On 02/12/18 08:13, William Pitcock wrote:
On Sun, Feb 11, 2018 at 3:27 PM, A. Wilcox
<awilfox(a)adelielinux.org> wrote:
> rsync:
>
> We enable xattr support via attr-dev. We split -openrc out. We also
> have the test suite working correctly.
Let's upstream.
[adelie-integration 2a33591ed7] main/rsync: add xattr support, check,
split -openrc
1 file changed, 12 insertions(+), 5 deletions(-)
> sdl:
>
> We enable NLS.
Let's upstream assuming $subpkg-lang is present.
This is vaguely hilarious.
I just blindly changed --disable-nls to --enable-nls and built it.
Turns out, whoever packaged it before me blindly wrote --disable-nls.
SDL does not have any NLS functions. Neither option does anything.
Binaries all hash the same with either one.
So I removed that errant line entirely.
[adelie-integration c2237f2b37] main/sdl: modernise, fix license, mark
no tests
1 file changed, 10 insertions(+), 21 deletions(-)
> syslinux:
>
> We do not use mkinitfs so we need to move this to system/ if we do not
> fork aports.git.
I'm not sure a good solution here. I guess we carry it in system/
Done.
> util-linux:
>
> In addition to Python 2->3 we enable partx, mesg, write, and wall, which
> are requirements of POSIX but disabled by Alpine for being unnecessary
> bloat. This is almost certainly going to need to moved to system/ if we
> don't fork.
Perhaps a util-linux-extra?
> v4l-utils:
>
> We are using the better-maintained Qt5 port of V4L, which again, needs
> the Qt5 packages that are only in community/. I may suggest to Alpine
> to move v4l-utils to community/ anyway; then our changes could be
> upstreamed.
We should see if it can be moved to community.
I'm considering making a mail to alpine-devel with all the packages we
think should be moved to community. If you think that's a good idea
I'll go ahead and do that.
> vim:
>
> We ship a default vimrc. This will have to move to system/.
>
>
> wpa_supplicant:
>
> We depend on D-Bus for KDE integration.
D-Bus support is present in wpa_supplicant already, so all we need is
to ship a modified init script, right?
--- /usr/src/alpine-aports/main/wpa_supplicant/APKBUILD 2018-02-12
17:13:15.059166429 -0600
+++ /usr/src/adelie-aports/main/wpa_supplicant/APKBUILD 2017-10-18
07:35:34.525598215 -0500
@@ -7,8 +7,9 @@
url="https://w1.fi/wpa_supplicant/"
arch="all"
license="BSD"
-subpackages="$pkgname-doc"
-makedepends="linux-headers libressl-dev dbus-dev libnl3-dev pcsc-lite-dev"
+subpackages="$pkgname-doc $pkgname-openrc"
+depends="dbus"
+makedepends="linux-headers openssl-dev dbus-dev libnl3-dev pcsc-lite-dev"
This and dropping the libressl patch are the only differences. I
believe the explicit depends= was there for dbus-launch? Maybe that is
no longer neccessary. I really do not know.
> xf86-video-ati:
>
> We disable GLAMOR extensions in our driver. I don't remember why or
> what issue that solves. If there's no good reason to do that, we can
> just use the upstream xf86-video-ati package.
>
>
> xfsprogs:
>
> We ship patches that don't apply to the new version. If they are
> unnecessary, we can simply ship the Alpine 4.14.0. Otherwise, we need
> to port them to 4.14.0.
We should probably test both of these.
It looks like our disabling GLAMOR was a holdover from X 1.17 where it
could break GCN chips using DRI3. This is fixed in 1.18.3, so it should
be fine.
xfsprogs built, so I'm going to consider that as fine to ship as it
stands in Alpine.
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org