[00:15] <zyga> lifeless, can I call bzrlib.log.get_history_change(old_revision_id=None) to get a history since beginning?
[00:16] <lifeless> I haven't looked at the log code in over a year
[00:17] <zyga> reading it quickly it seems that I have to
[00:17] <zyga> how can I get the revision_id of the first revision in a branch?
[00:18] <lifeless> well you'd travese the mainline to the start
[00:18] <lifeless> but
[00:18] <lifeless> I suspect you're using the wrong entry point
[00:19] <zyga> lifeless, I just want to have the same objects to work with (to tell the user how many things changed) regardless of doing pull vs update internally
[00:20] <lifeless> you'd normally use revisions
[03:00] <mwhudson> what the heck?  meld is running 'bzr check' for me
[03:01] <mwhudson> on my launchpad repository
[03:01]  * mwhudson objects
[03:02] <mwhudson> whisky tango foxtrot!! http://mail.gnome.org/archives/commits-list/2011-February/msg01667.html
[03:07] <lifeless> AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
[03:07] <lifeless> I presume you will express mail the nuclear cluebat?
[03:07] <mwhudson> well
[03:07] <mwhudson> i'm trying to remember how bugzilla works
[03:07] <bob2> bwahahaha
[03:08] <mwhudson> so yes, running bzr check --tree --branch _is_ faster than running bzr check
[03:08] <bob2> from the "better to ask for a large stable of ponies and a yacht, than forgiveness" style of error handling
[03:09] <fullermd> If they just want to check that it's a branch, couldn't they just make a few commits and then roll them back?  I should suggest that...
[03:09] <mwhudson> os.path.isdir('.bzr/checkout') seems about right to me
[03:10] <mwhudson> of course there's no documentation so i don't quite know what the method is for
[03:40] <mwhudson> https://bugzilla.gnome.org/post_bug.cgi
[03:40] <mwhudson> ah haha, nice one bugzilla
[03:40] <mwhudson> https://bugzilla.gnome.org/show_bug.cgi?id=653302
[03:41] <mwhudson> well, that was a distraction
[03:43] <mwhudson> "This patch attempts to add a quick sanity check
[03:43] <mwhudson>   to most version control systems.  The checks are meant to be
[03:43] <mwhudson>   as quick as possible to reduce startup time."
[03:43]  * mwhudson giggles
[05:22] <jtv> lifeless, quick Q: are non-ASCII svn usernames supposed to work when checking out a svn repository into a bzr branch?
[05:23] <jtv> oh, looks like the traceback may be apport crashing while it tries to report the problem.
[05:24] <jtv> Nope, the traceback is bzr.
[05:24] <jtv> I'm filing.
[12:05] <jelmer> hmm, anybody seen John today?
[12:41] <jam> vila: ping
[13:08] <jelmer> hi jam
[13:18] <vila> jam: hi and pong
[13:18] <vila> jelmer: hi
[13:35] <jelmer> hey vila
[14:05] <maxb> If someone has a moment, UDD iscsitarget is ready for repair in bug 794574
[14:27] <vila> maxb: this requires updating the jubany scripts from lp:udd right ? (Which also requires restarting mass_import since udd.paths has been introduced (not strictly required but..)))
[14:29] <vila> maxb: jubany is at revno 470 right now
[14:52] <Riddell> jelmer: you said we have --directory for most commands but many just take a [Location] argument, is there a reason to use one over the other?
[14:53] <jelmer> Riddell: -d is usually where we don't have a location to work from as the first argument, but want a way to specify it
[14:53] <Riddell> I think for verify-signatures it makes sense just to have a [Location] option then
[14:54] <Riddell> since it doesn't take any other options
[14:54] <jelmer> Riddell: e.g. bzr push takes a -d option to override the source location, bzr tag already takes a tag name argument so you can override the branch to work in with -d, etc.
[14:54] <jelmer> Riddell: presuming you mean s/options/arguments, I agree
[14:55] <Riddell> I do
[14:59] <maxb> vila: There's no requirement to restart mass_import here. I think we should skip doing so. (Or, we should migrate to doing so in a LOSAless fashion, or decide to hold off future refactorings that would affect it)
[15:01] <vila> maxb: (I went that route...For now, we have a losa and have to bear with it) Now, I know we don't *need* to restart mass_import, it's just that I'd feel safer doing so. But more importantly I wanted to check with you I understood what changes were pending and didn't miss some
[15:04] <vila> especially with 2 revisions fixing previous ones, nothing pending ?
[15:06] <vila> maxb: and keep in mind that the initial plan was to migrate from jubany and lose shell access... so we're "lucky"
[15:07] <maxb> :-/
[15:07] <mbp_> hi maxb, vila
[15:07] <mbp_> i think a agood step for the losas is to start having them do jobs for max that we currently do ourselves
[15:08] <poolie> why 'lucky'?
[15:08] <vila> no shell access would have been worse :)
[15:09] <vila> poolie, maxb : I think giving access to jubany would me pragmatic given the recent requests
[15:10] <vila> s/me/be more/
[15:10] <vila> funny tyop
[15:11] <poolie> to whom?
[15:11] <vila> to us
[15:12] <vila> bah
[15:12] <vila> to maxb
[15:12] <poolie> i see your point
[15:13] <maxb> That would be convenient, but would probably need to go via the Ubuntu Developer Membership Board for signoff, given the level of access that implies
[15:14] <poolie> right, it's pretty high
[15:14] <poolie> and it's a step in the wrong direction
[15:14] <poolie> routing through the losas seems like a good step
[15:15] <maxb> I disagree on both counts
[15:15] <poolie> oh?
[15:15] <vila> except the losas don't have the required knowledge as of today and the long term plan is to not need them for such operations
[15:16] <vila> maxb: lp:udd pulled & fixit done , by the way
[15:16] <maxb> Applying to give me access to the branches directly is roughly similar to me applying to be a core-dev - not a wrong direction, but potentially awkward because I've jumped directly to contributing to matters cutting across all of Ubuntu
[15:16] <maxb> Involving the LOSAs simply adds more "please run this" repetetive work to an already overworked team
[15:16] <vila> oh, we aren't giving you access to the branches, we give you the ability to impersonate james_w :D
[15:17] <vila> poolie: by the way, what's the status of the bug about not using james_w credentials anymore ?
[15:18] <maxb> None of the work involved in managing the importer necessarily requires administrative rights - all it requires is enough privileges on Launchpad plus a computer to run the importer on
[15:18] <poolie> maxb, that's true about it creating more manual work
[15:18] <poolie> or, spreading it around
[15:18] <poolie> vila, i have an email alias for it
[15:19] <vila> poolie: and a lp account ?
[15:19] <poolie> not yet
[15:19] <poolie> that's the next thing i need to do
[15:19] <poolie> oh, also to test whether the address works :)
[15:23] <maxb> vila: Can you check if something's broken, the web pages don't seem to be updating, as if categorize_failures.py was not running
[15:23] <vila> NameError: global name 'explanations_file' is not defined :-(
[15:23] <vila> tests tests tests :D
 davmor2: don't you wish you could do that?
[15:24] <james_w> * em has quit (Read error: Connection reset by peer)
 Not that I would want to touch the floor in a men's bog
[15:24] <james_w> * em (~em@unaffiliated/emma) has joined #ubuntu-uk
 anyone know what the premissions openssh actually wants for a chrooted sftp are? It's doing that wonderful thing of saying I've got them wrong, but not what they should be
 BigRedS: http://www.debian-administration.org/articles/590 ?
[15:24] <james_w> * em has quit (Ping timeout: 260 seconds)
 yeah, it wants more than just owned-by-root it seems
[15:24] <james_w> * Guest96855 has quit (Quit: Ex-Chat)
[15:24] <james_w> * em (~em@unaffiliated/emma) has joined #ubuntu-uk
[15:24] <maxb> oh for goodness sake. I suck, evidently, though I grepped really really carefully after the first problems.
 It's happy with the user being unable to write to the chroot dir
 which seems normal, except I'm sure the user used to be able to write there...
[15:24]  * maxb fixes
 BigRedS: yes, so the user can't drop a .ssh/authorized_keys
 I *thought* it used the user's ~ for ssh bits and bobs for precisely that reason?
 docs seem either to be scarce or to be hiding from me though
[15:24] <james_w> * marxjohnson (~mark@2.102.242.119) has joined #ubuntu-uk
 apt-get source... :)
[15:24] <james_w> oops, sorry
[15:24] <vila> who is impersonating james_w now ?
[15:25] <vila> maxb: you don't suck, really
[15:27] <maxb> pushed
[15:27] <vila> AttributeError: 'set' object has no attribute 'web_status_dir' :-}
[15:27] <maxb> what?!
[15:28] <vila>     paths = set()
[15:28] <vila>     path = os.path.join(paths.web_status_dir, "index.html")
[15:28] <maxb> yes :-/
[15:29] <vila> I really think overriding symbols should be banned from all languages :)
[15:29] <jelmer> james_w: is it correct that RepackTarballAdaptor isn't used anywhere in bzr-builddeb?
[15:30] <james_w> jelmer, I'm not sure. I don't remember the class, so if grep says no then it likely isn't
[15:30] <poolie> hi jam
[15:30] <maxb> pushed, again
[15:31] <vila> maxb: watch out for the same pattern in write_main_page or did you fix both ?
[15:31] <james_w> ah
[15:31] <maxb> yes, I fixed all three
[15:31] <james_w> from the test multiplication code
[15:31] <vila> maxb: by removing them ? (They don't seem to be needed, it's a set for a single add)
[15:31] <maxb> I didn't want to change that much for a quick-fix
[15:32] <vila> maxb: anyway, it ran
[15:32] <jelmer> james_w: ah, hmm. is this replaced by the scenarios now perhaps?
[15:32] <maxb> Besides, I think it's so that all of the writing functions have the same interface
[15:32] <vila> maxb: ok, will you or should I ?
[15:32] <maxb> do what?
[15:32] <vila> maxb: sure same interface but that doesn't mean the implementation has to do useless stuff
[15:33] <maxb> I'm happy with the code as it currently is.
[15:35] <vila> ha right, just re-read get_info, it has to be a set, so nm
[15:36] <james_w> jelmer, I can't remember if it uses multiplication any more
[15:37] <jelmer> james_w: I'll browse a bit further
[15:37] <james_w> yeah, looks to be scenarios now
[15:38] <poolie> maxb, i'll see if we can do that
[15:38] <poolie> s/that/giv eyou access
[15:39] <jam> hey poolie, just on my way out
[15:47] <jelmer> hey jam
[15:51] <maxb> poolie: That would be useful. I suppose I should file a per-package uploader application for bzr, so that I can be an Ubuntu developer of some kind.
[15:54] <poolie> that'd be good
[15:55] <poolie> hi jam
[15:55] <poolie> and jelmer
[15:56] <poolie> maxb, so perhaps we should ask the tb if you can have access to ubany
[15:58] <poolie> maxb, i think it would be worth you doing a ppa
[15:58] <maxb> PPU ?
[15:58] <poolie> you can find my application in the techboard archive
[15:58] <poolie> yes, ppu
[16:00] <jelmer> hi poolie, maxb
[16:01] <poolie> you can crib from that if you want
[16:02] <jelmer> wait, what?
[16:02] <jelmer> clearly there are some meanings of the word "crib" I'm not familiar with :)
[16:04] <poolie> copy
[16:04] <poolie> as in cheat on an exam
[16:04] <jelmer> ah, thanks
[16:05] <poolie> also 'a brothel', 'a wicker basket', ' a packed lunch taken to work'
[16:05] <poolie> i have nevert heard of those
[16:06] <poolie> actually maybe the first, but it's very archaic
[16:06] <jelmer> yeah, the only two places I remember seeing it are in bible references and on MTV ("MTV Cribs")
[16:06] <vila> ha, I found surprising you never heard of a brothel :)
[16:06] <vila> jelmer: what ? The bible is talking about brothels ???
[16:07] <vila> oops, that may be offensive, sorry
[16:07] <poolie> these are obscure meanings of the word 'crib'
[16:07] <jelmer> vila: a crib is also an infant bed
[16:07]  * vila notes to never ever use this word
[16:08] <vila> Just in case I try to say I put one of my daughter in a crib....
[16:09] <jelmer> :)
[16:10] <vila> jelmer: is it still time to remember you about bike leds ?
[16:10] <jelmer> vila: I haven't forgotten :)
[16:10] <vila> great !
[16:43] <maxb> Oh. Hah.
[16:43] <maxb> jubany gets different results to me because lucid's and natty's dpkg behave differently
[16:56] <poolie> hm
[16:56] <poolie> i wonder if i should just ask on the tb list
[16:58] <poolie> maxb it may be better f you start your developer application first
[16:58] <poolie> then that can describe your credentials etc
[16:58] <maxb> ok
[16:58] <poolie> i would be delighted to endorse you
[16:59] <vila> maxb: can't you test it in chroot ?
[16:59] <poolie> i expect james, jelmer, and others would too
[16:59] <vila> poolie: by the way, could we discuss with losas to get a read-access to some ppa so we can precisely (and cheaply) setup jubany replicas ?
[17:00] <vila> poolie: that is, not *now* but next week ;)
[17:00] <maxb> PPA? To contain their patched packages?
[17:02] <vila> maxb: yeah, *these* packages
[17:03] <poolie> the CAT packages?
[17:03] <vila> maxb: or share one with them, whatever
[17:03] <poolie> sure
[17:03] <poolie> just ask
[17:03] <vila> poolie: could be. The ones that are installed on jubany.
[17:03] <vila> creat
[17:04] <poolie> vila, the URL is visible on jubany ;)
[17:05]  * vila blinks
[17:05]  * vila blinks twice
[17:05] <vila> yummy
[17:06] <vila> what a beautiful idea to end the week...
[17:21] <poolie> cheerio
[19:24] <Prodi> i'm having some issues with bzr throwing an error when I try to do a push
[19:25] <Prodi> tried a search, but nothing seems to be relevant/help
[19:26] <Prodi> the last part I see working is the fetching revisions, it sends a few megs to the server, and then throws the following error
[19:26] <Prodi> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[19:26] <Prodi> my network appears to be fine though
[19:26] <maxb> Hmm. Please check your ~/.bzr.log, see if there is additional debugging information there
[19:26] <Prodi> i'm running this on windows
[19:26] <Prodi> do you know where that file is located?
[19:26] <maxb> No :-)
[19:27]  * Prodi googles
[19:27] <maxb> Ah. "bzr version" should tell you where the log file is
[19:27] <Prodi> oh ok
[19:28] <Prodi> got it
[19:33] <Prodi> there's some message about adding something to LRUSizeCache failed, but I assume that's just a warning
[19:33] <maxb> Yes
[19:34]  * maxb wonders which flavour of UDD failure to attack next
[19:35] <maxb> The remaining NoSuchTag ones that I semi-diagnosed at Millbank, I think
[19:35]  * Prodi wonders what UDD is
[19:35] <maxb> UDD is Ubuntu Distributed Development, the use of Bazaar to maintain Ubuntu packages
[19:35] <Prodi> ah
[19:35] <maxb> UDD is also the Ultimate Debian Database, just to confuse everyone :-)
[19:36] <Prodi> TooManyConcurrentRequests: The medium 'SmartSSHClientMedium
[19:36] <Prodi> )' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.
[19:37] <maxb> Hmm. Usually that means a ssh connection has broken and bazaar has kept trying to use it
[19:37] <Prodi> hmmm
[19:37] <maxb> Perhaps you could pastebin a larger chunk of the log?
[19:37] <vila> Prodi: bzr version ?
[19:38] <Prodi> Fri 2011-06-24 14:30:55 -0400
[19:38] <Prodi> 0.062 bazaar version: 2.3.1
[19:38] <Prodi> 0.063 bzr arguments: [u'qsubprocess', u'--bencode', u'l4:pushe']
[19:39]  * jelmer is making progress on multiple upstream tarballs
[19:40] <vila> Prodi: 2.3.3 is out, not sure if the fixes are relevant though. Depending on your OS there is also betas for 2.4
[19:40] <Prodi> i went with the windows MSI
[19:41] <Prodi> taht contains all the pieces
[19:41] <vila> right, windows it is then. So you can (and probably should) upgrade to either 2.3.3 or 2.3b4
[19:41] <vila> meh
[19:41] <vila> 2.3.3 or 2.4b4
[19:42] <vila> if you still encounter the issue, file a bug please at http://pad.lv/fb/bzr
[19:43] <Prodi> I went for the stable release provided at http://wiki.bazaar.canonical.com/WindowsDownloads
[19:45] <Prodi> http://pastebin.com/3rEHqZU6
[19:56] <Prodi> actually, this may be server permissions related
[19:56] <Prodi> it never seems to set the right permissions when I branch on the server
[20:29] <Prodi> well, that didn't help
[20:30] <Prodi> is there a server side log I can look at?
[20:30] <Prodi> ]for the smart server?
[20:31] <james_w> maxb, $ requeue lash
[20:31] <james_w> Traceback (most recent call last):
[20:31] <james_w>   File "/srv/package-import.canonical.com/new/scripts/requeue_package.py", line 33, in <module>
[20:31] <james_w>     opts.zap_revids = filter(None, opts.zap_revids.split(','))
[20:31] <james_w> AttributeError: 'NoneType' object has no attribute 'split'
[20:32] <james_w> that's because there's no --zap-revids given I think?
[20:32] <maxb> Argh
[20:32] <maxb> I seem destined to break udd scripts in silly ways at the moment
[20:32] <james_w> maxb, want me to fix it?
[20:33] <maxb> I'm happy to do so, but you can likely to it just as quickly :-)
[20:33] <maxb> *do
[20:33] <maxb> (I'd just add default="" to the option definition)
[20:34] <maxb> Maybe I should just turn it into a standard append-type optparse option
[20:34] <maxb> The current uses I'm coming up with for it tend to only involve zapping a few series
[20:35] <james_w> done
[20:35] <maxb> thanks
[20:36] <maxb> by the way, don't update bzr-builddeb on jubany, it breaks current udd :-/
[20:36] <james_w> ok
[20:36] <james_w> that was the fix jelmer proposed, or something else?
[20:36] <maxb> Apparently jelmer's fix didn't go far enough
[20:37] <james_w> ah, ok
[20:38] <maxb> bug 801726 filed for now to preserve my mental state on that
[20:46] <maxb> Right.
[20:47] <maxb> I'm done compiling work for people to run on jubany now :-)
[20:48] <maxb> Ooh, and I've *very nearly* knocked AssertionError:<module>:main:find_unimported_versions:check off the top spot in the rankings
[20:51] <Prod[a]> is there a way I can work around having to push to the server remotely?
[20:51] <Prod[a]> like package the change into a file and do the commit from the server or something?
[20:52] <Prod[a]> or rather package the commit, and push it from the server
[20:53] <maxb> Bazaar has a concept called a "bundle"
[20:55] <maxb> Try bzr send --no-patch -o foo.bundle destination-branch
[21:04] <Prod[a]> k, will try it out
[21:04] <Prod[a]> thnx
[21:04] <Prod[a]> should I also open a bug report for this?
[21:05] <Prod[a]> considering I don't really know where or what the issue is?
[21:12] <maxb> (assuming no more of the in-progress ones fail :-) )
[21:19] <KombuchaKip> EasyTAG has just been resurrected. Please vote on your preferred revision control management we should use: http://www.easypolls.net/poll.html?p=4e04d772a34eb0e4f6954f91
[21:23]  * maxb wonders how spamming that message in #bzr can possibly make sense
[22:01] <Prod[a]> i opened a bug for it
[22:01] <Prod[a]> https://bugs.launchpad.net/bzr/+bug/801769
[22:01] <Prod[a]> oh, there it is :)
[22:57] <maxb> requeue --auto qbittorrent if someone has a moment?
[23:27] <timrc> does anyone have an example of how to push a local branch to a remote location using bzrlib?