Re: [gentoo-dev] Last rites: www-client/chromium-bin
On 04.05.23 20:59, Maciej Barć wrote: R.i.p. to a lot od desktop users on non-state-of-the-art HW. Building Chromium inside a cloud VM may be an option for some users with older hardware. When using e.g. https://github.com/hartwork/binary-gentoo for that, the VM doesn't even have to run Gentoo.
Re: [gentoo-dev] Last rites: www-client/chromium-bin
> On Thu, 04 May 2023, James Le Cuirot wrote: >> On May 4, 2023 6:38:32 PM UTC, Mike Gilbert wrote: >> > # Out of date by several versions. Many unresolved security >> > # vulnerabilities. Lack of manpower/interest in keeping it up to date. >> > # Removal on 2023-06-03. >> > www-client/chromium-bin >> > >> On Thu, 2023-05-04 at 18:59 +, Maciej Barć wrote: >> R.i.p. to a lot od desktop users on non-state-of-the-art HW. >> But chromium source build was unusable for long time with big UI bugs. > Those affected can try www-client/vivaldi instead. If you're unaware, it's > based on Chromium. It's also a binary package, I keep it well-maintained, and > if you ask me, it's just better all round. :) Could the mask message mention it as possible alternative? Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: www-client/chromium-bin
James you either got into my localnet or you are reading my mind. That's what I swapped chromium-bin for. This is because I need to test some stuff on Chromium based-browser(s) specifically. W dniu 4.05.2023 o 23:06, James Le Cuirot pisze: On May 4, 2023 6:38:32 PM UTC, Mike Gilbert wrote: # Out of date by several versions. Many unresolved security # vulnerabilities. Lack of manpower/interest in keeping it up to date. # Removal on 2023-06-03. www-client/chromium-bin On Thu, 2023-05-04 at 18:59 +, Maciej Barć wrote: R.i.p. to a lot od desktop users on non-state-of-the-art HW. But chromium source build was unusable for long time with big UI bugs. Those affected can try www-client/vivaldi instead. If you're unaware, it's based on Chromium. It's also a binary package, I keep it well-maintained, and if you ask me, it's just better all round. :) -- Have a great day! ~ Maciej XGQT Barć x...@gentoo.org Gentoo Linux developer (dotnet, emacs, math, ml, nim, scheme, sci) https://wiki.gentoo.org/wiki/User:Xgqt 9B0A 4C5D 02A3 B43C 9D6F D6B1 14D7 4A1F 43A6 AC3C OpenPGP_0x14D74A1F43A6AC3C.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: www-client/chromium-bin
> On May 4, 2023 6:38:32 PM UTC, Mike Gilbert wrote: > > # Out of date by several versions. Many unresolved security > > # vulnerabilities. Lack of manpower/interest in keeping it up to date. > > # Removal on 2023-06-03. > > www-client/chromium-bin > > > On Thu, 2023-05-04 at 18:59 +, Maciej Barć wrote: > R.i.p. to a lot od desktop users on non-state-of-the-art HW. > But chromium source build was unusable for long time with big UI bugs. Those affected can try www-client/vivaldi instead. If you're unaware, it's based on Chromium. It's also a binary package, I keep it well-maintained, and if you ask me, it's just better all round. :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites: www-client/chromium-bin
R.i.p. to a lot od desktop users on non-state-of-the-art HW. But chromium source build was unusable for long time with big UI bugs. On May 4, 2023 6:38:32 PM UTC, Mike Gilbert wrote: ># Out of date by several versions. Many unresolved security ># vulnerabilities. Lack of manpower/interest in keeping it up to date. ># Removal on 2023-06-03. >www-client/chromium-bin >
Re: [gentoo-dev] Last rites: www-client/chromium-bin
On Fri, 4 Mar 2011 21:41:30 -0500 Rich Freeman ri...@gentoo.org wrote: and for me the bigger benefit is not sucking down half a gig of RAM. Oh, that's exactly what is catching more and more users out: Hey I got 8 cores so I can run MAKEOPTS=-j8! What happens? With only 6GB RAM, and each of those eight cc1plus jobs picking more than half a gigabyte, jobs get OOM killed. Please volunteer on bug-wranglers@. :) jer
Re: [gentoo-dev] Last rites: www-client/chromium-bin
On 3/5/11 12:51 AM, Tomáš Chvátal wrote: Dne 5.3.2011 00:46, Alex Alexander napsal(a): Chromium has its own version of webkit :) For this lovely thing it should be webkit-gtk Actually, Alex is right. Chromium has its own port of WebKit, different from Qt and GTK ports. Reasons for that include sandboxing, process separation, and little rendering differences (for example using the skia library). This might be possible to change in the future (a separate library to possibly avoid recompilations), but for now I'm not aware of any effort to do that (it's really non-trivial). On 3/5/11 3:41 AM, Rich Freeman wrote: Still, the build has gotten faster with time as the excellent g.o chromium team slowly strips out bundled libs. If you want a real eye-opener do a du -s * in the source tree for chromium and see where all the code is. Thanks! Anyway, I guess that the WebKit part of the browser still takes the majority of the compile time. On 3/5/11 12:58 AM, Alex Alexander wrote: I can also give you a binpkg from one of my chroots :P It sounds like a possible option. We could then advertise those binpkgs on the project page, or make them semi-official. If you or someone else is interested in doing that, I second that effort. Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: www-client/chromium-bin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 4.3.2011 10:35, Paweł Hajdan, Jr. napsal(a): # Pawel Hajdan jr phajdan...@gentoo.org (04 Mar 2011) # Masked for removal in 90 days. # Multiple hard to fix and time consuming maintenance problems: # - history of bugs (bug #304527, bug #335101, bug #347175, #bug #349249, bug #356609) # - upstream's binary builds cannot be used on Gentoo #as easily as other -bin packages (ubuntu-specific #library names that require compatibility symlinks, #bundling libraries, mirror/redistribution policy, and so on) # - dependencies for the -bin package are harder to manage; #often we have source compatibility, but not binary compatibility www-client/chromium-bin Well I can't afford to compile it for 3 hours. Could you at least make it compile against system webkit? That would save so much time i would not complain :) Tom -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1xdn8ACgkQHB6c3gNBRYfVAACggDqC1IBOLzMfiHBclXf3e9qH wXQAn0AISAPglT2ZBr5KfTEcSQ+rh3Nk =p81E -END PGP SIGNATURE-
Re: [gentoo-dev] Last rites: www-client/chromium-bin
On Sat, Mar 05, 2011 at 12:32:15AM +0100, Tomáš Chvátal wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 4.3.2011 10:35, Paweł Hajdan, Jr. napsal(a): # Pawel Hajdan jr phajdan...@gentoo.org (04 Mar 2011) # Masked for removal in 90 days. # Multiple hard to fix and time consuming maintenance problems: # - history of bugs (bug #304527, bug #335101, bug #347175, #bug #349249, bug #356609) # - upstream's binary builds cannot be used on Gentoo #as easily as other -bin packages (ubuntu-specific #library names that require compatibility symlinks, #bundling libraries, mirror/redistribution policy, and so on) # - dependencies for the -bin package are harder to manage; #often we have source compatibility, but not binary compatibility www-client/chromium-bin Well I can't afford to compile it for 3 hours. Could you at least make it compile against system webkit? That would save so much time i would not complain :) What system webkit? Chromium has its own version of webkit :) Anyway, compilation on a modern system shouldn't take more than an hour. ~15-20 minutes on a quad i5. -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com pgppKwus8FBgQ.pgp Description: PGP signature
Re: [gentoo-dev] Last rites: www-client/chromium-bin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 5.3.2011 00:46, Alex Alexander napsal(a): What system webkit? Chromium has its own version of webkit :) For this lovely thing it should be webkit-gtk Anyway, compilation on a modern system shouldn't take more than an hour. ~15-20 minutes on a quad i5. Do I look like I *censored* money? How am I supposed to build such system :D -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1xevsACgkQHB6c3gNBRYfIfACeOfqKMRHaqq8idg0acABT6x3+ DkEAniY5pfmKqS7T9U4jsd1dJTwx+3Up =lYQC -END PGP SIGNATURE-
Re: [gentoo-dev] Last rites: www-client/chromium-bin
On Sat, Mar 05, 2011 at 12:51:23AM +0100, Tomáš Chvátal wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 5.3.2011 00:46, Alex Alexander napsal(a): What system webkit? Chromium has its own version of webkit :) For this lovely thing it should be webkit-gtk Anyway, compilation on a modern system shouldn't take more than an hour. ~15-20 minutes on a quad i5. Do I look like I *censored* money? How am I supposed to build such system :D heh. then you should stick to stable releases and compile less frequently, the binary package is too painful to maintain [also known as a demotivator]. I can also give you a binpkg from one of my chroots :P -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com pgpxsj09Qg3Cl.pgp Description: PGP signature
Re: [gentoo-dev] Last rites: www-client/chromium-bin
Alex Alexander dixit (2011-03-05, 01:46): On Sat, Mar 05, 2011 at 12:32:15AM +0100, Tomáš Chvátal wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 4.3.2011 10:35, Paweł Hajdan, Jr. napsal(a): # Pawel Hajdan jr phajdan...@gentoo.org (04 Mar 2011) # Masked for removal in 90 days. # Multiple hard to fix and time consuming maintenance problems: # - history of bugs (bug #304527, bug #335101, bug #347175, #bug #349249, bug #356609) # - upstream's binary builds cannot be used on Gentoo #as easily as other -bin packages (ubuntu-specific #library names that require compatibility symlinks, #bundling libraries, mirror/redistribution policy, and so on) # - dependencies for the -bin package are harder to manage; #often we have source compatibility, but not binary compatibility www-client/chromium-bin Well I can't afford to compile it for 3 hours. Could you at least make it compile against system webkit? That would save so much time i would not complain :) What system webkit? Chromium has its own version of webkit :) Anyway, compilation on a modern system shouldn't take more than an hour. ~15-20 minutes on a quad i5. Takes ~32 minutes on my i7 (dual core @2.67 ghz). -- [a] pgpsOhkMX68V6.pgp Description: PGP signature
Re: [gentoo-dev] Last rites: www-client/chromium-bin
On Fri, Mar 4, 2011 at 6:46 PM, Alex Alexander wi...@gentoo.org wrote: Anyway, compilation on a modern system shouldn't take more than an hour. ~15-20 minutes on a quad i5. Clearly your definition of modern doesn't include my server... :) Just checked and the last build clocked in at 192 minutes. I need to make sure I have /var/tmp/portage symlinked back to a non-tmpfs location whenever I build it or else the system pretty-much dies from a lack of RAM. For kicks I tried to do better with distcc and EC2. That worked great until it started running a bunch of python scripts in the makefile - at -j15 or whatever I had it set to. Distcc really needs a solution for the fact that you can't pick a single optimum value for -j when gcc is only part of the build. Sure, the EC2 latency isn't great, but you can parallelize as much as you want, and for me the bigger benefit is not sucking down half a gig of RAM. Still, the build has gotten faster with time as the excellent g.o chromium team slowly strips out bundled libs. If you want a real eye-opener do a du -s * in the source tree for chromium and see where all the code is.
Re: [gentoo-dev] Last rites: www-client/chromium-bin
On Fri, Mar 04, 2011 at 09:41:30PM -0500, Rich Freeman wrote: ... For kicks I tried to do better with distcc and EC2. That worked great until it started running a bunch of python scripts in the makefile - at -j15 or whatever I had it set to. Distcc really needs a solution for the fact that you can't pick a single optimum value for -j when gcc is only part of the build. ... from 'man make': -l [load], --load-average[=load] Specifies that no new jobs (commands) should be started if there are others jobs running and the load average is at least load (a floating-point number). With no argument, removes a previous load limit.