We should not close bugs before the fix has reached our users - which includes our installer, sometimes, maybe.
We therefore need some reliable way to check which installer is considered the officially current one, and which release of which packages that officially current installer contains.
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T553 unspecified when a PureOS issue is truly "resolved" | ||
| Resolved | mak | T700 unspecified which installer is currently stable and released, and what versions of which packages it contains |
Ehhh... What?
The latest release on https://downloads.pureos.net/ is the current one, and once it has been tested the released one (which should happen very quickly, ideally). If a release is considered broken, it is either removed or a more recent one is built.
Each and every image build is accompanied by a .packages files which lists the contained packages and their versions in details. See https://downloads.pureos.net/live/gnome/2019-02-10/pureos-8.0-gnome-live_20190210-amd64.packages for example.
There are also detailed file listings of stuff included in the installation images, as well as a build log and checksums (the former of which also contains all information on package versions).
So next in line to be tested in the February 2nd release, yes? If so what do we mean by "test", are we sanity testing i.e. it works in my machine kind of thing? I'd like to create a more formal QA process around this and would like to start from how we test today.
@jeremiah.foster There isn't a formal testing process. I check whether the system boots, installs and runs through the initial setup and the initial experience looks okay. Others do that as well on different hardware, and if nobody reports any major issues, the image is good to go.
If there was a particular change on the installer or initial setup that might have broken something, I will look at that change in more detail to see if really everything works as expected.
But that's about it, nothing fancy (or even structured) is currently happening.
Great, thanks for the reply. What triggers the build? Is it possible for me to trigger a build? I'd like to test our PureOS ISO for reproducible builds so I'd like to build two images of PureOS twice and test with diffostat.
@jeremiah.foster Currently I manually trigger builds by running a command on the archive server. I could likely give you access to that with permission of the sysadmins. Since the automated builds might be very slow though and the system will override the previous image in case there is more than one image build on the same day, I think that you might be happier with a manual image build.
With regard to installers, it is unclear to me which installer is the default. This is relevant because I'm trying to diagnose a situation where the installer fails on disks that are 4 TB large. It looks like, from the files that show which packages are included in the ISO, that we also have a 'pureos-installer' and a 'pureos-live-installer' along with 'calamares' which appears to be an installer as well. I assume that pureos-installer is the default (and pureos-live-installer is just for GNOME Live?
Just to elaborate on that: The pureos-*installer executables are either compatibility scripts or helper scripts that change installer configuration to the OEM settings. All of them eventually will launch Calamares.