On 02/11/18 17:52, William Pitcock wrote:
> Hello,
> On Sun, Feb 11, 2018 at 2:00 PM, A. Wilcox <awil...@adelielinux.org> wrote:
>> audacious (and audacious-plugins):
> I am more in favour of moving audacious to community, I just haven't
> done it yet.  But, Alpine ships a GTK+ desktop instead of a Qt one.

That's fine, but we still need audacious-qt.  You can't build both kinds
in the same tree (I tried, it was a mess).  That can go in user/ unless
you are suggesting that go in Alpine community/ (either would be fine
with me).

>> busybox:
>> We have an /sbin/init virtual.  I added busybox as a provider.
> We may want to keep this for Adelie Core, as we will probably ship
> busybox userland anyway in that case.  But we may wind up just using
> s6 as the init system there, so I don't know for sure.

We'll need to have our own busybox package in system/, unless this
/sbin/init provider is being upstreamed.  And it doesn't make sense for
Alpine because Alpine don't ship sysvinit (or other /sbin/init providers).

>> check:
>> They have a checkdepends of gawk which is satisfied by our mawk.  Very
>> annoying as I don't want to ship gawk at all, but I suppose we can live
>> with it if it means we don't have to fork.
> We could use a virtual here instead.

I had thought about cmd:awk, but wouldn't busybox provide that?

>> coreutils:
>> We have a bunch of hacks to support cross-compile, and a 32-bit PowerPC
>> patch.  They don't release very often so I am fine with moving this to
>> system/.
> I am okay with upstreaming this.

Trust me, you aren't.  You really, really aren't.


It uses conditionals for sha512sum and source and it is the worst
ugliest hack in all of aports.  You really don't want this upstreamed.

I had forgotten that the 32-bit PowerPC patch was upstreamed in 8.28 so
we don't actually ship that any more.

>> exiv2:
>> We are tracking 0.26 which is not yet released on their official site
>> because it includes fixes for big-endian that are irrelevant to Alpine.
>> I know the maintainers personally and I am fine with maintaining this
>> myself in system/.
> Technically, s390x is big-endian but I doubt anyone is using exiv2 there.

It is only relevant if you are also processing metadata on a separate
thread.  I only ran in to it when Dolphin was thumbnailing a Pictures
directory with thousands of JPEGs.  It is very unlikely that someone is
doing such on s390x, and anyway, when 0.26 is released it will be a moot

>> ffmpeg:
> We should probably check this to make sure that we're not shipping
> anything that violates patents.

I disabled all the mp4 stuff that didn't explicitly have a patent waiver

-               --enable-libx264 \

The x265 stuff actually does have a patent waiver until "more than
250,000 copies are in use".  I figure by that time it won't be a big
deal to give them their 10 cents per seat, especially since ffmpeg is
not included by default in the installation.

(This does raise a separate concern of the fact that we need a popcon
like system not only for research but for stuff like that.  That will be
another thread, probably in -project.)

>> gcc:
>> Our gcc is wildly different from Alpine, so much so that this probably
>> belongs in system/ even if we do end up keeping an aports.git fork.  In
>> addition, I don't feel comfortable with jumping to GCC 8 and Alpine has
>> been talking about it for retpoline support.  This is going in system/
>> unless someone has a very good argument why it shouldn't.
> It is complicated.  I would prefer to have a gcc6 package for GCC 6
> and a separate package for GCC 8.  Shipping GCC 8 is necessary for
> risc-v, which I am marginally interested in.  Ideally, this is
> something we would work with Alpine on.

I don't have a problem with having gcc8 for a RISC-V target only,
because the hardware itself is still new and would have the potential
for issues just as GCC 8 does.  Since GCC 8 changes ABI for PA-RISC as
well, if we ever target that we should probably use GCC 8 there as well.

There are serious regressions in LTO when -g is passed, and SIMD
multiplication on aarch64 generates wrong code with any -O not 0
(multiple prs filed on this, maybe it will get fixed).  In the same way
6.0 made me nervous until 6.3, 8 is shaping up to be similar.  And I
have this feeling Alpine will be moving to 8 far before 8.3 ;)


A. Wilcox (awilfox)
Project Lead, Adélie Linux

Attachment: signature.asc
Description: OpenPGP digital signature

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