 Okay, and now Holger will talk about pure parts another quality assurance effort of him after the Jenkins yesterday and Yeah, enjoy Hello, good morning Thank you. I Will talk about pure parts what pure parts is the development status and plans for the future Are you I'm Maintaining pure parts since 2006 or rather 2007. I was root on the pure parts WNORC machine before I was a DD So in case I just tell this as an example the DSA is quite more flexible than it seems How many of you had bucks filed by pure parts against your package how many of you had received false positives only Okay Quite some how many of you have filed bucks against pure parts Okay, cool. Thank you So Debbie and is defined by the Debbie in policy which describes what is expected from and pure parts test against the policy Lindsay just looks at the sources and Find problems from there and you parts actually installs the packets Finds Problems during installation Sorry, we gave you the one with it, which is apparently a bit broken. Okay That was actually a good one, but now it's pretty This has prefer the other Mick we are so have better Peoparts is working Peopart is short for package installation upgrading and removal testing suit and That's what it does now since a month it also runs adequate at the end of the installation so it finds all issues reported by adequate as well if You don't know adequate adequate is from Jacob work it's he introduced us half a year first to find Something wrong with pison libraries, I think and he added other tests also to find Wrongly linked libraries missing copyright and other stuff Also new since Three months is the support for multiple slaves Peopart says this master slave architecture in the past we only run one slave, but since Debian has received this bike mark cluster Peopart has moved there from a very old machine and it's the slave is now running with four cores and lots of rum so there's nothing happening on the files is on the disc anymore and Peopart is now I think 15 to 20 times faster than the machine So it's really possible now to test one suit in four days or something Well, it used to take two weeks and one suit while they're still uploads are happening So we used to test just sit testing to sit wheezy squeeze to wheezy and squeeze Nowadays, we test a lot more like we also test whatever we see to backpots to Jesse and squeeze to backpots sloppy What we don't test is Wheezy proposed because we test upgrades from wheezy to wheezy proposed There's some wish list bugs for other combinations, but I'm not sure if that is the right way forward There were one million Peopart's test run in the last four years, I think Um was almost two thousand bucks filed and only about three hundred are still open For RC bucks, it's almost one thousand four hundred RC bucks filed most of them are fixed and that's really just serious bucks for the numbers here and also care about important bucks and In average, it means there has been zero point eight six RC bucks filed per day in the last four and a half years since 2009 I think that's pretty impressive and Also impressive is the current status of Jesse, which is So this is There is up in the right corner 37,000 packages up past the test only 43 failures and This is with this Purple background means that about these failures. No bugs have been filed So all except for file your failures have been bucks filed, which is mostly the work of Andreas Beckman the last Year or something he has by now Andreas has overtaken last and me was filing Peopart's buck. I think I filed over 400 last has filed 200 and Andreas over thousand So he's really super active and for the VZ. It looks even while that is easy proposed so this is VZ where basically all green and only six failed locks in VZ We see proposed looks completely green because we only started it testing after VZ was released and There are eight failures instead of six in VZ Sit looks a bit worse. There's some bucks not filed and there's a total 200 failures That's because we are test more things and sit To use Peopart is really super easy. Just install it and run it against the Debian package or Run it against the changes file since I don't know since this year probably Peopart's also probably supports you're having your own archive and Getting some packages from the Debian archive and others from a local archive and There's another way to test PO cards, of course, which is not the recommended way Just uploading the package and wait for Peopart's to test it And I think everybody has done that including me. It's not recommended, but that's just life. So Originally Peopart's was written by Lars Wittzenius, but he's dropped out of six years ago Now it's mostly Andreas Beckmann Dave Steele and myself There's not been many committers like eight in total since 2010 and there was a new committer yesterday and Hopefully you will be the next I really like to take patches There are many wishlist bugs which are rather easy to implement because that's for example, we have a test not testing User share doc that user share doc is not writable according to policy that should be possible That test we have another test. We don't have is the same with user local So if you're interested in that to test how packages behave as low user local is not writable You can learn from this user share doc test We have a mailing list Peopart's list on alias. I also read Debbie in QA So in principle, I don't care on which list it is sometimes it's better on the QA list Because it might be more suitable for Lindsay and tests or other tools Or just use the Q W and QA C channel Peopart's is maintained in git If you want to work on it check out a feature branch, please or create a feature branch based on develop and Make your changes and send a pull request or file a buck we use master for releases develop for the daily development and the Peopart's Debbie and org instance usually runs the same code as developed just when some Big edge code code reorganization happens I switch off in the bike set branch and use that for the Debbie and org setup But normally it's really same as develop the road map is not really a road map there is a huge to do with ideas in git and We look at important or higher bugs But in general wish list bugs are really ignored because there's other stuff to do and There's some wish list bugs I really would like to see fixed like Peopart's used to have a unit test suit and it has rotten So it's just disabled at the moment. So if someone of you is into unit tests, I would be very happy to have this brought up Usable state again The other thing is have an archive with known good and bad packages which Peopart can test and so we can Confirm that it still detects the same failures it used to detect Someone is interested in keeping broken packages. This is a good opportunity There are some things wish list bugs Which I don't care about but I know other people care about There's The extra test for in its scripts. I'm personally not interested in testing in its grip or spending time on it Because I think they need to go away But I happily take the patch of someone wants this Cow builder support. I've also not implemented because running on it temp file system and run is fast enough for me LVM support the same What are the other bug I really would like to see is this make Peopart's run without root privileges That's possible with currents sch root tool The DSA has done a similar thing with their ch root set up on Porter machines And in fact this LVM support has been fixed in 2009. I just keep thinking it's not implemented So if you care for your stuff, please submit patches During this step conf and before there has been talks about having Peopart's run before accepting a package in the archive The other option would be to run pu parts or to use pu parts to event testing migration I think it would be better to run it before accepting a package in the archive But maybe it's easier Politically to get it and inside the testing migration Then the other thing pu parts currently only tests AMD 64 I don't think it's feasible At the moment maybe later with more hardware I'm to run it on the whole archive for all the suits at the first start I would like just like to test those packages which are not available on AMD 64 and other architectures Which are just a few packages And there are these Some errors detected by pu parts which not cause of pu parts failure Like broken sim links is one and also some adequate issues Which I think should be promoted to pu parts failure status But I don't think the debian the debian the pu parts maintainer should decide that themselves But rather The debian community must define what's a critical error Unless it's obvious from policy or from the behavior What do you want? And in the long run, I would like to go to automated bug filing for some issues But Partly Andreas has been too too productive in filing bugs And partly I fear the problems was having automated bugs And I'm overworked That was it about Thank you for running pu parts and for caring about the results And I'd like to hear some feedbacks ideas comments Everybody just sleepy so for In dev scripts, you can configure the build to always run lynching after building a package Is it possible to do the same with pu parts? I didn't get the beginning for what okay? In the dev scripts configuration file, you can tell the build To always run lynching after you finish a build Is it possible to do the same with pu parts? No at the moment not But that should not be too hard Just running against the produce changes for I'm not sure whether you've mentioned auto package test and whether it will ever be part of pu parts I don't I don't think pu parts is the right tool for this Because the auto package test are just in a few packages And you need to have several setups like auto packages can destroy the environment And pu parts is currently only testing in ch root And I would like to have it outside also to keep the scope of pu parts smaller And just rather run Auto package tester Somewhere else Have you ever thought about running pu parts as a Jenkins shop? I've thought about it and came to the conclusion. It's not useful Like they're at the moment 250,000 active locks And I don't the way pu parts is set up Is that you can Scroll them by source packages and you have all these packages and I would don't really know how to Map this in a Jenkins shop so There is pts integration. So the results that is played in the pts Um, yeah I think it's a danger like there's many Good tools and often people try how we try need to get everything in this tool And I think it's good to have several tools doing several jobs Uh about the pts integration Do you have a json dump or something that we could import in udd? Um at the moment, it's just a txt file with um all packages. There's a wishlist bug to improve that Um for all the suites, but there's no json Just now in the design. I could give you the number the bug number where we discuss this Are there complaints about pu parts? Okay So I must admit I'm one of the guys who's just uploading and then checking pyro parts afterwards um, how how much do lynchion and pyro parts overlap Or or do completely different things. I'm not quite clear on that already They overlap a little like lynchion also detects missing copyright files and pu parts detect them but there are many are P lynchion just looks at the source code And some problems are not cannot be as well detected by just installing it and comparing the system before and after So they complement each other Okay, thanks And sometimes it's also more effective to it's more effective if you can test it with lynxion It's better because lynxion is run by more people. It runs faster Um, so it's better to have the test on lynxion if possible So so yes, but what also happens is that? Well, I got bug reports for lynching clean packages from pyro parts So there are definitely things that are not detected quite a lot actually by lynxion The question is that I have um Is it is it possible to join efforts more for these two project projects Or is the design so different it is different? I know but is it it's so different that it actually Targets as some completely different part of the packaging workflow and the installation workflow They really work completely differently because lynxion is in effect unpacking a source package and looking at Its contents and doing pattern matching sort of analysis to look for The presence or absence of various things combinations of things that should or shouldn't exist Whereas pu parts is is actually sort of taking complete packages and installing them and looking at the consequences on a system So it's actually very different machinery I suppose in theory pu parts could run lynxion as part of its process But since it's really focusing on the installation or removal Characteristics of binary packages It's sort of a different data set and it makes sense to me at least conceptually that they're Separate efforts and while there are some things as holger says where they they overlap a little bit in what they can detect Um, I that's never actually bothered me. I mean I've never sort of had Different people complaining about the same problem in the same package at the same time Perhaps because I am much more careful about running linty and on all my packages before uploading them in pu parts, but We could add more patterns to lynxion to try to detect more things But I think that's for some problems. It's very difficult And if there's another solution to test these things, we can also use them and improve lynxion in other ways And also was now is the new third tool adequate adequate also looks at the package after it's installed Um, so that's different from that what lynxion does again So and I like these three tools and I also like pu parts to Keep only detecting serious problems or important issues so that you can always say pu parts failure is always a real at least important problem um, and Other tool pu parts should also find other problems but not fail because of this So I have this distinction between failure really and just complaining about minor stuff But pu parts should never fail about minor stuff Well, if there are no more questions We can go out in the sun or something Yeah, thank you holger