[chromium-dev] Clobber required on Windows after r36033
If you get a compile error in installer_util on Windows after syncing to r36033, try deleting chrome/build/obj/global_intermediate/installer_util_strings folder or manual rebuild on chrome_strings project. Rahul -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Running multiple Google Chrome channels side-by-side (for testing)
From the right email address this time.
If you really want to hack it, I think the below steps would work but there
are some many corner cases in the install flow, I am not sure if it will
always work.
- Change
HKEY_CURRENT_USER\Software\Google\Update\ClientState\{8A69D345-D564-463C-AFF1-A69D9E530F96}\ap
key (2.0-dev = dev channel, 2.0-beta = beta channel, empty = stable channel)
- Change
HKEY_CURRENT_USER\Software\Google\Update\ClientState\{8A69D345-D564-463C-AFF1-A69D9E530F96}\pv
key to 1.0.0.0 (if the key exists)
- Change
HKEY_CURRENT_USER\Software\Google\Update\Clients\{8A69D345-D564-463C-AFF1-A69D9E530F96}\pv
key to 1.0.0.0
- Rename %USERPROFILE%\Local Settings\Application
Data\Google\Chrome\Application\version folder from W.X.Y.Z to 1.0.0.0
- Start Chrome, go to about chrome box, hopefully it will prompt you for an
update, once you install it you will be on the channel that you selected in
the first step.
After looking at the steps, I am thinking it would be simpler to just
uninstall and reinstall though. Also if you are going from version N to
version N-1 there is always a small chance of Chrome profile not being
compatible with the older version of Chrome.
On Fri, Dec 18, 2009 at 12:49 PM, Aaron Boodman a...@google.com wrote:
On Fri, Dec 18, 2009 at 12:07 PM, Mark Mentovai m...@chromium.org
wrote:
Finnur Thorarinsson wrote:
You can use the channel changer, as PhistucK points out, to switch and
then
use the About box to update, but you can only move forward in time
(stable
- beta - dev).
I'm pretty sure the changer is deprecated. The supported way to hop
between channels is to run the installer for whatever channel you want
to move to.
Right, but you can't downgrade, so this approach only works a maximum of
twice.
I'm leaning toward just having separate user accounts for now.
-a
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Embedding chrome.pak in the chrome binary for Linux?
There are not embedded even on Windows (see 52 dlls under Google\Chrome\Application\version\Locales folder). On Sat, Dec 12, 2009 at 4:52 AM, Satoru Takabayashi sato...@chromium.orgwrote: The chrome binary for Linux seems to load resource bundles from a file named chrome.pak, while the resource booundles are embedded in the chrome DLL in other platforms (correct me if I'm wrong). This makes me wonder if it's a good idea to embed chrome.pak in the chrome binary for Linux. This would save open+mmap cost (probably negligible though), and would make the package a bit simpler. I guess it can be done with objcopy, without too much work. Any thoughts? Satoru -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: inconsistent file_util::CopyDirectory() behavior
Yes Windows installer relies on this behavior. There are installer_unittests
which might cover this particular use case (in CopyTreeWorkItemTest) but I
am not sure.
On Mon, Oct 12, 2009 at 3:52 PM, Steven Knight s...@chromium.org wrote:
Our existing unit tests for file_util::CopyDirectory() do not test its
behavior when the destination directory already exists. The following CL:
http://codereview.chromium.org/271060/show
which adds unit tests for already-existing destination directories, shows
that Windows and POSIX behave differently for recursive copies when the
destination directory already exists. Specifically:
On Windows, a call to file_util::CopyDirectory() with recursive copy
enabled will copy the directory name itself to ay(already-existing)
destination directory. POSIX systems will copy the *contents* of the
directory to the destination. That is, given a 'src' directory containing
two files and a call like:
file_util::CopyDirectory('src', 'existing_dest_dir', true);
On Windows we create 'existing_dest_dir/src/{file1,file2}' while on POSIX
we create just 'existing_dest_dir/{file1,file2}'.
This has come up for memory_test, which uses CopyDirectory() to copy its
checked-in cached user data dir to a freshly-created temporary directory.
At some point the Windows version of memory_test.cc was broken by this
inconsistency. We haven't noticed because the breakage fails to load the
(cached) pages, but still returns memory size data and doesn't cause the
test itself to fail.
Based on the fact that memory_test.cc originally worked on Windows, it
seems like the POSIX behavior is correct/intended (especially since it's
consistent with the behavior when the directory doesn't exist). Any
disagreement? If not, I'll fix Windows accordingly.
--SK
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: [Linux folks] Splitting First Run into it's own process
AFAIK no one is working on it for Linux. On Fri, Aug 21, 2009 at 5:11 PM, Jeremy Moskovich jer...@chromium.orgwrote: I'm looking at splitting the First Run UI import machinery into it's own process on OS X. I just wanted to sync up with people working on the Linux side of things to make sure no-one else is working on the same thing in Linux-land? Best regards, Jeremy --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How do I filter CC'd code reviews in Gmail?
I thought to:user and -cc:user would work in this case? Have you tried using that in Has the words on Filter edit screen? On Fri, Jul 31, 2009 at 5:18 PM, Brett Wilson bre...@chromium.org wrote: I added myself to some watchlists and I get a bunch of email about a lot of reviews But this has confused my Gmail filters, which automatic ally label and archive code reviews not addressed directly to me, and all of my CCd code reviews show up in my inbox. Anybody know how to reliably detect the difference between I'm the reviewer and I'm CC'd on a review in a Gmail filter? Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: setup.exe doesn't run work for me
Not sure why you are getting error when setup.exe gets launched but to get around it you can launch Chrome as admin, set it as default and then exit. On Tue, Jun 2, 2009 at 12:11 AM, nakro yoav.zilberb...@gmail.com wrote: setting chromium as the default browser make it invoke setup.exe the problem is that i started getting manifest errors when i try to launch the program the application has failed to start because the application config is incorrect also, when i build this project, i get an exe but the compiler is never happy if i build setup.exe i get compiling install.cc doing build again compiling UNInstall.cc build again compiling install.cc something is wrong in my build but i can't figure what i clobbered my build many times, and this only started happening in the last 3 days and to make the UI tests pass, chromium has to be the default browser (especially on hebrew vista) i really did try to solve it myself, but am not sure what is going on there --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Valgrind Fixit Day!
A few of these, where root cause is the same (leaking of tasks, for example 11462, 6, 11144 among others) should get fixed once http://codereview.chromium.org/115328 gets committed. On Wed, May 13, 2009 at 5:23 PM, Evan Martin e...@chromium.org wrote: And the award goes to... % git log origin --since=yesterday --grep=valgrind -i --pretty='format:%an %s' thes...@chromium.org Split NetUtilTest.IDNToUnicode into IDNToUnicodeFast e...@chromium.org valgrind: print the gtest suppression list on startup. Wait, we've had *one* fix so far? :~( (Mine doesn't count, as it's a one-liner for logging.) I guess there's room for some others where someone didn't mention valgrind in their commit message. I've made progress on two more bugs, but that leaves pretty much all the rest unclaimed. http://code.google.com/p/chromium/issues/list?can=2q=label:valgrind On Mon, May 11, 2009 at 2:20 PM, Dan Kegel daniel.r.ke...@gmail.com wrote: We've been using Valgrind to find memory leaks, pointer errors, and race conditions in Chromium on Mac and Linux for a while now. (See the valgrind bots at http://build.chromium.org.) That's cool, but it would be even cooler if we actually fixed the problems Valgrind has found. According to http://code.google.com/p/chromium/issues/list?q=valgrind we've fixed 24 Valgrind issues already, but there are 60 still open. So let's do something about it! The first step is for you to visit http://dev.chromium.org/developers/how-tos/using-valgrind and learn about how to use Valgrind to find problems in Chromium. A few Chromium developers (playmobil, jhawkins, thestig, and myself) are going to host a Valgrind Fixit this Wednesday and Thursday, May 13th and 14th. We'll be available on the chromium irc channel (irc.freenode.net/#chromium) to help you get started using Valgrind with Chromium. The page linked above also has suggestions for what to do during the Fixit. (For instance, be sure to put a note in the bug report saying you've started fixing the bug, so nobody else duplicates your effort.) As incentive for people to help out, we will send a Valgrind mug to whoever contributes the best Valgrind-related fixes, bug reports, and/or triage during those two days (winner will be chosen at the discretion of the valgrind fixit judging panel). Thanks, and see you at the Fixit! - Dan p.s. And thanks to Julian Seward of http://valgrind.org for providing such a wonderful tool! --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Graceful updates on Linux
If file structure on Linux is anywhere like Windows than the shared library (chrome.dll on Windows) would be versioned (the dll is kept inside a version directory on Windows) but the executable itself (chrome.exe) will always live at the same place. On Linux are we going to allow Chrome updates to happen while Chrome is running? In this is what we are aiming for forking sounds great since we will end up using the same exe version and this should work as long as we know which shared library we are using with it. On Thu, Feb 5, 2009 at 9:33 AM, Dan Kegel daniel.r.ke...@gmail.com wrote: Firefox behaves terribly upon update on Linux because they didn't bother even trying to make distro updates work well, and everybody uses distro packages for Firefox. Let's avoid this same problem on Chrome for Linux. Does that sound like a reasonable goal? We're early enough in the port that it might not be too hard to bake that feature in. What would it take to survive all our files changing out from under us? I imagine it would suffice to: 1) open all the files we're going to need early, and keep the handles around for when we need them 2) for our own executables, don't exec, only fork. That would mean using a zygote, i.e. at startup time, fork before creating any threads, and have the initial instance just be a factory for anybody who needs another instance of that executable. Is that practical, and did I miss anything? - Dan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Graceful updates on Linux
Since I don't know how zygote works I will just throw it out there - what will happen if Chrome gets updated while it is already running and user tries to launch another instance of Chrome browser (from a shortcut or from command line)? I am guessing if its the same profile the new chrome will exit after sending a msg to already running browser instance. But if it is a different profile we can potentially have two different version running with two different profiles? On Thu, Feb 5, 2009 at 10:35 AM, t...@chromium.org wrote: I think the current plan is to have a zygote used to spawn sub processes in which case it should be safe to change the chrome executable while it is running. The running chrome process won't depend on disk for anything (all data files are mmapped at process start up). On Thu, 5 Feb 2009, cpu wrote: Are there any implications for sandboxing on the fork vs exec ? I don't want us to paint ourselves in a corner when we implement the sandbox. On Feb 5, 9:57 am, Rahul Kuchhal kuch...@chromium.org wrote: If file structure on Linux is anywhere like Windows than the shared library (chrome.dll on Windows) would be versioned (the dll is kept inside a version directory on Windows) but the executable itself (chrome.exe) will always live at the same place. On Linux are we going to allow Chrome updates to happen while Chrome is running? In this is what we are aiming for forking sounds great since we will end up using the same exe version and this should work as long as we know which shared library we are using with it. On Thu, Feb 5, 2009 at 9:33 AM, Dan Kegel daniel.r.ke...@gmail.com wrote: Firefox behaves terribly upon update on Linux because they didn't bother even trying to make distro updates work well, and everybody uses distro packages for Firefox. Let's avoid this same problem on Chrome for Linux. Does that sound like a reasonable goal? We're early enough in the port that it might not be too hard to bake that feature in. What would it take to survive all our files changing out from under us? I imagine it would suffice to: 1) open all the files we're going to need early, and keep the handles around for when we need them 2) for our own executables, don't exec, only fork. That would mean using a zygote, i.e. at startup time, fork before creating any threads, and have the initial instance just be a factory for anybody who needs another instance of that executable. Is that practical, and did I miss anything? - Dan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
