[adelie-devel] Re: main/ -> system/ + user/ vs aports.git fork [1]
On 02/11/18 14:00, A. Wilcox wrote: > 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/. Wrong. It's released in May, and the patch is for 0.26 itself. I meant 0.27. Anyway, I feel since it is a simple patch and it fixes an actual issue, it should just be upstreamed now. So this is done. [adelie-integration 687531e2ea] main/exiv2: bump to 0.26, modernise, mark no tests 4 files changed, 106 insertions(+), 50 deletions(-) --arw -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org 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
[adelie-devel] Re: main/ -> system/ + user/ vs aports.git fork [1]
On 02/11/18 22:38, Horst G. Burkhardt wrote: > On Sun, 11 Feb 2018 14:00:15 -0600 > "A. Wilcox" wrote: > >> bash: > > I'd actually like to see dash moved into system to provide /bin/sh - > but that notwithstanding, the patch to make bash use bashrc properly > and our own bashrc are a good enough reason to keep our own bash in > system/ ... dash is already in system via Alpine main. It's certainly possible to provide /bin/sh using dash, but I'm not sure if that is well advised. I suppose we could offer the option to advanced users, but I'm not sure we should make it all that obvious that one can do it. Best, --arw -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org 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
[adelie-devel] Re: main/ -> system/ + user/ vs aports.git fork [1]
On Sun, 11 Feb 2018 14:00:15 -0600 "A. Wilcox" wrote: > bash: > > We have the -binsh virtual, the patch for bashrc location, and our own > bashrc file. None of these make sense for upstream. Unless I hear a > good argument for offering it in user/, I'm pretty sure this should be > in system/. I'd actually like to see dash moved into system to provide /bin/sh - but that notwithstanding, the patch to make bash use bashrc properly and our own bashrc are a good enough reason to keep our own bash in system/ ... > binutils: > > We ship 2.29 instead of 2.28. We ship seven patches for everything > from tests to wrong behaviour with MIPS targets. ncopa did not seem > interested in bumping binutils until GCC is also bumped. This could > be moved to system/ since we are already maintaining it ourselves. > 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. I support binutils and gcc going into our system/ - especially since we're supporting different platforms from Alpine and those may have technical demands of their own. As for the rest, I defer judgement to people who know what they're doing - the sooner we get alpha5 going and this grand unification done, the sooner i get community/emacs and can actually work on things comfortably :) Regards, - Horst ___ Adélie Development mailing list -- adelie-devel@lists.adelielinux.org To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org
[adelie-devel] Re: main/ -> system/ + user/ vs aports.git fork [1]
On 02/11/18 18:03, Max Rees wrote: > On Feb 11 05:54 PM, A. Wilcox wrote: >> We even still have the archive of Gentoo-based ebuilds, in case we need >> them: https://code.foxkit.us/adelie/packages/tree/ebuild > > In my opinion these should be removed from packages.git and put in a > separate archive as well, unless it's something that you refer to often. We have not yet finished migrating all the packages out of that to the user/ repository. At that time, we likely will. (As it stands, horst@ is the only person I know who managed to build BasiliskII for musl.) >> As someone who *uses* three of those plugins on my own system, I would >> be very disappointed to have to give them up. But I don't want to have >> to maintain ffmpeg, and I don't think I could track their releases. >> Does anyone else want to? > > If nobody else steps up I can do this possibly. I'll keep that in mind. >> I'm not seeing visual artifacts anywhere, on my desktop 21" wide-screen >> flat panel monitor, my laptop 13" panel, or my 17" CRT. Is it only in >> some software or does it affect all X clients? Maybe start a new thread >> about that. > > It was mostly firefox-esr I believe. Once alpha5 is released I will test > again and report the results. Sounds like a plan. Best, --arw -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org 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
[adelie-devel] Re: main/ -> system/ + user/ vs aports.git fork [1]
On 02/11/18 17:52, William Pitcock wrote: > Hello, > > On Sun, Feb 11, 2018 at 2:00 PM, A. Wilcox 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 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
[adelie-devel] Re: main/ -> system/ + user/ vs aports.git fork [1]
On Feb 11 05:54 PM, A. Wilcox wrote: > We even still have the archive of Gentoo-based ebuilds, in case we need > them: https://code.foxkit.us/adelie/packages/tree/ebuild In my opinion these should be removed from packages.git and put in a separate archive as well, unless it's something that you refer to often. > As someone who *uses* three of those plugins on my own system, I would > be very disappointed to have to give them up. But I don't want to have > to maintain ffmpeg, and I don't think I could track their releases. > Does anyone else want to? If nobody else steps up I can do this possibly. > I'm not seeing visual artifacts anywhere, on my desktop 21" wide-screen > flat panel monitor, my laptop 13" panel, or my 17" CRT. Is it only in > some software or does it affect all X clients? Maybe start a new thread > about that. It was mostly firefox-esr I believe. Once alpha5 is released I will test again and report the results. Max ___ Adélie Development mailing list -- adelie-devel@lists.adelielinux.org To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org
[adelie-devel] Re: main/ -> system/ + user/ vs aports.git fork [1]
On Sun, Feb 11, 2018 at 4:21 PM, Max Rees wrote: > On Feb 11 02:00 PM, A. Wilcox wrote: >> Currently we have a "fork" of aports.git. It's very difficult to rebase >> what we have, so it definitely needs to "restart" imo. We can move >> aports.git to aports-historic.git and then re-clone from Alpine to make >> it cleaner, but I think the better thing is to pull all the packages >> that we want to keep different from Alpine and put them in system/ in >> packages.git, leaving our aports.git fork strictly for changes we wish >> to upstream. > > This makes sense to me. I was concerned about what would happen to the > old repo, so archiving it seems like a good idea. > >> audacious (and audacious-plugins): >> >> We are shipping the Qt variant. Alpine are shipping the Gtk variant. >> Since Alpine doesn't have Qt5 in main/ we unfortunately cannot upstream >> this change. We could rename it audacious-qt and ship it in user/, >> where even Alpine users could enjoy it, but it would need a maintainer. > > audacious-qt is probably the better choice. Gentoo also calls it > audacious-qt, so there is some precedent. > >> ffmpeg: >> >> We enable a LOT more plugins: libcdio, ladspa, lzma, libspeex, freetype, >> wavpack, libwebp, and pulseaudio output support. Almost none of those >> are in Alpine main/ so it is impossible to add them to ffmpeg >> dependencies upstream. I really don't want to maintain ffmpeg myself >> since it is a frequent security flyer; if someone else wants to maintain >> it in system/ then that is fine. As someone who *uses* three of those >> plugins on my own system, > > I think you forgot to finish this part. > >> freetype: >> >> Our freetype-profile.sh differs (we enable infinality by default). We >> have no other changes. Alpine upstream temporarily did re-enable >> infinality by default, but they did not like it (I believe there was >> some bug in their XFCE 4 maybe?) so they reverted it. > > There is something weird going on with the LCD filtering such that only > "lcdnone" is usable on Adélie last time I tried, and even then there are > still some visual artifacts. I'm not sure if this is related to > infinality or not but it's worth investigating. I believe this is why infinality is disabled on Alpine, there are problems with gtk+2. William ___ Adélie Development mailing list -- adelie-devel@lists.adelielinux.org To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org
[adelie-devel] Re: main/ -> system/ + user/ vs aports.git fork [1]
On 02/11/18 16:21, Max Rees wrote: > On Feb 11 02:00 PM, A. Wilcox wrote: >> We can move >> aports.git to aports-historic.git > > This makes sense to me. I was concerned about what would happen to the > old repo, so archiving it seems like a good idea. We even still have the archive of Gentoo-based ebuilds, in case we need them: https://code.foxkit.us/adelie/packages/tree/ebuild >> audacious (and audacious-plugins): > audacious-qt is probably the better choice. Gentoo also calls it > audacious-qt, so there is some precedent. Okay, I will move that over to user/ soon-ish. >> ffmpeg: >> >> We enable a LOT more plugins: libcdio, ladspa, lzma, libspeex, freetype, >> wavpack, libwebp, and pulseaudio output support. Almost none of those >> are in Alpine main/ so it is impossible to add them to ffmpeg >> dependencies upstream. I really don't want to maintain ffmpeg myself >> since it is a frequent security flyer; if someone else wants to maintain >> it in system/ then that is fine. As someone who *uses* three of those >> plugins on my own system, > > I think you forgot to finish this part. As someone who *uses* three of those plugins on my own system, I would be very disappointed to have to give them up. But I don't want to have to maintain ffmpeg, and I don't think I could track their releases. Does anyone else want to? >> freetype: > > There is something weird going on with the LCD filtering such that only > "lcdnone" is usable on Adélie last time I tried, and even then there are > still some visual artifacts. I'm not sure if this is related to > infinality or not but it's worth investigating. I'm not seeing visual artifacts anywhere, on my desktop 21" wide-screen flat panel monitor, my laptop 13" panel, or my 17" CRT. Is it only in some software or does it affect all X clients? Maybe start a new thread about that. > The rest of your proposals make sense to me. Now we just have to find willing maintainers for the packages that need them. :) Best, --arw -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org 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
[adelie-devel] Re: main/ -> system/ + user/ vs aports.git fork [1]
Hello, On Sun, Feb 11, 2018 at 2:00 PM, A. Wilcox wrote: > Currently we have a "fork" of aports.git. It's very difficult to rebase > what we have, so it definitely needs to "restart" imo. We can move > aports.git to aports-historic.git and then re-clone from Alpine to make > it cleaner, but I think the better thing is to pull all the packages > that we want to keep different from Alpine and put them in system/ in > packages.git, leaving our aports.git fork strictly for changes we wish > to upstream. > > Of course, since we can no longer merge in upstream changes, we would > therefore be tracking all the updates ourselves. This is why I would > like to be conservative. > > These are the packages with changes that, for whatever reason, we cannot > merge upstream to Alpine. We should discuss what to do with them. > > > audacious (and audacious-plugins): > > We are shipping the Qt variant. Alpine are shipping the Gtk variant. > Since Alpine doesn't have Qt5 in main/ we unfortunately cannot upstream > this change. We could rename it audacious-qt and ship it in user/, > where even Alpine users could enjoy it, but it would need a maintainer. 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. > bash: > > We have the -binsh virtual, the patch for bashrc location, and our own > bashrc file. None of these make sense for upstream. Unless I hear a > good argument for offering it in user/, I'm pretty sure this should be > in system/. > > > binutils: > > We ship 2.29 instead of 2.28. We ship seven patches for everything from > tests to wrong behaviour with MIPS targets. ncopa did not seem > interested in bumping binutils until GCC is also bumped. This could be > moved to system/ since we are already maintaining it ourselves. > > > busybox: > > We have an /sbin/init virtual. I added busybox as a provider. > Honestly, this was primarily for Alpine's benefit. Since they don't > have a reason to ship a /sbin/init virtual I think this change can be > discarded; if anyone wants to use busybox as /sbin/init, please speak up > now. 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. > 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. > 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. > 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. > ffmpeg: > > We enable a LOT more plugins: libcdio, ladspa, lzma, libspeex, freetype, > wavpack, libwebp, and pulseaudio output support. Almost none of those > are in Alpine main/ so it is impossible to add them to ffmpeg > dependencies upstream. I really don't want to maintain ffmpeg myself > since it is a frequent security flyer; if someone else wants to maintain > it in system/ then that is fine. As someone who *uses* three of those > plugins on my own system, We should probably check this to make sure that we're not shipping anything that violates patents. > freetype: > > Our freetype-profile.sh differs (we enable infinality by default). We > have no other changes. Alpine upstream temporarily did re-enable > infinality by default, but they did not like it (I believe there was > some bug in their XFCE 4 maybe?) so they reverted it. > > > 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. William ___ Adélie Development mailing list -- adelie-devel@lists.adelielinux.org To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org
[adelie-devel] Re: main/ -> system/ + user/ vs aports.git fork [1]
On Feb 11 02:00 PM, A. Wilcox wrote: > Currently we have a "fork" of aports.git. It's very difficult to rebase > what we have, so it definitely needs to "restart" imo. We can move > aports.git to aports-historic.git and then re-clone from Alpine to make > it cleaner, but I think the better thing is to pull all the packages > that we want to keep different from Alpine and put them in system/ in > packages.git, leaving our aports.git fork strictly for changes we wish > to upstream. This makes sense to me. I was concerned about what would happen to the old repo, so archiving it seems like a good idea. > audacious (and audacious-plugins): > > We are shipping the Qt variant. Alpine are shipping the Gtk variant. > Since Alpine doesn't have Qt5 in main/ we unfortunately cannot upstream > this change. We could rename it audacious-qt and ship it in user/, > where even Alpine users could enjoy it, but it would need a maintainer. audacious-qt is probably the better choice. Gentoo also calls it audacious-qt, so there is some precedent. > ffmpeg: > > We enable a LOT more plugins: libcdio, ladspa, lzma, libspeex, freetype, > wavpack, libwebp, and pulseaudio output support. Almost none of those > are in Alpine main/ so it is impossible to add them to ffmpeg > dependencies upstream. I really don't want to maintain ffmpeg myself > since it is a frequent security flyer; if someone else wants to maintain > it in system/ then that is fine. As someone who *uses* three of those > plugins on my own system, I think you forgot to finish this part. > freetype: > > Our freetype-profile.sh differs (we enable infinality by default). We > have no other changes. Alpine upstream temporarily did re-enable > infinality by default, but they did not like it (I believe there was > some bug in their XFCE 4 maybe?) so they reverted it. There is something weird going on with the LCD filtering such that only "lcdnone" is usable on Adélie last time I tried, and even then there are still some visual artifacts. I'm not sure if this is related to infinality or not but it's worth investigating. The rest of your proposals make sense to me. Max ___ Adélie Development mailing list -- adelie-devel@lists.adelielinux.org To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org
