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.

https://code.foxkit.us/adelie/aports/commit/53c43166

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
point.


>> 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
applied:

-               --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 ;)


Best,
--arw

-- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org

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