alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2023-04-11T14:46:54Zhttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/58DT_RELR2023-04-11T14:46:54ZGhost UserDT_RELRmusl now has DT_RELR support in https://git.musl-libc.org/cgit/musl/commit/?id=d32dadd60efb9d3b255351a3b532f8e4c3dd0db1 (so it will be in the next release)
glibc added it in https://github.com/bminor/glibc/commit/e895cff59aa562cad83fa...musl now has DT_RELR support in https://git.musl-libc.org/cgit/musl/commit/?id=d32dadd60efb9d3b255351a3b532f8e4c3dd0db1 (so it will be in the next release)
glibc added it in https://github.com/bminor/glibc/commit/e895cff59aa562cad83fa0fdd187bfe4b45312d5 , in the 2.36 release
binutils supports setting this at link time (`-z pack-relative-relocs`) since 2.38. ld.lld added it in LLVM 15 (soon to be available). (prior to 15, it has it via `--pack-dyn-relocs=relr`)
there is a lot written about this new linker feature here: https://maskray.me/blog/2021-10-31-relative-relocations-and-relr . it has all the info you might want to know. (do read it!)
this issue is a proposal to enable this by default (via either LDFLAGS in abuild.conf or some form of binutils/lld default cmdline editing, former preferred). it would have to wait for the next musl release (or that patch can be backported, i have verified it works (if the support doesn't work, the binaries with RELR sections segfault instantly in the loader))
the main benefits are size. practically everything shrinks 5-8% in size with no gotcha. see the linked article for more details.
the main issue would be time travel compatibility. without backporting the musl patch to stable releases, or first waiting until things within reason all have the support (prior to toggling the linker flag), people using binaries from edge on stable would just have them segfault. we don't support this (mixing edge with stable), obviously, but practically everyone ends up doing it (much to my annoyance). so, i think it would be best to backport it one release (3.16) and then have it in 3.17 naturally and toggle it then for edge (after 3.17), or, alternatively, toggle it for edge before 3.17 if we backport the patches earlier. all the times can change depending on when musl makes a release , unless we backport it early
i have not tested if this feature is secretly broken outside of x86_64- maybe the other arches aren't ready for it.
overall, it's a free optimisation without much downside, that relies on relatively-new libc loading support. i don't see a reason to not enable it by default once musl supports it.
the time-travel issue needs more consideration- see some discussion in https://github.com/llvm/llvm-project/issues/53775 for instance. not sure if we can also implement a lockouthttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/52[3.17] Rework device manager handling, split busybox-initscripts2022-09-04T08:24:41ZLaurent Bercot[3.17] Rework device manager handling, split busybox-initscriptsIt all started in the 3.16 merge window with [a merge request](https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/34459) that sparked a lot more pushback than I was expecting.
Granted, the timing was bad, and the proposed cha...It all started in the 3.16 merge window with [a merge request](https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/34459) that sparked a lot more pushback than I was expecting.
Granted, the timing was bad, and the proposed changes had more impact than I realized. So @ncopa cherry-picked a few non-controversial changes that could be made before 3.16, and the remainder of the MR was shelved.
Today I'm coming back to discuss changes in [the rest of this MR (which I just reworked)](https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/34459), that I think would be beneficial for Alpine.
- Split `mdev-conf` and `mdev-openrc` from `busybox-initscripts`.
- Make `mdev-openrc`, `mdevd-openrc` and `udev-init-scripts-openrc` all provide the `dev-initscripts` virtual package.
- Make `alpine-base` depend on `dev-initscripts`.
The goal is to have mdev, mdevd and udev all symmetrical, instead of having mdev be privileged because it's provided by busybox and the other device managers be hacks around it. (Eventually, in the future, I would like mdevd to become the default because it can be paired with libudev-zero to provide full udev emulation - whereas mdev cannot - but this is not the point here.)
As @ncopa pointed out, the changes require additional modifications to `mkinitfs`, which I am willing and able to provide manpower for: implementing the fixes, testing that things don't break, and communicating clearly and efficiently with other testers. I think the reduction in ad-hocness, which means a reduction in technical debt, is worth the effort in the long run - although @ncopa was 100% right to refuse during the 3.16 merge window.
More generally, and this is more a matter of opinion and totally debatable, I would like functionality to be progressively stripped from `busybox-initscripts`, which is a package that gathers a bunch of miscellaneous policy scripts that are only related by the fact that their mechanism is provided by busybox. I don't think this package makes sense from a semantics point of view; it is more logical to provide the policy scripts classified by *service*, no matter whether or not the implementation of the service is done by busybox. To me, ideally, `busybox-initscripts` would be empty, and we'd have virtual packages for every service that is currently defined in it, so support for alternative implementations can be added over time. This would also ease the path to getting out of busybox, or at least providing alternative coreutils/low-level utilities implementations, is there is ever a will from Alpine to do so.https://gitlab.alpinelinux.org/alpine/tsc/-/issues/46Allow packages for larger ecosystems be maintained by teams2022-12-13T19:17:49ZKevin DaudtAllow packages for larger ecosystems be maintained by teamsThere are larger ecosystems which cannot easily be maintained by a single maintainer. For example gnome, which is currently maintained (on paper) by @cogitri, but we recently added 2 new developers to @team/gnome.
The current policy is...There are larger ecosystems which cannot easily be maintained by a single maintainer. For example gnome, which is currently maintained (on paper) by @cogitri, but we recently added 2 new developers to @team/gnome.
The current policy is that packages should have a single maintainer. The reason behind this is that ultimately, someone should feel responsible for the packages, and we want to avoid the bystander syndrome (someone else will fix it).
The proposal is to allow only for packages part of larger ecosystems (desktop environments, toolchains, etc), for which we typically already have a team/* group created. This would mean the maintainer entry would probably list something like `team/gnome` as name. I'm not sure what would make sense to use as e-mail address, either something fictional, or we could provide forwards (team-gnome@alpinelinux.org).
@cogitri, @leo: this would also mean aports-qa-bot would need to be adjusted to deal with this. As you cannot assign merge requests / issues to groups, it should be assigned to one member of the group. This could either be some designated member, or a round-robin assignment. In any case, the team should be pinged ('CC: @team/gnome').Kevin DaudtKevin Daudthttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/40Planning for 3.16 release2022-05-24T10:24:54ZNatanael CopaPlanning for 3.16 releaseWhat are the important things that we need to work on for 3.16 release?
- [x] LLVM/clang 13?
- [ ] ~rust in main?~
- [ ] ~apk3?~
- [ ] ~openssl3/libressl? (https://gitlab.alpinelinux.org/alpine/tsc/-/issues/28)~
- [ ] cloud images?
- [x...What are the important things that we need to work on for 3.16 release?
- [x] LLVM/clang 13?
- [ ] ~rust in main?~
- [ ] ~apk3?~
- [ ] ~openssl3/libressl? (https://gitlab.alpinelinux.org/alpine/tsc/-/issues/28)~
- [ ] cloud images?
- [x] new musl release?
- [x] modular kernel configs?
- [ ] ~replace ash? (https://gitlab.alpinelinux.org/alpine/tsc/-/issues/39)~
- [ ] signed docker images
- [x] python2
other?Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10750Out of space errors on armv7 / aarch64 runners2022-02-20T21:30:21ZAntoine MartinOut of space errors on armv7 / aarch64 runnersThe following discussion from alpine/aports!29253 should be addressed:
- [ ] @ayakael started a [discussion](https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/29253#note_216246): (+1 comment)
> issue: out of space erro...The following discussion from alpine/aports!29253 should be addressed:
- [ ] @ayakael started a [discussion](https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/29253#note_216246): (+1 comment)
> issue: out of space errors on aarch64 / armv7
Dotnet build requires at minimum 50GB of space to build. This is fine on x86_64 runners as there's usally about 200G of space available. No such luck on armv7 / aarch64 as there's only ~32-40GB of space on this runners. Anyway to have more space so I can confirm succesful build on aarch64 and armv7 architecture?https://gitlab.alpinelinux.org/alpine/tsc/-/issues/36Policy for non-maintainer updates to aports2022-06-07T12:42:03ZKevin DaudtPolicy for non-maintainer updates to aportsSeveral incidents make it clear we should create a policy around updates to packages to which the author is not the maintainer.
It should be clear for every developer what they can an cannot do. This is closely related to documenting [t...Several incidents make it clear we should create a policy around updates to packages to which the author is not the maintainer.
It should be clear for every developer what they can an cannot do. This is closely related to documenting [the responsibilities of a maintainer](#22).Kevin DaudtKevin Daudt2022-06-21https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10747smtp IPv62022-11-06T20:14:57ZJ0WIsmtp IPv6Forking from #6377:
IPv6 for `smtp.alpinelinux.org`Forking from #6377:
IPv6 for `smtp.alpinelinux.org`https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10745lists IPv62022-11-06T20:15:47ZJ0WIlists IPv6Forking from #6377:
IPv6 for `lists.alpinelinux.org`Forking from #6377:
IPv6 for `lists.alpinelinux.org`https://gitlab.alpinelinux.org/alpine/tsc/-/issues/35sse2 usage for programming languages (#20 part 1.5)2023-12-14T14:20:28ZAlex Xu (Hello71)sse2 usage for programming languages (#20 part 1.5)the resolution in #20 doesn't address a point which is relevant but was not brought up in that issue: what to do with programming language implementations and other packages with observable excess floating-point precision differences. fo...the resolution in #20 doesn't address a point which is relevant but was not brought up in that issue: what to do with programming language implementations and other packages with observable excess floating-point precision differences. for example, php "guarantees" ieee 754 floating-point support, but we don't provide that on x86-32. there have been several issues filed to this effect, such as aports#11645. fixing this issue for x86-64 simply required not gratuitously setting the fpu control word, but according to @dalias, it is not possible to fully implement standard ieee 754 floats on x86-32 without either sse2 or software emulation. a somewhat similar issue affects rust, which always uses sse2 on x86-32. a freebsd patch exists to get rid of it but of somewhat dubious quality (afaik not actually tested on no-sse2 machines).
this issue is not addressed by the resolution in #20; based on my interpretation of that, we should compile qt no-sse2, as there are minimal user-facing impacts other than it running slightly slower. however, if we compile php or go or rust without sse2, then all x86-32 users will get observably different floating-point results. if we compile with sse2, then they will not run on no-sse2 cpus, which i guess is not a huge issue for php or go, but may be an issue for rust.https://gitlab.alpinelinux.org/alpine/tsc/-/issues/29designated experts, etc.2022-06-07T11:00:27ZAriadne Conillariadne@ariadne.spacedesignated experts, etc.We need some sort of documented procedure for inviting designated experts (or even developers who are working on specific issues) to be able to join TSC meetings.We need some sort of documented procedure for inviting designated experts (or even developers who are working on specific issues) to be able to join TSC meetings.Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.space2022-06-23https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10739Upgrade netbox to 3.x2022-01-09T15:21:47ZKevin DaudtUpgrade netbox to 3.xhttps://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10738Continious Integration support for riscv642022-11-06T20:18:11ZSören TempelContinious Integration support for riscv64It would be nice to add a continuous integration service for the riscv64 architecture to GitLab CI. This would allow us to catch issues on this architecture, which might occur during package upgrades and modifications, earlier.It would be nice to add a continuous integration service for the riscv64 architecture to GitLab CI. This would allow us to catch issues on this architecture, which might occur during package upgrades and modifications, earlier.https://gitlab.alpinelinux.org/alpine/tsc/-/issues/27Officially decommission mips642022-02-23T19:51:36ZKevin DaudtOfficially decommission mips64The mips64 builder is gone. There is no way we can build any packages anymore, we can no longer fix any security issues, so it's prudent to officially decommission mips64.The mips64 builder is gone. There is no way we can build any packages anymore, we can no longer fix any security issues, so it's prudent to officially decommission mips64.Carlo LandmeterCarlo Landmeterhttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/22Maintainer responsibilities and privileges2022-06-07T10:58:24ZKaarle RitvanenMaintainer responsibilities and privilegesAs per the TSC decision, I am opening this issue for the purpose of defining the responsibilities and privileges of the package maintainers. To start the discussion, here are some preliminary ideas:
* responsibilities:
* providing f...As per the TSC decision, I am opening this issue for the purpose of defining the responsibilities and privileges of the package maintainers. To start the discussion, here are some preliminary ideas:
* responsibilities:
* providing fresh upstream releases on edge, preferably the latest release
but also considering
* support lifecycle compatibility between upstream and AL policy, and
* compatibility with depending packages
* on edge and all stable branches under active maintenance:
* fixing issues related to building and compatibility with the base
system
* backporting critical bug fixes from upstream
* fixing major security issues promptly
* adherence to TSC decisions and policies
* privileges:
* delegation of maintenance work to others who volunteer to help
* rejecting non-trivial changes
* reverting commits
In addition, we might want to define the processes for becoming a maintainer of a package and resigning as the maintainer.https://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/18Non-discriminatory meeting schedule2022-01-05T10:16:09ZKaarle RitvanenNon-discriminatory meeting scheduleAction point from 2021-08-19: Kevin will make a proposal on how to select the timeslot for future meetings such that each TSC member has regularly a chance to attend. He suggested everyone verify the availability data is correct in the s...Action point from 2021-08-19: Kevin will make a proposal on how to select the timeslot for future meetings such that each TSC member has regularly a chance to attend. He suggested everyone verify the availability data is correct in the spreadsheet he shared.Kevin DaudtKevin Daudthttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/12Future of eudev2022-01-13T18:49:35ZKevin DaudtFuture of eudevThe [eudev](https://github.com/gentoo/eudev) maintainer blueness indicated that they are no longer interested in maintaining eudev. They asked us if we want to take over maintainership:
```
blueness │ hi ncopa et al. Does anyone want t...The [eudev](https://github.com/gentoo/eudev) maintainer blueness indicated that they are no longer interested in maintaining eudev. They asked us if we want to take over maintainership:
```
blueness │ hi ncopa et al. Does anyone want to take over maintenance of eudev? I'm going to give it up since gentoo/musl is moving to systemd+openembedded patches
| it only has a few bugs, but is lagging behind upstream
```
So we can do 3 things
* Take over maintainership
* Drop it and switch to an alternative (libudev-zero)
* Leave it, hope someone else takes overhttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/8define process for moving things from main to community2022-06-28T15:50:51ZAriadne Conillariadne@ariadne.spacedefine process for moving things from main to communityA few times things have been moved to `community`, which shouldn't have been. We should define a process for handling these moves so that things like `gpsd` do not get moved to community, when they are needed by users who only want to u...A few times things have been moved to `community`, which shouldn't have been. We should define a process for handling these moves so that things like `gpsd` do not get moved to community, when they are needed by users who only want to use `main` repo.https://gitlab.alpinelinux.org/alpine/tsc/-/issues/5Where do we host the next TSC meeting?2021-08-03T21:24:46ZKevin DaudtWhere do we host the next TSC meeting?Sören TempelSören Tempelhttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/1Move sudo to community2023-05-15T10:47:47ZAriadne Conillariadne@ariadne.spaceMove sudo to community## Summary
At present, `sudo` is in the `main` repository, which requires us to provide security support for 2 years. Upstream `sudo` does not provide an "LTS" lifecycle, so this requires either performing security upgrades during the ...## Summary
At present, `sudo` is in the `main` repository, which requires us to provide security support for 2 years. Upstream `sudo` does not provide an "LTS" lifecycle, so this requires either performing security upgrades during the maintenance lifecycle, or backporting security fixes by hand.
## Benefit to Alpine
Prior to the creation of the security team, there was an unofficial preference to push `doas` as the preferred pivot tool for Alpine. This reinforces that messaging.
Additionally, we do not have to support `sudo` for a 2 year lifecycle, since there are no LTS branches for it.
## Contingency Plan
If there is a problem with implementing this plan, we will move `sudo` back to `main` from `community`, but no such problem is expected.
## Documentation
This will need to be documented in the release notes. We should recommend `doas` as the preferred pivot tool, noting that `sudo` is available in `community` if explicitly wanted.
## Owners
@kdaudt and @kaniini will implement this change on behalf of @team/security.
## Timeline
We would like to implement this change within the next few weeks, with TSC approval.