Hello,

On Mon, Feb 12, 2018 at 5:41 PM, A. Wilcox <awil...@adelielinux.org> wrote:
> On 02/12/18 08:13, William Pitcock wrote:
>> On Sun, Feb 11, 2018 at 3:27 PM, A. Wilcox <awil...@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
> @@ -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.

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
_______________________________________________
Adélie Development mailing list -- adelie-devel@lists.adelielinux.org
To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org

Reply via email to