wallyworldsinzui: yes, looks like it was r13573, bug 80950800:02
_mup_Bug #809508: Suggest branches with current bug number when associating a bug with a branch. <qa-ok> <Launchpad itself:Fix Released by benji> < https://launchpad.net/bugs/809508 >00:02
wallyworldcommit msg: Make the search box stay disabled and the spinner visible until all outstanding searches are finished00:02
wallyworldmp was self reviewed, so something slipped through there00:03
wgrantwallyworld: Should we abort the rollout?00:05
StevenKwallyworld: If you're unclear, just revert it00:05
mhall119does anybody else get an error on this page: https://api.launchpad.net/1.0/~ubuntu-br/homepage_content ?00:28
mhall119wgrant: ^^00:28
mhall119or lifeless00:29
mhall119whoever is awake00:29
mhall119cjohnston: this is the cause of our lpupdate failure I think00:29
StevenKThat doesn't look like JSON to me00:29
cjohnstonhmm.. where is that coming from00:30
mhall119it's part of the response from https://api.launchpad.net/1.0/~locoteams/members00:31
mhall119that part of the json, brazil's homepage_content00:31
mhall119is where our script if throwing exceptions00:32
cjohnstonso something is wrong it looks like on LPs end in the Homepage Content area00:35
mhall119I'm still not quite sure what though00:35
cjohnstonI wander if its something with the localization of it00:36
mhall119I think it's more likely that it's not specifying that it's unicode00:38
wgrantStevenK: Your browser Accepts HTML, so it will give it HTML.00:51
StevenKwgrant: Even wget doesn't show JSON00:52
wgrantIt does.00:52
wgrantWell, curl does.00:52
wgrant"Usu\u00e1rios do Ubuntu no Brasil.\n\nTime para usu\u00e1rios do Ubuntu no Brasil.\n\nComece Aqui:  -  http://www.ubuntu-br.org/comece\n\nP\u00e1gina Principal:  -  http://www.ubuntu-br.org\nWiki:  -  http://wiki.ubuntu-br.org\nPlaneta:  -  http://planeta.ubuntu-br.org\nF\u00f3rum  -  http://ubuntuforum-br.org/\nDocumenta\u00e7\u00e3o:  -  http://wiki.ubuntu-br.org/Documentacao\n\nAntes de entrar neste time, voc\u00ea deve ler, concordar ...00:52
wgrant... e assinar o C\u00f3digo de Conduta do Ubuntu (http://www.ubuntu-br.org/codigodeconduta)."00:52
wgrantwget does too.00:53
wgrantContent-Type is correctly "application/json"00:53
wgrantNo encoding is required, as it's ASCII.00:53
wgrantmhall119: What's the error your script is throwing?00:53
mhall119yeah, I'm getting json00:58
mhall119wgrant: http://paste.ubuntu.com/658298/00:58
wgrantI can access the members collection without trouble.00:58
mhall119I've tracked it down so simplejson trying to decode a string00:58
wgrantIs it possible you've got a corrupt cache?00:59
wgrantTry removing your launchpadlib cache.00:59
mhall119I don't have access to do that on cranberry00:59
mhall119and my local dev isn't even getting me past lp_login, not sure why00:59
mhall119ok, I just need to get my local dev working to the point where I can watch this with a debugger01:02
wgrantI doubt it will happen locally.01:03
cjohnstonmhall119: there is a vangard on01:09
mhall119cjohnston: I've already got them doing it01:10
mhall119now we wait until 10pm01:10
mhall119the cron should have run again by then01:10
LPCIBotProject devel build #945: STILL FAILING in 5 hr 48 min: https://lpci.wedontsleep.org/job/devel/945/05:12
jtvwgrant: did you have any luck trying the new publish-ftpmaster yesterday?07:02
wgrantjtv: It finished not long after you EODed.07:06
wgrantjtv: Expedited security processing works fine.07:06
jtvYou have made me so happy.07:07
wgrantI'm pretty happy with the whole thing now, but I need to check over the hooks a bit.07:07
jtvI'd appreciate that — as soon as you're satisfied with them, we can make the switch.07:07
wgrantjtv: They all look pretty sensible.07:12
wgrantWhat's the worst that it could do...07:12
jtvwgrant: then I shall proceed to move this towards production…07:14
jtv…albeit with some trepidation.07:14
wgrantBut I think we can do little else now.07:15
adeuringgood morning07:26
=== almaisan-away is now known as al-maisan
jtvah yes, bigjools: when copying custom uploads from a previous Ubuntu series, I don't suppose the pocket matters much?08:42
bigjoolsjtv: nup08:50
jtvArgh.  But the changes file does.  It'd be nice if I could just copy the LFA id, but that's not currently supported.08:51
jtvDistroSeries.createQueueEntry expects to have to store the changes file into the Librarian.08:51
wgrantYou are creating new PUs and PUCs? :/08:52
jtvwgrant: Have to.  What's the problem with that?09:15
wgrantyou don't have to; it's just easier than the rather messy and time consuming proper fix.09:16
wgrantPerhaps understandable.09:17
wgrantBut definitely another pile in the hack pile.09:17
wgrantanother hack in the hack pile09:17
wgrantThat's the one.09:17
wgrantIt's like delayed copies, except even worse defined :(09:19
jtvInternet connections: you just can't trust 'em.09:30
jelmerIs staging used to test anything in particular ? I wonder if now would be a good moment to get the  branch with the newer bzr deployed there for the extended QA discussed on the list.10:49
wgrantjelmer: DB patches (at least for the next week) and mailing lists and some build farm stuff.10:51
wgrantPretty much everything else is on qastaging these days.10:51
jelmerwgrant: Ah, cool - thanks.10:53
jelmerTime to land my branch and QA it then.10:53
wgrantjelmer: Land it? Do you mean get it cowboyed onto staging?10:54
wgrantAlso, staging is having a bit of evil performed on it a bit the last couple of weeks, for testing fastdowntime.10:54
wgrantNot sure if stub has much more of that planned.10:54
jelmerah, hmm10:54
lifelesswgrant: waiting on pgbouncer just now, for prod.10:54
wgrantlifeless: We're going with the 3m downtime?10:55
lifelesswgrant: stub has it down to ~2m10:55
lifelesswgrant: slony deletes and creates ~ 500 triggers on all nodes.10:55
wgrantI had a 2-slave no-op update down to 45s here by skipping trusted.sql, IIRC.10:55
wgrantThe master takes around 12 seconds.10:56
wgrantSo the triggers don't take tooooo long.10:56
lifelesswe may be seeing cold cache table metadata on staging timings10:56
stubI'm still looking at shaving time off. Skipping trusted.sql if unmodified is doable - just need to store a hash of the file in the db somewhere.10:56
wgrantstub: Can't we treat trusted.sql like the rest of the schema?10:57
wgrantHave a base + patches?10:57
stubAnd we can deprecate updating it10:57
wgrantlifeless: Surely the metadata should be pretty tiny.10:57
stubwgrant: We already have had to with the bugsummarywork10:58
jelmerwgrant: I'm wondering with whom to coordinate this exactly, is there a point of contact/process?10:58
jelmerstub: Are you planning to do more testing on staging for fastdowntime?10:58
stubjelmer: fastdowntime is live on staging, any more tests are just improving the process.10:58
wgrantstub: Right, so let's do that everywhere and stop recreating all those functions each time :)10:58
stubwgrant: The nice thing about trusted.sql is you can edit your code in place, get diffs etc. Current approach by punting that to the dbpatches means cut & paste to tweak a stored procedure, and locating the current implementation involves grep, and source will eventually disappear when we clean out the old db patches. Not sure if we can easily solve any of the downsides, but thoughts welcome.11:01
wgrantstub: Agreed, and that really hurt during the bugsummary debacle.11:01
wgrantBut reapplying trusted.sql is really slow.11:02
stub(cycling the baseline will need some more thought too, as it is tied up with trusted.sql, but I need to fix that already)11:02
stubwgrant: Yup. It seems to be a per-statement overhead in there somewhere, which is why I already dropped comments.sql out of patch application.11:02
stubI could be evil and package trusted.sql up in a stored procedure that applies the contents :-)11:03
stubyour timing on trusted.sql is good though - I hadn't gone to that granularity yet11:04
wgrantI forget exactly, but I think removing trusted.sql saved around 40s. But it only started at around 100s, so I'm not sure what's up with staging.11:05
wgrantmake -C database/replication devsetup is awesome, btw.11:06
LPCIBotProject devel build #946: STILL FAILING in 5 hr 56 min: https://lpci.wedontsleep.org/job/devel/946/11:09
wgrantstub: What intervals are staging's slons running at?11:21
wgrantThe variance gets a lot lower if I reduce the no-SYNC interval to 2s from 10s.11:24
wgrant39-41s without trusted.sql, rather than 45-55s.11:24
wgrantWhich I guess makes sense.11:25
wgrantSince it's waiting for synchronization, with no replicatable write activity.11:26
wgrantAnd if it's waiting for an extra sync on both sides of trusted.sql, that could explain much of the difference.11:26
wgrantNope, adding trusted.sql adds 45s even with 2s forced syncs.11:29
stubwgrant: I landed a branch last night that drops staging down to 1 second syncs and 5 second forced syncs to see if it changes things significantly.11:49
stub1 second sync check, 5 second forced sync11:49
wgrantstub: What was it before?11:49
wgrantWe may want to push through some update right before each sync.11:49
stub2 second sync check, 10 second forced sync (defaults)11:49
stubI don't think it will be significant - maybe shave 10 seconds off, or 15 if we drop the sync poll time to 0.5.11:50
stubBut worth testing in case.11:50
wgrantAdding a third slave has added 15s to the trusted.sql time...11:50
wgrantWhich is about right.11:51
wgrant12-14s to apply to the master, then apparently a similar time to each slave, serially?11:51
wgrantI'm still not entirely clear on how the DDL gets propogated.11:51
wgrantI guess I should read more on that.11:52
wgrantBlah, but it slows down the no-trusted.sql upgrade by nearly 4s too.11:54
wgrantI guess that matches up fairly well, but is still disappointing.11:54
wgrantParticularly if prod has ... 8 replicas?11:54
wgrantMaybe 6.11:54
wgrantI can't count.11:54
jtvwgrant: I'm looking into where to copy the latest custom uploads to a new distroseries.  Julian suggests I might use the hook we already have for the case where a distroseries is being published for the first time.  What do you think?11:58
wgrantjtv: I suggest you do whatever is quickest and easiest to remove when we fix custom uploads properly. That may be that.12:00
wgrantBut it's possibly appropriate to put it right in IDS, if you're creating new PUCs.12:00
wgrantSince it doesn't need to manipulate the disk directly.12:00
jtvBut it also doesn't currently use DSP.12:00
jtvYes.  Well, the code I have now doesn't actually care whether you use it or not; but the initial plan is to do this based on previous_series.12:01
jtvOr whatever the old parent_series got renamed to.12:01
wgrantRight, that sounds somewhat sensible.12:01
wgrantStill more appropriate for IDS IMO, if you're creating PUCs.12:01
jtvDoes IDS get run just once per derived series?12:02
bigjoolsyes, but even creating PUCs is not enough, you need to force them through process-accepted12:02
wgrantYou'll need to create PUs and PUCs, and process-accepted will handle them in its own special way.12:03
bigjoolsit makes me shudder12:03
wgrantI believe I've expressed my opinions on process-accepted and this new strategy.12:03
=== vila_ is now known as vila
bigjoolsleast-worst option for now.  We don't have time to redesign this12:04
wgrantIt is terrible, but probably least-worst.12:04
* bigjools observes the ivory towers in the distance12:04
stubwgrant: An interesting thing about trusted.sql is that it doesn't need to be applied via slonik at all12:06
wgrantstub: It shouldn't have to be, no, so we could possibly work around it.12:06
wgrantBut it may still be slow without it.12:06
stubyes, but I'm looking at 2 minutes. If I can shave 40 seconds off that, it is a big win percentage wise.12:07
stubIt does mean it is being applied outside the db patch transaction12:07
wgrantThe no-op upgrade SQL (just the two UPDATE LDR statements) takes 15s here when executed directly through slonik with three slaves.12:07
wgrantSo we have 30s of overhead in the script.12:07
wgrantProbably the sync on either side.12:07
jtvbigjools: I need to force my copied PUCs through process-accepted?  Won't that run anyway?12:08
wgrantjtv: Yes.12:08
wgrantJust create them on new ACCEPTED PUs, and all will be good.12:08
bigjoolsjtv: it's ok as long as there's a PU in ACCEPTED state12:08
wgrantWell, bad, but it will work.12:08
bigjoolsit is a horrible hack but then custom uploads are a horrible hack :(12:09
jtvSo I have to create my PUs as ACCEPTED?12:09
stubGiven we have already applied stuff from trusted.sql live, I guess we can live without it being applied in-transaction with the db schema updates12:09
wgrantjtv: Maybe just create them and then pu.setAccepted.12:09
bigjoolsthat will also work12:09
wgrantNo, there's setDone... don't think there's setAccepted.12:09
wgrantJust acceptFrom*12:10
wgrantBut one of those might work.12:10
wgrantstub: Hm.12:10
wgrantstub: trusted.sql applies in 100ms directly.12:10
wgrantLet me force it through slonik and see what happens...12:10
wgrantSo something is causing it to execute all the syncs serially, or something.12:11
wgrantWhere that doesn't happen with the no-op patch SQL.12:12
* wgrant tries merging them into one file.12:12
wgrantWith the minor issue that they already end up as one file.12:13
wgrantSo where is the extra 45s coming from.12:13
wgrantThe 13s overhead is on each execute_script.12:14
stubwgrant: When we check for sync, we wait for the sync to be confirmed by ALL nodes. So that blocks until a node has finished doing something like apply a patch and it gets around to acking.12:17
wgrantstub: Yeah, but the patches take <100ms each.12:17
wgrantSo either the slon goes to sleep for 15s after applying the patch, or something else is happening.12:17
wgrantstub: Overhead vanishes if I change upgrade.py's run_sql to merge it all into one big file, with a single execute_script.12:24
stubwgrant: I'm thinking on why patches sometimes get serialized, rather than applied on slaves simultaneously. I think slave2 might block on slave1 saying 'sure - go ahead' because slave1 has already started processing a dbpatch.12:24
wgrantWell, it's down to below 2s, at least.12:24
stubwe don't do that already?12:24
stuboh... one execute script12:24
wgrantWe create one slonik script.12:24
wgrantWith multiple SQL files, and multiple execute_script stanzas.12:25
wgrantIt looks like the syncs around the second one end up serialised, somehow. Might watch slon logs tomorrow.12:25
wgrantWhich is really going to hurt production, if it's 16s per slave rather than 3s.12:25
stubso we want an assert in there that len(open(script).readlines()) < 1000, or we overflow a slony constant I think set at compilation time12:25
stubwe are weird. agile is foreign to most db environments and dbas12:26
stubOur sort of automation tends to scare the bejesus out of people.12:26
wgrantstub: Are the syncs in execute_script insufficient?12:27
wgrantWe currently seem to sync on either side.12:27
wgrantWhich is an extra $while.12:27
wgrantOverhead in upgrade.py is still 30s.12:27
wgrantWill be more on prod.12:28
wgrantBut I wonder if you can try the upgrade.py SQL merge thing on staging?12:28
wgrantSee how far down it takes it.12:28
wgrantEven better if you can reduce the forced sync interval.12:28
stubwgrant: Sure. Stick in a MP for db-devel (we want the fastdowntime stuff on that branch still)12:29
stubI have no problem lowering the sync check and forced sync times if it helps. It won't affect our load.12:29
wgrantAs you say, it should only save a few times the reduction. Might get better numbers tomorrow when I am awake.12:30
wgrant./src/parsestatements/scanner.h:#define MAXSTATEMENTS 100012:31
wgrantKill me now.12:31
wgrantThis is not sensible!12:31
wgrant./src/parsestatements/scanner.c:int STMTS[MAXSTATEMENTS];12:31
wgrantmalloc is hard, I guess.12:32
stubwgrant: Shouldn't be a genuine problem given we won't want a backlog of patches to apply in one hit.12:32
stubwgrant: esp if we decide to pull trusted.sql out12:32
wgrant$ wc -l /tmp/trusted.sql12:33
wgrant2111 /tmp/trusted.sql12:33
wgrantI guess there are some nice long statements in that.12:33
wgrantWill be fun counting them.12:33
stubyes - a whole stored procedure counts as '1'12:33
stubYou are counting semi colons out side of strings, which you can assume are 'string' or $$string$$. Or just ignore the problem for now.12:34
wgrantI think it will be ignored for now.12:34
wgrantWill see how upgrade.py copes if it's violated.12:34
wgrantI mean, it will probably cause slon to segfault or something...12:34
wgrantNo biggie.12:34
stubit will barf in the transaction and roll back.12:35
stubmeybe picked up at slonik compilation time12:35
wgrantHah, all my logging changes conflict with yours.12:35
stubcomments.sql will make it explode :)12:35
* stub disappears for an hour12:39
wgrantstub: https://code.launchpad.net/~wgrant/launchpad/single-execute_script/+merge/7043212:51
* wgrant sleeps.12:59
jelmerg'night wgrant13:00
gary_posterabentley, when you are around, if you could let me know which of bugs 820510, 820511 and 820516 are worthy of critical, or help me decide at least, maybe yellow squad could take one or more of those.13:03
=== wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 247 - 0:[#######=]:256
=== allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap | Critical bugs: 247 - 0:[#######=]:256
abentleygary_poster:  820511 and 820510 give the best bang for buck, but I don't think either one is truly critical, and marking them critical makes it hard for us to see what's truly critical.13:06
henningeabentley, adeuring: I have to switch locations now. Should be back in time for the stand-up.13:07
abentleyhenninge: cool.13:07
gary_posterabentley, ok thanks.  "hard to see what's truly critical"...I don't think it's any different than the existing situation with the critical bug tag, but let's not go there.  Practically, do you agree with wgrant that this is something that should be tackled now, even when our focus is supposed to be on "critical" bugs?13:09
abentleygary_poster: I think it makes sense to tackle soon.  I don't think the focus on "critical" bugs is meant to exclude us working on anything else.13:11
gary_posterabentley, ok.  I'll encourage yellow to grab at least one of those, asking you for guidance when we get there.13:12
abentleygary_poster: np.13:13
StevenKallenap: O HAI!13:15
allenapStevenK: HAI!13:15
StevenKallenap: You marked https://code.launchpad.net/~stevenk/launchpad/populate-bprc/+merge/69412 as Needs Fixing a week ago, and you have since been smacked down by wgrant and lifeless. Can you reconsider? :-)13:16
allenapStevenK: There were other points in the review :)13:17
StevenKallenap: Right, so I'll look at getCandidateBPRs(). I disagree about the loop size -- if it gets killed half-way through a loop, for example?13:18
StevenKallenap: And I don't agree the test is dependant on test data. How?13:18
=== jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap, jcsackett | Critical bugs: 247 - 0:[#######=]:256
allenapStevenK: Why do you only want to do one thing round the loop? I suppose it keeps transactions short, but it's meant to tune for than anyway isn't it?13:20
StevenKallenap: So, each iteration reads a .deb from the librarian, parses the contents and starts tossing rows into BPRC and BPP. If that loop gets interruptted, do I end up with half of the data in the tables and half not?13:21
allenapStevenK: No? Why is that a concern? I don't think it interrupts in the middle of a run. And transactions.13:22
StevenKallenap: My basis for this was the PSC work -- and that was actually unpacking source packages and dealing with a bunch of temporary files, so it was more critical it wasn't killed in the middle of a run13:22
StevenKallenap: Conceeding the loop tuning question -- I'll bump it 20 or so13:23
allenapStevenK: Okay :)13:23
StevenKallenap: So, the test is dependant on sample data?13:24
allenapStevenK: It looked that way, but I didn't dig much. If you say it's not then that's all I want to know.13:25
allenapStevenK: What about 3? That doesn't actually look like it's going to work how it is.13:26
StevenKallenap: I didn't want to include another .deb in the tree, so I make use of one that's already there due to archiveuploader tests13:26
allenapStevenK: Oh, ignore me. EPARSE.13:26
allenapStevenK: So, r=me now, but consider point 4.13:27
StevenKYou'd prefer self.layer... ?13:27
StevenKWait, ignore me, I can't read.13:27
StevenKallenap: -1 for including the IRC log in the MP :-P13:33
allenapStevenK: I just added a tl;dr. What's wrong with an IRC log?13:34
StevenKallenap: Just teasing :_P13:34
=== al-maisan is now known as almaisan-away
=== Ursinha-afk is now known as Ursinha
rvbaallenap: I've fixed my MP, could you add it to your queue? https://code.launchpad.net/~rvb/launchpad/bug-820900/+merge/7043414:20
allenaprvba: Sure.14:20
rvbaallenap: Thanks.14:20
allenaprvba: r=me14:22
rvbaallenap: \o/14:22
cjohnstonthanks mrevell15:34
mrevellHi cjohnston15:43
mrevellno problem at all cjohnston :) thanks for your help15:43
=== beuno is now known as beuno-lunch
sinzuijcsackett, can you review https://code.launchpad.net/~sinzui/launchpad/person-picker-expand-1/+merge/7045916:13
sinzuiThe MP is lying about the changes from the prerequisite branch. I attached the actual changes16:14
jcsackettsinzui: thanks, i was just looking at the MP diff and getting confused about the scope of the changes. :-)16:14
jcsackettsinzui: r=me.16:23
sinzuijcsackett, thank you.16:27
jcsackettsinzui: you're welcome. :-)16:27
=== allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | Critical bugs: 247 - 0:[#######=]:256
nigelberr, wrong channel :P16:42
LPCIBotProject devel build #947: STILL FAILING in 5 hr 53 min: https://lpci.wedontsleep.org/job/devel/947/17:03
=== beuno-lunch is now known as beuno
abentleyjcsackett: Could you please review https://code.launchpad.net/~abentley/launchpad/induce-latency/+merge/7047117:45
jcsackettabentley: sorry, i missed your msg; i'm looking at the MP now.18:01
abentleyjcsackett: cool.18:01
jcsackettabentley: looks good to me, r=me.18:05
lifelessbug 82051019:50
_mup_Bug #820510: hard to turn on extra logging for twisted job runner <jobs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/820510 >19:50
sixstringSo, I killed rocketfuel-setup yesterday. I think it was right in the middle of the "bzr pull" step. Now, when I run "rocketfuel-get", I get "ERROR: No WorkingTree exists".19:54
sixstringBTW, which pastebin do we use here?19:54
lifelessany that ou want19:55
sixstringHow do I fix my bzr repo? (I'm familiar with hg and svn, but I'm a bzr n00b.)19:55
* sixstring searches for paste.lifeless.org. ;)19:56
lifelessput set -x at the top of rocketfuel get so you can see the failing bzr command19:57
sixstringIt's failing at "bzr up ~/launchpad/lp-sourcedeps/download-cache".20:13
sixstringIn hg world, I'd just blow away that directory and re-clone it. Any bzr advice?20:13
sixstringBTW, the bash mojo in rocketfuel is impressive.20:14
sixstringOK, I'll try this: (1) mv ~/launchpad ~/launchpad-busted (to get it out of the way) then (2) re-run rocketfuel-setup.20:21
sixstringThat seemed to work.20:27
sixstringI don't suppose there's a log-bot logging this stuff for posterity?20:27
=== matsubara is now known as matsubara-afk
=== jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 247 - 0:[#######=]:256
LPCIBotYippie, build fixed!22:54
LPCIBotProject devel build #948: FIXED in 5 hr 50 min: https://lpci.wedontsleep.org/job/devel/948/22:54
wgrantwallyworld: You said you had a better bzr plugin?23:35
wallyworldwgrant: yes, i'll email it to you23:35
wgrantThanks. Going to submit it upstream?23:35
poolieooh, for what?23:36
wgrantpoolie: PyCharm.23:36
pooliethat'd be good to send it up to them23:36
poolieif it has significant new features maybe we can put it on the blog?23:36
wgrantwallyworld: Also, do you have any hints on setting up the project? You said to create it outside the branch, but I'm not sure how to get everything into it.23:36
wgrantThe original is already on LP (https://launchpad.net/bzr4j)23:37
lifelesswgrant: do you know why sinzui marked bug 345349 invalid ?23:37
_mup_Bug #345349: Notifications about private branch linkages sent to unprivileged subscribers <disclosure> <lp-bugs> <Launchpad itself:Invalid> < https://launchpad.net/bugs/345349 >23:37
wallyworldwgrant: the email may help. my copy of the bzr plugin has changes which i've submitted to the lp project but which have not yet been merged in23:38
wgrantlifeless: No, and the call finished like 2 minutes ago :(23:38
wallyworldwgrant: read the email first and then ping me with any questions23:38
wgrantwallyworld: Indeed, that helps a lot, thanks!23:39
wallyworldwgrant: np. it's a very terse summry. there's potentially a lot more you may need help with. but see how you go....23:39
wallyworldwgrant: also, i have debuging working when running lp inside an lxc container23:42
lifelesswallyworld: oh nice23:42
lifelesswallyworld: what did you do to make that work ?23:42
wallyworldyou have to add a couple of lines to the top of bin/run23:43
wallyworldand tweak a setting inside the debug config of pycharm to tell it to connect to a "remote" instance23:43
wallyworldlifeless: you did realise we were talking about pycharm? i'm not sure about debugging using pdb etc23:45
lifelesswallyworld: yes, I did23:46
wallyworldcool, just checking :-)23:46
=== wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld* (jtv) | Critical bugs: 247 - 0:[#######=]:256
wgrantwallyworld: Should I create a separate empty directory for the project?23:56
wgrantI can't find a way to add external stuff.23:56
wallyworldwgrant: yes, in my case, i created a ~/PyCharmProjects directory and saved the lp project there23:57
wallyworldthen you can got o settings->project structure and add a content root23:58
wallyworldthe content root is your working tree23:58
wgrantAhh, thanks.23:58
wallyworldand from there you mark stuff as sources and exclude things as per my screenshots23:58

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!