 So, this is the Git and Debian packaging discussion. It's going to be a panel with our distinguished panelists here, Ansgar and Joey and David. But hopefully, it will also be a discussion. So if folks have questions or examples or suggestions, feel free to raise your hand. I'll try to keep an eye on the audience and I can run the mic to you. So, yeah, give these folks a hand. So thanks everybody for showing up. I hope we'll have lots of questions and interaction. I realized in my first buff that if you give me slides, then I go into teaching mode. And that's okay as far as it goes, I like to think, but it's kind of not buff like. So we're slide free. We have Gobi. Hopefully, by this point in DevConf, everybody knows how to, does anybody need the address? It's Gobi.Debian.org. So please join in and edit. Is there anybody who would like to volunteer to take minutes or notes? I mean, everybody is welcome to, but those of us sitting up here might get distracted somehow. Also, while we're asking for volunteers, can we get a volunteer to relay questions from IRC? You do IRC? Thank you. Probably on hashDebconf-talkroom1. So, volunteer for taking notes? It's okay. We don't really need notes. Okay. Notes are for the week. We have the video team. So we'll just watch the video if we want to know what happened in this. So great. So if you're like me, you have no idea really what Git source packages are except that they're not allowed in the archive. And so today, Ansgar showed me how to use a Git source package. And so to sort of underline the fact that this isn't a practical how-to session, we're going to show you how to do this thing which is of no use to you in Debian. All right. Thank you, I think. Okay. So it's a bit of a cheat because we tried this package already and it worked. Oh, no. And I even checked it out. Thanks. Okay. So what do- Check out, check out. It's quite- Git clone, blah, blah, blah. Right. It's okay. Upon your- Okay. Okay. Okay. Joey's more cautious than I am. I just discovered. Okay. So just Deb check out. Nothing fancy here. And that's only because I'm too lazy to remember what the URL is. So this is in the package Perl, one of the package Perl Git repos. I think Ansgar, I hear myself, immortalized. All right. So let us go into this Debian source, Buxy's Magic Directory, and we'll use everybody's second favorite editor. Yes. So as- and in fact, this line of said could sort of sum up my hopes and dreams, which are so far not realized, which is I just want to replace Quilt with Git. Not everybody agrees with that, and that's perfectly okay. It wouldn't be Debian if everybody agreed. Okay. Voila. So commit minus M, convert to 3.0 Git, Nia, FTP masters. Right. Okay. So I was talking yesterday in a bof about recognizing emotions from phone calls. And that's pretty much it. So let's- we're now in the root directory of the package, and we're going to build the package, and we're not going to sign it because, well, we can't upload it anyway, so what would be the point? Okay. There's some noise. I mean helpful messages. Stop yell if I'm going too fast. I mean nothing too interesting is happening so far. So what did I do so far? I edited format, and then I just ran dpackage build package as normal, dpackage source directly would work fine. So let's have a look at the DSC file, blah, blah, blah, and it has only one file in it, which is a Git bundle. So some of the noise that rattled pie was something about being a native package, and so from dpackage to this point of view, these things are kind of native because there's no separate pristine tar ball. Let's change somewhere else. It's gone. Right. TempFS. Let's have that TempFS discussion. Right. So I could actually just directly clone. That's just a Git bundle, but let's try and use the more debian-y tools, dpackage source minus x. Thank you, ZSH. Okay. So what happened? Dpackage source knows how to unpack these things, and it basically just does a Git clone. And well, it looks suspiciously like what I started out with. So cp minus a might have been a simpler way to do this. You do have the option of giving some Git shallow options to dpackage source to reduce the amount of history that's included. But if we look at the, okay, so let's look at what branches included. So just the master branch. And if we look at the tags, hey. Quick question, David. Yes. Just to get the context, you're syncing against which repository? So you mean what is origin here? Yes. Origin is the Git bundle. So origin is actually the source package here, and pushing back to it isn't going to do us a lot of work good. But, so Git bundles look just like repositories to Git. You can clone from them. Okay. So how did we get the Git bundle? You use the Git bundle command. It was dpackage source just runs that to build the bundle, which is effectively the same as a Git pack file with a few header information. Could you show the source directory? Just about one level up that was created. You want the source directory where I made the, okay. Yeah. With the long listing. All right. So this is a regular Debian packaging directory that happens to be in a Git repository. And if we look at Debian source format, it says 3.0 Git. And so when I said dpackage, build package, I could probably say dpackage source, right? Let's dash b minus uc minus us. All right. So this is just calling dpackage source as we might in any other package. And then the reason I didn't do that before is because you have to be in the parent directory or something. Right? And I'm only doing the building the source package here because mainly that's the part we're interested in. Also, I don't have the dependencies to build dependencies. Okay. So what just happened? So you saw some of the things, delta, blah, blah, blah, that's Git talking to us as it makes the bundle. Why don't you scroll up just a little bit? If only I knew how to do that. Shift page up. Shift page up. Thank you. All right. Okay. So here we are. Right? Info bundling dash all, counting objects, delta compression, the usual sort of stuff that Git mutters about while it's working. And then, oh, apparently I'm using xz compression. That's nscar at work, I bet. There's nothing to do with Git, the fact that it's using xz compression. So can you show the files in the parent directory? Yeah. Okay. As usual, dpackage build package, put the source package in the parent directory. And we have a dsc and a .git. That's a .git file, not a .git directory. Right. And so here's the dsc file. We see right at the top, it says 3.0 Git. And then everything else is as per normal. And then down, it has a package list. And only in the checksum section do we see that there's only this .git file included. So, okay, so that... Can you show us the actual Git bundle? What is it? Is it a text file? Is it a binary file? It's a binary file. So I could... Don't know how to... I can basically show it to you by cloning it. Right. Okay. Any other tools apart from Git who read the Git bundles? If you look at the format of a Git bundle, like I said, it's the same as a Git pack file. There's several programs that can read Git pack files. They're all various implementations of Git. And it is a documented standard file format with version numbers and all that kind of thing. The Git bundle adds a small header saying it's a bundle and a few other pieces of metadata. Question? So that's pretty much it for the demo. We can... Like I say, now when you unpack... I mean, when you unpack a source file, you don't really care anymore, right? You have the directory. You have the working directory. In this case, you also have the Git history, which I guess we'll discuss in a minute. That's actually the main weakness of this format as well, is that we really have the complete history here. So I don't know if that's readable, but you get the idea that no FTP master, even Ansgar, who sort of likes Git, is going to be willing to review that. And this is actually not a huge history. It has a thousand... I don't know if you were counting, but there's a thousand commits there, which is a smallish Git history. I mean, so I think plenty of projects in Debian have in the range of 30,000, 100,000 commits in their history. So clearly something... Well, clearly looking at every one of those commits is not viable. I have a question. What makes the magic prompt that tells you which bit you're in that looks really useful? Yes. So that's actually... It is very useful. It is ZSH, and I think I stole this from Martin Kraft originally. So it's one of those... Yeah, it's more or less off the shelf ZSH, but it still seems to take some configuration, but it's not that hard. Question up front? Question regarding the Git bundle format. Does that encode any sort of references to external repositories? This kind of leads into the next question about shallow branching. As far as I know, it does not. I have to admit that I don't fully understand the Git pack format, but as far as I know Git packs don't do that, and Git bundle only adds some refs that are included in the bundle. So when you unpack it, it knows what refs to create. Right. So I mean, obviously the ideal would be if there are concerns about not having the whole history in the bundle because of having to review everything, then the ideal would be you just have the tip and you include something that actually points you to the right place for all the history, or two multiple right places for all the history. My incomplete understanding is that this is essentially an upstream missing feature in Git, is that shallow clones are not as nice as they could be or should be. Any other? Okay. So I think that Ian. So the reason we're using shallow clones is because we don't want the entire history in the archive because the FTB masters don't like it. However, we already have in general complete history on Allioff, where apparently Allioff admins are completely happy with it. Is there anything stopping us from somehow treating the archive as a output format, output location and not having to have all this pay? So you might be jumping ahead to line nine, which is totally fine. Oh, you want to answer? I mean, I'm not quite sure what you meant by treating the archive as an output format, but I think that you have a good point about Allioff already having, you know, generally the full history, upstream history of every Git repository that we pulled in. And there probably could be licensing issues with what's on Allioff. I think it's just that we're not shipping it to quite the same degree that we are. And the FTB masters are, I'm sorry, I don't think we're shipping it quite to the same degree that we do ship Debian source packages. So that might be the only dividing line. Well, Allioff can also. Well, we don't just bring us between main and contribe on Allioff. So when there's not free but distributable files, I think that would be okay to have on Allioff, but it should not be in the main archive. I guess I could mention since the FTB masters did bring up this, you know, concern, which I hadn't really thought about. Currently, my best approach to trying to deal with this, which I haven't tried to implement yet, is to instead of just having a shallow clone that say has, you know, the most recent commit or something, you can make a series of branches, basically, each of which has a Debian release. So you can have the last 10 releases or something like that. And you'll have, you know, you'll have a snapshot of each of those available in your Git repository in the bundle. And then if you need to deepen that, you can pull from Alioff or something. But that's not implemented. I think it's probably the blocker, as far as I'm concerned, for getting this in. I don't know about the FTB masters. Is there a pristine tar integration? And can I regenerate the upstream tar ball from the Git bundle? Maybe I could answer that. It's just another Git repo, so sure. Anything you can do with a Git repo, you can do with this thing. On the other hand, the reason, think about why do we have these upstream tar balls and why do we use them. It's to verify what we got from upstream. In the case of a lot of these Git repositories, what you get from upstream is a Git repository with, if you're lucky, some signed tags on it. And so that's a major reason to want to use this format in the first place. And you won't have a pristine tar ball. Yeah, I understand. Because for me, it's not necessarily that the developer can get the original tar ball, but that you can actually get it from the Git source package, from the Git bundle. Because one nice property of the Debian mirrors is that it's mirroring upstream software and upstream tar ball releases across the world. Where they do exist, and they're becoming much less frequent if you look at, say, Rails stuff, or, you know. That, of course, one can question the sanity of some. Anyway, never mind. No, I can't hear me. I was going to say, there's sort of two things going on here. One is this notion that as more and more upstreams move to rational, distributed, revision control systems like Git for doing their base work, then the nature of the problem we're trying to solve changes. And that's certainly true. I believe today that in my own set of Debian packages, a very small percentage of the upstreams actually themselves use Git. And I don't always even notice when they change to it. And then there's the whole kerfluffle about figuring out what to do, how to re-synchronize my work with theirs and all of that sort of thing. But it also strikes me that we've had this mechanism for a while for capturing VCS entries and control files. And some combination of capturing information there and what we actually have to put in the file. It just seems logically like it ought to be possible to come up with some suitable, as Joe was saying, maybe it's where we actually do the Debian package building on specific branches for each Debian release or something. I don't know, it seems to me like we ought to build a dream up something that resolves this in a plausible way where the rest of the package contains the pointers to where to get the rest of the history. So one thing that occurred to me in response to Dmitri's question about pristine tar balls and Debian being a kind of librarian for the free software world, which is certainly a positive thing that we do. But I mean in a purely technical sense, we could do that by signing tags as well as by making tar balls. And for us, when the tar ball isn't used in the build process, it seems a bit artificial to declare, hey, this is our pristine. We're gonna get archive to a tar ball and then put that tar ball back into the same Git repo. I don't know, without getting into weak hashes yet. So I hear where you guys are coming from regarding upstream now distributing directly via Git and tar balls being an unnecessary artifact of what they now consider to be an obsolete distribution mechanism. However, one of the things that seems to be falling by the wayside, and this was a point that I heard Ian making in the Hack Lab the other day where he was trying to check out a package Git tree and get it to build. And he was running into problems because there was no release machinery in that Git repository that would actually give you the auto conf output and have something you could actually build as a package. Because you had the source, which consisted of what upstream considered the source that was checked into Git, plus the Debian directory, and all the auto-generated files were missing, which traditionally we view that as, yes, you don't check in things to the repository that are auto-generated, but if you want a representation of an actual buildable Debian source package, you actually should have those in there. So are there any conventions developing around that in your work? And I'm actually interested in this question in terms of larger usage of Git build package as well, to make sure that when people actually are checking out things that are Git, there is some obvious consistent way to build the package. So are you answering Steve's question? Yeah, I was going to say, for me, the simple answer is to always have the Debian packaging do the bootstrapping work and build depend on whatever auto-star, et cetera, tools are required to do that. I've actually been doing that by adding another target to my Debian rules files, which is the configure target, and other folks I've seen are doing the same thing, and this sort of insulates you from all that, and it sort of guarantees that when you do a clean, you actually flush away all those auto-generated things, and when you do the build process and sit, it depends on the configure having completed and generated a stamp, then you kind of get that whole bootstrapping thing captured there, even if it's not captured by the upstream folks in their sources. Yeah, I guess there are people sort of for and against auto-reconfing, and I guess the one point of view, which was sort of diverging from the topic, but it's somehow related to, as you mentioned, because it comes up more often in building from version control. So the one point of view is you introduce variation into the build process when you don't ship configure exactly as generated by auto-conf version zero that upstream is using or whatever. I... Ian has a question for it. I have an answer to this, which is, we don't need to have one answer to the question of should you do this, and we're never going to get one answer to that anyway. What we need is either for the thing that you get by checking out to have all of those files in it so that they're pre-generated and they're not regenerated when you build the package, or the rules file does it for you. And either of those is sufficient. So Ian, but is this a question for Demian Packagers or is it a question for upstreams or both? Yes, but upstreams seem to be doing all sorts of crazy stuff. And different ideas about these things. We at the very least have the benefit of being able to declare a standard interface to a package. The moment we don't have a spec for what it means to be a standard Debian package in version control. So it's not possible to get a package from something that you expect to be a version controlled Debian package and build it because you might have to run some weird script, it might be on a weird branch, there's all sorts of strange things that aren't sorted out. So this is actually the last item and I don't care about the order. I'm glad you asked these questions because I had no idea what the point of this item was in the agenda. So some people are using readme.source for this kind of thing, although it's technically not what it's for. Okay, so I can relay Vdale's comment there, which is that that's a terrible idea. So do we need a readme....? No, it needs to be automatic! Okay, yeah, that seems reasonable enough. Yeah, I was thinking you had it right. Either the source package when unpacked is ready to go or the rules file does the bootstrap and text query. For a 3.0 git package, this would be the case because basically what you get from the checkout is what the buildDemons, for example, will use to build the package. So it will either have to have the configure files or rebuild them at the time. So to the best of our knowledge, there's not currently a DH1 build system that recognizes how to do the right thing, which might be a good idea for facilitating Debian rules doing the right thing for a majority of packages that are in this scenario. You mean for configure files? I mean that DH should know how to run... The DH auto underscore configure should recognize a git tree that has no... That has, for instance, a configure.ac but doesn't have any of the... It doesn't have a generated configure script or whatever and should know to do the right thing so that people aren't once again in the situation of putting lots of readily-automatable build logic into their Debian rules. It's not in debhelper, per se, but I think that DH auto-recomp or something like that does do this. It's a sequence add-on, so it's one with auto-comp or something like that in your rules file. It seems relatively clean, although a little messy under the hood. So I just wanted to comment that I'm a huge fan of the not shipping all the auto foo in the package because it just means you get ancient versions of auto foo which have all piles of bugs. We fix a lot more bugs by redoing it than we do by keeping the old version even though that's kind of how the auto stuff was designed. I think it's a bad plan, so this is just great. So more discussion about... Yes? Yeah, I was just going to say that I had all kinds of trouble for a long time with Emacs and that sort of thing, and things got much better when I switched to not... Can you speak up? Sorry. In Emacs, I had all kinds of trouble with that kind of thing for a long time, and things got much better when I switched to not shipping any of the pre-built auto foo files. And to your earlier point, in DH, I just create one line override for I think it was DH auto-configure or whatever, which invokes either auto-regen or auto-recon for whichever one's appropriate. So... Any more discussion about shallow histories and what... I mean, so one thing we didn't talk about, which some people I know feel very strongly about, so I'm a bit surprised there's been no yelling, is that... Well, Dimitri sort of mentioned it obliquely, which is that, okay, this thing you handed me, which you told me was a source package, I need Git to read it. And for some people, that is much, much worse than needing tar and deep package dev to... Well, to read it. So I don't really feel that way myself, but I want to sort of throw that out there because I know... I've been yelled at that way before, so... Anybody here want to take that point of view or expand on it? Well, I have in the past downloaded Debian source packages with current... You're really yelling very quietly. Okay, how about this? Better. I really did download packages from Debian Archive on Solaris machines and then trying to build them because that was the only way to get a package and I knew how to build a Debian package quickly and get all the correct dependencies. So I did use it on a non-Debian machine just purely as a source repository. I mean, Git runs on Windows, so... Well, true. But not on Solaris 7 or whatever it was. Okay, so you're saying it would be a restriction? Yeah. I can agree with that. I would say that another possible devil's advocate reason to worry about this is what if in 10 years we're not using Git anymore and we have all these Git source packages? Could happen. I think that it can be managed. So firstly, I'll just come back to the point there about Solaris. I don't think that we should take that as one of our goals and Debian format source packages have never been intended to be unpickable on anything other than Debian. The real reason to be wary of Git format source packages is that the Git user interface is a catastrophic disaster, at least for some people. And it's not so much that you have to install some tool. You always have to install some tool. The problem is that you might have to use it. All of that can be buried in something. It means that you don't need to understand how it works. You don't need to understand its data model and so on. Then I think a lot of that objection would go away. Yeah, I mean, I hate Git because I can't drive it. But like you say, if all you have to do is dpackage source-x and you don't care whatever the hell happened, then I don't think that's a reasonable objection. That might have been the most important part of my demo then. Steve has a question. Well, it's not so much a question as, I guess, a follow-up comment that... So, for instance, the 3.0 quilt format is handled internally by dpackage. And I guess I'm surprised that this is something we're going back and forth on because I would expect that if this is something we're going to use in the archive that dpackage itself would implement that in some capacity without relying on external tools. Because you don't want... I would expect... I don't know. That's really a question for the dpackage maintainers about how they would choose to implement that. But certainly you wouldn't want dpackage-dev to not, upon installation, give you everything you need to work with any source package in the archive. So whether that's dependency on Git that it shells out to or some sort of internal re-implementation of Git, I would expect it to be transparent to the user that dpackage-dev is the interface you need to worry about. And that's it. Sure. As I say, I'm Devil's Advocating and no, I think the point really was about use outside Debian. So if you don't care about that, then we can move on from that point. Are there really no questions from IRC or rude remarks or songs? Okay, funny jokes? Okay. Regarding the non-Debian users who may... I mean, by GPL license, they should be able to get the source in an easy way. I don't think Git is an easy way for non-unix platforms, even though it's possible to get Git on Windows, I agree. For instance, if you ever had to get PDF or some documentation or some funds from Microsoft, and I probably... I guess you would have been very upset to have to get some strange MSI file or CAB file to get your PDF for you. So I don't think we should... We should make it easy for non-Debian users to get the source of our packages. It doesn't mean... It could be HTTP with something... Sure. I mean, I guess this is the argument, and Ian doesn't care. He's maybe going to tell us so. And I think we have git.debian.org to also make that access available as well. Right. So the argument being made there was, as far as I can make out, partially based on licensing. And I don't think you could make a plausible argument that almost whatever format Debian chose to use was not a format conventionally used for software interchange. So essentially, whatever format we use will satisfy the legal requirements. That's not the issue. The issue is, do we think this is an important thing that we're supposed to be doing or should we try to make our own workflow smoother? And at the moment what we have is we do have a version control system. Debian Archive is a version control system. That's how we use it. It keeps multiple versions of things. You can commit to it by uploading, all that other kind of thing. And it's a catastrophically awful version control system. It's really absolutely terrible. I prefer it to SVN. I'm kidding. I'm kidding. I've never used SVN. I think that's entirely plausible. But really, in this day and age, there's so many better tools available. And we are making our lives extremely difficult by battling with these terrible tools where it takes you, sometimes it can take you half an hour, an hour, to get from, I've got the name of a package to now I've got it building and I just want to make my change. And then having done that, made your change, tested it, you've got to spend another half hour wrestling with the crazy system to let you commit, push whatever your change is. When people outside our crazy bubble, these are trivial operations that take minutes. We're wasting so much time. Okay. Well, I think we have more comments along those lines. Oh, a question from IRC, maybe? Yes, there was an opinion brought up by Bernhard Link. He said, well, Davion is not only about participating in free software, so we should care that other Linux distributions are able to see what we do. Sure. It's a comment, and I agree with that sentiment. I don't think anybody here thinks we should somehow make it harder on purpose. On the other hand, I'm a little skeptical of this argument that there are Linux distributions that can't use Git, and if so, I pity them. I mean, okay, I know that Git is not everybody's favorite tool and that it's far from perfect, but on the other hand, it's becoming kind of basic literacy in my... And I know people who dislike Git find that even more upsetting that Git is becoming a de facto standard and you kind of can't work in free software. I know people that this drives literally irrationally angry, but there it is. So I don't know that that's such a big thing. Anyway, it's not... I felt like we should bring this up. Maybe we have five, seven minutes left, so I don't know what you guys want to talk about for this. There is another opinion from IC, from the same guy that is trying to look for patches in other distributions and to have to use different VCSs and different branch naming setups is quite a hell. Yes. Right, so I really sympathize with Git haters whenever I have to use BZR or HD or SVN, right? I mean, it's mostly familiarity. Hello. I know you probably have seen me around. I'm from Canaima distribution. We kind of have said Git as a default for our packaging in Canaima. All our packages are tracked by Git, so we benefit from it in a great way. We simplified the way we make change logs with GitDZH. We also participate or contribute, or help contribute to Canaima by basically showing the things we do with the commit diff. I just want to say that it's a magnificent tool, and we have that experience in Canaima. So I'm happy to keep discussing or I can do another demo. What do you want? Discussion is somehow more valuable, I guess. So I'd like to go on record as one of the Git haters. I really do think that the Free Software Community has missed out on an opportunity to standardize around VCS with a much better UI, that being bizarre. But given the fact that everybody has a standardized around Git, because it happened to have the right advantages at the right point in history, I don't have a problem with there being a Git source package format in Debian, and the reason for that is very simple. It doesn't matter. The interface as a Debian developer, if I'm going to be working on somebody's package, the interface that I'm going to be using is the same. I'm going to be using dPackage. The fact that there's additional information there that happens to tie into the version control system that the maintainer would be using whether they have this package format available to them or not is immaterial to the kinds of interactions that I as an NMU-er would have to have with that package. And as long as that's the case, I'm happy for there to exist a 3.0 Git format. Actually, I think I had forces Git on you a bit because you have to commit your changes with Git. Well, except that dPackage, buildPackage, or source or whatever now has a dash-dash commit. So you use that as a version control system, abstracting over this anyway. And I think Ian had a really good point about it, being a horrible, horrible version control system, but it is the one that you use if you don't want to dive into the details. Right. So I think Steve's hit the nail on the head. There will always be people who don't want to use a new tool. And in an organization the size of Debian, we're not going to be able to just say, if you would even switch over to some new workflow. Those of us who have tried the new workflows and have rotated our brains at 90 degrees to reality to cope with the Git user interface now find that those new workflows are much better. So what I want is I want to be able to have a Git workflow and I want Steve to be able to have his dPackage workflow. And if he wants to spend half an hour wrestling with dPackage when I'm typing Git clone and commit and push, that's absolutely fine by me. And what we need is a set of tools that means that both of us can get what we want in a standard way without having to run bizarre scripts, not know where to find the source code. It should all be automatic, standardized, and none of us should have to do extra scutwork the computer should be doing for us. And at the moment, I think unfortunately, our tooling is considerably short of that. For example, we're going to have to have build the source package from a Git push, which we don't have and that's a bit of a political problem as well, but it is an important thing that will need to be fixed. And until we fix that, you're missing half of the workflow. One thing I've noticed a lot more recently since the 3.0 format is things that you can't build twice. And I don't know whether heading in this direction is going to make that problem much worse. One of my packages doesn't, and I'm not quite sure what to do about it because it's tech craziness. Something definitely we should worry about is files that get changed by the build in place, and then it all goes wrong. Don't build in place? How do you make tech not build in place with the source files? Can you do that? That's just an example. Okay, so we're veering off, and I think we have like zero minutes left. We could probably sneak one more question in without further angering the video team. Who wants the last question, who's not sitting in the front row? Another question from ISE. Jaroslav asks about, is it preferable to carry pure Debian Git repositories, i.e. imported top horse and Debian on top, or maybe original upstream repository plus Debian branch? Can you repeat the question? Whether it is preferable to carry pure Debian Git repositories, i.e. imported top horse plus the Debian sub-director on top of that, or maybe original upstream repositories plus a Debian branch? I don't know what's preferable. I myself do both. I find the second option, if you don't care about resource consumption, is probably the good one, but someone... So cherry picking upstream patches with Git is great, and I think that that is so, and if that costs 100 megs of disk space, I'm okay with that, but the Ali auth admins aren't here, so it's safe to say that. I guess we should stop. Thanks, everybody. That was a really great lots of interaction, and that was... that's what you want for a bof, and no anger. Well, Steve's a little bit angry about the fact that BZR lost, but it's okay. Okay. Thank you.