alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2023-12-11T15:47:24Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/14468Provide versionless package for all php module packages2023-12-11T15:47:24ZHoël BézierProvide versionless package for all php module packagesMost php modules are provided both as `php81-module-name` and as `php-module-name`. Some of them do not have a versionless package though, the full list is below:
- [x] php81-brotli-0.11.1-r0
- [x] php81-pecl-amqp-1.11.0-r0
- [x] php81-...Most php modules are provided both as `php81-module-name` and as `php-module-name`. Some of them do not have a versionless package though, the full list is below:
- [x] php81-brotli-0.11.1-r0
- [x] php81-pecl-amqp-1.11.0-r0
- [x] php81-pecl-apcu-5.1.22-r0
- [ ] php81-pecl-ast-1.1.0-r0
- [ ] php81-pecl-couchbase-4.0.0-r1
- [ ] php81-pecl-event-3.0.8-r1
- [x] php81-pecl-igbinary-3.2.12-r0
- [x] php81-pecl-imagick-3.7.0-r0
- [x] php81-pecl-imagick-dev-3.7.0-r0
- [ ] php81-pecl-lzf-1.7.0-r0
- [ ] php81-pecl-mailparse-3.1.4-r0
- [ ] php81-pecl-maxminddb-1.11.0-r0
- [x] php81-pecl-msgpack-2.2.0_rc2-r0
- [x] php81-pecl-memcache-8.0-r0
- [x] php81-pecl-memcached-3.2.0-r0
- [ ] php81-pecl-mongodb-1.15.0-r0
- [ ] php81-pecl-protobuf-3.21.7-r0
- [ ] php81-pecl-psr-1.2.0-r0
- [x] php81-pecl-rdkafka-6.0.3-r0
- [x] php81-pecl-redis-5.3.7-r0
- [x] php81-pecl-ssh2-1.3.1-r0
- [ ] php81-pecl-swoole-5.0.1-r0
- [ ] php81-pecl-swoole-dev-5.0.1-r0
- [x] php81-pecl-uploadprogress-2.0.2-r0
- [x] php81-pecl-uploadprogress-doc-2.0.2-r0
- [ ] php81-pecl-uuid-1.2.0-r0
- [ ] php81-pecl-vips-1.0.13-r0
- [x] php81-pecl-xdebug-3.2.0-r0
- [x] php81-pecl-xhprof-2.3.9-r0
- [x] php81-pecl-xhprof-assets-2.3.9-r0
- [x] php81-pecl-yaml-2.2.2-r0
- [ ] php81-pecl-zstd-0.12.0-r0
Feel free to edit that as you add the corresponding provides.3.19.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/13155main/krb5: test failures after openldap 2.62023-11-01T22:53:03ZAndy Postnikovmain/krb5: test failures after openldap 2.6Test fails on builders after !24084
disabled via 1ac4b4fd65a9 ff01e75be4fb
```
PYTHONPATH=../util VALGRIND="" python3 ./t_general.py
*** Failure: /home/buildozer/aports/main/krb5/src/krb5-1.19.2/src/clients/kinit/kinit failed with cod...Test fails on builders after !24084
disabled via 1ac4b4fd65a9 ff01e75be4fb
```
PYTHONPATH=../util VALGRIND="" python3 ./t_general.py
*** Failure: /home/buildozer/aports/main/krb5/src/krb5-1.19.2/src/clients/kinit/kinit failed with code 1.
*** Last command (#5): /home/buildozer/aports/main/krb5/src/krb5-1.19.2/src/clients/kinit/kinit user@KRBTEST.COM
*** Output of last command:
Password for user@KRBTEST.COM:
kinit: Password incorrect while getting initial credentials
*** Failed in test pass: default
For details, see: /home/buildozer/aports/main/krb5/src/krb5-1.19.2/src/tests/testlog
Or re-run this test script with the -v flag:
cd /home/buildozer/aports/main/krb5/src/krb5-1.19.2/src/tests
PYTHONPATH=/home/buildozer/aports/main/krb5/src/krb5-1.19.2/src/util /usr/bin/python3 ./t_general.py -v
Use --debug=NUM to run a command under a debugger. Use
--stop-after=NUM to stop after a daemon is started in order to
attach to it with a debugger. Use --help to see other
options.
make[1]: *** [Makefile:766: check-pytests] Error 1
make[1]: *** Waiting for unfinished jobs....
```3.19.0Andy PostnikovAndy Postnikovhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11701Ensure valid AppStream metadata2023-05-09T14:22:44ZRasmus Thomsenoss@cogitri.devEnsure valid AppStream metadataCurrently we're having many faulty (e.g. missing description, missing icons etc.) AppStream files in our packages. This isn't necessarily because of packaging error but because upstream didn't follow the AppStream policies while writing ...Currently we're having many faulty (e.g. missing description, missing icons etc.) AppStream files in our packages. This isn't necessarily because of packaging error but because upstream didn't follow the AppStream policies while writing the file for their project. As such we should probably poke upstreams about these issues when we discover them.
See https://appstream.alpinelinux.org/20200628/html/edge/community/issues/index.html for a list of issues. Note that the data is regenerated daily, so you might have to change the date. Also see the main and testing repos.3.19.0Rasmus Thomsenoss@cogitri.devRasmus Thomsenoss@cogitri.devhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10385kernel option apkovl is not working2023-05-09T14:24:06Zalgitbotkernel option apkovl is not workingCheck **initramfs-init.in** file:
- **unpack\_apkovl** is called before setting **$repofile**
That’s why booting is crashes with filed to install openssl package
*(from redmine: issue id 10385, created on 2019-05-01)*Check **initramfs-init.in** file:
- **unpack\_apkovl** is called before setting **$repofile**
That’s why booting is crashes with filed to install openssl package
*(from redmine: issue id 10385, created on 2019-05-01)*3.19.0Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/625have autobuilders use chrooted builds2023-05-09T14:24:15ZNatanael Copahave autobuilders use chrooted buildsThe autobuilders should build packages in chroots. We could fix buildlab
for this.
*(from redmine: issue id 625, created on 2011-05-05)*
* Relations:
* blocks #801The autobuilders should build packages in chroots. We could fix buildlab
for this.
*(from redmine: issue id 625, created on 2011-05-05)*
* Relations:
* blocks #8013.19.0Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10972package version formatting2024-03-27T16:28:48ZSertonixpackage version formattingThe issue has mutated to a discussion about the version formatting in general.
Related !144, #7100, #10816
## Old description
The version format for virtual packages (`YYYYmmdd.HHMMSS`) doesn't include a `pkgrel` like packages normall...The issue has mutated to a discussion about the version formatting in general.
Related !144, #7100, #10816
## Old description
The version format for virtual packages (`YYYYmmdd.HHMMSS`) doesn't include a `pkgrel` like packages normally have (`<pkgver>-r<pkgrel>`).
This creates ambiguity in the output of the `apk list` command. Normally it is enough the strip the last 2 dashes but that doesn't work with the version format of virtual packages:
- `<pkgname>-<pkgver>-r<pkgrel>`
- `<pkgname>-YYYYmmdd.HHMMSS`
I suggest adding `-r0` to the version of virtual packages [`app_add.c#L118`](https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/acefa1acc1ce0e1871d17b4eafe4b1888f45d4d0/src/app_add.c#L118). !132 does fix the `apk list` problem too but a consistent version format would still be better.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10964Provide development documentation2024-03-11T08:31:37ZSander MaijersProvide development documentation[`docs/`](docs/) contains user manuals, but short of that, development documentation seems absent.
@ariadne wrote interesting analyses such as https://ariadne.space/2021/10/31/spelunking-through-the-apk-tools-dependency-solver/, which I ...[`docs/`](docs/) contains user manuals, but short of that, development documentation seems absent.
@ariadne wrote interesting analyses such as https://ariadne.space/2021/10/31/spelunking-through-the-apk-tools-dependency-solver/, which I think deserve a more central place.
In addition, personally, I'd like to learn about `apk-tools`'s design principles and architectural requirements. For example, is `/var/cache/apk/` supposed to be data race safe in the face of parallel `apk` processes?backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10892Fuzz apk-tools2024-02-23T12:54:00ZjvoisinFuzz apk-toolsIt would be nice to have some [fuzzing]( https://en.wikipedia.org/wiki/Fuzzing ) for apk-tools, since it's doing some cryptographic operations, has a lot of privileges, parses things coming from the internet, …
I would have done it myse...It would be nice to have some [fuzzing]( https://en.wikipedia.org/wiki/Fuzzing ) for apk-tools, since it's doing some cryptographic operations, has a lot of privileges, parses things coming from the internet, …
I would have done it myself, but since apk is using a database, it's non-trivial to write proper fuzzers :/backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10891Add an option to download the packages before upgrading/installing packages2023-09-18T13:45:05ZBart RibbersAdd an option to download the packages before upgrading/installing packagesWhen running `apk upgrade` or `apk add` the packages are downloaded and installed 1-by-1. This means that if your internet connection for some reason drops out in the middle of it, you now have a partially upgraded system. It would be gr...When running `apk upgrade` or `apk add` the packages are downloaded and installed 1-by-1. This means that if your internet connection for some reason drops out in the middle of it, you now have a partially upgraded system. It would be great to have a command line switch or environment variable to tell apk to first download all packages it's modifying before installing them, so network failures halfway through don't leave you with a partially updated system.backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10887feature to keep old/previous package when upgrading kernel2024-02-23T12:28:43ZNatanael Copafeature to keep old/previous package when upgrading kernelTwo problems:
- when kernel package is upgraded, modprobe will stop working til machine is rebooted, because old kernel modules were deleted.
- it would be nice to keep old kernel around for a while, in case new kernel is broken. For ex...Two problems:
- when kernel package is upgraded, modprobe will stop working til machine is rebooted, because old kernel modules were deleted.
- it would be nice to keep old kernel around for a while, in case new kernel is broken. For example as `/boot/vmlinuz-lts.old`
Possible solution:
We could have a virtual `.old` or `.previous` package. When flagged packages (`linux-lts`would have a flag of some sort) apk would on upgrade transfer ownership of the old package to this virtual package. Files that would be deleted are kept, and files that would be replaced could get a `.old` suffix.
The result would be that `/lib/modules/<old-version>` are transferred to virtual `linux-lts.old`, and `/boot/vmlinuz-lts` are kept as `/boot/vmlinuz-lts.old`. User can then chose to keep this til next time linux-lts is upgraded or for example clean up .old as last step during bootup. (for example `apk del '*.old'` or similar)
This way `modprobe` will continue work after an `apk upgrade` and user can have a vmlinuz-lts.old fallback in boot loader in case new kernel is broken.
Any package could be flagged with 'keep-old' but I think it mostly makes sense for linux kernels.backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10874conversion of installeddb and query applets to new database format2023-01-31T11:16:53ZTimo Teräsconversion of installeddb and query applets to new database formatConvert all internal code to use the new ADB based structures.
Support old indexes by doing on-the-fly conversion.
Automatically convert and keep installeddb in the new format.Convert all internal code to use the new ADB based structures.
Support old indexes by doing on-the-fly conversion.
Automatically convert and keep installeddb in the new format.v3.1Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10873tooling for repository mirroring2023-04-11T17:55:40ZTimo Terästooling for repository mirroringImprove existing applets (e.g. `fetch`) or create new one(s) to allow for:
- downloading repository index and all packages in it
- support incremental download with modified-since timestamp (or possibly compared to an old index)
- rec...Improve existing applets (e.g. `fetch`) or create new one(s) to allow for:
- downloading repository index and all packages in it
- support incremental download with modified-since timestamp (or possibly compared to an old index)
- recreate repository index given index and list of directories where to look files from; create symlinks or hardlinks
- print list of package names present on indexv3.0Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10868add vendor field to apkv2/apkv3 control data and apkdb2024-03-08T14:45:39ZAriadne Conillariadne@ariadne.spaceadd vendor field to apkv2/apkv3 control data and apkdbSoftware component analysis tools (and related software such as vulnerability scanning tools) use CPE identifiers and Package URLs (PURLs) to determine the ecosystem a software component originates from.
At present, the apkdb does not c...Software component analysis tools (and related software such as vulnerability scanning tools) use CPE identifiers and Package URLs (PURLs) to determine the ecosystem a software component originates from.
At present, the apkdb does not contain this information, so SCA tools assume that all packages originate from the distribution. This causes problems when trying to understand the relationship between software components and their suppliers, to do things like find out about remediated CVEs, as the calculated CPE identifiers and PURLs are matched to the wrong supplier.
Since Alpine 3.16, we have shipped `/etc/secfixes.d/$vendorlabel`, e.g. `/etc/secfixes.d/alpine`, files in the baselayout. Some other apk distributions which use the same secdb format have done the same such as $dayjob's Wolfi GNU/Linux distribution. By providing a vendor tag in the APK control data and apkdb which matches to these `/etc/secfixes.d` files, we can correctly map relevant security remediation feeds to the packages.
I'm happy to work on this if @fabled agrees we should do this.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10867Documentation on cmd:PATTERN, so:PATTERN etc. missing from apk-search.82022-12-26T13:28:50ZPaul W. Rankinhello@paulwrankin.comDocumentation on cmd:PATTERN, so:PATTERN etc. missing from apk-search.8I'm not sure where I learnt that `apk-search(8)` could accept `cmd:PATTERN` but it seems it was not the man page.
Upon trying to learn which prefixes are available the documentation is missing.I'm not sure where I learnt that `apk-search(8)` could accept `cmd:PATTERN` but it seems it was not the man page.
Upon trying to learn which prefixes are available the documentation is missing.backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10865Add info on where each package in apk upgrade is coming from2022-12-21T18:56:12ZJustinAdd info on where each package in apk upgrade is coming fromIf the user has multiple repositories installed, show where each package is coming from.
For instance I have a script that does this with apt data and spits out this:
```
+------------------+-----------------+-------------------+------...If the user has multiple repositories installed, show where each package is coming from.
For instance I have a script that does this with apt data and spits out this:
```
+------------------+-----------------+-------------------+-------------------+
| Package Name | Repository | Current Version | New Version |
+------------------+-----------------+-------------------+-------------------+
| kpartx | focal-security | 0.8.3-1ubuntu2 | 0.8.3-1ubuntu2.1 |
| libexpat1 | focal-security | 2.2.9-1ubuntu0.4 | 2.2.9-1ubuntu0.5 |
| multipath-tools | focal-security | 0.8.3-1ubuntu2 | 0.8.3-1ubuntu2.1 |
+------------------+-----------------+-------------------+-------------------+
```v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10862Fetch fails to detect broken IPv62022-12-21T19:39:44ZReuben LifshayFetch fails to detect broken IPv6If apk is running in a dual stack environment where AAAA records are returned but IPv6 packets do not go through fetch will try to connect only to the v6 addresses and will take a very long time to fail and fall back to v4. In my case, t...If apk is running in a dual stack environment where AAAA records are returned but IPv6 packets do not go through fetch will try to connect only to the v6 addresses and will take a very long time to fail and fall back to v4. In my case, this is with building docker images.
Other utilities such as `curl` work correctly in the same situation because they use the Happy Eyeballs algorithm ([RFC 8305](https://www.rfc-editor.org/rfc/rfc8305)).
apk:
```
~ # apk update
fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/main/x86_64/APKINDEX.tar.gz
...(hangs until timeout)
```
curl:
```
~ # curl -vI https://dl-cdn.alpinelinux.org/alpine/v3.16/main/x86_64/APKINDEX.tar.gz
* Trying 2a04:4e42:600::645:443...
* Trying 151.101.194.133:443...
* Connected to dl-cdn.alpinelinux.org (151.101.194.133) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
...CLIPPED
```
curl IPv6 only:
```
~ # curl -6 -vI https://dl-cdn.alpinelinux.org/alpine/v3.16/main/x86_64/APKINDEX.tar.gz
* Trying 2a04:4e42::645:443...
...(hangs until timeout)
```backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10861implement support for OCI registries2022-12-21T18:56:11ZAriadne Conillariadne@ariadne.spaceimplement support for OCI registriesWith projects such as ORAS (OCI Registry as Storage), it may be interesting to support fetching apk packages as if they were objects stored in OCI registries. This would allow users to distribute apk packages at zero cost by using pre-e...With projects such as ORAS (OCI Registry as Storage), it may be interesting to support fetching apk packages as if they were objects stored in OCI registries. This would allow users to distribute apk packages at zero cost by using pre-existing OCI registries such as DockerHub, GHCR, etc.
Other package managers, such as Homebrew, have implemented support for this distribution method. I believe OpenWrt developers have expressed interest in this as well.
(This would be for something after apk 3.0 release.)v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10858`apk add ...` should attempt to redownload an apk package with a bad signatur...2022-12-21T18:56:11ZEllie`apk add ...` should attempt to redownload an apk package with a bad signature at least once during the command run`apk add ...` should attempt to redownload an apk package with a bad signature at least once during the command run. Instead it just gets stuck dumbfounded and always gives the same failed output even if the command is rerun:
```
$ sudo...`apk add ...` should attempt to redownload an apk package with a bad signature at least once during the command run. Instead it just gets stuck dumbfounded and always gives the same failed output even if the command is rerun:
```
$ sudo apk add py3-pip
(1/12) Installing py3-contextlib2 (21.6.0-r2)
(2/12) Installing py3-tomli (2.0.1-r1)
(3/12) Installing py3-pep517 (0.12.0-r2)
(4/12) Installing py3-six (1.16.0-r1)
(5/12) Installing py3-retrying (1.3.3-r3)
2% ██
(6/12) Installing py3-appdirs (1.4.4-r3)
2% ██
3% ██
(7/12) Installing py3-more-itertools (8.13.0-r0)
3% ██
4% ███
5% ███
(8/12) Installing py3-ordered-set (4.0.2-r3)
5% ████
(9/12) Installing py3-parsing (2.4.7-r3)
5% ████
ERROR: py3-parsing-2.4.7-r3: IO ERROR
(10/12) Installing py3-packaging (21.3-r0)
8% ██████
ERROR: py3-packaging-21.3-r0: BAD signature
(11/12) Installing py3-setuptools (59.4.0-r0)
10% ███████
ERROR: py3-setuptools-59.4.0-r0: BAD signature
(12/12) Installing py3-pip (22.1.1-r0)
23% █████████████████
ERROR: py3-pip-22.1.1-r0: BAD signature
100% █████████████████████████████████████4 errors; 2154 MiB in 814 packages
$
```
For such an obvious culprit, I would expect it to do *something* when it runs into broken packages like that. at the very least when I try running the command again.
I saw this with apk 2.12.9 on postmarketOS 22.06.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10856apk3: failure upgrading packages if newer version replaces file with directory2022-12-21T18:56:12ZDaniel Kolesaapk3: failure upgrading packages if newer version replaces file with directoryOne will get a `not a directory` error when trying to upgrade a package and the newer version has a directory where the previous version had a file.One will get a `not a directory` error when trying to upgrade a package and the newer version has a directory where the previous version had a file.v3.1https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10523lbu support commit if any changes2022-07-13T15:42:36Z杨文 陈lbu support commit if any changes
Current workaround
```bash
[ $(lbu st | wc -c) = "0" ] && echo No changes || lbu ci
```
Better for lbu commit support changes only
Current workaround
```bash
[ $(lbu st | wc -c) = "0" ] && echo No changes || lbu ci
```
Better for lbu commit support changes only3.15