=== mpt_ [n=mpt@219-89-153-81.jetstart.xtra.co.nz] has joined #launchpad [12:12] matsubara, vai ou no vai? eu tenho que ir embora! [12:13] vou onde? === AlinuxOS [n=Ubuntu@d83-176-25-250.cust.tele2.it] has joined #launchpad === X1n3 [i=X1n3@cm-83-97-180-148.telecable.es] has left #launchpad [] === X1n3 [i=X1n3@cm-83-97-180-148.telecable.es] has joined #launchpad [12:53] hi [12:56] what is? [12:56] that the free cds need to be aproved? [12:57] i have 45 of the 100 that i say [12:58] X1n3, write to the email address I provided earlier. === kiko [n=kiko@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === X1n3 [i=X1n3@cm-83-97-180-148.telecable.es] has left #launchpad [] === ryanakca [n=ryan@d226-20-171.home.cgocable.net] has joined #launchpad [01:08] what is "ubuntero"? [01:10] another FAQ [01:10] a person who has signed the Code of Conduct [01:13] kk, ty [01:13] njy [01:18] dilys, give me the good news tomorrow === kiko-zzz yawns [01:25] Merge to devel/launchpad/: [trivial] Fix for bug 31380: source package sort by version doesn't cope with invalid version numbers. Use apt_pkg.VersionCompare instead of Sourcerer's unmaintained Version method which blows up occasionally. Fixes an OOPS. Even removes an XXX (r3192: kiko) === jsgotangco [n=jsg@210.4.38.43] has joined #launchpad === ohoel [n=eruin@unaffiliated/eruin] has joined #launchpad === stub [n=stub@ppp-58.10.74.179.revip2.asianet.co.th] has joined #launchpad [02:04] Merge to devel/launchpad/: rs=BjornT though rather trivial; Fix for bug 31367: Specifying a non-published binary package when filing a bug causes an oops. Change the add bug process to ignore the package if it was never published in the distribution, and test it using Gentoo (which now uses Malone officially, yay. Or at least in sampledata). This fixes a topcrasher, so hooray for us. (r3193: kiko) [02:13] jamesh: ping? [02:23] Kinnison: pong [02:23] jamesh: I'm desperate for a bzr conversion of the gnome-power-manager portion of gnome-cvs [02:23] jamesh: but tailor can't do its job from gnome anoncvs [02:23] jamesh: any chance you could grab me a tarball of that bit of cvs? [02:23] you want a tarball of the repo? [02:23] please === Kinnison hopes he has time to translate it before he falls asleep :-) [02:24] it's 01:24 [02:25] http://www.gnome.org/~jamesh/gnome-power-manager-repo.tar.gz <- 3.8MB [02:25] fetching now [02:26] Kinnison: looks like time doesn't go backwards for that module, so Tailor shouldn't get confused [02:27] UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-3: invalid data [02:27] go tailor [02:31] any suggestions? [02:32] if I do "LANG=C ....." then it whinges the equivalent with an ascii codec [02:33] Might try LANG=en.iso-8859-1 -- text files without an explicit encoding have a tendancy to be iso-8859-1 encoded [02:34] that's an "unsupported locale" apparently [02:35] even after I've allegedly created the en_GB.ISO8859 locale python rants [02:36] Kinnison: You could try changing the default encoding in /usr/lib/python2.4/site.py (the setencoding() method), but make sure you change it back! === stub cluches at straws [02:37] Kinnison: did you try putting "encoding = iso-8859-1" in the [cvs:source] section of your .tailor file? [02:38] nope 'cos I didn't know it existed [02:38] trying [02:38] oooh, jamesh wins [02:38] tailor running [02:38] iirc, tailor told me to do that when I tried [02:38] jamesh: aah didn't tell me [02:38] Kinnison: which version of tailor are you using? [02:39] 0.9.20 apparently [02:39] Tailor could certainly do with some robustness improvements [02:40] Anyone have access to merge to the tailor trunk? pull out canonical.encoding and use encoding.guess as a fallback. Otherwise you won't be able to migrate trees where commit messages used mixed encodings. [02:52] Run tailor! Run! [03:29] Hmm, up to the 19th January [03:35] cor 10th Feb [03:35] tailor in getting faster shocker [03:42] jamesh: you're a star === Kinnison goes to bed [03:42] ciau === stu1 [n=stub@ppp-58.10.73.80.revip2.asianet.co.th] has joined #launchpad === merriam [n=merriam@84.12.156.26] has joined #launchpad === irvin [n=irvin@ubuntu/member/irvin] has joined #launchpad [05:16] stu1: do you have any ideas about this bug? https://launchpad.net/products/launchpad/+bug/31651 [05:16] malone bug 31651 in launchpad "IPlacelessLoginSource.getPrincipalByLogin(email) returns None with an email address that was just created" [Normal,Confirmed] [05:17] stub: the second OOPS report seems very weird, given the statement log [05:22] If the insert was failing, the transaction would be screwed. So we can assume the inserts are working correctly [05:22] I could see that behavior happening if we had multiple connection objects. [05:23] I could see that happening if some of the code was creating a connection using sqlbase.connect(), as it opens a fresh database connection. [05:24] (by default - I think I landed an option recently to make that call reuse the existing connection if a parameter is passed? Can't remember if it landed or if I backed it out) [05:24] But that wouldn't be happening because it is all SQLObject code [05:25] could it be index corruption? [05:26] Unlikely - postgresql is good on that front. Bugs like that seem to only occur in the pathalogical edge cases some people create. [05:26] But possible [05:27] Do we log calls to the connections commit and rollback methods? [05:28] Easiest way to explain that behavior would be some doofus sticking a rollback in the code, or rollback being called by Z3 for some pathalogical reason [05:30] Is it happening often? I can reindex the person table for a laugh but it will render launchpad unusable for maybe 10 mins [05:31] I don't know how often it happens: salgado only mentioned two oops reports [05:31] I'll make a note to reindex the person and emailaddress tables next rollout (and hopefully remember to check my notes...) [05:41] I wonder how much more reliable things would be if SQLObject did "self._connection = self._connection" in its constructor? [05:41] it'd definitely help with problems related to garbage collection on the wrong thread [05:53] SQLOS replaces self._connection with a descriptor, so in our case I don't think it would help much (?). [06:03] the descriptor is the issue: it means that if an object gets garbage collected on a different thread, the destructor will use a different _connection than the one used to create the object [06:04] so the object doesn't get removed from the cache [06:06] jamesh: Ouch, that's a nasty one. [06:06] spiv: SteveA pointed it out to me originally [06:06] jamesh: Yeah, instances really should know what connection they're tied too. [06:07] spiv: with plain sqlobject they do: self._connection :) [06:07] Right :) [06:07] zopeless also has its own descriptor for _connection :/ [06:08] yeah [06:08] I suppose one way to do it would be to make the descriptor's __get__ method do the assignment [06:08] so an sqlobject gets bound to a connection the first time it tries to use it === mpt__ [n=mpt@219-89-133-196.jetstart.xtra.co.nz] has joined #launchpad === stub [n=stub@gb.ja.101.40.revip.asianet.co.th] has joined #launchpad === pkunk_ [n=pkunk@a84-231-5-36.elisa-laajakaista.fi] has joined #launchpad === irvin [n=irvin@ubuntu/member/irvin] has joined #launchpad === carlos [n=carlos@84.76.255.40] has joined #launchpad === koke [n=koke@ubuntu/member/koke] has joined #launchpad === istbot [n=gokaye@88.224.183.203] has joined #launchpad [09:15] hi [09:16] fuck you ChanServ === fish [n=kvirc@h081217119213.dyn.cm.kabsi.at] has joined #launchpad === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad === stub [n=stub@gb.ja.101.40.revip.asianet.co.th] has joined #launchpad === mpt [n=mpt@219-89-132-228.jetstart.xtra.co.nz] has joined #launchpad === dsaa [n=dsaa@210.1.85.218] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === carlos_ [n=carlos@62.87.127.194] has joined #launchpad === mpt [n=mpt@219-89-132-228.jetstart.xtra.co.nz] has joined #launchpad === WaterSevenUb [n=WaterSev@195-23-238-209.nr.ip.pt] has joined #launchpad [11:21] spiv: hi, around? [11:24] lifeless: can you make it more apparent, in emails sent to arch-commits, what is the branch being merged into? [11:25] For example, by telling the branch name and nick in the message body and in a header [11:25] I'm quite confused with bzr commits being mixed with launchpad commits [11:26] I have to actually think to tell what the commit is relevant to. [11:26] It hurts. [11:41] +1 [11:43] And also list the commits in chronological instead of reverse chronological order :-) [11:43] And make the list of modified files as compact as it was in the baz days [11:43] And, and, and ... === mpt gets a headache from Launchpad permissions [11:44] carlos, do you happen to know what the template equivalent of 'launchpad.Edit' is? [11:44] tal:condition="..." [11:45] I thought it would be tal:condition="view/edit", but no [11:45] I don't remember it, but I know where I can see it [11:45] just a second... [11:46] mpt: well, you first need to associate the launchpad.Edit permission with the interface [11:46] I think it already is, because it's used for this page's menu [11:46] s [11:47] @enabled_with_permission('launchpad.Edit') works for one of the menu items [11:47] but now I want to do the same thing in TAL [11:48] hmmm, other templates are using "view/edit" [11:48] tal:condition="entry/required:launchpad.Edit" [11:49] entry is a SQLObject [11:50] aha [11:50] so in this case, tal:condition="context/required:launchpad.Edit" [11:50] Great, carlos, thanks [11:50] yeah [11:50] mpt: you are welcome [11:52] another bug fixed [12:00] and another === hunger [n=tobias@p54A62775.dip0.t-ipconnect.de] has joined #launchpad [12:02] Is there any documentation on what I should do to report bugs in launchpad? [12:03] Like should I assign bugs? To whom? May I close bugs? Which ones? Which priorities/severities may I assign? That kind of stuff? [12:04] What does assigning a bug signify? [12:04] All this workflow kind of stuff. [12:11] hunger: that kind of workflow is specific to each project using launchpad. for example for ubuntu bugs, http://www.ubuntu.com/community/participate#head-5f51744fe2ab198ea488499b475eedefb45860c2 is proably a good start. [12:11] BjornT: Thanks! [12:13] Even though the documentation is still about bugzilla there:-) === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === jinty [n=jinty@196-28-45-170.jhb.netdial.co.za] has joined #launchpad [12:14] good morning === mpt [n=mpt@219-89-132-228.jetstart.xtra.co.nz] has joined #launchpad [12:16] hunger: really? :) i looked only briefly, and saw that it mentioned launchpad and malone, so i assumed they were updated === AlinuxOS [n=Ubuntu@d83-176-25-250.cust.tele2.it] has joined #launchpad === lbm [n=lbm@x1-6-00-13-10-7a-d1-e4.k233.webspeed.dk] has joined #launchpad [12:53] hello hackers of the world [12:53] UNITE === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:04] stub, ping? [01:17] kiko: pong [01:17] hello stub [01:17] how's thailand today? [01:17] it is hot and humid here [01:17] and the air is sizzling with pqm commits [01:18] kiko: same same === beyond [n=beyond@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:18] stub, would you consider my commits from yesterday for the rollout? [01:18] yes, I was thinking of rolling out... === stub checks his email [01:18] r3193 [01:18] stub, matsubara has one OOPS fix to land this morning [01:19] ok [01:19] it hasn't landed because he apparently hasn't had a haircut yet or something like that [01:19] matsubara, can you mail stub cc: launchpad with the revision you land your majestic fix for bug 5757 the bug from hell? [01:19] malone bug 5757 in malone "OOPS: requesting an upstream fix doesn't check input for duplicates" [Normal,In progress] http://launchpad.net/bugs/5757 [01:19] Can I use that excuse? [01:20] stub, it's harder in your case because it is painfully obvious you have not had a haircut in the last 19 years [01:20] kiko: yes, I can. but let's see if pqm will accept it [01:20] thanks [01:21] kiko: 4 conflicts [01:21] fix them and resubmit [01:21] they should be trivial [01:22] does the zopeless test harness actually commit to the database? [01:22] daf, ping? === fabbione [i=fabbione@gordian.fabbione.net] has joined #launchpad [01:22] ddaa, I believe so [01:22] otherwise, how would selects work? [01:22] i.e. if I use LaunchpadZopelessTestSetup, can I put some some test data in the database, spawn a subprocess, and have the subprocess retrieve the data? [01:23] yes [01:23] (after commit, of course) [01:23] yes [01:23] ddaa, look at gina.txt [01:23] I do something like that in it [01:23] I trust you. [01:23] there may be hints in that file [01:24] just starting to hit the first "duh, didn't think of that" in implementing bzr imports... [01:24] stub, ping 2.0, a bit more urgent [01:24] https://launchpad.net/distros/ubuntu/+ticket/256/+index\ [01:24] okay, looking [01:24] stub, this suggests to me that the migration for statuses we did wasn't complete [01:24] stub, can you handle the database hack? [01:25] ok [01:26] kiko: it's the first time I see a use of "import transaction". Is that a relic, or is that a new preferred way of doing commits and stuff? [01:26] I think it's the way it's done in tests BIMBW [01:28] how does that compare to canonical.database.sqlbase's begin, commit and rollback? [01:28] launchpad_prod=# select status,count(*) from ticket group by status; [01:28] status | count [01:28] --------+------- [01:28] 30 | 12 [01:28] 20 | 169 [01:28] 10 | 222 [01:28] (3 rows) [01:29] stub, wth is wrong with that page? is it a keyerror on something else? it still oopses === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:29] The ticket update has been done - not sure where that 40 is comming from? [01:29] could it be /gasp/ hardcoded?! [01:29] Would the page template be broken? [01:30] it must be the case [01:30] probably something wrong in the menu links [01:30] but where? [01:31] stub, can you make sense of that traceback? [01:32] kiko: ah, i think there is some history that needs to be migrated :(, i'll take a look. [01:32] thanks BjornT [01:33] that's okay -- it appears to be affecting few users [01:34] stub: please run: select status,count(*) from ticketreopening group by status; [01:35] Just found that table :) [01:35] launchpad_staging=> select priorstate,count(*) from ticketreopening group by priorstate; [01:35] priorstate | count [01:35] ------------+------- [01:35] 30 | 23 [01:35] 50 | 2 [01:35] 40 | 3 [01:35] (3 rows) [01:35] enjoy the pain [01:36] man this my bloody valentine album is excellent [01:38] BjornT: Do you think just priorstate needs to be updated, or is it more complex like the ticket update patch? [01:39] Otherwise I've got: [01:39] UPDATE ticketreopening SET priorstatus=10 WHERE status IN (20, 30); [01:39] UPDATE ticketreopening SET priorstatus=20 WHERE status=40; [01:39] UPDATE ticketreopening SET priorstatus=30 WHERE status=50; [01:41] stub: it's just the priorstate column that needs to be updated. yes, i was going to give you those queries :) although, the last 'status's should be priorstatus as well. [01:41] BjornT? [01:41] kiko: yes? [01:41] I didn't understand your last phrase. [01:41] bah - they are all priorstate [01:42] ah, yes. [01:42] tickets fixed [01:42] good work stub and BjornT [01:42] the page works! === dsa [n=dsaa@210.5.87.33] has joined #launchpad [01:50] stub, ping? [01:50] ? [01:51] stub, could you find out how many bugwatches we have for each bug tracker type? [01:51] I'm in the middle of a hack or else I would do it myself [01:51] if you are uberbusy I can do it later [01:54] launchpad_prod=# select count(*),bugtrackertype from bugtracker,bugwatch where bugwatch.bugtracker = bugtracker.id group by bugtrackertype; [01:54] count | bugtrackertype [01:54] -------+---------------- [01:54] 3730 | 2 [01:54] 22965 | 1 [01:54] 9 | 4 [01:54] (3 rows) [01:54] thanks dude [01:54] appreciated === carlos -> lunch [01:56] If you need me for anything, I will be available by phone. I need to recharge it [01:56] see you later [01:56] carlos, did you get cprov a bugfix [01:56] shit === pkunk__ [n=pkunk@a84-231-5-36.elisa-laajakaista.fi] has joined #launchpad === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has joined #launchpad === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad [02:08] stub, can you do a select datecreated from person where name = 'daniangella'; on production? === Keybuk [n=scott@213-78-32-60.ppp.onetel.net.uk] has joined #launchpad [02:08] 2006-02-23 10:20:46.878019 [02:09] that's UTC, right? [02:11] yup === raptoid [n=raptoid@85.96.210.207] has joined #launchpad [02:33] BjornT, ping? [02:33] bradb, ping? === jsgotangco [n=jsg@ubuntu/member/jsgotangco] has joined #launchpad [02:34] kiko: pong [02:34] bradb, have we had the existing Ubuntu Dapper tasks closed or updated? [02:34] bradb, if not, could you please take care of that today. [02:35] sure [02:35] (mark mailed me) thanks! [02:36] Hm, this could be painful [02:36] There are 49 + assignee and various status information to keep on them. [02:37] I wonder if we can offload that to someone else. === kiko thinks [02:37] jblack? [02:39] Maybe an Ubuntu triager? [02:39] can you try finding one? [02:39] sure === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #launchpad [02:43] kiko:? [02:43] jblack, was wondering if you could help us with something, but.. [02:43] but... [02:44] what's the something? [02:44] moving some ubuntu bugs around [02:44] let's see if dholbach is game first, otherwise you can help [02:44] heh. I don't know if I can help until I understand the scope of the help. [02:45] :) [02:45] If its a company priority, I can drop work responsibilities to do it though. [02:47] jblack: looks like dholbach is on top of it, thanks [02:52] kiko: pong? [02:52] BjornT, never mind, was the topic above [02:52] ok [02:52] thanks though === doko [n=doko@dslb-084-059-085-222.pools.arcor-ip.net] has joined #launchpad === irvin [n=irvin@ubuntu/member/irvin] has joined #launchpad [03:01] hi all [03:01] hello mdke_ [03:01] an upload to breezy-updates was published yesterday [03:01] and it has appeared in the archive but is not being included in the index [03:01] https://launchpad.net/distros/ubuntu/breezy/+source/ubuntu-docs/5.10-6.3 [03:01] http://archive.ubuntu.com/ubuntu/pool/main/u/ubuntu-docs/ [03:01] when did it appear in the archive, mdke_? [03:02] kiko, i don't know, it was built about 24 hours ago, so maybe soon after that? [03:02] does the file time not suggest that === mdke_ downloads it [03:03] about 11 hours ago? maybe [03:03] i don't know [03:04] it finished building about 26 hours ago according to https://launchpad.net/+builds/+build/170866 [03:05] mdke_, okay, we'll need cprov to look into it and figure out why apt-ftparchive isn't doing it's thing [03:05] shall I file a bug, or will you guys look into it without? [03:05] mdke_, file a bug and ping cprov [03:06] thanks kiko [03:06] enjoy [03:09] cprov, bug #32721 for you. Thanks! [03:09] malone bug 32721 in soyuz "Package built for breezy-updates is not appearing in the package index" [Major,Unconfirmed] http://launchpad.net/bugs/32721 === jsgotangco [n=jsg@125.212.123.59] has joined #launchpad === mdke_ is now known as mdke === tseng [n=tseng@unaffiliated/tseng] has joined #launchpad === hunger [n=tobias@p54A61C35.dip0.t-ipconnect.de] has joined #launchpad [03:19] is it a known issue that closing any bug makes launchpad oops? [03:20] tseng, no, it is not. OOPS code please. [03:20] kiko: OOPS-55C321 [03:20] https://chinstrap.ubuntu.com/~jamesh/oops.cgi/55C321 [03:20] kiko: this is the second bug i've tried to close with the same result [03:21] hold tight london [03:21] BjornT, ping [03:21] pong [03:21] I need a band-aid for tseng [03:21] BjornT, from_addr = format_address(person.displayname, person.preferredemail.email) [03:21] AttributeError: 'NoneType' object has no attribute 'email' [03:22] BjornT, we need a band-aid and a needle to test it [03:27] hmm, i can't say that i understand why this is happening. person should be the currently logged in user, and the error indicates that it doesn't have a preferred email address. i'll take a closer look... [03:27] BjornT: there is a back story [03:27] which may or may not be relevant [03:27] i tried to merge two accounts, one with a non-working email address [03:27] so one account got stuck in limbo [03:28] stevea merged it for me by hand after gpg verification [03:28] the account might be a bit non-standard due to this [03:29] tseng, what's the account name? [03:29] 'brandon' [03:29] you have a preferred email address [03:30] it is listed on your page [03:30] what was the old address? [03:30] brandon@brandonhale.us was the broken one [03:30] do you remember the launchpad name for it? [03:30] brandon-ubuntu was the other account [03:30] okay, the commit-pass-to-subprocess thing does not work here :( [03:31] tseng, are you logged in now? [03:31] kiko: as brandon [03:31] are you sure it's as brandon? can you click on the link next to Log Out to confirm? [03:32] https://launchpad.net/people/brandon [03:32] kiko: I noticed that the Dapper bugs are all cleaned up now. Yay to dholbach. [03:32] tseng, okay, then I'll leave you in BjornT's hands because it is not an obvious case of bustage [03:32] kiko: ok. [03:32] bradb: was there a reason why they *all* had to be closed? I was using the dapper tasks to remember certain things I wanted to fix for dapper, and I've just lost that information. [03:32] bradb: because "target fix to release" creates a dapper task [03:32] kiko: have you executed the last sql query in the oops report, to see what it returns? [03:33] Kamion, it won't create them any longer after tuesday [03:33] Kamion, you should use milestones instead [03:33] releases are for backports [03:33] Kamion: yeah, that's a UI bug that I've landed a fix for. things you want to fix for dapper should use milestones (again, our fault on the UI) [03:33] milestones are for the future [03:33] where is the UI for that? [03:33] Kamion: +editstatus [03:33] kiko: also, please check 'select name from person where id=301599 [03:33] ah [03:33] Merge to devel/launchpad/: [trivial] Add an assert in PersonSet.getByEmail() to help debugging https://launchpad.net/products/launchpad/+bug/31755 (r3194: Guilherme Salgado) [03:34] that has both "dapper" and "ubuntu-6.04" [03:34] rock on dilys [03:34] make your minds up :P [03:34] Kamion: Those are your guys' milestones, not ours [03:34] Kamion, blame mdz! :) [03:34] I frequently do [03:34] mdz is Canada [03:34] BjornT, brandon-ubuntu-merged [03:34] The "dapper" one was there before the important, the "ubuntu-*" ones came from Bugzilla, IIRC [03:34] s/important/import/ [03:35] bradb: please add a way to search by milestone [03:35] tseng: can you try to logout, and then login again, to see if it helps? [03:36] BjornT: mm, ok [03:37] BjornT: whatdyaknow [03:37] BjornT: works. [03:37] Kamion: er, yeah, that's a bug. I've got a big landing in code review right now which changes all the bug listings and advanced search screen, so I can easily sneak in the milestone search. [03:37] BjornT: thanks a lot [03:37] bradb: yes please, I need to not lose track of bugs where my manager has said "please don't forget about this for dapper" [03:37] jamesh: Any review news, btw? :) [03:37] tseng: ok, that's good to hear. it was probably due to the manual merge === BjornT heads out for a while === carlos [n=carlos@84.76.255.40] has joined #launchpad [03:42] cprov: hi [03:42] carlos: hi [03:42] cprov: I'm back with DSL, just in time ;-) [03:42] carlos: good, have talked with pitti about our situation [03:42] cprov: Thinking it twice, you don't need any patch from me. The changes I did are not executed by soyuz but from manually uploaded files [03:43] carlos: uhm ... [03:43] cprov: rollout your changes and I will try to get mine reviewed, landed and cherrypicked as soon as possible (that's today) [03:43] kiko: hi, around? [03:44] bradb: should I file a bug as a memory aid? [03:44] carlos: I've already rolled out my relevant parts,i.e., your code is there ;) [03:44] hmm, in fact, my changes are not really needed for soyuz, but for manual uploads so it's not even so urgent [03:44] cprov: well, I mean, any other change that was not already on your branch [03:45] carlos: AFAICS, you won't be able to cherrypick anything til monday, no stub [03:45] cprov: when will martin upload the new pkgstriptranslations? [03:45] carlos: the other changes I have are planned for tuesday [03:45] Kamion: sure, that would help. can you please assign it to me, and mark it High priority and In Progress? [03:45] carlos: so, I've fixed a deadline to tuesday [03:45] cprov: that's ok, as I said, it's not affected directly by your uploads from soyuz, that should work anyway [03:45] carlos: or as soon as you can release your fix [03:45] cprov: so no translations for dapper until tuesday?? [03:46] cprov: ok, let me tell it again. You don't need any patch from me or on production for dapper imports. At least not that I'm aware of [03:46] carlos, always around. [03:46] cprov: if your part is already done, let's do it now [03:46] carlos: pitti doesn't like the idea of extra clicks exposed by the lack of your fix [03:47] cprov: I did a mistake when I talked with you [03:47] carlos: what was it ? [03:47] cprov: those clicks should not affect soyuz imports [03:47] because the translations are not uploaded against a potemplate but a source package [03:47] so we need the initial review anyway [03:48] carlos: so why those tests in mawson was wrong ? [03:48] were [03:48] cprov: so the changes I'm doing atm are useful only for manual imports not for the automatic path [03:48] maybe it's just connecting to the wrong db... [03:48] carlos: I lost the track then, why did you said the mawson's results were wrong ? [03:49] cprov: Because the IPOFile.path was wrong on the previous import [03:49] cprov: it was for another problem that should not appear now === tseng [n=tseng@unaffiliated/tseng] has left #launchpad ["thanks"] [03:49] cprov: I tested it manually here and it worked [03:49] carlos: then it won't work now too, we have no fix [03:49] but you just remind me to check it with raw DB access [03:49] carlos: why did it failed in mawson ? [03:50] cprov: that's a problem only with old imports into dapper [03:50] cprov: we imported them on december [03:50] with wrong settings [03:50] bradb: done, bug 32728; thanks [03:50] malone bug 32728 in malone "need search by milestone facility" [Normal,In progress] http://launchpad.net/bugs/32728 [03:50] carlos: the same thing will happen again in production. [03:50] Kamion: cheers [03:50] spiv, ping? [03:50] we will need to fix them by hand and next time it will work [03:51] Kamion, bradb: uhm, you can search by milestone today. [03:51] cprov: but the amount of broken packages is low as we stopped the old import procedure long time ago already [03:51] bradb, make sure your branch does not regress that, btw [03:51]