[05:05] hi, does anyone know how i can get a reference to the default db user? === jamalta_ is now known as jamalta [05:06] jamalta: There isn't really a default user. What are you trying to do? [05:12] wgrant: i'm writing a test that needs to create fake records to the karmacache table [05:13] so i have to switch db users to one that has write access to that tab le [05:13] table* [05:13] and i need to switch back to the regular user after i'm done [05:13] but i can't find how to get a reference to it [05:13] wgrant: you can look at the diff here https://code.edge.launchpad.net/~jamalta/launchpad/bug-127489/+merge/10785 to see what i'm doing exactly [05:14] jamalta: Ah, I see. [05:14] Let me have a look... [05:14] wgrant: Thank you :) [05:14] I got lost trying to find it [05:15] jamalta: Have a look at lp.registry.tests.test_distributionsourcepackage [05:15] switchDbUser is the magic method. [05:17] wgrant: Oh, ok.. that should work then, thanks :) [05:17] I am using config.karmacacheupdater.dbuser, so should I change it to match the way it is done in that test instead? [05:18] jamalta: Probably. It probably doesn't really matter, but most tests seem to use a literal. [05:19] wgrant: Thank you for your help, I will use that route then [08:37] hmmm, I think that makes 5 bugs submitted today [08:42] Ah, excellent. It is fairly easy to get dev primary archives set up to overlay on top of a real primary archive. That makes testing muuuuch easier. [08:49] lifeless: What's the best way to get lpnet7 kicked? [08:57] spm: ^ [08:57] try a sysadmint hat might be around [08:57] failing that I'll escalate [08:58] how long as it been down for? [08:58] lifeless: Around 1.5 hours, I'd say [08:58] Could be more. [08:59] is it still in rotation? [08:59] It is. [08:59] ok [08:59] So 502s are more frequent than they should be. [08:59] we'll give spm 5-10 then I'll ring the SA's [08:59] Great. [09:10] escalated [09:11] thought I really have to wonder just how much you're using lp that you're noticing :P [09:13] lifeless: 1/8 isn't small. [09:20] anyhoo I escalated [09:21] lifeless: Thanks. [09:21] the long suffering elmo is on the case [10:37] maxb: I still can't reproduce those failures on a clean Karmic installation. [10:37] hrm [10:37] Most puzzling [10:38] What about the "Unable to find mandatory field 'files' in the changes file." ones? [10:38] I installed it by using plain rocketfuel-setup, then adding your PPA and installing launchpad-developer-dependencies. [10:38] maxb: Those work fine. [10:39] This is quite confounding [10:39] Incredibly so. [10:39] You say you can reproduce on two systems? [10:40] certainly the DONE != ACCEPTED one [10:41] I've run that test on two machines in three configurations (one was reinstalled as another arch yesterday). [10:41] It works fine. [10:41] How strange. [10:43] Hm. I wonder if it's some bizarre interaction with something in my user account [10:44] My entire homedir is under Subversion, so the different machines are somewhat similar [10:44] Are things oddly shared? [10:44] Ahhh. [10:44] That is possibly relevant. [10:44] adduser will tell. [10:49] * maxb pondering what to chown, etc. [11:24] gary_poster: When you fix up the symlinks, don't forget to also fix up sourcecode/Makefile! [11:27] gahh, I hate shhh.py [11:30] wgrant: You didn't get bitten by Getting distribution for 'lazr.uri==1.0.1'. [11:30] Installing lazr.uri 1.0.1 [11:30] Caused installation of a distribution: [11:30] lazr.uri 1.0 [11:30] with a different version. [11:30] When doing your clean karmic test [11:30] Got None. [11:30] ? [11:30] maxb: No -- I didn't have launchpadlib installed yet. [11:31] I've since installed it (which brought along python-lazr-uri), and everything remains happy. [11:45] huh [11:45] so now even if I purge python-lazr-uri, a clean make is now impossible [11:45] ImportError: No module named uri [11:46] * maxb has breakfast instead [11:46] maxb: Impressive. [11:47] Do you have any other lazr.* installed? [11:47] eg. lazr.restfulclient? [12:06] wgrant: aha, that's it exactly [12:07] Gah. So now I have to choose whether to attempt to debug buildout or attempt to debug launchpad. [12:07] maxb: buildout is scary. Run away. [12:10] Hrm. I wish launchpad wasn't so messy in /var/tmp/ [12:13] It's not too bad. [12:13] You can blow it all away and it will be happy. [12:13] And at least it puts stuff only there. [12:16] * mwhudson isn't completely sure about that [12:17] i think some tests still scribble into /tmp [12:17] Ideally it would all go under /var/tmp/launchpad-$USER/ [12:17] (they should be fixed though) [12:17] Scribbling into /tmp/ isn't wrong, if it's genuinely temporary [12:17] WTF!?!?!? wgrant it works in my clean user [12:17] maxb: you are right about /var/tmp/launchpad-$USER/, but thinking about it makes me want to cry a little [12:18] maxb: Excellent! [12:18] maxb: Now, bonus points for working out what it was. [12:18] maxb: My first try would be copying over bashrc and the like. [12:24] maxb, wgrant: what's the problem? [12:24] gary_poster: Which problem would you like to talk about first? :-) [12:24] There are a few. [12:25] maxb: oh I dunno. Just list em for me/ [12:25] I have a couple of weird test failures that happen only for me, but on all my systems. We're now thinking that it's something in my common .bashrc or similar [12:25] huh [12:25] And, it's currently impossible to bootstrap launchpad on karmic, if you have python-lazr-* system packages installed. buildout gets confused [12:29] And, when you fix up the zope-removal properly, don't forget to look at sourcecode/Makefile :-) [12:29] grr. I spent a fair amount of time trying to make that kind of bootstrap problem go away. [12:29] and did so for all of the instances I knew about. [12:29] zope-removal: ack, I saw your ping. thanks. [12:31] so maxb, those are the 3 problems: (1) something on your system causes test failures only for you. (2) buildout's bootstrap is broken on karmic if you have lazr.* Installed. (3) I missed some things in my zope branch removal. [12:32] yup [12:33] (1) is more specifically something to do with a shared home directory [12:33] I think it's down to my .bashrc [12:33] I'm bisecting it now [12:33] maxb: I can dupe 2 and 3 on my own. Fixing 3 should be relatively easy, and once I've seen 2 hopefully I'll know what's up. 1 is harder. I see your clean user works fine. oh, shared home directory... [12:33] ok [12:34] maxb: could you pastebin me the traceback from (2) [12:34] when you get a chance [12:35] There's two flavours of (2) - if you have python-lazr-uri installed, buildout goes to install lazr.uri==1.0.1, but ends up installing 1.0 instead, catches this mistake, and aborts [12:35] Then, if you purge python-lazr-uri but still have python-lazr-restfulclient, you get a horrendous traceback with the ImportError I mentioned [12:37] I'll get pastes for both, but it'll be 15mins or so [12:38] maxb: is this during the bootstrap or the buildout? It sounds like buildout. [12:38] um, the bit where it populates eggs/ from download-cache/dist/ ? [12:38] buildout, ok [12:41] maxb: I suspect this is new because we have things packaged for karmic that are not packaged in jaunty; and our lazr packages have had some build issues. I think I've addressed all of them in branches as of this weekend--need to get some reviewed and landed. I still had hoped that we would be isolated from things like this, but oh well, I'll try again. [12:42] :-) thanks [12:44] maxb: IRT the two flavors, the first flavor is more interesting to me. The second one is kind of corollary of the first. The first problem is "Gary thought we were protected from site-packages now (we are in Jaunty), but it is still leaking." (Or lazr.uri packaging is more hosed than I thought--it's possible that it is packaged as 1.0.1 but then declares that it provides 1.0, which would explain the problem) [12:45] !info python-lazr-uri karmic [12:46] maxb: the second problem is: when you take out a dependency of a package, and you try to use that package, it breaks. :-) the only way it is related to buildout/launchpad is that I had hoped we wouldn't see those packages [12:46] we don't in jaunty :-/ [12:46] at least for the examples I have seen [12:47] I don't really understand what you mean by "when you take out a dependency of a package, and you try to use that package" [12:48] And unrelated: wgrant: So the DONE != ACCEPTED failure is apparently caused by me changing my umask from 022 to 002 [12:48] maxb: lazr.restful depends on lazr.uri. you removed lazr.uri, and lazr.restful breaks. It makes sense in isolation. [12:48] oh.... but what stopped it from trying again to install lazr.uri first? [12:48] Ah, yes, I vaguely recall having been burned by umask in the past [12:49] I'm sorry you were hit by it. Would you send an email to the list about it? Others will have more context on that than I [12:49] * maxb afk 5mins [12:49] why didn't it try to install lazr.uri? Yeah, good question. [12:50] maxb: I spent some hours this morning working out a lp-buildd umask issue... [12:50] I regard it (maybe incorrectly) as a corollary of the first one, like I said [12:50] anyway, I need to run go do family things, but maxb, these things (2 and 3, in particular; someone else may need to look at what seems to be the umask issue, maybe wgrant?) will be top billing for me. [12:52] maxb: Let's see if I can repro it. [12:56] maxb: That does the DONE != ACCEPTED one, but not the others :( [13:01] mhm, ok then [13:03] I wasn't actually running anything but that one test whilst searching for the problem, I'm trying the other two now [13:05] maxb: Ahaha. [13:06] ERROR: Queue item ignored: Bad umask; expected 022, got 002 [13:06] So, not an entirely unexpected failure. [13:07] ah... where did that vital piece of info disappear to? [13:07] maxb: The BufferLogger that the previous statement logs to. [13:07] So did it actually end up anywhere useful in a test run, or did you have to run things manually? [13:08] maxb: Had to alter the code manually. [13:09] maxb: (print logger.buffer.read()) [13:11] ok, I'm on the trail of what's breaking the uploadprocessor tests for me [13:12] Great. [13:21] riiight [13:21] so the last two are due to my ~/.devscripts [13:25] Aha. [13:26] So. [13:26] On to 2.5! [13:26] * wgrant shall try to set it up tonight. [13:31] DEBUILD_DPKG_BUILDPACKAGE_OPTS="-us -uc" <-- upsets launchpad [13:32] so I guess I need to find the appropriate place to apply a --no-conf option in the testsuite [14:32] maxb: OK, test suite running fairly happily with 2.5. I'll poke at any real failures (eg. soyuz-set-of-uploads.txt, which looks unfortunate...) tomorrow. [14:32] nice :-) [14:33] Now if I can just figure out why bzr import-dsc is barfing, I'll try to get my launchpad-dependencies branches created. [14:33] And then progress to actually preparing submission branches for some of the stuff I've accumulated in ~maxb/launchpad/python2.5 [14:34] maxb: Did you turn of shhh.py in there? [14:34] I noticed the build was fairly noisy. [14:34] yes [14:35] accidently at first, but I didn't feel like reverting :-) [14:36] Are you getting lots of "/home/wgrant/launchpad2.5/lp-sourcedeps/eggs/pytz-2009j-py2.5.egg/pytz/__init__.py:32: UserWarning: Module lazr was already imported from None, but /home/wgrant/launchpad2.5/lp-branches/python2.5/lib is being added to sys.path\n from pkg_resources import resource_stream"? [14:43] yes, and that's recent [14:44] but I think Gary's aware and has some thoughts on that one === mpt_ is now known as mpt [20:44] moin [20:54] good mornign [21:20] mwhudson: so, liking your current role? [21:20] or going whoa, where to start? [21:25] Gah. gah. gah. /me is constructing a branch for launchpad-dependencies, and has just discovered that it basically forked for dapper vs. feisty, with each branch using the same version numbers for entirely different packages [21:27] lifeless: somewhere in between those two :) [21:27] i'm glad i've got 4 weeks left, let's say [21:28] * mwhudson breaks fast [21:28] mwhudson: :P [21:28] maxb: whats the goal of this archaeology/ [21:29] morning [21:29] There is very little point. I'm just being obsessive about producing an accurate branch representing past history, if I do so at all [21:30] mwhudson: still up for a call at 9? [21:35] thumper: sure [21:55] thumper: having said that, 9:10 or so would be better [21:58] ok [22:12] Gr. [22:13] Tests that rely on set() ordering make me sad. [22:13] wgrant: KILL [22:13] thumper: call? [22:15] maxb: Dammit. I managed to run 'make check' in the same shell that I had my umask set to 002 from earlier. [22:15] :-) [22:15] * thumper nods [22:16] ah well, you know exactly what failure that causes, so no problem :-) [22:16] thumper: skype desn't think you're online, is it wrong? [22:16] mwhudson: yes, I'm trying to get to you too [22:16] maxb: I'm hoping it won't cause any others. [22:16] it didn't for me [22:17] maxb: Not even on 2.5? [22:18] Well I admit I'm conjecturing a bit, but the chances of a test being disrupted by umask on 2.5 but not being disrupted by umask on 2.4 seem vanishingly small [22:18] https://answers.edge.launchpad.net/launchpad-code/+question/81385 [23:00] hi [23:04] hey jml [23:04] spm, hi :) [23:05] hi jml [23:05] lifeless, g'day [23:05] lifeless, I had a look at your subunit filter patch last night. It looked like it deserved more concentration than I had though. [23:06] * jml fires off 4 ec2test runs [23:08] jml: thanks [23:17] thumper, hi [23:17] jml: morning [23:17] thumper, you available to talk today? [23:18] yes, at some stage [23:19] thumper, cool. when do you think? [23:19] jml: when did you want to talk? [23:19] I think all the time :) [23:19] thumper, soon-ish, so I can get on with other stuff [23:19] jml: ok, give me a few minutes to get a cuppa, then we can tal [23:19] k# [23:19] thumper, cool.