[00:02] <Noldorin> bob2, thanks
[00:54]  * spiv blinks
[00:55] <spiv> $ bzr st
[00:55] <spiv> modified:
[00:55] <spiv>   doc/en/_templates/index.html
[00:55] <spiv> ignored:
[00:55] <spiv>   doc/en/_templates/index.html
[00:55] <lifeless> \o/
[00:56] <AfC> Remind me not to use the version spiv is running...
[01:00] <spiv> Bug 712209 filed.
[01:00] <spiv> AfC: tip of lp:bzr, of course :)
[01:01] <spiv> AfC: but it appears to affect 2.2 too.  2.1 seems ok.
[01:11] <poolie> hullo spiv
[01:14] <fullermd> spiv: bug 587506
[01:20] <spiv> fullermd: thanks!
[01:22] <fullermd> (it also, AIR, shows up in the commit template; not sure if there's an extant bug about that.  But I presume it's all the same code causing it everywhere anyway)
[01:24] <spiv> fullermd: I'd expect so
[01:49] <poolie> "ian.clatworthy@internode.on.net has been removed from bazaar-commits." :-(
[01:50] <spiv> :(
[01:50] <spiv> I noticed earlier today he has four branches on https://code.launchpad.net/bzr/+merges?field.status=WORK_IN_PROGRESS
[01:51] <spiv> I'm going to take a look and try to either abandon them or do something with them.
[01:51] <poolie> that'd be good
[02:01] <poolie> spiv i guess the things that most need review are actually yours
[02:02] <spiv> poolie: yeah
[02:04] <spiv> As it's the start of a cycle I wonder if I should land them, especially given they've already had some review.
[03:58] <lifeless> spiv: does your haproxy thing for codehosting also make it wait to shutdown for things to finish ?
[03:58] <lifeless> spiv: if so, what method of shutdown were you expecting?
[04:01] <spiv> lifeless: yes, and SIGTERM or SIGINT
[04:01] <spiv> (which are the default signal handlers twisted installs)
[04:05] <lifeless> spiv: could you join #launchpad-ops for a bit ?
[04:07] <spiv> Sure
[04:08] <lifeless> thanks
[04:45]  * maxb hugs mod_wsgi
[04:47] <maxb> One quick installation of bzr smart server + loggerhead, no extra daemons beyond the apache, 70 lines of config total :-)
[04:48] <maxb> and that only because I decided I wanted a custom logging arrangement any ended up copypasting part of bzrlib.trace
[04:49] <poolie> nice
[04:49] <maxb> hmm
[04:49] <poolie> maxb, if you have notes on how to do it i'd like to add that to the docs or the blog
[04:49] <poolie> though, pehraps 70 lines could be improved upon
[04:53] <maxb> well, that's including a full apache <VirtualHost> block and two wsgi hooks, each with ~7 lines of imports
[04:54] <maxb> hah, nice
[04:55] <maxb> Now I've mounted the loggerhead and the smart server sharing the same URLs
[04:56] <maxb> I have to have two urls, one for read-only and one for read-write, though
[04:57] <maxb> Now, if the smart server could map 'read only transport' errors into 401 http responses, that would be awesome, because then I could do anonymous-read/authenticated-write on a single URL
[04:58] <lifeless> file a bug
[04:59] <maxb> ugh, it's 5am, I should stop playing with wsgi :-)
[05:06] <spiv> maxb: ...and start drinking whiskey instead? :)
[05:08] <maxb> Nah, I've already had some port tonight
[05:10] <peitschie> you mean last night :P
[05:18] <maxb> or possibly both
[05:30] <peitschie> maxb: whoah... snapps!
[05:30] <peitschie> or is it schnapps =D
[07:47] <vila> hi all !
[08:59] <jelmer> moin
[09:30] <vila> jelmer: hey !
[10:02] <jelmer> vila: did you see Charlie's comment on the NoWhoAmi bug ?
[10:02] <vila> yes
[10:03] <jelmer> vila: When is 2.3 scheduled exactly?
[10:03] <vila> freeze today
[10:03] <vila> 2.3.0
[10:04] <jelmer> hmm, ok. so if we want to get it in it should be done today?
[10:04] <vila> but I may freeze 2.2.4 first
[10:04] <vila> done and approved... which seems a bit of a hurry :)
[10:04] <jelmer> It'd be nice to get that one fixed so launchpad can deploy 2.3
[10:05] <vila> I smell controversy and regressions around this topic :-/
[10:05] <vila> basically there are two class of users competing for one default value/behaviour for opposite reasons,
[10:06] <vila> newbies that don't understand the implications and admins who don't care about these implications
[10:06] <jelmer> vila: I think the use of mailname is reasonable, and we could still warn if we end up using the mailname
[10:06] <jelmer> I'm sure we can find a better middle ground than we have at the moment :)
[10:07] <vila> I seem to remember that the warning lead has been explored at one point but it seems to be the most reasonable one to try now ;)
[10:08] <vila> . o O (daggyfix for features should tell us this kind of thing instantly...)
[10:09] <jelmer> vila: Did we really have a warning at some point? I remember somebody saying that in Dallas as well, but I don't remember it.
[10:09] <vila> jelmer: still, deploying on lp is only part of the issue, I'm pretty sure they want on lucid...
[10:09] <vila> jelmer: I don't remember discussing the subject in Dallas, so that should have been someone else ?
[10:10] <vila> jelmer: it may have been discussed in the mp and never landed
[10:10] <jelmer> vila: yeah, I don't think that was with you
[10:10] <vila> I think the issue with the warning is that explorer/GUI users may not get it
[10:11] <vila> on the other hand, GUIs *should* guide the users on this particular issue
[10:11] <jelmer> vila: Yeah, agreed
[10:12] <vila> so let's do the warning and put the burden on GUI devs :D
[10:12] <jelmer> I think it's very clear how a GUI should deal with this - just prompt the user and suggest a username.
[10:13] <jelmer> vila: I also think we should bring back the functionality to guess a username, so it can be used by the GUIs as a suggestion, and so it can be used when we need a username for e.g. a lock or "bzr blame"
[10:15] <vila> jelmer: good point, but it's a separate issue
[10:15] <vila> haa, what I meant is:
[10:15] <vila> - yes, valuable work has been invested in guessing, let's share it with GUIs
[10:16] <vila> - don't mix the warning stuff with the guessing stuff
[10:17] <vila> or may be I'm wrong and instead the warning stuff *is* (or should) be based on the guessing (I don't remember the code in detail)
[10:18] <jelmer> vila: I agree, they're related but separate issues
[10:19] <vila> right, the pain point today is for admins, let's do the warning first and *then* let's address the guessing,
[10:20] <vila> the former may be targeted  at 2.1 (unless it's too hard) while the later can be done in trunk
[10:21] <vila> this way the admins can get their cake on lucid
[10:21] <vila> pending sru for 2.1 yada yada
[10:23] <vila> maxb: your fix for bug 707075 is required for 2.2 whatever launchpadlib version is used right ?
[10:24] <vila> maxb: (trying to see if it can be backported in the packaging branch for 2.2.3 or if we really need a 2.2.4 for other distros)
[11:02] <Tak> which subproject is launchpad "bugs" ?
[11:05] <mgz> malone.
[11:43] <maxb> vila: Correct, it is required for any launchpadlib >= 1.5.5
[11:44] <vila> busted (I didn't hope much ;)
[12:38] <vila> jelmer: tracking a test failure in bzr-builddeb I end up with a test failure in bzr-svn: http://paste.ubuntu.com/561900/
[12:40] <vila> jelmer: do I need svn itself installed ? (I have bzr-svn/1.1 python-subvertpy from bzr/ppa (0.7.5))
[12:41] <jelmer> vila: no, that's actually a known failure at the moment
[12:41] <jelmer> there's an open bug about it
[12:41] <vila> ha, ok, thanks
[12:51] <vila> jelmer: some builddeb test require bzr-svn or fail (they should check the plugin is there instead, I'll fix), but I know have a failure due to a late change in revno 3510 AttributeError: 'Revision' object has no attribute 'mapping'
[12:51] <vila> s/know/now/
[12:58] <jelmer> vila: as far as I know none of them really require bzr-svn, because I don't have bzr-svn installed in the environment I run the tests.
[13:00] <vila> jelmer: even the one that includes 'svn in their name in test_merge_upstream ?
[13:00] <vila> s/one/ones/
[13:00] <vila> circa line 80
[13:01] <vila> jelmer: introduced ~08/2008 ;)
[13:12] <vila> jelmer: http://paste.ubuntu.com/561919/ , so the issue is that the test fakes a Revision object but not a ForeignRevision one :-/
[13:13] <jelmer> vila: ah, hmm
[13:13] <jelmer> vila: yeah, bzr-svn recently started looking at rev.mapping
[13:13] <vila> yeah, no worries, it's a test bug I'd say
[13:14] <vila> how do I create this attribute to mean it comes from svn ? (value)
[13:16] <jelmer> vila: you'd need to get it from the bzr-svn mapping registry
[13:16] <vila> darn, complex object ?
[13:17] <jelmer> vila: well, I guess you could mock one if you wanted to
[13:17] <vila> hmm, they are compared for equality so mocking...
[13:18] <jelmer> the mapping object isn't compared, but the .vcs one is
[13:18] <jelmer> the .vcs bit you should be able to get from bzrlib.foreign.foreign_vcs_registry.get("svn")
[13:28] <vila> jelmer: did the trick, thanks
[13:30] <vila> jelmer: yet, it's weird you don't see the failure when svn is not installed, are you sure you don't get it from somewhere unexpected ?
[13:35] <jelmer> vila: hmm, actually.. I might have it but just an older version
[13:36] <jelmer> vila: are you fixing this bug, or should I have a look?
[13:50] <vila> jelmer: now I'm fixing a bug in bzrlib.tests.ModuleAvailableFeature :-/
[13:51] <vila> shudder... no way I could force a dependency on bzr.dev to bzr-builddeb isn't it ?
[13:52] <jelmer> vila: ideally not
[13:52] <jelmer> vila: it makes backporting a pain
[13:53] <jelmer> other than that I don't really think it's a big deal
[13:53] <vila> I will find a way to split the fixes
[14:37] <fax8> hi guys, I do have my sources updated to the latest revision
[14:37] <fax8> how do I get them as in a previous one
[14:37] <fax8> ?
[14:43] <jelmer> fax8: hi
[14:43] <jelmer> fax8: I'm not sure I understand the question - you'd like to see the contents of a previous revision?
[14:57] <jelmer> vila: fwiw there's already a MP open for the zipfile issue
[14:58] <vila> jelmer: trying to run selftest will all plugins I get >100 failures, if disable svn I get 0
[14:58] <vila> jelmer: ha, rats
[14:58] <jelmer> (~jelmer/bzr-builddeb/712180-zipfile-python2.6)
[14:58] <jelmer> vila: all foreign branch plugins trigger errors unfortunately
[14:59] <vila> ok, np, just making sure you knew about it
[14:59] <jelmer> it's on my list of things to work on (testsuite improvements for foreign plugins in general), but I haven't gotten to it yet
[15:00] <vila> jelmer: your patch for zip if far more complex than mine :D
[15:00] <jelmer> well, it actually makes the zip file a proper file :)
[15:00] <vila> mine doesn't ?
[15:01] <jelmer> I thought it just added some bytes into the file?
[15:01] <fax8> jelmer: yeah.. I do have all the files updated to reversion X ... I want that all becames as in reversion X-Y.. how can I do so?
[15:02] <vila> jelmer: writestr accepts zinfo_or_arcname, you went for zinfo, I went for arcname (AFAUI)
[15:02] <jelmer> vila: ah, ok
[15:02] <vila> fax8: there are various ways to achieve that, it depends on what you want to do *after(
[15:03] <jelmer> vila: I guess we should take the smaller version of it then (but still close the bug #)
[15:03] <vila> jelmer: yup, I'm trying to check that using arcname is not a recent addition
[15:03] <fax8> vila: I don't wanna commit anything.. just see how the were (can't use bzr cat)
[15:05] <vila> fax8: why not create a new branch then: from <current> (where you are) : 'cd .. ; bzr branch current -r-2 new'
[15:05] <vila> but generally you look at the diff: 'bzr diff -r-2'
[15:05] <vila> or the status: 'bzr st -r-2'
[15:06] <vila> so you don't touch your working tree and its uncommitted changes
[15:10] <vila> jelmer: I checked zipfile.writestr for python2.[456], three different versions all accepting the simpler one proposed above but varying slightly implementing yours.
[15:10] <jelmer> vila: I'm not particularly tied to my solution, happy to go with yours.
[15:11] <vila> ok, I'll steal the bug then ;)
[15:12] <vila> jelmer: hmm, there is a debian dir there, how is the changelog handled ? Should I add an entry (or are tests not worth it) ?
[15:13] <jelmer> vila: actually, since this is a regression that's never been in a release I'm not sure if a changelog entry is worth it
[15:13] <vila> ok
[15:16] <fax8> vila: thanks.. I did know about the branch solution.. I just wanted to switch to an older snapshot.. not needed to create a branch
[15:17] <vila> bzr pull -r2 then
[15:17] <vila> bzr pull -r-2 then
[15:18] <jelmer> more specifically, "bzr pull -r-2 --overwrite ."
[15:19] <fax8> that did it .. thank you
[15:27] <vila> jelmer: I start the freeze, no mp for the whoami warning ?
[15:27] <jelmer> vila: nope, sorry
[15:28] <jelmer> we can probably cherry pick it after its landed though
[15:28] <vila> np
[15:28] <vila> we ?
[15:28] <vila> as in lp ?
[15:29] <jelmer> yeah
[15:30] <vila> k
[15:30] <jelmer> I'm keen to see a newer bzr deployed on lp, as it'll help with recipe builds (being able to use stacking, for example)
[15:30] <vila> I'd prefer merging up from 2.1 if you target that, but since I won't be the one doing it, you're the judge ;)
[15:31] <mgz> exec vila? really? why not just check sys.modules first?
[15:31] <vila> and they need a proper whoami there ?
[15:31] <jelmer> vila: there among other places
[15:31] <vila> mgz: I was wondering who will mention that first, spiv, jam or you ;)
[15:31] <mgz> :D
[15:31] <vila> jelmer: ok
[15:31] <jelmer> mgz: exec is what we use to load plugins, too
[15:32] <jelmer> so it doesn't seem that bad to use it here as well
[15:33] <vila> honestly, I thought about checking sys.modules *after* submitting and then wondered if some edge cases would be covered...
[15:33] <mgz> yeah, it's not really that evil as it's just tests, but I get heebies about running some interpolated string
[15:34] <vila> mgz: nothing with running interpolated strings.... as long as you understand what they contain :D
[15:35] <mgz> well, we can trust test authors not to write ModuleAvailableFeature("sys; something_evil")
[15:37] <vila> right, worth mentioning in the mp, checking sys.modules should be enough here anyway plus I forgot to add tests
[15:37] <vila> s/mp/review/
[15:38] <mgz> I will add a little note.
[15:44] <mgz> done, typed in some (untested) code that might work.
[15:45] <mgz> ...and has at least two errors, which just makes life more fun.
[15:51] <vila> mgz: :)
[16:07] <mgz> jam gets one prize.
[16:09] <jelmer> 'morning jam
[16:12] <maxb> jelmer: Hi, I have a question about bzrlib.plugins.launchpad - You recently added qastaging support - I was intending to refactor it to rely on launchpadlib for all its list-of-launchpad-instances support, but the versions of launchpadlib currently in ubuntu don't include qastaging. How would you feel about me addressing this by conditionally monkeypatching launchpadlib.uris ?
[16:12] <jelmer> maxb: hi
[16:13] <jelmer> maxb: what's the issue with the current way of retrieving the URLs?
[16:14] <maxb> That we currently maintain two separate lists of launchpad instances within bzrlib.plugins.launchpad, and, except for the addition of qastaging, launchpadlib has all the data we need in the launchpadlib.uris module
[16:15] <jelmer> can't we just keep a single list in bzrlib.plugins.launchpad ?
[16:15] <maxb> I'm aiming to reduce the amount of launchpadlib functionality duplicated within bzrlib.plugins.launchpad.
[16:16] <maxb> So, I was thinking of something along the lines of:   if 'qastaging' not in launchpadlib.uris.service_roots: launchpadlib.uris.service_roots['qastaging'] = 'https://api.qastaging.launchpad.net/'
[16:16] <jelmer> maxb: monkey patching is duplicating code as well
[16:17] <maxb> Yes it is, but in the net reduction in duplication should be pleasing
[16:17] <maxb> Yes it is, but in *this case* the net reduction in duplication should be pleasing
[16:20] <maxb> The monkeypatching will be confined to four lines, and will allow all the rest of the code to use public launchpadlib apis for the rest of the URL manipulation
[16:27] <jelmer> it's about the same amount of code to cope with it sometimes being missing at the moment
[16:27] <jelmer> perhaps I'm missing something here :)
[17:43] <jelmer> abentley: hi
[17:43] <abentley> jelmer, hi.
[17:44] <jelmer> abentley: I'm looking for a way to walk over the ancestors of a revision but processing them in increasing distance from my current tip
[17:44] <jelmer> abentley: is there anything in graph that allows me to do that?
[17:46] <abentley> I don't think we have that specifically.  We have a breadth-first traversal.
[17:47] <abentley> jelmer, does Graph._make_breadth_first_searcher do what you need?
[17:48] <jelmer> abentley: it seems to, but it's also private
[17:49] <jelmer> find_descendants sort of seems to do what I need, except in the wrong order
[17:51] <abentley> jelmer, I don't understand how it can be the wrong order if it uses make_breadth_first_searcher and make_breadth_first_searcher works for you.
[17:53] <abentley> jelmer, nm.
[17:53] <abentley> jelmer, what about iter_ancestry?
[17:54] <jelmer> abentley: I need to exclude a particular key and its ancestry
[17:56] <vila> jelmer: log needs that for --exclude-common-ancestry
[17:57] <vila> jelmer: see branch.iter_merge_sorted_revisions
[18:00] <jelmer> \o/
[18:13] <vila> jelmer: what's the landing policy for bzr-builddeb ? push when mp is approved ? 2 votes ? something else ?
[18:14] <jelmer> vila: merge revision for branch when there is approval
[18:14] <vila> jelmer: locally, and push to trunk ?
[18:15] <jelmer> vila: yeah
[18:15]  * vila slaps fingers for working in trunk
[18:15]  * jelmer wished there was a "bzr merge --into" command
[18:16] <jelmer> to say merge my branch into that one, with a particular message, rather than merging that one into mine
[18:17] <vila> but... you need a working tree (if only for the conflicts)
[18:18] <vila> merge is a serious operation you know, you can't just drop it on some random branch !
[18:18] <vila> ;)
[18:18] <jelmer> that's fine, I don't mind using the current one
[18:18] <vila> oh, you mean --swap-parents ?
[18:18] <jelmer> yeah, that's all I care about really :)
[18:18] <vila> (don't search, it doesn't exist but has been mentioned several times)
[18:18] <jelmer> I did search :)
[18:19] <vila> sry :-/
[18:20] <vila> jelmer: test failures fix pushed
[18:23] <jelmer> vila: \o/
[18:23] <vila> jelmer: and for bug status, committed and the RM mark them fix released ?
[18:25] <jelmer> vila: yep
[18:25] <jelmer> at least that's what I've been doing, hopefully james_w can correct me if I'm wrong :)
[18:25] <vila> nah, looks fix-released when landed, but... https://launchpad.net/bzr-builddeb/+series isn't super clear 8-)
[18:27] <vila> or fixreleased when mentioned in changelog ?
[18:27] <vila> :D
[18:27] <vila> anyway, landed, marked fixed :)
[18:30] <james_w> I always used to do "commited" and then "released" on release, but it's kind of shaky given that it's a native package that I have sometimes uploaded to Ubuntu directly
[18:35] <vila> james_w: ack
[18:48] <vila> hmm, code import failures mail flood, that reminds me about adding a host monitor for the package importer (lp is done, debian is unreachable, etc) to avoid this kind of issue
[18:49] <vila> s/done/down/ hee, that wasn't a joke ! Why did the tyop gnome keep jumping on my fingers !
[20:26] <james_w> oh hey, Debian release due. That's going to require some co-ordination with the importer and Launchpad
[21:18] <poolie> good morning
[21:22]  * jelmer waves
[21:29] <poolie> hi jelmer; what are you up to now?
[21:35] <james_w> poolie, drowning me in merge proposals :-)
[21:35] <james_w> but I imagine that jelmer sustains 12 other activities while doing that
[21:51] <poolie> :)
[22:07] <jelmer> poolie: I swear, the VCS imports emails are not my fault :)
[22:15] <poolie> :)
[22:15] <poolie> vila, still awake? we should consider doing a new 2.2.x soon i think, to get the sru going
[22:17] <vila> poolie: yup, the question is: for what value of soon, I thought about it and whether it should be before 2.3.0 but decided that the later was more important
[22:17] <vila> poolie: now, the second question is: ;)
[22:17] <vila> poolie: should I freeze tomorrow or leave a bit of time to packagers,
[22:18] <vila> poolie: but since we use pindependant branches and ppa, there is not a huge incentive to delay
[22:18] <vila> poolie: so I probably freeze 2.2.4 tomorrow unless someone objects
[22:20] <vila> jelmer: ha ! not your fault ! Who else can generate such amounts ?
[22:20] <vila> :-p
[22:22] <vila> OMG ! 23:20 local time ! The jetlag fairy is after me again or what ?  Back to the bed ! Back to the bed !
[22:22]  * jelmer grins
[22:23] <jelmer> vila: g'night :)
[22:23] <maxb> speaking of independent ppas - do we really? normally I would start constructing 2.3.0 in proposed now, which would preclude 2.2.4 in PPA
[22:23] <fullermd> Bed?  The sun isn't even up yet!
[22:28] <vila> maxb: ouch, on the other hand, 2.3 will become the new stable, so all is really needed for 2.2.4 is bzr itself which you could upload directly (or blame the one who fixed the only bug there ;)
[22:30] <vila> maxb, vila (note to self): may be worth documenting
[22:30] <poolie> vila, also, i'd like to choose a good release name with you
[22:31] <poolie> something fun, exciting, and meaningful
[22:31] <poolie> hi jaypipes
[22:31] <vila> hehe
[22:31] <jaypipes> poolie: heyo :)
[22:32] <vila> poolie: for 2.2.4 or 2.3.0 ? And could we do that tomorrow (argh, admin required for family bug :-/)
[22:32] <jaypipes> poolie: ty for your quick response on those bugs/questions
[22:32] <poolie> you're welcome
[22:32] <poolie> vila, 2.3.0 tomorrow sounds' ok; let's not miss the natty boat
[22:34] <fullermd> 'natty boat'?  What an odd release name   :p
[22:50] <mgz> that's a natty boat you're paddling fullermd.
[22:51] <mgz> what's happening with 2.3 and the no whoami case? I thought I read rumblings of wanting to change the behaviour there again.
[22:53] <poolie> hello mgz
[22:53] <poolie> i'd like to change it to use /etc/mailname if it's present
[22:53] <poolie> i guess this missed 2.3.0 but it could make 2.3.1 in natty, possibly
[22:53] <poolie> it seems to be quite a pain point for people doing automatic commits or using bzr to record /etc
[22:54] <mgz> that sounds fine.
[22:58] <mgz> just want to keep coverage where there's really no id, running as www-data and such like already has a few oddities.
[23:27] <fullermd> No update to bookmarks plugin for 2.3   :(