mailing list of musl libc
 help / color / Atom feed
* [musl] Musl gentoo development: browsers
@ 2020-02-14 12:12 Brian Peregrine
  2020-02-14 17:15 ` A. Wilcox
                   ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: Brian Peregrine @ 2020-02-14 12:12 UTC (permalink / raw)
  To: musl

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [musl] Musl gentoo development: browsers
  2020-02-14 12:12 [musl] Musl gentoo development: browsers Brian Peregrine
@ 2020-02-14 17:15 ` A. Wilcox
  2020-02-14 20:51 ` Michael Forney
  2020-02-15 14:20 ` [musl] " Brian Peregrine
  2 siblings, 0 replies; 12+ messages in thread
From: A. Wilcox @ 2020-02-14 17:15 UTC (permalink / raw)
  To: musl

[-- 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 --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [musl] Musl gentoo development: browsers
  2020-02-14 12:12 [musl] Musl gentoo development: browsers Brian Peregrine
  2020-02-14 17:15 ` A. Wilcox
@ 2020-02-14 20:51 ` Michael Forney
  2020-02-14 21:14   ` Rich Felker
  2020-02-14 21:35   ` A. Wilcox
  2020-02-15 14:20 ` [musl] " Brian Peregrine
  2 siblings, 2 replies; 12+ messages in thread
From: Michael Forney @ 2020-02-14 20:51 UTC (permalink / raw)
  To: musl

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [musl] Musl gentoo development: browsers
  2020-02-14 20:51 ` Michael Forney
@ 2020-02-14 21:14   ` Rich Felker
  2020-02-14 21:32     ` A. Wilcox
  2020-02-14 21:35   ` A. Wilcox
  1 sibling, 1 reply; 12+ messages in thread
From: Rich Felker @ 2020-02-14 21:14 UTC (permalink / raw)
  To: musl

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [musl] Musl gentoo development: browsers
  2020-02-14 21:14   ` Rich Felker
@ 2020-02-14 21:32     ` A. Wilcox
  0 siblings, 0 replies; 12+ messages in thread
From: A. Wilcox @ 2020-02-14 21:32 UTC (permalink / raw)
  To: musl

[-- 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 --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [musl] Musl gentoo development: browsers
  2020-02-14 20:51 ` Michael Forney
  2020-02-14 21:14   ` Rich Felker
@ 2020-02-14 21:35   ` A. Wilcox
  1 sibling, 0 replies; 12+ messages in thread
From: A. Wilcox @ 2020-02-14 21:35 UTC (permalink / raw)
  To: musl

[-- 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 --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [musl] Re: Musl gentoo development: browsers
  2020-02-14 12:12 [musl] Musl gentoo development: browsers Brian Peregrine
  2020-02-14 17:15 ` A. Wilcox
  2020-02-14 20:51 ` Michael Forney
@ 2020-02-15 14:20 ` Brian Peregrine
  2020-02-15 17:29   ` Rich Felker
  2020-02-15 18:54   ` A. Wilcox
  2 siblings, 2 replies; 12+ messages in thread
From: Brian Peregrine @ 2020-02-15 14:20 UTC (permalink / raw)
  To: musl

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [musl] Re: Musl gentoo development: browsers
  2020-02-15 14:20 ` [musl] " Brian Peregrine
@ 2020-02-15 17:29   ` Rich Felker
  2020-02-15 17:45     ` Milan P. Stanić
                       ` (2 more replies)
  2020-02-15 18:54   ` A. Wilcox
  1 sibling, 3 replies; 12+ messages in thread
From: Rich Felker @ 2020-02-15 17:29 UTC (permalink / raw)
  To: Brian Peregrine; +Cc: musl

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [musl] Re: Musl gentoo development: browsers
  2020-02-15 17:29   ` Rich Felker
@ 2020-02-15 17:45     ` Milan P. Stanić
  2020-02-15 18:56     ` A. Wilcox
  2020-05-20 16:30     ` Brian Peregrine
  2 siblings, 0 replies; 12+ messages in thread
From: Milan P. Stanić @ 2020-02-15 17:45 UTC (permalink / raw)
  To: musl

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [musl] Re: Musl gentoo development: browsers
  2020-02-15 14:20 ` [musl] " Brian Peregrine
  2020-02-15 17:29   ` Rich Felker
@ 2020-02-15 18:54   ` A. Wilcox
  1 sibling, 0 replies; 12+ messages in thread
From: A. Wilcox @ 2020-02-15 18:54 UTC (permalink / raw)
  To: musl

[-- 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 --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [musl] Re: Musl gentoo development: browsers
  2020-02-15 17:29   ` Rich Felker
  2020-02-15 17:45     ` Milan P. Stanić
@ 2020-02-15 18:56     ` A. Wilcox
  2020-05-20 16:30     ` Brian Peregrine
  2 siblings, 0 replies; 12+ messages in thread
From: A. Wilcox @ 2020-02-15 18:56 UTC (permalink / raw)
  To: musl

[-- 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 --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [musl] Re: Musl gentoo development: browsers
  2020-02-15 17:29   ` Rich Felker
  2020-02-15 17:45     ` Milan P. Stanić
  2020-02-15 18:56     ` A. Wilcox
@ 2020-05-20 16:30     ` Brian Peregrine
  2 siblings, 0 replies; 12+ messages in thread
From: Brian Peregrine @ 2020-05-20 16:30 UTC (permalink / raw)
  To: musl

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
>

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, back to index

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-14 12:12 [musl] Musl gentoo development: browsers Brian Peregrine
2020-02-14 17:15 ` A. Wilcox
2020-02-14 20:51 ` Michael Forney
2020-02-14 21:14   ` Rich Felker
2020-02-14 21:32     ` A. Wilcox
2020-02-14 21:35   ` A. Wilcox
2020-02-15 14:20 ` [musl] " Brian Peregrine
2020-02-15 17:29   ` Rich Felker
2020-02-15 17:45     ` Milan P. Stanić
2020-02-15 18:56     ` A. Wilcox
2020-05-20 16:30     ` Brian Peregrine
2020-02-15 18:54   ` A. Wilcox

mailing list of musl libc

Archives are clonable: git clone --mirror http://inbox.vuxu.org/musl

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git