Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: baz on December 12, 2009, 08:56:54 PM
-
I find Google Chrome to be much faster and lighter than other browsers and would love to have it on TinyCore. What can I do to make that happen?
-
I was thinking about trying to compile Chrome, but I don't have time right now. I think someone has to compile it for TC for it to work (I don't think you can just install from a .deb)
To compile, you'll want to get the extension "tc-compile".
The "google chrome source" web site can provide the source code for download and it'll tell you what libraries/dependencies need to be present at compile-time.
All of the how-to's on making a tinycore extension seem to require more indepth Linux knowlege than I have,* but I've been trying to make sense of them. You can learn more by reading the forums and the wiki.
*specifically, after having compiled a kernel extension I didn't know where the files created by "make" were, and you can't "tar" a file without knowing where it is or what it's name is.
-
nss-nspr requirement does not meet in tiny core it needs to be updated first
http://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisites#Software_Requirements (http://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisites#Software_Requirements)
-
I will update nss-nspr soon. I followed linux from scratch build which packaged them together, but the newer LFS builds them seperate. I will for now keep them together as to not break existing dep files and tce directory installations, and will seperate them for TC 3.0.
-
I will update nss-nspr soon. I followed linux from scratch build which packaged them together, but the newer LFS builds them seperate. I will for now keep them together as to not break existing dep files and tce directory installations, and will seperate them for TC 3.0.
i have successfully compiled chrome from source after updating nss-nspr myself
posting from chrome at the moment :) :) :)
-
If you already have an updated nss-nspr, please feel free to submit it as there it no need to duplicate work. :)
-
http://farm3.static.flickr.com/2493/4185688318_79591bd9b5_o.png (http://farm3.static.flickr.com/2493/4185688318_79591bd9b5_o.png)
-
If you already have an updated nss-nspr, please feel free to submit it as there it no need to duplicate work. :)
when it comes to packaging i am not too good :D
i will submit it with chrome in a few days
-
WHAT!!!!!!!!! How amazing is this community!!
-
Arslan, I think your packaging will be fine. It will be nice to have a chrome built from source into /usr/local as opposed to the Debian/Fedora packages they supply.
-
it just runs where it is located provided that some other files alongside with it
it doesnt have an auto install option
i was thinking of puting those files under /usr/local/share/chromium
and creating a wrapper script in /usr/local/bin
for flash player support creating a symlink $CHROME_ROOT/plugins/libflashplayer.so
but i have for now problems with licencing and how can i build it for i486
i set compiler flags in environment but dunno if building system respected those flags
this is the link i followed with compiling
http://code.google.com/p/chromium/wiki/LinuxBuildInstructions (http://code.google.com/p/chromium/wiki/LinuxBuildInstructions)
-
The other Mozilla browsers are installed to /usr/local/browsername. So /usr/local/chromium would fall in line with that, with a wrapper in /usr/local/bin.
I built Shiretoko optimized for i686, a 586 or lower machine is not going to even be able to run any of these browsers. So I think that i686 is acceptable for apps that must have a more modern machine to run.
Licensing does seem a little unclear, and I am not sure if one can distribute a non official build as chrome or if another name must be used. I will look further.
-
I built Shiretoko optimized for i686, a 586 or lower machine is not going to even be able to run any of these browsers.
Just curious, did you try it?
-
Though I built the original Shiretoko as i686, the subsequent builds have been -march=i486 -mtune=i686 as I have used the standard TC build flags for it.
I will test on my 400mhz Athlon that is a 586 as I am curious, the machine I was using in the past to test i586 compatibility. It would run Shiretoko that was built for i486, though anyone using a machine of that spec to surf the modern web with a modern browser would be quickly frustrated by it.
-
i have found the licence is BSD and third party libs has own licences
http://code.google.com/intl/tr-TR/chromium/terms.html (http://code.google.com/intl/tr-TR/chromium/terms.html)
-
There also seems to be some not so clear branding rules that may be similar to Firefox that was mentioned on that page:
http://www.google.com/permissions/guidelines.html
http://www.google.com/permissions/brand_terms.html
I don't have time to delve into it now, but I didn't see an answer right off on whether we would need to rename our own build. I will look more into it later.
-
You can call it Chromium if you want.
I think it may be against the rules to call any browser "Google Chrome" if you compile it yourself (as someone who doesn't work for the Google Chrome project).
-
You can call it Chromium if you want.
I think it may be against the rules to call any browser "Google Chrome" if you compile it yourself (as someone who doesn't work for the Google Chrome project).
i will name it chromium-browser
and put a copyright notice under /usr/local/share/doc/chromium-browser
also there is the license in source code bsd style and as i understand as long as you dont use google brand to endorse your distribution with google reputation it is fine to distribute it
there are other distros have their own built from source chromium packages
http://code.google.com/p/chromium/wiki/LinuxChromiumPackages (http://code.google.com/p/chromium/wiki/LinuxChromiumPackages)
-
I just noticed the new build in the AppBrowser!! It is lightning fast, and uses much less memory than Shiretoko. Thanks for your great work!! Chrome and TinyCore make a great match.
-
I only worked out today how to install apps onto TinyCore linux - I love it!
Just installed google chrome but when I ran
/usr/local/bin/chromium-browser
It came up with:
error while loading shared libraries: libdbus-glib-1.so.2: cannot open shared object file: no such file or directory
I ended up installing dbus.tcz and dbus-glib.tcz and it worked fine.
I thought you guys might want to know so you can update the dependencies for chromium-browser-686
Thanks for all the great work!
-
gconf updated that's the reason, thanks for feedback
new GConf library depends on:
glib2 -> new dependency
dbus -> new dependency (dbus depends on expat2)
dbus-glib -> new dependecy
libxml2 -> new dependency
wish we had a recursive dep system ;D
-
gconf updated that's the reason, thanks for feedback
new GConf library depends on:
glib2 -> new dependency
dbus -> new dependency (dbus depends on expat2)
dbus-glib -> new dependecy
libxml2 -> new dependency
wish we had a recursive dep system ;D
I have incorporated recursive dep processing into tce-load, It is currently in testing.
However it would not be backward compatible, e.g., once deployed for a given extension, then that extension would not load on prior versions.
-
i see but remember moving from tczl to tcz with tce-notify for older versions
a similar approach can be followed maybe?
-
You can't retract older versions.
You can't let older versions prevent progress.
Even when I write support programs to support older versions, I get reviews like this:
http://server.ericsbinaryworld.com/blog/2010/01/29/review-tiny-core-linux/
-
ok no problem :)
i have a question to you
let's say extension A dependends on extension B and extension B dependens on Extension C but extension A works without extension C in this case do i have to add extension C to dep list of extension A ?
let's say i did not add extension C as a dependency and loaded extension_A then if i try to load extension B extension C is not loaded and receiving error extension B is already loaded ;D
my overall question is do i have to recursively add every dependent extensions or not ?
-
It would be preferable. Even if ext_B can run without some extensions, say perl or some other interpreter, parts of it will be disabled, and users will eventually find out.
-
When 2.8 was released I was wondering how many people would have been puzzled when upgrading and not finding any of the installed apps, then going back to read the release notes and setup a properly made onboot.lst
Almost no complaints, so for now the TC average user is geeky enough to understand the need for such changes and then adapt. It's not about such changes deserving a mayor version number, even small cosmetic changes could challenge a novel user. One sample: /tce/optional it is no longer about being 'optional', so changing the name to something like /tce/local-repository would clarify its purpose. But such a change would involve apps not starting until moved again to such a new location.
I don't think TC has to rethink anything: it's just the way it is and we know it is a good thing to be the way it is. If someone thinks 2.8 should really be called 0.2.8 that is fine, moreover if that someone thinks that getting to 1.0 means no major changes and stalled thinking for then on.
If 2.9 (or 3.0 or whatever) is not backwards compatible but is greater than any prior version, that is good for me.
-
Sometimes it is a matter of how best to get the word out for changes that affect extensions.
Perhaps it is too geeky to assume that one would read the change log for a new release.
Perhaps it is too much to ask for one to actually read the .info file to see the actual requirments of a selected extension.
Is there any reason for one to stay behind in the 2.x series and not stay current?
I would really like to release an updated tce-load with recursive dependency capability.
-
I think I made myself clear in my last sentence but were a little confusing in the preceding paragraph. IMHO, TC doesn't need to rethink itself to be more conservative, quite the opposite. TC is really good in the way it doesn't stay the same thing, and making instead great jumps in usability every release.
Even if it sometimes suffer in the easyness of use. That is a bonus which, while frequently meet, is not tthe real aim.
I honestly think we all agre here.
-
A newer version of Chrome is out that supports extensions - anyone know if it is supported on tc?
-
I am using Chromium with extensions - already supported by the version in the repo.
-
Interestingly enough, even though extensions ARE supported, if you try to install an extension at the moment there is a message saying extensions aren't yet supported. Maybe it's time for an update of Chrome anyway?
-
Weird. I have a couple extensions installed but don't recall messages about these not being supported. Using v4.0.286 or something.
-
I'll try an update, I installed a while ago
-
Weird. I have a couple extensions installed but don't recall messages about these not being supported. Using v4.0.286 or something.
Yeah, I've got some installed extensions too, it definitely WAS working for the first month or two after extensions were released. Maybe they're trying to force people to stay up-to-date?
-
i am unable to update chromium soon it seems due to my busy schedule till then you can try out nightly builds here
http://build.chromium.org/buildbot/snapshots/chromium-rel-linux (http://build.chromium.org/buildbot/snapshots/chromium-rel-linux)
-
The latest nightly build (40288) fixes every problem I've so far encountered with Chrome - Extension support disappearing, and bad SSL revocations on valid SSL certs. Definately worth switching to the nightlies.
-
I have just this morning found the bookmark sync causes chromium to shut down. It worked before.