Hello,
On Mon, Feb 12, 2018 at 5:41 PM, A. Wilcox <awilfox(a)adelielinux.org> wrote:
> 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(-)
Thank you for both of these.
>>> 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.
Yes, go ahead.
>>> 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
> _at__at_ -7,8 +7,9 _at__at_
> 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.
I believe we actually need depends=dbus-x11 for dbus-launch.
>>> 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.
Okay, that sounds good to me.
William
Received on Tue Feb 13 2018 - 15:17:11 UTC