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
Description: OpenPGP digital signature
_______________________________________________ Adélie Development mailing list -- firstname.lastname@example.org To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org