[05:11] <poolie> cinerama, https://bugs.launchpad.net/bzr/+bug/255687
[06:02] <wgz> still dark outside...
[06:02] <AuroraBorealis> its dark outside here too!
[06:06] <poolie> hi wgz
[06:06] <poolie> beautiful day here
[06:13]  * fullermd searches around to find a window, and discovers darkness there too....
[06:14] <wgz> :)
[06:14] <fullermd> It's like a giant plague, taking over!  It probably covers half the world by now   :(
[06:37] <wgz> okay, nearly time for bus
[06:38] <wgz> cow-orking today.
[06:39] <poolie> oh great
[06:39] <poolie> i'm out for a bit to play squash, probably back later
[06:48] <jam> poolie: i think I mentioned earlier, but they put a 1hr inetd timeout on savannah, i believe.
[06:49] <jam> I don't think it is from bzr, I think it is from their configuration.
[06:49] <jam> morning all
[07:45] <Pegasus_RPG_> Hello. I just wanted to find out what the best way of moving/copying a bzr checkout to another PC is?
[07:45] <Pegasus_RPG_> (I'm on a slow Internet connection and don't want to have to check it out again)
[08:07] <mgz> good morning.
[08:10] <mgz> kirkland deserves some praise, fix up etckeeper in oneiric from yesterday
[08:23] <poolie> hi mgz, jam
[08:23] <poolie> jam, oh it kills it after an hour regardless?
[08:23] <jam> poolie: I'd have to track down the original message, let me check
[08:25] <jam> https://bugs.launchpad.net/bzr/+bug/824797
[08:25] <jam> I may have just been confused
[08:25] <jam> because he closed the connection himself after 1 hour
[08:34] <poolie> i think that's imapd, or maybe inetd, closing it
[09:25] <cjwatson> hey, I'd like to have a working Debian dpkg import today for Ubuntu precise opening, and apparently it's blocked on bug 714622
[09:26] <cjwatson> I've deleted the 1.16.0~ubuntu8 tag from the natty branch, since AFAICS it doesn't correspond to anything that was ever accepted into the archive
[09:26] <cjwatson> could somebody please requeue it and see if that's enough to fix this?
[09:30] <poolie> hi cjwatson
[09:30] <poolie> i'll do that now
[09:30] <poolie> mgz: hi meet cjwatson
[09:31] <mgz> hi cjwatson!
[09:31] <cjwatson> heya
[09:32] <poolie> cjwatson: do you mean 'an import of dpkg itself'?
[09:35] <cjwatson> I mean package-import
[09:35] <cjwatson> http://package-import.ubuntu.com/status/dpkg.html
[09:35] <cjwatson> sorry for slow response, I'm doing Ubuntu 11.10 publishing
[09:37] <poolie> it's running now
[09:38] <poolie> btw multi-tarball inputs should be supported fairly soon
[09:43] <poolie> cjwatson: it seems to be failing on
[09:43] <poolie> AssertionError: ('steve.langasek@linaro.org-20110325000519-s1f74q0j9esmvs1s', '0d73da5a0af194cfc458d9ec624b6f42209f35f7') != (u'james.westby@ubuntu.com-20110324170447-1m0lwg8kvwt6yfli', u'c7a0e118cb0af317cf3e7af7874192fa4c405d0a') for dpkg 1.16.0~ubuntu6 in natty, something has changed
[09:44] <poolie> could that be a similar problem?
[09:45] <cjwatson> hmm
[09:45] <cjwatson> ok, I'll have another look in a minute, worst case is deleting a tag likely to solve the problem?
[09:46] <poolie> it seems possible
[09:46] <cjwatson> hmm
[09:47] <cjwatson> I don't see the latter revision id in either lp:ubuntu/dpkg or lp:ubuntu/natty/dpkg
[09:47] <cjwatson> where might it be coming from?
[09:47] <poolie> hm, let me see if i can work out more
[09:49] <poolie> cjwatson: i'll try a full reimport
[09:53] <cjwatson> poolie: um
[09:53] <cjwatson> poolie: will that trash existing revision ids?  we are actually using lp:ubuntu/dpkg
[09:53] <cjwatson> definitely don't want to lose that
[09:54] <poolie> i killed it
[09:57] <jam> cjwatson: the 'latter' revision_id is probably the one the package importer stores in its sql database tracking what has been imported.
[09:57] <jam> It is the one that the importer had imported to match the given debian revision.
[09:57] <jam> well, ubuntu revision, obviously :)
[09:59] <jam> lifeless: you mention that nose is evil, do you have a recommended test runner?
[09:59] <cjwatson> is it possible to excise that, or would that cause other problems?
[09:59] <jam> cjwatson: it is possible, though I don't specifically know a way that isn't hacking the sql database directly.
[10:00] <jam> lifeless: I'm trying "py -m testtools.run" but it is a bit wonky
[10:00] <jam> like '-v' for verbose doesn't do anything, etc.
[10:01] <poolie> i think we do need to excise them, and that would be a good fix for this
[10:01] <lifeless> jam: I usually use testr
[10:01] <poolie> cjwatson: i need to go and get S from uni in a bit, but jelmer and mgz will be here soon and may be able to fix it
[10:02] <lifeless> jam: which builds on py -m subunit.run
[10:02] <lifeless> (which extends testtools.run)
[10:02] <poolie> or maybe maxb?
[10:02] <cjwatson> ok, thanks
[10:03] <maxb> I can look at it at lunchtime
[10:03] <maxb> (London lunchtime, that is)
[10:04] <poolie> thanks
[10:04] <mgz> cool, I'm not sure which bits to poke with package stuff yet
[10:04] <poolie> maybe max can tell you about it
[10:18] <poolie> night all
[10:19] <mgz> night poolie.
[10:34] <jam> night poolie
[10:34] <jam> mgz: so, after tons of bug filing I found the problem :)
[10:34] <jam> (why I was running more tests)
[10:34] <jam> the old, non-scenario code was using mixins, of the form class TestsForX(Mixin, TestCase)
[10:35] <jam> and I accidentally had the same "TestsForX" class name in two places.
[10:35] <jam> So scenarios really did give me better coverage, as it is a lot harder to make the mistakes you can make with mixins
[10:35] <jam> figuring that out was very clumsy with the bugs I ran into.
[10:37] <mgz> jam: ha, that's actually really interesting
[10:39] <jam> mgz: also, if I use the 'load_tests' hook, then 'discover --list' works correctly, since the suite of tests is determined at load time, rather than at run time.
[10:39] <jam> but -v is still broken, etc.
[10:39] <jam> (and I had to patch --list to make it work :)
[10:42] <jam> mgz: also lots of other oddities. Like testscenarios.TestWithScenario inherits directly from unittest.TestCase rather than testtools.TestCase
[10:43] <jam> which matters when you try to run with --verbose
[10:43] <jam> because TextTestRunner uses test.shortDescription() to determine what name to print
[10:43] <jam> and unittest.TestCase returns the docstring or nothing
[10:43] <jam> (thus using str(Test) for the representation)
[10:43] <jam> while testtools.TestCase returns self.id() as the short description
[10:43] <jam> so TestWithScenarios was doing the multiplying correctly, but it wasn't showing the new test ids.
[10:44] <jam> because str(test) wasn't changing.
[10:45] <Mez> I'm currently reviewing our internal code hosting stuff for bzr.  Anyone know of any tutorials for a decent setup (pref with stuff like hookless emails etc) or a good way of working within a team?
[10:45] <Mez> What we've got a the moment is a kind of "mish-mash" repository (basically bzr+ssh) and was wondering if anyone knows a better way of doing it.
[10:46] <Mez> I'd use something like LP's code-hosting if it wasn't a proprietary development
[10:48] <cjwatson> canonical-bazaar / LOSA: Please stop the package importer for Oneiric
[10:48] <cjwatson> (per http://wiki.ubuntu.com/ReleaseProcess)
[10:48] <gnuoy> cjwatson, ok, I'll take a look
[10:50] <Riddell> Mez: launchpad is open source
[10:51] <Mez> Riddell: indeed it is - however - it's not exactly the best solution for us as a whole.
[10:52] <lifeless> Mez: thumper made a standalone lp based codehosting system
[10:52] <Mez> If it were easy enought to pull out the code-hosting stuff on it's own, that'd be fine - but the rest of it would just get in the way (and the setup/dependencies to get LP running locally is a bit of a pain)
[10:52] <Mez> lifeless: oh, cool - that's exaclty the kind of response I wass hoping to hear :)
[10:54] <lifeless> its designed for school projects and soon, but should be close enough to consider
[10:54] <Mez> yeah - just looking over it now.  I have a feeling that I might even be able to contribute to it.
[10:56] <Mez> (Mainly, I see the ability to add stuff like code review/merges/pqm-esque stuff)
[10:56] <Mez> (I do like LP's Pqm-esque stuff)
[10:56] <mgz> jam: do you know how to stop the package importer for Oneiric as cjwatson asked?
[10:57] <mgz> gnuoy and I are... not completely sure what to do
[10:57] <cjwatson> james_w should but probably isn't up yet
[10:58] <james_w> hi
[10:58] <cjwatson> aha
[10:58] <james_w> I wish I wasn't :-)
[10:59] <james_w> mgz, gnuoy, it's mass-import on jubany, it has an init script
[11:03] <mgz> cjwatson: done (with more than a little help :)
[11:04] <cjwatson> thanks!
[11:08] <lifeless> Ran 23 tests in 4.600s
[11:08] <lifeless> OK
[11:08] <lifeless> bah
[11:24] <ccxCZ> Mez: I plan to do something like codehosting system eventually, basically by integrating bzr, sphinx, roundup and buildbot
[11:25] <ccxCZ> lightweight, componentized & extensible
[11:25] <ccxCZ> but it will take some work, mainly on the sphinx front I think
[11:26] <Mez> ccxCZ: actually - sloecode looks promising - however, I think zope is broken in Oneiric.
[11:27] <Mez> http://paste.ubuntu.com/707279/
[11:32] <ccxCZ> not zope, just older zope.interface than paste requires it seems
[11:32] <ccxCZ> either upgrade or use different wsgi launcher (I use uwsgi)
[11:33] <ccxCZ> zope.interface is independent of the rest of zope and used by other projects aswell, eg. twisted
[11:36] <mgz> okay, looks like the basic idea of the morning works: <http://pastebin.ubuntu.com/707284/>
[11:37] <mgz> I shall now go and have lunch
[12:08] <awilkins> qbzr diff viewer ; any way to make the view options sticky or preconfigure them?
[12:09] <awilkins> Specifically I want to make "ignore whitespace" sticky because the project team I'm working with have annoyingly different whitespace settings in their IDEs (yes, I should just slap them, but that's not an option. Sadly.)
[13:06] <mgz> awilkins: you can pass the option on the command line to qdiff, but I don't think there's a conf option for it
[13:07] <mgz> awilkins: could file a bug against qbzr for that, but really sounds like you need to do some slapping
[13:08]  * fullermd is occasionally irritated at the unconfigurability of qdiff too.
[13:08] <fullermd> If I used it more often, I'd have local hacks sitting around in the code like there's no tomorrow.
[13:12] <mgz> I think there's some blame for bzrlib for various parts not quite being flexible enough for reuse in a gui
[13:14] <awilkins> Alas, I can only limit my slapping to people I manage
[13:16] <awilkins> These are the guys who thought they were OOOO so clever to sit around wasting hours discuss code formatting standards and then don't stick to a consistent IDE config (as predicted by Yours Truly - the only config you should use is the DEFAULT one)
[13:16] <awilkins> Unless your IDE is clever enough to infer formatting rules from the files it opens (which Eclipse isn't, apart from line endings, it seems)
[13:19] <fullermd> If you just converted to APL, you wouldn't have to worry about formatting rules...
[13:24] <jay567> hi
[13:25] <jay567> i need to install from source, but i don't find the right download
[13:29] <mgz> under downloads on launchpad, the last one should always be a .tar.gz source package
[13:29] <mgz> eg, https://launchpad.net/bzr/+downloads
[13:30] <mgz> *ie
[13:32] <jay567> thank you, i didn't see the right bar, thought it would have to be under 'code'
[13:49] <jay567> there i am again... the downloaded package says python 2.6 needed... on the pages all i've seen is 2.4, whioch i have to work with
[13:49] <mgz> you need 2.3 then jay567
[13:50] <mgz> bzr-2.3.4.tar.gz same page, further down
[13:51] <kirkland> mgz: ;-)  thanks
[13:52] <jay567> :)
[14:10] <jay567> next obstacle: ImportError: No module named distutils
[14:10] <jay567> in setup.py
[14:14] <mgz> jay567: ...do you have a full python installed, or just a core system package?
[14:15] <mgz> distutils is part of the standard library and should be packed in "python"
[14:15] <jay567> i want to run bazaar on a server of my university...
[14:16] <jay567> maybe i can get them to install some modules for me...
[14:16] <mgz> and you have no ability to request packages?
[14:17] <mgz> if they can give you a working python (and ideally some build tools, pyrex and gcc), then you can do a user install of bazaar
[14:17] <mgz> or they might just be able to install the bazaar package for you.
[14:19] <mgz> jay567: as a final option, you may be able to get away with not having bazaar there as you can still work over sftp for instance
[14:22] <jay567> what do you mean by user install? isn't this what i tried? (python setup.py install --home $HOME)
[14:23] <fullermd> Well, you can run it in place without installing.  Though you may not even be able to build the C extensions without distutils, so you may be stuck with the slower pure-python variants...
[14:24] <mgz> jay567: yes, that kind of thing.
[14:26] <mgz> as fullermd says, you can get away without using install at all, but without the extensions you may not be better off then you would be just treating the server as a filesystem where you can put branches
[14:27] <fullermd> Well, even without the extensions, I'm sure using it for bzr+ssh would beat the crap out of sftp, unless the server itself is mind-zonkingly slow and very [network-topologically-] close by.
[14:27] <fullermd> Dumb servers are occasionally a necessary evil.  But they're way more the short word than the long one   :p
[14:27]  * mgz defers to the greater wisdom
[14:27] <jay567> ;)
[14:27] <jay567> ehm
[14:28] <fullermd> (it's not greater wisdom; I just take any excuse to say "mind-zonkingly", 'cuz it's way fun.  You should try it sometime.)
[14:29] <fullermd> Try just running 'gmake' in the dir, see if it can do enough to build the C extensions.  I'm betting 'no', sadly...
[14:29] <jay567> so if i commit to a 'server', my local bzr calls the server-bzr via ssh... yes?
[14:30] <jay567> gmake and make just return the distutils error
[14:30] <fullermd> There are a lot of variations, depending on details of your setup.  But in practice I'd say 'no'.
[14:30] <fullermd> Just think of the server and your local as separate branches, that you sync up occasionally (probably only working on one side at a time)
[14:30] <fullermd> So you commit locally, then you 'push' to the server, which calls that bzr over an ssh channel.
[14:30] <jay567> yes
[14:31] <fullermd> Yeah.  Figured.  Sounds like a pretty wacked out python install to not have distutils though.
[14:31] <jay567> i think they are pretty afraid of the students, every student from the computer science faculty has a shell account there
[14:32] <fullermd> As well they should be   :p
[14:32] <mgz> jay567: try asking nicely for a proper python and build tools.
[14:32]  * fullermd remembers being a CS student once, and it would be a pretty dumb staff/prof who wasn't scared to death of him   :p
[14:32] <jay567> :P
[14:33] <jay567> so, what do I need to do to get the 'push' working? tell my local bzr where to find the bzr binary on the server?
[14:35] <fullermd> Well, there's an env var I'd have to look up to give the remote path.
[14:35] <fullermd> Easier probably just to put it in your $PATH though.
[14:35] <jay567> yes
[14:35] <fullermd> You could e.g. have a ~/bin/bzr symlink that points to ~/src/bzr-a.b.c/bzr
[14:35] <fullermd> (assuming ~/bin/ is in your path of course.  But naturally it is, surely)
[14:36] <jay567> i see
[14:37] <fullermd> It should Just Work(tm) then.  With the python fallbacks, so slower in various operations than would be possible otherwise, but it'll work.
[14:38] <jay567> i don't thnk performance is a big issue
[14:49] <jay567> where do i put the config files in this case?
[15:09] <james_w> and there is precise :-)
[15:09] <james_w> the package importer has just seen it and created all the jobs to create the branches, it will get to them when it is started again
[15:16] <mgz> james_w: should be be started again?
[15:16] <mgz> *it be
[15:17] <james_w> we should get notification when they are ready for it
[15:17] <james_w> I expect it could be started now, but let's wait
[16:21] <slangasek> jam, poolie: as far as bug #714622 is concerned, I think the correct course of action for *all* the affected packages is to take the revid currently on the branch as authoritative... bad form as it may be, if someone has bzr push --overwritten (or otherwise changed the tag), they've done so for a reason.  As long as someone's doing db surgery, could you do so for the other 48 affected packages on http://package-import.ubuntu.com/status/ ? :)
[16:21] <slangasek> (this would help me for sysvinit in particular)
[16:31] <CaMason> Hi guys. How can I 'merge' / squash 2 commits into one?
[16:43] <jelmer_> CaMason: "bzr uncommit; bzr uncommit; bzr commit -m "Commit message for the squashed commit"
[17:32] <jelmer_> wgz: hi
[17:36] <wgz> jelmer: hi, just back from cow-orking
[17:37] <wgz> I see from your summary page the builddeb test tweak worked for maverick and natty
[17:37] <jelmer_> wgz: did you perhaps request a rebuild for bzr-builddeb?
[17:37] <jelmer_> I'm a bit surprised by the upload error
[17:37] <wgz> have you got a bug for the other lucid failures? I guess it's some known issue with the debian helper script not existing in that ancient a release?
[17:37] <wgz> jelmer: nope, I shouldn't have touched any buttons
[17:38] <jelmer_> wgz: I've fixed those I think
[17:38] <jelmer_> http://people.canonical.com/~jelmer/recipe-status/bzr.html
[17:39] <jelmer_> I had to backport cython for hardy as well
[17:39] <wgz> ha, I see what you mean about the 'failed to upload'
[17:40] <wgz> is that not just something about today being release day?
[17:40] <jelmer_> wgz: that usually happens when somebody hits the "Request a build" button
[17:40] <jelmer_> and the same version gets built twice
[17:40] <wgz> (looking at the <https://code.launchpad.net/~bzr/+recipe/bzr-builddeb-daily> page)
[17:41] <wgz> right, food time for me.
[21:48] <maxb> Anyone know why the UDD importer is not running?
[21:49] <wgz> I stopped it.
[21:50] <wgz> and james_w said "let's wait" when I asked about restarting after the release was done.
[21:50] <wgz> it may well now be time to start it again.
[21:52] <wgz> if you have any idea, please say maxb :)
[21:52] <maxb> I'm not clear why it needed to be stopped at all?
[21:53] <maxb> cjwatson was asking about getting the dpkg import fixed today, but I'm confused, as it appears to have last run successfully
[21:54] <wgz> after that, another item on his checklist for the release was to stop the Bazaar importer
[21:54] <wgz> ...I don't have any more information than that, I'm afraid
[21:56] <maxb> Oh, wait, it'll be so it's not trying to do stuff whilst LP's branch-distro.py process is executing
[21:57] <james_w> exactly
[21:59] <james_w> we don't want to be pushing up branches for the new series before that has run, otherwise it will lead to a huge increase in storage used
[22:00] <wgz> what's the run time on that? :)
[22:00] <james_w> 18397 outstanding jobs
[22:00] <james_w> it
[22:00] <james_w> it's around 18 hours IIRC
[22:01] <maxb> Hmm - the web UI currently says precise has no packages
[22:01] <james_w> jam, thanks for the package import status notifications on branch, it's very nice to have
[22:02] <maxb> Does that mean the initialize-from-parent / branch-distro stuff is not under way yet?
[22:03] <james_w> maybe there was a bug in i-f-p, let me check my scrollback
[22:05] <maxb> I suspect a cache of some kind, looks like only the counts on https://launchpad.net/ubuntu/precise are zero
[22:07] <maxb> there are definitely publications for precise - which explains the UDD queued jobs, actually
[22:08] <james_w> maxb, yeah
[22:09] <james_w> seems like there were some problems with publishing, but I can't tell if they were resolved
[22:09] <james_w> the people in question left for the day though, so it may be completed tomorrow
[22:09] <james_w> branch-distro has been started though
[22:25] <poolie> hi all
[22:27] <wgz> hey poolie
[22:30] <jelmer_> hey poolie, wgz
[23:52] <poolie> hi there
[23:53] <Riddell> morning poolie
[23:54] <poolie> hi there
[23:54] <poolie> can anyone update me on the udd importer?
[23:55] <poolie> i guess there is scrollback, perhaps i'll just read that