[00:47] <jelmer> maxb: døne
[00:47] <maxb> thanks
[00:48] <poolie> lifeless: hi, re your comments on the export patch
[00:49] <poolie> is a do-nothing generator really the cleanest thing?
[00:49] <poolie> jelmer: ^
[00:51] <jelmer> hi lifeless, poolie
[00:51] <poolie> this seems redundant with observing the exporter writing to the file object
[00:53] <lifeless> wsgi needs a yield in there
[00:54] <poolie> it must pull rather than being pushed to?
[00:54] <lifeless> yeah
[00:55] <poolie> ok, not quite
[00:55] <poolie> there is a write function you can use
[00:56] <poolie> which is what i was remembering
[00:56] <poolie> but it's deprecated
[01:03] <spiv> Good morning.
[01:03] <lifeless> poolie: so you're ok with the approach I suggested?
[01:04] <poolie> it seems a bit ugly
[01:04] <poolie> would be better to actually generate the bytes or something
[01:04] <poolie> but i suppose if you're writing to a local file, it is better to have them written directly
[01:05] <lifeless> its complex generating the bytes:
[01:05] <lifeless>  - first you need the archive layer to put them together
[01:05] <lifeless>  - then pass into the compression layer (when its separate)
[01:05] <lifeless>  - then flush that (which most/all compressors do by pushing through write)
[01:06] <lifeless>  - and finally pull that out of a buffer to yield it
[01:06] <poolie> right
[01:06] <jjohansen> is there a way to get bzr-fastimport to do character mapping to do tag name translation
[01:06] <jelmer> jjohansen: hi
[01:06] <jelmer> jjohansen: not at the moment
[01:06] <poolie> hi spiv
[01:07] <jjohansen> jelmer: thanks
[01:07] <poolie> the failure rate went down?
[01:07] <poolie> lifeless: otoh this will buffer up whole files
[01:07] <lifeless> poolie: yes
[01:07] <lifeless> poolie: however once we emit our first set of bytes haproxy and apache will become happy
[01:08] <poolie> it will avoid them thinking we've died
[01:08] <lifeless> poolie: also, this provide an abstraction layer
[01:08] <lifeless> bzrlib could change this to a threaded implementation
[01:08] <lifeless> and yield multiple times in a big file
[01:08] <spiv> poolie: yes, https://bugs.launchpad.net/udd/+bug/790733 resolved.
[01:08] <lifeless> and loggerhead wouldn't need to change
[01:08] <poolie> oh thanks
[01:08] <jelmer> lifeless: the existing patch doesn't make an abstraction layer possible though, as it still requires a tarfile object to be passed in
[01:08] <poolie> there are a few others from max, you probably saw
[01:09] <lifeless> jelmer: I think geoff has updated it
[01:09] <lifeless> jelmer: I wanted him to do the public api at a slightly higher level
[01:09] <jelmer> l
[01:09] <jelmer> lifeless: there's also some overlap with the existing abstraction layer for exporting to files
[01:10] <maxb> jelmer: Your git and bzr trunks of dulwich appear to have diverged?
[01:10] <jelmer> lifeless: that's not to say I don't like the idea of an abstraction layer for exporting to streams, but it'd be nice to avoid duplicating all that code
[01:11] <lifeless> jelmer: the reason I asked him to patch bzrlib was to avoid duplication
[01:11] <lifeless> jelmer: I haven't re-read his patch yet
[01:11] <poolie> so there's going to be higher-level code that, each time the generator yields, sucks out the file object and sends it back to wsgi?
[01:11] <poolie> in loggerhead, taht is
[01:11] <lifeless> loggerhead will have a file object that acts as a buffer
[01:12] <lifeless> it will pass that file object into bzrlib along with the tree to export etc
[01:12] <lifeless> and then on each yield handoff to wsgi
[01:12] <jelmer> it seems like that sort of code would be nice to have in bzrlib too - so it can be used when e.g. streaming to stdout
[01:12] <poolie> so it will pass something like a stringio?
[01:12] <poolie> and then do yield buf.getvalue()
[01:12] <lifeless> a list of bytes
[01:12] <lifeless> but yes
[01:13] <poolie> hm
[01:13] <lifeless> there is a patch up on loggerhead with his original code
[01:13] <poolie> it does seem a bit like we're reimplementing something that already exists in wsgi or paste
[01:15] <spiv> maxb: hmm, looks like kde-l10n-tg and bittorrent may be the same issue
[01:18] <lifeless> poolie: possibly.
[01:25] <poolie> do we know who blackbug-nx is?
[01:48] <spiv> Hmm, I think 'bzr upgrade' is broken for upgrading stacked-on shared repositories
[01:49] <spiv> Because it tries find_branches which tries to open a branch which is stacked on a different format, which is why I'm running upgrade in the first place
[01:50] <spiv> The other question though is why is e.g. lp:~ubuntu-branches/ubuntu/natty/bittorrent/natty a shared repo?
[01:50] <maxb> That's... interesting
[01:54] <spiv> Heh, and pushing to ~ubuntu-branches/ubuntu/gutsy/bittorrent/gutsy-proposed warns me it won't update its working tree!
[01:55] <spiv> I guess some of these old branches were copied via directly sftp'ing up the local files and directories rather than pushing.
[02:02] <spiv> Ok, looks like I've got the bittorrent package import doing real work now.
[02:07] <lifeless> poolie: thanks for reviewing xaavs thing so clearly
[02:14] <poolie> lifeless: oh are you talking about the little tags?or the review itself?
[02:16] <lifeless> both
[02:17] <poolie> thanks :)
[02:22]  * maxb is working on the residual weirdness of the rxtx import from the bzr sprint
[02:46] <poolie> should we let this blackbug guy into ~udd?
[02:46] <poolie> i'm guessing no, because it would allow merging to the package importer branch
[02:47] <spiv> It's not like udd needs more bugs either ;)
[02:48] <spiv> What do they want to do that requires membership of ~udd?
[02:48] <poolie> i don't know
[02:48] <poolie> this is a persistent problem with moderated teams
[02:49] <lifeless> Decline with a message asking.
[02:49] <poolie> yes
[02:49] <poolie> i filed https://bugs.launchpad.net/launchpad/+bug/792155
[02:49] <poolie> probably a dupe of a six year old mpt bug
[02:50] <lifeless> I think its new actually
[02:50] <lifeless> strongly related to some other things
[02:50] <poolie> yes
[02:51] <poolie> istm there could be a pretty cheap page that just lists every privilege of the team
[02:51] <poolie> or even just _some_ privileges "and more" would be a start
[02:51] <poolie> like: "it has a ppa"
[02:51] <lifeless> mm
[02:51] <lifeless> its a transitive thing
[02:51] <lifeless> it can scale poorly
[02:52] <lifeless> but yes, it should be done
[02:52] <poolie> uh
[02:52] <poolie> knew you were going to say that :)
[02:52] <poolie> cheap to write; perhaps not easily cheap to compute
[02:52] <poolie> which almost implies not cheap to write :)
[02:53] <poolie> but even if you said "plus, all the privileges of _link_ _link_ ..."
[02:53] <lifeless> one of the problems is that 'has privilege' is turing complete
[02:53] <lifeless> it would be good to fix that
[02:54] <poolie> indeed
[02:54] <poolie> i think listing just some of them, the ones that are cheap,
[02:54] <poolie> would let me quickly say "no, i'm not letting random people commit to that branch"
[03:17] <poolie> what is the answer to this? https://answers.launchpad.net/bzr/+question/160044
[03:26] <spiv> poolie: first I'd need to figure out what the question is!
[03:26] <dcoles> Sounds almost like he's talking about multiple repositories in one directory.
[03:26] <dcoles> Rather than two branches from the same project.
[03:27] <spiv> I'm not sure it is actually a question.  It reads more like a blog post about an idea that occurred to the author.
[03:35] <dcoles> But yes. I kind of agree. Sounds like they wanted to give feedback on the colocated branches spec and used the Answers system to do it.
[04:00] <poolie> i agree
[06:33] <poolie> spiv, re bug 792193, it seems like the 500 should be an lp bug
[06:34] <spiv> Yes.  It'd be noticed by the OOPS reports I guess?  It does generate an OOPS code.
[06:34] <poolie> oh maybe
[06:34] <poolie> i believe the practice is to file one anyhow
[06:34] <spiv> I'd imagine it's not too hard for them to fix that 500 to be a 404
[06:35] <spiv> Or maybe 410 Gone?
[06:35] <poolie> yes, let's protect http status biodiversity
[06:35] <spiv> :)
[06:35] <poolie> if it knows it used to exist i think Gone would be good
[06:35]  * spiv files
[07:01] <spiv> wgrant: you maybe know this: where, if anywhere, would I be able to find the conflicting version of linux_2.6.24.orig.tar.gz from https://bugs.launchpad.net/launchpad/+bug/663562 ?
[07:05] <wgrant> spiv: We swore that that file would never see the light of day again.
[07:05] <spiv> Yes, I can imagine :)
[07:05] <spiv> It leaves the package importer in a bit of a quandry though
[07:05] <wgrant> I think we may have deleted it.
[07:05] <wgrant> But let me see.
[07:05] <wgrant> Oh?
[07:06] <spiv> Because it wants to turn that package version into a revision
[07:06] <spiv> And it can't because it can't find the source for it.
[07:07] <wgrant> spiv: Both are still there. Do you know the md5/sha1 of the one you need?
[07:08] <wgrant> b7b63f52551f9e4bf2e5ba902f8385fbefc5d80c is the purged sha1.
[07:08] <spiv> Yes, f09806748f6809d5f7d2a1859240e1a5, a.k.a. not the one currently published
[07:08] <wgrant> I presume that's it.
[07:08] <spiv> (that's an md5, obviously)
[07:08] <wgrant> Right, that one.
[07:09] <spiv> Well, I can sneak it onto a directory on jubany where the importer will find it
[07:09] <wgrant> http://launchpadlibrarian.net/11930615/linux_2.6.24.orig.tar.gz, but don't tell the kernel or security teams.
[07:09] <spiv> Thanks!  I won't :)
[07:09] <wgrant> Or they will find a way to sneak it into the primary archive and destroy a few days again.
[07:10] <spiv> (And I'm glad to see the original bug that allowed it in the first place is fixed)
[07:10]  * spiv hmms
[07:10] <wgrant> It gave us a very unpleasant couple of days, so yes, it was fixed :)
[07:11] <spiv> The importer understandably doesn't really expect this scenario, so I made need to do some hackery beyond just putting that file there…
[07:11] <spiv> But this is a good start, thanks!
[07:12] <wgrant> Yeah.
[07:14] <spiv> (if it finds it has the right filename but wrong md5 it just shrugs and redownloads, but that means it's likely to overwrite the manually downloaded copy in its cache.  we'll see how I go.)
[07:14] <spiv> Once we get past this tricky revision we hopefully never need to care about this situation again.
[07:48] <glob> is it possible to set a 'related branch' on an existing branch?
[07:51] <spiv> glob: probably, what do you mean by “related branch” though?  Something that appears in the “Related branches:” section of 'bzr info' output?
[07:51] <glob> spiv, yes; i am talking about the 'related branches' section of bzr info
[07:52] <spiv> So you can set any of those locations via 'bzr config' (except perhaps “stacked on”, but you can use 'bzr reconfigure' for that one).
[07:53] <glob> spiv, ah, thanks :)
[07:53] <spiv> But there's a fixed set of relationships there, just public, parent, push, submit and stacked-on.
[07:55] <spiv> (Most of those can also be updated by using --remember with the appropriate command, e.g. bzr push --remember NEW_LOCATION)
[07:56] <spiv> Goodness, I think I really have convinced the package import of 'linux' to make more progress
[07:57] <glob> spiv, are those config changes local only?  can i make them the default for anyone else who checks out the branch?
[07:59] <spiv> If you set them on the branch (bzr config --scope=branch, or by editing .bzr/branch/branch.conf by hand), then yes they'll be the default for other people.
[07:59] <glob> excellent, you have been a wealth of knowledge, thanks :)
[08:00] <spiv> (Well, the stacked on location won't be, but again it's a bit special)
[08:00]  * glob is setting submit_branch
[08:26] <poolie> jam: don't suppose you're here yet?
[08:36] <maxb> So, since people are busily UDD-ing, what do you think of my either-or on bug 708655 ?
[08:38] <poolie> oops
[08:38] <poolie> i actually did the deletion and requeeu
[08:38] <poolie> oh, actually only the deletion
[08:38] <poolie> will do the other part now
[08:40] <spiv> maxb: have you seen my latest comments on https://bugs.launchpad.net/udd/+bug/792193 ?
[08:41] <maxb> um
[08:41] <maxb> Thorny problem. I don't have an answer without studying the code for a while
[08:41] <spiv> I'm getting close to the end of my day (and week!) but if you can help me understand the impact of that situation that'd be lovely
[08:41] <poolie> good morning vila
[08:41] <spiv> Ah, that'll do for now :)
[08:42] <poolie> spiv, i'm getting close to the end too
[08:42] <poolie> i was thinking a bit about bug 257217
[08:42] <maxb> Presumably I can set this import up myself by just seeding the download cache with the "odd" version from the librarian?
[08:42] <poolie> and the conversations in london about this kind of thing
[08:42] <spiv> But I do see light at the end of the tunnel for that import, which is nice.
[08:42] <poolie> about error handling and so on
[08:42] <poolie> perhaps i should post to the list
[08:42] <spiv> maxb: yeah, although of course it's a pretty resource-intensive import
[08:42] <poolie> the idea of a crash-only design seems to make sense
[08:43] <maxb> I'll abuse my office workstation with it over the weekend :-)
[08:43] <spiv> maxb: FWIW it took ~1400s to reach the point where it used to crash on jubany, and if left to run to completion would probably take... hmm, not sure, but possibly days!
[08:44] <spiv> I suspect when 2.4 is released and we put that on jubany it'll help the performance somewhat.
[08:44] <maxb> Maybe I should hack the code to ignore the existence of all series after hardy
[08:44] <spiv> Maybe only a little, but I can be optimistic :)
[08:44] <poolie> there's no reason we can't run the betas
[08:44] <maxb> lamont was definitely working on a 2.4b2 IS-blessed package
[08:45] <spiv> poolie: well, except that the last time we updated to a beta on jubany there was some fallout due to plugin breakage or something like that IIRC
[08:45] <poolie> mm
[08:45] <poolie> could well happen
[08:45] <poolie> we could just try running it from source
[08:45] <spiv> It was fairly easily resolved, but it does push the “upgrade bzr” task past the <"trivial, just do it” threshold.
[08:46] <poolie> true
[08:46] <poolie> so essentially i'm thinking of marking 257217 wontfix
[08:46] <poolie> to say that we handle closing windows by detecting the lock is stale
[08:48] <spiv> Hmm, I think so.
[08:48] <spiv> In general I think it's nice to make a best-effort attempt to cleanup when things go wrong or the process gets interrupted.
[08:49] <poolie> i'm coming to think that it may be 'nice' but it's not actually sensible
[08:49] <spiv> But in this case the risk of EINTR etc by intercepting SIGHUP means it's probably not worth the tradeoff.
[08:49] <poolie> like, the general skew should be more towards nicely recovering from an interrupted situation
[08:49] <spiv> And I definitely agree that it's far more important to recover gracefully on the next run
[08:49] <poolie> because you will hit that anyhow
[08:50] <spiv> So I'd much rather we put effort into graceful recovery than dubious cleanups while crashing.
[08:50] <spiv> Which is a long-winded +1 for me for Won't Fix.
[08:51] <poolie> :) thanks
[08:54] <spiv> Ok, I'm off.  Have a good weekend everyone!
[08:54] <poolie> cheerio, have a good weekend
[08:54] <poolie> maybe i will stop too
[08:56] <spiv> poolie: perhaps take a final re-review of that export patch first?
[08:56] <spiv> (if you haven't already?)
[08:56] <spiv> Ok, really gone now :)
[08:56] <poolie> which?
[08:56] <poolie> oh from um xaaz?
[08:56] <poolie> ok
[08:59] <maxb> poolie: Can I ask you to kill the sysvinit import? Ironically I've just found and fixed a bug I introduced during the bzr sprint which will cause the importer to produce slightly suboptimal history for packages being freshly imported with history in etch and earlier.
[09:00] <poolie> spiv, beyond my sure
[09:00] <maxb> So, I'm hoping we can defer the sysvinit import until that can get reviewed and deployed
[09:00] <poolie> blah
[09:00] <poolie> maxb, sure, how?
[09:00] <maxb> figure out the pid and kill -INT it?
[09:01] <poolie> done
[09:01] <maxb> thanks
[09:01] <maxb> I'll update the bug
[09:01] <poolie> thank you
[09:49] <jelmer> Riddell: do you know if syncs are happening at the moment?
[09:49] <jelmer> Riddell: I mean, whether manually requested syncs are processed?
[09:50] <Riddell> jelmer: yes should be
[09:57] <poolie> hello riddell, jelmer
[09:58] <Riddell> good morning poolie
[09:58] <jelmer> hey poolie
[09:59] <lifeless> poolie: hi
[09:59] <lifeless> poolie: you're not in #launchpad-dev
[09:59] <poolie> huh
[09:59] <lifeless> poolie: but I don't agree with your approach on the mail handling patch; I've replied in mail - and had already suggested an approach in the bug.
[09:59] <lifeless> poolie: I'm glad you're hacking on it.
[10:00] <poolie> hm, i thought my approach was consistent
[10:01] <Riddell> poolie: what was the rt ticket for adding me to jubany (asks the sysadmin vanguard)?
[10:01] <poolie> 45864
[10:02] <lifeless> poolie: if my mail resolves things great; if not I can chat about it so we get a consistent view on things anytime
[10:07] <gour> are you aware that PHP is considering switch from SVN and only hg & git are discussed?
[10:09] <AuroraBorealis> so?
[10:09] <AuroraBorealis> post on on the mailing list advertising for bzr, if not then oh well :>
[10:11] <gour> such tasks are for bi fishes since the migration is very often not based on technical merits but it's political issue
[10:11] <gour> *big
[10:12] <AuroraBorealis> pretty much
[10:49] <gour> i'm reading about Advanced shared repository layouts (http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/shared_repository_layouts.html) and wonder how relevant it is when one uses LP to host project's branches? to me it seems not so much and for my local organization it's anyway not a problem..
[10:50] <AuroraBorealis> it seems that launchpad is the repo
[10:50] <AuroraBorealis> and you can branch and submit those branches to lp like you would anywhere else
[10:52] <spiv> gour: Launchpad automatically arranges for branches to be stacked, so you don't need (and actually can't use) shared repositories on its code hosting server
[10:54] <gour> spiv: good...one headache less ;)
[10:56] <spiv> (And Launchpad also enforces a particular, consistent hierarchy; typically ~owner/project/branch-name, with some shortcuts and a slightly different scheme for branches of distro packages)
[10:56] <gour> now i'm researching about rebase7rewrite plugin...not considering git's feature but more from the darcs/fossil perspective and their 'private' branches which help to have 'nicer' history
[10:57] <spiv> The first question is “why do you care about making 'nicer' history?”  bzr's default presentation of just the mainline in 'bzr log' etc typically gives a similarly nice view without throwing away any history.
[10:59] <gour> in case when i do some 'experimental' commits in a 'feature branch' and then would like that during merge it's presented as 'one nice patch', is it the right use-case?
[10:59] <spiv> Well, you get to choose the use cases, you're the user ;)
[11:00] <gour> heh...doing commit/uncommit, making mistakes etc. is, maybe, not so nice/important to keep in the history
[11:01] <spiv> But I'd first check if the default operation of "bzr merge" and "bzr commit" for that does something you like or not.
[11:01] <spiv> I think you may find that actually you're happy with that without rebasing.
[11:02] <spiv> (Or maybe not.  Personally it suits me quite well.)
[11:02] <gour> spiv: you mean, you don't have need for rebase?
[11:02] <spiv> I do use uncommit quite frequently :)
[11:02] <spiv> I can't remember the last time I rebased.  Probably many months ago.
[11:02] <AuroraBorealis> what is rebase?
[11:03]  * gour is re-reading http://bemusement.org/diary/2008/July/29/rebase-criticism
[11:03] <spiv> gour: that would be my website :)
[11:03] <Riddell> yay, I have access to jubany
[11:03] <gour> AuroraBorealis: http://wiki.bazaar.canonical.com/Rewrite?action=show&redirect=Rebase
[11:04] <gour> spiv: heh, interesting...i remember it was good read, but it looks i forgot the wisdom ;)
[11:04] <AuroraBorealis> ah
[11:04] <spiv> gour: :)
[11:04] <spiv> gour: thanks!
[11:06] <spiv> To an extent I don't think it matters hugely if you rebase or simply merge; it's usually pretty rare for someone to actually spelunk through old history in enough detail that the difference would matter much.  But given that, you may as well do the simpler of the two: just merge.
[11:07] <spiv> It mostly is a question of how you want to present your changes to someone else to get them accepted to their branch.
[11:09] <gour> it makes sense...
[11:09] <gour> btw, i've decided to use LP with or without wiki ;)
[11:09] <spiv> gour: :)
[11:09]  * spiv wanders off for dinner
[11:10] <gour> now we're coming to looms..
[11:25] <gour> now, after brief look at looms, i wonder i part of its functionality is available by using shelves to keep it simpler
[11:52] <Riddell> jelmer: thanks for the changelog-closes-bugs review, I didn't write a test because I've no idea how to run the test suite for bzr-builddeb, can you tell me how?
[11:53] <jelmer> Riddell: anytime, this will be a neat feature to have :)
[11:53] <jelmer> Riddell: You can run them using "bzr selftest bzrlib.plugins.builddeb" or (shorter variant) "bzr selftest -s bp.builddeb"
[11:54] <jelmer> Riddell: if you're not working in the version of bzr-builddeb you currently have active, you can use BZR_PLUGINS_AT
[11:54] <jelmer> I usually run something like this in my active bzr-builddeb branch:
[11:54] <jelmer> BZR_PLUGINS_AT=builddeb@`pwd` bzr selftest -s bp.builddeb
[11:55] <Riddell> ah hah right, I should have been able to work that out
[12:59] <jelmer> Riddell: just noticed - there's a find_bugs_fixed convenience function in builddeb's util.py you should be able to use
[13:28] <Riddell> I'll take a look
[15:29] <Riddell> jelmer: updated
[15:33] <jelmer> Riddell: reviewed.
[15:34] <Riddell> thanks jelmer, do you know if bzr-builddeb has a NEWS type file?  I can't see one
[15:35] <jelmer> Riddell: that's a good point
[15:35] <jelmer> Riddell: it's a native package, so we add entries to debian/changelog
[15:35] <Riddell> ah right
[15:36] <Riddell> well it can't be merged in until https://code.launchpad.net/~jr/bzr/707274-commit-message-hook/+merge/62334 gets merged anyway
[15:36]  * jelmer takes the hint
[15:36] <jelmer> ;)
[15:36] <jelmer> I'll have a look after I wrap up my current branch
[15:40] <Riddell> jelmer: "We usually stick to one single summary line in docstrings"  why, surely it should be as long as it takes to clearly describe it?
[15:40] <jelmer> Riddell: sorry, that could've been worded better
[15:40] <jelmer> Riddell: we usually have one sentence on a single line with the summary and then more lines for further explanation
[15:42] <jelmer> doc generators often only display the first line in various places so if the initial sentence spans multiple lines it cuts the sentence off halfway
[15:47] <mgz> it's also a good habit to say what a function's for in ~60 characters
[15:48] <jelmer> mgz: I guess that's what I'm trying to say.
[15:48] <jelmer> mgz: But you managed to do it in 60 characters rather than 4 lines :)
[15:50] <mgz> :)
[16:41] <mgz> gah, will have to leave bzr things for another day again
[16:41] <mgz> still haven't replied to that cycles thread on the list
[21:17] <jelmer> lifeless: hi
[21:17] <lifeless> hi
[21:18] <jelmer> lifeless: what's the best way to QA the code importers? As I understand qastaging doesn't come with its own import slave?
[21:18] <lifeless> dunno
[21:18] <lifeless> have a chat with losa
[21:19] <jelmer> hmm, ok
[21:25] <lifeless> generally we can't run stuff that talks to external servers in *staging
[21:25] <lifeless> so its tricky
[21:33] <jelmer> lifeless: thanks; that's not the answer I was hoping for.. :)
[21:33] <jelmer> I'll talk to a losa first thing on Monday
[22:29] <maxb> jelmer: Hi. Your bzr and git branches of dulwich seem to have diverged