alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2023-07-11T11:26:36Zhttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/21[3.19] System change proposal: Rust in main2023-07-11T11:26:36ZAriadne Conillariadne@ariadne.space[3.19] System change proposal: Rust in main## Summary
Presently, Alpine provides the `rust` programming language in the `community` repository.
However, this has resulted in many packages being migrated to `community`, that users and maintainers would prefer to keep in `main`, ...## Summary
Presently, Alpine provides the `rust` programming language in the `community` repository.
However, this has resulted in many packages being migrated to `community`, that users and maintainers would prefer to keep in `main`, such as Ansible, and soon, Mesa. It is also expected that the Linux kernel may start to use Rust for some subsystems in the future.
A key reason why Alpine presently maintains Rust in the `community` repository is due to a lack of formal stability assurance from upstream. By taking the steps outlined in this SCP in concert with the implementation of suggested steps in the Rust community, it is believed that stability can be sufficiently guaranteed to warrant inclusion in `main`.
Thanks to @jirutka and others in the Alpine community for reviewing this proposal, as well as Esteban Kuber from the Rust Compiler development team.
## Benefit to Alpine
It is assumed that by following the steps in this proposal that Alpine users will be presented with a functional Rust toolchain which has a maintenance window of 2 years, that is also supportable by the Rust community through its normal support channels.
## Contingency Plan
If we are unable to meet the requirements of this proposal by the time 3.16 freeze approaches, Rust will remain in `community` until the 3.17 release.
## Owners
@kaniini (on behalf of the security team), others TBA.
## Requirements for adoption of rust in `main`
Support of rust in `main` is an ongoing burden, which will require creation of a dedicated Rust team (thereafter referred to as "Rust team"), like the base system toolchain team. It is desired that maintainers of Rust packages as well as participants in the upstream Rust development process participate in this team. We propose that the Rust team is chartered with an upstream contact serving as liaison between Alpine and the Rust core developers.
The Rust team must provide a production-quality Rust toolchain which passes all tests to be included in `main`. Updates to the toolchain must continue to pass tests. It is proposed to use Alpine's CI system to build Rust snapshots on a weekly basis against the Alpine patchset to verify that all tests pass. It is expected that the Rust team would coordinate with upstream as appropriate to solve any test failures. This will be implemented by maintaining the Alpine Rust patchset in git, in the same way as the GCC patch set is maintained.
The Rust team must provide this toolchain for all architectures supported by Alpine. A rust package must be able to be built with `arch=all`, unless there is a specific reason not to.
The Rust team must provide the latest stable release on all supported branches within a reasonable time period (no more than 14 days after upstream release). As the Minimum Supported Rust Version (MSRV) varies wildly from package to package, providing the latest stable release is key to ensuring that security updates to applications continue to build.
In the event of a CVE or other vulnerability against the base Rust toolchain, it is expected that Rust Upstream will give sufficient notice in order to allow the Rust team to prepare new packages within an accelerated time period. The Rust team is expected to abide by any embargo requirements imposed by Upstream.
Finally, it is expected that the Rust team produce a policy manual for the work-in-progress Developer's Handbook outlining best practices for packaging Rust software in Alpine.
## Oxidation of components in the Alpine base system
With the introduction of Rust to the base system, it may be desirable to oxidize certain components which have high security value in the system. Such discussions will be postponed until at least Alpine 3.18 development cycle (late 2023) to allow for the Rust team to acclimatize to meeting the proposed obligations.https://gitlab.alpinelinux.org/alpine/tsc/-/issues/43support DNS over TCP (as required by every DNS RFC since and including RFC1035)2023-05-09T20:30:31ZAriadne Conillariadne@ariadne.spacesupport DNS over TCP (as required by every DNS RFC since and including RFC1035)Musl does not presently support DNS over TCP. I am told that DNS over TCP support may be sponsored for inclusion in musl.
In my opinion, we should delay the 3.16 release until this is tested and validated to work, in other words, we sh...Musl does not presently support DNS over TCP. I am told that DNS over TCP support may be sponsored for inclusion in musl.
In my opinion, we should delay the 3.16 release until this is tested and validated to work, in other words, we should treat this as a release-critical bug.https://gitlab.alpinelinux.org/alpine/aports/-/issues/12763Conflicting files while installing libressl on Alpine 3.142021-08-05T11:08:50ZTinxConflicting files while installing libressl on Alpine 3.14When installing `libressl` on Alpine 3.14 there are two file conflicts of subpackages:
```
/ # apk --update --no-cache add libressl
fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpin...When installing `libressl` on Alpine 3.14 there are two file conflicts of subpackages:
```
/ # apk --update --no-cache add libressl
fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/community/x86_64/APKINDEX.tar.gz
(1/4) Installing libressl3.3-libcrypto (3.3.3-r0)
(2/4) Installing libressl3.3-libssl (3.3.3-r0)
(3/4) Installing libressl3.3-libtls (3.3.3-r0)
ERROR: libressl3.3-libtls-3.3.3-r0: trying to overwrite usr/lib/libtls.so.20 owned by libretls-3.3.3-r0.
ERROR: libressl3.3-libtls-3.3.3-r0: trying to overwrite usr/lib/libtls.so.20.0.3 owned by libretls-3.3.3-r0.
(4/4) Installing libressl (3.3.3-r0)
Executing busybox-1.33.1-r2.trigger
1 error; 10 MiB in 18 packages
```3.14.1https://gitlab.alpinelinux.org/alpine/aports/-/issues/12167RISC-V port upstream planning2021-12-06T15:54:20ZDrew DeVaultRISC-V port upstream planningSetting aside this ticket to manage plans for upstreaming my RISC-V port of Alpine Linux.
## Links
- [WIP aports tree](https://git.sr.ht/~sircmpwn/aports-riscv64)
- [riscv64 package repository](https://mirror.drewdevault.com/alpine/edg...Setting aside this ticket to manage plans for upstreaming my RISC-V port of Alpine Linux.
## Links
- [WIP aports tree](https://git.sr.ht/~sircmpwn/aports-riscv64)
- [riscv64 package repository](https://mirror.drewdevault.com/alpine/edge/main/riscv64/) ([signing key](https://mirror.drewdevault.com/alpine/edge/sircmpwn-25.rsa.pub))
The package repository is entirely natively built. I have a separate repository for the cross-compiled bootstrap packages, but I am working on rebuilding everything natively.
## Pulls
- https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/76
- https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16361
## Testing the port
**qemu**
TODO: Blocked on kernel & u-boot packages
**HiFive Unleashed**
TODO: Blocked on kernel & u-boot packages
**HiFive Unmatched**
TODO: Hardware on order
## Blockers
1. Natively build the bootstrap packages.
2. Rebase and address porting issues, see FIXME and DROPME commits.
3. Prepare aports pulls upstreaming riscv64 fixes.
4. u-boot and kernel packages, initramfs.
5. Write release scripts and produce a convenient install package.
6. Set up a builder? Finish building main & community, address issues as they come?
I have a RISC-V board which I am willing to devote to Alpine's use, for devs to have shell access to and as a builder.
## Comments
- The gcc cross compiler built by bootstrap.sh will likely have issues with libatomic for anyone who tries to use it, especially for building LLVM. It should work if you use the hosted build.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10661About making apk reliable and deterministic2020-05-10T05:11:39ZAndrea PudduAbout making apk reliable and deterministicHello,
Reaching out because this is a recurring problem, e.g. https://github.com/GoogleChrome/puppeteer/issues/4823
People even blogged about it: https://medium.com/@stschindler/the-problem-with-docker-and-alpines-package-pinning-18346...Hello,
Reaching out because this is a recurring problem, e.g. https://github.com/GoogleChrome/puppeteer/issues/4823
People even blogged about it: https://medium.com/@stschindler/the-problem-with-docker-and-alpines-package-pinning-18346593e891
In our case, we started using the edge branch and once it failed we thought it was normal, so we switched to a pinned version… it worked… until Friday afternoon.
This is the command:
![Screen_Shot_2019-10-21_at_10.15.52](/uploads/bb70a688ba66fa08fd9d55071570585c/Screen_Shot_2019-10-21_at_10.15.52.png)
And here’s the error (Friday, Oct. 18th):
![Screen_Shot_2019-10-21_at_10.14.30](/uploads/d6b06b78f35168e7109a1fea79e12726/Screen_Shot_2019-10-21_at_10.14.30.png)
The thing is that right now apk is unreliable and non deterministic because old packages are being deleted.
So the question is: there’s any official mirror where we can find all the packages, including the old ones? Or they will be deleted anyways?
Thanks for your time and support!https://gitlab.alpinelinux.org/alpine/abuild/-/issues/9996Alpine repo drops packages. This prevents package version pinning, and makes...2024-01-15T09:15:25ZP. CowlinatorAlpine repo drops packages. This prevents package version pinning, and makes apk non-deterministic.Alpine Linux has gained popularity as a Linux distribution that is especially good for Docker images.
What’s one of the biggest benefits of Docker? Reproducibility, including deterministic, reproducible Dockerfile builds.
You should be...Alpine Linux has gained popularity as a Linux distribution that is especially good for Docker images.
What’s one of the biggest benefits of Docker? Reproducibility, including deterministic, reproducible Dockerfile builds.
You should be able to make a Dockerfile deterministic by pinning package version numbers, so that your image is not dependent on the point in time when it was built.
Unfortunately, the Alpine package repo drops packages, even packages on "stable" branches.
Example: on 2020 March 10th, I found gcc 9.2.0-r3 on the Alpine package repository (web UI) under branch 3.11. On 2020 March 23rd, just 13 days later, my Dockerfile failed to run because the package gcc 9.2.0-r3 had been revoked from the branch 3.11 of the package repository, and was replaced with gcc 9.2.0-r4.
This makes Alpine Linux unsuitable for use in Docker images. Either your Dockerfile with pinning will "expire", or you are forced to avoid pinning package versions, which may cause unexpected behavior. When package maintainers decide to release a new version, this unexpected version will be automatically installed as soon as you rebuild your image the next time.
Compare this to PyPI or npm: No version is dropped, so version pinning works perfectly fine, no matter when you build or use your stuff.
There is a similar thread, https://gitlab.alpinelinux.org/alpine/apk-tools/issues/10661 , which Timo Teräs (@fabled) closed, based on the unconfirmed assumption that the OP was mixing an Alpine image with Alpine packages from 2 different branches.
However, in my example, both the Alpine version and the package version were on the 3.11 branch. There is no mixing.https://gitlab.alpinelinux.org/alpine/aports/-/issues/14058Alpine Linux should default to nf_tables backend2023-07-28T03:27:12ZDaniel GrayAlpine Linux should default to nf_tables backendAlpine linux commands such as "iptables" currently point to the "legacy" variants.
I inquired about this a year ago but [never got an answer](https://lists.alpinelinux.org/~alpine/users/%3C20210515133248.txheslwbqlzxzecn%40disroot.org%3...Alpine linux commands such as "iptables" currently point to the "legacy" variants.
I inquired about this a year ago but [never got an answer](https://lists.alpinelinux.org/~alpine/users/%3C20210515133248.txheslwbqlzxzecn%40disroot.org%3E).
Alpine Linux should default to the `nf_tables` variants ie `iptables-nft`.
It's now expected by things like libvirtd, docker, podman etc that you'll have the `nf_tables` backend.
Worth noting upstream Netfilter team doesn't support legacy any more. Both Debian, and other major distributions all default to the `nf_tables`.
@ikke does currently say that awall depends on the legacy framework, perhaps it should be updated.3.19.0Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/ca-certificates/-/issues/2WARNING: ca-certificates.crt does not contain exactly one certificate or CRL:...2023-01-06T16:39:37Zrusty xWARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping`c_rehash` is always logging this spurious warning, which is confusing.
WARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping
This happens because `update-ca-certificates` writes the file `/etc/ssl/...`c_rehash` is always logging this spurious warning, which is confusing.
WARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping
This happens because `update-ca-certificates` writes the file `/etc/ssl/certs/ca-certificates.crt` before invoking `c_rehash /etc/ssl/certs`.
`update-ca-certificates` should:
1. remove the bundle,
2. invoke `run-parts`,
3. wait until it finishes,
4. *then* write the new bundle.
That is also how it works on Debian.https://gitlab.alpinelinux.org/alpine/aports/-/issues/10136No pdftk package for Alpine 3.92022-10-13T14:22:30ZOtto BretzNo pdftk package for Alpine 3.9It existed in 3.8
https://pkgs.alpinelinux.org/packages?name=pdftk&branch=v3.8
but not in https://pkgs.alpinelinux.org/packages?name=pdftk&branch=v3.9
I can’t use the edge package since it links against libc:
ERROR: unsatisfiable ...It existed in 3.8
https://pkgs.alpinelinux.org/packages?name=pdftk&branch=v3.8
but not in https://pkgs.alpinelinux.org/packages?name=pdftk&branch=v3.9
I can’t use the edge package since it links against libc:
ERROR: unsatisfiable constraints: so:libgcj.so.17 (missing): required by: pdftk-2.02-r1[so:libgcj.so.17]
The command '/bin/sh -c apk add --no-cache --repository http://dl-cdn.alpinelinux.org/alpine/edge/community pdftk' returned a non-zero code: 2
Ive emailed the maintainer but did not get any reply. Is there any
chance of getting a 3.9 version?
*(from redmine: issue id 10136, created on 2019-03-19)*3.11.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/15498Update 3.18.4 image to fix new CVE CVE-2023-53632023-12-05T06:00:31ZArtem YakimenkoUpdate 3.18.4 image to fix new CVE CVE-2023-5363Mirroring [GitHub issue](https://github.com/alpinelinux/docker-alpine/issues/352) to source of truth here.
```
Trivy scan of 3.18.4 official image:
$ trivy image alpine:latest
2023-11-06T02:06:07.665Z INFO Vulnerability scann...Mirroring [GitHub issue](https://github.com/alpinelinux/docker-alpine/issues/352) to source of truth here.
```
Trivy scan of 3.18.4 official image:
$ trivy image alpine:latest
2023-11-06T02:06:07.665Z INFO Vulnerability scanning is enabled
2023-11-06T02:06:07.665Z INFO Secret scanning is enabled
2023-11-06T02:06:07.665Z INFO If your scanning is slow, please try '--scanners vuln' to disable secret scanning
2023-11-06T02:06:07.665Z INFO Please see also https://aquasecurity.github.io/trivy/v0.45/docs/scanner/secret/#recommendation for faster secret detection
2023-11-06T02:06:15.026Z INFO Detected OS: alpine
2023-11-06T02:06:15.026Z INFO Detecting Alpine vulnerabilities...
2023-11-06T02:06:15.028Z INFO Number of language-specific files: 0
alpine:latest (alpine 3.18.4)
Total: 2 (UNKNOWN: 0, LOW: 0, MEDIUM: 2, HIGH: 0, CRITICAL: 0)
┌────────────┬───────────────┬──────────┬────────┬───────────────────┬───────────────┬───────────────────────────────────────────────┐
│ Library │ Vulnerability │ Severity │ Status │ Installed Version │ Fixed Version │ Title │
├────────────┼───────────────┼──────────┼────────┼───────────────────┼───────────────┼───────────────────────────────────────────────┤
│ libcrypto3 │ CVE-2023-5363 │ MEDIUM │ fixed │ 3.1.3-r0 │ 3.1.4-r0 │ Incorrect cipher key and IV length processing │
│ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2023-5363 │
├────────────┤ │ │ │ │ │ │
│ libssl3 │ │ │ │ │ │ │
│ │ │ │ │ │ │ │
└────────────┴───────────────┴──────────┴────────┴───────────────────┴───────────────┴───────────────────────────────────────────────┘
In a 3.18.4 based Dockerfile, doing this fixes this issue:
RUN apk update && apk upgrade --no-cache libcrypto3 libssl3
```
Is it possible to push out a fresh image? Thank you :pray:3.18.5Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/14618Go: disable telemetry by default for Go 1.212023-02-25T11:23:19ZDrew DeVaultGo: disable telemetry by default for Go 1.21The next release of Go will report telemetry to Google by default. Alpine should patch this behavior out.
https://github.com/golang/go/discussions/58409The next release of Go will report telemetry to Google by default. Alpine should patch this behavior out.
https://github.com/golang/go/discussions/58409Sören TempelSören Tempelhttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/54Disable desktop packages on arches without graphical interface2022-12-19T16:13:47ZKevin DaudtDisable desktop packages on arches without graphical interfaces390x for example does not have a GPU, so building desktop / graphical packages for s390x has little benefit.
Some benefits of disabling packages for these arches:
* We don't have to spend time / energy on fixing build issues
* Reduct...s390x for example does not have a GPU, so building desktop / graphical packages for s390x has little benefit.
Some benefits of disabling packages for these arches:
* We don't have to spend time / energy on fixing build issues
* Reduction on disk space usage
This discussion came up due to rust becoming available for s390x, unblocking a lot of packages.https://gitlab.alpinelinux.org/alpine/aports/-/issues/14017Feature request: support kexec2023-01-09T08:34:04ZGhost UserFeature request: support kexec_This issue is a product of an IRC discussion at 2022-07-14 09:30:00 CEST_
_Related: https://gitlab.alpinelinux.org/alpine/aports/-/issues/8400_
# Feature
Enable the kexec syscall, such that users may quickly reboot their machines with..._This issue is a product of an IRC discussion at 2022-07-14 09:30:00 CEST_
_Related: https://gitlab.alpinelinux.org/alpine/aports/-/issues/8400_
# Feature
Enable the kexec syscall, such that users may quickly reboot their machines without going through POST and bootloader.
# Considerations
> kexec is a system call that is used to boot another kernel during runtime. This functionality can be abused to load a malicious kernel and gain arbitrary code execution in kernel mode, so this sysctl disables it.
[Linux Hardening Guide | Madaidan's Insecurities](https://madaidans-insecurities.github.io/guides/linux-hardening.html), 2022-03-19
# Requirements
- [x] Ship package [kexec-tools](https://pkgs.alpinelinux.org/package/edge/testing/x86_64/kexec-tools)
- [ ] Enable `CONFIG_KEXEC=y` in `lts.*.config`
- [x] Figure out a good, reliable way of having kexec off by default but togglable without recompiling kernel. (@ncopa's [suggested patch](https://tpaste.us/nVRv))https://gitlab.alpinelinux.org/alpine/aports/-/issues/13533util-linux-login and acct conflicts2022-03-14T17:24:03ZEdd Salkieldutil-linux-login and acct conflictsCurrently `util-linux-login` and `acct` both provide `usr/bin/last` and `usr/share/man/man1/last.1.gz`, causing installation errors if commands from both packages are required.Currently `util-linux-login` and `acct` both provide `usr/bin/last` and `usr/share/man/man1/last.1.gz`, causing installation errors if commands from both packages are required.https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-www/-/issues/1Cannot apk install: "temporary error (try again later)"2022-02-15T15:45:35ZMalcolm CrumCannot apk install: "temporary error (try again later)"Forgive me, I don't know what project to file this under. I think alpinelinux is experiencing an outage:
```
docker run --rm alpine:3.15.0 apk add openssh-client
fetch https://dl-cdn.alpinelinux.org/alpine/v3.15/main/x86_64/APKINDEX.ta...Forgive me, I don't know what project to file this under. I think alpinelinux is experiencing an outage:
```
docker run --rm alpine:3.15.0 apk add openssh-client
fetch https://dl-cdn.alpinelinux.org/alpine/v3.15/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.15/community/x86_64/APKINDEX.tar.gz
ERROR: https://dl-cdn.alpinelinux.org/alpine/v3.15/main: temporary error (try again later)
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.15/main: No such file or directory
ERROR: https://dl-cdn.alpinelinux.org/alpine/v3.15/community: temporary error (try again later)
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.15/community: No such file or directory
ERROR: unable to select packages:
openssh-client (no such package):
required by: world[openssh-client]
```
```
❯ curl https://www.alpinelinux.org
curl: (28) Failed to connect to www.alpinelinux.org port 443: Operation timed out
```https://gitlab.alpinelinux.org/alpine/council/-/issues/12Update Code of Conduct2022-10-06T15:36:40ZAriadne Conillariadne@ariadne.spaceUpdate Code of ConductI request that the Alpine council charter a working group to make minor revisions to the Code of Conduct, including, but not limited to, documenting a redress method. I also suggest that the Alpine council charter a specific working gro...I request that the Alpine council charter a working group to make minor revisions to the Code of Conduct, including, but not limited to, documenting a redress method. I also suggest that the Alpine council charter a specific working group for CoC inquiries, from users in the Alpine community who do not have conflicts of interest (e.g. are not on the Council or TSC).https://gitlab.alpinelinux.org/alpine/aports/-/issues/12904feat: librewolf2023-11-21T22:38:18Ztelroyfeat: librewolfA fork of Firefox, focused on privacy, security and freedom.
Website: https://librewolf-community.gitlab.io/
Source: https://gitlab.com/librewolf-community/browserA fork of Firefox, focused on privacy, security and freedom.
Website: https://librewolf-community.gitlab.io/
Source: https://gitlab.com/librewolf-community/browserhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12739Build the sdl package via sdl12-compat instead of SDL 1.22022-10-02T14:02:16ZNewbyteBuild the sdl package via sdl12-compat instead of SDL 1.2SDL 1.2 does not receive much attention any more, and upstream does not recommend using it[1]. There is, however, the replacement called sdl12-compat which implements the SDL 1.2 API and ABI using SDL 2.0, which means you gain things suc...SDL 1.2 does not receive much attention any more, and upstream does not recommend using it[1]. There is, however, the replacement called sdl12-compat which implements the SDL 1.2 API and ABI using SDL 2.0, which means you gain things such as Wayland support, better support for various input devices, and native PipeWire audio support. Fedora is making this change as of Fedora 35 (the next release)[2] and has a nice write-up about this change, linked below.
This also solves an issue in postmarketOS where we want to set `SDL_VIDEODRIVER=wayland` globally for Wayland UIs as SDL(2) works significantly better in native Wayland mode on phones, but doing this currently breaks SDL 1.2 applications as those then cannot find any video driver with this set:
```
[neboula@nocturne ~]$ SDL_VIDEODRIVER=wayland icebreaker
Hey. We're gonna need some graphics.
SDL error: No available video device
```
This should not be an issue with sdl12-compat as it uses SDL 2 behind the scenes, so this should be handled the same way in both.
- [1] https://github.com/libsdl-org/sdl12-compat#simple-directmedia-layer-sdl-sdl12-compat
- [2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VO33YWAYCQXAX5TZSWFE5Y5PNN7F7XRA/https://gitlab.alpinelinux.org/alpine/aports/-/issues/12730Unable to install php7-pecl-imagick=3.4.4-r7 with alpine:3.132021-06-09T15:16:31Zvgogh4vUnable to install php7-pecl-imagick=3.4.4-r7 with alpine:3.13Hi, i saw this: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12512 but the same error is happening to me now on alpine:3.13Hi, i saw this: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12512 but the same error is happening to me now on alpine:3.13https://gitlab.alpinelinux.org/alpine/aports/-/issues/12199aports with systemd files included2022-07-27T23:46:23ZTBKaports with systemd files included```
| /usr/lib/systemd/user/profiled.service | profiled | edge | testing | x86_64 |
|----------------------------------------------------...```
| /usr/lib/systemd/user/profiled.service | profiled | edge | testing | x86_64 |
|---------------------------------------------------------------------------------------------------------------------|-----------------------------|-------|------------|--------|
| /usr/lib/systemd/system/irccd.service | irccd | edge | testing | x86_64 |
| /usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/pleaserun-0.0.30/templates/systemd/default/program.service | logstash | edge | testing | x86_64 |
| /usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/pleaserun-0.0.30/templates/systemd-user/default/program.service | logstash | edge | testing | x86_64 |
| /usr/lib/systemd/user/mpDris2.service | mpdris2 | edge | testing | x86_64 |
| /lib/systemd/system/dbus-org.sailfishos.usermanager.service | user-managerd | edge | testing | x86_64 |
| /lib/systemd/system/nemo-devicelock.service | nemo-qml-plugin-devicelock | edge | testing | x86_64 |
| /usr/lib/systemd/system/monetdbd.service | monetdb | edge | testing | x86_64 |
| /usr/lib/systemd/system/tpm2-abrmd.service | tpm2-abrmd | edge | testing | x86_64 |
| /usr/share/phoronix-test-suite/deploy/phoromatic-systemd/phoromatic-client.service | phoronix-test-suite | edge | testing | x86_64 |
| /usr/share/phoronix-test-suite/deploy/phoromatic-systemd/phoromatic-server.service | phoronix-test-suite | edge | testing | x86_64 |
| /usr/lib/systemd/user/timed-qt5.service | timed | edge | testing | x86_64 |
| /usr/lib/systemd/system/pam_namespace.service | linux-pam | edge | main | x86_64 |
| /usr/lib/systemd/user/gnome-terminal-server.service | gnome-terminal | edge | community | x86_64 |
| /usr/lib/systemd/user/gnome-flashback.service | gnome-flashback | edge | community | x86_64 |
| /usr/lib/systemd/user/emacs.service | emacs-nox | edge | community | x86_64 |
| /usr/lib/systemd/user/emacs.service | emacs-x11 | edge | community | x86_64 |
| /usr/lib/systemd/user/emacs.service | emacs-gtk2 | edge | community | x86_64 |
| /usr/lib/systemd/user/emacs.service | emacs-gtk3 | edge | community | x86_64 |
| /usr/lib/systemd/system/baculum-api-lighttpd.service | baculum | edge | testing | x86_64 |
| /usr/lib/systemd/system/baculum-web-lighttpd.service | baculum | edge | testing | x86_64 |
| /usr/lib/systemd/user/plasma-kded.service | kded | edge | community | x86_64 |
| /usr/lib/systemd/user/plasma-kglobalaccel.service | kglobalaccel | edge | community | x86_64 |
| /usr/lib/systemd/user/evolution-addressbook-factory.service | evolution-data-server | edge | community | x86_64 |
| /usr/lib/systemd/user/evolution-calendar-factory.service | evolution-data-server | edge | community | x86_64 |
| /usr/lib/systemd/user/evolution-source-registry.service | evolution-data-server | edge | community | x86_64 |
| /usr/lib/systemd/user/evolution-user-prompter.service | evolution-data-server | edge | community | x86_64 |
| /usr/share/gnunet/services/systemd/gnunet.service | gnunet | edge | testing | x86_64 |
| /usr/lib/systemd/user/plasma-kwin_wayland.service | kwin | edge | community | x86_64 |
| /usr/lib/systemd/user/plasma-kwin_x11.service | kwin | edge | community | x86_64 |
| /usr/lib/systemd/system/gvmd.service | gvmd | edge | community | x86_64 |
```
Source: https://pkgs.alpinelinux.org/contents?file=*.service&path=*systemd*&name=&branch=edge&arch=x86_64
We might want to add an error to abuild during packaging to detect systemd stuff.