Outside of the Debian stable repo, what is the policy for packages in the MX repo?
Outside of the Debian stable repo, what is the policy for packages in the MX repo?
Specifically, how are new packages vetted before they're added to the MX stable repo? Is it the same process as Debian?
-
- Posts: 3602
- Joined: Tue Jun 14, 2016 2:02 pm
Re: Outside of the Debian stable repo, what is the policy for packages in the MX repo?
What specific part of “vetting” are you inquiring about?
The vetting to determine if I package should be built and added to the Repo?
Or the process to determine if a completed package is ready to be uploaded to the Repo?
For the first one, we typically determine if a package should be built and added to the Repo a few different ways, but in general
1) user requests
2) it’s already a package one of us is maintaining and there is a update we know of
3) one of us “finds” a new application we think users may want, this either is from us monitoring blogs, news sites, etc
The above isn’t “vetting” so much as it is determining if we should spend time packaging.
Once the above is determined, we will check out wherever the source code is. Verify it is a legitimate application, is the original or official source, copyright, etc. We check if the same application and specifically the same source code is being packaged by other Distros as well.
Dependent on the application and time we will review the source files and code to make sure it’s not doing anything funky. For example, I just updated Cherrytree, there really isn’t a need for me to review this prior. But for maybe a new application I may rummage through the source files real quick.
The next part of the process depends on if it’s already “debianized”, has Debian source packaging done. If it does we will review it and update as needed. If it doesn’t, they we create those files.
The next part isn’t really “vetting”, but since we build in Debian secure chroots (schroot) which doesn’t allow internet access during the compile, if something tries to change or alter the build (outside of the actual build files that is), the build will fail.
After that, dependent on the application, need to do it, and potentially time, the packager will test the built files either in a VM, physical system, or both. How much testing is done is depended on a lot of things. A lot of time we use a local Repo to test the installation process as well.
Recently I’ve been testing in VMs and physical installs that have OpenSnitch, so I catch any weird outgoing network processes that might occur. But I don’t expect others to do this, I’m not 100% right in the head.
Lastly, the package files are signed by the package maintainer and sent to the Repo Manager who adds them and does all the magic up there. Pretty sure our Repos aren’t set up much different that Debian’s, if that all. We actually include the original source files and required build files in the Repo.
I can’t speak to that whole process except for it the built files aren’t good and ready to pass the inclusion process, then the Repo Manager let’s us know they won’t be added and why. If that case we may have to fix and rebuild the package.
Once it’s added, we may test a install from the Repos, it all depends on the application and time.
That’s probably more than you asked for or wanted, but yeah.
Let us know if that doesn’t answer it or you have specific questions.
Edited quick for some typos
The vetting to determine if I package should be built and added to the Repo?
Or the process to determine if a completed package is ready to be uploaded to the Repo?
For the first one, we typically determine if a package should be built and added to the Repo a few different ways, but in general
1) user requests
2) it’s already a package one of us is maintaining and there is a update we know of
3) one of us “finds” a new application we think users may want, this either is from us monitoring blogs, news sites, etc
The above isn’t “vetting” so much as it is determining if we should spend time packaging.
Once the above is determined, we will check out wherever the source code is. Verify it is a legitimate application, is the original or official source, copyright, etc. We check if the same application and specifically the same source code is being packaged by other Distros as well.
Dependent on the application and time we will review the source files and code to make sure it’s not doing anything funky. For example, I just updated Cherrytree, there really isn’t a need for me to review this prior. But for maybe a new application I may rummage through the source files real quick.
The next part of the process depends on if it’s already “debianized”, has Debian source packaging done. If it does we will review it and update as needed. If it doesn’t, they we create those files.
The next part isn’t really “vetting”, but since we build in Debian secure chroots (schroot) which doesn’t allow internet access during the compile, if something tries to change or alter the build (outside of the actual build files that is), the build will fail.
After that, dependent on the application, need to do it, and potentially time, the packager will test the built files either in a VM, physical system, or both. How much testing is done is depended on a lot of things. A lot of time we use a local Repo to test the installation process as well.
Recently I’ve been testing in VMs and physical installs that have OpenSnitch, so I catch any weird outgoing network processes that might occur. But I don’t expect others to do this, I’m not 100% right in the head.

Lastly, the package files are signed by the package maintainer and sent to the Repo Manager who adds them and does all the magic up there. Pretty sure our Repos aren’t set up much different that Debian’s, if that all. We actually include the original source files and required build files in the Repo.
I can’t speak to that whole process except for it the built files aren’t good and ready to pass the inclusion process, then the Repo Manager let’s us know they won’t be added and why. If that case we may have to fix and rebuild the package.
Once it’s added, we may test a install from the Repos, it all depends on the application and time.
That’s probably more than you asked for or wanted, but yeah.

Let us know if that doesn’t answer it or you have specific questions.
Edited quick for some typos
NEW USERS START HERE FAQS, MX Manual, and How to Break Your System - Don't use Ubuntu PPAs! Always post your Quick System Info (QSI) when asking for help.
Re: Outside of the Debian stable repo, what is the policy for packages in the MX repo?
Whoops. Forgot to respond. But yes, that is a really good explanation. I guess what I was mostly asking is, as far as package stability and security checks for the MX stable repo are concerned, are they the same as what checks Debian employs before packages enter the Debian stable repo? Slightly different? Really different?SwampRabbit wrote: Thu Nov 25, 2021 8:26 am What specific part of “vetting” are you inquiring about?
The vetting to determine if I package should be built and added to the Repo?
Or the process to determine if a completed package is ready to be uploaded to the Repo?
For the first one, we typically determine if a package should be built and added to the Repo a few different ways, but in general
1) user requests
2) it’s already a package one of us is maintaining and there is a update we know of
3) one of us “finds” a new application we think users may want, this either is from us monitoring blogs, news sites, etc
The above isn’t “vetting” so much as it is determining if we should spend time packaging.
Once the above is determined, we will check out wherever the source code is. Verify it is a legitimate application, is the original or official source, copyright, etc. We check if the same application and specifically the same source code is being packaged by other Distros as well.
Dependent on the application and time we will review the source files and code to make sure it’s not doing anything funky. For example, I just updated Cherrytree, there really isn’t a need for me to review this prior. But for maybe a new application I may rummage through the source files real quick.
The next part of the process depends on if it’s already “debianized”, has Debian source packaging done. If it does we will review it and update as needed. If it doesn’t, they we create those files.
The next part isn’t really “vetting”, but since we build in Debian secure chroots (schroot) which doesn’t allow internet access during the compile, if something tries to change or alter the build (outside of the actual build files that is), the build will fail.
After that, dependent on the application, need to do it, and potentially time, the packager will test the built files either in a VM, physical system, or both. How much testing is done is depended on a lot of things. A lot of time we use a local Repo to test the installation process as well.
Recently I’ve been testing in VMs and physical installs that have OpenSnitch, so I catch any weird outgoing network processes that might occur. But I don’t expect others to do this, I’m not 100% right in the head.![]()
Lastly, the package files are signed by the package maintainer and sent to the Repo Manager who adds them and does all the magic up there. Pretty sure our Repos aren’t set up much different that Debian’s, if that all. We actually include the original source files and required build files in the Repo.
I can’t speak to that whole process except for it the built files aren’t good and ready to pass the inclusion process, then the Repo Manager let’s us know they won’t be added and why. If that case we may have to fix and rebuild the package.
Once it’s added, we may test a install from the Repos, it all depends on the application and time.
That’s probably more than you asked for or wanted, but yeah.![]()
Let us know if that doesn’t answer it or you have specific questions.
Edited quick for some typos
Re: Outside of the Debian stable repo, what is the policy for packages in the MX repo?
No idea about security checks beyond what SR has already said (eg checks with opensnitch, reviewing the source code even if just briefly) or what Debian does, but as regards stability issues, note that the packages built by the team go first into the MX Test Repo, and (usually) a forum post for that application will announce the new introduction/update. Users are invited to test the package version that is in Test Repo and provide feedback, bug reports, etc.
If there are complaints about stability, crashing, it not working well or at all, etc, users will report there.
If there is no feedback at all, good or bad, it never leaves the Test Repo, so most users won't ever come into contact with it except for those who willingly access the Test Repo and install said package of their own accord.
If there are complaints about stability, crashing, it not working well or at all, etc, users will report there.
If there is no feedback at all, good or bad, it never leaves the Test Repo, so most users won't ever come into contact with it except for those who willingly access the Test Repo and install said package of their own accord.
Desktop: Intel i5-4460, 16GB RAM, Intel integrated graphics
Clevo N130WU-based Ultrabook: Intel i7-8550U (Kaby Lake R), 16GB RAM, Intel integrated graphics (UEFI)
ASUS X42D laptop: AMD Phenom II, 6GB RAM, Mobility Radeon HD 5400
Clevo N130WU-based Ultrabook: Intel i7-8550U (Kaby Lake R), 16GB RAM, Intel integrated graphics (UEFI)
ASUS X42D laptop: AMD Phenom II, 6GB RAM, Mobility Radeon HD 5400