alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2024-03-03T20:11:35Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15827[RFC] Disabling "thought-provoking stories" on Firefox new tab2024-03-03T20:11:35ZPatrycja Rosaalpine@ptrcnull.me[RFC] Disabling "thought-provoking stories" on Firefox new tabFirefox 125.0 seems to introduce "exceptional content curated by the Firefox family" on the new tab:
![image](/uploads/201e5b78b8466e7fa0e0c29ba35086ea/image.png)
should Alpine disable those by default in the vendor preferences? the `a...Firefox 125.0 seems to introduce "exceptional content curated by the Firefox family" on the new tab:
![image](/uploads/201e5b78b8466e7fa0e0c29ba35086ea/image.png)
should Alpine disable those by default in the vendor preferences? the `about:config` key responsible for this ( `browser.newtabpage.activity-stream.feeds.section.topstories` ) is also exposed as a checkbox in preferences, so a user would be able to enable them as such:
![image](/uploads/ac55ba47ef3bbe4474051dc64e30052d/image.png)https://gitlab.alpinelinux.org/alpine/aports/-/issues/13068Should Alpine drop official branding for Firefox?2023-11-21T22:38:18ZAriadne Conillariadne@ariadne.spaceShould Alpine drop official branding for Firefox?The newest version of Firefox now enables advertisements in the address bar if compiled with official branding.
My understanding is that disabling this functionality by default may leave us in breach of the Mozilla trademark policy.
I ...The newest version of Firefox now enables advertisements in the address bar if compiled with official branding.
My understanding is that disabling this functionality by default may leave us in breach of the Mozilla trademark policy.
I think we should want to disable this functionality (and probably also Pocket in general) since it has gotten to this level of aggressiveness, but I don't see a path forward that allows us to legally do so without dropping the official branding.
What do we think?Rasmus Thomsenoss@cogitri.devRasmus Thomsenoss@cogitri.devhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9074Aports contributions - license & copyright?2023-11-20T18:31:34ZTBKAports contributions - license & copyright?The question was brought up with this PR -
https://github.com/alpinelinux/aports/pull/4490/files and has also
previously been touched in https://bugs.alpinelinux.org/issues/7423
The https://git.alpinelinux.org/cgit/aports/tree/README.md...The question was brought up with this PR -
https://github.com/alpinelinux/aports/pull/4490/files and has also
previously been touched in https://bugs.alpinelinux.org/issues/7423
The https://git.alpinelinux.org/cgit/aports/tree/README.md file nor is
there another file mentioning it in the git repo.
and I have searched the sites and wiki and can not find the answer.
So I have the following questions:
- Which license are the aports themselves (APKBUILD, pre, post…)
under?
- Who are the copyright holders (the contributor or given to the
project)?
- Should AL have a CLA
(https://en.wikipedia.org/wiki/Contributor\_License\_Agreement)?
*(from redmine: issue id 9074, created on 2018-07-11)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/13269Tracking issue for official riscv64 support2024-03-12T19:59:34ZSören TempelTracking issue for official riscv64 supportIt would be nice to have official riscv64 support for the upcoming ~~3.16~~ ~~3.17~~ 3.18 release of Alpine Linux. From my point of view, there are a few issues that should be addressed within the upcoming development cycle to offer offi...It would be nice to have official riscv64 support for the upcoming ~~3.16~~ ~~3.17~~ 3.18 release of Alpine Linux. From my point of view, there are a few issues that should be addressed within the upcoming development cycle to offer official support for the riscv64 architecture. This issue serves as a tracking issue to track the overall status of Alpine riscv64 support.
* [x] #12985: Boostrap rustc for riscv64. Currently, a lot of packages are disabled due to lack of rustc. I would personally argue that would be beneficial to add support for `riscv64` to `community/rust` before supporting the architecture officially given the vast amount of packages that depend on rust.
* *Rust support for riscv64 is kind of wonky at the moment*
* [ ] #13267: Don't build riscv64 packages with `options="!check"` globally. This seems to be a formal requirement set forth by the TSC for official architecture support in a `-stable` branch [\[0\]][0]. This will likely require real riscv64 hardware for the builders.
* [x] https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10738: It would be nice to have continuous integration support for riscv64 in GitLab since this allows us to detect riscv64 build issues on package upgrades/modifications early.
* We have optional CI support nowadays
* [ ] Determine what kind of installation media we want to provide for riscv64. @ddevault has been working on having
U-Boot bootstrap UEFI into grub (cb053f3506f9486d41a9c5744e07116ccc6cbaa1) on the Unmatched. Additionally it might be nice to provide an APKVOL image (similar the "Generic ARM" image) for RISC-V (see #12976). I believe @clandmeter was also working on such an image.
People which have RISC-V hardware and might be interested in official riscv64 support: @ariadne, @rvs, @clandmeter, @ddevault.
Might be useful to also create a riscv64 team?
<!--
* [ ] Regarding the Unmatched, it would also be useful to support installation of U-Boot to the SPI Flash in the `update-u-boot` script (see #13268)
-->
[0]: https://gitlab.alpinelinux.org/alpine/tsc/-/blob/master/minutes/2021-11-09.md#stable-releases-for-riscv64https://gitlab.alpinelinux.org/alpine/aports/-/issues/12406ERROR: busybox-1.32.1-r2.trigger: script exited with error 1 on alpine:3.13.12021-08-31T21:48:01ZFabian NeugartERROR: busybox-1.32.1-r2.trigger: script exited with error 1 on alpine:3.13.1Hey!
I'm trying to build a docker image for armv7 with [GitHub actions](https://github.com/neugartf/mautrix-telegram/actions/runs/546400737/workflow) from `alpine:3.13.1`, which fails with the following error:
```
#5 21.67 (148/148) Inst...Hey!
I'm trying to build a docker image for armv7 with [GitHub actions](https://github.com/neugartf/mautrix-telegram/actions/runs/546400737/workflow) from `alpine:3.13.1`, which fails with the following error:
```
#5 21.67 (148/148) Installing yq (3.4.1-r0)
#5 22.02 Executing busybox-1.32.1-r2.trigger
#5 22.02 ERROR: busybox-1.32.1-r2.trigger: script exited with error 1
#5 22.02 Executing ca-certificates-20191127-r5.trigger
#5 22.04 /bin/sh: can't open 'trigger': No such file or directory
#5 22.04 ERROR: ca-certificates-20191127-r5.trigger: script exited with error 2
#5 22.06 1 error; 227 MiB in 162 packages
#5 ERROR: executor failed running [/dev/.buildkit_qemu_emulator /bin/sh -c apk add --no-cache python3 py3-pip py3-setuptools py3-wheel py3-virtualenv py3-pillow py3-aiohttp py3-magic py3-sqlalchemy py3-telethon-session-sqlalchemy py3-alembic py3-psycopg2 py3-ruamel.yaml py3-commonmark py3-idna py3-decorator py3-tqdm py3-requests py3-numpy py3-pysocks py3-cffi py3-qrcode py3-brotli ffmpeg ca-certificates su-exec netcat-openbsd olm-dev py3-pycryptodome py3-unpaddedbase64 py3-future bash curl jq yq]: exit code: 1
```
<p>
<details>
<summary>Dockerfile</summary>
<pre><code>FROM alpine:3.13.1
RUN apk add --no-cache \
python3 py3-pip py3-setuptools py3-wheel \
py3-virtualenv \
py3-pillow \
py3-aiohttp \
py3-magic \
py3-sqlalchemy \
py3-telethon-session-sqlalchemy \
py3-alembic \
py3-psycopg2 \
py3-ruamel.yaml \
py3-commonmark \
# Indirect dependencies
py3-idna \
#moviepy
py3-decorator \
py3-tqdm \
py3-requests \
#imageio
py3-numpy \
#py3-telethon@edge \ (outdated)
# Optional for socks proxies
py3-pysocks \
# cryptg
py3-cffi \
py3-qrcode \
py3-brotli \
# Other dependencies
ffmpeg \
ca-certificates \
su-exec \
netcat-openbsd \
# encryption
olm-dev \
py3-pycryptodome \
py3-unpaddedbase64 \
py3-future \
bash \
curl \
jq \
yq
COPY requirements.txt /opt/mautrix-telegram/requirements.txt
COPY optional-requirements.txt /opt/mautrix-telegram/optional-requirements.txt
WORKDIR /opt/mautrix-telegram
RUN apk add --virtual .build-deps \
python3-dev \
libffi-dev \
build-base \
&& sed -Ei 's/psycopg2-binary.+//' optional-requirements.txt \
&& pip3 install -r requirements.txt -r optional-requirements.txt \
&& apk del .build-deps
COPY . /opt/mautrix-telegram
RUN apk add git && pip3 install .[speedups,hq_thumbnails,metrics,e2be] && apk del git \
# This doesn't make the image smaller, but it's needed so that the `version` command works properly
&& cp mautrix_telegram/example-config.yaml . && rm -rf mautrix_telegram
VOLUME /data
ENV UID=1337 GID=1337 \
FFMPEG_BINARY=/usr/bin/ffmpeg
CMD ["/opt/mautrix-telegram/docker-run.sh"]</code></pre>
</details>
</p>
Any ideas how to fix this?
Thanks!https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10712triggers on files2024-01-10T15:53:00ZLuca Weisstriggers on filesCurrently apk-tools only supports triggers on directories but it would be quite convenient to have the possibility to get triggers executed on updated files.
> Apk-tools can "monitor" directories and execute a trigger if any package ins...Currently apk-tools only supports triggers on directories but it would be quite convenient to have the possibility to get triggers executed on updated files.
> Apk-tools can "monitor" directories and execute a trigger if any package installed/uninstalled any file in the monitored dir.v3.1https://gitlab.alpinelinux.org/alpine/aports/-/issues/14169gcc-cross2023-12-08T12:42:44ZDrew DeVaultgcc-crossOpening an issue just to mark that this is desirable to add at some point. Such a package is a bit more intimidating than binutils-cross, but also useful.
Aside: might be nice to write a sysroot manager tool that apk add's packages for ...Opening an issue just to mark that this is desirable to add at some point. Such a package is a bit more intimidating than binutils-cross, but also useful.
Aside: might be nice to write a sysroot manager tool that apk add's packages for foreign architectures into /var/lib/sysroots or something.https://gitlab.alpinelinux.org/alpine/aports/-/issues/13998Package request: bun2023-09-13T20:48:55ZHoang NguyenPackage request: bunIncredibly fast JavaScript runtime, bundler, transpiler and package manager – all in one.
Website: https://bun.sh/
Source: https://github.com/Jarred-Sumner/bun
License: MITIncredibly fast JavaScript runtime, bundler, transpiler and package manager – all in one.
Website: https://bun.sh/
Source: https://github.com/Jarred-Sumner/bun
License: MIThttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/31Tracking staticly linked dependencies with metadata2022-04-23T19:56:56ZAriadne Conillariadne@ariadne.spaceTracking staticly linked dependencies with metadataIn part due to the concerns of mitigating security vulnerabilities in staticly-linked dependencies, tsc#30 was opened. However, an examination of the issue shows that the underlying concern involves the distribution at large.
For examp...In part due to the concerns of mitigating security vulnerabilities in staticly-linked dependencies, tsc#30 was opened. However, an examination of the issue shows that the underlying concern involves the distribution at large.
For example, besides static linking against libraries Alpine provides, some packages vendor their own copies of packages, which need to be tracked and patched for CVEs. At present, Alpine lacks the ability to handle this patching lifecycle except to keep track of these situations by hand and hope that everything gets patched.
Accordingly, it is proposed to use the provider-metadata system to record which packages are either staticly linked against other packages in Alpine, or against vendored code.
We propose two namespaces:
* `bundled:$packagename` - this will be declared for packages which use static linking, allowing for tooling to do rebuilds as needed
* `vendored:$packagename` - this will be declared for packages which use vendored code, allowing for the security team to track CVEs in the vendored code inside those packages
Vendored code should still ideally be avoided in Alpine packages, of course, but is sometimes necessary due to downstream modification of the vendored code (for example in Chromium).
It is intended that this proposal supercede tsc#30.https://gitlab.alpinelinux.org/alpine/aports/-/issues/13048Migrate from wpa_supplicant to iwd2023-08-22T21:48:19ZDavid HeidelbergMigrate from wpa_supplicant to iwdTo improve user experience proposing defaulting to IWD daemon instead original `wpa_supplicant`. Generally since IWD matured since last few years, migration from `wpa_supplicant` should be fluent
Talk about IWD: https://www.youtube.com/...To improve user experience proposing defaulting to IWD daemon instead original `wpa_supplicant`. Generally since IWD matured since last few years, migration from `wpa_supplicant` should be fluent
Talk about IWD: https://www.youtube.com/watch?v=QIqT2obSPDk
Downstream pmOS ref: https://gitlab.com/postmarketOS/postmarketos/-/issues/45https://gitlab.alpinelinux.org/alpine/aports/-/issues/12157When installing new kernel, please don't delete old modules2023-05-19T12:49:24ZjujuWhen installing new kernel, please don't delete old modulesWhen apk update installs a new kernel, old modules in /lib/modules got deleted.
This may make the system unbootable if:
* You want to boot with the old kernel
* You are not booting from /boot, ie with rEFInd from another place
Pleas...When apk update installs a new kernel, old modules in /lib/modules got deleted.
This may make the system unbootable if:
* You want to boot with the old kernel
* You are not booting from /boot, ie with rEFInd from another place
Please keep the old files in /lib/modules and warn user to clean it up instead.https://gitlab.alpinelinux.org/alpine/abuild/-/issues/9997Follow XDG Base Directory specifications2023-10-24T01:52:52ZBart RibbersFollow XDG Base Directory specificationsCurrently abuild write it's config file and build keys to `~/.abuild`, and puts generated packages in `~/packages`. It would be nice if it would use [the XDG Base Directory specification](https://specifications.freedesktop.org/basedir-sp...Currently abuild write it's config file and build keys to `~/.abuild`, and puts generated packages in `~/packages`. It would be nice if it would use [the XDG Base Directory specification](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) instead so it doesn't clutter the `$HOME` directory.
The config file would go to `~/.config/abuild/abuild.conf` (if `$XDG_CONFIG_DIR` isn't set) and the keys and packages to `~/.local/share/abuild` (if `$XDG_DATA_DIRS` isn't set).https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10669[Feature request] apk add --retry flag.2022-12-21T20:03:12ZJohannes Tegnér[Feature request] apk add --retry flag.### Feature request:
I would love to see a flag added to the apk tool making it possible to "retry" failed package installs. Preferably with a `--retry <times>` option.
What it would do: just try the exact same thing again until `tim...### Feature request:
I would love to see a flag added to the apk tool making it possible to "retry" failed package installs. Preferably with a `--retry <times>` option.
What it would do: just try the exact same thing again until `times` are reached or it is installed.
### Why tho?:
From time to time when I install packages with apk, I get errors, the errors are usually solved by just running the same `get` command again. For example, today I have in my CI scripts been getting the following type of errors on a whole lot of images:
```
/ # apk add --no-cache curl
fetch https://ftp.acc.umu.se/mirror/alpinelinux.org/v3.11/main/x86_64/APKINDEX.tar.gz
fetch https://ftp.acc.umu.se/mirror/alpinelinux.org/v3.11/community/x86_64/APKINDEX.tar.gz
(1/4) Installing ca-certificates (20191127-r0)
(2/4) Installing nghttp2-libs (1.40.0-r0)
(3/4) Installing libcurl (7.67.0-r0)
56% ██████████████████████████████████████████████████████████████████████████████████████████████████ 140118755360072:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1913:
ERROR: libcurl-7.67.0-r0: Permission denied
(4/4) Installing curl (7.67.0-r0)
85% █████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████ 140118755360072:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1913:
ERROR: curl-7.67.0-r0: Permission denied
Executing busybox-1.31.1-r8.trigger
Executing ca-certificates-20191127-r0.trigger
2 errors; 6 MiB in 16 packages
```
I would guess that this have to do with some error on the UMU mirrors end (due to the permission error), but sometimes the next "retry" works fine, mostly though, the same error happens again on another package.
Running with `--retry` would ofcourse not remove the issue, while it would make it possible to successfully fetch the package at the end.
---
Another approach could be to allow for secondary repositories to use as fallback:
`/etc/apk/repositories`
```
# Primary repositories.
https://ftp.acc.umu.se/mirror/alpinelinux.org/v3.11/main
https://ftp.acc.umu.se/mirror/alpinelinux.org/v3.11/community
# Fallback repositories.
https://ftp.halifax.rwth-aachen.de/alpine/v3.11/main
https://ftp.halifax.rwth-aachen.de/alpine/v3.11/community
```
I read that this should work, but in my case, it does not seem to work...backloghttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/77Add Celeste as developer2024-02-04T22:10:34Zomniomni+alpine@hack.orgAdd Celeste as developerSee https://git.alpinelinux.org/aports/log/?qt=author&q=Celeste :upside_down:
In addition to a large volume of quality commits, @Celeste is also pragmatic, friendly and helpful within the project.See https://git.alpinelinux.org/aports/log/?qt=author&q=Celeste :upside_down:
In addition to a large volume of quality commits, @Celeste is also pragmatic, friendly and helpful within the project.https://gitlab.alpinelinux.org/alpine/tsc/-/issues/72New architecture LoongArch64 porting2024-03-02T01:51:59ZJingyun HuaNew architecture LoongArch64 portingHi all,
The purpose of creating this issue is to discuss with the community the addition of the new architecture LoongArch port to the aports project.
In March this year, we began to transplant the alpine Linux edge version (commit: 31...Hi all,
The purpose of creating this issue is to discuss with the community the addition of the new architecture LoongArch port to the aports project.
In March this year, we began to transplant the alpine Linux edge version (commit: 31aac06d3eaf0ff86c42eb5e4793fd9215fd3c79) on the LoongArch64 platform. The transplantation status at that time was: the bootstrap process was completed, minirootfs was built and produced, and the basic system construction of Alpine Linux was completed locally. Considering that the upstream of musl does not yet support the LoongAarch64 architecture, so we paused after building about 12000 apk packages.
Recently, the musl community mail has received new feedback on LoongArch64 architecture support. Judging from the feedback, the patch is basically qualified. Therefore, I recently built the alpine system based on the community's latest aports source code. The bootstrap phase is currently about to be completed. In this build, I'm using the latest patch for musl from loongarch64's upstream commit 0001-add-loongarch64-port-v7.patch (https://www.openwall.com/lists/musl/2023/04/18/1).
And I have one questions want to discuss:
Can we submit LoongArch64 support for aports before musl upstream doesn't support LoongArch64?
We very much hope to share our results with the community and look forward to contributing to the alpine community. After the above questions are solved, I think we can make an aports porting plan.Thanks!
A bit of introduction on the LoongArch:
1、Introduction
LoongArch is a new RISC ISA, which is a bit like MIPS or RISC-V. LoongArch includes a reduced 32-bit version (LA32R), a standard 32-bit version (LA32S) and a 64-bit version (LA64).
Loongson and LoongArch documentations:
https://github.com/loongson/LoongArch-Documentation
2、Upstream software supports LoongArch
Kernel、Gcc、Glibc、Binutils、Gdb、Llvm、Rust、Golang have merged by upstream(github) projects and so on.
For examples,
Kernel: https://www.kernel.org/doc/html/latest/
Gcc: https://gcc.gnu.org/gcc-12/changes.html
Glibc: https://sourceware.org/pipermail/libc-alpha/2022-August/141193.html
Gdb: https://sourceware.org/gdb/
Binutils: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/heads/binutils-2_39-branch
Llvm: https://github.com/llvm/llvm-project/tree/main/llvm/lib/Target
Rust: https://github.com/rust-lang/rust
Golang: https://go.dev/doc/go1.19
3、operating systems supports LoongArch
debian: https://wiki.debian.org/Ports/loong64
gentoo: https://wiki.gentoo.org/wiki/Project:LoongArch
archlinux: https://loongarchlinux.org/
fedora:https://github.com/fedora-remix-loongarchhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/14769Chromium on Docker Alpine Image (3.17.2) not Running2023-06-11T14:23:21ZFelix AmmannChromium on Docker Alpine Image (3.17.2) not RunningWe run a Docker Container with a Alpine Image (3.17.2) and chromium installed with it.
Since the new Build 2 days ago (110.0.5481.177 to 111.0.5563.146) we are not able to run the chromium-browser on host devices with x86_64 Architecture...We run a Docker Container with a Alpine Image (3.17.2) and chromium installed with it.
Since the new Build 2 days ago (110.0.5481.177 to 111.0.5563.146) we are not able to run the chromium-browser on host devices with x86_64 Architecture.
We got this Segfault Error:
```
[5877008.674069] chrome[3054575]: segfault at 0 ip 00007f1a4970df21 sp 00007ffedf7408e0 error 4 in libstdc++.so.6.0.30[7f1a496ff000+119000]
[5877008.674255] Code: f8 48 c7 04 24 00 00 00 00 48 b8 00 00 00 00 10 00 00 00 48 89 44 24 10 49 8b 00 48 c7 44 24 08 00 00 00 00 48 39 78 f8 75 5d <48> 8b 07 48 89 d5 49 89 cd 48 89 e2 52 49 89 f1 48 89 e9 ba 06 00
[5877008.691461] chrome[3054586]: segfault at 0 ip 00007f1a4970df21 sp 00007ffedf7408e0 error 4 in libstdc++.so.6.0.30[7f1a496ff000+119000]
[5877008.691646] Code: f8 48 c7 04 24 00 00 00 00 48 b8 00 00 00 00 10 00 00 00 48 89 44 24 10 49 8b 00 48 c7 44 24 08 00 00 00 00 48 39 78 f8 75 5d <48> 8b 07 48 89 d5 49 89 cd 48 89 e2 52 49 89 f1 48 89 e9 ba 06 00
[5877008.707572] chrome[3054595]: segfault at 0 ip 00007f1a4970df21 sp 00007ffedf7408e0 error 4 in libstdc++.so.6.0.30[7f1a496ff000+119000]
[5877008.707758] Code: f8 48 c7 04 24 00 00 00 00 48 b8 00 00 00 00 10 00 00 00 48 89 44 24 10 49 8b 00 48 c7 44 24 08 00 00 00 00 48 39 78 f8 75 5d <48> 8b 07 48 89 d5 49 89 cd 48 89 e2 52 49 89 f1 48 89 e9 ba 06 00
[5877012.042516] chrome[3054717]: segfault at 0 ip 00007fd1732b8f21 sp 00007ffc0a9151f0 error 4 in libstdc++.so.6.0.30[7fd1732aa000+119000]
[5877012.042708] Code: f8 48 c7 04 24 00 00 00 00 48 b8 00 00 00 00 10 00 00 00 48 89 44 24 10 49 8b 00 48 c7 44 24 08 00 00 00 00 48 39 78 f8 75 5d <48> 8b 07 48 89 d5 49 89 cd 48 89 e2 52 49 89 f1 48 89 e9 ba 06 00
[5877012.062233] chrome[3054728]: segfault at 0 ip 00007fd1732b8f21 sp 00007ffc0a9151f0 error 4 in libstdc++.so.6.0.30[7fd1732aa000+119000]
[5877012.062424] Code: f8 48 c7 04 24 00 00 00 00 48 b8 00 00 00 00 10 00 00 00 48 89 44 24 10 49 8b 00 48 c7 44 24 08 00 00 00 00 48 39 78 f8 75 5d <48> 8b 07 48 89 d5 49 89 cd 48 89 e2 52 49 89 f1 48 89 e9 ba 06 00
[5877012.078907] chrome[3054736]: segfault at 0 ip 00007fd1732b8f21 sp 00007ffc0a9151f0 error 4 in libstdc++.so.6.0.30[7fd1732aa000+119000]
[5877012.079090] Code: f8 48 c7 04 24 00 00 00 00 48 b8 00 00 00 00 10 00 00 00 48 89 44 24 10 49 8b 00 48 c7 44 24 08 00 00 00 00 48 39 78 f8 75 5d <48> 8b 07 48 89 d5 49 89 cd 48 89 e2 52 49 89 f1 48 89 e9 ba 06 00
```
We tried to install the old 110.0.5481.177 Build but we were not able to find it.
Are you aware of this Problem or do you have an idea how we can fix this?
Let me know if you need more informationhttps://gitlab.alpinelinux.org/alpine/abuild/-/issues/10090Move config directory to $XDG_CONFIG_HOME2023-01-12T11:08:15ZNatanael CopaMove config directory to $XDG_CONFIG_HOMEWe should move the `~/.abuild` to `~/.config/abuild`. (using `$XDG_CONFIG_HOME`)
We should also have a fallback to `~/.abuild` with a deprecation warning, but we should not auto-migrate it for the user.
If both exists, the deprecated `...We should move the `~/.abuild` to `~/.config/abuild`. (using `$XDG_CONFIG_HOME`)
We should also have a fallback to `~/.abuild` with a deprecation warning, but we should not auto-migrate it for the user.
If both exists, the deprecated `~/.abuild` should be ignored, with a warning.https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10062Add default_s6 subpackage split function2023-02-11T05:38:12ZPatrycja Rosaalpine@ptrcnull.meAdd default_s6 subpackage split functionThis would allow for package maintainers to include s6 service files, either for users that would want to use s6 alongside openrc, or with regard to future migration of the whole ecosystemThis would allow for package maintainers to include s6 service files, either for users that would want to use s6 alongside openrc, or with regard to future migration of the whole ecosystemhttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/34[3.16] implement alpine official container registry via gitlab2022-02-27T08:33:35ZAriadne Conillariadne@ariadne.space[3.16] implement alpine official container registry via gitlabPresently, the Alpine official container image is distributed by Docker, but there have been some historical problems with this:
- getting new images updated on Docker's container registry has some variable amount of lag
- [the containe...Presently, the Alpine official container image is distributed by Docker, but there have been some historical problems with this:
- getting new images updated on Docker's container registry has some variable amount of lag
- [the container image has not been signed in 2 years](https://github.com/docker-library/official-images/issues/6838), this seems to be related to the Mirantis split, presumably whoever was signing the official images in Docker's registry left with the Mirantis side of the split.
The container image signing problem is concerning to me, in my opinion, it means that building a container from `scratch`, and downloading our minirootfs directly and verifying *that* with GPG is a better practice, than actually using the official image. Accordingly, this is not up to the standard that we want in the Alpine community for the container base image, as it is not signed.
Given these points, and the fact that we have deployed GitLab which supports running a container registry, I think it makes sense to publish our own. We can then sign the images with `cosign`, which is the standard way of doing it for kubernetes images. (Docker itself does not have any signing integration except for their notary service, which as noted above, has not been signing anything for the past 2 years.)
As such I propose that from 3.16 onwards, we publish our own container images and self-host them. We should keep the Docker container registry distribution channel for now, but work to deprecate it as an official source of truth for Alpine images, this could be done in 3.17 or 3.18.https://gitlab.alpinelinux.org/alpine/aports/-/issues/13113dependabot for aports?2021-11-01T00:58:54ZMengyang Lidependabot for aports?Are you too lazy to perform travail package update manually? I'd like to introduce something like dependabot, but for alpine packages.
Where it can perform basic upgrades automatically by
- Parsing current version from APKBUILD
- Pars...Are you too lazy to perform travail package update manually? I'd like to introduce something like dependabot, but for alpine packages.
Where it can perform basic upgrades automatically by
- Parsing current version from APKBUILD
- Parsing the latest version from upstream or https://pkgs.alpinelinux.org/flagged
- Perform some test build
- Post a Merge Request
This could reduce tons of repetitive works, and maintain a relative recent copy of edge.