 Good morning. I will be talking about scaling pu parts Debian org to multiple architectures Skip this one thing. I work barefoot some people think I like to break rules, which is not really true. I Think for Debian policy that should be strictly followed by Packages and we should not bend the rules if any package is a special snowflake It's probably buggy and needs to be fixed. We have 20,000 source packages and there's 30 or 40 or 50 special ones, but the rest is not so if your package is special I would like to know why With human societies they also need rules, but these rules need to be more flexible We are not software. We must bend these rules and special snowflakes are great, but this is for humans. Packages are different and For all rules there are exceptions and testing for policy compliance is hard So yeah, I started with this Debian pu parts Debian org service in 2009 Actually took over maintain as well as stop doing it will originally develop in 2007 There's now almost 700,000 locks from 54,000 packages in 28 suits with word tested in at the end of 2016 I'm aware by 47 suits in the last five years alone, we did almost 10 million tests and Today, I'm basically not active in developing pu parts anymore. I just maintain the service and maintain the source code I do sometimes updated for new stuff, but the development is done mostly by Andreas Beckman I Skip this as well because there are not so many people in the audience. Have you received a pu part report? Yay Have you received more than one buck in a source single source package? Yay, good the video team is here We have at least one that people contribute a year The talk is mostly done that there's more people contributing You but what is it? It's a package installation and upgrade removal test suite tests whether packages comply with Debian policy Or rather test the subset of policy mainly that whether packages can be installed upgraded removed Perched and that the system is the same afterwards Only uses up get it doesn't use up to do it. So we could repeat all these tests was also using up to do And only use the CH roots and not reassess them not other things. So it's test the subset and All bugs are fired manually We have we have some Templates, but there's no tool which will scan the log and say this is likely this kind of Which could be improved and it's another thing and the source code is written in Python Debian or It's actually rather small in my school base And yeah bugs and patches are very much welcome new contributors would really be awesome So few parts runs people put Debbie and all runs people parts and all packages and these suits which are many so just 47 suits that suit combination That's also from Jesse to stretch or from Jesse to stretch to Buster and And But and to back porch and to back porch and to proposed updates and or whatever and sadly, this is only on a 64 and Has been only 64 for the last 10 years and protest multiple architectures What the real fix would be at support for multiple architectures and people put parts master and That is being on the table since 10 years and nobody around to do it and I don't think it would be that hard, but it would be some work and then a few months ago I realized I could could just run two masters and be done With the different directories where they live and then they talk to different slaves and the slaves need to be real I386 or on HF or whatever, but just running two masters would be fine And so I hope that some DSA Debbie and admin People would be here to talk about resources It needs still then if you have two masters, then we would have few parts the web page twice and there would be no navigation between them But I think that would still be worthwhile at the start and as soon as we have these two more Architecture than somebody will hopefully write the code to make cross Architecture things right having it better isn't better than having it not and then there's more incentive to fix it if Yeah, and I think it would be good to test arm 64 or on HF. No, I see really six. It's not so useful probably But it's easy hardware to get because you can just run it on the 64 Yeah There's more stuff to be done Pew parts rep report at the moment takes 12 hours to run and we run it twice a day So that's something that only runs once a day and With two architectures that would run the double amount of time That's Andrea's is working on it split in splitting Pew parts reports and several bits which can be run at the same time But I think Pew parts reports also creates the report for all the old suits Which are old old old old old stable and old old old stable and that's a bit useless So there's definitely room for improvement Could also just put the results in a database and create the pages dynamically because at the moment we're creating 700,000 pages This report is only for the web pages or so to the interaction with Brittany No, no, it's just for the web pages. Brittany is used to in the testing in the devian release team area And it it passes the locks but the locks are created by Pew parts report And the locks are only only need to be passed once and then we then there's the result There's several classes detected of errors And we were if you would put that in a database then we can also process it as well And the other thing missing which is not in Pew parts report It's proper isolation of Pew parts itself the moment we only test within a CH route and on the same So it's TCP IP you can communicate with the host that sometimes kills processors on the host so if we would use kind of namespaces there or KVM or whatever Technology for proper isolation then DSA would be happy because at the moment the backup job Regularly killed and some other thing is cut it from DSA and then they get a Nagios Notification and And there's 17 bucks open against source PO parts I've tried to close all wishlist bucks, which were older than two or three years in the way worked on I put them in the to-do at the bottom at close wishlist bucks or something These are all more or less real errors problems Please help or it will not happen or Andreas will make it happen Maybe Andreas was some point doesn't this has no time tonight This was it. I missed the beginning of course, but can you comment maybe a little bit on the? The use of the of the release team now of the results of PO part I mean it I guess or at least I have the feeling that in the beginning it wasn't going smoothly For some transient things, but I haven't noticed any issues with that lately. So in the beginning there were a few more Bucks by people or generally that people will then when they have packaged it in my grave because of few pasts But I think that has It's not happening that much anymore at all Their release team uses that for the testing migration and also for proposed updates. They check the packages Install savingly That's it at the moment. There's also that's what We are doing is we're testing upgrades from Stable to testing to sit and That could block the migration of packages to testing Or it will show that packages will fail to upgrade later Are we are reporting them by filing bugs by filing bugs? The question is how we are reporting the failures. I think there's the script from the release team which Passes our output and then puts the block into Brittany, but I don't really know it's Brittany itself that passes the or yeah So it's a two-step. It touches the file and then it processes it to figure out if it's blocking or not And I think it's only blocking on regression not on yeah, it's only on regression But only only to sit At me there's no need for it to block on the transitions, right? You can just limit the sections that's that is working on It's only testing test thing at the moment so buster in this case Okay, but I guess you could test also on stable to testing or yeah But that they they look at it for proposed update, but this is rather manual Okay, so it's great that's it's being used actually in that way yet Yeah, I have any idea what Or have a feeling of the status of what you would do on another architecture, maybe even from the reproducible build View I would like to have DSA hardware for that Because it should be running constantly and we have the has resources So I would not the reproducible build stuff is all done on private hardware or in sponsor for this I didn't need the meant to abuse that for that But just if you ever run it or have a feeling for how other architectures are faring on this area I think there will be mostly the same because it's so spaced and the problems are usually so spaced There will be some installation failures found I guess through due to broken builds or stuff or Also missing dependency combinations, maybe and multi-arch kind of you mean multi-arch as in We don't test that yet It's gonna make it a lot more bigger problem. I guess yes But there the co-install bill or co-install install ability you can test also with the doser tools And so They these classes should be fine as well. Yeah, thank you for using pu part