- devel - lists.apertis.org

Fixing messy git commit graphs in packaging repositories
by Vignesh Raman 22 Feb '22

22 Feb '22

Hello all, Due to some rough edges hit during the development of our tools over the years, a few packaging repositories currently have rather confusing git histories. To make things easier to reason about, we decided to overwrite the git commit graph pointed by the apertis/v2021 branches of the affected git repositories. The git histories pointed by the apertis/v2021 branches of the packages below have been rewritten using git filter-branch to completely disconnect them from the history pointed by the apertis/v2022* branches: * https://gitlab.apertis.org/pkg/cppcheck <https://gitlab.apertis.org/pkg/cppcheck> * https://gitlab.apertis.org/pkg/eigen3 <https://gitlab.apertis.org/pkg/eigen3> * https://gitlab.apertis.org/pkg/fonts-freefont <https://gitlab.apertis.org/pkg/fonts-freefont> * https://gitlab.apertis.org/pkg/golang-github-modern-go-reflect2 <https://gitlab.apertis.org/pkg/golang-github-modern-go-reflect2> * https://gitlab.apertis.org/pkg/tinyxml2 <https://gitlab.apertis.org/pkg/tinyxml2> * https://gitlab.apertis.org/pkg/hidapi <https://gitlab.apertis.org/pkg/hidapi> The apertis/v2021 branches for the repositories below have been fixed using git rebase to ensure the versions in debian/changelog are monotonically increasing: * https://gitlab.apertis.org/pkg/cjson <https://gitlab.apertis.org/pkg/cjson> * https://gitlab.apertis.org/pkg/kissfft <https://gitlab.apertis.org/pkg/kissfft> * <https://gitlab.apertis.org/pkg/kissfft>https://gitlab.apertis.org/pkg/exfatprogs <https://gitlab.apertis.org/pkg/exfatprogs> This means that git fetch and git pull on any of those repositories will yield complaints about the history for the apertis/v2021 branch having been force-updated. No other branch is affected. In particular the pristine-lfs and pristine-lfs-source branches are not affected, and neither are OBS and the APT repositories. The changes will be pushed 2 days from now and an email announcing that the branches have been updated will follow immediately. Let us know if there's any doubt or concern. On behalf of the Apertis maintainer team, Vignesh

1 1

Feature freeze for v2021.4
by Walter Lozano 16 Feb '22

16 Feb '22

Hi all, I'm glad to announce that we have entered Feature Freeze for v2021.4 [1]. From this moment no additional features will be accepted for this release cycle. New features will be postponed to v2021.5. Thanks to everyone who contributed! Walter [1] https://www.apertis.org/release/v2021.4/release_schedule/ -- Walter Lozano Collabora Ltd.

1 0

Proposal: switch from ntp to ntpsec in Apertis
by Andrej Shadura 20 Jan '22

20 Jan '22

Hi all, In short, Debian is considering removing ntp package and switching to ntpsec which is a drop-in replacement. In Apertis, we already use systemd-timesyncd as a default ntp client, and ntp is as far as I can see only a dependency of some packages. Namely, fake-hwclock has ntp as a hard dependency, but not because it requires strictly ntp, but because at the time the dependency was added, there was no other viable alternative. However, it remains to be seen how much fake-hwclock itself is necessary, as it seems systemd-timesyncd already provides a replacement: From https://www.freedesktop.org/software/systemd/man/systemd-timesyncd.service.…: > systemd-timesyncd is a system service that may be used to synchronize > the local system clock with a remote Network Time Protocol (NTP) > server. It also saves the local time to disk every time the clock has > been synchronized and uses this to possibly advance the system realtime > clock on subsequent reboots to ensure it (roughly) monotonically advances > even if the system lacks a battery-buffered RTC chip. -------- Forwarded Message -------- Subject: Re: The future of src:ntp Resent-Date: Wed, 19 Jan 2022 03:20:23 +0000 (UTC) Resent-From: debian-devel(a)lists.debian.org Date: Tue, 18 Jan 2022 21:19:27 -0600 From: Richard Laager <rlaager(a)debian.org> To: debian-devel(a)lists.debian.org [I'm the Debian ntpsec maintainer.] On 1/18/22 11:21 AM, Paride Legovini wrote: > I'd prefer making ntp a dummy package depending on ntpsec rather than > having src:ntpsec takeover bin:ntp. If I understand correctly, you're suggesting src:ntp builds bin:ntp that is a dummy package which depends on ntpsec? Another option would be to have src:ntpsec build the bin:ntp dummy package and remove src:ntp entirely. Either seems fine to me. I don't have a strong preference. I can implement whatever is necessary on the ntpsec side. And for either option, probably likewise ntp-doc -> ntpsec-doc, ntpdate -> ntpsec-ntpdate, and if I broke out ntpdig as suggested in bug #1003966, sntp -> ntpsec-ntpdig. There are some differences. For example, ntp stores its configuration file at /etc/ntp.conf while ntpsec uses /etc/ntpsec/ntp.conf. [1] But bin:ntpsec's postinst already handles that transition. On 1/18/22 5:03 PM, Paride Legovini wrote: > bin:ntp has always been a specific NTP implementation, I think > it's OK if it's replaced by an almost compatible fork, less OK if a > completely different implementation is brought in instead. I'm biased here, but I agree. I think it makes the most sense to transition existing ntp installs to ntpsec, not chrony, as ntpsec is a drop-in replacement with a shared code history. This is my position even if we think that chrony should be the default for new installs. On that topic, I think the current default of systemd-timesyncd is fine. [1] When I was first packaging ntpsec, I was going to have it share as many paths, service names, etc. with ntp (as upstream NTPsec does). But this lead to issues with certain tooling (e.g. around init scripts) and ultimately I decided it was better to use a different namespace. This does mean that Debian ntpsec is patched and diverges a bit from upstream NTPsec. -- Richard

1 0

New Apertis v2023dev0 development release available
by Walter Lozano 16 Dec '21

16 Dec '21

1 0

New Apertis v2022pre preview release available
by Walter Lozano 09 Dec '21

09 Dec '21

1 0

Apertis release candidate v2023dev0.0rc1 available for testing
by Walter Lozano 08 Dec '21

08 Dec '21

Hello everyone, I'm glad to announce that Apertis v2023dev0.0rc1 images for all the supported platforms have been published: AMD64 https://images.apertis.org/release/v2023dev0/v2023dev0.0rc1/amd64/ Arm32 public https://images.apertis.org/release/v2023dev0/v2023dev0.0rc1/armhf/ Arm64 https://images.apertis.org/release/v2023dev0/v2023dev0.0rc1/arm64/ This is the fourth development release based on Debian Bullseye. Compared to v2022pre it contains * Updates from Debian Bullseye * Replacements for old GPL-2 version of GNU utilities such as cpio, diffutils, grep, gzip, tar and sed The test reports are below: * https://lavaphabbridge.apertis.org/report/v2023dev0/20211208.0020/apt * https://lavaphabbridge.apertis.org/report/v2023dev0/20211208.0020/ostree * https://lavaphabbridge.apertis.org/report/v2023dev0/20211208.0020/lxc * https://lavaphabbridge.apertis.org/report/v2023dev0/20211208.0020/nfs The full release schedule is described at https://www.apertis.org/release/v2023dev0/release_schedule/ Thanks, Walter -- Walter Lozano Collabora Ltd.

1 0

Re: [Devel] Forwarding dwarf2sources bug upstream.
by Andrej Shadura 08 Dec '21

08 Dec '21

Hi Peter and Sjoerd On 07/12/2021 15:03, Sjoerd Simons wrote: > Hey Peter, > > I prodded Andrew about this when i first saw your mail (as he's the > maintainer on the Debian side), but it seems he didn't take action on > it yet... > > dwarf2sources is a trivial tool which we use in the Apertis > infrastucture (a wopping 200 lines of Rust, mostly based on the gimli > example code) and given Apertis is based on debian stable written > against the versions in Debian stable. > > I doubt there are Debian users using it, so from my point of view it > would be better to drop it from Debian rather then blocking Rust > package migrations on it. I don't really intend to update it until we > start rebasing Apertis to bookworm in any case. > > Andrew, unless you plan to update it, could you please request removal > from Debian? While I do agree it doesn’t make sense to block other stuff from being updated, I don’t think a removal request is necessary at this point. I will try to find time to look at this around Christmas — meanwhile, it’s okay to raise the severity of the bug and break its build by updating its build dependencies. -- Cheers, Andrej

1 0

New Apertis v2021.3 stable release available
by Walter Lozano 02 Dec '21

02 Dec '21

Hello everyone, I'm glad to announce that Apertis v2021.3 stable release is now available! Apertis v2021.3 is the fourth stable release of the Apertis v2021 release flow. Apertis is committed to maintaining the v2021 release stream until December 2022. For more details about the Apertis release flows and support periods, see https://www.apertis.org/designs/release-flow/ You can find the full release notes at https://www.apertis.org/release/v2021.3/releasenotes/ This release ships the security updates from Debian Buster and the latest LTS Linux kernel on the 5.10.x series. Additionally it implements the approach used in v2022 TLS stack [1] to avoid licensing issues, which required upgrade glib-networking to 2.66 in order to properly support OpenSSL backend. Images are available for download at https://images.apertis.org/release/v2021/v2021.3/ Thanks to everyone who contributed! Walter [1] https://www.apertis.org/concepts/tls-stack/ -- Walter Lozano Collabora Ltd.

1 0

Apertis release candidate v2022pre.0rc1 available for testing
by Walter Lozano 01 Dec '21

01 Dec '21

Hello everyone, I'm glad to announce that Apertis v2022pre.0rc1 images for all the supported platforms have been published: AMD64 https://images.apertis.org/release/v2022pre/v2022pre.0rc1/amd64/ Arm32 https://images.apertis.org/release/v2022pre/v2022pre.0rc1/armhf/ Arm64 https://images.apertis.org/release/v2022pre/v2022pre.0rc1/arm64/ This is the second development release based on Debian Bullseye. Compared to v2022dev3 it contains * Updates from Debian Bullseye * New Flatpak Runtime for Apertis * Apply and enforce signatures for Apertis Flatpak packages and runtimes * Audio policy to mute song app when switching to video app * Improves license compliance checks * Improve docker experience * Improve packaging tools for developers The test reports are below: * https://lavaphabbridge.apertis.org/report/v2022pre/20211201.1511/apt * https://lavaphabbridge.apertis.org/report/v2022pre/20211201.1511/ostree * https://lavaphabbridge.apertis.org/report/v2022pre/20211201.1511/lxc * https://lavaphabbridge.apertis.org/report/v2022pre/20211201.1511/nfs The full release schedule is described at https://www.apertis.org/release/v2022pre/release_schedule/ Thanks, Walter -- Walter Lozano Collabora Ltd.

1 0

New Apertis v2020.7 stable release available
by Walter Lozano 25 Nov '21

25 Nov '21

1 0