=== mpool_ [n=mbp@ozlabs.org] has joined #launchpad === stgraber [i=steph@sgserv.net] has joined #launchpad [12:21] cprov-afk, replied. [12:22] jamesh, do you understand what happens when you commit locally in a non-lightweight checkout? [12:22] jamesh, how do you get that commit into your repository branch? [12:23] kiko: if it is a heavyweight checkout, the commit will be made both locally and remotely [12:23] unless you do "bzr commit --local" [12:23] jamesh, and if you do --local [12:23] how does it get moved up? [12:24] kiko: I haven't looked at the code, but I believe it is essentially (1) check that local branch is up to date, (2) try to commit to local branch, (3) push that commit to remote branch [12:24] if (3) fails, the change gets rolled back locally [12:25] kiko: if you pass --local, (3) gets skipped [12:25] jamesh, okay. but now your checkout and the repo are out of sync. how do they sync up? [12:25] you do a commit without --local [12:25] ah. and then it pushes all pending commits? [12:26] yeah [12:27] I think "bzr update" might also send pending local commits [12:27] lifeless said that if your local commits form a divergance from the remote branch, "bzr update" will do a merge [12:28] I see. interesting [12:28] good for shared branches where other people might be committing [12:29] yeah [12:31] the current workflow I use is to have a copy of my repo locally, and rsync the entire repo to sodium when I want to publish changes I've made [12:31] I then use lightweight checkouts of the local repo, so that commits go directly into the repo [12:32] jamesh, you use rsync instead of push? why? [12:33] kiko: I push all my branches in one go [12:33] is there an advantage to that, though..? [12:34] I was using this workflow when I switched to a repo back when we were using weave branches still [12:34] back then it was definitely a win over sftp push [12:34] it might not be as much now === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has left #launchpad ["Bye"] [12:53] spiv, ping? [12:57] bradb: tags!!!! [01:19] sabdfl: http://people.ubuntu.com/~robertc/lp-depends/ if you need the lp-deps, until Etienne publishes his ones === _mholthaus [n=mholthau@johnny33.dersbach.ch] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad === rpedro_ [n=rpedro@87-196-9-93.net.novis.pt] has joined #launchpad === Solarion [n=solarion@cruftix.physics.uiowa.edu] has joined #launchpad [02:48] Is there a problem with bug submission? I get "Please fix the problems listed below" without any problems listed below! [02:50] Solarion, hmmm. can you tell me exactly what you are doing? [02:51] I'm trying to submit a bug to ubuntu, url https://launchpad.net/distros/ubuntu/+filebug [02:51] I had javascript disabled initially, which may have caused the trouble. [02:52] Solarion, there is no JS requirement in that form. so tell me what you are doing [02:52] did you add a sumary or description? [02:53] ah [02:53] it doesn't say they are required. [02:53] it reported having blocked JS [02:53] [it being NoScript] [02:53] I have a package selected, and a summary, and Further Information [02:53] well, the only JS there is used to render the menus AFAICS. [02:53] ah [02:53] Solarion, which package? [02:53] Inkscape [02:53] how did you select it? [02:53] typed it in [02:54] a drop-down list popped up next to it after (failed) submission [02:54] ah. [02:54] ah-ha [02:54] that's a known bug [02:54] click on the list, select an item from it (even if it is a single-item list) and try submitting again. [02:54] I had typed "Inkscape" and the drop-down list had "inkscape" and somehow things were unhappy [02:54] typing "inkscape" worked [02:55] however, there should be some text to say that was what failed. :) [02:55] yeah [02:58] ah well. works now. [03:00] cool === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad === Owais` [n=ow@202.163.108.225] has joined #launchpad === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad === stub [n=stub@ppp-58.8.3.94.revip2.asianet.co.th] has joined #launchpad === dous_ is now known as dous === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad [05:00] Gooooooooooooooooood afternoon Launchpadders! [05:03] hey === sevrin [n=sevrin@202.75.186.154] has joined #launchpad [05:12] SteveA, pong [05:19] spiv, ping [05:20] mpt: pong [05:22] spiv, I spent 40 minutes last night trying to work out how to make "ssh sodium" work, including reading the man page [05:22] mpt: ouch [05:23] Can you put me out of my misery? :-) [05:23] https://sodium.ubuntu.com/~andrew/paste/filebailL8.html [05:23] mpt: pastebin your ~/.ssh/config? [05:23] Heh. [05:23] The last section doesn't make any difference, either to chinstrap's workiness or sodium's non-workiness [05:23] mpt: As I said yesterday, you need to duplicate the contents of your *.ubuntu.com section in your sodium section. [05:24] mpt: You don't need it for chinstrap, because chinstrap is the only system directly accessible from outside. [05:24] mpt: (hence the ProxyCommand) [05:24] by "duplicate in" do you mean "add to", or "use to replace"? [05:24] "add to" [05:25] Specifically, you need the ProxyCommand in the "Host sodium" section. [05:25] That was one of the things I tried, and I got some error about stdin not being a terminal [05:25] one moment [05:25] huh! [05:26] it works [05:26] thank you :-) [05:27] mpt: https://sodium.ubuntu.com/~andrew/paste/file8khb9Y.html is the relevant bits of mine, if you want to compare [05:27] You're welcome :) === mpt wonders at the efficacy of "Host chinstrap.ubuntu.com \n HostName chinstrap.ubuntu.com" :-) [05:29] mpt: heh :) [05:30] mpt: You can make that 'Host chinstrap chintrap.ubuntu.com\nHostName chinstrap.ubuntu.com' [05:30] mpt: So you won't need the domain name [05:37] (look out, it's a chintrap!) === stub wonderth wtf happened to hith eth key [05:39] stub: haha [05:42] stub: I look forward to reviewing code where you have "aththert" and "clathth" statements ;) [05:47] thuffering thuckertaththh === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad [06:26] lifeless: I'm not clear what LoomEntry.name is supposed to be. [06:26] lifeless: oic. don't worry. === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [06:48] lifeless: So how are we going to access LoomEntrys ? Will we need to retrieve all looms for a given revision in order of sequence? Do we need to look them up by name? [07:14] stub: thanks [07:14] privmsg.. === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad === rraphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [07:50] bother [07:50] PQM seems to think my branch is still on chinstrap for some reason [07:51] mpt: If you do a "bzr push --remember sftp://sodium.ubuntu.com/...", the location info in your branch will be updated. [07:52] spiv, that's what I did [07:52] and it updated .bzr/branch/parent [07:52] mpt: What are you using to generate PQM requests? [07:52] but not .bzr/x-push-data [07:52] Hmm. [07:52] So I've updated that manually, but I feel dirty for doing so [07:53] and my submit script has MYURL=$(cat .bzr/x-push-data | sed -e 's|^$.*$:/|sftp://\1/|g') [07:55] x-push-data isn't the right thing to read. [07:56] It's not a bzr thing; that's left by bzrtools' rspush command only afaict. [07:56] The correct place is in your ~/.bazaar/branches.conf [07:57] I guess the right thing to do is use the pqm-submit plugin, rather than your submit script, but I haven't got any experience with that yet. [07:57] branches.conf refers to sodium for this branch [07:58] but maybe that's because I did another push after updating x-push-data? [07:59] branches.conf should have been updated when you did the "bzr push --remember". [08:00] oh, right [08:00] so it's just the submit script that's wrong [08:00] Right. [08:00] Because nothing should be using x-push-data anymore. [08:01] And because branches.conf has multiple lines per branch, that's not an awk-able problem [08:02] Hmm, I think it probably is gawk-able, but it would be dirty. The right answer is to stop using shell hacks, and to use the proper pqm-submit plugin. [08:04] mpt: https://launchpad.canonical.com/WorkingWithSharedRepositories has a section on WorkingWithSharedRepositories [08:07] mpt: Er, a section on "Sending Merge Requests to PQM", rather. [08:08] Yes, that's what I guessed you meant :-) [08:08] thanks [08:08] mpt: I'm glad your telepathy is workiing :) === mpt_ [n=mpt@203.118.156.188] has joined #launchpad === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad === mpt [n=mpt@203.118.156.188] has joined #launchpad === rpedro_ [n=rpedro@87-196-111-49.net.novis.pt] has joined #launchpad === mpt [n=mpt@203.118.156.188] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad === malcc [n=malcolm@host86-134-233-12.range86-134.btcentralplus.com] has joined #launchpad === Fujitsu [n=Fujitsu@c58-107-168-5.eburwd7.vic.optusnet.com.au] has joined #launchpad === einheit_ [n=steve@82.109.136.116] has joined #launchpad === ddaa [n=ddaa@82.109.136.116] has joined #launchpad [10:15] good morning === danilos [n=danilo@82.109.136.116] has joined #launchpad === jamesh [n=james@82.109.136.116] has joined #launchpad [10:20] lifeless: rocketfuel-built on sodium.u.c does not seem to be updating. === dsas [n=dean@host86-129-20-188.range86-129.btcentralplus.com] has joined #launchpad [10:41] jamesh: thanks, fixed [10:41] jamesh: or not [10:41] its in cron [10:41] elmo: is cron workin on sodium? === ddaa [n=ddaa@82.109.136.116] has joined #launchpad [10:43] elmo: ah. Can you please install baz on sodium? Its used by a library that probes for tree types. I'll fix the script to be happy without it. [10:43] but for now ... [10:44] lifeless: the pending-reviews page is updating, so cron must be working [10:44] ok, going home from mpools, when baz is installed it will start updating === ddaa [n=ddaa@82.109.136.116] has joined #launchpad === SteveA wonders if a shell script can "simulate" baz for this ;-) [10:52] Znarl: ping === mpt_ [n=mpt@203.118.156.188] has joined #launchpad === doko [n=doko@dslb-088-073-104-011.pools.arcor-ip.net] has joined #launchpad === SteveA files RT request for baz on sodium, cc lifeless [11:14] jamesh, lifeless: james t. has installed baz on sodium. [11:15] SteveA: cool. We should see if rocketfuel- [11:15] built is updating in a little while then === jinty [n=jinty@213-156-52-99.fastres.net] has joined #launchpad === mpt [n=mpt@203.118.156.188] has joined #launchpad [11:19] Where do I get urlutils from? It doesn't seem to be mentioned in any Ubuntu package description [11:20] mpt: pqm-submit failing for you? [11:20] yes [11:21] i had that too - apparently the trick is to revert the pqm-submit plugin to revision 11 [11:21] My first time using it [11:21] but i'm not sure how one does that [11:21] heh === mpt thinks he has it [11:26] sabdfl, cd ~/.bazaar/plugins/pqm-submit; bzr revert -r 11 [11:27] oh, hooray for hiding the bounty tracker === Spads [n=crack@217.205.109.249] has joined #launchpad === carlos [n=carlos@82.109.136.116] has joined #launchpad === ploum [n=ploum@ubuntu/member/ploum] has joined #launchpad [11:33] mpt: bzr revert does not seem to actually make the revisions disappear === mholthaus_ [n=mholthau@178.23.62.81.cust.bluewin.ch] has joined #launchpad [11:36] sabdfl, true, bzr revno gave me the same after as before, but bzr pqm-submit worked after where it didn't before [11:54] morning [11:56] I broke PQM :-( [11:56] Spads? [11:57] mpt: tell me a story. [11:58] Spads, once upon a time there was PQM status served at http://pqm.launchpad.net/ [11:58] About five minutes ago, it changed to a directory listing [11:58] and now, it won't respond at all [11:59] Aha [11:59] so what were you doing at the time? [11:59] clicking Reload [11:59] haha [11:59] aha, I see [11:59] let me look at that [11:59] thankew [12:00] Spads: it is supposed to proxy to another machine running a PQM status page [12:00] ah, I believe I know what this is [12:01] We are doing some recovery work, and had to take down the machine that is doing the proxying. We have a temporary system in place, but the downtime is unavoidable, I'm afraid. [12:01] we can fix that [12:02] We have the technology. [12:05] launchpad developers: see my message to the launchpad mailing list about how to get access to your branches and other data that was on chinstrap. [12:05] Spads: is pqm continuing to do what it was doing, just the display is borked? [12:05] i had a landing in the queue too [12:06] pqm should be fine === Spads nods [12:06] except for its web UI [12:06] i'll wait for the failure message, then [12:07] pqm web UI is back [12:10] thanks elmo === ChanServ [ChanServ@services.] has joined #launchpad [12:16] SteveA: think we can get edge.launchpad.net / crack.launchpad.net / beta.launchpad.net up and running for 1.0? [12:16] lifeless: is that a bug in the pqm display that it thinks that merge request for branches on sodium are for "other projects", or does that mean that I got my merge request wrong? [12:17] sabdfl: depends what else is on stuart's plate. I'll talk with stub. === SteveA notes that the bounty-tracker-hiding branch landed [12:19] I mean on pqm.launchpad.net [12:20] 'mpt@myrealbox.com is not permitted to commit to /home/pqm/archives/thelove/bzr/+trunk' [12:20] and it's actually my merge request was wrong [12:20] ugh [12:21] mpt: if you do "bzr pqm-submit --dry-run -m message", you can see what the email would look like [12:21] it will print the submission request to the terminal rather than sending it, so you can see if it looks wrong [12:21] right... that's the hardcoded default for the pqm-submit plugin [12:22] you need to update the text in your ~/.bazaar/branches.conf [12:22] I'd like branches.conf to work differently [12:22] so that you can give a "root path" location [12:22] I did that [12:22] and specify the pqm for all things below that [12:22] following the text in WorkingWithSharedRepositories [12:23] mpt: is there a section in ~/.bazaar/branches.conf for your branch as well? [12:24] yes [12:24] mpt: if you have sections for $REPOSITORY and $REPOSITORY/$BRANCH in your branches.conf file, bzr will ignore the settings in the [$REPOSITORY] section [12:24] I was wondering that [12:24] which is a pain, since some commands will automatically create the [$REPOSITORY/$BRANCH] section [12:24] Should I remove all the branch-specific parts from the file? [12:24] (since they're all Launchpad branches) [12:25] you can either do that or copy the settings from the repository section to each of the relevant branch sections. [12:26] With the former, I get a "Not a branch" error [12:26] so I'll try the latter [12:28] ... and so does the latter === fantamaxx3 [n=mholthau@65.193.63.81.fix.bluewin.ch] has joined #launchpad [12:31] ah, pqm_branch = push_location [12:32] hmm, no, pqm thinks that's a non-pqm-managed branch [12:35] hooray === stub [n=stub@ppp-58.8.3.94.revip2.asianet.co.th] has joined #launchpad [12:42] hi stub [12:43] Morning [12:58] hey stub, how's progress on CanonicalPillarNames? [12:59] sabdfl: Up for review [12:59] that's awesome, thanks for getting it nailed [01:00] stub: jamesh is sorting out the final touches on the python demo server [01:00] there are some questions about how to set up the incoming email [01:00] Nothing in my mailbox. jamesh - wassup? [01:01] stub: will you brief brad, bjorn, others on places where it can be used to simplify things? [01:01] for example, malone email interface [01:01] sabdfl: Ok. I'll add an agenda item to this weeks Launchpad meeting [01:01] brad won't be there [01:01] stub: I haven't yet set up the cron jobs for incomming email handling or the outgoing bug mail handler. I have the details for the POP email box now [01:02] nor will bjorn [01:02] so, this week's launchpad meeting isn't a great venue for that [01:02] I just need to know how the cron jobs should be set up, and where to put the POP3 configuration [01:02] Hmm... ok. [01:02] mail to launchpad list may be better [01:02] perhaps we can just adapt what's being used in production/ [01:02] ? [01:02] followed up by a note for next week's lp meeting [01:03] jamesh: Yes. Just looking there to refresh my memory ;) [01:19] stub: hi, do you have sometime to talk about my migrate-translations branch? [01:20] carlos: sure [01:20] stub: we got it done, but we are trying to optimize it a bit (it took 6 hours to migrate translations from breezy to dapper) [01:20] stub: ok, thanks [01:20] stub: danilos suggested to use a temporary table to store all information so we don't need to do similar queries 4-5 times [01:20] like we do with current code [01:21] I we would like to know your opinion about that [01:21] Makes sense. Temporary table, or even a real one. [01:21] stub: they were all nested selects [01:21] stub: this is the current diff (without the optimizations) [01:21] stub: https://sodium.ubuntu.com/~jamesh/pending-reviews/carlos/launchpad/migrate-translations/full-diff [01:22] Sure. It is a standard optimization technique. You probably need to create indexes on the temp table to speed up its subsequent usage. [01:22] stub: yeah, we were wondering whether we can create indexes there [01:22] stub: could we just use the usual syntax to do that? [01:23] yes [01:23] stub: btw, if our temporary tables ends up being like 3M rows, doing inserts directly from that won't be too slow? [01:24] danilos: I don't follow you sorry. [01:25] stub: well, we want to do something like "insert into something (blah, blah) from select (foo, bar) from temporary_table;" === lfittl [n=lfittl@85-125-227-78.dynamic.xdsl-line.inode.at] has joined #launchpad [01:25] temporary tables being 3M rows long isn't a problem. Inserts using that as source data won't be slow if you are doing a bulk insert (iNSERT INTO FOO (bar,baz) SELECT bing, bong FROM temp_table), or one-at-a-time inserts provided you have created a suitable index. [01:25] stub: ah, ok, great, that's exactly what I was wondering [01:25] It would be one of the faster ways of inserting 3 million rows [01:27] stub: ok, thank you very much [01:27] stub: thanks for the help ;) [01:28] danilos: You probably won't want to insert all 3 million rows at once though, as that would lock the destination tables for an unacceptable amount of time. So you might need to do the insert in batches, using an ID column (INSERT INTO something(blah, blah) FROM select foo, bar from temp_table where id BETWEEN 1000 AND 2000; [01:29] carlos: That script should probably be run in READ_COMMITTED isolation level. (just add isolation=READ_COMMITTED as a parameter to initZopeless. READ_COMMITTED can be imported from canonical.database.sqlbase) [01:30] stub: what does it ? [01:32] carlos: It means your migration script won't die with a serialization exception half way through. file:///usr/share/doc/postgresql-doc-8.1/html/transaction-iso.html for the theory [01:32] stub: we won't be inserting 3m rows, this is just the data we will be using, extrapolated somewhat with outer joins (we need it all for some checks) [01:32] stub: ok, thanks [01:32] carlos: Oh... add 'import _pythonpath' to the top of your script so I don't have to. [01:32] ok [01:33] stub: what's the reason begin that if we are not using _pythonpath ? [01:33] carlos: If you don't add it, I have to when running it on production so script can find the modules it needs to import. [01:34] oh, I see [01:34] (because it is easier than arsing about setting environment variables) [01:34] so we are actually using it ;-) [01:34] ok [01:34] I was not sure about its utility [01:36] sivang: ping [01:37] SteveA: pong === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad [01:54] ddaa: your target url should be sodium.ubuntu.com [01:54] ddaa: thats what in the config. [01:54] lifeless: the problem was different [01:55] specifically, I updated pqm-submit, and the pqm_branch option is now a user option instead of a branch option [01:55] ddaa: er, its always been both [01:55] mh? [01:55] lifeless: rocketfuel-built still seems out of date, and baz is installed now [01:56] so it fell back to the bzr-dev default [01:56] anyhow, I got it "working" [01:56] I have limited time to investigate that sort of issue [01:56] this "default" for the pqm branch seems like a bad idea to me [01:56] sftp sodium.ubuntu.com fails on sodium [01:56] which is whack [01:57] lifeless: eh [01:58] oh, I know why [01:58] lifeless: should work now [01:58] ok, rf-built should update preoplery now [01:58] spelling good I am at === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:00] jamesh: 3828 correct? [02:00] (12:58:44) sabdfl: hmm... Product permissions are a bit of a mess [02:00] (12:58:54) sabdfl: it seems Rosetta admins have launchpad.Admin on all products [02:00] (12:59:15) sabdfl: and Product.owner (plus lpadmins) is the only person with launchpad.Edit [02:00] (12:59:35) sabdfl: and now matsubara has allowed Product.owner to be edit by anybody with Product.owner [02:00] (12:59:53) SteveA: this is a #launchpad discussion, not a #bzr one [02:00] (12:59:54) sabdfl: how does the transfer-of-ownership protocol work? [02:01] lifeless: looks better now. Thanks [02:02] np [02:02] carlos and danilo are discussing some database stuff right now. matsubara and salgado will be around in an hour or so. [02:03] we're here already === niemeyer [n=niemeyer@200.138.54.241] has joined #launchpad === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:03] sabdfl: previously product owners had launchpad.Admin on their products, so they could transfer ownership [02:03] oh, hi salgado... early riser! [02:05] sabdfl: the security adapter for IProduct/launchpad.Admin has a comment pointing to https://launchpad.net/products/rosetta/+bug/753 above it [02:06] jamesh: do we want Foo.owner to have launchpad.Admin on the foo, as a rule? [02:09] sabdfl: there are some cases where we use launchpad.Admin to give owners more rights (where other people might have launchpad.Edit permissions) [02:09] sabdfl: and other areas where launchpad.Admin is used to restrict access to administrators (LP admins, rosetta admins or some other team) [02:10] it'd probably be good to use different permission names for these two cases [02:11] jamesh: agreed. i think we need to take time to talk about the permission system for LP generally === MaSa69 [n=MaSa69@dsl-jklbrasgw1-fe1cfb00-100.dhcp.inet.fi] has joined #launchpad [02:13] sabdfl: I have a bunch of changes to this pending coding, based on what we've discussed over the past several months [02:14] these are incremental changes, because it is a big risk to pull everything out and replace it all at once [02:14] this is something we should talk through at the infrastructure sprint in a couple of weeks [02:17] agreed === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad [03:02] the london sprinters go to lunch === mpool [n=mbp@ozlabs.tip.net.au] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [03:04] me go to lunch, me go to lunch, me go to lunch ;) [03:13] jamesh: thanks - that RT ticket just made my day [03:14] stub: apparently there's something wrong with dilys@muse. Should I remove all reference to it from lp code? === jinty [n=jinty@213-156-52-99.fastres.net] has joined #launchpad === jim09 [i=Tim@n219079031252.netvigator.com] has joined #launchpad [03:39] matsubara: It is hard coded? Sure. [04:09] matsubara: are the error reports you're seeing coming from carbon.ubuntu.com? [04:10] jamesh: yes [04:10] matsubara: there are some problems with how the outgoing email cron job interacts with the mail whitelist we've got in place (i.e. it doesn't handle the rejection), and dilys is just the first address it tries [04:11] it isn't on the whitelist [04:13] I need to so another code update on staging, is there anyone using it atm ? [04:13] it will take 5-10 minutes [04:14] s/so/do/ === lbm [n=lbm@0x5358aa18.hrnxx7.adsl-dhcp.tele.dk] has joined #launchpad === ddaa [n=ddaa@82.109.136.116] has joined #launchpad [04:15] jamesh: I see, but stub suggested that I should remove dilys@ from lp code anyway. Nobody's using "her" AFAICT [04:15] no complains? [04:15] 5 [04:15] 4 [04:15] 3 [04:15] 2 [04:15] 1 [04:15] 0 [04:15] Anyone up for a quick review of https://sodium.ubuntu.com/~jamesh/pending-reviews/malcolmcleaton/launchpad/bug-54032/full-diff ? [04:16] malcc: just did [04:16] one comment: [04:16] and one question [04:17] matsubara: I suppose so. I was just pointing out the cause of the failure [04:17] the question is, does the doc test change actually test the code change? it isn't clear from the diff what the meaning of the doctest change is, because there is no documentation visible in the diff. [04:17] the comment is: [04:17] pub_careful = False [04:17] -if not (options.careful or options.careful_publishing): [04:17] +if options.careful or options.careful_publishing: [04:17] pub_careful = True [04:17] [04:17] why use an 'if' there? [04:18] staging is back to live [04:18] you can just say pub_careful = options.careful or options.careful_publishing [04:19] I'll add some doc to the doctest [04:19] jamesh: thanks. [04:19] And yes, that would be shorter [04:27] jamesh: when you have a spare few minutes, please join #bzr to talk about the pqm-submit plugin === jamesh joins [04:27] hullo [04:31] gnight all === lifeless waves [04:32] SteveA: Changes made, new diff here: https://sodium.ubuntu.com/~andrew/paste/fileUoBLtd.html [04:32] malcc: not only shorter but I think clearer [04:33] fewer items on the mental stack needed to understand what's going on [04:33] SteveA: Yes I agree. [04:33] SteveA, kiko, stub, lifeless: Could you remove/hide this bounty? https://launchpad.net/bounties/0 [04:33] and reads from python into english easiy [04:33] looks good [04:33] is "careful publishing" explained elsewhere in the doc? [04:34] carlos, I don't see how that bounty is worse than any other, tbh. we should just remove them all. [04:34] kiko: well... that one doesn't have any content ;-) [04:34] the others are more user requests and others... are offering money to implement those features [04:34] SteveA: Hmm, no === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad [04:37] carlos: done [04:37] stub: thanks [04:39] SteveA: https://sodium.ubuntu.com/~andrew/paste/fileJZ1AUe.html [04:40] malcc: that reads well to me. good stuff. r=me. [04:41] SteveA: Thanks === Spads_ [n=crack@217.205.109.249] has joined #launchpad === jinty [n=jinty@213-156-52-99.fastres.net] has joined #launchpad === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad === frodon_ido [n=patrick@ip-213-49-150-10.dsl.scarlet.be] has joined #launchpad === Lord_Athur [n=alejandr@pc-10-33-214-201.cm.vtr.net] has joined #launchpad === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad === dous [n=dous@ubuntu/member/dous] has joined #launchpad [06:13] spiv? === lbm [n=lbm@0x5358aa18.hrnxx7.adsl-dhcp.tele.dk] has joined #launchpad === Ubugtu [n=bugbot@ubuntu/bot/ubugtu] has joined #launchpad === rraphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [07:04] jamesh: I think 15216 is now done - do you want to check? [07:08] elmo: It seems to be able to open the mail box. I'll see if it can process the email [07:08] elmo: yep. Looks like it is all working. Thanks [07:09] jamesh: cool [07:17] SteveA: please revert the MigrationToSodium changes when you get a sec, chinstrap is back [07:19] elmo: I've updated the wiki page to remove the note [07:19] jamesh: thanks === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad === jinty [n=jinty@213-156-52-99.fastres.net] has joined #launchpad [08:30] SteveA: http://wiki.python.org/moin/LaunchpadTracker <- that's the info I've put up so far [08:36] salgado: Ping [08:37] niemeyer, pong [08:37] Heya! [08:37] how's it going? [08:37] Everything going smoothly :) [08:37] Quick questoin: [08:37] SteveA: What do you guys do when you have to insert something unique in a table, reusing an existent value when it's already there? [08:37] SteveA: Do you usually lock the whole table, use a db function, or catch the error and invalidate the transaction? [08:38] salgado: I remembered the "single request per person" shipit issue [08:38] and we tried a couple of things [08:39] but I can't remember what they were exactly [08:39] yeah, that's right. let me see if I remember [08:40] so, niemeyer, you actually want to know the different things we tried or just if/how we solved it in the end? [08:40] one issue was to do with the isolation level used === mdke_ [n=matt@unaffiliated/matt/x-000000001] has joined #launchpad [08:41] yeah, because the constraint was hard to write we first tried to lock the table in EXCLUSIVE mode, IIRC. but that didn't work because of the isolation lever we used [08:41] salgado: I'd like to know which solution turned out to be the best and why, if possible. I kind of understand a few different paths to do it. [08:41] niemeyer: talk with stu when he's arround tomorrow [08:41] niemeyer: inside a transaction you'd usually perform a select to see if a row exists, and then add the row if it doesn't [08:42] jamesh: That's what I'm doing now, except that I have to catch an error on the insert, since someone else might have inserted it before. [08:42] jamesh: So it becomes a function, to avoid invalidating the whole transaction [08:42] Which is of course boring to work with [08:43] I was wondering if you have a clever way to handle it [08:43] "SELECT OR INSERT" is what I need.. ;-) === niemeyer writes to the SQL consortium complaining.. ;) [08:44]