https://release.debian.org/buster/freeze_policy.html
So Buster is Frozen today if I'm not mistaken. Is there anything we ought to do in our Laniakea for us to track the Freeze? My assumption is that we'll see fewer updates as fewer packages will be accepted into testing.
Also, if Debian removes packages from testing, will those get remove from PureOS? I'm thinking about things like gksu, do we have to manually remove packages that are removed from Debian?
Regards,
Jeremiah
Am Di., 12. März 2019 um 17:18 Uhr schrieb Jeremiah C. Foster jeremiah.foster@puri.sm:
https://release.debian.org/buster/freeze_policy.html
So Buster is Frozen today if I'm not mistaken. Is there anything we ought to do in our Laniakea for us to track the Freeze? My assumption is that we'll see fewer updates as fewer packages will be accepted into testing.
Jup, but aside from that there is nothing we need to change - all updates will keep flowing into PureOS from Debian's in-development buster suite.
Also, if Debian removes packages from testing, will those get remove from PureOS? I'm thinking about things like gksu, do we have to manually remove packages that are removed from Debian?
The correct answer to that question is "Maybe" ;-) Laniakea and dak will attempt to remove packages from PureOS that have also been dropped from Debian using the information they have about the package (migration status and most importantly reverse dependencies). The package will be autoremoved if the system sees no point in keeping it, but it is very conservative to ensure PureOS won't break by accident. So in doubt, a package will not be removed. If a package can't be removed, a sync issue is emitted and we can choose to remove it manually. See https://master.pureos.net/synchrotron/ for a list of issues (cruft issues are marked explicitly).
The gksu issue was special, because the package wasn't removed *and* no issue was emitted. I haven't tracked down the cause of this issue yet though, in any case this shouldn't have happened (the expected result would have been the package not being removed and an issue being emitted so this problem could have been dealt with manually).
Cheers, Matthias
On Wed, 2019-03-13 at 23:16 +0100, Matthias Klumpp wrote:
Am Di., 12. März 2019 um 17:18 Uhr schrieb Jeremiah C. Foster jeremiah.foster@puri.sm:
https://release.debian.org/buster/freeze_policy.html
So Buster is Frozen today if I'm not mistaken. Is there anything we ought to do in our Laniakea for us to track the Freeze? My assumption is that we'll see fewer updates as fewer packages will be accepted into testing.
Jup, but aside from that there is nothing we need to change - all updates will keep flowing into PureOS from Debian's in-development buster suite.
Awesome!
After Buster becomes stable, I assume we'll then just follow that and get security and other important updates as point releases?
Will we want to set up another tracker that then moves to testing to track bullseye/sid? I am not sure we'll need it aside from packages for the Librem 5. But the Librem 5 is ARM v8 and we can build images for that here: https://downloads.puri.sm/phone/
Currently the Librem 5 team has their own CI on a Cavium machine somewhere in Germany.
Also, if Debian removes packages from testing, will those get remove from PureOS? I'm thinking about things like gksu, do we have to manually remove packages that are removed from Debian?
The correct answer to that question is "Maybe" ;-) Laniakea and dak will attempt to remove packages from PureOS that have also been dropped from Debian using the information they have about the package (migration status and most importantly reverse dependencies). The package will be autoremoved if the system sees no point in keeping it, but it is very conservative to ensure PureOS won't break by accident. So in doubt, a package will not be removed.
Excellent. This sounds like a sane, useful setup.
If a package can't be removed, a sync issue is emitted and we can choose to remove it manually. See https://master.pureos.net/synchrotron/ for a list of issues (cruft issues are marked explicitly).
I've noticed those "cruft" notices.
The gksu issue was special, because the package wasn't removed *and* no issue was emitted. I haven't tracked down the cause of this issue yet though, in any case this shouldn't have happened (the expected result would have been the package not being removed and an issue being emitted so this problem could have been dealt with manually).
Cool.
Thanks Matthias.
Jeremiah
Cheers, Matthias
Am Do., 14. März 2019 um 00:06 Uhr schrieb Jeremiah C. Foster jeremiah.foster@puri.sm:
[...]
Jup, but aside from that there is nothing we need to change - all updates will keep flowing into PureOS from Debian's in-development buster suite.
Awesome!
After Buster becomes stable, I assume we'll then just follow that and get security and other important updates as point releases?
No, the way the system is set up after buster is released we will immediately jump onto the bullseye testing cycle. PureOS was designed as a semi rolling-release distribution, and so far we have not made any decision to change that (if we would want to change anything, doing that before buster is released is a good idea).
Will we want to set up another tracker that then moves to testing to track bullseye/sid? I am not sure we'll need it aside from packages for the Librem 5. But the Librem 5 is ARM v8 and we can build images for that here: https://downloads.puri.sm/phone/
Currently the Librem 5 team has their own CI on a Cavium machine somewhere in Germany.
If we do that, create one "frozen" PureOS suite and one that tracks testing, we would essentially abandon the rolling-release model and go to a new development model that is much closer to what Debian itself does, except that we would actually roill out our development release to the users by default. In that case, I'd wonder why we need the frozen suite at all... - If we want to change PureOS development, we need a good plan on what exactly we want to change and for which reason, and how much additional work the team can realistically handle (stable releases aren't maintenance free, quite the contrary!).
Also, if Debian removes packages from testing, will those get remove from PureOS? I'm thinking about things like gksu, do we have to manually remove packages that are removed from Debian?
The correct answer to that question is "Maybe" ;-) Laniakea and dak will attempt to remove packages from PureOS that have also been dropped from Debian using the information they have about the package (migration status and most importantly reverse dependencies). The package will be autoremoved if the system sees no point in keeping it, but it is very conservative to ensure PureOS won't break by accident. So in doubt, a package will not be removed.
Excellent. This sounds like a sane, useful setup.
At Ubuntu, as far as I know, this is still a manual process. We have a least a small amount of automation ^^
[...]
Cheers, Matthias
On Thu, 2019-03-14 at 00:18 +0100, Matthias Klumpp wrote:
Am Do., 14. März 2019 um 00:06 Uhr schrieb Jeremiah C. Foster jeremiah.foster@puri.sm:
[...]
Jup, but aside from that there is nothing we need to change - all updates will keep flowing into PureOS from Debian's in- development buster suite.
Awesome!
After Buster becomes stable, I assume we'll then just follow that and get security and other important updates as point releases?
No, the way the system is set up after buster is released we will immediately jump onto the bullseye testing cycle. PureOS was designed as a semi rolling-release distribution, and so far we have not made any decision to change that (if we would want to change anything, doing that before buster is released is a good idea).
Thanks for letting me know. I think that there is a consensus that it would be good to follow stable for the Librem 13 and 15. There have been things that have come into testing that have disrupted work on coreboot and have affected users ability to start Libre Office which is a bit of a problem for the enterprise users we're trying to get.
How can we set this up so we continue to follow Buster once it's stable?
Will we want to set up another tracker that then moves to testing to track bullseye/sid? I am not sure we'll need it aside from packages for the Librem 5. But the Librem 5 is ARM v8 and we can build images for that here: https://downloads.puri.sm/phone/
Currently the Librem 5 team has their own CI on a Cavium machine somewhere in Germany.
If we do that, create one "frozen" PureOS suite and one that tracks testing, we would essentially abandon the rolling-release model and go to a new development model that is much closer to what Debian itself does, except that we would actually roill out our development release to the users by default. In that case, I'd wonder why we need the frozen suite at all...
The frozen suite would become stable and be for the laptops. Doesn't that make sense? I doubt that the laptop folks want things like phosh and all the other updates that the phone will get.
- If we want to change PureOS development, we need a good plan on what
exactly we want to change and for which reason, and how much additional work the team can realistically handle (stable releases aren't maintenance free, quite the contrary!).
But Debian stable releases get many fewer updates. At least in my experience. I've run testing for years and then switched to stable and the number of updates drops by an order of magnitude.
Cheers,
Jeremiah
Dear Jeremiah,
Thanks for letting me know. I think that there is a consensus that it would be good to follow stable for the Librem 13 and 15.
I'm sure a few people have Thoughts & Feelings on this and it's quite a big deal for Purism generally in that it speaks to the alignment or even marketing of the Librem offerings, so proposing this rather big change under a discussion about the freeze cycle of another distribution does not feel quite right to me.
I wonder if you could start a new thread with a vaguely concrete proposal?
I wouldn't want anyone to miss the discussion at the very least and I'm certain it would also be extremely useful "historical documentation" of the reason for the switch that we can point new contributors to instead of rehashing it IRL or IRC.
Best wishes,
On Thu, 2019-03-14 at 13:25 -0400, Chris Lamb wrote:
Dear Jeremiah,
Thanks for letting me know. I think that there is a consensus that it would be good to follow stable for the Librem 13 and 15.
I'm sure a few people have Thoughts & Feelings on this and it's quite a big deal for Purism generally in that it speaks to the alignment or even marketing of the Librem offerings, so proposing this rather big change under a discussion about the freeze cycle of another distribution does not feel quite right to me.
Fair enough. But much discussion on PureOS is distributed. There are internal Purism discussions, Matrix, various issue trackers (gitlab, phabricator) and of course person to person. I try and build consensus in each channel before a concrete proposal.
I wonder if you could start a new thread with a vaguely concrete proposal?
Sure. But I'd love your thoughts on the topic before I do.
I wouldn't want anyone to miss the discussion at the very least and I'm certain it would also be extremely useful "historical documentation" of the reason for the switch that we can point new contributors to instead of rehashing it IRL or IRC.
I wouldn't want to leave anyone out of the discussion but right now I think we need to know what's possible before we drive consensus on a proposal. Internally various teams see the move to Buster as positive, next is to understand what we need to do to make it happen and if it is even possible with our tooling.
Cheers,
Jeremiah
Hi Jeremiah,
I wonder if you could start a new thread with a vaguely concrete proposal?
Sure. But I'd love your thoughts on the topic before I do.
Of course. But my point was really… not on this thread. :) Absolutely no need for anything resembling concrete proposal at this point; I believe I mispoke accidentally there.
I wouldn't want to leave anyone out of the discussion but right now I think we need to know what's possible before we drive consensus on a proposal.
I completely agree; let's start having that pre-discussion!
Best wishes,
-
Chris Lamb -
Jeremiah C. Foster -
Matthias Klumpp