One of the main issues that is holding back musl use in gentoo is the lack of browsers on gentoo/musl. I'm not much of a coder (my skills are quite limited), so can't do much on this. SJLC could work on this, but for that to happen we need donations. Alternatively, other musl developers can help on this issue. I posted a request to integrate a firefox and chromium script to gentoo/musl, see https://github.com/gentoo/musl/pull/296 ,but they're outdated so need to be improved before the pull would be accepted. Any coding help from musl members would be appreciated. Also, we would like to integrate the possibility of musl compilation with the palemoon browser, but again, we need donations for this. The palemoon browser (under musl) is already being used in our own musl distro (TAZ), but we need to integrate the musl compilation directly into the browser to make the whole process easier (ie also for developing new TAZ releases). Donations are welcome at https://github.com/Sharrisii/TAZ (sponsor button).
[-- Attachment #1.1: Type: text/plain, Size: 2694 bytes --] On 14/02/2020 06:12, Brian Peregrine wrote: > One of the main issues that is holding back musl use in gentoo is the > lack of browsers on gentoo/musl. > > I'm not much of a coder (my skills are quite limited), so can't do much on this. > SJLC could work on this, but for that to happen we need donations. > Alternatively, other musl developers can help on this issue. > I posted a request to integrate a firefox and chromium script to > gentoo/musl, see https://github.com/gentoo/musl/pull/296 ,but they're > outdated so need to be improved before the pull would be accepted. Any > coding help from musl members would be appreciated. > > Also, we would like to integrate the possibility of musl compilation > with the palemoon browser, but again, we need donations for this. The > palemoon browser (under musl) is already being used in our own musl > distro (TAZ), but we need to integrate the musl compilation directly > into the browser to make the whole process easier (ie also for > developing new TAZ releases). Donations are welcome at > https://github.com/Sharrisii/TAZ (sponsor button). Adélie has been very active in making a Firefox build that works properly on musl on all the supported architectures. (We haven't yet tested MIPS or RISC-V.) The patches and build recipe are available in our Git at: https://code.foxkit.us/adelie/packages/tree/master/user/firefox-esr We are also working on making the latest development branches of Qt WebKit function properly on musl. Since it is a Git snapshot, it isn't working perfectly, but our in-progress patchset is at: https://code.foxkit.us/adelie/packages/tree/master/user/qt5-qtwebkit The Adélie team would also appreciate any donations you can afford. We work very hard every day to improve the state of the art, and work with upstreams and software authors to try to obviate the need to patch software to work on musl at all :) https://www.adelielinux.org/contribute.html On the other paw, there is one Chromium patchset that I'm aware of that attempts to make it work on musl and has people actually experienced in this type of porting work involved. It is slightly outdated - by 8 months - which isn't much for most software, but is an eternity for Google software. For security and privacy reasons I do not recommend usage of Chromium, but if you feel especially brave, the patchset is at: https://github.com/smaeul/portage-overlay/blob/master/www-client/chromium/ Hope this helps your endeavours to bring different browsers to your musl distribution(s). Best, --arw -- A. Wilcox (awilfox) Project Lead, Adélie Linux https://www.adelielinux.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --]
Recently, I've been spending some time writing upstreamable patches for long standing musl incompatibilities in Firefox (and the parts it imports from chromium), and pushing to get them fixed finally. So far, I've had some good success: https://hg.mozilla.org/mozilla-central/rev/1acc873aa118 https://hg.mozilla.org/mozilla-central/rev/660da1ec99c0 https://hg.mozilla.org/mozilla-central/rev/3ec8c96f4d53 https://hg.mozilla.org/mozilla-central/rev/7c6f9f854cfc https://hg.mozilla.org/mozilla-central/rev/a3096ca24124 All but the last one should be available in the next Firefox release (74). I believe the last remaining remaining issue is usage of getcontext in tools/profiler. I've just filed a bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1615713. I have a couple ideas for a fix (outlined in that bug), but haven't written a patch yet. If anyone has suggestions, please let me know! In one of the reviews, the reviewer mentioned about the existence of build target support tiers: https://developer.mozilla.org/en-US/docs/Mozilla/Supported_build_configurations I was thinking that once Firefox can build with musl out of the box, it would be really great to see if we can get Mozilla to consider musl to be a Tier 3 target (at least x86_64), so we can avoid any musl regressions in the future. -Michael
On Fri, Feb 14, 2020 at 12:51:25PM -0800, Michael Forney wrote:
> Recently, I've been spending some time writing upstreamable patches
> for long standing musl incompatibilities in Firefox (and the parts it
> imports from chromium), and pushing to get them fixed finally.
>
> So far, I've had some good success:
> https://hg.mozilla.org/mozilla-central/rev/1acc873aa118
> https://hg.mozilla.org/mozilla-central/rev/660da1ec99c0
> https://hg.mozilla.org/mozilla-central/rev/3ec8c96f4d53
> https://hg.mozilla.org/mozilla-central/rev/7c6f9f854cfc
> https://hg.mozilla.org/mozilla-central/rev/a3096ca24124
>
> All but the last one should be available in the next Firefox release (74).
>
> I believe the last remaining remaining issue is usage of getcontext in
> tools/profiler. I've just filed a bug at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1615713. I have a couple
> ideas for a fix (outlined in that bug), but haven't written a patch
> yet. If anyone has suggestions, please let me know!
>
> In one of the reviews, the reviewer mentioned about the existence of
> build target support tiers:
> https://developer.mozilla.org/en-US/docs/Mozilla/Supported_build_configurations
>
> I was thinking that once Firefox can build with musl out of the box,
> it would be really great to see if we can get Mozilla to consider musl
> to be a Tier 3 target (at least x86_64), so we can avoid any musl
> regressions in the future.
There's a third-party libucontext that can be used with musl, but it's
nonconforming in that it doesn't save/restore signal mask. That
probably doesn't matter for their usage so it might make sense to just
build against that. (Have you checked what Alpine and Adélie and Void
are doing?)
Rich
[-- Attachment #1.1: Type: text/plain, Size: 1159 bytes --] On 14/02/2020 15:14, Rich Felker wrote: > On Fri, Feb 14, 2020 at 12:51:25PM -0800, Michael Forney wrote: >> I believe the last remaining remaining issue is usage of getcontext in >> tools/profiler. I've just filed a bug at >> https://bugzilla.mozilla.org/show_bug.cgi?id=1615713. I have a couple >> ideas for a fix (outlined in that bug), but haven't written a patch >> yet. If anyone has suggestions, please let me know! > There's a third-party libucontext that can be used with musl, but it's > nonconforming in that it doesn't save/restore signal mask. That > probably doesn't matter for their usage so it might make sense to just > build against that. (Have you checked what Alpine and Adélie and Void > are doing?) > > Rich > As far as I'm aware, all musl distributions disable the profiler because it doesn't work properly on musl. Michael's work would enable us to build it at all. For clarification, it does handle the signal mask, but only on PowerPC where the Linux kernel has a syscall specifically for ucontext. Best, --arw -- A. Wilcox (awilfox) Project Lead, Adélie Linux https://www.adelielinux.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #1.1: Type: text/plain, Size: 2144 bytes --] On 14/02/2020 14:51, Michael Forney wrote: > Recently, I've been spending some time writing upstreamable patches > for long standing musl incompatibilities in Firefox (and the parts it > imports from chromium), and pushing to get them fixed finally. > > So far, I've had some good success: > https://hg.mozilla.org/mozilla-central/rev/1acc873aa118 > https://hg.mozilla.org/mozilla-central/rev/660da1ec99c0 > https://hg.mozilla.org/mozilla-central/rev/3ec8c96f4d53 > https://hg.mozilla.org/mozilla-central/rev/7c6f9f854cfc > https://hg.mozilla.org/mozilla-central/rev/a3096ca24124 > > All but the last one should be available in the next Firefox release (74). > > I believe the last remaining remaining issue is usage of getcontext in > tools/profiler. I've just filed a bug at > https://bugzilla.mozilla.org/show_bug.cgi?id=1615713. I have a couple > ideas for a fix (outlined in that bug), but haven't written a patch > yet. If anyone has suggestions, please let me know! > > In one of the reviews, the reviewer mentioned about the existence of > build target support tiers: > https://developer.mozilla.org/en-US/docs/Mozilla/Supported_build_configurations > > I was thinking that once Firefox can build with musl out of the box, > it would be really great to see if we can get Mozilla to consider musl > to be a Tier 3 target (at least x86_64), so we can avoid any musl > regressions in the future. > > -Michael > Thank you so much for your work! Especially on Bug 1157850, that has been annoying me for quite a while. Most of our work has been on the Rust integration side, and also PowerPC (I believe mhoye added PowerPC to Tier 3 specifically because of the combined efforts of us and Fedora.) It would probably be best to tried and add musl as an "and" to the Tier 3 statement about the various architectures. This way it isn't specific to any one architecture nor maintainer, but rather a community effort from all interested people (you, us, Void, Alpine..) Best to you and yours, --arw -- A. Wilcox (awilfox) Project Lead, Adélie Linux https://www.adelielinux.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --]
I probably need to clarify the approach further. The idea is to have something (more precisely a script) which is intented specifically for gentoo (not all linux variants; not that the pull is to the gentoo/musl repo btw). Once that's ready, a binary can be made. Speaking for our own distro, it can be used on the optional usb stick (https://github.com/Sharrisii/TAZ_optional_usb_stick/tree/master/binaries ). I assume these binaries can then also be shared and used with non-gentoo based linux versions (if generic compiler flags are used, which is also the idea). Interested people can work on improving the files in the pull (https://github.com/gentoo/musl/pull/296 ) and then having these improvements added to the pull. Adelie's firefox-esr version is 68.5.0, jakeogh's version (in pull) is v.41 so Adelie's version is indeed newer. Current is v73, so still needs to be improved it further. So yes, you could already switch this in the pull. The binary I used of Adelie (v52.9.0-r4, back in June 2019) didn't work, and wasn't optimized for i686 cpu's (and also, Adelie linux is based on abuild system rather then gentoo's portage system), so I am somewhat cautious. That said, if the script is worked out further, there may be no issues. On 2/14/20, Brian Peregrine <peregrinebrian@gmail.com> wrote: > One of the main issues that is holding back musl use in gentoo is the > lack of browsers on gentoo/musl. > > I'm not much of a coder (my skills are quite limited), so can't do much on > this. > SJLC could work on this, but for that to happen we need donations. > Alternatively, other musl developers can help on this issue. > I posted a request to integrate a firefox and chromium script to > gentoo/musl, see https://github.com/gentoo/musl/pull/296 ,but they're > outdated so need to be improved before the pull would be accepted. Any > coding help from musl members would be appreciated. > > Also, we would like to integrate the possibility of musl compilation > with the palemoon browser, but again, we need donations for this. The > palemoon browser (under musl) is already being used in our own musl > distro (TAZ), but we need to integrate the musl compilation directly > into the browser to make the whole process easier (ie also for > developing new TAZ releases). Donations are welcome at > https://github.com/Sharrisii/TAZ (sponsor button). >
On Sat, Feb 15, 2020 at 03:20:08PM +0100, Brian Peregrine wrote:
> I probably need to clarify the approach further.
> The idea is to have something (more precisely a script) which is
> intented specifically for gentoo (not all linux variants; not that the
> pull is to the gentoo/musl repo btw). Once that's ready, a binary can
> be made. Speaking for our own distro, it can be used on the optional
> usb stick (https://github.com/Sharrisii/TAZ_optional_usb_stick/tree/master/binaries
> ). I assume these binaries can then also be shared and used with
> non-gentoo based linux versions (if generic compiler flags are used,
> which is also the idea).
>
> Interested people can work on improving the files in the pull
> (https://github.com/gentoo/musl/pull/296 ) and then having these
> improvements added to the pull.
>
> Adelie's firefox-esr version is 68.5.0, jakeogh's version (in pull) is
> v.41 so Adelie's version is indeed newer. Current is v73, so still
> needs to be improved it further. So yes, you could already switch this
> in the pull.
> The binary I used of Adelie (v52.9.0-r4, back in June 2019) didn't
> work, and wasn't optimized for i686 cpu's (and also, Adelie linux is
> based on abuild system rather then gentoo's portage system), so I am
> somewhat cautious. That said, if the script is worked out further,
> there may be no issues.
AIUI Adélie follows -esr for which 68 is latest; is that incorrect?
Alpine has 73 in the testing repo.
Rich
On Sat, 2020-02-15 at 12:29, Rich Felker wrote: > On Sat, Feb 15, 2020 at 03:20:08PM +0100, Brian Peregrine wrote: > > I probably need to clarify the approach further. > > The idea is to have something (more precisely a script) which is > > intented specifically for gentoo (not all linux variants; not that the > > pull is to the gentoo/musl repo btw). Once that's ready, a binary can > > be made. Speaking for our own distro, it can be used on the optional > > usb stick (https://github.com/Sharrisii/TAZ_optional_usb_stick/tree/master/binaries > > ). I assume these binaries can then also be shared and used with > > non-gentoo based linux versions (if generic compiler flags are used, > > which is also the idea). > > > > Interested people can work on improving the files in the pull > > (https://github.com/gentoo/musl/pull/296 ) and then having these > > improvements added to the pull. > > > > Adelie's firefox-esr version is 68.5.0, jakeogh's version (in pull) is > > v.41 so Adelie's version is indeed newer. Current is v73, so still > > needs to be improved it further. So yes, you could already switch this > > in the pull. > > The binary I used of Adelie (v52.9.0-r4, back in June 2019) didn't > > work, and wasn't optimized for i686 cpu's (and also, Adelie linux is > > based on abuild system rather then gentoo's portage system), so I am > > somewhat cautious. That said, if the script is worked out further, > > there may be no issues. > > AIUI Adélie follows -esr for which 68 is latest; is that incorrect? > Alpine has 73 in the testing repo. Alpine have both -esr in community and latest release (73.0) in testing. Though doesn't work on all architectures. > Rich
[-- Attachment #1.1: Type: text/plain, Size: 1743 bytes --] On 15/02/2020 08:20, Brian Peregrine wrote: > I probably need to clarify the approach further. > The idea is to have something (more precisely a script) which is > intented specifically for gentoo (not all linux variants; not that the > pull is to the gentoo/musl repo btw). Once that's ready, a binary can > be made. Speaking for our own distro, it can be used on the optional > usb stick (https://github.com/Sharrisii/TAZ_optional_usb_stick/tree/master/binaries > ). I assume these binaries can then also be shared and used with > non-gentoo based linux versions (if generic compiler flags are used, > which is also the idea). > > Interested people can work on improving the files in the pull > (https://github.com/gentoo/musl/pull/296 ) and then having these > improvements added to the pull. > > Adelie's firefox-esr version is 68.5.0, jakeogh's version (in pull) is > v.41 so Adelie's version is indeed newer. Current is v73, so still > needs to be improved it further. So yes, you could already switch this > in the pull. > The binary I used of Adelie (v52.9.0-r4, back in June 2019) didn't > work, and wasn't optimized for i686 cpu's (and also, Adelie linux is > based on abuild system rather then gentoo's portage system), so I am > somewhat cautious. That said, if the script is worked out further, > there may be no issues. The reason I linked to Adélie's build recipe is because you can use it as a starting point for writing an ebuild. You can also integrate our patch set to make your porting work easier. I didn't mean to imply you could directly copy what we did in to a Gentoo system. Best, --arw -- A. Wilcox (awilfox) Project Lead, Adélie Linux https://www.adelielinux.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #1.1: Type: text/plain, Size: 508 bytes --] On 15/02/2020 11:29, Rich Felker wrote: > AIUI Adélie follows -esr for which 68 is latest; is that incorrect? > Alpine has 73 in the testing repo. > > Rich That's correct. We track the ESR branch since there is significantly less churn. It is a herculean effort to handle Firefox bumps, and having to put that much effort in every 6 weeks would preclude most other work we want to do. Best, --arw -- A. Wilcox (awilfox) Project Lead, Adélie Linux https://www.adelielinux.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --]
So far, there has been no progress on the creation of those browser scripts I mentioned last time. No binaries were made so far either. Main problem hindering further development is lack of funding as for the actual development work everything falls on Stephanie and I consider (financial) compensation for her paramount. She hasn't received much donations through the funding link at github (github.com/Sharrisii/TAZ) so that's not working. A possible solution I came up with is just dropping Chromium and replacing it with Brave instead. The idea here is that since Brave generates money for its users (you get paid from advertisements); that money can be sent back to us by musl users that will also use the (musl) Brave browser we could create binaries for. Similarly, they can support our other development work (Palemoon musl, firefox musl, and our musl distro (TAZ). The system is called BAT (Basic Attention Tokens). Anyway let me know if there are any enthusiasts out there that would indeed support us. They can just deposit a small sum trough the button on our repo, or directly at https://www.paypal.me/teamlc You can donate less then 5$ or so, since it takes a while to get to 5$ with BATs (or so I assume, giving the page on token giveaways, see https://brave.com/million/ ). If I read correctly on the pages on BATs, you can then deposit the 5$ you earned later-on through the system back to your own deposit account, meaning you can compensate the sum and actually did no expense whatsoever. Don't shoot me if I'm wrong on all this, check it out yourself first. But I think I'm correct ... If there are enthusiasts, I'll mention the idea to Stephanie to see whether she is interested in it, and whether she is interested in registering as a Brave creator (https://creators.brave.com/ ). The other thing is that I got no idea how much work she'll have on it and thus the amount of people needing to donate to get this done. It's just an idea to get this done (and could perhaps support other musl development projects too). If there are any others developers that are interested in tackling the scripts for fun, go right ahead (and let me know). Then, this whole setup wouldn't be needed. If the thing succeeds, Stephanie can make a repo specifically for holding the ebuild scripts, and the binaries produced from it can be put on I read the basic (non-musl) scripts should be on https://github.com/brave , after reading that someone else already tried to make a gentoo Brave package once. See https://community.brave.com/t/would-like-to-bring-brave-to-gentoo-but-how-to-install-the-result-of-a-build/107969 Brian On 2/15/20, Rich Felker <dalias@libc.org> wrote: > On Sat, Feb 15, 2020 at 03:20:08PM +0100, Brian Peregrine wrote: >> I probably need to clarify the approach further. >> The idea is to have something (more precisely a script) which is >> intented specifically for gentoo (not all linux variants; not that the >> pull is to the gentoo/musl repo btw). Once that's ready, a binary can >> be made. Speaking for our own distro, it can be used on the optional >> usb stick >> (https://github.com/Sharrisii/TAZ_optional_usb_stick/tree/master/binaries >> ). I assume these binaries can then also be shared and used with >> non-gentoo based linux versions (if generic compiler flags are used, >> which is also the idea). >> >> Interested people can work on improving the files in the pull >> (https://github.com/gentoo/musl/pull/296 ) and then having these >> improvements added to the pull. >> >> Adelie's firefox-esr version is 68.5.0, jakeogh's version (in pull) is >> v.41 so Adelie's version is indeed newer. Current is v73, so still >> needs to be improved it further. So yes, you could already switch this >> in the pull. >> The binary I used of Adelie (v52.9.0-r4, back in June 2019) didn't >> work, and wasn't optimized for i686 cpu's (and also, Adelie linux is >> based on abuild system rather then gentoo's portage system), so I am >> somewhat cautious. That said, if the script is worked out further, >> there may be no issues. > > AIUI Adélie follows -esr for which 68 is latest; is that incorrect? > Alpine has 73 in the testing repo. > > Rich >