=== Dsbeerf [n=Dsbeerf@modemcable137.101-200-24.mc.videotron.ca] has joined #launchpad === Dsbeerf [n=Dsbeerf@modemcable137.101-200-24.mc.videotron.ca] has left #launchpad [] [01:14] Good night all [01:15] night === sabdfl [n=mark@pdpc/supporter/silver/sabdfl] has joined #launchpad === stub [i=stub@sweep.bur.st] has joined #launchpad [02:24] i always read that as "stub sweeps into the room" [02:25] hmm [02:26] Is the job in PQM at the moment the same one SteveA was bitching about being stuck, or has PQM already had its enema? === zzone [n=daniel@CPE000bdb97337f-CM000f2120db83.cpe.net.cable.rogers.com] has joined #launchpad [02:42] its busy enough [02:42] strace shows lots of action [02:46] I killed it, as there seemed to be a duplicate request in the queue directly after. [02:46] The librarian needed a kill -9 [02:51] lifeless: Did you create those 'stablish-for-production' bzr and config-manager branches? [03:07] sabdfl: Do you know if kiko landed everything he needed to for a Gina run? [03:08] stub: i don't, no. seems like pqm is stuck on a trivial from him, though, with nothing else in the queue [03:08] that job is fine - pqm was stuck on a previous job that has been killed [03:09] from him? [03:09] Yes - it was in the queue twice. The first one was hung [03:11] I've got no emails so I guess not yet. I don't think it is Sunday in Brazil yet anyway. [03:15] he sounded pretty confident this morning [03:15] sabdfl: That double config/config in your doc. Is that a bzr bug, or just because you didn't change into the directory you just checked out (lp-config, in which case it should be lp-config/config [03:16] ah, sorry, i half-fixed it. should be build lp-config/configs... [03:16] and lifeless has promised to move the inner config out the way once we are FreeOfBaz [03:16] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Improve error message when a GPG key retrival from our keyserver fails (patch-2707: christian.reis@canonical.com) [03:17] could you fix it please? [03:17] Cool.... so config manager doesn't insist on the config file being in the current tree like baz did. That will improve the layout on the fs. [03:17] yup [03:17] hell yes [03:17] that was a major pita [03:17] this will make it much easier to have multiple trees [03:21] I assume I'm allowed to move bzr branches around my fs without screwing up other branches that branched from them? (except that my default upstreams might need resetting?) [03:29] stub: i don't know if it knows about a default upstream [03:30] stub: looks like there was no landing from kiko today [03:30] saturday [03:30] bzr pull pulls from where you branched from I think [03:32] it records the last pull location in .bzr/parent, from the look of things [03:57] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] various bugs fixed (patch-2708: steve.alexander@canonical.com) === TinMan [n=Lotus@cpe-66-65-244-241.nycap.res.rr.com] has joined #launchpad === robitaille [n=robitail@d154-5-117-228.bchsia.telus.net] has joined #launchpad === LaserJock [n=LaserJoc@ppp-69-229-207-6.dsl.renocs.pacbell.net] has joined #launchpad === poningru [n=poningru@n128-227-13-135.xlate.ufl.edu] has joined #launchpad === Burgundavia [n=corey@S0106000000cc07fc.gv.shawcable.net] has joined #launchpad === aaron1 [n=c@d-199-242-64.bootp.Virginia.EDU] has joined #launchpad [07:49] hello [07:49] what is launchpad? [07:50] hello? === aaron1 [n=c@d-199-242-64.bootp.Virginia.EDU] has left #launchpad [] === robitaille [n=robitail@d154-5-117-228.bchsia.telus.net] has joined #launchpad === Keybuk [n=scott@syndicate.netsplit.com] has joined #launchpad === SteveA_ [n=steve@195.182.78.95] has joined #launchpad === stub [i=stub@sweep.bur.st] has joined #launchpad === zyga [n=zyga@2-mi2-1.acn.waw.pl] has joined #launchpad === sivang --> attached [10:43] Good morning all === mfuentes [n=mario@200.54.6.25] has joined #launchpad === lbm [n=lbm@x1-6-00-13-10-7a-d1-e4.k233.webspeed.dk] has joined #launchpad === WaterSevenUb [n=WaterSev@195-23-220-181.net.novis.pt] has joined #launchpad === gualteri [n=salva@81-202-225-188.user.ono.com] has left #launchpad [] === stub [i=stub@sweep.bur.st] has joined #launchpad === zyga runs away === Belutz [n=Belutz@202.155.150.72] has joined #launchpad [01:22] hello all [01:23] in rosetta, i got this "translator-credits" [01:23] Developer note: Put one translator per line, in the form of NAME , YEAR1, YEAR2 [01:23] should i translate the "translator-credits" or fill the translation based on developer note? [01:34] Belutz, the translation based on developer note [01:34] always read the developer notes [01:35] mdke, so i put in my name? [01:35] yes [01:35] and email, year etc as it says [01:37] is it ok if i just entered 1 year? [01:37] just 2005, it's ok isn't it? [01:38] yes [01:39] ok, thanks mdke :) [01:39] np [01:39] i'm translating the faqguide :D [01:40] Strange [01:40] ah, it's the faqguide, nm [01:41] hey jordi , 'sup? [01:41] woa [01:41] Debian got OOo 2.0 [01:41] wheee, it's about time :) [01:41] sivang: I'm stealing bandwith to my dad. :) [01:42] morning jordi [01:42] well, it's been out like 2 days [01:42] hey ajmitch [01:42] hi sivang [01:42] jordi: what sort of network connection do you have there? [01:43] ADSL 1024/256 or something [01:44] sleep time, see you all later :) [01:44] later [01:45] night ajmitch === bayr00t [n=veruda@oliver.efpu.hr] has joined #launchpad [02:02] hi everyone [02:02] can someone help me with uploading translation templates into rosetta? [02:02] i'd like to translate Drupal (CMS) into croatian [02:04] bayr00t: jordi is your man :) [02:05] he around? [02:05] bayr00t: HOLA! [02:05] i created this rosetta BRANCH thing here: https://launchpad.net/products/drupal/4.5.0 [02:06] bayr00t: before uploading drupal to rosetta, you may want to contact the developers to ask them if they are ok with this. [02:07] oh, ok. how can i see who they are? [02:11] bayr00t: they might be around #drupal now [02:11] bayr00t: send them to me if they have questions [02:12] ok, thanks. will try to contact them. cu [02:27] jordi: is the developer i have to contact the same as debian's .deb package mantainer? === jinty [n=jinty@205.134.224.215] has joined #launchpad === stub [i=stub@sweep.bur.st] has joined #launchpad [03:14] can i do the translation offline? [03:15] if i could, how? === HiddenWolf [n=HiddenWo@136.228.dynamic.phpg.net] has joined #launchpad === kiko [n=kiko@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [03:40] yarrr [03:40] yarrrrrrrr [03:40] yo ho ho [03:40] where's the stubber [03:41] We had pirates day a few weeks back already? ;) [03:41] everyday's pirate day on #launchpad [03:42] What do I need in order to get permission to close bugs on malone? [03:42] kiko: stub's around [03:42] and sabdfl's around too! [03:42] kiko: question. can i go ahead and create a Dapper entry on staging before we do the gina run? [03:43] i'd like to see that it doesn't stick anything in there [03:43] HiddenWolf, it depends. on what would you like to close the bugs [03:43] sabdfl, of course [03:43] yo [03:43] how are you stub [03:43] hey stubarooney [03:43] good enough [03:43] looks like the bake-gina-brat-pack is in place [03:43] kiko, I'd just like to be able to set NOTABUG to some random drivel. [03:43] Hey there all :) [03:43] stub: so, is the staging db ready? librarian ready? [03:43] kiko, I'd rather not have to bug -devel and -motu with it all the time. [03:44] can we prevent it from nuking itself tonight, so we can continue to examine the fallout tomorrow? [03:44] yup [03:44] HiddenWolf: i'm thinking of adding a QA person to distro, and letting those people have edit on any bug tasks associated with the distro [03:44] make sense? [03:44] sabdfl, yeah. [03:44] sabdfl: sounds like a nueclear melt down :) [03:44] sivang: ? [03:45] sabdfl: nuking, fallout [03:45] right [03:45] maaayyybe [03:45] sabdfl, you got a minute? may i pm you? [03:45] it's all on the kikoman's shoulders [03:45] will she, or won't she? [03:45] hehe [03:45] Belutz: briefly, yes [03:45] * Scanning for full-tree revision: .. [03:45] * from revision library: rocketfuel@canonical.com/hct--devel--1--patch-22 [03:45] * tree version set rocketfuel@canonical.com/hct--devel--1 [03:45] unable to rename "/srv/launchpad.ubuntu.com/staging/launchpad/lib/,,get.hct.1130068981.752.2745" to "/srv/launchpad.ubuntu.com/staging/launchpad/lib/hct" (Not a directory) [03:45] PANIC: I/O error [03:45] sabdfl, I'm not a coder, but when I come across wacky bugs, I'd like to be able to close them. this bug suggesting ubuntu-doc is messed up for not showing the upgrade path to dapper already, for instance. :) [03:46] HiddenWolf: so that fits the qa team model nicely [03:46] sabdfl, piont is, who do you trust? ;) [03:47] stub: lib/hct is now a symlink to sourcecore/hct it seems [03:47] HiddenWolf: reason i haven't done this is because we haven't really discussed permissions much in LP [03:47] stub: lifeless should probably have mailed the list before doing that [03:47] and obviously, we need to get that right over the coming weeks [03:47] even I didn't expect that one [03:48] options are: a team on the distro, or a team on the actual release (hoary), or both... [03:48] Keybuk: Indeed. Because staging isn't updating and I now only have half a staging server :-( [03:48] <\sh> sabdfl: hmm...looks like that distro team == ubuntu-core-dev? [03:48] and questions are: do we want separate teams for bugs / support / specs? [03:48] \sh: well, if there is a separate field, then its easy to set it to the same value [03:48] stub: he moved hct, sourcerer, psycothingican'tspell and sqlos from lib to sourcecode and replaced them with symlinks [03:49] <\sh> sabdfl: because I could close/reject the bug... [03:49] if there is no separate field, you're assuming that only devs should be able to close bugs [03:49] and that's not true [03:49] sabdfl: well, eventually you're gonna get a defined support team, as one use case. [03:49] right. and the support team could include ubuntu-dev and ubuntu-core-dev [03:49] Keybuk: ok. So I should be able to hack the local config file and keep this thing limping along until we actually have bzr and config-manager available on the staging box [03:49] as well as anybody else we give those permissions to [03:49] stub: none of those are in bzr yet [03:49] we're still turfing out the bugs [03:50] it's just the baz branches that got moved [03:50] stub: staging's bad gatewaying for me? [03:50] Keybuk: But the dists tree is in bzr now, but I can't use it on asuka yet. So I think I need to backport the changes [03:50] (20:48:08) stub: Keybuk: Indeed. Because staging isn't updating and I now only have half a staging server :-( [03:51] half a staging server? [03:51] ahh [03:51] ffs [03:52] <\sh> hmmm...montreal can come....hilfiger ready to be used again [03:52] mdz: around? [03:53] sabdfl: still far too easy mdz-time [03:53] is 6am on Sunday there or something [03:53] uh, early! [03:53] not easy [03:53] obviously [03:55] ok. this looks healthier [03:56] he called me the other day at 6am [03:58] is something like #3494 going to fixed / scheduled for fix ? (Maybe that's too harsh of a bug report, will close it on feedback) [03:58] Bug 3494 [03:58] Malone bug #3494: successful login page is counter intuitive and crippeling. Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/3494 [03:59] sivang: I think it is underway actually. [03:59] sivang, yeah, salgado's working on it [03:59] SteveA just needs to ok the implementation [03:59] stub: should staging be working right now? [04:00] cool, then sorry for the dup I just had to do that since that's been bugging me like for ever :) [04:00] sivang, you need to stop clicking on log in :) [04:00] sabdfl: It is doing a fresh rebuild right now. Probably be another 15 mins for the full text indexes to reset [04:00] ok, cool, thanks [04:00] man today is the last day of the roy lichtenstein expo [04:01] kiko: :) [04:01] gina had better not cancel that one for me [04:01] sabdfl: Did you need to do anything before I nuke the sourcepackagereleases and binarypackagereleases for Gina? [04:01] if build: [04:01] # XXX: check if there are other packages in this build with this [04:01] # same package name [04:01] stub: nope [04:02] kiko: Just put a 'sleep(60*60*4)' at the top so you will have a 4 hour window before we know it has crashed [04:02] :) [04:02] stub: lol [04:03] KIKO [04:04] bayr00t: no, not the Debian maint, but the upstream authors [04:04] JORDI [04:04] stub, kiko: ALTER TABLE BinaryPackageRelease ADD CONSTRAINT binarypackagerelease_build_name_uniq UNIQUE (build, binarypackagename); [04:04] should do the trick [04:04] sabdfl, that sounds better than any check I can do [04:04] there is currently a unique (build, name, version) [04:05] i think that could be tightened to (build, binarypackagename) [04:05] stubarooney? [04:05] sabdfl, what is the difference between them? [04:05] in fact, i know it could [04:05] tests pass [04:05] ROCK [04:05] kiko: I have a mission for you [04:05] stub: recalling that you said there were plans to implement the sort of google suggests thingy to the entiy search window, there a spec about it somewhere? [04:05] jordi, shoot and I will fall === bayr00t [n=veruda@oliver.efpu.hr] has joined #launchpad [04:06] the existing one suggests someone thought that you could get two packages with the same name and different versions [04:06] but, i don't believe that should happen [04:06] sabdfl: sounds fair to me. Kiko can add it on his branch if he hasn't finished landing [04:06] so i'd like to tighten the constraint [04:07] sabdfl: we can always relax a unique in the future. No data to migrate. [04:07] sabdfl, in the same build, two packages with the same name but differing versions? that's crack indeed [04:07] stub, can you add it? I really don't want to do that now :-( [04:07] Erdal Ronahi has multiple accounts [04:08] ah... hmm... i wonder if the existing one is there so it can be part of a remote "points back at this table" index / constraint [04:08] jordi, okay [04:08] kiko: ok. But it will tie up PQM if you are trying to land after. [04:08] Thanks. By the way, can you permanently delete the users reimar-heider and [04:08] reimar-heider-merged, which also run under the name "Erdal Ronahi" in several [04:08] teams? I cannot delete them, because their pages are in fact deleted (because [04:08] they were successfully merged). They only show up in some team lists, where [04:08] there seem to be two "Erdal Ronahi" because of that. Not beautiful... [04:08] stub, I'll give you a branch name for me if you want to use that directly [04:08] is that enough info? [04:08] kiko: I can assemble the file for you to baz add in your branch [04:08] jordi, that's a bug that was fixed, but there's data leftover -- stub just needs to drop the membership entries [04:08] stub, perfect. [04:08] kiko: i would like you to add this code in place of the XXX as well [04:09] what's the name of the BPR you just created before this code? [04:09] or, the variable that has the name? [04:09] sabdfl, binary.package, let's say [04:10] and is that a BinaryPackageRelease, or some local class? [04:10] binary is a local class but has anything you need [04:11] if build: [04:11] for bpr in build.binarypackages: [04:11] if bpr.binarypackagename.name == binary.package: [04:11] raise AssertionError('There should never be another BPR with the same name in a Build') [04:12] that should do it [04:12] okay. [04:12] kiko: does stub need info about these entries, or can they be detected automatically? [04:12] ie, should I forward this to him? [04:12] binary.package is a string? [04:14] eh? [04:15] sabdfl, yes === kiko adds and re-runs tests [04:18] runs fine [04:18] okay [04:18] stub, I'm going to submit this to PQM [04:19] https://chinstrap.ubuntu.com/~dsilvers/paste/fileVzEice.html [04:19] kiko: ^^^ [04:20] stub, where do I put this? [04:20] sec [04:20] kiko: database/schema/patch-25-44-0.sql [04:20] sabdfl, what? [04:20] i think that binarypackagename_key is used. is there a foreign key that points at it? [04:20] it looks like something that was added so that something else could point at it === stub waits for his db to rebuild [04:21] the constraint? [04:22] kiko: Nuke that line. We can drop it later if it is redundant. [04:23] okay. [04:23] So just the first ALTER TABLE [04:25] sure. === kiko rebuilds db === heyko [n=heyko@tor/session/x-ded98209a8e3ef3d] has joined #launchpad [04:25] sabdfl, you need to create all the distroarchreleases for hoary/breezy if we don't have them already. [04:26] ok. i don't know if there's UI for that [04:26] there is UI for distrorelease [04:26] not sure about distroarchrelease [04:26] may need some sql commands [04:29] wow. there really is no UI for it [04:30] SQL is a UI ;) [04:30] sabdfl, could you file a bug on that? [04:30] kiko: i will fix it myself, now, and land it [04:30] it will just take a little while thanks to baz [04:31] well [04:31] I'm sending off gina to pqm [04:32] I haven't managed to finish the multi-arch test [04:32] so I'll work on that meanwhile [04:36] stub: from a db design point of view, i'd like your preference [04:36] the idea is to model whether or not a spec is really on the agenda of a sprint [04:36] the options are: [04:37] A) to have a SpecSprint.confirmed, starts NULL, can become TRUE or FALSE [04:38] B) to have a SpecSprint.confirmation int enum starts UNCONFIRMED, can become DECLINED or APPROVED [04:38] preference? [04:38] lifeless: Can you chmod -R a+xR /home/warthogs/source/rollouts (paramiko in particular) [04:38] sure [04:38] gosh. several minutes into baz status and no sign of progress. Give me Bzr NOW! [04:38] lol [04:39] stub: a+x surely [04:39] a+rX [04:39] invalid mode string dude [04:39] sabdfl: those db preferences, having an int would cater for more values should they be required in the future [04:39] ah [04:39] sabdfl: like, postponed, deffered etc [04:39] sabdfl, stub: christian.reis@canonical.com--lozenge/launchpad--devel--0--patch-231 until pqm has it. [04:39] sabdfl: Today I lean towards B [04:40] done [04:51] stub: ok [05:00] hey guys [05:00] how is it going? === mpool_ [n=mbp@ozlabs.org] has joined #launchpad [05:02] hey fabbione [05:03] hey sivang [05:05] Does 'all architectures' mean i386, ppc and amd64 for the time being? [05:05] no [05:05] well [05:05] theres all and any [05:05] which do you mean ? [05:06] Gina [05:06] stub, test only i386 first, please [05:06] kiko: ok [05:06] I am still working on a test to ensure all archs/pockets work as expected [05:07] actually [05:08] it seems to have magically run now [05:08] kiko: You want me to run with --verbose, --quiet or normal? [05:09] stub, that's a tricky one, but I guess --verbose because it's possible to filter stuff out later. [05:09] Yup. makes sense [05:09] kiko: warty, hoary & breezy? [05:09] stub, if you have the guts for it, so do I :) [05:10] kiko: The more I run, the longer you have at your exhibition before someone pages you ;) [05:11] stub, the problem is the 5-minute exception it will raise after starting :-( [05:12] you know software... [05:12] heh [05:12] ARGH [05:12] stub: so are you in melbourne still ? [05:12] WHO CONFLICTED WITH ME [05:13] lifeless: Nope. Bangkok. [05:13] ffs [05:13] ffs [05:13] Oh yeah... I noticed a conflict when I merged in your branch. [05:13] Keybuk: pushed === stub ducks [05:14] Keybuk: merge now :) [05:15] stub, how solvable is it? [05:15] lifeless: exxxxcellent [05:15] kiko: It is a trivial conflict. Looks like you conflicted with yourself [05:15] shall I try a pqm-submit-merge too? [05:16] stub, okay. are you using my branch, then? [05:16] kiko: About that exception.... [05:16] yeah [05:16] privmsg me [05:16] kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/fileYnbdwD.html [05:16] Keybuk: yes === pkunk [n=pkunk@a84-231-2-45.elisa-laajakaista.fi] has joined #launchpad [05:17] stub, you need to nuke the librarian files that were uploaded [05:17] LibraryFileContent.sha1 isn't unique. You need to just pull the first one that matches. [05:17] lifeless: tomorrow we'll do the same for sourcerer, and then work out replacing the branches with the right ones? [05:18] dear evolution, you suck donkey balls. Thats MY donkey. Please stop. [05:18] stub, I can cope with the exception, but you need to cope with the entries in the librarian :) [05:18] kiko: The entries in the librarian are fine. [05:18] kiko: LibrarianGarbageCollection will remove them eventually [05:18] stub, no, gina won't run. [05:18] (if you don't clean them out) [05:18] sabdfl asked me to do this check [05:18] kiko: You cannot clean them out. [05:18] so I added it [05:18] then I don't know what to do. [05:19] Keybuk: yes [05:19] kiko: It won't work with that. sha1 isn't unique, and never will be due to race conditions. [05:19] you can comment out check_not_in_librarian calls, stub.. [05:19] stub, so there's no way of knowing if the librarian already has a file? [05:19] Keybuk: what I'd like you to do, is to do a 'merge' from rf, and then a push, before any merge in a converted branch. [05:20] kiko: Yes. You search for the sha1. You just have to be aware that it might have several copies. [05:20] lifeless: any particular reason? [05:20] kiko: So don't use selectOne. Use select and grab the first one in the resultset. [05:20] stub, but I can't be sure that I have the right file, can I? [05:21] Keybuk: yes. [05:21] Keybuk: it should trigger a reweave [05:21] kiko: The sha1 is identical. If that isn't good enough you have to download it and do a byte-by-byte comparison. [05:21] right [05:21] stub, okay. can we run with those calls commented out for now? it's going to take me time to fix this the right way [05:21] a reweave is only triggered when two branches have a parent they disagree on === GoRoDeK [n=gorodek@p5083FD75.dip.t-dialin.net] has joined #launchpad [05:22] that happens to the *second* branch to have the combined history [05:22] kiko: Although I think we decided that if the sha1 is the same they are the same file. So just replace selectOne with select()[0] and a suitable exception handler. [05:22] okay. [05:22] kiko: what calls and where are they [05:22] the first branch just gets a new copy of the revisions it did not have [05:23] wooo [05:24] Keybuk: its up to the make check_merge [05:24] Keybuk: I'm confident it will continue [05:24] if it wedges, stub is your man [05:24] stub, how does this look? [05:24] return LibraryFileContent.selectBy(sha1=digest).count() > 0 [05:24] stub, instead of selectOneBy. [05:24] stub: you know how to remove a stale patch command if pqm starts looping ? [05:24] kiko: Looks good [05:24] stub: they are files in ~/arch/queue/patch.* [05:24] cool. [05:24] lifeless: No idea [05:25] stub: so just remove the lowest numbered file [05:25] (if pqm is looping that is) [05:25] lifeless: How do I know if pqm is looping? [05:25] Keybuk: if this goes through, please make thumbs up motions at sabdfl [05:25] stub: well, it will email me lots. [05:25] lifeless: is that the "it works for keybuk, it MUST be ready for the world" pass? :p [05:26] be sure to bounce mpool to merge the fixes into bzr.dev [05:26] but primarily, it will be going round in circles so the process will always be doing shit but nothing advancing in the queue [05:26] lifeless: How do *I* know ;) [05:26] Keybuk: 'bounce' heh. Trampoline I think [05:26] stub: someone says 'its been 4 hours for that merge', and you look and its attempting that merge still, but not 'stuck' in the classical sense. [05:27] lifeless: ok. so if it is clogged but pqm is still doing shit, nuke the lowest number file in ~/arch/queue/patch.* and... ? [05:27] and thats it [05:27] it will then move on [05:27] kill the current job? [05:27] ok. [05:27] stub, but note that this will still error out (because gina doesn't want to see these files in the librarian) [05:27] this happens for completely untrapped exceptions [05:28] stub, so either nuke the entries or comment out any calls to check_not_in_librarian. [05:28] which is important, as they then tell me what to get out and fix :) [05:28] kiko: We can't nuke them, either on staging or on production so please comment them out on your branch. [05:28] gnight all [05:29]