 Yeah, hi. Let's talk about PU parts, or rather not a talk, but rather a both. I'll explain why it's a both and not a talk. It's mostly... Of course, PU parts scans the whole archive and generates a lot of work and I'm the only one working with it mostly, so I look for new people who would like to help me with it. I'll explain a bit what PU parts does, what problems are, and then I would just like you to file bugs. Yeah, whatever. If you have questions, just ask them. You don't have to wait till the end. Fine. I started preparing the slides only two hours ago. I know PU parts in and out, but still, I wish I had more time. That's probably because I was involved in doing this conference. I maintain a few packages in Debian, but mostly nowadays I do Debian Edo and PU parts. I used Debian since a long time and for a long time I believed that what I do with PU parts now has been done since always. I always thought that Debian packages have to comply to policy and this was somehow tested, while in truth it's only been tested since six years. That's when Lars started writing PU parts. How many of you have packages in the archive? I guess most everybody. How many of you have run PU parts on them or run PU parts regularly? How many of you have looked at their PU parts pages? If you don't know it, that's the wrong one. Here on the left there are packages by maintainer uploader. Every e-mail address in the uploader field has a status page. It's for all test and distribution, so it's VZ, SID and Lenni and SID. In VZ my packages are fine. While in SID one package of mine has a failure, or where I am in the uploader's field. How many of you have looked at the PU parts source code? More people than using it. PU parts in short detects policy violations, it's probably nothing new. The name is for package installation upgrading and removal test suite. So in reality it only detects some policy violations. There are many many policy violations PU parts cannot detect or cannot detect yet or will never detect. For me it's obvious, I really believe that policy should be followed, that the rules are sensible and I want my packages, not only my packages to be clean, but rather the whole Debian archive to behave in the same way. If there's something wrong with policy then there should be discussed in the policy list. In PU parts it's just the tool to detect those changes, those failures. It's written by Lars Vietzenius, but he gave up caring for it in 2008 I think. He has some ideas for a rewrite, but that is not happening at the moment. There was a short period where some more people were hacking on PU parts, but since 2009 it's mostly me. There are some contributors from time to time, but nobody else has stepped up so far to really continuously help me, both with caring about the PU parts source code as well as caring about the results which are generated on piatti.debian.org, which is the machine which runs PU parts Debian.org. In the last months or so there was Scott Schaefer who contributed quite some patches. I think I've applied, I don't know, seven or so in the last months, but I was too busy preparing DebConf to really take some more patches from him. So there are some patches still in the BTS which I need to look at in the next months or so. The most useful patch from Scott is something that PU parts can now finally handle alternative depends. Previously PU parts would only look at the first depends in a series of alternative depends. So if a package first depended on Apache or Apache 2, then PU parts would say Apache does not exist anymore, so this package is untestable. While now it detects that Apache 2 is there and can test the package. This is for the master slave mode I use on piatti, where packages are only tested when all depends already tested successfully. What it was Lucas sometimes does is he just runs PU parts on the whole archive regardless of whether the packages are tested. Which is fine if you do it for your packages but for automatically detecting you don't want to have a package fail because the dependencies fail. So you only want to test the package if all the dependencies have been tested correctly. So PU part is written in Python. In my opinion it's very well written in Python. But I added some rather heckish sales scripts to pass all the logs. At the moment the four suits are tested so there are 120,000 log files and I just wrap in there for some strings. And that definitely needs to be improved. I also really want to move the code to Git which is rather easy but if somebody has nothing better to do I would be really really happy if somebody just creates a Git repository on alias and moves the code there. I will immediately start using it. Okay great. The PU parts Debbie and Ork is up since two and a half years since then these web pages are generated. In VZ there are now over 31,000 successfully tested packages. 93 failures and 272 other package log files which are due to this. So there are some failures which the post installation maintainer script failed. I'm not the post removal script failed and unknown reasons which I don't know at the moment better. So there are then 33 packages which where the dependency failed and some circular dependencies which are where the detection is also still a problem but that part of the code, the dependency part where the scheduler is recursive code which I've spent several hours like 20 hours staring at it and debugging it and I still only partly understand it so that's probably not so well written or it's too well written for me. But still it detects a lot of failures. For testing VZ I've ignored some failures which PU parts can detect. Like in VZ I don't care about packet files which exist after purge because in SIT there are broken simulings due to own files after purge there are 200 failed packages and if I apply this to VZ then less packages are tested and the more serious errors are not detected. But even for SIT it would be very useful to file those 200 bucks. And if I continue in the speed this buff will be over in 10 minutes and then you can all file 10 bucks Yeah sure? Yes. So how is it for you to file bugs? Do you have scripts to pass logs? Not yet. My own experience with PU parts that is really hard to pass the logs automatically just to extract the parts is interesting so I ended up rewriting something equivalent to PU parts which was easier to pass which maybe was the goal to make it easier to pass but I think that something that you can really win a lot of time you should just focus on getting it easier to pass. Yeah. It's on my list but I have another slide with my three most wishes for PU parts and that's not on there. So that is testament of the bed preparation of that. What I have is a collection of templates which you see there. I hope that's readable on the recordings which are templates I use for filing bugs where I have the relevant policy sections so that people will not reply saying is this really a bug or something which also takes time away but I would like a local tool which I can run locally on the logs because the failed logs are just 100 so I can also download them and run the tool locally. You said that you disabled the check for purged files wouldn't it be sensible to have two classes of failures those who prevents dependencies to be built? Yes. But then I would still not treat those failures so the result would be the same because you can assume that if a package has these problems instead it will also have them in VZ. I just don't test for it in VZ. I don't understand. At the moment every PU part's failure is a failure. There are no classes of bugs. And as I'm not testing for these failures in VZ but do test for those failures in SIT I have the same results as I would have a class of bugs which is not a critical failure so the end result is the same. I'm thinking now that you have three packages in a dependency line and the first is failing if the result is really the same. In VZ the package will not fail because of a left over after purge so packages which depend on that and also have these leftovers after purge are also not failing because in VZ leftovers after purge are ignored. While in SIT it's a failure and already the dependent package will fail and the other packages will not be tested. And if there is a dependent package which has the same failure it will neither be reported in SIT nor in VZ. It will be reported in VZ because the other dependent package will not be tested against failures. I'm happy we have plenty of time. SIT has less packages being tested. These are mostly the packages where the dependency is failing but it also has a lot more failures. But those failures are less critical while in VZ it's only critical failures. And every day there are two or three buggy packages found. So in a while I try to keep up with that and every day file the bugs which are newly found but it's impossible to keep up with it basically. Two to three emails to learn about them? No. But I should probably turn that into a mailing list. Can somebody write this on some note? Can you file a wishlist bug about that? Because I will not do it this week and in a week I will have forgotten everything. And the good thing about bug filing is that then bugs are fixed rather fast. If they are in the PTS they are not fixed that often. So I see when a package fails again it's a new upload I see the package failing again and there are some candidates which I recognize as oh another upload and another failure still the bug is not fixed. So filing bugs really helps. So these are what I had in mind what the three worst most pressing shortcomings are. Use Python BTS. Currently this is really legacy from when PU parts report was not as much used as now. You manually move the file from the fail directory into the bug directory which is really annoying. I do it on the server which runs PU parts I move the log file from one to the other directory and this is really stupid because I can query the user text anyway so it's easy to query for that bugs. The other shortcoming there is PU parts report every days against those 120,000 log files grabs again for the same errors so it doesn't keep state which is really, really horrible. But it still works and the machine idle a lot of time anyway so I don't, I do care but I didn't have time to do it. And the other thing is the exit code that there are not, that there are fatal failures and lesser failures. Wait a second. So mailing list as number four and I've been thinking would it somehow be possible to basically automatically generate a bug report? It is for some bugs it is definitely possible it's also possible to even generate the patch for some kinds of bugs because they are so simple like lots of packages use add user in the post-rm script and add user is not an essential package so that will fail. If you use user add instead which is in pass 3D the post-rm will succeed in approach. So that's almost, they could even create a patch automatically but you're invited to write the code. So patches welcome basically. Yeah patches are definitely welcome and there are 27 wishlist bugs in the BTS so there's a lot, many people have good ideas about what PU parts should do but it's only me trying to implement it once in a while. So that's really what's lacking. And I mostly just lack time but yeah who doesn't lack time. And most bugs found by PU parts are important or serious by definition. Important bugs are like these packages left over after purge that is a policy violation but it's not a serious policy violation. It's ugly but still I don't file them as serious really. Because then I would have more discussions with the maintainer if this bug is really serious or not I'd rather file them as important and don't have the discussion. There are some bugs which I file serious like if the post fails or if there are files left over in user local or files left in home or generally home username is created those are definitely serious but not all are serious. Generally PU parts has very few false positives it has more cases probably where policy violations are not detected. The only one which I think is controversial or many people fail to set up a database which are packages which expect running database and where the post is then fails. I think those are at least important or even serious if the package fails to install in a CH route because setting up a CH route without the database is used for generating live builds for fully automatic installations but people disagree so that would need another discussion for which I don't have the time. About fail to set up a database so many packages use a dbconfig common and I have tried packaging a package and used dbconfig common and I couldn't find any way to prevent this problem so maybe I just didn't find the documentation or dbconfig common doesn't provide for this. Does anyone know dbconfig common and can comment on that? Dbconfig common apparently doesn't provide for supporting installing a package and not having the database running so the package basically so to have the post and succeed you have to create the database and there's no way around it. He's saying that you can ignore it and tell it to create the database anyway. No. The Susanment can do this or the package can do it? Okay. Since the goal of PewParts is to test the packages and the fact that failing because of the database is controversial, what I did in my PewParts... well, rewrite, is that if I detect that the log contains an error message about connecting to the database, I just try again after installing my SQL and Postgres and that works sort of. Yes, that's an interesting idea. Well, it works, so... Well, but I still... if I want to prepare a live build or set up CHroot, I don't want to set up the database server and I think a package should just install cleanly whatever happens because there are other ways to configure the package and he doesn't want to run a database locally and that's another valid use case. The point is to be able to test what happens after the DB configuration and that's enabled me to file bugs about stuff, about errors that happened after the DB configuration because PewParts has to do stuff automatically. You just need to find a way to skip that step and go... I agree, it's a clever, pragmatic approach. At the moment I ignore the issue. I just file the other bugs. There are still more bugs to be filed, so... Yeah, this is the error. I should make it bigger as well. Pardon? Yeah. In my script, I grabbed for PSQA, could not connect to server and then... For a database. Actually, they should install when testing. I think the packages should install cleanly however that's implemented, yes. It's not that I want to file bugs or detect those bugs. I think there's a use case that this should be serious, this bug, but... Yeah, it's not the right... Yeah, that was my idea, as I said. There are more than 30 people, which is great. We have 300 bugs to file. 30 minutes. We can also talk. It's fine if there's stuff to discuss. But these bugs are really easy. Where are those? Unknown filed after-perts. 260 packages, which are really... But there are other more interesting ones, like these post-installation script fades. So if we could file bugs, I'm happy to go around if somebody wants to file bugs and give advice. Wait for the microphone. Michael wants the microphone. You had templates for filing those bugs. Are they in the package or are they just in your evolution? They're in my own folder. Wouldn't that be useful to share them? More easily file them? I think that would be useful. I've used them, or you can just go to the BTS, to the bug-squared PO parts, which are somewhere here. They would lessen the barrage entry, I guess. Pardon? It would lessen the barrage entry and then... So that was... Setting up the mailing list and sharing those templates, yes. I'm sure that is in the to-do list. But the to-do list is also, I don't know, 300 lines or something. Wait for the microphone, please. You should really prioritize what makes other people contribute. I try. But so far, also I've not seen so many contributions. Which, of course, is a chicken and egg problem, but the to-do list is not that big. It's small fonts, yeah. Yeah, one after the other. Okay, let's do it in here. So that was... So, we already have a breakdown of failures and most of them are categorized... I mean, I identified already for the root cause of the problem. And I assume that for most of these, you already have a template. So is it the matter of writing a script that gets pointed to a web page and knows which is the template for the kind of error and queries the BTS to submit bug reports? Yeah, mostly. I would write the script so that it displays the bug report and asks to confirm do you really want to send this bug report. But for these files left over after purge, it's pretty obvious. Yeah, I mean, for the cases which is undoubtedly... Yeah, and it's definitely possible to start with some undoubted cases and then... I think that could be a better use of time. Yes, it's just more difficult to write such a script with 50 people. But I'd be happy to have such a script. Yes, definitely. That's just the user text I'm using. W and QA list and user text PU parts and PU parts DO. Which is mostly historic reasons to use both user text. I wanted to use user text for different categories of bugs, but somehow never got around to do that. About your to-do list, have you considered switching to S-Shoot to manage the shoot instead of doing it yourself? I think there's a wishlist bug for that, yes. It makes things much easier. Currently, I think the table is extracted manually and everything is set up manually. By PU parts? What do you mean by manually? Well, it's part of the code that takes the table extracted to some place and... Yeah, but that code is working fairly well, so why should I touch it? There are other parts which are working less well, which really require more attention. There are also bugs that should support AVM and whatnot, but that is really the machine is only used 10% of the day, so it's really very idle and gaining more speed is not really so useful for me. And I'm done with my slides. The last is just thank you. Thanks. Have you just considered giving people commit to the code who contribute, like Scott, for instance? Yes, sure. I'm happy to give Scott commit access and he's happy that I review the patches. But there are, I don't know, 10 people also who have commit access. I'm generally very happy to give people commit access. I'm not sure whether it's a stupid question, what we have time. Wouldn't it be the right thing to merge Linzian and PU parts? Because they are slightly doing the same things? No. Sneals here. You can probably better explain. The one is doing static analysis and you're installing and perching. They both detect some kind of policy violations, but Linzian is just checking the package as it is and not the installed system. So those are two different environments which are tested. And PU parts also only cares about the binary package, which is not a problem. Here's not a question, but Kvix on IRC says, does it make sense to make this task set for bite-sized bugs for DMs or people who become Deben contributors, so you have more people to engage with? That new NM file bugs or what was the question? No. There are bugs called bite-sized bugs, so small bugs who everyone can try, who is not really involved in the package itself, so you could mark a package of bugs with this tag and people would find it to help you without knowing about PU parts or something else. And that's what Kvix wanted to tell on IRC. I'm not aware of many of those bugs. Okay, thank you. But I can look, we have time, so let's look. No, those are not really easy. Those many of those wishlist bugs is to do... Well, yeah, I'm not sure what the question was, but maybe the point was that you could tag some of the bugs that are filed by PU parts, people as easy, because you know that they're easy, and so contributors could fix them more easily without doing much. Maybe that was not the point. Yeah, but if that's the case, then I would say no, because that would even put more load on me for filing bugs, and I don't want to. That's true, but usually all the bugs are in the same category, so you could just say this category is easy to fix, but I guess it's a general Debian problem and whatever. Yeah, but there are bugs like when the dependency is missing, those are really easy, but then the patch is also not needed. So maybe I'm not really used to this bite-sized bug category thing. I plan to do a release of PU parts before depthcon for what I failed, so I will just commit this to my to-do, okay? Or writing this report bug to helper. Seraphine? I see the page that lists all the packages that failed with a specific failure mode, and it says please file bugs. So how are these moved out of the page once you file the bug? How do I know that someone has already, other than taking money to the BTS? I lock into Piatti and move them from the failed directory to bugged, which is why I really want to use Python BTS because that is stupid manual work. Completely agreed, and I know this since two years or something, so the script that would automatically submit the bugs would also have to move? No, the next thing I'll do is add support for Python BTS. There are more use cases for using Python BTS when I can also display the bugs and can display several bugs per package at the moment. I just link to the BTS, to the package of the package, but I don't link to the specific bug. So using Python BTS to query the BTS is way better than keeping state that the package has been filed a bug because I cannot really detect unless the next test is successful that the bugs has been fixed. So that is really using Python BTS is higher on my to-do list than writing this report tool, which list. You find them on pupatstabian.org, and then you either go to vz.sit or squeeze, and there you have them. pupatstabian.org is just this about page, but you go on the left to whatever vz. And then there it is. Everything generally is linked in the left side, the documentation, the SVN repository, the bugs filed by pupatstabian.org, the bugs in pupatstabian.org, the to-do list is linked there. So everything is there. Okay, then let's finish that here. Thank you and have fun with pupatstabian.org.