From jeremiah.foster at puri.sm Tue Dec 1 10:05:23 2020 From: jeremiah.foster at puri.sm (Jeremiah C. Foster) Date: Tue, 01 Dec 2020 13:05:23 -0500 Subject: [PureOS] Bits from PureOS | opening the firehose In-Reply-To: <20201125130433.GA206374@bogon.m.sigxcpu.org> References: <8aa923dcf17c2056e031cfa1228835a4e64c44f7.camel@puri.sm> <20201125130433.GA206374@bogon.m.sigxcpu.org> Message-ID: On Wed, 2020-11-25 at 14:04 +0100, Guido G?nther wrote: > Hi Jeremiah, > On Tue, Nov 24, 2020 at 02:11:02PM -0500, Jeremiah C. Foster wrote: > > Hello, > > > > Some bits from PureOS; > > Due to the fact that there is a new SoC / CPU in the Mini and > > the > > Librem 14, we need to move to a new kernel for these new devices. > > The > > good news is that the Byzantium kernel appears to fit our needs. > > Let me add that we (as discussed) started uploading Librem 5 related > packages to byzantium. Do we need to have another version of the "blessed builds" documentation for the new pipelines and build process? I think that documenting the end-to-end process of building a package for the Librem 5 might be useful for third party developers. I'm happy to work on this but will need a bit of guidance. > As of now we avoided uploading patched gtk, > g-c-c, g-i-s, webkit, epiphany, ... but that is bound to change in > the > next couple of days. The rule for byzantium there is: > - must be a regular (non-sloppy) build > - if the software is not adaptive per se it need to figure things out > by itself e.g. based on the form factor or the dowstream GTK toggle > we have. > > This will also lead to some consolidation e.g. on the g-i-s side and > the > aim is certainly to not break the laptop use case but i just want to > bring this up since the automatic testing you mentioned in earlier > reports would become even more useful now. Yes, it seems like now is the time to implement this. Just to be clear, you're looking to test the resulting Librem 5 image? Or just packages in the Byzantium distro? This makes a difference of course in how we run the automated QA. Regards, Jeremiah -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part URL: From guido.gunther at puri.sm Fri Dec 4 05:36:00 2020 From: guido.gunther at puri.sm (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Fri, 4 Dec 2020 14:36:00 +0100 Subject: [PureOS] Bits from PureOS | opening the firehose In-Reply-To: References: <8aa923dcf17c2056e031cfa1228835a4e64c44f7.camel@puri.sm> <20201125130433.GA206374@bogon.m.sigxcpu.org> Message-ID: <20201204133600.GA34429@bogon.m.sigxcpu.org> Hi, On Tue, Dec 01, 2020 at 01:05:23PM -0500, Jeremiah C. Foster wrote: > On Wed, 2020-11-25 at 14:04 +0100, Guido G?nther wrote: > > Hi Jeremiah, > > On Tue, Nov 24, 2020 at 02:11:02PM -0500, Jeremiah C. Foster wrote: > > > Hello, > > > > > > Some bits from PureOS; > > > > Due to the fact that there is a new SoC / CPU in the Mini and > > > the > > > Librem 14, we need to move to a new kernel for these new devices. > > > The > > > good news is that the Byzantium kernel appears to fit our needs. > > > > Let me add that we (as discussed) started uploading Librem 5 related > > packages to byzantium. > > Do we need to have another version of the "blessed builds" > documentation for the new pipelines and build process? I think that For core apps nothing changes there atm. Except that we're - building from the `pureos/byzantium` git branch - have `byzantium` in the changelog. - use a slightly different versioning scheme (see separate mail) > documenting the end-to-end process of building a package for the Librem > 5 might be useful for third party developers. I'm happy to work on this > but will need a bit of guidance. Since we drop the separate suite for byzantium (to not work around but work *with* laneakia and hence have proper package transitions and updates from Debian not overriding phone versions or have Matthias to force migrations, etc.) there's also no 3rd party maintenance atm since we don't have a suite in the archive for that So to somewhat rephrase what i raised before: do we want a separate suite for 3rd party software corresponding to amber-phone (name e.g. byzantium-apps or byzantium-l5-apps) bringing back all side effects we're currently trying to get rid off? These would then come from the /Librem5-apps gitlab space and we'd need indeed more docs. But my understanding so far was: - amber: Phone specific packages go to amber-phone (including 3rd party apps) - byzantium: All packages go to byzantium proper and 3rd party apps use another distribution path (e.g. flatpak). If that's not correct we'd need to introduce a suite for 3rd party apps first. > > As of now we avoided uploading patched gtk, > > g-c-c, g-i-s, webkit, epiphany, ... but that is bound to change in > > the > > next couple of days. The rule for byzantium there is: > > - must be a regular (non-sloppy) build > > - if the software is not adaptive per se it need to figure things out > > by itself e.g. based on the form factor or the dowstream GTK toggle > > we have. > > > > This will also lead to some consolidation e.g. on the g-i-s side and > > the > > aim is certainly to not break the laptop use case but i just want to > > bring this up since the automatic testing you mentioned in earlier > > reports would become even more useful now. > > Yes, it seems like now is the time to implement this. Just to be clear, > you're looking to test the resulting Librem 5 image? Or just packages > in the Byzantium distro? This makes a difference of course in how we > run the automated QA. I'm mostly after automatic tests for amd64 (which could even happen in a VM). Per device L5 or Laptops testing would go on top later on. Cheers, -- Guido > > Regards, > > Jeremiah > > _______________________________________________ > PureOS-project mailing list > PureOS-project at lists.puri.sm > https://lists.puri.sm/listinfo/pureos-project From agx at sigxcpu.org Fri Dec 4 05:37:57 2020 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Fri, 4 Dec 2020 14:37:57 +0100 Subject: [PureOS] Byzantium versioning Message-ID: <20201204133757.GB34429@bogon.m.sigxcpu.org> Hi, since we're dropping phone specific package for byzantium we also ought to drop `+librem5.X' in the version numbers. Matthias, what would you suggest here so that we generate higher version numbers in byzantium when backporting a package to both amber and byzantium to be consistent whith the rest of PureOS but also have a higher number than the current - Cheers, -- Guido From agx at sigxcpu.org Mon Dec 7 07:15:53 2020 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Mon, 7 Dec 2020 16:15:53 +0100 Subject: [PureOS] Byzantium versioning In-Reply-To: <20201204133757.GB34429@bogon.m.sigxcpu.org> References: <20201204133757.GB34429@bogon.m.sigxcpu.org> Message-ID: <20201207151553.GA43461@bogon.m.sigxcpu.org> Hi, On Fri, Dec 04, 2020 at 02:37:57PM +0100, Guido G?nther wrote: > Hi, > since we're dropping phone specific package for byzantium we also ought > to drop `+librem5.X' in the version numbers. Matthias, what would you > suggest here so that we generate higher version numbers in byzantium > when backporting a package to both amber and byzantium to be consistent > whith the rest of PureOS but also have a higher number than the current > > - For the time being addin `+byzN` at the end of the version number will do: 1.0-2pureos+librem5+byzN For new upstream versions we can drop the librem5 postfix since there's no difference between laptop and phone and we can do 1.0-2pureosN for byzantium? and 1.0-2pureosN~amberM for amber (when backporting the byzantium version to amber). Does that make sense? Cheers, -- Guido 1) according to https://tracker.pureos.net/w/development/packaging_overview/ > > Cheers, > -- Guido From jeremiah.foster at puri.sm Mon Dec 7 08:17:21 2020 From: jeremiah.foster at puri.sm (Jeremiah C. Foster) Date: Mon, 07 Dec 2020 11:17:21 -0500 Subject: [PureOS] Byzantium versioning In-Reply-To: <20201207151553.GA43461@bogon.m.sigxcpu.org> References: <20201204133757.GB34429@bogon.m.sigxcpu.org> <20201207151553.GA43461@bogon.m.sigxcpu.org> Message-ID: On Mon, 2020-12-07 at 16:15 +0100, Guido G?nther wrote: > Hi, > On Fri, Dec 04, 2020 at 02:37:57PM +0100, Guido G?nther wrote: > > Hi, > > since we're dropping phone specific package for byzantium we also > > ought > > to drop `+librem5.X' in the version numbers. Matthias, what would > > you > > suggest here so that we generate higher version numbers in > > byzantium > > when backporting a package to both amber and byzantium to be > > consistent > > whith the rest of PureOS but also have a higher number than the > > current > > > > ??? - > > For the time being addin `+byzN` at the end of the version number > will do: > > ??????? 1.0-2pureos+librem5+byzN > > For new upstream versions we can drop the librem5 postfix since > there's > no difference between laptop and phone and we can do > > ??????? 1.0-2pureosN > > for byzantium?? and > > ??????? 1.0-2pureosN~amberM > > for amber (when backporting the byzantium version to amber). > > Does that make sense? I think it does make sense Guido. I ought to have replied sooner, but I don't think that there's much I can add to the discussion since I think this follows our versioning scheme as documented. In fact I'm going to add this information to that document unless Matthias has any objections. Regards, Jeremiah > Cheers, > ?-- Guido > > 1) according to > https://tracker.pureos.net/w/development/packaging_overview/ > > > > > Cheers, > > ?-- Guido > _______________________________________________ > PureOS-project mailing list > PureOS-project at lists.puri.sm > https://lists.puri.sm/listinfo/pureos-project From matthias at tenstral.net Mon Dec 7 17:45:07 2020 From: matthias at tenstral.net (Matthias Klumpp) Date: Tue, 8 Dec 2020 02:45:07 +0100 Subject: [PureOS] Byzantium versioning In-Reply-To: <20201207151553.GA43461@bogon.m.sigxcpu.org> References: <20201204133757.GB34429@bogon.m.sigxcpu.org> <20201207151553.GA43461@bogon.m.sigxcpu.org> Message-ID: Am Mo., 7. Dez. 2020 um 16:16 Uhr schrieb Guido G?nther : > > Hi, > On Fri, Dec 04, 2020 at 02:37:57PM +0100, Guido G?nther wrote: > > Hi, > > since we're dropping phone specific package for byzantium we also ought > > to drop `+librem5.X' in the version numbers. Matthias, what would you > > suggest here so that we generate higher version numbers in byzantium > > when backporting a package to both amber and byzantium to be consistent > > whith the rest of PureOS but also have a higher number than the current > > > > - > > For the time being addin `+byzN` at the end of the version number > will do: > > 1.0-2pureos+librem5+byzN I think that's an okay-ish temporary workaround - unfortunately 1.0-2pureos1 isn't considered a higher version than 1.0-2pureos+librem5, so I see no other way to do this transition. > For new upstream versions we can drop the librem5 postfix since there's > no difference between laptop and phone and we can do > > 1.0-2pureosN > > for byzantium? and > > 1.0-2pureosN~amberM > > for amber (when backporting the byzantium version to amber). > > Does that make sense? > Cheers, > -- Guido > > 1) according to https://tracker.pureos.net/w/development/packaging_overview/ Yes, that's exactly how this should look like, I think - the phone packages wouldn't be treated any differently than regular PureOS packages, going forward. Makes a lot of sense to me :-) Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/ From agx at sigxcpu.org Tue Dec 15 04:32:36 2020 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Tue, 15 Dec 2020 13:32:36 +0100 Subject: [PureOS] Byzantium versioning In-Reply-To: References: <20201204133757.GB34429@bogon.m.sigxcpu.org> <20201207151553.GA43461@bogon.m.sigxcpu.org> Message-ID: <20201215123236.GA25586@bogon.m.sigxcpu.org> Hi, On Tue, Dec 08, 2020 at 02:45:07AM +0100, Matthias Klumpp wrote: > Am Mo., 7. Dez. 2020 um 16:16 Uhr schrieb Guido G?nther : > > > > Hi, > > On Fri, Dec 04, 2020 at 02:37:57PM +0100, Guido G?nther wrote: > > > Hi, > > > since we're dropping phone specific package for byzantium we also ought > > > to drop `+librem5.X' in the version numbers. Matthias, what would you > > > suggest here so that we generate higher version numbers in byzantium > > > when backporting a package to both amber and byzantium to be consistent > > > whith the rest of PureOS but also have a higher number than the current > > > > > > - > > > > For the time being addin `+byzN` at the end of the version number > > will do: > > > > 1.0-2pureos+librem5+byzN > > I think that's an okay-ish temporary workaround - unfortunately > 1.0-2pureos1 isn't considered a higher version than > 1.0-2pureos+librem5, so I see no other way to do this transition. > > > For new upstream versions we can drop the librem5 postfix since there's > > no difference between laptop and phone and we can do > > > > 1.0-2pureosN > > > > for byzantium? and > > > > 1.0-2pureosN~amberM > > > > for amber (when backporting the byzantium version to amber). > > > > Does that make sense? > > Cheers, > > -- Guido > > > > 1) according to https://tracker.pureos.net/w/development/packaging_overview/ > > Yes, that's exactly how this should look like, I think - the phone > packages wouldn't be treated any differently than regular PureOS > packages, going forward. > Makes a lot of sense to me :-) Thanks. Just to clarify since i got questions regarding that: We want to use 1.0-2pureosN~amberM even when we don't upload 1.0-2pureosN to byzantium right away since otherwise *if* we upload to byzantium later on we're in version trouble again. So basically i expect all uploads that don't go to landing to have a `pureosN~M`. Right? Also we use `~amberM` even for `amber-phone` to keep the length of the version number somewhat under control (and there's little conflict potential and the additional '-' confuses even more). Cheers, -- Guido > > Cheers, > Matthias > > -- > I welcome VSRE emails. See http://vsre.info/ >