gmane.comp.web.chromium.devel

Re: MSB6006 error code 53

Scott Graham — 2013-05-19T02:24:08

I'd guess based on the command line and the error level that it's probably
a cygwin<->win32 style path problem (\\ being interpreted as a network
path). But I don't see anything obviously wrong.

I would try to run those commands standalone to see if either run outside
msbuild or give a more useful error message. Then you can add prints to the
scripts to see what's going wrong.


On Sat, May 18, 2013 at 4:42 PM, pdwiki <prabal.dey< at >gmail.com> wrote:

Re: MSB6006 error code 53

pdwiki — 2013-05-18T23:42:12

Thanks for the reply. I always checkout the code and run a build first 
before making any changes. Touched absolutely nothing!

Attached is the detailed log file from VS. I see a file is missing but am 
having trouble why this is happening. Any ideas?

Thanks again.

On Saturday, May 18, 2013 5:30:30 PM UTC-6, Scott Graham wrote:

Re: MSB6006 error code 53

Scott Graham — 2013-05-18T23:30:30

Error code 53 is "The network path was not found". Maybe you've done some
remapping or something that's stale now?

Otherwise, you could try turning up the verbosity of MSBuild or trying the
ninja build.


On Sat, May 18, 2013 at 4:10 PM, pdwiki <prabal.dey< at >gmail.com> wrote:

MSB6006 error code 53

pdwiki — 2013-05-18T23:10:19

I setup a new laptop today with Windows 8, VS 2010 Ultimate and all the 
other requirements to build Chromium. I used the following .gclient file to 
checkout Chromium last night:

solutions = [
  { "name"        : "src",
    "url"         : "https://src.chromium.org/chrome/trunk/src",
    "custom_deps" : {
      "src/content/test/data/layout_tests/LayoutTests": None,
      "src/chrome_frame/tools/test/reference_build/chrome_win": None,
      "src/chrome/test/data/perf/canvas_bench": None,
      "src/chrome/test/data/perf/frame_rate/content": None,
      "src/chrome/tools/test/reference_build/chrome_mac": None,
      "src/chrome/tools/test/reference_build/chrome_win": None,
      "src/chrome/tools/test/reference_build/chrome_linux": None,
      "src/third_party/hunspell_dictionaries": None,
    },
    "safesync_url" : "https://chromium-status.appspot.com/lkgr"
  }
]


Now, every time I am building Chromium, I am getting a MSB6006 error with 
code 53. This is happening in the generate_files project in yasm an

Re: Differentiating Chrome Frame in unittests

Matthew Menke — 2013-05-18T03:39:20

Having code in net/ test for the presence of Chrome Frame seems like it 
would be a layering violation.

Also, you can disable only specific tests in ChromeFrame, so you can, in 
fact, just disable the new ones - see 
src/chrome_frame/test/net/fake_external_tab.cc

On Friday, May 17, 2013 4:02:26 PM UTC-4, ttuttle wrote:

Re: Re: Linux now uses ninja by default

2013-05-17T23:00:43

Ninja now supports specifying which version of Ninja the build files 
require.  This makes the version dependency explicit (and Ninja will abort 
with a nice error message if your version is too old).

For more, see:
  http://martine.github.io/ninja/manual.html#ref_versioning

We should make gyp pass the appropriate value.  Then the dependency by 
Chrome remains just about which version of gyp it uses.

On Thursday, May 16, 2013 4:00:30 PM UTC-7, Paweł Hajdan, Jr. wrote:

formatting broken on src.chromium.org

Gregg Tavares — 2013-05-17T22:11:00

I noticed lots of indentation is missing in certain files on
src.chromium.org

Example:
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/service/texture_manager.cc

There's no indentation in that entire file where as there is in

http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/service/texture_manager.h

Known issue? Where should I file a bug or submit a patch?

Re: Re: Minimal version of "Offline Mode" available behind a flag on dev channel

Randy Smith — 2013-05-17T21:33:02

Hmmm.  A couple of thoughts:

* I completely agree that if a web site / web app has specified the offline
behavior they want to have happen, we should respect that.  You may
remember that in my initial note I indicated that this might not play well
with AppCache :-}.  I have no problem believing that there are improvements
that can (and should before any release) be made in the interaction between
web apps and any feature based on this experiment.

* My target for this experiment is the non-webapp properties, and the
question I'm trying to answer is "How much better could we make the offline
user experience for pages that *haven't* put thought into how they should
behave offline?".

* I'd imagine for any feature based on this experiment, we'd have to badge
the pages so that the user knew they were getting stale data.  Since this
was just an experiment to get information, I settled for warning people up
front that there wasn't any UI and relying on people turning the flag on
being ok with the lack of such a b

Re: Differentiating Chrome Frame in unittests

ttuttle — 2013-05-17T20:02:26

I don't want to remove them entirely, since some are modifications of
existing tests.  I might fork the old ones and disable only the new
ones.

On Fri, May 17, 2013 at 3:41 PM, Greg Thompson <grt< at >chromium.org> wrote:

Re: Differentiating Chrome Frame in unittests

Greg Thompson — 2013-05-17T19:41:27


If your tests simply don't apply for CF, add them to
FilterDisabledTests<https://code.google.com/p/chromium/codesearch#chromium/src/chrome_frame/test/net/fake_external_tab.cc&q=FilterDisabledTests%20file:fake&sq=package:chromium&type=cs&l=169>
.

Cheers

Differentiating Chrome Frame in unittests

ttuttle — 2013-05-17T19:34:16

Hi,

I'm making a change that adds functionality to net/ that's not
expected to work under Chrome Frame (it relies on code in Chromium's
URL request jobs, which aren't run in Chrome Frame).  I've taken a
look around chrome_frame.gyp and other tests, but can't find a way to
tell in my test cases whether I'm running in a Chrome Frame context or
elsewhere.  Does anyone have any ideas?

Thanks,

ttuttle

Re: Error with "chrome\common\extensions\docs\server2\patched_file_system.py"

Marc-Antoine Ruel — 2013-05-17T19:09:27

No problem, what is not tested in CI is bound to break. We don't expect
devs to know all of the intricacies of python features.

M-A


2013/5/17 Benjamin Kalman <kalman< at >chromium.org>

Re: Error with "chrome\common\extensions\docs\server2\patched_file_system.py"

Benjamin Kalman — 2013-05-17T19:04:10

Sorry everybody, it wasn't deliberate. I'm not up to speed with what is
python 2.x and what is 2.(x+n).


On Fri, May 17, 2013 at 11:56 AM, Justin Dewitt <dewittj< at >chromium.org>wrote:

Re: Error with "chrome\common\extensions\docs\server2\patched_file_system.py"

Justin Dewitt — 2013-05-17T18:56:09

The fix has been committed as r200860

Justin


On Fri, May 17, 2013 at 11:52 AM, Marc-Antoine Ruel <maruel< at >chromium.org>wrote:

Re: Error with "chrome\common\extensions\docs\server2\patched_file_system.py"

Marc-Antoine Ruel — 2013-05-17T18:52:18

2013/5/17 Justin Dewitt <dewittj< at >chromium.org>


Do not break 2.6.x support until chromium requires 2.7.x. Do not put that
on your backburner, you are actively breaking other developers.

Upgrading to Windows user to 2.7.x is tricky due to a gclient runhooks bug
that only happens on 2.7.x on Windows. Because of that the deployment has
to be delayed a bit.

Dict comprehension are not wacky syntax, I'm eager to be able to use them
too but please use dict() in the meantime.

Thanks,

M-A

Re: Error with "chrome\common\extensions\docs\server2\patched_file_system.py"

Tom Cassiotis — 2013-05-17T18:11:41

Thanks for the help.

I just read that Python 2.74 on Windows was added to depot_tools then 
rolled out.

(That is some wacky syntax though)

On Friday, 17 May 2013 14:05:50 UTC-4, dewittj wrote:

Re: Error with "chrome\common\extensions\docs\server2\patched_file_system.py"

Justin Dewitt — 2013-05-17T18:05:50

+kalman

I think that the version of Python that ships with depot_tools on Windows
doesn't support the dict comprehension syntax.  I had been working with
kalman on fixing that but it got put on my backburner.  I'll start looking
into that again now.  If you intend to git cl upload you may need to skip
the presubmit checks (--bypass-hooks), or use a box with Python 2.7 until
this is fixed.

Justin

D:\src\src>python --version
Python 2.6.4


On Fri, May 17, 2013 at 10:57 AM, Tom Cassiotis <tom.cassiotis< at >gmail.com>wrote:

Re: Error with "chrome\common\extensions\docs\server2\patched_file_system.py"

Roland McGrath — 2013-05-17T18:01:57

That syntax is valid in Python 2.7 but not in 2.6.

On Fri, May 17, 2013 at 10:57 AM, Tom Cassiotis <tom.cassiotis< at >gmail.com> wrote:

Error with "chrome\common\extensions\docs\server2\patched_file_system.py"

Tom Cassiotis — 2013-05-17T17:57:57

I am getting the following error on a 'git cl upload'.  patched_file_system.py 
was added 4 days ago as part of r199727.

The "path for " looks wrong and should be deleted, but I'm not familiar 
with python.

Should I post an issue or is this something on my end?

Traceback (most recent call last):
  File "docs\server2\integration_test.py", line 20, in <module>
    from handler import Handler
  File 
"D:\dev\chromium_git\src\chrome\common\extensions\docs\server2\handler.py", 
line 7, in <module>
    from patch_servlet import PatchServlet
  File 
"D:\dev\chromium_git\src\chrome\common\extensions\docs\server2\patch_servlet.py", 
line 19, in <module>
    from patched_file_system import PatchedFileSystem
  File 
"D:\dev\chromium_git\src\chrome\common\extensions\docs\server2\patched_file_system.py", 
line 51
    dir_paths = {path for path in paths if path.endswith('/')}
                        ^
SyntaxError: invalid syntax

** Presubmit ERRORS **
IntegrationTest failed!

Re: interactive_ui_tests flakiness

Fady Samuel — 2013-05-17T17:36:57

I know. I put it there. :-)

I have no idea why mapping a shared memory buffer is failing. It shouldn't
fail. BrowserPlugin expects this to work...

Did anything change about the Windows sandbox recently?

Fady


On Fri, May 17, 2013 at 10:33 AM, Paweł Hajdan, Jr. <phajdan.jr< at >chromium.org

Re: interactive_ui_tests flakiness

Paweł Hajdan, Jr. — 2013-05-17T17:33:38


Generally I wouldn't be so eager to remove a NOTREACHED() - after all, it
was put there for a reason, to alert us about issues the developer putting
it there thought should not happen.

Paweł