alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2022-03-19T09:27:53Zhttps://gitlab.alpinelinux.org/alpine/go/-/issues/1Work with both APKv2 and APKv3 formats2022-03-19T09:27:53ZAriadne Conillariadne@ariadne.spaceWork with both APKv2 and APKv3 formatsAPKv3 objects have radically different format. It would be nice to be able to handle and mutate both formats, as the APKv2 format is going to be deprecated with apk-tools 3.0 release.
How do you think we should implement this, @kdaudt?APKv3 objects have radically different format. It would be nice to be able to handle and mutate both formats, as the APKv2 format is going to be deprecated with apk-tools 3.0 release.
How do you think we should implement this, @kdaudt?Kevin DaudtKevin Daudthttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10819manage user and group creation/deletion directly2023-12-19T12:23:07ZAriadne Conillariadne@ariadne.spacemanage user and group creation/deletion directlyPresently, the majority of pre-install/post-install scripts in Alpine are doing user/group management. If apk did this instead, we could drop these scripts in the future.Presently, the majority of pre-install/post-install scripts in Alpine are doing user/group management. If apk did this instead, we could drop these scripts in the future.v3.1https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10060Subpackage versioning2022-08-14T17:58:30ZAntoine MartinSubpackage versioningThe following discussion from aports!28195 should be addressed:
- [ ] @jirutka started a [discussion](https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28195#note_205465): (+14 comments)
> `pkgver` should not be redefi...The following discussion from aports!28195 should be addressed:
- [ ] @jirutka started a [discussion](https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28195#note_205465): (+14 comments)
> `pkgver` should not be redefined for subpackages. I tried that a few years ago in some aports and it didn’t work well with the build servers (I don’t remember details). However, maybe this is a good time to open a discussion about this, because this is a quite unfortunate limitation and I’d like to overcome it.
>
> /cc @ncopa, @ariadne, @kdaudt
dotnet packages require custom pkgver within subpackages, as SDK and Runtime have different versioning schemes. This is not currently supported by buildrepo or abuild as they source only global pkgver to check if there should be a rebuild of packages, or whether old packages should be purged. I implemented a mitigation from within my aports that create a symbolic link between where the APK is expected to be by abuild and buildrepo, and where it actually is. This works for most use-cases that I could test for, except for buildrepo's purging functionality. As buildrepo purges every APK that doesn't match `(name or pkg.pkgname).."-"..pkg.pkgver.."-r"..pkg.pkgrel..".apk"`, this means it deletes any subpackage with custom pkgver.
The mitigation is as follows:
```bash
scan_symlink_targets() {
local name="$1" dir="$2"
local ver=$(pkginfo_val pkgver "$dir"/.PKGINFO)
local subpkgarch=$(pkginfo_val arch "$dir"/.PKGINFO)
[ -d "$REPODEST"/${repo:?}/${subpkgarch/noarch/$CARCH} ] || mkdir -p "$REPODEST"/$repo/${subpkgarch/noarch/$CARCH}
[ "$ver" = "$pkgver-r$pkgrel" ] || ln -sf "$REPODEST"/$repo/${subpkgarch/noarch/$CARCH}/$name-$ver.apk "$REPODEST"/$repo/${subpkgarch/noarch/$CARCH}/$name-$pkgver-r$pkgrel.apk
}
```
# Problematic functions
Through my attempts at figuring out a mitigation, I identified the following problematic functions
## abuild
* `scan_symlink_targets`: when it detects symlink dependencies between subpkgs sets a hard dependency to that specific version of subpackage. Above mitigation neutralizes scan_symlink_targets, leaving the maintainer to set those dependencies explicitely
* `apk_up2date` / `abuildindex_up2date`:root cause of subpkg issues in abuild. Both functions define expected path as `"$dir"/$subpkgname-$pkgver-r$pkgrel.apk`. Since these are defined from within a for loop for each package, `$pkgver` should rather be `$subpkgver`, but no logics are in place to do so.
* `subpkg_set`: defines above `$pkgver` variable. Logics for `$subpkgver` would be implemented here.
## lua-aports
* `db:each_need_build` / purge logics (`buildrepo`): former relies on `pkg.apk_file_exists` which checks if there's a readable file at output of `get_apk_file_path`, which relies on `get_apk_file_name`. Latter also relies on `get_apk_file_name`
* `get_apk_file_name` (`buildrepo/pkg.lua`): root function of the above functions, defines `apk_file_name` as `(name or pkg.pkgname).."-"..pkg.pkgver.."-r"..pkg.pkgrel..".apk"`. `pkg.pkgver` is presumable sourced from aport's global pkgver rather than APKINDEX. If `get_apk_file_name` sourced pkg.pkgver from subpkgver, this would likely fix the issues with buildrepo. This function is thus a root-case for issues relating to subpkg versioning.
# Implementation proposal
## aports
Similar to :arch implementation within subpackages array, this would probably be a similar strategy to define pkgver for subpackages. Thus possible variables within subpackages would be `subpkgname:subpkgsplit:subpkgver:subpkgarch` rather than `subpkgname:subpkgsplit:subpkgarch`
It would then be a matter of changing the above abuild functions, implementing most of the logics in `subpkg_set`.
## Buildrepo
I know little of lua, so while I might make an attempt at an implementation, I can't even tell how `pkg.pkgver` is sourced. The only thing I can tell is that `get_apk_file_name` *seems* to be where I need to implement the logics, but then again `db:each_name` seems to also be a candidate. This is likely something that someone more lua-savy should address.https://gitlab.alpinelinux.org/alpine/aports/-/issues/13501udisksctl unable to mount /dev/mapper volumes2023-08-23T11:15:42ZDaniel Grayudisksctl unable to mount /dev/mapper volumesAn encrypted volume, whether it be a partition, or loop device cannot be mounted with `udisksctl mount -b /dev/mapper/luks-*`. I suspect this is due to missing policy kit rules. If the device is not encrypted you can mount that ie `udis...An encrypted volume, whether it be a partition, or loop device cannot be mounted with `udisksctl mount -b /dev/mapper/luks-*`. I suspect this is due to missing policy kit rules. If the device is not encrypted you can mount that ie `udisksctl mount -b /dev/disk`. Using less secure means `cryptsetup luksOpen` and `mount` methods work.
I have `/usr/lib/polkit-1/polkitd --no-debug` running and `/usr/bin/lxqt-policykit-agent` and have launched my sway session with `dbus-run-session sway`. I am using `elogind` and `eudev`.
Unlocking works, ie `udisksctl unlock -b /dev/device` encrypted container, ie:
```
# dd if=/dev/random of=test count=100000 bs=1000
# cryptsetup luksFormat test,
# cryptsetup luksOpen test test
# mkfs.ext4 /dev/mapper/test
# cryptsetup luksClose /dev/mapper/test
$ udisksctl loop-setup test
$ udisksctl unlock /dev/loop0
```
What doesn't work is:
1. `udisksctl mount -b /dev/mapper/luks-*`
When you click on an encrypted disk in Nautilus or Thunar this is the part that doesn't work either. It will ask you for the password, and as soon as provided the device will disappear from the side panel. Having a look at `udiskctl monitor` I noticed this after unlocking:
```
23:45:00.698: /org/freedesktop/UDisks2/block_devices/sdb1: org.freedesktop.UDisks2.Encrypted: Properties Changed
HintEncryptionType: LUKS
23:45:00.699: Added /org/freedesktop/UDisks2/jobs/8
org.freedesktop.UDisks2.Job:
Bytes: 0
Cancelable: true
ExpectedEndTime: 0
Objects: /org/freedesktop/UDisks2/block_devices/sdb1
Operation: encrypted-unlock
Progress: 0.0
ProgressValid: false
Rate: 0
StartTime: 1643894100696853
StartedByUID: 1000
23:45:02.776: /org/freedesktop/UDisks2/jobs/8: org.freedesktop.UDisks2.Job::Completed (true, '')
23:45:02.776: Removed /org/freedesktop/UDisks2/jobs/8
23:45:02.778: Added /org/freedesktop/UDisks2/block_devices/dm_2d0
org.freedesktop.UDisks2.Block:
Configuration: []
CryptoBackingDevice: '/org/freedesktop/UDisks2/block_devices/sdb1'
Device: /dev/dm-0
DeviceNumber: 64768
Drive: '/'
HintAuto: false
HintIconName:
HintIgnore: false
HintName:
HintPartitionable: false
HintSymbolicIconName:
HintSystem: true
Id:
IdLabel:
IdType:
IdUUID:
IdUsage:
IdVersion:
MDRaid: '/'
MDRaidMember: '/'
PreferredDevice: /dev/dm-0
ReadOnly: false
Size: 7740588032
Symlinks:
UserspaceMountOptions:
23:45:02.778: /org/freedesktop/UDisks2/block_devices/sdb1: org.freedesktop.UDisks2.Encrypted: Properties Changed
CleartextDevice: '/org/freedesktop/UDisks2/block_devices/dm_2d0'
```
Whereas when I try this on Fedora, Debian etc I see:
```
22:50:53.494: Added /org/freedesktop/UDisks2/jobs/12
org.freedesktop.UDisks2.Job:
Bytes: 0
Cancelable: true
ExpectedEndTime: 0
Objects: /org/freedesktop/UDisks2/block_devices/sde1
Operation: encrypted-unlock
Progress: 0.0
ProgressValid: false
Rate: 0
StartTime: 1643890853492936
StartedByUID: 1000
22:50:54.808: /org/freedesktop/UDisks2/jobs/12: org.freedesktop.UDisks2.Job::Completed (true, '')
22:50:54.808: Removed /org/freedesktop/UDisks2/jobs/12
22:50:54.822: Added /org/freedesktop/UDisks2/block_devices/dm_2d1
org.freedesktop.UDisks2.Block:
Configuration: []
CryptoBackingDevice: '/org/freedesktop/UDisks2/block_devices/sde1'
Device: /dev/dm-1
DeviceNumber: 64769
Drive: '/'
HintAuto: false
HintIconName:
HintIgnore: false
HintName:
HintPartitionable: false
HintSymbolicIconName:
HintSystem: true
Id: by-id-dm-name-luks-ce782db4-f9ee-4154-80e1-72c0d71b08da
IdLabel:
IdType: ext4
IdUUID: d8f0c988-446b-46db-a9f9-15db9431085b
IdUsage: filesystem
IdVersion: 1.0
MDRaid: '/'
MDRaidMember: '/'
PreferredDevice: /dev/mapper/luks-ce782db4-f9ee-4154-80e1-72c0d71b08da
ReadOnly: false
Size: 7740588032
Symlinks: /dev/disk/by-id/dm-name-luks-ce782db4-f9ee-4154-80e1-72c0d71b08da
/dev/disk/by-id/dm-uuid-CRYPT-LUKS2-7b7bdab9c4fc43afabe61240e616b5dc-luks-ce782db4-f9ee-4154-80e1-72c0d71b08da
/dev/disk/by-uuid/d8f0c988-446b-46db-a9f9-15db9431085b
/dev/mapper/luks-ce782db4-f9ee-4154-80e1-72c0d71b08da
UserspaceMountOptions:
org.freedesktop.UDisks2.Filesystem:
MountPoints:
Size: 7740588032
22:50:54.823: /org/freedesktop/UDisks2/block_devices/sde1: org.freedesktop.UDisks2.Encrypted: Properties Changed
CleartextDevice: '/org/freedesktop/UDisks2/block_devices/dm_2d1'
```
The component that seems to be blank is:
```
Id: by-id-dm-name-luks-ce782db4-f9ee-4154-80e1-72c0d71b08da
IdLabel:
IdType: ext4
IdUUID: d8f0c988-446b-46db-a9f9-15db9431085b
IdUsage: filesystem
IdVersion: 1.0
```
and instead of pointing to the /dev/mapper device
```
PreferredDevice: /dev/mapper/luks-ce782db4-f9ee-4154-80e1-72c0d71b08da
```
it points to:
```
PreferredDevice: /dev/dm-0
```
The symlinks were also missing:
```
Symlinks: /dev/disk/by-id/usb-TOSHIBA_TransMemory_000000000000000000000000-0:0-part1
/dev/disk/by-partuuid/41c05551-f39c-42db-b64e-1b36a924f573
/dev/disk/by-path/pci-0000:39:00.0-usb-0:1.3:1.0-scsi-0:0:0:0-part1
/dev/disk/by-uuid/ce782db4-f9ee-4154-80e1-72c0d71b08da
```https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10057RFC: implement optimization profiles2022-02-06T03:00:21ZAriadne Conillariadne@ariadne.spaceRFC: implement optimization profilesPresently, `abuild` only supports a unified set of `CFLAGS`, et al. If you want to override the `CFLAGS` used for a package, you must do it in the `APKBUILD` for that package. However, there are many packages where the default `-Os` op...Presently, `abuild` only supports a unified set of `CFLAGS`, et al. If you want to override the `CFLAGS` used for a package, you must do it in the `APKBUILD` for that package. However, there are many packages where the default `-Os` optimization setting does not make any sense: for the amount of binary size savings, we lose significant performance -- an example of this being the OpenBLAS and LAPACK libraries.
Talking about this with @jirutka we thought about the concept of an *optimization profile*: a package maintainer would specify how the build should be optimized, and `abuild` would choose the correct CFLAGS based on that profile. For example, an `APKBUILD` could have `optprofile=size` or `optprofile=performance`, which would choose different CFLAGS based on the requested profile. It would be desirable for the end-user to be able to override the default profiles in `abuild.conf`, as well.
Thinking out loud, there could be at least three profiles, but we may want additional profiles to trade hardening features for performance too:
* `size`: the current default CFLAGS: `-Os -fomit-frame-pointer`
* `balanced`: basically the same as the current default, but `-O2`
* `performance`: `-O3 -ffast-math -funroll-all-loops ...`
We probably want to tweak these profiles for specific microarchitectural optimizations, too, but that seems like something where @alxu probably knows a lot more than me.
The point of this being that we no longer are just overriding CFLAGS to get `-O2` and so on, it keeps everything more consistent with the building.https://gitlab.alpinelinux.org/alpine/cloud/alpine-cloud-images/-/issues/125AWS Marketplace2021-12-27T17:37:39ZMike Crutemike@crute.usAWS Marketplace*Created by: oxr463*
> ...Ideally I'd say that we should not ever delete and AMI but since I'm personally funding this I'd like to strike a balance between supporting our users and not incurring unbounded cost.
> --https://github.com/m...*Created by: oxr463*
> ...Ideally I'd say that we should not ever delete and AMI but since I'm personally funding this I'd like to strike a balance between supporting our users and not incurring unbounded cost.
> --https://github.com/mcrute/alpine-ec2-ami/issues/23#issuecomment-635713152
Why not list these in the marketplace?Mike Crutemike@crute.usMike Crutemike@crute.ushttps://gitlab.alpinelinux.org/alpine/mkinitfs/-/issues/21Switch default compressor to zstd2021-12-09T18:59:29ZAlex Xu (Hello71)Switch default compressor to zstdDue to small window size, gzip does not take full advantage of the inter-file correlations. All other modern compressors do better; however, only a few options are actually useful. xz is slow to compress and decompress; the latter is par...Due to small window size, gzip does not take full advantage of the inter-file correlations. All other modern compressors do better; however, only a few options are actually useful. xz is slow to compress and decompress; the latter is particularly bad during boot, as the 16-bit real mode kernel decompressor stub is even slower. zstd is a good option because it decompresses quickly. It can use excessive ram when compressing small files at very high compression levels, but for typical initramfs size (around 15 MB) and zstd -19, it uses only about 150 MB.
Implementing this would decrease the initramfs size by about 3 MB and speed up boot by about 0.1 seconds on a 3 GHz amd64 CPU; on a non-overclocked RPi Zero, that could be almost half a second of boot speed-up, plus the decreased I/O (another few hundreds of ms on a slow SD card).https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10736Migrate pkgs.a.o to pmOS python implementation2021-12-17T11:04:25ZCarlo LandmeterMigrate pkgs.a.o to pmOS python implementationThe current pkgs.a.o has been implemented with lua-turbo which unfortunately has not much upstream life.
In combination with luajit, this has been giving us troubles and needing to switch back to regular lua.
The discussion has risen on...The current pkgs.a.o has been implemented with lua-turbo which unfortunately has not much upstream life.
In combination with luajit, this has been giving us troubles and needing to switch back to regular lua.
The discussion has risen on IRC to switch to the python [alternative](http://pkgs.postmarketos.org/packages) created by PmOS.
The sources can be found [here](https://gitlab.com/postmarketOS/apkbrowser).
although most features have been ported over, there is one feature that has been left out, Fedora [Anitya](https://release-monitoring.org/) release monitoring.
This feature has previously been added by @jirutka. @jirutka, are you interested in adding a similar feature to the python implementation?
As previously discussed on IRC, we would like to move this forward even if that means if this feature is missing.
/cc @alpine/infraCarlo LandmeterCarlo Landmeterhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10765Add support for variables in /etc/apk/repositories like Yum has2022-12-21T19:39:44ZChristoph ObexerAdd support for variables in /etc/apk/repositories like Yum hasThis would IMO solve #10756 by replacing the repo in /etc/apk/repositories by a caching proxy
An example need of such a feature is documented in the wiki:
https://wiki.alpinelinux.org/wiki/Alpine_newbie_apk_packages#New_users:_installin...This would IMO solve #10756 by replacing the repo in /etc/apk/repositories by a caching proxy
An example need of such a feature is documented in the wiki:
https://wiki.alpinelinux.org/wiki/Alpine_newbie_apk_packages#New_users:_installing_needed_packages
```
# old /etc/apk/repositories from the example above
cat > /etc/apk/repositories << EOF; $(echo)
http://dl-cdn.alpinelinux.org/alpine/v$(cat /etc/alpine-release | cut -d'.' -f1,2)/main
EOF
```
would become:
```
# proposed /etc/apk/repositories
cat > /etc/apk/repositories << EOF; $(echo)
http://dl-cdn.alpinelinux.org/alpine/v\$releasever/main
EOF
```
Now that is of little use, BUT we use Artifactory as cache and thus point our Alpine containers to a repo mirror there... but need a separate repo file for every alpine release or synthesize a repo file based on the alpine release... that sounds easy enough but the code that needs to synthesize the repo file needs to be running outside the container and thus has to guess the correct release number from docker tags for various base images (node, go, java, ...)...
We would love to be able to just bind mount `/etc/apk/repositories` with our artifactory repositories (and credentials) without fancy magic and use `$releasever` as a placeholder for the version inside them.backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10760Parallelize triggers2024-01-10T16:03:46ZAriadne Conillariadne@ariadne.spaceParallelize triggersSome triggers can take multiple seconds (up to minutes) to run, like the `mkinitfs` trigger.
It would be a nice win to run all triggers in parallel.
Another thing to consider might be running triggers in the background.Some triggers can take multiple seconds (up to minutes) to run, like the `mkinitfs` trigger.
It would be a nice win to run all triggers in parallel.
Another thing to consider might be running triggers in the background.v3.1https://gitlab.alpinelinux.org/alpine/infra/aports-turbo/-/issues/44Consider making the default package search fuzzy (not exact)2024-03-12T06:56:05ZValentinConsider making the default package search fuzzy (not exact)On most websites search is by default fuzzy, including other distro's package search pages like https://archlinux.org/packages/ and https://www.debian.org/distrib/packages . This is different from https://pkgs.alpinelinux.org/packages w...On most websites search is by default fuzzy, including other distro's package search pages like https://archlinux.org/packages/ and https://www.debian.org/distrib/packages . This is different from https://pkgs.alpinelinux.org/packages where the default is exact.
The website does tell you this when you hover over the field with the mouse but it is easy to miss and not everyone uses the mouse to navigate. If you do miss it then you might end up thinking the package you are looking or does not exist or you miss interesting related packages.
For example if I search for `gdb` on alpine I only see the `gdb` package but not `gdb-doc`. In the other linked searches it shows similar names by default.
To me it would feel better if the search was by default something like `*gdb*` with the results ordered by some kind of similarity metric so that the exact match `gdb` still shows up first.
I understand that this is a subjective preference. I still want to give this feedback as it might confuse other new users.https://gitlab.alpinelinux.org/alpine/aports/-/issues/12309net-snmp not working on Alpine 3.13 (amd64)2022-11-19T07:09:09ZStefano Marinellinet-snmp not working on Alpine 3.13 (amd64)Both on updated Alpine 3.12->3.13 hosts and newly created Alpine 3.13 hosts, snmpd kills itself just after being launched. dmesg reports:
`traps: snmpd[21440] general protection fault ip:7f7bbd9efc59 sp:7ffd4e6df8e0 error:0 in ld-musl-...Both on updated Alpine 3.12->3.13 hosts and newly created Alpine 3.13 hosts, snmpd kills itself just after being launched. dmesg reports:
`traps: snmpd[21440] general protection fault ip:7f7bbd9efc59 sp:7ffd4e6df8e0 error:0 in ld-musl-x86_64.so.1[7f7bbd9e1000+48000]`
Removing the trapsink on snmpd.conf, it seems to be running but dmesg reports:
`snmpd[22073]: segfault at 7f7598021110 ip 00007f759859d215 sp 00007ffed55515e0 error 6 in libnetsnmpmibs.so.40.0.0[7f759858b000+ab000]
Code: 09 f0 f3 48 0f 2a c8 f3 0f 58 c9 f3 0f 5e c1 f3 0f 58 05 22 b1 09 00 f3 0f 2c c0 c3 53 e8 53 0e ff ff 48 89 c7 48 85 c0 74 1a <48> 83 a7 70 20 00 00 df 48 c7 87 68 20 00 00 ff ff ff ff e8 c3 33`
Still, there seem to be some stability problems as after some pollings it seems to kill itself.Carlo LandmeterCarlo Landmeterhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12293updating status of packages with maintainers inactive for more than 60 days2022-01-23T20:11:27ZLeoupdating status of packages with maintainers inactive for more than 60 daysThe following is a rough list of maintainers that have not:
- **committed**
- **authored a commit**
1. Check which packages are currently maintained. `grep -r &#39;^# Maintainer: $NAME&#39; .`
2. Check that the name/mail-address hasn&#...The following is a rough list of maintainers that have not:
- **committed**
- **authored a commit**
1. Check which packages are currently maintained. `grep -r '^# Maintainer: $NAME' .`
2. Check that the name/mail-address hasn't just changed but the maintainer remains active.
3. If `2` is true then create a MR pinging the maintainer and changing all the Maintainer and Contributor fields to reflect the new name/mail-address.
4. Check if those packages have new upstream releases that we don't have.
5. Check the history for any other contributors touching the pcakages. `git log -- $PATH_TO_PACKAGE`
6. If either `4` or `5` is true write an email with this template, replace $PACKAGE_LIST with packages the person maintains and $NAME with your handle.
```
Hello
I am contacting because you're the maintainer of one or more packages in Alpine Linux, namely:
$PACKAGE_LIST
Your last commit was made more than 60 days ago, in the meantime one or more packages you maintain received commits from other contributors or had new releases upstream that were followed.
Are you still an active contributor in the Alpine Linux project ? If yes, are there any of the packages listed above you do not wish to maintain anymore ?
Regards
$NAME
Alpine Linux developer
```
in the last 60 days (today being 2021-01-11)
> Situation resolved, maintainer still active
- [x] Adam Dobrawy \<a.dobrawy@hyperone.com>
- [x] Adam Saponara \<as@php.net> (dropped package `waf` on request)
- [x] Andrey Pustovetov \<andrey.pustovetov@gmail.com> (dropped package `async-profile` on request)
- [x] Cosmo Borsky \<me@cosmoborsky.com>
- [x] Carlos Giraldo \<cgiraldo@gradiant.org>
- [x] Bradford D. Boyle \<bradford.d.boyle@gmail.com>
- [x] Boris Faure \<boris@fau.re>
- [x] Adriaan Groenenboom \<agboom@pm.me> (expressed interest in dropping php7-dlib)
---
> Situation resolved: maintainer changed name/mail-address and it has been updated
- [x] Carlo Landmeter \<clandmeter at gmail>
- [x] Carlo Landmeter \<clandmeter@gmail.com>
- [x] Chloe Kudryavtsev \<toast@toastin.space>
---
> Situation resolved: maintainer confirmed its own inactivity, drop all packages
- [x] 7heo \<7heo@mail.com>
- [x] Aji Kisworo Mukti \<aji.kisworo.mukti@gmail.com>
- [x] Bennett Goble \<nivardus@gmail.com>
- [x] Anil Madhavapeddy \<anil@recoil.org>
- [x] Andrey L \<innerspacepilot@gmx.com>
- [x] Breno Leitao \<breno.leitao@gmail.com>
- [x] Adrian Siekierka \<kontakt@asie.pl>
- [x] Christine Dodrill \<me@christine.website>
- [x] Christian Kampka \<christian@kampka.net>
- [x] Andreas Laghamn \<andreas.laghamn@gmail.com>
- [x] Alexander Edland \<alpine@ocv.me>
- [x] Christophe BERAUD-DUFOUR \<christophe.berauddufour@gmail.com>
---
> Situation resolved: package maintained is up-to-date with upstream
- [x] "Andrzej Trzaska \<atrzaska2@gmail.com>"
- [x] Aleks Bunin \<alpinelinux@compuix.com>
- [x] Alex Laskin \<alex@lask.in>
- [x] Alexander Belkov \<msun00@yandex.ru>
- [x] Alexander Willing \<willing.alexander@googlemail.com>
- [x] Andre Bierwolf \<a.b.bierwolf@gmail.com>
- [x] Andy Li \<andy@onthewings.net>
- [x] Anirudh Oppiliappan \<x@icyphox.sh>
- [x] Arch3y \<arch3y@riseup.net>
- [x] Axel Ulrich \<ulrich.axel@gmail.com>
- [x] Benoit Masson \<yahoo@perenite.com>
- [x] sin \<sin@2f30.org>
- [x] Blake Oliver \<oliver22213@me.com>
- [x] Build Robot \<buildrobot@pay.pizza>
- [x] Christian Franke \<nobody@nowhere.ws>
- [x] Cory Sanin \<corysanin@outlook.com>
---
> Situation pending: name in `Maintainer` field doesn't match one in commits
- [ ] Antoni Aloy \<aaloytorrens@gmail.com>
- [ ] solidnerd \<hi@solidnerd.dev>
---
> Situation pending: In discussions
- [ ] Alexander Sack \<asac@pantacor.com>
---
> Contacted
- [ ] Alexander Rigbo \<alex@dnb.nu>
- [ ] Allan Garret \<allan.garret@gmail.com>
- [ ] Andreas Schipplock \<andreas@schipplock.de>
- [ ] Andrew Bell \<andrew.bell.ia@gmail.com>
- [ ] Andrew Hills \<ahills@ednos.net>
- [ ] Andy McLeod \<andy@amcleod.ca>
- [ ] Antoine Tenart \<antoine.tenart@ack.tf>
- [ ] Ashley Sommer \<ashleysommer@gmail.com>
- [ ] Assaf Gordon \<assafgordon@gmail.com>
- [ ] Austin Page \<jaustinpage@gmail.com>
- [ ] Ben Allen \<bensallen@me.com>
- [ ] Ben Pye \<ben@curlybracket.co.uk>
- [ ] Bernhard J. M. Gruen \<bernhard.gruen@googlemail.com>
- [ ] Bjoern Schilberg \<bjoern@intevation.de>
- [ ] Bradley J Chambers \<brad.chambers@gmail.com>
- [ ] Bradley Saulteaux \<-@bradso.to>
- [ ] Bradley Saulteaux \<bradsoto@gmail.com>
- [ ] Bradley Saulteaux \<~@bradso.to>
- [ ] Cameron Banta \<cbanta@gmail.com>
- [ ] Camille Scholtz \<onodera@openmailbox.org>
- [ ] Charles Pritchard \<chuck@jumis.com>
- [ ] Charles Wimmer \<charles@wimmer.net>
- [ ] Chitao.Gao \<neeke@php.net>
- [ ] stef \<l0ls0fo2i@ctrlc.hu>
- [ ] ungleich \<alpinelinux@ungleich.ch>
- [ ] viest \<dev@service.viest.me>
- [ ] xcko \<xcko@airmail.cc>
- [ ] Cian Hughes \<Ci@nHugh.es>
- [ ] Corentin Henry \<corentinhenry@gmail.com>
- [ ] Corey Oliver \<corey.jon.oliver@gmail.com>
- [ ] Corey Oliver \<coreyjonoliver@gmail.com>
- [ ] Cían Hughes \<Ci@nHugh.es>
---
> Failure to deliver: Address does not exist
- [ ] Alan Lacerda \<alacerda@alpinelinux.org>
- [ ] August Klein \<amatcoder@gmail.com>
- [ ] Chris Leishman \<chris@leishman.org>
---
> Failure to deliver: blocked
- [ ] Aaron Hurt \<ahurt@ena.com>
- [ ] Alexander Kulak \<sa-dev@rainbow.by>
---
> No longer maintainer of any packages
- [x] Adam Nye \<adam@spoontech.biz>
---
- [ ] Bartłomiej Piotrowski \<nospam@bpiotrowski.pl>
- [ ] Daiki Maekawa \<daikimaekawa29@gmail.com>
- [ ] Dan Theisen \<djt@hxx.in>
- [ ] Danct12 \<danct12@disroot.org>
- [ ] Daniel Corbe \<daniel@corbe.net>
- [ ] Daniel Everett \<deverett@gmail.com>
- [ ] Daniel Isaksen \<d@duniel.no>
- [ ] Daniel Sabogal \<dsabogalcc@gmail.com>
- [ ] Daniele Debernardi \<drebrez@gmail.com>
- [ ] Danilo Bürger \<danilo@feastr.de>
- [ ] Danilo Falcão \<danilo@falcao.org>
- [ ] Dave Hall \<skwashd@gmail.com>
- [ ] Dave Henderson \<dhenderson@gmail.com>
- [ ] David Heidelberg \<david@ixit.cz>
- [ ] David Huffman \<storedbox@outlook.com>
- [ ] David Sugar \<tychosoft@gmail.com>
- [ ] Dawid Dziurla \<dawidd0811@gmail.com>
- [ ] Dekedro \<dekedro@tankers.xyz>
- [ ] Denis Ryabyy \<vv1r0x@gmail.com>
- [ ] Diaz Devera Victor \<vitronic2@gmail.com>
- [ ] Diego Queiroz \<diego.queiroz@gmail.com>
- [ ] Dominic Fung \<domokun997@gmail.com>
- [ ] Duncan Guthrie \<dguthrie@posteo.net>
- [ ] Díaz Urbaneja Diego \<sodomon2@gmail.com>
- [ ] Ed Robinson \<ed+alpine@reevoo.com>
- [ ] Ed Robinson \<ed@reevoo.com>
- [ ] Ed Robinson \<edward-robinson@cookpad.com>
- [ ] Ehud Kaldor \<ehud@unfairfunction.org>
- [ ] Eivind Uggedal \<eu@eju.no>
- [ ] Elizabeth Jennifer Myers \<elizabeth@sporksirc.net>
- [ ] Emily Ingalls \<emily@ingalls.rocks>
- [ ] Eric Molitor \<eric@molitor.org>
- [ ] Erik Ogan \<erik@stealthymonkeys.com>
- [ ] Erik Wisuri \<ewisuri@gmail.com>
- [ ] Fabio Aires \<fabioaires.web@gmail.com>
- [ ] Fabio Napoleoni \<f.napoleoni@gmail.com>
- [ ] Fabio Ribeiro \<fabiorphp@gmail.com>
- [ ] Fathi Boudra \<fathi.boudra@linaro.org>
- [ ] Fernando Casas Schossow \<casasfernando@outlook.com>
- [ ] Florian Heigl \<florian.heigl@gmail.com>
- [ ] Francesco Colista \<francesco.colista@gmail.com>
- [ ] Francesco Zanini \<francesco@zanini.me>
- [ ] Frank Hunleth \<fhunleth@troodon-software.com>
- [ ] François Chavant \<alpine@mail.chavant.info>
- [ ] Frédéric Guillot \<fred@miniflux.net>
- [ ] G.J.R. Timmer \<gjr.timmer@gmail.com>
- [ ] Gavin D. Howard \<yzena.tech@gmail.com>
- [ ] Gennady Feldman \<gena01@gmail.com>
- [ ] Guilherme Felipe da Silva \<gfsilva.eng@gmail.com>
- [ ] Haelwenn (lanodan) Monnier \<contact+alpine@hacktivis.me>
- [ ] Hasse Hagen Johansen \<hasse-docker@hagenjohansen.dk>
- [ ] Hauke Loeffler \<alpine@hauke-loeffler.de>
- [ ] He Yangxuan \<yangxuan8282@gmail.com>
- [ ] Heiko Bernloehr \<Heiko.Bernloehr@FreeIT.de>
- [ ] Hinata Yanagi \<hinasssan@gmail.com>
- [ ] Hiroshi Kajisha \<kajisha@gmail.com>
- [ ] Holger Jaekel \<holger.jaekel@gmx.de>
- [ ] Hristiyan Ivanov \<hristiyan.d.ivanov@gmail.com>
- [ ] HyperOne staff \<pkg-maintainers@hyperone.com>
- [ ] Ian Bashford \<ianbashford@gmail.com>
- [ ] Ian Douglas Scott \<ian@iandouglasscott.com>
- [ ] Iilluzion \<iilluzion@gmail.com>
- [ ] Isaac Dunham \<ibid.ag@gmail.com>
- [ ] Iskren Chernev \<iskren.chernev@gmail.com>
- [ ] Ivan Tham \<pickfire@riseup.net>
- [ ] Jakub Skrzypnik \<j.skrzypnik@openmailbox.org>
- [ ] James White \<stegoxorus@gmail.com>
- [ ] Jan Tatje \<jan@jnt.io>
- [ ] Jared Szechy \<jared.szechy@gmail.com>
- [ ] Jay Christopherson \<jaychris@gmail.com>
- [ ] Jean-Louis Fuchs \<jean-louis.fuchs@adfinis-sygroup.ch>
- [ ] Jeff Bilyk \<jbilyk@alpinelinux.org>
- [ ] Jeff Bilyk \<jbilyk@gmail.com>
- [ ] Jeff Pohlmeyer \<yetanothergeek@gmail.com>
- [ ] Jens Staal \<staal1978@gmail.com>
- [ ] Jeremy O'Brien \<neutral@fastmail.com>
- [ ] Jeremy Thomerson \<jeremy@thomersonfamily.com>
- [ ] Jesse Young \<jlyo@jlyo.org>
- [ ] Jinming Wu, Patrick \<me@patrickwu.space>
- [ ] Jirka Dutka \<jirka@dutka.net>
- [ ] Joe Holden \<jwh@zorins.us>
- [ ] Joe Searle \<joe@jsearle.net>
- [ ] Joel Hansen \<joelh@disroot.org>
- [ ] Johan Bergström \<bugs@bergstroem.nu>
- [ ] Johannes Findeisen \<you@hanez.org>
- [ ] Johannes Matheis \<jomat+alpinebuild@jmt.gr>
- [ ] John Kerl \<kerl.john.r@gmail.com>
- [ ] John Regan \<john@jrjrtech.com>
- [ ] Jonathan Sieber \<mail@strfry.org>
- [ ] Jonny Tyers \<jtyers@gmail.com>
- [ ] Joonas Kuorilehto \<oss@derbian.fi>
- [ ] Jose Maria Garcia \<josemaria.alkala@gmail.com>
- [ ] Jose-Luis Rivas \<ghostbar@riseup.net>
- [ ] Josef Vybíhal \<jvybihal@uniscomp.cz>
- [ ] Joseph Benden \<joe@benden.us>
- [ ] Joshua Haase \<hahj87@gmail.com>
- [ ] Julian Weigt \<juw@posteo.de>
- [ ] Julien (jvoisin) Voisin \<julien.voisin+snuffleupagus@dustri.org>
- [ ] Justin Menga \<justin.menga@gmail.com>
- [ ] Karim Kanso \<kaz.kanso@gmail.com>
- [ ] Katie Holly \<holly@fuslvz.ws>
- [ ] Keith \<keithy@consultant.com>
- [ ] Keith Maxwell \<keith.maxwell@gmail.com>
- [ ] Kiyoshi Aman \<kiyoshi.aman+adelie@gmail.com>
- [ ] Kiyoshi Aman \<kiyoshi.aman@gmail.com>
- [ ] Klemens Nanni \<kl3@posteo.org>
- [ ] Kozak Ivan \<kozak-iv@yandex.ru>
- [ ] Kristóf Jakab \<jakab.kristof@balasys.hu>
- [ ] Kurt Marasco \<celilo@lavabit.com>
- [ ] Kyle Parisi \<kyleparisi@gmail.com>
- [ ] Laurent Arnoud \<laurent@spkdev.net>
- [ ] Leo Unglaub \<leo@unglaub.at>
- [ ] Leon Bottou \<leonb@bottou.org>
- [ ] Leonardo Arena \<rnalrd@alpinelinx.org>
- [ ] Linus Swälas \<linus.swalas@borderless.se>
- [ ] Luka Vandervelden \<lukc@upyum.com>
- [ ] Maartje Eyskens \<maartje@eyskens.me>
- [ ] Maciej Klak \<klak.maciej@gmail.com>
- [ ] Magicloud \<magiclouds@gmail.com>
- [ ] Marc Vertes \<mvertes@free.fr>
- [ ] Marian \<marian.buschsieweke@ovgu.de>
- [ ] Marian Buschsiewke \<marian.buschsieweke@ovgu.de>
- [ ] Mark Constable \<markc@renta.net>
- [ ] Mark Jynx \<markjynx@cock.li>
- [ ] Mark Pashmfouroush \<mark@markpash.me>
- [ ] Mark Riedesel \<mark+alpine@klowner.com>
- [ ] Mark Riedesel \<mark@klowner.com>
- [ ] Markus Juenemann \<markus@juenemann.net>
- [ ] Marlus Saraiva \<marlus.saraiva@gmail.com>
- [ ] Martijn Braam \<martijn@brixit.nl>
- [ ] Martin Rusko \<martin.rusko@gmail.com>
- [ ] Martin Schmidt \<martin.schmidt13@gmx.de>
- [ ] Mathew Meins \<mathewm@sdf.lonestar.org>
- [ ] Mathias LANG \<pro.mathias.lang@gmail.com>
- [ ] Matt Smith \<mcs@darkregion.net>
- [ ] Matthew T Hoare \<matthew.t.hoare@gmai.com>
- [ ] Matthew.T.Hoare \<matthew.t.hoare@gmail.com>
- [ ] Matthias Neugebauer \<mtneug@mailbox.org>
- [ ] Matthieu Monnier \<matthieu.monnier@enalean.com>
- [ ] Max Claus Nunes \<maxcnunes@gmail.com>
- [ ] Michael Aldridge \<maldridge@voidlinux.org>
- [ ] Michael Jeanson \<mjeanson@efficios.com>
- [ ] Michael John \<gosh.mike@gmail.com>
- [ ] Michael Koloberdin \<koloberdin@gmail.com>
- [ ] Michael Mason \<ms13sp@gmail.com>
- [ ] Michael Truog \<mjtruog@gmail.com>
- [ ] Michael Zhou \<zhoumichaely@gmail.com>
- [ ] Michael Zuo \<muh.muhten@gmail.com>
- [ ] Michał Fita \<1369-Manveru@users.gitlab.alpinelinux.org>
- [ ] Mickaël Remars \<github@remars.com>
- [ ] Miguel Terron \<miguel.a.terron@gmail.com>
- [ ] Mika Havela \<mika.havela@gmail.com>
- [ ] Mike Crute \<mike@crute.us>
- [ ] Mikhail Snetkov \<msnetkov@navikey.ru>
- [ ] Mikolaj Chwalisz \<chwalisz@tkn.tu-berlin.de>
- [ ] Milan P. Stanic \<mps@arvanta.net>
- [ ] Miles Alan \<m@milesalan.com>
- [ ] Minecrell \<minecrell@minecrell.net>
- [ ] Mitch Tishmack \<mitch.tishmack@gmail.com>
- [ ] MrBiTs \<mrbits@mrbits.com.br>
- [ ] Natanael Copa \<natanael.copa@gmail.com>
- [ ] Natanael Copa \<ncopa@alpinleinux.org>
- [ ] Natanael Copa \<ncopa@alpinlinux.org>
- [ ] Nathan \<ndowens@artixlinux.org>
- [ ] Nathan Angelacos \<nangel@alpinelinux.org>
- [ ] Nathan Caldwell \<saintdev@gmail.com>
- [ ] Nathan Johnson \<nathan@nathanjohnson.info>
- [ ] Nathan Rennie-Waldock \<nathan.renniewaldock@gmail.com>
- [ ] Nero \<nero@w1r3.net>
- [ ] Nick Andrew \<nick@nick-andrew.net>
- [ ] Nick Black \<dankamongmen@gmail.com>
- [ ] Nicola Worthington \<nicolaw@tfb.net>
- [ ] Niko Dittmann \<mail@niko-dittmann.com>
- [ ] Noam Preil \<pleasantatk@gmail.com>
- [ ] Oliver Smith \<ollieparaoid@postmarketos.org>
- [ ] Orion \<systmkor@gmail.com>
- [ ] Orson Teodoro \<orsonteodoro@hotmail.com>
- [ ] Oz Tiram \<oz.tiram@gmail.com>
- [ ] Patrick Gansterer \<paroga@paroga.com>
- [ ] Patrick Gaskin \<patrick@pgaskin.net>
- [ ] Paul Kilar \<pkilar@gmail.com>
- [ ] Paul Morgan \<jumanjiman@gmail.com>
- [ ] Pavel Pletenev \<cpp.create@gmail.com>
- [ ] Paweł Tomak \<pawel@tomak.eu>
- [ ] Pedro Filipe \<xpecex@outlook.com>
- [ ] Pegah Bahramiani \<pb.bahramiani@gmail.com>
- [ ] Pellegrino Prevete \<pellegrinoprevete@gmail.com>
- [ ] Pete Dietl \<petedietl@gmail.com>
- [ ] Philipp Andronov \<filipp.andronov@gmail.com>
- [ ] Philipp Glaum \<p@pglaum.de>
- [ ] Przemyslaw Pawelczyk \<przemoc@zoho.com>
- [ ] Raatty \<me@raatty.club>
- [ ] Rafael del Valle \<rvalle@privaz.io>
- [ ] Ramanathan Sivagurunathan \<ramzthecoder@gmail.com>
- [ ] Raphael Cohn \<raphael.cohn@stormmq.com>
- [ ] Raymond Page \<pagerc@gmail.com>
- [ ] Renoir Boulanger \<hello@renoirboulanger.com>
- [ ] Richard Mortier \<mort@cantab.net>
- [ ] Robert Boisvert \<rdboisvert@gmail.com>
- [ ] Robert Hencke \<robert.hencke@gmail.com>
- [ ] Robert Sacks \<robert@sacks.email>
- [ ] Roberto Oliveira \<robertoguimaraes8@gmail.com>
- [ ] Roger Newman \<roger.newman@riseup.net>
- [ ] Russ Webber \<russ@rw.id.au>
- [ ] Róbert Nagy \<vrnagy@gmail.com>
- [ ] Sam Dodrill \<shadowh511@gmail.com>
- [ ] Samuel Hunter \<samuelhunter1024@gmail.com>
- [ ] Sander Maijers \<S.N.Maijers+Alpine@gmail.com>
- [ ] Sascha Brawer \<sascha@brawer.ch>
- [ ] Sascha Paunovic \<azarus@posteo.net>
- [ ] Sasha Gerrand \<alpine-pkgs@sgerrand.com>
- [ ] ScrumpyJack \<scrumpyjack@me.com>
- [ ] ScrumpyJack \<scrumpyjack@st.ilet.to>
- [ ] ScrumpyJack \<scrumypjack@st.ilet.to>
- [ ] Sean McAvoy \<seanmcavoy@gmail.com>
- [ ] Sebastian Hugentobler \<sebastian@vanwa.ch>
- [ ] Sergey Safarov \<s.safarov@gmail.com>
- [ ] Shannon Noe \<snoe925@gmail.com>
- [ ] Shawn Johnson \<sjohnson@axiomega.com>
- [ ] Shiva Velmurugan \<shiv@shiv.me>
- [ ] Shiz \<hi@shiz.me>
- [ ] Shyam Sunder \<sgsunder1@gmail.com>
- [ ] Simon Frankenberger \<simon-alpine@fraho.eu>
- [ ] Simon Rupf \<simon@rupf.net>
- [ ] Simon Zeni \<simon@bl4ckb0ne.ca>
- [ ] Steeve Chailloux \<steeve.chailloux@orus.io>
- [ ] Steeve Chailloux \<steeve@chaahk.com>
- [ ] Stefan Stutz \<stutz@pm.me>
- [ ] Stefan Wagner \<stw@bit-strickerei.de>
- [ ] Stefano Marinelli \<stefano@dragas.it>
- [ ] Steffen Lange \<steffen@stelas.de>
- [ ] Steve McMaster \<code@mcmaster.io>
- [ ] Steven Honson \<steven@honson.id.au>
- [ ] Sven Wick \<sven.wick@gmx.de>
- [ ] Sören Tempel \<soeren+alpine@soeren-tempel.net>
- [ ] Sören Tempel \<soeren+alpinelinux@soeren-tempel.net>
- [ ] TBK \<alpine@jjtc.eu>
- [ ] Takumi Takahashi \<takumiiinn@gmail.com>
- [ ] Thomas Boerger \<thomas@webhippie.de>
- [ ] Thomas Kienlen \<t.kienlen@adhoc-gti.com>
- [ ] Tiago Ilieve \<tiago.myhro@gmail.com>
- [ ] Timo Teras \<timo.teras@iki.fi>
- [ ] TimotheeLF \<timotheel-f@protonmail.com>
- [ ] Tobias Spieth \<tobias.spieth@evbox.com>
- [ ] Tom Parker-Shemilt \<palfrey@tevp.net>
- [ ] Trevis Schiffer \<nikolaibitinit@gmail.com>
- [ ] Trevor R.H. Clarke \<trevor@notcows.com>
- [ ] Tuan M. Hoang \<tmhoang@flatglobe.org>
- [ ] Ty Sarna \<ty@sarna.org>
- [ ] Tycho Andersen \<tycho@docker.com>
- [ ] Valery Kartel \<valery.kartel@gmail.com>
- [ ] Vince Mele \<vmele@inoc.com>
- [ ] Will Jordan \<will.jordan@gmail.com>
- [ ] Yagnesh Mistry \<ysh@live.in>
- [ ] Yohann DANELLO \<yohann.danello@crans.org>
- [ ] alpine-mips-patches \<info@mobile-stream.com>
- [ ] alpterry \<alpterry@protonmail.com>
- [ ] arch3y \<arch3y@riseup.net>
- [ ] arx \<thinkabit.ukim@gmail.com>
- [ ] atka \<atka@tuta.io>
- [ ] azmeuk \<eloi@yaal.fr>
- [ ] dai9ah \<dai9ah@protonmail.com>
- [ ] jv \<jens@eisfair.org>
- [ ] kohnish \<kohnish@gmx.com>
- [ ] l-n-s \<supervillain@riseup.net>
- [ ] lemon \<lemon@bitmessage.ch>
- [ ] llnu \<llnu@ungleich.ch>
- [ ] mcrmonkey \<git@manchestermonkey.co.uk>
- [ ] nixfloyd \<nixfloyd@gmail.com>
- [ ] opal hart \<opal@wowana.me>
- [ ] rahmanshaber \<rahmanshaber@yahoo.com>
- [ ] rfaa \<rfaa@rfaa.se>
- [ ] shrizza \<shrizza@gmail.com>
- [ ] signageOS \<dev@signageos.io>https://gitlab.alpinelinux.org/alpine/docker-abuild/-/issues/68Auto-update Docker image2020-09-01T16:50:55ZLuca WeissAuto-update Docker imageIt would be nice if dabuild would auto-update its Docker image every so often (maybe once a month?) as otherwise the updates inside the container will get longer and longer.
My suggestion is checking (with some docker magic) how old the...It would be nice if dabuild would auto-update its Docker image every so often (maybe once a month?) as otherwise the updates inside the container will get longer and longer.
My suggestion is checking (with some docker magic) how old the image is, if it's older than 30 days then ask the user whether they want to update the image (then it would docker pull the new image and continue) or not, where the tool just continues and does the updates inside the container as it does at the momenthttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11754nginx-mod-http-lua needs requires working directory in /usr/lib/nginx and com...2021-05-25T21:34:31ZFerdinand Prantlnginx-mod-http-lua needs requires working directory in /usr/lib/nginx and complains a lotUsing Alpine Linux latest (3.12) with the following `Dockerfile`:
```dockerfile
FROM alpine:latest
RUN apk --no-cache add nginx-mod-http-lua && \
mkdir -p /run/nginx
```
and building & serving a project in the current directory by:...Using Alpine Linux latest (3.12) with the following `Dockerfile`:
```dockerfile
FROM alpine:latest
RUN apk --no-cache add nginx-mod-http-lua && \
mkdir -p /run/nginx
```
and building & serving a project in the current directory by:
```sh
docker build -t nginx-lua .
docker run --rm -it -p 80:80 -v "${PWD}":/app -w /app nginx-lua nginx -p .
```
fails with:
```txt
2020/07/18 11:29:10 [emerg] 1#1: dlopen() "./modules/ndk_http_module.so" failed
(Error loading shared library ./modules/ndk_http_module.so:
No such file or directory) in /etc/nginx/modules/devel_kit.conf:1
```
because the configuration files `devel_kit.conf` and `http_lua.conf` expect nginx to start in `/usr/lib/nginx`. **How about putting the full path to the configuration files?**
```txt
load_module "/usr/lib/nginx/modules/ndk_http_module.so";
load_module "/usr/lib/nginx/modules/ngx_http_lua_module.so";
```
After overcoming the module loading problem, the user is intimidated by an alert and an error:
```txt
2020/07/18 12:28:07 [alert] 1#1: detected a LuaJIT version which is not OpenResty's; many optimizations will be disabled and performance will be compromised (see https://github.com/openresty/luajit2 for OpenResty's LuaJIT or, even better, consider using the OpenResty releases from https://openresty.org/en/download.html)
```
**How about installing the LuaJIT version that openresty/lua-nginx-module recommends?**
```txt
2020/07/18 12:28:07 [error] 1#1: lua_load_resty_core failed to load the resty.core module from https://github.com/openresty/lua-resty-core; ensure you are using an OpenResty release from https://openresty.org/en/download.html (rc: 2, reason: module 'resty.core' not found:
no field package.preload['resty.core']
no file './resty/core.lua'
no file '/usr/share/luajit-2.1.0-beta3/resty/core.lua'
no file '/usr/local/share/lua/5.1/resty/core.lua'
no file '/usr/local/share/lua/5.1/resty/core/init.lua'
no file '/usr/share/lua/5.1/resty/core.lua'
no file '/usr/share/lua/5.1/resty/core/init.lua'
no file '/usr/share/lua/common/resty/core.lua'
no file '/usr/share/lua/common/resty/core/init.lua'
no file './resty/core.so'
no file '/usr/local/lib/lua/5.1/resty/core.so'
no file '/usr/lib/lua/5.1/resty/core.so'
no file '/usr/local/lib/lua/5.1/loadall.so'
no file './resty.so'
no file '/usr/local/lib/lua/5.1/resty.so'
no file '/usr/lib/lua/5.1/resty.so'
no file '/usr/local/lib/lua/5.1/loadall.so')
```
A simple example using `ngx.say` works, but the error does not look well. **How about including the `resty.core` module in the package?**Jakub JirutkaJakub Jirutkahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11670targetcli does not succesfully restore config2020-11-09T13:35:25ZAlain van Hooftargetcli does not succesfully restore configAfter configuring targetcli and saving config, config is not restored after a reboot, or when loaded via commandline. Both due to this error:
targetcli restoreconfig
restore_from_file() takes from 1 to 4 positional arguments but 5 were ...After configuring targetcli and saving config, config is not restored after a reboot, or when loaded via commandline. Both due to this error:
targetcli restoreconfig
restore_from_file() takes from 1 to 4 positional arguments but 5 were given
Note: "targetctl restore" does work.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10699Making it more obvious that mixing edge and stable isn't supported2022-12-21T20:09:57ZRasmus Thomsenoss@cogitri.devMaking it more obvious that mixing edge and stable isn't supportedI think that many users aren't aware that mixing stable releases and packages from edge isn't supported and might break at any point - e.g. when we bump an soname and rebuild everything but the stable release still has the old library ve...I think that many users aren't aware that mixing stable releases and packages from edge isn't supported and might break at any point - e.g. when we bump an soname and rebuild everything but the stable release still has the old library version in it. As such, I think it'd make sense if APK either explicitly warned you about it, or even better if it threw an error you'd have to override, so something like this wehn when doing `update`/`upgrade`/`add` etc. with mixed repos in `/etc/apk/repositories`:
```
$ apk update
ERROR: Detected repositories from multiple different releases in /etc/apk/repositories.
Please keep in mind that this is unsupported and might break at any point. See $SOME_INFORMATIVE_LINK
for more information. Specify --allow-broken-mixing-releases to keep going anyway.
```backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10680A higher level API for libapk2022-12-21T19:37:23ZRasmus Thomsenoss@cogitri.devA higher level API for libapkHello,
I think it would be nice if libapk used a friendlier, higher level API for dealing with package operations, so that projects like QtApk or apk-polkit don't have to wrap as much functionality.
Overall, I think the following funct...Hello,
I think it would be nice if libapk used a friendlier, higher level API for dealing with package operations, so that projects like QtApk or apk-polkit don't have to wrap as much functionality.
Overall, I think the following functionality should be exposed via a higher level API:
* Add packages
* Delete packages
* Upgrading packages
* Querying information about a package
* Listing packages (and filtering, e.g. upgradable/installed)
* Open/Close the database
Other bits probably aren't too interesting for projects using libapk.v3.1https://gitlab.alpinelinux.org/alpine/docker-abuild/-/issues/61Implement reuse container2021-04-08T21:10:02ZCarlo LandmeterImplement reuse containerI would like to implement DABUILD_REUSE. The major idea behind is when you are building packages it could fail and this would allow us to quickly reuse the existing container and rerun abuild. Currently we have cached volumes to kind of ...I would like to implement DABUILD_REUSE. The major idea behind is when you are building packages it could fail and this would allow us to quickly reuse the existing container and rerun abuild. Currently we have cached volumes to kind of do similar, but it's not an optimal solution and is currently being removed in !60. I currently have some code locally to test it and it seems to work nicely but it's kind of rough. I also haven't completely thought about possible issues so comments are welcome.Carlo LandmeterCarlo Landmeterhttps://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10638Vagrant VirtualBox image for Alpine2019-08-03T06:35:50ZMichael AldridgeVagrant VirtualBox image for AlpineI have a series of scripts and a packer template for both Vagrant Virtualbox and for an Amazon AMI. I can clean up both from my organization's internal repository and provide them to the Alpine project if there is interest. I do not kn...I have a series of scripts and a packer template for both Vagrant Virtualbox and for an Amazon AMI. I can clean up both from my organization's internal repository and provide them to the Alpine project if there is interest. I do not know the best way to do this though, as I am not currently a contributor to Alpine. I also do not think Alpine is currently in control of the atlas namespace (https://app.vagrantup.com/alpine) as there is no official branding on the account.
Lets assume we start with the work on Vagrant, what's the best way for me to proceed here? I can contribute the parts but not take care of the release process for images (I have a personal policy of only maintaining the release train for one distro, and Void already occupies that slot).