[00:18] Hey poolie. [00:19] The Bugzilla Project is thinking about switching to bzr: https://bugzilla.mozilla.org/show_bug.cgi?id=bz-bzr [00:19] :D [00:20] And related discussion thread here: http://groups.google.com/group/mozilla.dev.apps.bugzilla/browse_thread/thread/8f1d9255845b3794 [00:21] mkanat, I'm really not here, but, you have my full support to get Loggerhead into the shape you need [00:22] beuno: Sweet. [00:22] ping me with the bugs you want me working on, and I'll focus on them :) [00:22] beuno: I filed one just today. [00:22] mkanat, and I confirmed it and marked it as high [00:23] beuno: Great. :-) [00:23] mkanat, just make sure that I'm aware of your major pain points, I tend to drift ;) [00:23] beuno: Okay, cool. :-) [00:28] mkanat: do you have many developers on Windows? [00:29] markh: We have some, yeah. [00:29] markh: And we keep our VCS stuff in all our tarballs. [00:29] will EOL support be an issue? [00:29] markh: So users will end up using bzr, too. [00:29] markh: Hm? [00:29] IIUC, your cvs repo will have \r\n line endings on windows [00:29] Ohh. [00:29] well - the windows checkouts of the repo [00:30] markh: What does bzr do with EOLs now, just leave them as they are in the repo? [00:30] yeah - nothing [00:30] so bzr checkouts on windows will have \n [00:30] but this is being worked on [00:30] markh: I think that's OK, actually. [00:31] markh: Since we're a web app. [00:31] markh: We have problems with that anyway, right now, so we have to deal with it on our end. [00:31] diffing a cvs and bzr tree becomes hard, for example, and "dumb" editors will have trouble. But in practice, it often isn't really a problem. [00:33] silly things like the patch tool I use always converting files to \r\n is annoying - for large projects in the meantime, a hook that *prevents* \r\n checkins might help for the future too. [00:34] I'm pretty sure it's all mixed up currently in our CVS repo. :-) [00:34] heh - no problem then - bzr has exactly the support you need ;) [00:41] :-D [00:47] beuno: Is Search supposed to be working in 1.6? The relnotes seem to indicate so, but it doesn't seem to quite be working, even with bzr-search installed and the branches indexed. [00:56] beuno: Our Loggerhead is at http://bzr.bugzilla.org/ and it allows access to the .bzr directories too if you want to poke around and figure out why search isn't working. [00:56] beuno: (e.g. http://bzr.bugzilla.org/bugzilla/trunk/.bzr/ ) [01:02] mkanat, you need to have the bzr-search plugin installed [01:02] beuno: I do. [01:02] and index each branch one time (bzr index) [01:02] beuno: You can see the indexes in that link there. [01:02] mkanat, ah [01:03] mkanat, does bzr search work through the terminal? [01:03] beuno: It does. [01:03] bzr-1.9 FWIW. [01:04] mkanat, it should work, lifeless made sure it did [01:05] * beuno thinks [01:05] beuno: This is python-2.4, also. [01:05] beuno: And the only thing I don't have is sqlite3, as far as loggerhead's prereqs go. [01:05] At least, as far as I know. [01:06] mkanat, sqlite will just improve performance, but everything should work without it [01:06] are you using loggerhead's trunk? [01:06] beuno: No, 1.6. [01:06] I'm using the tip of whatever 1.6 branch is right now. [01:06] mkanat, ah, go for trunk. It has the work for 1.9 [01:07] I'll be making a new release soon [01:07] beuno: Ah, okay. :-) Is trunk stable enough to use right now? [01:07] mkanat, yeap, much better than 1.6! [01:07] beuno: Great! [01:08] mkanat, in general, trunk is pretty stable. We try and not do any crazy stuff in trunk :) [01:08] beuno: Okay, great. :-) [01:08] beuno: I'll just run trunk then. [01:09] mkanat, let me know if that fixes the search issues [01:12] beuno: Yeah, that fixes it. :-) [01:14] Really, overall, loggerhead is great. [01:14] Probably the best code browser for any VCS. [01:14] Anyhow, I'm off for the night. [01:14] Later! [01:18] :) === AfC1 is now known as AfC [02:25] man, loggerhead is terrible [02:26] i can believe that other code browsers are even worse though :) [02:29] viewvc isn't so bad [02:29] although it doesn't map easily to bzr [02:49] i love viewvc [03:04] is there some easy way from the command line to write lock and then unlock a branch? [03:04] i guess it would be a very easy plugin... [03:10] what would be the point? [03:11] obscure details of how launchpad works :) [03:11] (i.e. it would make my job a teensy bit easier) [03:19] mwhudson: lock the branch then sys._exit()? [03:19] no, nothing so fancy [03:22] i think http://pastebin.ubuntu.com/90483/ does what i want :) [03:23] mwhudson: except lock_write, right? [03:23] uh [03:23] yes [03:24] sshfs + flymake-mode considered irritating [04:05] hm, is there a hook or someway to be notified whenever an init-repo is performed? (code-wise) [04:29] rocky: I don't *think* so. [04:29] rocky: what do you want it for? [06:06] markh: just posted a review of your cicp patch (at last!) [06:19] jml, are you still around? [06:19] I am. [06:19] poolie: what's up? [06:20] i wanted to check about this progress bar thing [06:20] poolie: ok. I've got to head out soon. Should I skype you or something? [06:21] i'd like to finish soon too [06:21] sure let's talk there [06:22] "Call refused" [06:43] igc: excellent, thanks. You may be correct that special-casing mv and add might be best. The rest are nice and easy :) [06:43] (and many I should have known better - leading _, double space :)) [06:43] markh: cool. I was thinking re ongoing support of the feature as much as anything [06:44] yeah [06:44] choosing the word "canonical" to describe the feature is working against the 1-line docstrings too :) [06:45] markh: btw, going over 80 chars on that one line is fine if required [06:45] oh - excellent! [06:56] poolie: so I'm adding base classes for wt4 and later workingtrees as discussed [06:56] are the names _DirStateWorkingTree and _DirStateWorkingTreeFormat ok with you? [08:02] Hello, I'm playing around with a project whose build environement is heavily path dependent and I would like to know if it is possible to easily manage several "branches" in a single directory with bzr. Thanks. [08:05] dD0T: Kind of. Pretty much. [08:06] dD0T: As I understand it, a branch is a directory. But you can do what you want by using checkouts of local branches and switching between them with 'bzr switch'. [08:09] RAOF: So I would keep my branches somewhere and "switch" to lightweight checkout of the one I want to work on in the directory specified by the build environement? [08:09] Yes. [08:09] Exactly. [08:09] ROAF: Sweet ;-) I guess that's good enough for me. [08:10] ROAF: Thanks for you help! [08:12] Great :) [08:14] Just out of curiosity. Anyone got a clue when windows binaries for the new version will be available? [08:55] * igc dinner - night all [10:22] dD0T: There's a problem with the Windows build machine. I don't know of an ETA for fixing it and building 1.10. [10:30] Peng_: :-( Anyway. Up to now I found nothing terribly wrong with 1.09 so I can wait. [10:57] * markh should just make them again :) [10:59] hi, I've got a quick question: I know a change was made in a merged revision (let's say 45.1.2), is there a easy way to get the revision number of the merge? [11:00] I'd just run "bzr log | less" and search for the revision, but I don't know if there's a better way. [11:01] There isn't a UI way I can think of, certainly. [11:02] Peng, yeah that's similar to what I'm doing, but it can be terribly difficult [11:03] I'm fine with every bzrlib piece of code, if there is something, [11:03] but I don't know the magic of bzrlib enough do code it myself ;) [11:08] I'd just use bzr qlog, and click on revision links until I find the merge [11:09] thekorn, if you want to know what mainline revision a dotted revno belongs to, there's no easy way to do it with bzrlib [11:10] luks: hi! [11:10] beuno: no easy way? simple iterate over parents backwards [11:10] hi markh [11:12] luks, well, yes and no. Because you can have multiple parents. [11:12] and, getting the revision graph from a big branch is pretty expensive [11:13] revision numbers depends on the whole revision graph anyway, you can't work that around [11:13] so as soon as you want to translate 45.1.2 to a rev_id, you already have the whole graph loaded [11:13] that's true [11:14] there's something to load mainline revnos lazily, but not dotted ones === Mario__ is now known as pygi [11:41] Hi, I would like to know if it is safe to push a repository to a central directory on a shared directory. How Bazaar handles concurrency ? === Tobbe is now known as Tobbe|autoaway === Tobbe|autoaway is now known as Tobbe === kiko is now known as kiko-afk [12:48] ok, thanks beuno, so I will go on with grepping in the output of bzr log, but that's ok [13:36] Hi there [13:36] Is there a way to see what's in a repository? === kiko-afk is now known as kiko [13:37] I have a shared repo with other shared repos underneath, and I'd like to be sure the real data are in the sub-repos. === thekorn_ is now known as thekorn [13:47] Lo-lan-do: which data? [13:47] Revisions and what they contain [13:47] right, but not some random revisions I suppose [13:48] bzr check on a branch at least will check for ghosts [13:48] Lo-lan-do: what situation are you guarding against? [13:48] Yeah, I'll try and be more precise, sorry. [13:49] I have several repositories under a common directory. [13:49] ~/bzr-repo/gforge, ~/bzr-repo/client-1, and so on. [13:50] They all contain branches which seem to work (at least, I can't see any problems with them) [13:50] However, I just realised that ~/bzr-repo is also a repository itself. It has a .bzr subdirectory, which contains knits and whatnot. [13:51] I'd like to know if I can zap it, but for that I'd need to be sure that there's nothing important in there. [13:51] ah, right, yes. [13:52] Lo-lan-do: branches store their revisions in the first repo above them they find, if all branches work fine, then nothing uses the one above. Of course, you need to be sure they work fine then. [13:52] Lo-lan-do: you can use `bzr heads` on the repo to get an idea of what is inside. [13:53] Thanks [13:53] (it would be possible to have ~/bzr-repo/somedir/branch, then make ~/bzr-repo/somedir a repo too, and have branch miss the earlier revisions) [13:54] commandline bzr will refuse to make somedir a repo though, but with mv being careless it could happen [13:54] * LarstiQ goes afk for dentist [13:54] Good luck, and thanks, it does list a few heads. [13:55] (dead ones) [13:56] none of the dead heads is in the ancestry of live branches you care about? [13:57] yay transitivity, and now really gone [13:57] Not sure, I'll grep [13:59] Hm. They all are. [14:01] But moving ~/bzr-repo/.bzr to someplace else doesn't seem to break anything in these live branches, so I guess I'm fine. [16:33] Anyone use cherrypicking routinely in their workflow? [16:34] I'm wondering if there's a decent way to a) review the changes from a branch and b) selectively merge those into a feature branch (or the upstream branch) [16:35] Obviously there's "diff", but I'd like a streamlined approach that let me review each revision and decide whether to merge it or not. [16:36] Then there's "log", which of course gives me the list of revisions. [16:36] I guess I'm looking for something that stream lines that process. Kinda like an unshelve style interaction. === kiko is now known as kiko-afk === salimander__ is now known as Suigintou === Pilky_ is now known as Pilky === asabil__ is now known as asabil_ === asabil_ is now known as asabil [18:38] mwhudson, I'm releasing a new version of LH today [18:38] it's been too long, and too many people use releases [18:38] also, I'll push packages to a PPA [18:39] beuno: Yay. :-) [18:39] mkanat, and after that, I'm tackling the latest bug you filed. That's my priority list ATM for Loggerhead :) [18:40] beuno: Great. :-) [18:40] I wonder if there are any other Bonsai features that people are going to want... [18:40] Oh, date limiters, probably. [18:40] mkanat, we can easily do that [18:41] also [18:41] That'd probably make you guys pretty much functionally equivalent to Bonsai. [18:41] And so much nicer. [18:41] if you want a nice theme for bugzilla, let me know, I have a week or so off coming up ;) [18:41] beuno: Ooooh. :-) [18:42] beuno: Even if you just wanted to play with our Skins (which is just CSS stuff), that'd be fun. :-) [18:43] mkanat, sure. I'll add that to my list as well then. [18:43] Sweet. :-) [18:43] We're also doing some usability work with NASA and the whole Mozilla UX team, too. [18:44] although, a theme may kinda force you to merge from trunk. It kinda sucks how we do themes today. [18:44] oh, very cool [18:44] beuno: Although actually, the default loggerhead theme is probably fine. [18:44] beuno: I misunderstood you and thought you meant for Bugzilla itself. :-) [18:45] beuno: That's where the seemingly non-sequitur comment about our UX work came from. [18:45] mkanat, well, we can slap a header with a logo on there [18:45] heh, right [18:45] I'd love to help out there as well [18:45] That's a much bigger sort of project, though. :-) [18:45] but time, as it turns out, is very limited :) [18:45] Hahaha, yeah. [18:48] beuno: Oh, it looks like you guys already have date stuff? https://bugs.launchpad.net/loggerhead/+bug/121719 [18:48] Ubuntu bug 121719 in loggerhead "need more discoverable search facilities" [Undecided,Confirmed] [18:48] beuno: Maybe just a [Help] link for the search box... [18:49] mkanat, we do, although it's a bit cryptic, and I'm not sure if it still works when bzr-search is installed [18:49] Ah, okay. [18:49] so I didn't want to confirm until I tested it [18:49] that's kinda why I said it was easy ;) [18:49] Ahh, okay. :-) [18:54] * emmajane waves :) [18:56] emmajane: hi! [18:56] jelmer, hey :) [18:56] jelmer, any new and exciting stories for today? [18:57] not yet, but hopefully bzr-git should be supporting imports from git by the end of today [18:57] WOO [18:57] Jc2k, hi! [18:58] * emmajane has a new question about bzr. [18:59] I tried to "pull" some XML files for the desktop course. but got an error that I'd diverged. [18:59] So I merged instead and it said I'd merged....but I think it should have taken longer. [19:00] emmajane, merging should be pretty quick if you tried to pull earlier, since it would've already retrieved all the data from the remote branch [19:00] the pull was almost instantly rejected... [19:01] emmajane, did "bzr merge" show a summary of changes that you expected? [19:01] no. :/ it just said, Merging from remembered location bzr+ssh://emmajane@bazaar.launchpad.net/~canonical-training/ubuntu-desktop-course/ubuntu-desktop-course-beta/ All changes applied successfully. [19:01] I think it's lying. [19:02] jelmer: sounds exciting! [19:02] jelmer: and useful for me! [19:03] emmajane: You could do "bzr status" [19:03] AHA, that's more useful, thanks mkanat [19:04] mkanat, now I can see there is one pending merge. [19:04] emmajane, the merge didn't bring in any actual file changes, but it did bring in a new revision [19:04] jelmer, There have been branches merged since I last made updates though. [19:04] emmajane, perhaps both branches contained the same changes, but those changes were committed in both independently? [19:05] jelmer, wishful thinking. :( [19:05] i've seen that before when i made the same change to my branch of dulwich as jelmer did :p [19:05] emmajane@gollum:~/ubuntu/ubuntu-desktop-course$ bzr status [19:05] pending merges: [19:05] Belinda Lopez 2008-12-10 Merged corrections to front matter and chapters 1... [19:06] (what's the rule on pastebin? how many lines of spam do I need before I start getting thwacked?) [19:07] emmajane: No more than three lines, in most channels. [19:07] kay :) [19:08] To me "pending merge" implies, "not done yet." Does that seem right? [19:08] emmajane, they are merges that are already in your working tree but not committed yet [19:09] jelmer, so they are downloaded? [19:09] emmajane, yes, and applied to the working tree (if they made any changes) [19:09] excellent, thanks jelmer [19:15] And now the status returns no text. [19:15] * emmajane thinks that dancing elves might be a nice touch. That sing a little midi tune to tell you there are no changes and no errors. [19:15] just an idea. ;) [19:17] Hmm, pygame could handle that, right? [19:17] * emmajane chuckles. [19:18] Peng, for the bzr v 99837.7 beta release? :) [19:19] I'll put it on my to-do list. I'll probably have learned bzrlib and pygame by then, right? :D [19:19] lol :) [19:20] I love it. :) [19:20] * emmajane will learn how to make midis. [19:21] :D [19:25] Can't use authentication.conf with bzr-svn and googlecode.com passwords. Although I have the correct password in authentication.conf it still gives me "ERROR: Permission denied". If I remove authentication.conf and enter the password by hand it works, I have triple-verified the password [19:26] but also, it asks for the password 3 times each branch I try [19:26] and that is annoying [19:27] nosklo, do you have the username specified in authentication.conf ? [19:28] jelmer, yes, and I am also specifying the same username in https://user@project.googlecode.com [19:28] because otherwise bzr-svn won't kick up, and it will try to branch a bzr repository which will also fail [19:29] nosklo, there is an open merge request for bzr about this I think [19:29] jelmer, cool, can I pull it [19:30] nosklo, when bundlebuggy gets back up :-/ [19:30] abentley, ping [19:30] I love bzr, but bzr-svn is not up to the task yet [19:30] nosklo, this particular bit is a bzr bug [19:31] nosklo, at least as far as I can see [19:31] I am trying to move everything I have to bzr [19:31] git-svn seems to work better for now [19:31] nosklo, what's problematic about bzr-svn? [19:32] jelmer, well, it can't detect I am using svn, if I use just a http url it fails to try it as svn [19:32] jelmer, I have to use svn+http or use username@host to make bzr-svn try the url [19:32] nosklo, again, that's a bzr bug - you can workaround [19:32] nosklo, it by specifying svn+http:// [19:32] beuno: Did jelmer tell you about some of the wishes we have for LH on alioth.debian.org? [19:33] Lo-lan-do, Hi [19:33] Hi jelmer :-) [19:33] Lo-lan-do, yeah, we discussed it here a couple of days ago [19:33] jelmer, the other problem I have is that it asks for authentication 3 times each branch I make :) [19:33] Great [19:33] Lo-lan-do, hi [19:33] jelmer, did we solve all of them? [19:33] I forget :) [19:33] typing generated passwords of letters and numbers 3 times each branch, is... annoying [19:33] nosklo, as I mentioned, please use svn+https:// [19:34] nosklo, that way regular bzr probing is skipped [19:34] beuno, hey :) [19:34] beuno, Well, start-loggerhead/stop-loggerhead are still present :-) [19:35] hey hey emmajane [19:35] beuno, are you back in the land of warmth and sunshine? :) [19:35] jelmer, ah. Well, I'll make it a goal for the next release to remove them and substitute all functionality with serve-branches [19:35] I'm releasing Loggerhead 1.10 *today* [19:36] .10? [19:36] beuno: Good news :-) [19:36] ah, cool [19:36] hi beuno :) [19:36] Not .7? [19:36] hey Jc2k [19:36] Peng_, we're following bzr's versions [19:36] beuno: ah. [19:36] as counter-intuitive as that is :) [19:36] You should follow bzr, only backwards...somehow. :) [19:36] I'm open to suggestions if you guys think that's too crazy [19:37] jelmer, okay, thank you. It says its deprecated but works. But it is still asking 3 times for the password [19:38] jelmer, I'm going to upload this release to PPA [19:38] nosklo, if you run "svn ls" or something on the URL once, it will cache that in ~/.subversion and bzr-svn will use those credentials [19:38] nosklo: Yeah, "svn+" is officially deprecated, but still has a purpose. [19:38] jelmer, have you updated your packaging branch to reflect the dependency changes? [19:38] Dependency changes? [19:38] beuno, yeah [19:39] beuno, please let me know when 1.10 is out, so I can upload to debian :-) [19:40] jelmer, if everything goes well, in about 20 minutes, but I will ping you :) [19:42] mkanat: BTW, did you see my comment on bug 240577? [19:42] Launchpad bug 240577 in loggerhead "Loggerhead should be able to serve branches through http" [Undecided,Confirmed] https://launchpad.net/bugs/240577 [19:42] ubottu: botsnack [19:42] Peng_: Oh, true. [19:42] Yum! Err, I mean, APT! [19:50] jelmer, https://code.edge.launchpad.net/loggerhead/1.10/1.10 [19:50] beuno, awesome, thanks [19:50] beuno, tags? [19:50] jelmer, loggerhead-1.10 on trunk [19:52] beuno, yay :) [19:53] beuno, loggerhead/__init__.py still says 1.6 [19:54] dang [19:55] jelmer, I'll remove/add the tag again [19:55] and push to lp:loggerhead/1.10 [19:57] jelmer, done [19:57] thanks [19:57] I'll re-create the tarball as well === vednis is now known as mars [20:08] beuno: I've updated the packaging branch [20:09] jelmer, you have the full release in that branch? [20:09] beuno, yes, it's an ancestor of lp:loggerhead [20:10] jelmer, so what do you use to create the package? [20:10] not the tarball? [20:10] beuno: The upstream tarball is generated from lp:loggerhead, by exporting the relevant tag/revision [20:10] I was thinking about using the scripts in bzr.dev/tools/packaging/* [20:11] jelmer, so why do you have all the files in the branch then? [20:11] beuno, Building it should be as simple as "bzr builddeb" [20:11] beuno, the files in the branch are used to generate the debian diff [20:12] jelmer, so you merge into that branch for each release? [20:12] I'm getting no revisions to pull on the debian branch [20:13] beuno, yes, I merge for each release (using "bzr merge-upstream" (from bzr-builddeb)) [20:13] beuno, launchpad may not have mirrorred it yet [20:13] http://bzr.debian.org/pkg-bazaar/loggerhead/unstable is the original URL [20:14] (fwiw, all bzr-related packages for debian use this structure atm) [20:14] * beuno has to learn to use bzr-builddeb [20:14] in your spare time, eh beuno ? :) [20:15] emmajane, I haven't seen any of that in a while! [20:15] beuno, I hear it goes on sale in the new year!! [20:15] * beuno will be in the front of the queue waiting [20:15] :) === asac_ is now known as asac [20:43] jelmer, well, it works, after svn ls it does not ask anymore for auth, even without authentication.conf - it seems to read svn authentication. I had to install subversion though [20:44] jelmer, is it a bug? shouldn't it ask only once and use the same name/password pair for all subsequent requests, at least on the same session? [20:44] jelmer, Is there something I can do to help? [20:45] nosklo: basically, this requires some improvements of the credentials layer in bzrlib that vila has been working on [20:46] nosklo, hopefully that will also allow bzr to in the future write credentials to authentication.conf rather than just reading them from there [20:47] jelmer, yeah, even reading from there seems broken... but anyway, I got mine to work, thanks again. [20:47] I'm not entirely sure why specifying them manually in authentication.conf doesn't work [20:47] nosklo, any chance you can file a bug about that bit? [20:49] jelmer, of course, you got it. I will start with a fresh environment and put it in a way you can reproduce. Where do I file the bug, malone? [20:50] nosklo, yep - http://launchpad.net/bzr-svn/+filebug IIRC [20:50] what exactly does bazaar do? [20:51] abouche2, there's a really great documentation site that explains some of the basics: http://bazaar-vcs.org/ [20:52] awww. [20:53] * emmajane was just getting started! [20:54] wise man ;) [20:56] jelmer, is there any way I can have the equivalent of debuild -S with bzr-builddeb? [20:56] I think "bzr builddeb -S" is the equivalent [20:57] * beuno tries for the 6th time to get the package into a PPA [20:57] beuno, what's being problematic? [20:58] jelmer, I am :) [20:58] I mean, what's preventing it from getting into PPA ? :_) [20:58] Or do you mean it's a PEBKAC? [20:59] I haven't used builddeb, so I'm going ahead with "trial and error" instead of "reading documentation" [20:59] beuno, *grin* [20:59] so PEBKAC I guess [20:59] emmajane, :) [21:00] emmajane, the suggestion is pretty good though [21:00] * emmajane chuckles at beuno's aversion to documentation. [21:00] I promise it's not ALL bad. [21:00] emmajane, I'm not taking any risks today ;) [21:00] * emmajane grins. [21:01] give me an hour, I'll whip up a screen cast. ;0 [21:01] ok, maybe four. I'd need to read the documentation first. [21:02] heh [21:06] Hi [21:06] * emmajane waves to RainCT [21:06] * RainCT waves back :) [21:07] Is there some FLOSS good bug tracker which supports bzr (so that you can say "I fixed this bug on revision X")? (a friend is asking for this o.O) [21:08] RainCT, like having a project in Launchpad? [21:08] emmajane: yes, but to install on his own server [21:09] RainCT, I believe there's a bugzilla plug-in. [21:09] and can't you install bugzilla for your own server? [21:09] Indeed, indeed. [21:10] Although we don't have highlighting in comments for things like "revision X" if that's what you were looking for. [21:10] http://www.bugzilla.org/download/ [21:10] http://bazaar-vcs.org/BzrPlugins is the list of plugins. [21:11] I'm not sure how they fit together though. :) [21:11] heh OK I'll tell him [21:11] thanks :) [21:12] bzr has some native support for bugzilla, too. [21:12] * RainCT personally dislikes Bugzilla, though.. :P [21:12] RainCT, google might have more ideas too. [21:12] RainCT: Awww. :-) It's much nicer nowadays than it used to be, if you used it a long time ago. [21:13] mkanat: I've used the version on GNOME and on Mozilla [21:13] RainCT: The current mozilla one is representative of what Bugzilla is like out of the box, largely. [21:13] RainCT: The GNOME one is a very old version. [21:13] and I'm sorry but the interface is nothing against Launchpad :P [21:16] well, thanks mkanat and emmajane :) [21:16] np. :-) [21:17] RainCT: there is also "bugs everywhere" which was a look at distributed bug tracking from Aaron Bentley [21:17] and I know there is some amount of Trac + bzr work [21:19] * mkanat is still all for Bugzilla... :-D [21:21] * RainCT likes the "bugs everywhere" concept :) [21:21] hehe [21:21] jelmer, any workaround for the orig.tar.gz changing with builddeb? [21:21] beuno, ahh, you hit that bug? [21:22] jelmer, yeah :( [21:22]