 Kiitos. Mä haluan katsomaan ensimmäistä katsomista, jotka olisivat ymmärtänyt. Ymmärtää. Siitä, jotka olisivat käyttäneet ymmärtää. Siitä, jotka käyttävät ymmärtää. Onko anybody here who thinks it's a good thing? Is anyone here who thinks it's a slow bloated and crappy Britain? Okay, good. Then we are sort of in agreement. Pew Parts is a name originally suggested by Tollef Foghend in 2005, which I wrote because I noticed that many packages have difficulty uninstalling. Because the maintainer does the installation of a package because the maintainer uses the package themselves. But because they use it themselves, they never uninstall it. So there's an entire code path, a post-RM script that never gets called until someone files a release critical bug. So I figured it would be nice to have a tool for testing this. So I wrote Pew Parts, which is a package installation, upgrading and removal testing suite. And the name was chosen because it had zero hits on Google. And this is what it does. That's not actual code. It sort of looks like Python, but it's pseudocode. It first creates a CS shoot, a virtual environment, in which it pretends to install Debian. Then it installs the package into this CS shoot, removes it, and verifies that everything went okay. And if there's a problem, it reports a failure. And if there's no problem, it reports a success. And getting all the details working. This is why they... That's not me. So getting all the details worked out was a bit of iteration. But that's basically what it does. There's a lot of tests that Pew Parts does that don't show up in this pseudocode, some of which where it turns out a bad idea. But we'll get to that. The short version of how to use Pew Parts is this command. You have to run it as root because it creates a CS shoot and this requires root privileges. Someday, when I have a lot of extra time, I will add support for KBM so that you don't need to run it as root. But that's somewhere far in the future. The output is long. Typically, at least several tens of kilobytes. Sometimes several hundreds of kilobytes. I don't think I've ever gone over one megabyte, but still think. The output is in the form of a log file. You don't need to read all the tests there. There are specific parts of the log file that you need to look for. That's the good part. If you see that, then everything went okay and you can upload. The intention is that you use Pew Parts like you use LinkedIn before you do an upload. If there's any problems you want to fix, then you fix them. Essentially, you just scroll to the end of the log file. That's the important part. This is not necessarily the last line. There might be a dozen or two dozen lines after that, but grepping through the log file is easy enough. Sometimes you get an error. Depending on the state of the package archive, you get this error very rarely or every time. This is one of the things that hurts my ears. This broken sibling test is one of the things that turns out to be a bad idea because it gets triggered occasionally by some of the core packages in the archive, which result in every package that you test failing tests. It's almost visible that the timing at the beginning of the line is an offset from where the beginning of the run of the Pew Parts. On the machine at home on which I tested this, it took one minute, seven seconds to run, which is not too bad, but then again I have a local mirror and error at zero and so on, so in real life it might take a bit slower with the default options. Therefore, since you're all building your packages with P-builder anyway and P-builder has a tarball, and the creation of the tarball is what takes most of the time in a Pew Parts run, you can use that option, dash P. And then Pew Parts will use the P-builder, tarball and everything goes slightly faster, 12.12 seconds, if you're lucky. Sometimes it takes a long time. I have a couple of other options I would like to recommend. One is to skip the so called minimizing takes, which is a useful thing to do, but it rarely catches problems. What it does is when Pew Parts has installed Debian into a tier truth, it then throws away most of it, because I wanted to have only the essential packages basically. And that is basically no one runs a system like that. So this doesn't really find any problems that occur in real life. The other option is no sim links, because that always runs problems that you don't want to be bothered about. So tell us about the website. But overall, yes, as many as you want. As many as the kernel will let you. Pew Parts Debian org also uses by those minus no sim links, because it uses. There's a webpage at Pew Parts Debian org on displaying the results and having the manual and FAQ and other stuff. And it's a dedicated machine donated by HP some years ago and hosted at the University of Oslo. Yeah, thank you. It's running this setup now since spring. I started sometime in March and since May it's basically, I've not done much on it. It's a master slave setup, so it's not the normal setup last just described, but the master is scheduling the packages to be tested and the slave testing them, which can be extended to several slaves. And the machine access is also restricted. At the moment only Luke and me have access to it. But I would like other people to have access, at least as master, to be able to deal with the log files. The slave has full root access, so that maybe the S.A. doesn't want to give access. But really the most of the work can be done without, which is filing bugs. It's Pew Parts reports, which last wrote. I extended a little bit and added quite some best scripts to deal with the results and some cron job, which find packages, which are not available yet on AMD64. They will get rescheduled because they fail because some deep ends have not been built. Since reports about the status of the slave, we are male and the results of the Pew Parts run are put on the web, sorted by source packages and by maintainer address. It's since last week, Stefano included it into the PTS, so there's in the PTS now a link showing if the package has a Pew Parts problem and I used to use PTS user text to file bugs. There's an FAQ, where I put every questions which I ever got asked about Pew Parts I put in there. So if you have questions about Pew Parts, please ask. And then look at the Wiki first. This is the last Pew Parts result page. This sunny symbol means that the package is successfully run and there are quite many unknown packages because some deep ends could not be tested, so the status is unknown. In total there are Pew Parts, there be an org runs tests on sit and squeeze. The test in sit is just normal sit while the squeeze test includes first an installation in squeeze and then removal in squeeze and then an installation in Lennie and upgrade to squeeze and then removal in squeeze again. The machine has kept a bit of running about 1,000 Pew Parts tests a day, so checking the whole archive with this configuration takes not even two months. If you only want to do a full test on one distribution, it takes a month. So if the release team has plenty of time to add new tests and run the whole archive. Most packages are successfully tested by now because Pew Parts has been, there were several Pew Parts run by Lukas who then filed several hundred bucks. The problem are those 6,000 packages which cannot be tested. The easier ones are probably the circular depends due to Perl having circular depends on Perl modules and XORC on XSERVA or something and KDE, the new KDE LIPS introduced a circular dependency and I guess that is most of the 3,000 circular dependencies. I've started to grab for certain specific errors because at the moment Pew Parts just says failure and it's easier to do mass backpack filing if you see there are 50 packages that overwrite other packages files which is clearly RC and annoying. Those are the errors I can detect. But this grabbing is really not the right solution because command not found, for example, can be completely harmless and not the reason for an error. So this needs to be done in Pew Parts and this will be part of the BOP session where we want to discuss how to improve Pew Parts and give better results. And I don't remember that more than half of the bugs are not being detected by this grabbing. So this is improvement. Is Pew Parts extensible to the point where I could say for instance I want to check that not a single package in the entire archive ever accesses, let's say, ETCF-stap. The short answer to this is yes as soon as you rewrite it. I would not go so far called it rewrite at functionalities. It's just another test. The question I have for filing some of the bugs are they important or just serious because they are policy violations but we have lived with those bugs for years and nobody noticed them. So maybe not file them serious. Yeah, great. I plan to have discussions about these seven criteria on devil because they are at least 20 bugs each and I would like to have consensus and then do mass bug filing really on it because I used to do file two or three bugs every day for some time in the beginning of May I think but then stopped as some people complained that they believed that files left over in user local are not serious and I was not in the mood to discuss it and then I was okay and this is really the annoying part not running PU parts but dealing with the results which are people usually because the bugs are easy to file but then my to do for PU parts is first file bugs like all 300 errors we've detected are bugs so it should be filed and fixed. For the circular defense my idea is just to wide list Perl and Xorg because this will give us 2,000 more testable packages. I also would like to aid bug reporting that it fires up report bug with the log file included and the write package and the write user tag. Detect more errors of course. Our classes is this topic for the both. Multi arc support because it's master and slave the master could also give other slaves job and my idea is to have the packages to test distributed by architecture that this AMD64 machine tests all AMD64 and architecture all packages and the other PU parts last slaves only test the few packages for the architecture which are not available on AMD64 which is mostly boot loaders and the kernel packages so then a slave could be set up on a build D or another quite loaded machine because it will only run 5 or 10 PU parts tests a month anyway. The work with PU parts is really not keeping it running but dealing with the bugs and that's the easy part or that's also the part where you don't need machine access to do it just help on the mailing list basically and discuss with the other maintainers which severity it should have to deal with these problems. PU part is rather nitpicky and it does find sometimes problems that it shouldn't bother reporting but it also sometimes perhaps often enough finds problems that really should be fixed and well in my four years of being involved in PU parts yet met a bug that would wipe my hard disk but I'm sure it's out there somewhere and it would be nice if we could find this before the users do then we can at least tell them which bug reports to look at. You're testing removal of packages how do you handle essential packages? I don't test removal of essential packages actually I don't think we the master slave setup test essential packages at all that's one of the many shortcomings of PU parts but most the essential packages are maintained by people who are really really careful does anyone have another question? Please do so the question was that there's a rumor with PU part supporting co-builder instead of P-builder I have no idea if it's true the other day I asked the same question about S-build and somebody on IRC then said that is being worked on for co-builder so I'd say yes but I can't give you any details on it but I do have another question related to this are you planning or is it possible to have this somehow runnable by the user without having to maintain a truth install? sure PU parts creates a CH-shoot every time if it's not told to do otherwise so it will also populate it with the base system install? yes okay cool the simple command showed this actually does everything it's just not the fastest way of doing things why do you really want people to run it themselves actually if you have Q-parts at debian.org that works fine, that reports on the pts when something fails I think it's enough because people don't look at the pts often enough we also have lintian.debian.org but it doesn't help people actually fix problems until they run lintian themselves but lintian is much easier to run than pu-parts it's a shorter command I admit that I would like to make pu-parts faster and easier to run and someday I hope to have time to work on that but I think for the people who have enough computing capacity and my laptop is good enough running pu-parts is something that would be one way of making sure that the package actually works but yes I'm not saying that everyone should run it because people developing on netbooks probably want to conserve their battery life or something more important Is there a web interface where you can check the outputs of pu-parts so that you can look at other packages that you might, that you have some interest in to see whether they've got bugs that you could perhaps investigate more yourself rather than the two of you doing all the hard work finding the bugs The web interface has log files the successful one and the failed ones are trying to detect automatically depending bugs I'm looking at one of mine here where a tech packet is installing some fonts using dependencies and when it's removed some files but left behind it's not my package that's doing it it's something else that it depends on that's leaving those files behind How do you actually discover what packet had a problem? The way we do is that the master and the slave set up master looks at gives the slave packages so that the dependency is tested first and then your package and if the dependency fails leaves some files behind then your package won't be tested at all But there is a bug in the scheduler so that your package was tested despite having a bug there so I don't know when it occurs but it should be like last explained but it isn't There have also been some cases where when foo depends on bar and bar is tested first if it's tested alone it works but if it's tested with foo then it doesn't work and in this case someone needs to look at the problem and figure it out luckily these are rare There's also the case package depends on foo or bar foo has been tested successfully but then bar gets installed while testing your package and bar has a bug Sometimes I think we should not do dependencies No other questions? That was unexpectedly efficient of us We have a bof later in this conference Before the bof it would be really cool if people could try out Bupart because we have fast internet here and nobody wants to be on IRC and please do go out and kill the internet access so that we can do wireless as well so that you have some experience of Bupart and then come and tell us exactly what is wrong with it because that's what we want to hear on Wednesday Okay, don't kill the internet but okay, if you can, why please do We have a local mural here and all access to other murals is redirected to that one so please kill the mural I especially keenly realized that the only saving grace of the original Bupart's implementation is that it actually catches some bugs So I would also like to hear more viewpoints on how it could be improved what the problems are etc It's open to even to unconstructive criticism on Wednesday You do not have to be genteel Okay, I guess we are having a question Another question How easy is it to enable this to run on multiple architectures? In theory you can have a master and one or more slaves per architecture and it should work perfectly fine And at the moment you are testing which architecture? AMD64 Because the machine happens to be AMD64 Are you interested in any architecture in particular? Well, I've seen some architecture-specific packages with bugs Well, they were not AMD64 It would be nice to extend this to more architectures and someday hopefully we will Just a frivolous question How many times have you found bugs in Pui parts with Pui parts? With Pui parts, I think once Did it make you giggle? Yes, and it hurt my ears In my other packages I have found rather more problems with Pui parts Okay, then I guess we are... Thank you