=== poningru [n=poningru@n128-227-34-184.xlate.ufl.edu] has joined #launchpad === hannosch [i=hannosch@e176103166.adsl.alicedsl.de] has joined #launchpad [12:45] hannosch: oi [12:45] jordi: hi [12:46] jordi: I still have a duplicate pot in here: https://launchpad.net/products/plonesoftwarecenter/+translations :( [12:47] bleh [12:47] I'll nag people again :/ [12:48] The import was f**ked up somehow, but carlos couldn't fix it, so I added all entries manually to the right pot [12:56] lifeless: will it be possible to run baz2bzr on bzr checkouts in importd? [12:57] possible as in "technically feasible" and "a new enough bzrlib will be there" [12:57] hannosch: yeah, I fsckd when I imported to the wrong product [12:57] doh [12:58] jordi: no problem as long as it is fixed sometime :) === suodla is now known as dous === jsgotangco [n=jsg@210.4.38.43] has joined #launchpad [01:05] hannosch: hopefully :) [01:07] jordi: Could you point me to the current documentation for Rosetta? I'll guess I have to write some myself to explain how-to use Rosetta for my existing translators. So I would like to point them to some existing docs, or write some new if there's lacking some. === stu1 [n=stub@gb.ja.98.105.revip.asianet.co.th] has joined #launchpad [01:09] lifeless: ping, want to talk about you about potential need for special handling of "not quite atomic" behaviour of bzr commit compared to baz commit. [01:09] hannosch: basically, what there is is the FAQ. When I have time (heh) I will write a manual under at least two points of view: upstream maintainer and translator [01:09] unping for the checkout thing, it's not going to help anyway [01:09] hannosch: mail me, and lets coordinate about writing sometihng [01:10] jordi: will do, there is a new alpha release of Plone up this weekend, so I'll probably mail you next week ;) [01:11] ok :) [01:14] ddaa: what not quite atomic behaviour ? [01:15] commit, push, etc. works roughly like that: 1. add texts in the store 2. add revision entry in store 3. add revision to inventory 4. update head [01:16] roughly. you have the order wrong but close. [01:16] please correct me, I wish to learn [01:16] add texts [01:16] add inventory [01:16] add revision [01:16] update branch head [01:16] update working tree last revision [01:17] unlock everything [01:17] maybe I'm confused, but what happens if the commit is killed after adding the inventory. You get an inventory that references a revision that's not here... right? [01:18] inventories do not reference revisions [01:18] mh? [01:18] inventories reference fileid:revisionid pairs [01:19] revisions reference inventories [01:19] in the near future that will change to revisions reference fileid:revisionid pairs too - for the root node, and that root node will be the inventory [01:20] okay, I'm completely confuddled now... some internals documentation would be great... [01:20] nevermind [01:21] also, ids "update branch head" and "update working tree last revision" the same thing for a self-contained tree? === ulinskie [n=yolynne@202.57.88.34] has joined #launchpad [01:21] (that's relevant to the issue at hand) [01:22] the reference order is Revision owns an inventory owns file texts [01:22] EPARSE on 'ids "update branch head" and "update working tree last revision" the same thing for a self-contained tree' [01:23] s/ids/is/ [01:23] no, its not the same thing for a standalone branch [01:23] it is the same thing for a format 6 bzrdir [01:24] meta-format 1, available for use from 0.8 makes it different [01:24] that opens a new sort of confusing race on commit... [01:24] theres no race. There is a power-fail consistency issue [01:25] but we can journal that if we care to [01:25] if the commit is killed after updating the branch head and before updating the tree revision, you get an out of date tree that you need to revert and pull to unbreak... revert is totally not what you want to try in such a situation... [01:25] no [01:26] 'bzr update' will correct it and should never have issues as 3 way merge will see one side unchanged [01:26] okay, I will ask SteveA for alloted time to keep up with the bzr mailing list. I cannot work at my best in this situation :( [01:26] right... update... [01:27] also note that to kill commit there you will need to be very very fast off the mark, as its literally 2 disk operations apart [01:27] shit happens, in importd especially [01:27] and finally as I say, we can journal this: we can say 'pending commit $revid' in a file [01:27] and write that after everything is locked, before the branch head is updated. [01:28] can do it, and actually doing it is something different :) [01:28] Thanks for the explanations. So the issue I wanted to talk about is: [01:28] and when we start up if there are stale tree locks we can look for that and if the revid is in the branch just do it [01:29] ATM there are no stale tree locks. That would probably make things easier in the short term for importd if there are. [01:29] thats also a 0.8 feature [01:30] The general idea, is that commit puts a bunch of stuff in the store, that's not actually used until the branch head is updated. Usually, that's not a problem, the following commit will create stuff with different ids. [01:30] It creates some junk data, but it's usually not a big deal. [01:30] The issue I have, is how that pans out with baz2bzr in importd. [01:31] I dont see an issue. run baz2bzr after the mirror step in the current process [01:31] the data is consistent then with what is committed - arch gives you the same data each time. [01:31] Yeah, then what if baz2bzr is interrupted? [01:31] then run it again [01:31] For one thing, we use fixed revision ids, so I'm concerned that maybe the subsequent commit is going to cry conflict. [01:32] its designed for this. I'm not sure what your concern is [01:32] I'm not sure anymore either. [01:32] are you saying 'will baz2bzr work' [01:32] I think I should stop working on this stuff for today. [01:32] or are you saying 'I have tested it and it breaks' [01:32] if the latter - tell me and aaron as its a bug [01:33] if the former, treat it like a black box mmkmary [01:33] I'm asking will it work with sufficient shit-proofness for importd. [01:33] it should [01:34] it does not have specific tests, but I can't think of any expected fallout except in a very narrow range of circumstances. baz2bzr actually does its work semi atomically anyway with a temporary directory. [01:35] and the worst case situation is redoing a single branch over, which while not ideal does not seem hugely problematic to me given the plan [01:35] Initially, I was concerned about putting junk data in importd branches. [01:36] but as you said, it's not going to happen, because of predictable ids and data. [01:36] okay, I'm satisfied that there's no problem there :) [01:37] just exercising stone-turning skills to look for potential trouble. [01:37] lifeless: thank you [01:37] np [01:43] lifeless: Still no buildbot love. [01:43] "No module named testresources", same as before I think. [01:45] spiv: damn damn damn === Alinux [n=Ubuntu@d83-176-16-100.cust.tele2.it] has joined #launchpad === sevrin [n=sevrin@202.75.186.154] has joined #launchpad [02:38] Wow, were you guys aware of that? http://developer.yahoo.net/yui/ === Alinux [n=Ubuntu@d83-176-16-100.cust.tele2.it] has left #launchpad ["Ex-Chat"] [02:50] ddaa: the calendar widget looks good for date entry [02:51] I'm looking at the patterns now [02:51] e.g. http://developer.yahoo.net/yui/calendar/examples/default_2up/index.html [02:52] lovely [02:55] The menu portlet probably benefit from a treeview too, to hide the more rarely used items. [02:57] wow, rgb color picker! http://developer.yahoo.net/yui/slider/examples/slider.html [02:57] not terribly useful, but soooooo sexy [02:59] that yui stuff seems to be doing the rounds today [02:59] is it a new launch? [02:59] dunno, a relative of mine sent me a pointer... [02:59] I guess he read about it on some blog. [02:59] pff, that calendar widget doesnt work in konqueror :) [02:59] ddaa: friend of mine did the same :) [03:00] Lathiat: then fix it! It's BSD licensed! [03:00] i wouldnt have the slightest about javascript :) [03:01] Love it when companies get free software thing so right. BSD is just the right kind of license. [03:02] personally, i hate licensing :) [03:02] its too much effort to think about [03:03] It's like breathing. [03:03] you don't have to like it, you have no choice [03:05] indeed [03:13] hey anybody can help me with this [03:13] ttps://launchpad.net/malone/bugs/3987 [03:13] ulinskie - Changed attachments: [03:13] ulinskie Added: Patch to remove password field from UserPreferences [03:13] ulinskie http://librarian.launchpad.net/1569015/mo [03:15] what's your problem? [03:15] I can't edit out my wiki page and change the theme.. [03:16] coz everytime I change something..it says password did not match even if I gave already the correct password [03:16] ulinskie: don't enter your password in the form. [03:16] That should work around the issue. [03:17] ok [03:17] will do [03:17] ulinskie: the patch needs to be applied on the server [03:17] I'll tyr again [03:22] spiv, thanks [03:22] spiv, it already worked [03:22] spiv, god bless u [03:23] ulinskie: you're welcome :) [03:23] bless me too! [03:25] jsgotangco, god bless u too... although I know God had been showering you a lot this past year hehehehe === ulinskie is away: I love being Pinoy ... ayoko kasing maging mabahong isda [04:10] WTF does py.test think it is special and makes be jump through svn installation hoops and PYTHONPATH munging to use it? === sebest_ [n=sebest@86.71.122.17] has joined #launchpad [04:19] stub: to install the python2.4-pylib package, I needed to delete the syntax_error.py file and rerun "apt-get install python2.4-pylib" [04:20] stub: and then edit /usr/bin/py.test2.4 and change "from _findpy import py" to "import py" [04:22] spiv: buildbot bombs away [04:30] lifeless: A new error, in your mail. === spiv -> lunch [04:47] Ta. py.test works. Now I discover it sucks. I just want a traceback, not a damn essay! === mpt [n=mpt@219-89-159-91.jetstart.xtra.co.nz] has joined #launchpad [04:53] stub: whats using py.text? sqlobject ? [04:53] Yup [04:53] how do you find it ? [04:54] is it as crufty as it looks ? [04:54] From the sqlobject.org web site [04:54] nono, I know where the code is [04:54] I meant whats your user experience [04:54] Although I gave up on the SVN installation (they don't release distutils) and used Universe [04:55] Installation is a major negative. You just have to use distutils until something better comes along - not make your developers jump through pointless (to the developer) hoops. [04:55] Ran 1355 tests in 144.843s [04:55] bzr test suite is slowly growing [04:55] Output is way too verbose to be useful. The exploded tracebacks are not helpful to me and I can't turn them off [04:56] (ie. my tracebacks are spread over several screens intertwined with the source code) [04:56] are tests objects? can you manipulate (report/decorate/inject dependencies) them ? [04:56] stub: there is a --verbose flag if you want more output [04:56] jamesh: he wants --without-verbose === stub pokes jamesh with a pointy stick [04:57] It does seem to find and run tests however [04:57] lifeless: tests are functions or methods with names beginning with test_*, containing assert statements [04:57] No idea if it supports doctests [04:57] it seems to do some interpreter tricks to provide useful error messages for "assert x == y" [04:58] jamesh: IIRC running py.test tests with -O disables all the tests [04:58] jamesh: which seems freakily whack to me [04:58] Options like '--nomagic' are not helpful and indicate deeper problems to me [04:58] Running with -O is freakily whack [04:59] stub: I have serious doubts about py.tests goals, to me they seem to want to make testing les useful rather than easier to use. They dont claim that, its just my observation [04:59] of the net outcome [05:00] Indeed. Here I am wondering if I can be arsed making sure my altered SQLObject tests pass. [05:00] (although part of that is that the tests were not passing to begin with) [05:04] lifeless: I suppose that running "py.test -O" is an optimisation then [05:06] jamesh: indeed [05:13] Yay for useless py.test output! https://chinstrap.ubuntu.com/~dsilvers/paste/fileBK6vBc.html [05:15] Module imports fine from the command line, yet the output says 'failed to load'. And the traceback is mainly from the test machinery and suddenly jumping to the line that raised the exception with no context! [05:18] go libpy [05:23] stub: maybe you'll get a different answer if you tell it to use less magic [05:24] Nup. [05:25] jamesh: whats the public url for your new gpgme wrapper ? [05:25] stub: --tb short [05:26] stub: But yeah, the defaults are annoying. [05:26] There is no --tb in my version === mpt [n=mpt@219-89-156-94.jetstart.xtra.co.nz] has joined #launchpad [05:27] stub: Ah, I'm looking at SVN. [05:27] Yay for 'just pull it from SVN' and a release mechanism for creating obsolete packages [05:27] (And the SVN version doesn't work properly with SQLObject anyway...) === Alinux [n=Ubuntu@d83-176-16-100.cust.tele2.it] has joined #launchpad === JanC [n=janc@lugwv/member/JanC] has joined #launchpad [06:18] someone in states ? [06:19] http://l10n-status.gnome.org/gnome-2.14/ka/index.html I would like to download all files from this place ? is it possible? === mpt_ [n=mpt@219-89-137-182.jetstart.xtra.co.nz] has joined #launchpad [06:19] or how can I donwload all po files from here? [06:26] lifeless: Want to do a quick review of a fix for standalone page tests? https://chinstrap.ubuntu.com/~dsilvers/paste/fileKYQh2d.html [06:26] lifeless: Your one-liner wasn't sufficient. [07:11] spiv: Ok for me to merge in my SQLObject branch? [07:12] stub: Yep. [07:12] (I thought my mail said so?) [07:12] stub: Btw, I was surprised you wrote tests, given what a PITA the SQLObject test suite is :) [07:13] I'm certainly not complaining, though... [07:20] Gah! Now my testing is showing the boolean indexes are being used for '=true' lookups but not 'is true' lookups, which is the opposite to what my tests with partial indexes showed :-| [07:31] spiv: oh right, *thats* the local fix I have for zope [07:31] spiv: I've forgotten what it was :) [07:31] lifeless: Heh. [07:31] lifeless: Well, I don't mind fixing zope if you prefer. [07:31] this is easier, given we still have z3.2 incoming [07:32] lifeless: Right now though I'm off to yoga :) === spiv nods [07:32] wont that break the tests I wrote ? [07:32] or do I fudge on checking the id ? [07:32] anyway looks good [07:32] r=lifeless [07:32] I didn't run your tests... I just checked that test.py did what I expected :) [07:32] Ok, thanks, I'll double-check and merge after dinner. [07:32] ./test.py lib test_test_pages === mpt [n=mpt@219-89-137-182.jetstart.xtra.co.nz] has joined #launchpad [07:55] hi [07:55] mpt: how's the network today? [07:56] SteveA: I'm using the pretend-to-be-the-Mac trick, and it's working so far [07:57] My current trouble is remembering how to rebuild sourcecode/ for my 2006-01-build-pages/ branch [07:57] or how to update it, rather [07:58] File "/home/mpt/hacking/lp/2006-01-build-pages/lib/canonical/lp/__init__.py", line 69, in registerTypes [07:58] psycopgda.adapter.registerTypes(psycopgda.adapter.PG_ENCODING) [07:58] TypeError: registerTypes() takes no arguments (1 given) [07:58] because of the psycopgda update [07:58] which I had to merge in because there was one other conflict in the branch. [07:59] kiko told me how to do it before but I don't seem to have the log [07:59] it was something to do with link-source-code.sh ... [08:01] mpt: Update your sourcecode/psycopgda as per mailing list instructions [08:02] cd sourcecode/psycopgda; bzr pull [08:02] jblack: around? [08:02] mpt: cm.py can be used to update trees too [08:04] thanks stub -- I had your message open in front of me but all it said was "Update your psycopgda" [08:05] You need to configure your email client to display the fine print [08:05] yes, or get a hackitude implant === mpt is jsut a UI desinger [08:11] stevea: What are you doing up? [08:14] Thats wierd. I merge r3139 from launchpad/devel into launchpad/production/1.49 and I end up with an added file database/schema/patch-40-18-0.sql.moved instead of database/schema/patch-40-18-0.sql [08:16] Yet in the trunk it is patch-40-18-0.sql and no subsequent patches have renamed it that I can find [08:16] lifeless: ^^^ might want a look [08:17] stub: .moved happens on conflicts of a certain sort [08:17] Ahh... looks like a conflict. The contents of the file on the trunk is not what I expected [08:18] if it was deleted and add that would cause that [08:19] Yer - celso landed it with a different patch number than I told him to :-/ [08:19] jblack: well... it is 9:20 am [08:19] Ahh. Whats on your mind? [08:21] i sent a merge request to pqm yesterday, and didn't receive a response. lifeless told me that it had caused a new kind of error, and so he got the error report, and will add handling of this kind of error. the error was to do with the ssh command failing. lifeless speculated that it was because pqm couldn't get to the place where the branch is. [08:22] i think i was following the RocketfuelSetup instructions for this. i'd like to try merging again, with you around, so that we can see if i can reproduce the problem. [08:23] jblack: does the submit-bzr-merge uses .bzr/x-push-data [08:24] looking [08:24] for this branch, .bzr/x-push-data contains stevea@chinstrap.ubuntu.com:/home/warthogs/archives/stevea/sqlos/devel/ [08:24] i wonder if submit-bzr-merge isn't cutting off the "stevea@" part? [08:24] Yes, it does. [08:24] Yes, it does use x-push-data [08:24] MYURL=$(cat .bzr/x-push-data | sed -e 's|^$.*$:/|sftp://\1/|g') \ || (echo FAILED to get published location && exit 1) [08:25] This is the line that uses it. Thats a complicated regex, so its possible. [08:25] sftp://stevea@chinstrap.ubuntu.com/home/warthogs/archives/stevea/sqlos/devel/ [08:25] that is the result [08:25] so, i guess pqm would have problems with that [08:31] Ok. thats fixable. [08:31] I'll introduce a second regex to turn my url into a fqdn into something like $branchurl [08:35] stevea: is this blocking you? [08:38] jblack: change .* to [^:] * [08:38] jblack: it isn't blocking me [08:40] dooglus: You may be missing context. This is used for actual sftp pushing too [08:40] jblack: I'm missing everything :) sorry I didn't notice where I was. [08:40] I thought I was in #ubuntu, where people answer questions before reading them ;) [08:40] Heh. :) [08:41] try rebooting! [08:43] cat .bzr/x-push-data | sed -e 's|^$[^@] *@$$.*$:/|sftp://\2/|g' [08:44] morning [08:44] hey jblack , how you bee? [08:44] err, been even [08:44] jblack: do you think that would be okay? [08:44] it seems to work for me [08:44] but i'm don't really know sed [08:45] SteveA: are you wanting to throw away the part before the @ ? [08:45] if the script were written in python, then this replacement could have a simple doctest :-) [08:45] dooglus: yes [08:45] if there is a part before the @ [08:45] there may or may not be [08:45] SteveA: looks good then. is there always an '@'? 'cos if there isn't, your sed script won't change anything [08:46] there isn't [08:46] do that's a problem [08:46] SteveA: if it works for you, then I'll put that up [08:46] jblack: it works for me, but will fail for others, as dooglus pointed out [08:46] SteveA: test it on an input without either an "sftp://" prefix or an embedded '@' [08:46] cat .bzr/x-push-data | sed -e 's|^$[^@] *@$\?$.*$:/|sftp://\2/|g' [08:47] I think the easiest thing is to generate a second regex for the merge request. === carlos [n=carlos@84.76.255.40] has joined #launchpad [08:47] what i just posted works well for me [08:47] SteveA: what if there's no @ apart from in the filename to copy? [08:47] SteveA: I'm in a meeting with jblack [08:47] SteveA: can you pick this up in say 15 ? [08:47] sure [08:47] thanks [08:48] morning [08:48] hi carlos [08:51] spiv: ping? === mpt [n=mpt@219-89-152-47.jetstart.xtra.co.nz] has joined #launchpad [08:52] spiv is at yoga [08:52] he may be up for a call afterwards [08:53] failing that tomorrow [08:53] and I can fill you in myself later [09:02] okay, cool [09:06] stub: has anyone talked with you about getting the changes to +translate pages into production soon? [09:07] Merge to devel/launchpad/: [trivial] ShippingRequest index and fix build.pocket db patch (r3143: Stuart Bishop) [09:08] SteveA: Nope [09:08] stevea: Ok. Where were we? [09:08] I was highly lossy while we were talking. Can we just start over? [09:08] stub: carlos and daf made translate pages not try to re-render on a redirect [09:09] it ought to be an unintrusive browser-code-only patch, that may cut out a bunch of hard timeouts [09:09] jblack: cat .bzr/x-push-data | sed -e 's|^$[^@] *@$\?$.*$:/|sftp://\2/|g' [09:09] that appears to work for both cases with and without a name@ at the start [09:10] You've tested? [09:10] i've asked pqm to merge stuff [09:10] it isn't a real test [09:10] a real test would involve factoring out the conversion of text that is expected to be in x-push-data, and testing that conversion in a variety of cases [09:10] I don't mean a test of the whole process, but a test of that regex. [09:11] Ahh. I understand [09:11] jblack: the regex works for me. as the maintainer of the scripts, now you should check that it works for the cases you can think of [09:11] stub: that's rev 3141 [09:11] I think that there may be an easier way to do this. [09:11] also, a comment in the script describing what the transformation is, would help those maintaining the script [09:12] SteveA: I didn't know it should be cherrypicked [09:12] carlos: it is a simple change that may have a big effect in reducing timeouts [09:12] but, let's see what stub thinks about it [09:12] If we make sure the ssh config stuff docs are in both PQMsetup and rocketfuelsetup, then the user never needs to set the username [09:12] SteveA: ok [09:12] I'll run the tests and see what happens [09:13] (after my swim) [09:13] Stevea: what do you think about it? [09:13] jblack: okay. although i think it would still be good for the submit-bzr-merge script to deal elegantly with having username@ in x-push-data [09:13] beacuse otherwise, it has a failure mode that takes a long time to discover, and is quite obscure [09:14] the submit script could either: deal with having username@ in x-push-data, or, give a comprehensible error and fail early if there is username@ in the x-push-data [09:18] This is getting a little long for a bash script. :( [09:19] this coming from an arch hacker! [09:21] https://wiki.launchpad.canonical.com/PQMSetup?action=diff&rev2=22&rev1=20 [09:21] Heh. I fought my fair share with Tom about larch being in bash. He later admitted that the group was right. =) === mpt_ [n=mpt@219-89-137-140.jetstart.xtra.co.nz] has joined #launchpad [09:23] jblack: i think you can remove the work in progress, do not use marker now [09:24] As you wish. done [09:26] bzr is a python script, so there is nothing wrong with making submit-bzr-merge into a python script too. Its not like Python won't be installed or anything. [09:26] or a plugin might be better === stub goes for a swim [09:28] stub: Thats about what I'm thinking [09:28] They're in bash today because they were initially bash. === mpt [n=mpt@219-89-137-140.jetstart.xtra.co.nz] has joined #launchpad === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad === Alinux [n=Ubuntu@d83-176-16-100.cust.tele2.it] has joined #launchpad === mpt_ [n=mpt@219-89-137-140.jetstart.xtra.co.nz] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === Link9618 [i=Link@ppp-67-125-118-246.dialup.irvnca.pacbell.net] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [10:29] rock, a 1.5 MB failure message === mpt__ [n=mpt@219-89-150-174.jetstart.xtra.co.nz] has joined #launchpad === mpt__ is now known as mpt [10:34] I need to write a couple large documents. Is there anything I can do for anyone before I disapear for a few hours? [10:38] mpt hi, do you have some minutes to help me with javascript? === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad [10:39] carlos, I don't really know JavaScript yet, you'd be better off asking kiko [10:39] (I'm trying to study it an hour each day, but haven't got that far yet :-) [10:40] ok [10:40] kiko-zzz: please, ping me when you are awake [10:40] mpt: thanks anyway [10:47] pqm is down for a bit while I run tests on balleny. Should be back in 30 mins if I remember ;) === dous is now known as suodla [10:59] good morning [11:00] hi daf [11:01] hi mpt [11:01] did you get your router sorted? [11:03] not really [11:03] I have Internet on my Ubuntu box now in "I'm pretending to be Matthew's iBook" mode [11:03] i.e. having the same MAC address and IP number [11:03] so they can't be connected simultaneously [11:05] very odd === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [11:11] mpt: bug #30002: confirm or reject? [11:11] malone bug 30002 in launchpad "Cannot add HTML (or other formatting) in descriptions" [Normal,Unconfirmed] http://launchpad.net/bugs/30002 === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [11:12] daf, reject I think [11:13] right, thought so [11:13] can you do that? [11:13] sure [11:13] I think you'd do better than I at explaining the rationale [11:15] jamesh: ping [11:18] stub, pqm back up yet? [11:19] mpt: yes [11:19] ta [11:22] SteveA, carlos, daf: r3141 has been cherrypicked [11:22] stub: thank you [11:23] stub: thanks! [11:23] jordi: btw, you should be able to remove entries from the translation import queue [11:23] jordi: I already removed the drupal ones to test it [11:24] stub: great, I'll update the status [11:28] lifeless: ping === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [11:31] AssertionError: 1 != 2 [11:31] morning hackers [11:31] dang this reality-based mathematics === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad [11:32] spiv: ping === daf decides to move Australia into the Atlantic [11:36] hi [11:36] is launchpad known to have issues today? [11:36] it returns some "500 Internal Server Error" when trying to change settings of a bug === mjg59 [n=mjg59@cavan.codon.org.uk] has joined #launchpad [11:37] Hi - I uploaded a package last night, but launchpad shows no sign of it and I don't seem to have got an acknowledgement mail? [11:38] OOPS-46D173 now [11:38] https://chinstrap.ubuntu.com/~jamesh/oops.cgi/46D173 [11:38] The .upload file suggests that it all went up successfully [11:40] 7.0.0-0ubuntu1 was in NEW at the time when I uploaded 7.0.0-0ubuntu2, which may have something to do with it? [11:40] (Should I just file a bug?) [11:40] the .upload wouldn't know much more than it went to the ftpserver okay [11:40] Kinnison: Yeah [11:40] the drop on the floor will be that it couldn't find the orig in the distro (known bug) [11:41] Kinnison: Ah, right [11:42] The path of least resisitance is to get the first accepted into ubuntu and processed into the archive before trying to upload the second [11:43] mjg59: I can have a look for you,one sec [11:43] stub: is librarian gc running regularly? [11:43] Yeah, but I discovered the first was broken [11:44] (Missing build-depend that didn't show up because I had a stale copy of the library sitting around anyway) [11:44] upload the second having prepared it -sa ? [11:44] OOPS-46C178 [11:44] https://chinstrap.ubuntu.com/~jamesh/oops.cgi/46C178 [11:44] grumpf, I'm trying to update that bug for like 10 times now ... somebody fancy to look on what those oops are? :) [11:45] mjg59: xserver-xgl_7.0.0-0ubuntu1_source.changes REJECTED -> UploadError made it out to the main loop: Unable to find distrorelease: unstable [11:45] cprov: Yeah. I fixed that and then uploaded. [11:45] mjg59: didn't you receive the email ? [11:45] cprov: No, I got that one [11:45] I then got a "is NEW" mail [11:45] And then I uploaded a new version [11:46] The one that went into NEW first got built (with resulting broken binaries that people are now bitching about), and the second one vanished :) [11:46] mjg59: uhm .. will see [11:47]