alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2019-07-14T07:26:48Zhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/124apk add does not run .pre-install2019-07-14T07:26:48ZNathan Angelacosapk add does not run .pre-installtinyproxy user not created in 1.9.0beta2
\#apk add tinyproxy
Installing tinyproxy (1.6.3-r1)
Executing tinyproxy-1.6.3-r1.post-install
chown: unknown user/group tinyproxy:tinyproxy
\#adduser -h /dev/null -s /bin/false -D -H tinyp...tinyproxy user not created in 1.9.0beta2
\#apk add tinyproxy
Installing tinyproxy (1.6.3-r1)
Executing tinyproxy-1.6.3-r1.post-install
chown: unknown user/group tinyproxy:tinyproxy
\#adduser -h /dev/null -s /bin/false -D -H tinyproxy
*(from redmine: issue id 124, created on 2009-08-09, closed on 2009-08-19)*
* Relations:
* duplicates #126
* Changesets:
* Revision bc93eaffb0fe5dcb053364244f660e78199987e1 by Timo Teräs on 2009-08-10T05:47:05Z:
```
db, pkg: fix package verification during installation
some hooks to package verification code were missing causing the
verification to not be done (causing pre-script to be not run).
fixes #124, #126.
```Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/5055setup-disk incompatible with sfdisk2021-01-06T16:38:51ZMichael Smithsetup-disk incompatible with sfdiskI’m trying to install alpine to disk on a Samsung n150 netbook. I
downloaded alpine-3.3.1-x86\_64.iso and dd’ed it to a usb drive. It
booted fine. After I successfully set up wireless networking, I ran
setup-alpine. It worked fine until ...I’m trying to install alpine to disk on a Samsung n150 netbook. I
downloaded alpine-3.3.1-x86\_64.iso and dd’ed it to a usb drive. It
booted fine. After I successfully set up wireless networking, I ran
setup-alpine. It worked fine until it got to setup-disk. (-m That died
rather opaquely with “Failed to add parition: Invalid argument”.
Here is my answerfile:
KEYMAPOPTS="us us"
HOSTNAMEOPTS="-n n150"
INTERFACESOPTS="auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
hostname n150
auto wlan0
iface wlan0 inet dhcp
hostname n150
"
DNSOPTS="-d example.com 8.8.8.8"
TIMEZONEOPTS="-z UTC"
PROXYOPTS=none
APKREPOSOPTS="-r"
SSHDOPTS="-c dropbear"
NTPOPTS="-c chrony"
DISKOPTS="-m sys /dev/sda"
After some digging, I discovered that setup-disk is trying to set disk
types to “83” and “82” respectively, and that sfdisk does not understand
those numbers. (sfdisk is “sfdisk from util-linux 2.27.1”)
I manually ran sfdisk and used the “L” and “S” shortcuts it suggests.
That got me past the first bug, but now ‘find\_nth\_non\_boot\_parts’
isn’t grepping sfdisk -d for the correct output.
I will continue hacking at this as time allows, but since Googling
didn’t turn anything up I wanted to make sure it got reported.
Is it possible to either pin sfdisk to a version that is known to work
with setup-disk, or to fix setup-disk to use the long-form partition
types?
*(from redmine: issue id 5055, created on 2016-01-31)*
* Uploads:
* [alpinelinux-bug5055.fstype.patch](/uploads/120f8dba9e2a1e29bcfa4e177b62ec14/alpinelinux-bug5055.fstype.patch) Patch to make setup-disk use long-form hexadecimal disk typeshttps://gitlab.alpinelinux.org/alpine/awall/-/issues/2243Awall ignore "icmp-type" attribute2019-07-14T07:55:49ZLeonardo ArenaAwall ignore "icmp-type" attributeTake this sample policy:
{
"description": "Essential ICMPs",
"service": {
"frag-needed": { "proto": "icmp", "icmp-type": 3 }
},
"filter": [
{
"service": "frag-needed",
"...Take this sample policy:
{
"description": "Essential ICMPs",
"service": {
"frag-needed": { "proto": "icmp", "icmp-type": 3 }
},
"filter": [
{
"service": "frag-needed",
"action": "accept"
}
]
}
The resulting rule in rules-save file is:
-A FORWARD -p icmp -j ACCEPT
This happens on version 0.3.2-r0. Prior versions haven’t been tested.
Thanks!
*(from redmine: issue id 2243, created on 2013-08-30, closed on 2013-10-31)*Kaarle RitvanenKaarle Ritvanenhttps://gitlab.alpinelinux.org/alpine/docker-abuild/-/issues/23entrypoint.sh now updates packages on every run2019-06-21T14:58:59ZCarlo Landmeterentrypoint.sh now updates packages on every run*Created by: mor1*
Invoking `sudo apk -U upgrade -a` in `entrypoint.sh` significantly slows down invocation of `dabuild` because the updates aren't cached so have to be applied every time.
Better would be to autobuild and update the ...*Created by: mor1*
Invoking `sudo apk -U upgrade -a` in `entrypoint.sh` significantly slows down invocation of `dabuild` because the updates aren't cached so have to be applied every time.
Better would be to autobuild and update the `alpinelinux/docker-abuild` images on Hub when packages are updated I think -- is that feasible?
/cc @clandmeter @tcely https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/issues/24Automatically add security tag and tell user to make a MR for stable if in co...2022-04-23T14:26:15ZAnjandev MomiAutomatically add security tag and tell user to make a MR for stable if in community/mainAlgit should automatically read in the git diff and add the "security" tag by parsing secfixes. If the package is in community/main, it should notify the user to send a patch to patch main.
Example of algit not doing this:
https://gitl...Algit should automatically read in the git diff and add the "security" tag by parsing secfixes. If the package is in community/main, it should notify the user to send a patch to patch main.
Example of algit not doing this:
https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/29529https://gitlab.alpinelinux.org/alpine/aports/-/issues/35Quagga Autonomous System Number Remote Denial Of Service Vulnerability2023-08-13T23:17:36Ziilluzion _Quagga Autonomous System Number Remote Denial Of Service Vulnerability**Alpine Linux related**: All *quagga-0.99.xx* packages in Alpine Linux
releases up to *alpine-1.9.0\_alpha9*
**Severity**: Medium
**Potential loss type**: Availability
**Patch available**: Yes
**Vulnerability description**:
>The...**Alpine Linux related**: All *quagga-0.99.xx* packages in Alpine Linux
releases up to *alpine-1.9.0\_alpha9*
**Severity**: Medium
**Potential loss type**: Availability
**Patch available**: Yes
**Vulnerability description**:
>The BGP daemon (bgpd) in Quagga 0.99.11 and earlier allows remote
attackers to cause a denial of service (crash) via an AS path containing
ASN elements whose string representation is longer than expected, which
triggers an assert error.
**References**:
- DEBIAN: http://www.debian.org/security/2009/dsa-1788
- MLIST: http://marc.info/?l=quagga-dev&m=123364779626078&w=2
- CONFIRM: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526311
- XF: http://xforce.iss.net/xforce/xfdb/50317
- UBUNTU: http://www.ubuntu.com/usn/usn-775-1
- SECTRACK: http://www.securitytracker.com/id?1022164
- BID: http://www.securityfocus.com/bid/34817
- OSVDB: http://www.osvdb.org/54200
- MLIST: http://www.openwall.com/lists/oss-security/2009/05/01/2
- MLIST: http://www.openwall.com/lists/oss-security/2009/05/01/1
- MANDRIVA:
http://www.mandriva.com/security/advisories?name=MDVSA-2009:109
- MISC: http://thread.gmane.org/gmane.network.quagga.devel/6513
- SECUNIA: http://secunia.com/advisories/35061
- SECUNIA: http://secunia.com/advisories/34999
*(from redmine: issue id 35, created on 2009-05-21, closed on 2009-06-23)*Natanael CopaNatanael Copa2009-05-28https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/708Test ticket2019-07-12T16:14:48ZJeff Bilykjbilyk@gmail.comTest ticketTesting
—
Jeff
*(from redmine: issue id 708, created on 2011-07-14, closed on 2011-07-14)*Testing
—
Jeff
*(from redmine: issue id 708, created on 2011-07-14, closed on 2011-07-14)*https://gitlab.alpinelinux.org/alpine/abuild/-/issues/4985udev replacement2019-07-14T07:26:16ZSören Tempeludev replacementAs discussed on
[alpine-devel](http://lists.alpinelinux.org/alpine-devel/4958.html) last
year it would be nice to replace udev with some smaller in the next
major release. By default we still use mdev these days, but you can’t
run Xorg w...As discussed on
[alpine-devel](http://lists.alpinelinux.org/alpine-devel/4958.html) last
year it would be nice to replace udev with some smaller in the next
major release. By default we still use mdev these days, but you can’t
run Xorg with mdev out of the box currently. The
[setup-xorg-base](http://git.alpinelinux.org/cgit/alpine-conf/tree/setup-xorg-base.in)
script automatically replaces the mdev service with udev.
I would appreciate it if we would switch to one of the udev alternatives
discussed on the ML.
*(from redmine: issue id 4985, created on 2016-01-03, closed on 2017-05-25)*https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/126'fetchmail' does not exist in 1.9.0 beta 22019-07-14T07:26:48ZStephen Mun'fetchmail' does not exist in 1.9.0 beta 2“acf-fetchmail-0.4.0-r0” does not create the user “fetchmail”
‘fetchmail’ user should be manually created.
adduser –h /var/lib/fetchmail –s /bin/false –D –H fetchmail
*(from redmine: issue id 126, created on 2009-08-09, closed on 20...“acf-fetchmail-0.4.0-r0” does not create the user “fetchmail”
‘fetchmail’ user should be manually created.
adduser –h /var/lib/fetchmail –s /bin/false –D –H fetchmail
*(from redmine: issue id 126, created on 2009-08-09, closed on 2009-08-19)*
* Relations:
* duplicates #124
* Changesets:
* Revision bc93eaffb0fe5dcb053364244f660e78199987e1 by Timo Teräs on 2009-08-10T05:47:05Z:
```
db, pkg: fix package verification during installation
some hooks to package verification code were missing causing the
verification to not be done (causing pre-script to be not run).
fixes #124, #126.
```https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/5074setup script network interface misnaming in lxc container2019-07-14T07:49:46ZAndrej Surkovsetup script network interface misnaming in lxc containeron CentOS 7 in lxc container scripts take wrong network interface name
eth0@if21 instead of plain eth0, see below output in Alpine lxc guest
shell, and ip address setup fails
ffcrm:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER\_UP>mtu 65536...on CentOS 7 in lxc container scripts take wrong network interface name
eth0@if21 instead of plain eth0, see below output in Alpine lxc guest
shell, and ip address setup fails
ffcrm:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER\_UP>mtu 65536 qdisc noqueue state
UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid\_lft forever preferred\_lft forever
inet6 ::1/128 scope host
valid\_lft forever preferred\_lft forever
20: eth0@if21: <BROADCAST,MULTICAST,UP,LOWER\_UP,M-DOWN>mtu 1500
qdisc pfifo\_fast state UP qlen 1000
link/ether fe:a6:2b:33:cd:59 brd ff:ff:ff:ff:ff:ff
inet 10.74.58.3/24 scope global eth0
valid\_lft forever preferred\_lft forever
inet6 fe80::fca6:2bff:fe33:cd59/64 scope link
valid\_lft forever preferred\_lft forever
*(from redmine: issue id 5074, created on 2016-02-05)*Andrej SurkovAndrej Surkovhttps://gitlab.alpinelinux.org/alpine/awall/-/issues/2247/var/run/awall gets lost at next reboot (causing awall to fail)2019-07-14T07:55:50ZMika Havela/var/run/awall gets lost at next reboot (causing awall to fail)Having this issue using awall on a HDD installed Alpine (Alpine 2.6.4 /
awall-0.3.2-r0).
When installing awall I get the dir /var/run/awall (everything is fine
at this moment).
But at next reboot, the dir is gone (and therefore awall ...Having this issue using awall on a HDD installed Alpine (Alpine 2.6.4 /
awall-0.3.2-r0).
When installing awall I get the dir /var/run/awall (everything is fine
at this moment).
But at next reboot, the dir is gone (and therefore awall will fail to
start).
A way to fix this is to run ‘apk fix awall’ after each reboot.
*(from redmine: issue id 2247, created on 2013-09-05, closed on 2013-10-01)*
* Changesets:
* Revision 4313b0b6af5dbc79fd777ddaf52762f183259c20 by Kaarle Ritvanen on 2013-09-11T07:56:59Z:
```
create /var/run/awall directory at run-time
fixes #2247
```Kaarle RitvanenKaarle Ritvanenhttps://gitlab.alpinelinux.org/alpine/docker-abuild/-/issues/51Clarify dabuild multi arch support2019-12-29T18:28:53ZCarlo LandmeterClarify dabuild multi arch supportIt looks to me that only docker on MacOS can support multi-arch as can be read here:
https://docs.docker.com/docker-for-mac/multi-arch/
This makes it easy to run dabuild for a different arch with qemu emulation (its slow but it would...It looks to me that only docker on MacOS can support multi-arch as can be read here:
https://docs.docker.com/docker-for-mac/multi-arch/
This makes it easy to run dabuild for a different arch with qemu emulation (its slow but it would work).
I have tried this on Docker on Linux but it doesnt seem to work in the same way. I can also not find any reference for multi-arch for other platforms except the link above. https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/issues/25If a MR has APKBUILDs with different maintainers, allow all the maintainers o...2023-08-27T18:12:24ZAnjandev MomiIf a MR has APKBUILDs with different maintainers, allow all the maintainers of the packages to approve the MRhttps://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/33792#note_233120https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/33792#note_233120https://gitlab.alpinelinux.org/alpine/aports/-/issues/36"Sign In" page is not protected with SSL2019-07-12T14:22:30Ziilluzion _"Sign In" page is not protected with SSLUser *credentials* are being transfered in *clear* text. It may lead to
*leaking* of *sensitive* information and therefore potentially to an
*unauthorized access* to this site.
*(from redmine: issue id 36, created on 2009-05-21, closed...User *credentials* are being transfered in *clear* text. It may lead to
*leaking* of *sensitive* information and therefore potentially to an
*unauthorized access* to this site.
*(from redmine: issue id 36, created on 2009-05-21, closed on 2011-11-22)*Carlo LandmeterCarlo Landmeter2009-05-28https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/709Test 22019-07-12T16:14:49ZalgitbotTest 2Testing from unregistered account
Jeff
*(from redmine: issue id 709, created on 2011-07-14, closed on 2011-07-14)*Testing from unregistered account
Jeff
*(from redmine: issue id 709, created on 2011-07-14, closed on 2011-07-14)*https://gitlab.alpinelinux.org/alpine/abuild/-/issues/4998abuild may try to compress manpages several times2019-07-14T07:26:18ZTimo Teräsabuild may try to compress manpages several timesSee bug \#4991 that shows how abuild tried to compess certain man files
multiple times.
The problem is likely in the code finding the man pages:
[ -d "$mandir" ] && find "$subpkgdir"/usr/share/man \
-typ...See bug \#4991 that shows how abuild tried to compess certain man files
multiple times.
The problem is likely in the code finding the man pages:
[ -d "$mandir" ] && find "$subpkgdir"/usr/share/man \
-type f \( -name \*.[0-9n] -o -name \*.[0-9][a-z]* \) \
-exec stat -c "%i %n" {} \; | sort -n \
| while read inode name; do
And the fact that the compression is done in-place. It seems find can
start to find the newly created compressed files when the number of man
pages is large. This probably depends also on the filesystem being used.
Root cause seems to be that the filter:
-name \*.[0-9][a-z]*
matches \*.gz
*(from redmine: issue id 4998, created on 2016-01-08, closed on 2017-05-19)*
* Relations:
* relates #4991Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/127apk warns if /etc/apk/repositories contains empty lines2019-07-14T07:26:49ZNatanael Copaapk warns if /etc/apk/repositories contains empty linesIf there are empty lines in /etc/apk/reposiories there comes warnings
like:
`WARNING: Failed to open index for`
Apk should just ignore empty lines.
*(from redmine: issue id 127, created on 2009-08-11, closed on 2009-08-19)*
* Chang...If there are empty lines in /etc/apk/reposiories there comes warnings
like:
`WARNING: Failed to open index for`
Apk should just ignore empty lines.
*(from redmine: issue id 127, created on 2009-08-11, closed on 2009-08-19)*
* Changesets:
* Revision 6dd59d781717bae02cba5c886afb29bfa22b33aa on 2009-08-11T09:22:12Z:
```
db: ignore empty lines in /etc/apk/repositories
fixes #127
```https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/5975setup-alpine exits sys install because missing packages2021-01-06T16:48:13ZKarma Kolaborsetup-alpine exits sys install because missing packagessetup-alpine exits with an unsatisfiable constraint error when trying to
do a sys setup:
e2fsprogs (missing):
required by: world[e2fsprogs]
sfdisk (missing):
required by: world[sfdisk]
syslinux (missing):
req...setup-alpine exits with an unsatisfiable constraint error when trying to
do a sys setup:
e2fsprogs (missing):
required by: world[e2fsprogs]
sfdisk (missing):
required by: world[sfdisk]
syslinux (missing):
required by: world[syslinux]
seems like the setup for this iso was not tested with the sys option.
*(from redmine: issue id 5975, created on 2016-07-27)*https://gitlab.alpinelinux.org/alpine/awall/-/issues/2263netbios-ns and ip6tables2019-07-14T07:55:53ZNatanael Copanetbios-ns and ip6tableswhen i add a service ‘netbios-ns’ awall activate fails with this error:
# awall activate
ip6tables-restore: line 112 failed
/usr/share/lua/5.1/awall/iptables.lua:67: assertion failed!
stack traceback:
/usr/sh...when i add a service ‘netbios-ns’ awall activate fails with this error:
# awall activate
ip6tables-restore: line 112 failed
/usr/share/lua/5.1/awall/iptables.lua:67: assertion failed!
stack traceback:
/usr/share/lua/5.1/awall/uerror.lua:20: in function </usr/share/lua/5.1/awall/uerror.lua:16>
[C]: in function 'assert'
/usr/share/lua/5.1/awall/iptables.lua:67: in function 'restore'
/usr/share/lua/5.1/awall/iptables.lua:81: in function 'activate'
/usr/share/lua/5.1/awall/init.lua:162: in function 'f'
/usr/share/lua/5.1/awall/uerror.lua:15: in function </usr/share/lua/5.1/awall/uerror.lua:15>
[C]: in function 'xpcall'
/usr/share/lua/5.1/awall/uerror.lua:14: in function 'call'
/usr/sbin/awall:281: in function 'f'
/usr/share/lua/5.1/awall/uerror.lua:15: in function </usr/share/lua/5.1/awall/uerror.lua:15>
[C]: in function 'xpcall'
/usr/share/lua/5.1/awall/uerror.lua:14: in function 'call'
/usr/sbin/awall:124: in main chunk
[C]: ?
removing ‘netbios-ns’ makes it work.
*(from redmine: issue id 2263, created on 2013-09-27, closed on 2013-10-02)*Kaarle RitvanenKaarle Ritvanenhttps://gitlab.alpinelinux.org/alpine/docker-abuild/-/issues/22Check that $REPODEST is writeable2019-05-29T17:55:10ZRasmus Thomsenoss@cogitri.devCheck that $REPODEST is writeableI guess this might fall under user error, but it'd be nice if dabuild checked that `REPODEST` (from abuild.conf) is writable.I guess this might fall under user error, but it'd be nice if dabuild checked that `REPODEST` (from abuild.conf) is writable.