[00:25] thumper: :) [00:52] can anyone remember how to get local mail delivery working? [00:52] for the dev environment [00:53] apt-get install postfix isn't it? [00:53] i don't think there's anything special to do [00:54] I just use postfix with its stock local config. [00:54] Then redirect root's mail to my user. [00:55] And point Evo at my mbox. [00:57] wgrant: do you use a .forward file? [00:57] * thumper can't recall [01:00] best not to install new software while a distro upgrade is in progress [01:00] you know [01:00] parallel dpkg would be fun [01:01] hmm postfix is installed [01:01] as would fine grained locks [01:01] thumper: I just use /etc/aliases === jelmer_ is now known as jelmer [01:03] hmm, my local postfix install didn't generate a main.cf [01:03] dpkg-reconfigure postfix [01:04] postconf -n >> main.cf ;-) [01:09] * thumper thinks of something that will generate an email to test [01:10] mail -s foo [01:10] also [01:10] exim! [01:10] telnet localhost 25 [01:11] spm: ooh hardcore [01:11] heh, more like being on hardened firewalls... :-) [01:19] spm: do you know about postfix setup? [01:20] thumper: that'd be a yes. getting rusty; but yes. [01:21] in 2001, spm updated ~ 25+ firewalls and rather horrible mail funnel from sendmail to postfix. only 1 (minor) mess in the entire process. whee! [01:21] spm: I'm trying to get my local postfix to route email through my servers config using the submission port [01:22] my email client sends email through penhey.net:587 [01:22] hmm... [01:22] perhaps I'll try something else [01:24] thumper: Why do you want it sent externally, to pollute your real mailbox? [01:24] I was just thinking about that [01:24] perhaps just relay into local user mail [01:24] It's what I do. [01:25] thumper: exim can do it trivially [01:25] :P [01:25] * lifeless flogs the horse some more [01:25] wgrant: what do you read your local email with? [01:26] thumper: Evolution. [01:26] I use it for my normal mail too, though. [01:26] * mwhudson reads launchpad mail with mail(1) [01:30] spm: how to I remove a deferred email from the postfix queue? [01:31] thumper: sorry - mid debugging a U1 problem. one sec. [01:32] thumper: postsuper -d [01:33] where the hell is the default mailbox? [01:33] /var/mail ? [01:33] * thumper looks [01:33] thumper: /var/spool/mail/root [01:33] Also /var/mail. [01:36] gah, kontact still won't see it [01:36] I can see the mail in the file [01:38] * thumper shakes his head [01:39] haha [01:39] spam caught it [01:40] rofl [01:40] PEBKA.... spam filter [01:44] grar, another stable->db-devel conflict already [01:49] hmm... I wonder if I should boot into gnome rather than kde when lucid starts here... === ]reed[ is now known as [reed] [02:30] hmm [02:30] lucid decided to uninstall postgre 8.3 and python 2.5 [02:31] Yeah, they're gone. [02:32] reenable the launchpad ppa and install launchpad-developer-dependencies [02:32] Reactivate the ~launchpad PPA, and install lp-dev-deps again. [02:32] Damn. [02:32] :) [02:34] Is ReviewerSchedule out of date? [02:34] I don't think jml is in APAC any more. [02:34] well... [02:34] the default font for my irc client is much smaller :) [02:36] And al-maisan is no longer around. [02:36] And there have been no European reviewers since Monday night, although that might be special for this week. [02:50] thumper: interesting discovery [02:50] thumper: the kernel import has imported about 140 megs of packs so far, which sounds about right [02:50] thumper: the git.db file though is a hair under 6 GIGABYTES [02:51] which suggests something is going a bit wrong [02:51] Is that why it is so damn slow? [02:51] who knows [02:51] it doesn't sound very helpful though [02:51] 'taking 26 hours' <- niiiiice [02:52] Hm. Isn't the topic out of date, and it's in fact week 3 of 10.03? [02:52] Even pear looks like it's going to take about 14 hours. [02:52] StevenK: I think so. === mwhudson changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 3 of 10.03 | PQM is in open | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | [02:52] mwhudson: :-) [02:52] StevenK: don't know what you're talking about!! [02:54] mwhudson: OMG [02:54] thumper: indeed [02:55] mwhudson: where is jelmer_ when you need to smack him around a bit [02:55] well gnome wasn't pleasent [02:55] thumper: he knows, at least [02:55] it killed x [02:55] gwibber wouldn't start [02:55] and made gdm take over instead of kdm [02:56] * thumper has punted the little blighter back into his corner [02:56] back into kde now [03:01] Hm. What do I do if I see a typo in a branch which I didn't notice until it landed? :-( [03:05] The typo is in a debug print, but I suspect it may throw an exception when it's run. [03:06] StevenK: submit a branch to fix it [03:10] * thumper is reinstalling launchpad-developer-dependancies [03:10] somehow it got lost [03:11] thumper: Perhaps it got lost when the upgrade was removing obselete packages? [03:11] StevenK: probably [03:11] * thumper shurgs [03:11] Hm. How does one shurg? [03:11] it is like shrugging, but different :) [03:12] :-) [03:14] * thumper afk [03:15] mwhudson: Would you mind reviewing the change, it's a one-line patch [03:15] StevenK: sure [03:15] mwhudson: https://code.edge.launchpad.net/~stevenk/launchpad/fix-typo-for-bug-503258/+merge/22098 ; but you'll need to wait for the diff [03:21] Which has turned up [03:21] StevenK: is this covered by tests? [03:21] mwhudson: I could have sworn it was -- which is why I'm a little concerned how it got landed [03:21] hmm [03:23] mwhudson: The original branch (fixes-bug-503258) changes the test to make sure that custom files are not private [03:24] StevenK: ah [03:24] StevenK: want to add a test then? [03:25] Is debug printing on when running under a test? [03:25] StevenK: it doesn't matter does it? [03:25] debug(1, foo.bar) will blow up if foo doesn't have a bar attribute [03:25] no matter what debug does [03:26] mwhudson: It's a string subst, though [03:27] StevenK: even more so then [03:34] Dear bin/test, plz output debug output [03:38] mwhudson: Ah ha! It just prints the wrong filename, but doesn't error [03:38] (Un)lucky. [03:39] StevenK: heh heh [03:39] AttributeError: 'PackageUploadCustom' object has no attribute 'filename' [03:39] * StevenK grumbles [03:39] So even my fixed branch is broken [03:40] Which does fail the tests, excellent [03:44] * wgrant applies an axe to buildd-slavescanner.txt. [03:46] mwhudson: Do you need to re-rubber-stamp the branch now that I've fixed it so that tests actually pass, or shall I land it? [03:47] StevenK: i'll have another look quickly [03:47] mwhudson: It's pushed, so you should be able to see it [03:49] StevenK: +1 [03:49] land it [03:49] Aye, doing so === flacoste is now known as flacoste_afk [05:46] wheeee vm installs fly [06:53] stub: ping [06:53] thumper: pong [06:53] stub: my lucid upgrade installed postgres8.4 and removed 8.3 [06:53] stub: I have 8.3 back from lp dev deps [06:53] stub: but I've lost all my setup [06:54] stub: should I remove 8.4? [06:54] It did? Mine didn't, but I had both 8.3 and 8.4 installed. [06:54] stub: also, I can't find the database setup code [06:54] You can leave it. You can even use it - the tree passes and I would have loved to switch this cycle but not enough time. I just haven't announced it. [06:55] ah, ok [06:55] stub: where are the setup instructions now? [06:55] I looked in rocketfuel-setup but didn't see them [06:55] Dunno :-) Looking in the wiki now [06:56] https://dev.launchpad.net/Running says there is a script in utilities, although I've always done things manually (per the linked DatabaseSetup page) [06:56] ./utilities/launchpad-database-setup [07:02] stub: will that work with 8.3 and 8.4 installed? [07:03] IIRC it will prefer 8.4 if it finds it. [07:03] I have no idea. I've never run it myself. Should be fine though - unless someone tried hard to break things it will use whichever PG is running on port 5432. [07:04] I believe it finds the latest version and hopes that it's running on 5432. [07:05] hmm, I have 8.3 on 5432 and 8.4 on 5433 [07:06] The script looks like it should die in that case. [07:09] well that was a big fail [07:10] What died? [07:11] the setup script [07:12] failed in applying hunks [07:12] failed to create the user [07:12] failed on other bits [07:12] then said... [07:12] Looks like everything went ok. [07:12] bullshit [07:15] Hahhaa. [07:17] stub: it is all fucked! [07:20] thumper: https://dev.launchpad.net/DatabaseSetup still seems relevant and should work for 8.3. It should also work for 8.4 if you don't add 'max_fsm_relations = 2000' to postgresql.conf [07:22] stub: well, 8.4 won't start at all says it has invalid directories et al [07:23] stub: so I decided to go with 8.3 for now [07:23] however [07:23] http://pastebin.ubuntu.com/401000/ [07:24] why can't it get the working directory? [07:24] Because you're in the dropped cluster. [07:24] Because that script is destroying the directory you are running it from? [07:25] oh arse [07:26] I'll update that script for 8.4 soon anyway. I think it is how the ec2 instances get setup. [07:29] http://pastebin.ubuntu.com/401003/ [07:29] stub: ^^ [07:30] postgres8.3 says it is running [07:30] How does it say that? [07:31] :( [07:31] It might be running, but not on port 5432 [07:31] * Restarting PostgreSQL 8.3 database server [ OK ] [07:31] however [07:31] $ /etc/init.d/postgresql-8.3 status [07:31] Error: Invalid data directory [07:31] WTF? [07:31] Why not purge both, install 8.4, and run the script? [07:31] will that work? [07:32] It has for me. [07:32] Did you run step 4? [07:32] Except I installed 8.3, because LP didn't support 8.4 yet. [07:32] dropcluster,createcluster? [07:32] jtv updated the script to work with 8.4 IIRC [07:32] stub: yeah [07:33] I'd go with wgrant's suggestion as it will probably work. [07:33] ok [07:33] And even if it doesn't work, it won't get you into any worse a situation than you're in now. [07:36] ahh [07:36] 8.4 can't be removed because it fails to stop [07:36] because it has an invalid data directory [07:37] how can I force it harder? [07:37] kill it and see if it still tries to stop. [07:37] it isn't running [07:37] * thumper wonders [07:37] stub: ec2 test uses the script yeah [07:37] Make the data directory uninvalid, or hack the script to not whinge. [07:39] how do I make the data directory uninvalid [07:39] I don't know where it is looking [07:39] 'valid' [07:39] the word is 'valid' [07:39] lifeless: Well, I didn't want to take it that far. [07:39] It probably doesn't need to be a valid postgres data dir. It just needs to not look completely invalid. [07:40] wgrant: so, appear valid :P [07:40] Pfft. [07:43] stub: any idea how I can get 8.4 unfucked? [07:43] I'm losing patience rapidly [07:43] killall postgres ? [07:44] done [07:44] but the --remove triggers a stop, which fails [07:44] which stops the --remove [07:44] --remove? [07:45] sorry [07:45] sudo aptitude remove --purge postgresql-8.4 [07:45] that is what fails [07:46] Removing postgresql-8.4 ... [07:46] * Stopping PostgreSQL 8.4 database server * Error: Invalid data directory [07:46] Kill the processes, nuke /etc/postgresql, nuke /var/lib/postgresql [07:46] And file a bug if you can be arsed [07:46] stub: do you think the uninstall will work then? [07:47] Should. There are no config files to know what to shutdown. [07:52] * thumper thrashes the HDD [07:54] stub: aptitude tells me that postgresql-8.3 is installed, but there is no /etc/postgresql [07:54] I nuked it before [07:55] Sounds like aptitude didn't do some setup step. Or maybe its the 8.3 packages on lucid - I thought you where going to use 8.4? [07:56] Hmm. If you purged (not just removed) postgresql-8.3, postgresql-8.4 (and maybe postgresql-common), that directory should have been recreated on installation. [07:57] if I try to remove postgresql-8.3 it removes all the launchpad developer deps [07:58] With synaptic, it would remove the launchpad-developer-deps packages sure. But not the rest of the deps. [07:59] aptitude did, apt-get won't [07:59] stub: Regarding that EmailAddress issue, USSO was creating them until recently. Bug #523346. But I thought they fixed the data too. [08:01] stub: so if I install the 8.4 packages for slony, contrib, and plpython I should be good? [08:02] stub: 8.4 didn't add a /etc/postgresql directory either :( [08:03] stub: before when you said nuke, I just moved them to /junk [08:03] stub: could that matter? [08:03] You can run pg_createcluster yourself per the wiki docs, but something is screwed [08:03] I don't see how that could matter [08:04] it is creating the 8.4 cluster now [08:04] the launchpad database setup script needs to be run as root? [08:05] I expect so, unless it uses sudo internally [08:05] it uses sudo internally [08:05] just checked [08:06] I think I'm getting somewhere [08:06] making schema [08:06] on 8.4 [08:07] ok [08:07] work done for me [08:07] I think I'm up to a working launchpad environment on lucid [08:07] stub: thanks for your help [08:07] and wgrant [08:08] Hopefully there's still only that one test failure. I might run the whole suite again tonight. [08:11] wgrant: Which test failure? [08:11] StevenK: test_generateConfig in Soyuz. [08:11] apt-ftparchive outputs extra hashes. [08:11] s/Soyuz/archivepublisher/ [08:12] Ah. I just had test_mark_duplicate_form_overlay fail for me, thought it was related [08:13] There was a commit related to that this morning. [08:17] * wgrant WTFs at builder.txt. [08:53] Ah. [08:53] I was wondering why the start of builder.txt was so shocking. [08:53] annotate shows that it hasn't been changed significantly since around r6000. [08:53] Er. [08:53] r600. [08:54] :D [08:55] * wgrant throws a quick rewrite into another branch that touches that file. [09:09] bigjools: buxy himself visited earlier and asked that we enable 3.0 (quilt) in Karmic. I discussed this with some distro people a few weeks ago and they tended to agree. [09:09] The worst that will happen is that builds will fail if they use one of the couple of things that Karmic's dpkg doesn't support. [09:09] wgrant: sounds fine then [09:11] * bigjools considers firewalling all IPs from China, Russia and South America [09:11] bigjools: Should I poke a LOSA with instructions, or ...? [09:11] bigjools: Good idea. [09:12] bastards DoSing me trying to crack my ssh [09:12] denyhosts FTW. [09:12] yarp [09:13] 235 jobs (30 hours) [09:13] WOW. [09:13] I am glad I haven't tried to use a PPA lately. [09:13] I auto-drop after 3 failed attempts but it still screws my connection [09:13] builders removed, it'll come back [09:14] Um, 30 hours is really quite ridiculous and calls for drastic action. [09:14] it's not ideal [09:15] Waiting more than a day for a build is well beyond not ideal. [09:18] wgrant: umm anyway yes if you prepare some SQL I'm sure we can get a losa to poke it in [09:18] bigjools: OK. Thanks. [09:18] * wgrant works it out. [09:26] did anyone see https://bugs.launchpad.net/bugs/546017 ? [09:26] Bug #546017: can't add linux-meta-ti-omap to kernel/lucid package set [09:29] LOSAs: Can you please run this query on production to enable 3.0 (quilt) and 3.0 (native) in Karmic? [09:29] INSERT INTO sourcepackageformatselection (distroseries, format) SELECT id, 1 FROM distroseries WHERE name='karmic' UNION SELECT id, 2 FROM distroseries WHERE name='karmic'; [09:29] bigjools: Yeah, that's an odd one. [09:30] Although I don't see that source. [09:30] wgrant: can you pastebin that query, I need to get permssion from da management [09:30] wgrant: I'd need approval from someone (BjornT?) to run that on production [09:30] Ah, of course. [09:30] * wgrant pastes. [09:31] http://pastebin.ubuntu.com/401051/ [09:31] ta [09:31] I ran it on dogfood anyway [09:34] bigjools, wgrant: why is that query needed? [09:34] BjornT: I just updated LPS [09:34] BjornT: See scrollback starting from 25 minutes ago [09:36] wgrant: i prefer short summaries :) [09:36] Well, the relevant scrollback is two lines. [09:36] 20:09:24 < wgrant> bigjools: buxy himself visited earlier and asked that we enable 3.0 (quilt) in Karmic. I discussed this with some distro people a few weeks ago and they tended to agree. [09:36] 20:09:40 < wgrant> The worst that will happen is that builds will fail if they use one of the couple of things that Karmic's dpkg doesn't support. [09:37] BjornT: there's a short summary in LPS ... [09:39] wgrant: well, finding two lines in 25 minutes of scrollback isn't that easy, if you don't know which lines to look for [09:40] thanks bigjools [09:40] True. [09:42] approved [09:42] Thanks. [09:49] thanks BjornT [09:49] owdy [10:07] Morning, all. [10:08] buildd-slavescanner.txt creates builder1-11, sticks them in buildergroup.builders, and then does nothing further with buildergroup. [10:09] Before my branch it does touch buildergroup, but only to call rescueBuilderIfLost, which doesn't touch that .builders at all. [10:09] So there's a whole lot of dead tests code there that looks potentially important. [10:10] wgrant: is it possible that the actual tests have been gradually moved out over time, leaving just the test setup there? [10:10] noodles775: I hope so. [10:11] It looks like it might now create other equivalent builders as it goes. [10:12] The functionality does seem to be tested elsewhere, so I guess the creations and assignments can go. [10:13] Great. [10:13] (I'm removing buildergroup, so needed to do something with them) === dpm is now known as dpm-bbl === magcius_ is now known as magcius === magcius is now known as magcius_ === magcius_ is now known as magcius [10:59] stub: Still around? [10:59] yo [11:01] stub: Ohai. Can you cast your weather eye over this query and tell us if it's completely mad?: http://pastebin.ubuntu.com/401091/ [11:01] stub: We want to use it to schedule the next_check of a bug watch based on the number of errors it has had over the past 5 attempts. [11:03] The coalesce(array( stuff seems needlessly confusing over 'count(*)' [11:04] stub: I tried with a count but it didn't work after a couple of minutes and the array stuff did, so I didn't spend any more time on it. [11:05] or sum [11:06] But fine. It actually works? [11:06] stub: Yes. In my head, I imbued that question with a tone of surprise. [11:07] Sticking a subquery in the FROM clause of an UPDATE that references the table being updated - can't recall having tried that [11:07] nm,.. not doing that [11:08] Your missing 'BugWatch.id = bug_watch.id' in the WHERE clause [11:08] sorry... BugWatch.id = counts.id [11:08] Ah yes, thanks. [11:09] You don't *have* to do it in a single query though ;) [11:10] stub: It made allenap happy so I was loathe to stop him. [11:12] stub: Another version of the array stuff with count(*) instead: http://pastebin.ubuntu.com/401099/ [11:19] * stub wonders why next_check is ever null [11:19] Wouldn't it just default to NOW and be updated after every check, successful or not? [11:21] stub: I don't completely understand. Do you mean that we should calculated at the same time the watch is checked? [11:22] stub: next_check is set to NULL by checkwatches and then updated by a garbo process. We wanted to keep the scheduling logic out of checkwatches since it's complex enough already. [11:22] ok [11:22] Not sure if that is a win, but I'll believe you :) [11:23] From our point of view, anything that makes checkwatches do less is a win :) [11:23] So how does that query work in the context of a DBLoopTuner loop? It is updating all of them at once. [11:25] That could be tens of thousands if things don't run for a few days. === jelmer_ is now known as jelmer [11:26] stub: We can run that query against a batch of BugWatch IDs. [11:27] That would fit nicely with the LoopTuner way of doing things. [11:27] ok [11:28] If you do that though, you are still materializing the recent activity list for all bugwatches each time though, even though you are only updating a batch. [11:29] Maybe PG can optimize that, but I doubt it. [11:29] Oh... you put the list of ids in the subquery [11:29] that would work [11:30] stub: I was just about to say that ;) [11:30] wgrant: karmic now accepts quilt [11:30] bigjools: Thanks. [11:30] $LOSA: Also thanks. [11:32] wgrant: I just thought, we've never pushed a source package branch through dogfood [11:32] bigjools: True. [11:32] can you think of anything that would prevent that now (apart from lack of a UI) [11:32] It should all work now. [11:32] As long as the buildd is OK. [11:32] All relevant work is long-merged. [11:32] cool - have you got a script I can steal to poke something in? [11:33] I have somewhere.. [11:33] * wgrant hunts. [11:34] bigjools: I used http://pastebin.ubuntu.com/401111/ [11:34] It probably still works. [11:35] * wgrant checks the DF configs for the right branch prefix. [11:35] ok [11:37] Hm, so plain lp:whatever should work fine. [11:41] ok I'll poke it through now [11:41] I suppose you can just use any old production package branch. [11:42] And hope that dogfood doesn't explode... [11:43] * bigjools starts ripping chunks of hair out [11:43] AttributeError: 'NoneType' object has no attribute 'utf_8_decode' [11:43] ARGH [11:43] That reappears every couple of months. [11:43] Yay. === noodles785 is now known as noodles775 [11:43] I always forget how to fix it by the next occurrence. [11:44] and every f***ing day on dogfood [11:44] make clean [11:44] Oh. [11:45] well it's only doing it on iharness atm [11:45] I guess I'll have to put up with plain harness === matsubara-afk is now known as matsubara [11:48] Is it reasonably up to date, so the UI won't burn up once the build gets dispatched? [11:50] wgrant: http://pastebin.ubuntu.com/401120/ [11:50] seen that? [11:50] bigjools: The branch you referred to probably doesn't exist on DF. [11:50] What was your recipe? [11:50] ok that makes sense, I blindly copied yours :) [11:51] lp:ubuntu/hello should work [11:51] yeah [11:53] bigjools: How old is the DF archive? [11:53] old [11:54] If it lacks a reasonably recent bzr-builder, I guess the target archive will need external dependency on production primary. [12:00] wgrant: ran the script, b-m not dispatching :/ [12:03] bigjools: The builders are all disabled... [12:03] cobblers, why didn't I check that [12:05] You probably also need to twiddle scores, but we'll see. [12:06] which I really should have done before watching gcc get dispatched. [12:06]