=== mfuentes [n=mario@200.54.6.118] has joined #launchpad [12:05] wow [12:05] Hi, [12:05] so yes, nothing merged [12:05] Is the registration system of the launchpad ok? [12:06] The URL sended to the mail for activate my account es 404 :\ [12:06] kiko: btw the changes were not bzr related, they were a reorganisation requested by steve [12:07] lifeless, thank god [12:07] mfuentes, what URL was that? [12:07] launchpad.net/token/... [12:07] mfuentes, did you take too long? [12:07] mfuentes, can you try again? [12:08] page not found :( [12:09] mfuentes: ask for another email kiko means [12:09] mfuentes: they time out. [12:10] lifeless, hi [12:10] mfuentes, they time out, and we haven't yet fixed the bug that would lead the token to have a less horrible page [12:10] lifeless, I'm following the instructions at https://wiki.launchpad.canonical.com/RocketFuelSetup [12:11] carlos: ok [12:11] lifeless, but I get an error with bzr, seems like it does not understand the sftp:// when branching [12:11] carlos: do you have paramiko installed ? [12:11] lifeless, yes [12:11] can you do this for me [12:12] python -c 'import bzrlib.transport.sftp' [12:12] lifeless, https://chinstrap.ubuntu.com/~dsilvers/paste/filelgXnkv.html [12:12] ImportError: No module named sftp [12:13] python -c 'import bzrlib;print bzrlib.__version__' [12:14] 0.6pre [12:14] this is decidely strange [12:14] are you running from source or debs ? [12:14] debs [12:14] dpkg -l bzr [12:15] ii bzr 0.1.1+20051018 [12:15] ah [12:15] update :0 [12:15] lifeless, I had to revert to that version because latest one is broken [12:15] carlos: there is a newer one than the broken one [12:16] yeah, it was not there latest time I did the dist-upgrade ... [12:16] anyway, I get the same error [12:19] is it? [12:19] 20051020 is the latest one, no? [12:19] lifeless, sorry, my fault, it's working now [12:20] carlos: cool [12:20] I'm going to do a faster import process [12:21] so don't do the big branch conversion yet.. but making sure you can checkout everything and so on is good [12:21] hmm, worked here to ;-) === SteveA [n=steve@office.pov.lt] has joined #launchpad [12:22] lifeless, ok [12:24] if you want to do branch conversion on non-launchpad branches, thats cool [12:31] time to sleeeeeeeeep, see you tomorrow guys, good night [12:32] kiko: clean checkout, imports ok :[ === carlos -> bed [12:37] see you tomorrow! [12:38] any chacne spec tracker is experiencing problem? I just got the "please report a bug" page trying to add just another one [12:38] Kinnison: ping [12:43] lifeless, no clue as to why? [12:43] kiko: its mystifying me [12:44] shucks [12:44] I've disabled pqm and when the current merge stops, I'll try inline [12:44] pyc leftovers? [12:44] clean tree every time [12:44] it gets rm -rf'ed [12:45] Removing Default Programs - better mechanism to remove programs included in the default installation. Not removing ubuntu-desktop, maybe somehow remembering this is a default installation minus program removed, so you won't have problems when upgrading to a new distro version. [12:45] oops [12:45] sorry [12:45] no! you're fired! [12:45] haha :) [12:48] kiko: I filed a bug. spec tracker seem to really no like JUST the spec data I inputted at #3431 [12:48] kiko: otherwise it feels fine with the other specs I;ve registered [12:50] how can I reassign a bug after already entering it? [12:52] kiko: you were joking right? (although you're silence is somewhat disturbing ;-) ) [12:52] heh [12:52] sivang, you can click on the link in the top box and then change the assignee === Nafallo is now known as Nafallo_away [12:53] kiko: where? ;-) [12:53] in the little box at the top of the bug page [12:53] kiko: bug details? [12:54] huh? no, fix requested in [12:54] kiko: ok, should I enter "launchpad" as the upstream product? [12:55] becasue pressing "Add" again ives the "error occured in launchpad page" [12:55] (launchpad/+bug/3431/+upstreamtask) [12:56] ah! man, I just clicked the whole region there, and finally got it [12:56] crack [12:56] yeah [12:56] it's horrible [12:56] horrible [12:56] nobody wants to fix it [12:56] I wasn't sure this: [12:56] I might do that next week [12:56] launchpad (upstream) New Normal [12:56] yeah [12:56] ^^^^^^^ [12:56] totally horrible [12:56] is the link :-D [12:56] please don't rub it in [12:56] kiko: nobody wants to fix it ? I'm sure brad would love too [12:56] hehe [12:56] kiko: that's should be a relatively small UI change no? [12:57] mpt and the sab are in a deadlock over it [12:57] (/me is still uneducated aboue it, sorry for how this may sound) [12:57] it is a trivial change [12:57] but nobody agrees on how to do it [12:57] kiko: I see [12:57] kiko: spec it for UBZ ? :-D [12:58] I think we should let the same wave his wand [12:58] anything would be better [12:59] anything [12:59] even no link [12:59] I suggst to add another "obvious" action link [12:59] like "Request fix" thingies [01:01] I'm also wondering what the rationale about seperating editing the description, and the other details. [01:02] also, would be nice to ahve a way to search bugs by reporter [01:02] sivang, can you reproduce the system error you got in +upstreamtask? [01:03] kiko: let's try [01:03] I can't [01:04] kiko: I think that will happen again on a new bug, which has never been "+editbugs'd" [01:04] kiko: I'll test that again with a dummy one [01:05] bah! [01:05] EWORKFORME [01:06] ah ok [01:06] it happened while I Was trying to request and +upstreamtask, [01:09] yeah [01:09] can't reproduce, sivang? [01:10] oh [01:10] you typed in launchpad [01:10] gotcha [01:11] yes :) [01:11] I was just trying to tell you, but my breezy crashed! [01:11] (had to do full blown reboot) [01:12] should I not have typed in launchpad? [01:14] kiko: when there will be a way to remove specs? [01:17] hmm, proxy error on a spec again [01:25] someday [01:25] :) [01:25] lifeless, no love? [01:26] kiko: so, was me inputting "launchpad" a bad move ? [01:26] kiko: its checking out still [01:27] doing a make check [01:27] darn [01:28] if this passes [01:28] I'll do a merge of your pending request [01:28] and make check again [01:28] thanks [01:28] if that fails, then I think I know what the problem is [01:28] there were two actually [01:28] are you merged up with lp ? [01:29] yes [01:29] good [01:29] I can resubmit of course [01:29] should I? [01:29] not yet [01:29] I need to leave soonish [01:29] no lunch today [01:29] 9:30pm [01:29] gina still being loved [01:29] in your tree, do 'ls -ld lib/hct' [01:29] dude. [01:30] christian.reis@canonical.com--lozenge/launchpad--trivialities--1--patch-69 <- I'm trying to get this one in [01:30] cool [01:31] so - 'ls -ld lib/hct' pleas [01:31] man, another system error on a spec. probably unrelated to the data itself === stub [i=stub@sweep.bur.st] has joined #launchpad [01:32] stub: what branch did your import error on ? [01:33] cookiecrumber something. I think that branch has given us grief before and is stuffed even for baz IIRC. I suspect we need to skip it. [01:33] Or delete it. [01:34] importing stuart.bishop@canonical.com/cookiecrumbler--canonical--1.2 into /home/warthogs/archives/stuart.bishop@canonical.com/cookiecrumbler/1.2/canonical [01:34] Cleaning up [01:34] bzr: ERROR: conflict when applying pybaz.Revision('stuart.bishop@canonical.com/cookiecrumbler--release--1.2--patch-1') to /home/warthogs/archives/stuart.bishop@canonical.com/cookiecrumbler/1.2/baz2bzr-yLd8cN/rd [01:34] command: '/home/warthogs/source/bzr.integration/bzr' 'baz-import' 'stuart.bishop@canonical.com' 'stuart.bishop@canonical.com' [01:34] pwd: /home/warthogs/archives [01:34] at /home/pqm/source/pybaz/pybaz/_builtin.py line 2078, in apply() [01:34] see ~/.bzr.log for debug information [01:36] stub: ok. uhm, do we use cookiecrumbler ? [01:36] stub: also, do you need help getting staging to build configs with cm ? [01:36] and dogfood [01:37] Yes, but I think we use the modified copy in my Plone tree rather than my modified copy in the CookieCrumbler tree [01:37] lifeless: Dogfood is Kinnison now, although he might want to take my staging work. I'll give staging a go myself once I'm running with bzr and ping you if I get stuck. [01:38] I guess we will need bleeding edge bzr installed on asuka, gangotri, emperor, maquarie & macaroni if it isn't already [01:38] yes [01:39] well, 0.1.1 at least [01:39] lifeless, Kinnison wrote about dogfood, did you see that? [01:39] kiko: yes, and its two fold [01:39] kiko: I have fixed the dogfood config for him [01:39] but his rollout stuff does need to change. [01:44] night guys [01:45] lifeless: So should I give the archive conversion another spin after moving the offending branch out of the way, or is there a way I can tell it to skip that one? [01:46] I don't think it will cause any issues if we lost it. [01:52] stub: I'm going to do archive conversions for people [01:52] to bootstrap faster [01:52] so, just do branch conversions of your dists branches [01:53] I'll look at that branch for you later [01:53] its a project of its own right ? [01:53] If you are doing the archive conversion then there is no need for me to convert my dist branches. [01:53] or is it an lp branch ? [01:54] well, you need your dist branch to send in changes to dists, no ? [01:54] CookieCrumber is a 3rd party project for cookie authentication, used as part of plone, that I hacked to stop passwords flying about in clear text. [01:54] ok. [01:55] well that, if you dont need the history, yes, just delete [01:55] lifeless: I can make a new dists branch happily [01:55] stub: I'd kind of like to be sure the process works [01:55] making new branches is trivial [01:55] in fact, after you delete dists, just start the archive converter [01:55] it will do dists for you [01:55] (c..d) [01:56] ok. So I should remove the CookieCrumbler evil and run the conversion again as per the wiki? [01:56] you just confused me :-/ [01:57] yes [01:57] but when it gets onto launchpad, hit ctrl C [01:59] kiko: tests pass in rf [01:59] kiko: now with your merge [02:01] celso is on france TZ right ? [02:03] kiko: I have the bug isolated [02:03] kiko: fixing [02:07] thank god [02:07] broken Makefile in hct [02:07] lifeless, are you merging me /up-to/ patch 69, or just 69? [02:08] kiko: as you are here, just resubmit whatever you would like merged [02:08] ok, 2701 will fix this [02:09] BTW, if you have a situation where pqm fails and local tests do not, run 'make check_merge' it will do exactly what pqm does. [02:09] pqm reenable [02:09] Merge to rocketfuel@canonical.com/launchpad--devel--0: Disable autodetection of sourcecode/projects-to-test due to Makefilefiles not working in all cases. (patch-2701) [02:09] ok. that should be good now. [02:11] ok. conversion ran, including dists, and I ctrl-C'd it on the first launchpad branch [02:11] ok [02:11] thanks lifeless [02:12] now you should sign your revisions [02:12] kiko: np. [02:12] kiko: If things are completely bolluxed, you can ring me at stupid hours [02:12] I wont be happy, but I will try to help. [02:13] So it is correct that the conversion scripts stuffed the bzr branches into my baz archive? [02:13] stub: no, what dir did you run the conversion from ? [02:14] /home/warthogs/archives/ [02:14] stub: there is a 'cd $usercode' that you skipped [02:14] /home/warthogs/source/bzr.integration/bzr baz-import stuart.bishop@canonical.com stuart.bishop@canonical.com [02:14] ok [02:15] Which already exists if you did the stuff up the top [02:15] yes [02:15] :[ [02:18] To stop other losers doing what I just did, the mkdir can be a mkdir -p, followed by a cd to the $userid directory, then gpg --import ../allcommitters.gpg [02:18] stub: good idea, can you edit it ? [02:18] Sure === koke [n=koke@adsl229-164.unizar.es] has joined #launchpad [02:38] revisions 2555/2727 0:57:57 [02:39] are we there yet! [02:40] lifeless, why do these latest commits not include any patchlogs? [02:46] Resigned my dists branch, but I suspect that modifying that rsync line will trash my chinstrap bzr archive [02:47] stub: hmm [02:47] kiko: which commits ? [02:47] good night people [02:47] stub: we should detangle your archives [02:48] eh? I think I have if you mean the dud bzr branches created in my baz archive [02:48] ok, so what did you mean then [02:49] I've rsynced stuff, using the example command line, locally and resigned one of my branches. If I use the same command line with the source and dest reversed it will delete all the .py files on chinstrap I think === stub isn't an rsync command line expert [02:49] lifeless, patch-2701 and 2702? [02:50] err 2700 and 2701 [02:50] kiko: I commited them directly [02:51] kiko: its the only way to get tree-nesting changes done. [02:57] spiv? [02:57] I see [02:59] stub: thats ok. [03:00] stub: those .py files are not needed [03:00] stub: each bzr branch is *both* an 'archive of history' (the .bzr dir), and a working tree (the launchpad source) [03:00] the only value in the working tree is in changes that have not been committed [03:01] spiv, stub: [03:02] http://localhost:58000/search?digest=2d227a7e3e67d59c92cd265003ac882b76ae45eb [03:02] does this look like a reasonable librarian URL? [03:02] why the ? [03:02] (the ? will stop a lot of proxies caching it) [03:02] That is a search by sha1, which should only work on the LAN [03:02] dunno, it's how you talk to the librarian. [03:02] kiko: Yeah, it is. [03:03] stub, not even on localhost? [03:03] you are your own lan [03:03] hmmm [03:03] spiv: do we have ? in our urls for the librarian to the public ? [03:03] and everyman is an island [03:03] why does this return notfound for me :-( [03:03] nope [03:03] It doesn't have any localhost-only access restrictions, but it's never linked. [03:04] spiv, I'm uploading and then doing a pull for that URL [03:04] kiko: the "search" resource ought to be configured by daemons/librarian.tac [03:04] should work, shouldn't it? [03:04] kiko: has it finished the commit ? [03:04] hummm [03:04] kiko: Are you getting a 404, or something else? [03:04] checking. [03:05] Also, I'm curious about why you need to use that resource -- if you have direct access to the database, just use the database. [03:05] I got.. a zero. [03:05] spiv, hmmm. okay, good point. [03:05] Ah. So, no results. Sorry, "notfound" was rather unclear :) [03:06] I'm not sure that anything is actually using that feature in production... [03:07] it worked! [03:07] checking the database directly was a good idea. [03:08] no clue how I actually saw it without committing. [03:08] you get the id back before the transaction finishes IIRC [03:09] indeed [03:09] lifeless: The default mode now is that the client does the database access, including committing. [03:09] spiv: ah [03:09] So it's perfectly possible that the client has an id that the librarian can't see in the db yet. [03:09] in my day ... :) [03:09] lifeless: :) [03:09] Yeah, nothing in production is actually using the search "feature". [03:15] You should never need to construct URLs to the librarian anyway. The only thing clients should deal with to get to the librarian is client.py, and bypassing that is unsupported. [03:15] Or LibraryFileAlias/LibraryFileContent which make use of client.py [03:17] client.py unfortunately is chock-full of deprecated methods [03:17] kiko: LibrarianGarbageCollection is cleaning them out [03:18] stub, you added bug 3438 which is a dupe of bug 3436 [03:18] Anyway - the good stuff should be exposed on LibraryFileAlias, LibraryFileAliasSet etc. [03:18] Error: I cannot access this bug [03:18] Malone bug #3436: no sensible error message when adding a spec which has already been added. Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Mark Shuttleworth, Status: New http://launchpad.net/malone/bugs/3436 [03:18] stub, how about searching malone before filing bugs? :-) [03:18] kiko: But you do a much better job of it than I ever would ;) [03:19] I have one big mailbox full of bugs! [03:23] hm [03:23] is it possible to get Ubugtu to join #bzr? [03:25] if you ask Seveas /nicely/ [03:29] so if i just mention bug 3049 ... [03:29] Malone bug #3049: revert doesn't remove conflicts Fix req. for: bzr (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/3049 [03:30] nice! [03:30] Seveas: ping? [03:37] Merge to rocketfuel@canonical.com/launchpad--production--1.37: Cherry picks (patch-4: christian.reis@canonical.com, stuart.bishop@canonical.com, carlos.perello@canonical.com ...) [03:44] thanks stub [03:51] Seveas: can you get Ubugtu to join #bzr ? [03:57] night guys [03:57] gina's almost there [03:57] almost [03:58] yay === TinMan [n=Lotus@cpe-66-65-244-241.nycap.res.rr.com] has joined #launchpad === Alinux [n=Ubuntu@d83-176-97-213.cust.tele2.it] has joined #launchpad [04:29] alive? [04:29] :D [04:29] hello all. === TinMan is now known as LotusPetal [04:34] Merge to rocketfuel@canonical.com/launchpad--devel--0: rs=stevea, stub, ddaa [hackish] fix for bug 3410: Bazaar index page is broken. Split ProductSeriesSet into a separate ProductSeriesSourceSet class, and use that for the bazaar views. Will have a followup bug to fix this properly. Also Fix for bug 2668: product visible despite being inactive and bug 2669: project still visible, despite being flagged as inactive. Remove inactive products and projects from [04:49] win 17 === patr1ck [n=Patr1ck@unaffiliated/patr1ck] has joined #launchpad [05:23] Hello! is the ability to create new accounts down or something? I ask only cause i've been waiting like 20 minutes for this registration URL to be emailed. [05:31] ah, nevermind, it seems hotmail just sucks. whodathunkit? :) bye! === patr1ck [n=Patr1ck@unaffiliated/patr1ck] has left #launchpad [] === sankar [n=sankar@202.144.95.244] has joined #launchpad [05:57] lifeless: just looked at the pending-reviews page: your bzr branch didn't turn up because it didn't have the branch name in backticks [05:58] lifeless: I fixed that, but it also looks like the path is wrong [05:58] ok [05:58] checking [05:58] I don't see a /home/warthogs/archives/robertc/dists/devel [05:58] ah yes [05:58] I moved [05:58] done [05:59] I also had the rocketfuel branch URLs wrong initially, but that should be fixed for the next run [05:59] can you kick one off now ? [06:00] sure. [06:11] well, it definitely picked up some bzr rocketfuel branches that time: https://chinstrap.ubuntu.com/~jamesh/pending-reviews.new/rocketfuel-branches [06:12] (it will probably be a while before it hits your branch) [06:13] jamesh: how's bzr going for your branches? [06:13] mpool: I haven't converted any of my launchpad branches [06:14] mpool: I've played with it a bit for some personal projects though, and it seems quite nice [06:15] mpool: I'm looking forward to the switching though -- baz was getting to the point where I was considering buying another gig of memory [06:15] wow [06:15] jamesh: robert is pretty keen on using twisted in bzrlib [06:16] have you used it at all or run into it in pygtk? [06:16] my experience with twisted is very limited [06:16] i wrote a pygtk & http toy on top of twisted and it seemed to go well [06:18] cool. [06:19] jamesh: so, hows it running ? [06:19] lifeless: chugging away. [06:20] https://chinstrap.ubuntu.com/~jamesh/pending-reviews.new/ <- you can see the progress there [06:22] how does one authenticate to cinstrap http? [06:22] I'll /msg you the password [06:40] hey guys [06:40] what does provide ImportError: No module named gettextpo [06:40] ? [06:41] you have not done 'make build' probably [06:41] lifeless: there is no such thing in the wiki... [06:42] make build where and when? [06:42] fabbione: in the launchpad/ directory [06:43] jamesh: as i told yesterday to lifeless i am following the wiki step by step [06:43] there is no such thing [06:43] https://wiki.launchpad.canonical.com/RocketFuelSetup [06:43] i am at Database Setup [06:43] the Database setup assume the presence of gettextpo [06:43] so either we are missing a package in the apt-get steps [06:44] or as you say it's missing a command [06:46] what was being run when you got that error, out of interest? [06:50] cd $your_launchpad_checkout/database/schema; make; cd - [06:50] from DatabaseSetup [06:52] I mean what command was make running at the time it failed? === poningru [n=poningru@n128-227-34-221.xlate.ufl.edu] has joined #launchpad [06:52] * Installing tsearch2 into ts2 schema [06:52] Traceback (most recent call last): [06:53] do you want the full error? [06:54] nope. that's fine [06:54] does running "make" in $your_launchpad_checkout beforehand fix the problem? [06:56] dunno.. i can try [06:58] make fixes that problem [06:58] but the same module comes out with a different error now [06:59] and yes pg is running [06:59] and configured as requested [07:01] what error? [07:01] jamesh: see /msg [07:02] is there a unix domain socket by that name? [07:02] nope [07:02] you installed the postgres 8 packages ?:) [07:02] yes [07:02] okay [07:03] the postgres 8 packages are set to listen on a different port (presumably so that you can run both 7.4 and 8.0 at the same time) [07:03] hmmmm [07:03] ah i think i know what's wrong [07:03] if you want to use postgres 8, I think you need to set the port back to the default [07:03] jamesh: no there is a problem with the procedure === fabbione debugs === Burgundavia [n=corey@S0106000000cc07fc.gv.shawcable.net] has joined #launchpad [07:07] jamesh: hmm no [07:08] jamesh: the make in db/schema is accessing pgsql via unix socketsd [07:08] sockets [07:08] not via port [07:08]