 Hello. Hello, my name is Osamu Aoki. I'll be talking about modernizing packaging tutorial and practical challenges of the five. And beside documentation, I do package input method. And also, if you install any Asian language, you're likely to have my glue code to select all these input methods. Anyway, maintenance guides, which was started by Joseph at 1999, was based on DevilHelper 2. And that's maybe one year after they actually started. And also, tool of choice was DHmake, which also started a year ago. So it was very fresh and new. And it had an actual package as an example at that moment. And that was actually based on Makefile. And he had some nice Latin words. Basically, go by example. That's what he meant. And back then, I was sending touch. And I was invited to be a DD. I said, eh, I don't need to. Then I got into new maintenance here and stayed quite a bit, and eventually became a DD. And that's how I started, and that's how this document was started. But after a couple of years, it was getting a little bit old. So I started taking over the maintenance of maintenance guide. And DevilHelper became 2 to 4. And what did I do? And now DevilHelper's guide changed for 4 to 7. And actually, 7 was one of the epoch-making ones. 7, 8, 9. And that's when the DH syntax came in. Also, what happened was, Deviantok SGML was getting outdated. And I had to maintain it to keep it building. But I actually converted it. And I'm asking policy to do it. And they are now finally moving to this way. And PO4A, that wasn't used originally, but it's eventually used. So it's now have a very good collection of translation. And also, with these 12 years, I had to do quite a bit of these ad hoc additions, multi-arch, d-package, and symbols, library-packaging name convention, in extremely short version because there was no document within Deviant Policy. So for newcomers to understand at least some short text, and also some help by text for these key tools, which is widely used. But it was becoming, in one word, messy. That's what it was. 12 years, you can't blame it. And I realized there are quite a few challenges to make a packaging tutorial. One is packaging tool. It self-has a kind of not-so-well-organized document. And one of the candidates was Uscan. So I've been working on Uscan recently and made a reasonable make file with decent format. And that released recently. So that's pretty good. And some packaging tool, as I said, like Uscan, UU Update was extendable, even though I don't like power much, I had to write it. But then DH make license check was another tool in power. I forgot. This is, I think, power. But extending it was no intuitive and was a little bit difficult for me, so I didn't extend it. And then also packaging requirement has been moving and full use of DH 7 or 9 or 10. And most packages are either AutoTool, CMake, these standard packaging upstream build structure exist. And also, there is a lot of get text support. So that has to be covered. And this isn't too much about documentation, but multiple table was possible with the package 3. So Uscan need to be updated, which wasn't the case. And multiple binary packages, there wasn't much support in DH make to make multiple binary packages out of one source. And it wasn't intuitive, so writing down all these details in text, especially in English, is even harder than writing power code for me. So that was a big stopping point. Press one button. What happened? Sorry, went the wrong way. Anyway, then there was a substantial multi-arch reproducible build. All these new things came in. So how do we move forward? That's how I faced the problem. And then the packaging tutorial was doing all the hard ad hoc fixes, but that's not good enough. And we need a structural change. And also, root calls, that's tools, need to be updated. And so if there is a wall, we need to challenge it. This wall was challenged. There are a couple other walls, which need to be challenged. OK, so how do we do it? One thing I did was update Uscan and basically wrote reasonable pod documents, so now it's readable. And added a couple features. And I wanted to add more about this PGPG and signature support and also get rep support, because it is getting very popular to publish there. And another thing is this DH make. This was kind of fixed three-format output. So I need to be a little bit more flexible. And that's how I decided to write this DH make. It was supposed to be very simple. This was my original scope. And I wanted to release for Jesse. And I was almost done. Then I got a little greedy and started writing the five copyright template generator because it wasn't there. But I thought I fixed back, and then I introduced back. So I decided not to release it for Jesse. And finally got released for this sketch. Anyway, that's how this new tool was written. It wasn't too much about I hate power. It was because I need to cover these new features. And that was the only way for me to write. And OK, let's talk about the five. It's a very interesting format. And standard machine readable, blah, blah, blah. OK, that sounds good. OK, what's the benefit? Actually, forget about machine readable. The biggest advantage is human review are friendly. That was one of the best thing happened. So if you want to read it, you don't need to look for all the files. It's all there. Well, at least it was supposed to. And regular and ambiguous format in a file name and all those are linked. And that was actually becoming a requirement to get the package accepted. So initial package, they put a lot of effort to make it. And they did. And well, reality, the only machine readable usage is maybe licensing compatibility, which is already known. So it wasn't much used. This to me, I may be wrong, but that's my impression. And initial practical challenges of the five implementation was no active enforcement of consecutive uploads. I don't want to name a particular package, but I have seen some package changing license. It's free license to free license. So it's OK with Debian, but the copyright file, it was carrying the old license. And it was accepted to the FTP. So that was happening. Just because, partly, for developers, limited time, it's too much work to do all these money-out checks, every upload. And there's no automatic check on the server side, or FTP master side, to check it and kick it out. So of course. And Lin Xi'an check wasn't implemented because there is no automatic script to do it. And then file format limitation. And this may sound a little bit corner case, but the MIT license type of license has many text, and mostly putting some company name in it. So maybe I'm wrong, but I read it. You are supposed to copy exact copy text, right text, from source to the copyright file. So then you need to copy many, many files. To me, that's it sounded. So that was the limitation. And also, Dev5 doesn't dictate what this was left to the implementer and all the tool-manufacturer-creators thing, rules to store a machine-generated template. Actually, I didn't think about it. But somebody thought about it, and they are putting it in. That's a good idea. And method to track previous human decisions, because you make automatic file, but by the time you are supposed to put it in the Debian package, human made the changes. So since there is no machine-generated file stored, so it's kind of difficult to identify what was done. And method to detect license check mismatch. And since it's not intuitive to compare human-edited version to the machine-generated or to generated one. So it's kind of linked problem, but that's what the problem was. And OK, this is the example of the MIT license. Basically, if you look at the Xorg, Xserver package, they still have old-fashioned copyright file. And I think 60-some type of MIT type of license are listed there. So a lot. So if you do it in a modern way and following the Dev5, maybe you have to write MIT license, variant 1, variant 2, up to maybe variant 65. Anyway, for Denver program, I have actually like Ham and Ham case, test case in the package to test build. And I have 75 type of these MIT license, different license as a test case. And there's 180 license template file to be tested. Anyway, that's one challenge. And another challenge is auto-tool files. And you know, it's kind of stupid, but there's lots of in-GPL, permissive license, auto-tools, exception, et cetera, in makefile, makefile in, et cetera. But I see no one. No one who does manual hand-picked Dev5 file made that exact cut out of those copyright or whatever statement there. And I once said, why do we have to put these? And maybe we should relax the policy. And they got kind of like, oh, you're not supposed to do it. OK, I don't argue. So I just decided I keep kept the tool to be able to produce it by having extra. If you want, go ahead, kill yourself. But I'm going to make my default a little bit more reasonable. That's how I did. And after two-year delay, people kind of caught up. And the license checks seem to be getting better as I checked recently for this talk. And people are using it. I have to admit that. So that must be pretty good to be used. And I also saw CDBS basically seem to call this one. I may be wrong, but then was using it. So if you use it, it maybe has a good reason to do it. But there are other tools to make Dev5 tools. And this one actually uses maybe simplified old license check type of text in it. And that's my tool. It has a copyright file generator and also verifier in it. This is another Python implementation. At least Python deviants seem to be a little bit more professional writing style than mine. And then I see Ruby. OK. Anyway, what's the difference? License check, maybe do the scan source, do some minimal editing, removing some maybe leading style or something. And then they do partial text match. And then wherever it's matched, they cut it out. And they seem to make Dev5 output. I don't know how exactly. It depends on how you use tool. They may be creating extracted text, or they may be just labeling as a MIT license. But anyway, one other thing I found out at CDBS, I think one, I forgot, GDBC or something, was using automatic generated files stored in under Devian directory. That's a good idea. I should imitate it, or just steal the idea. But this definitely, due to this way of cutting out, at least they're not making so much nitpick type of decisions on the license text. And it's pretty decent for, anyway, that was pretty decent for GPL tube type of just a simple assignment licenses. And then what DevMake does is, actually, I scan text, and usually just assume the top portion has a license text, just cut out the entire section there, and remove maybe simply copyright or hold the name. And then rest, I assume that's a license. And I kind of, of course, in many of them, use this boilerplate. So it's same. So then I advance them up. Then I do full text match for the license, and starting with a very rigid one to relaxed one. So we know what level of matches it does. And then I make a depth file output. That's maybe too picky, but with this method, on the other side, I could do the depth file degenerate to the file against a source check. OK, so far so good. And at least some people seem to be using. And but now that I see other people did seem to have a different idea, maybe I may modify or just maybe stick the license check into the DevMake tool and dropped up my current code. But if I ever change my code, maybe I should do some maybe limiting the ranges of file to be scanned, or at least a way to do it. And also, trim the license text match. And sometimes they have a totally unrated English words after that, so maybe trim it beyond what's matched. Then do this depth file generation. That may make a little cleaner result. So that's so much for depth five. And maybe that's from next release I'll be looking at. And as far as packaging tutorial goes, basic ideas, maybe time is limited. So I basically made DevMake based tutorial. And the key here is this. I have a source actually customized for this tutorial. And also, I have all these variations documented that tutorial, so you can have an exact example. And also, this source package can be unpacked to create a log of packaging so that people can try and experiment with a simple source other than some existing huge Debian real package. And I think these are relatively simple. And if you have any suggestion to add, I'm thinking maybe making font package or something as addition. And so that's what I'm thinking. And of course, it has to be DH10. And some of the words, I need to correct it to be neutral, et cetera, et cetera. So that's what I'm looking at. So I'll be glad to get any feedback or suggestions. That's pretty much my talk. Thank you very much for listening.