=== Ursinha is now known as _starbuck-gone
[05:05]  * poolie reads eric's patch
=== AfC1 is now known as AfC
[05:49] <poolie> hi spiv?
[05:50] <spiv> Hi poolie
[05:52] <poolie> hey, how are you?
[05:55] <spiv> A bit thwarted; it turns out I still haven't got a local reproduction of bug 653307 yet after all.  And earlier today I thought it might be interesting to quickly try make a small update to one of the lpstats graphs and didn't find the relevant code/branch among those listed in the wiki.
[05:55] <ubot5> Launchpad bug 653307 in Ubuntu Distributed Development "Import fails with missing referenced chk root keys" [Critical,In progress] https://launchpad.net/bugs/653307
[05:56] <spiv> So I set my sights a bit lower for today and have bzr-usertest passing tests again and my old outstanding network-suite branch merged with current trunk, and about to see if it still does what it's supposed to.
[05:57] <poolie> hm, i think you want lp:tuolumne-lp-configs
[05:57] <poolie> i'm doing some low fruit in kanban at the moment
[05:57] <poolie> trying to get it running more frequently and faster
[05:57] <poolie> ah i saw some action there
[05:57] <spiv> That's what I thought, but I don't see any sign of the CodehostingConnections stats in there.
[05:57] <poolie> it would be nice if it was easy to reproduce
[06:00] <poolie> i guess you'd have to ask a losa where it's configured
[06:00] <poolie> possibly actually tom
[06:00] <poolie> it might be injected into the database by some other means
[06:00] <spm> hm?
[06:01] <spiv> (I did at least confirm that graphs for longer time periods will show misleadingly shallow spikes for brief-but-high spikes because it just collapses multiple data points to the mean)
[06:01] <poolie> spm, do you know where the code that injects CodehostingConnections into tuolumne is?
[06:01] <poolie> and hi!
[06:01] <spm> ah. the collection script probably isn't publically available.
[06:01] <spm> heh, heya
[06:01] <spm> it's pretty simple, one sec, will paste.
[06:03] <spm> spiv: https://pastebin.canonical.com/43318/
[07:51] <vila> hi all !
=== gthorslund_ is now known as gthorslund
=== zyga-afk is now known as zyga
[08:54] <mneptok> When the light of life has gone, no change from the meter. Then the King Of Spivs will come, seeling blood by the liter.
[09:08] <vila> mneptok: should mention a goat or two when summoning like that ?
[09:10] <mneptok> vila: do you have something against goats? why would you subject them to that?
[09:11] <vila> mneptok: nothing against, quite the contrary, they work far better than chickens for my needs
[09:11] <mneptok> vila: and last i knew, due to problems at an All-Hands in 2006, Canonical has a "no goats" policy.
[09:12] <vila> oooops, I wasn't aware of this policy, damn
[09:12] <mneptok> maybe they'll change it now that both Keybuk and i are gone.
[09:14] <vila> sounds more like it ;)
[09:19] <poolie> hi vila
[09:20] <vila> poolie: hey !
[09:20] <poolie> thanks for your mail
[09:20] <vila> hmm, which one ?
[09:20] <poolie> 'wheezy inhaling'
[09:20] <poolie> nice title
[09:20] <mrevell> Morning
[09:20] <vila> Oh, you already got it, cool
[09:20] <poolie> thanks for putting a summary at the top too
[09:20] <vila> hehe
[09:20] <poolie> it would have been a wee bit better if the summary had said what the bottom line was
[09:21] <poolie> just as an idea for next time
[09:21] <poolie> ie "we're all done"
[09:21] <vila> haha, of course ;)
[09:21] <poolie> or we're not?
[09:21] <vila> well, yeah, we're done for wheezy
[09:21] <poolie> i wasn't totally clear
[09:21] <poolie> ok
[09:22] <vila> we didn't significantly regress on the number of failures, so it's a nice result
=== elmo_away is now known as elmo
[09:22] <vila> poolie: I also submitted the script I used to analyze the logs
[09:23] <vila> well, almost all logs, 28 with one being 5GB uncompressed and one being 300M compressed
[09:24] <vila> I couldn't uncompress the 300M one but both of them contain mostly 'still active' spam so hopefully nothing valuable was lost
[09:24] <vila> well, not lost, just not usable so far
[09:26] <vila> now I can resume my work on making the p-i more robust and mail the list about that and some related ideas (working on it right now)
[09:36] <vila> poolie: wgrant also mentioned one branch (can't remember which) still using rich-root-pack instead of 2a
[09:37] <vila> poolie: the branch is probably broken on lp at this point after a failed attempt to stack
[09:37] <poolie> k
[09:42] <wgrant> poolie, vila: xserver-xorg-video-voodoo
[09:42] <vila> right !
[09:43] <vila> wgrant: can you file a bug for it ?
[09:43] <wgrant> I'm not entirely sure if it's a bug.
[09:44] <vila> well, leaving a broken branch on lp is one ;)
[09:44] <lifeless> we need to upgrad them all
[09:45] <wgrant> vila: Which logs from jubany are useful?
[09:45] <wgrant> /srv/package-import.canonical.com/new/logs, but do we also want /srv/package-import.canonical.com/new's old logs?
[09:46] <vila> ECONTEXT
[09:47] <wgrant> vila: I filed an RT asking for them to be synced to devpad so launchpadders can see them.
[09:47] <wgrant> But I have been told that /srv/package-import.canonical.com/new has some logs, and asked if we want them too.
[09:47] <vila> wgrant: I haven't looked into the new/logs ones, the ones in new itself are related to the controller
[09:47] <vila> yup
[09:48] <wgrant> OK, thanks.
[09:48] <vila> the ones in new/logs are by package
[09:48] <wgrant> Right.
=== _starbuck-gone is now known as _starbuck
=== oubiwann_ is now known as oubiwann
[12:59] <pfarrell> hello! I'm using bzr-svn so that I can use bzr with my group's svn repository
[12:59] <pfarrell> lately when I try to bzr up, I get --
[13:00] <pfarrell> bzr: ERROR: checksum mismatch: '883d0c2e655f3ad55a1c069193827fff' != 'eb7cf436745e9c4265dcfad3365a8552' in trunk:15475
[13:00] <pfarrell> any ideas what on earth it could be, or how I could go about debugging it?
[13:31] <jelmer> pfarrell: what version of bzr-svn are you using?
[13:31] <pfarrell> the one in ubuntu maverick (1.0.3)
[13:32] <jelmer> pfarrell: there's an open bug report about that issue
[13:32] <jelmer> including a workaround, but that requires upgrading to a newer version of bzr-svn
[13:32] <pfarrell> apologies, I know I should have looked; I was lazy
[13:33] <pfarrell> ok .. I guess I'll just use svn for now
[13:34] <maxb> You could try the ~bzr PPA for newer versions
[13:54] <maxb> james_w: Hello, I was hoping to ask you a question about bzr-builddeb. The following revision seems bogus: http://bazaar.launchpad.net/~bzr-builddeb-hackers/bzr-builddeb/trunk/revision/482 - given that 2.6 is tagged and uploaded to Debian and Ubuntu.
[13:54] <james_w> it does
[13:56] <maxb> Are you fine with simply reverting that, then?
[13:58] <james_w> maxb, sure
[14:23] <vila> james_w, maxb: As long as the info.py get updated too :)
=== zyga is now known as zyga-afk
[14:32]  * maxb lols at vila's subject line to u-d-d@
[14:37] <vila> :)
[14:53] <james_w> vila, nice investigations, thanks
[14:54] <vila> james_w: thanks for leaving us a robust tool to play with ;)
[14:55] <james_w> vila, you said that spm restarted the importer at one point, why was that?
[14:55] <vila> didn't I mentioned the bug # ?
[14:56] <vila> bug #719196
[14:56] <ubot5> Launchpad bug 719196 in Ubuntu Distributed Development "ImportDriver should wait between ThreadedImporter spawns" [High,Confirmed] https://launchpad.net/bugs/719196
[14:57] <vila> james_w: at least that's what I suspect so far
[14:57] <james_w> ah
[14:57] <vila> james_w: a bit surprising but race conditions... are so shy sometimes
[14:57] <james_w> I missed the connection
[14:59] <vila> ha, damn, I didn't mention the log excerpt, just a sec
[15:00] <vila> 2011-02-13 19:56:59,671 - __main__ - CRITICAL - Driver hit database is locked
[15:00] <elmo> I'm going to ask a random paramiko question here, because I suspect someone will know.. exec_command() appears to be 'ssh foo.example.com bar', what's the equivalent of 'echo bar | ssh foo.example.com' in paramiko?
[15:03] <vila> elmo: bzr use exce_command() :-}
[15:07] <vila> elmo: I'm not even sure I understand how 'echo bar | ssh foo.example.com' would work in paramiko speak... this reminds me of the infamous XXX in bzrlib.tests.test_transport.TestSSHConnections...
[15:08] <vila> i.e. you need to do the plumbing yourself around the paramiko channel
[15:09] <elmo> vila: yeah, I'm trying that now
[15:09] <elmo> vila: thanks
[15:11] <vila> elmo: try again later with spiv, I only slightly changed this test
[15:12] <vila> (but banged my head on paramiko doing so...)
[15:12] <vila> james_w: so the exception is stringified and traceback lost but, as said in the bug, I suspect a race condition
[15:13] <vila> meh, a race condition when spawning the imports
[15:14] <james_w> vila, sounds reasonable
[15:14] <james_w> vila, we should probably change it to not lose the traceback too
[15:14] <vila> that too...
[15:15] <vila> james_w: bug update
[15:15] <vila> d
=== zyga-afk is now known as zyga
=== deryck is now known as deryck[lunch]
=== beuno is now known as beuno-lunch
=== deryck[lunch] is now known as deryck
[17:59] <thrope> i just installed bazaar windows standard installer on windows 2008 server but it doesnt work well
[17:59] <thrope> it is impossibly slow
[17:59] <thrope> (~1min to open bzr explorer)
[17:59] <thrope> about 5 mins after log in the explorer extensions show up
[17:59] <thrope> but dont do anything
[18:00] <thrope> oh no they do - it just takes 2-3minutes for the checkout box to pop up
[18:00] <thrope> is there anything I can do about this?
[18:01] <vila> thrope: since this does not really match feedback from other windows users, you probably have a setup problem...
[18:01] <thrope> when I select checkout from the menu I see a tbzrcommand.exe process start with about 2MB
[18:01] <thrope> the memory usage slowly grows to about 20
[18:01] <thrope> then the window pops up
[18:01] <vila> thrope: it could be a anti-virus being overzealous, I'm not a windows expert though
[18:02] <thrope> but it is not even writing any files yet - this is just opening the dialog
[18:02] <vila> ha, I'm not sure the usual windows suspects are around, you'd better file a bug report against tbzr
[18:03] <vila> thrope: https://launchpad.net/tortoisebzr/+filebug
[18:03] <thrope> ok thanks
[18:03] <vila> thrope: be sure to mention the version you're using and search around for a .bzr.log file
[18:04] <vila> thrope: 'bzr version' should tell you where to find it
=== tomaw is now known as 5EXAB34GN
=== 5EXAB34GN is now known as tomaw
=== deryck_ is now known as deryck
=== beuno-lunch is now known as beuno
=== thrope_ is now known as thrope
=== _starbuck is now known as _starbuck-bbl
=== idnaria is now known as idnar
=== lamont` is now known as lamont
=== lifeless_ is now known as lifeless
=== lamont` is now known as lamont
[21:35] <poolie> stefanlsd, hi?
[21:36] <thumper> hi
[21:36] <thumper> I have a custom virtual transport
[21:36] <poolie> hi jam
[21:36] <poolie> hi thumper
[21:36] <thumper> which is supposed to implement all the public transport methods
[21:36] <jam> morning poolie
[21:36] <thumper> but I have a feeling it doesn't
[21:37] <thumper> and when I tried to do bzr info -v over the transport, it barfed at me
[21:37] <thumper> how can I test my virtual transport to make sure it does implement all the expected methods?
[21:37] <poolie> do you get a traceback?
[21:37] <poolie> running it through per_transport tests ought to do that
[21:37] <poolie> however it's possible info requires something the tests treat as optional, or something like that
[21:37] <poolie> which would be a bug
[21:40] <jam> thumper: if you are registering your transport, you can add a function in the module, and then the per-transport permutation tests will run against it
[21:40] <jam> let me check a sec
[21:40] <thumper> jam: my transport gets registered as part of a different plugin
[21:40] <thumper> jam: it operates very much like the launchpad virtual transports
[21:40] <jam> thumper: get_test_permutations()
[21:41] <jam> thumper: the per-transport tests specifically look at what transports are registered
[21:41] <jam> check what module they are comming from
[21:41] <jam> and look for a get_test_permutations() function
[21:41] <jam> if it is present, then they will run the per_transport tests against the result
[21:41] <thumper> the transport is registered at the start of a smart server process and unregistered at the end
[21:42] <thumper> poolie: ok, thanks, I'll look into that too
[21:42] <poolie> thumper, have you got a traceback?
[21:42] <thumper> in .bzr.log yes
[21:42] <jam> thumper: so... register it globally under an unaccessible url
[21:42] <jam> just a thought
[21:42] <poolie> that should make it obvious...
[21:42] <thumper> jam: can't really, as it needs to be constructed with a server object
[21:42] <jam> thumper: that is what the test permutations is about
[21:43] <jam> setting up a server
[21:43] <jam> so that the tests can run against it
[21:43] <jam> considering that is what happens for sftp, ftp, bzr+ssh, etc
[21:43] <jam> you could also just monkeypatch "bzrlib.transport._get_transport_modules()"
[21:43] <jam> it just returns a list
[21:44] <jam> and already has 2 modules hard-coded in it
[21:44] <thumper> actually, it looks like me
[21:44]  * thumper looks sheepish
[21:44]  * thumper hacks
[21:46] <lifeless> thumper: the memory-1234: urls have the same issue and constraints for testing pretty much
[21:46] <lifeless> thumper: as jam and poolie are describing
[21:47] <thumper> yep... thanks
[21:47] <jam> lifeless: thanks, I was looking at StubSftpServer, but MemoryServer is much more straightforward
[21:48] <jam> to register a new server, tell the test code what address to use to access it, and shut it down again
[21:50] <thumper> if I have a chrooted transport, are any clones of that also chrooted?
[21:50] <thumper> and are they chrooted to the new path?
[21:50] <thumper> I'd expect so, but just checking
[21:51] <thumper> abentley: hi, did my bug last night make sense?
[21:52] <abentley> thumper, I only glanced at at, but it seemed reasonable.
[21:52] <abentley> s/at at/at it/
[21:52] <thumper> abentley: ok, cool
[21:52] <thumper> abentley: if you have any questions, I'd be happy to help
[21:53] <thumper> abentley: also... I was working in a shared repo, with trees
[21:53] <thumper> abentley: and reconfigure-pipe worked
[21:53] <thumper> but when I tried to push
[21:53] <thumper> my append path policy screwed up the push to launchpad
[21:53] <abentley> thumper, the idea is that you have uncommitted changes in a shelf, you delete another shelf, that switches you into the first shelf, but you don't get the uncommitted changes?
[21:53] <thumper> as it was now in .bzr/pipes/whatever
[21:53] <abentley> sorry, let me try again.
[21:54] <thumper> s/shelf/pipe/ then yes
[21:54] <abentley> thumper, yes, that's the sort of mistake I can imagine making.
[21:55] <abentley> thumper, yes, reconfigure-pipe isn't really suitable for Launchpad work.
[21:55] <thumper> it wasn't launchpad work
[21:55] <thumper> but the project is hosted on LP
[21:55] <abentley> thumper, that's what I mean.
[21:55] <thumper> hmm...
[21:55] <abentley> bad for launchpad-hosted work.
[21:56] <thumper> yeah
[21:57] <abentley> thumper, it's a basic model issue, because the location of the branch changes when you do reconfigure-pipeline.
[21:58] <thumper> abentley: yeah... I briefly was thinking of a way around it, but I gave up
[21:58] <abentley> thumper, we may need a different way of doing that sort of configuration.  For example, if we could append the nick instead of the path.
[21:58]  * thumper nods
[21:59] <jam> thumper: cloning a chrooted transport is supposed to keep you in the chroot. Otherwise it wouldn't be much good :)
[22:00] <abentley> thumper, it's also possible that bzr-colo has solved that (but I doubt it).  I've been meaning to switch to using bzr-colo for bzr-pipeline.
[22:00] <thumper> jam: what I was meaning... was if I had a chrooted_transport which wraps (/local/path), if I have t.clone('subpath'), is the resulting transport now chrooted inside /local/path/subpath ?
[22:00] <jam> thumper: no, it is chrooted inside /local/path, AFAIK
[22:01] <thumper> hmm...
[22:01] <lifeless> jam is correct
[22:01] <lifeless> the chroot is a decorated transport, you can clone down and up within that transport as much as you want, but not up above it
[22:01] <thumper> I think that is OK for my current use
[22:02] <thumper> we have our bzr server hosting project almost ready to roll out
[22:02] <thumper> we use a lot of code from LP, ripped and hacked to provide SSH key authentication against SSH key values in our DB
[22:03] <thumper> but we just have simple file paths with shared repos for each user and project
[22:03] <thumper> the primary use case is for the local polytechnic (technical college)
[22:04] <thumper> privacy is there by default for projects and users
[22:04] <thumper> to stop copying :-)
[22:05] <lifeless> poolie: jam: bug 437003 is possibly worth doing fairly soon
[22:05] <ubot5> Launchpad bug 437003 in Bazaar 2.0 "Failure to autopack because of 'missing inventories'" [High,Confirmed] https://launchpad.net/bugs/437003
[22:05] <lifeless> it caused /lots/ of confusion in the u1 project today
[22:06] <lifeless> its a very worrying error when it occurs
[22:06] <jam> well, until you search for a bug with that 'missing inventories' string, and see that you just 'bzr pack'...
[22:06] <lifeless> jam: they didn't do that
[22:07] <jam> I would expect when getting a failure for them to investigate, and we can tell them right away what's up, if they just sit and privately worry, there isn't much we can do for any bug that we have
[22:08] <jam> I'm not saying it isn't worth escalating that particular bug
[22:09] <jam> but saying it should become Critical for something with a known workaround that happens rarely doesn't seem quite right
[22:09] <lifeless> mmm, I'm not saying it should be critical
[22:10] <lifeless> I'm just saying that it cost a couple of man hours today
[22:10] <lifeless> and that its a very worrying error to encounter
[22:18] <poolie> definitely a worrying error
[22:48] <jam> time for me to EOD, I'll try to be back online later
[23:36] <poolie> hi spiv?
[23:41] <spiv> Hi poolie
[23:44] <poolie> how are you?
[23:47] <spiv> Older today!
[23:47] <spiv> Hmm, and with intermittent ADSL for some reason.
[23:47] <poolie> :) congratulations
[23:47] <poolie> nice to see the arrow of time is still functioning correctly
[23:47] <spiv> It keeps losing line sync, but I don't recall V grabbing at those cables recently...
[23:48]  * spiv randomly twiddles a few connections and crosses his fingers
[23:53] <poolie> i'm moving the kanbans to be on people.c.c. so they can update more frequently
[23:53] <poolie> do you have a preference about having them public vs having them include private bugs?
[23:53] <poolie> i'm slightly inclined to the former
[23:53] <spiv> Me too
[23:54] <spiv> We don't have enough private bugs to make including them in the kanban worth it, I think.
=== Ursinha is now known as _starbuck