~cmiller/chromium-browser/ppa-chromium-browser.raring.stable

Viewing all changes in revision 878.

  • Committer: Chad Miller
  • Date: 2013-07-16 15:26:09 UTC
  • mfrom: (862.1.52 p-saucy)
  • Revision ID: chad.miller@canonical.com-20130716152609-d246ng41bv0m73sx
* New release 28.0.1500.71.
* debian/chromium-browser.install: Include inspector resources in
  chromium-browser package.
* debian/control: Make new -dbg package for chromedriver.
* debian/rules:
  - Remove tests for ancient versions of Ubuntu.
  - Return to using no explicity NEON fpu, and instead try to detect at
    runtime NEON caps. This effectively disables NEON, so far.
  - Build and run unit test suite as part of making a package. Abort if
    more than 15 out of ~1000 tests fail.
  - Clean up packaging sanity test that verifies everything we build is
    put into a package.
  - Set relative rpath to libs/ for chromium-browser executable, but . for
    libraries in libs/ ; that makes dpkg-shlibdeps happy and process run.
  - Strip out some ugly logic around keeping only one language in the main
    package, and keeping the contents verifier happy based on the
    architecture.
  - EXPERIMENT: Try not stripping enormous libraries' symbols explicitly.
  - Add more exceptions for packaging contents tests, this time to exclude
    files that are in package but not from the build tree.
  - Be more explicit about what files we set the rpath on.  Get all
    executables. We missed chromedriver before.
  - Only one hardware arch builds the independent files, so in our sanity
    test that we install everything upstream built once and only once in
    packages, we have to consider whether this build didn't even try to
    take and use arch-independent files.  Don't look for some file paths if
    we don't use them.  (Also, if we match too much of what we used, also
    remove matches from the list of created.  This should be better.)
* debian/patches/arm-neon.patch:
  - Compile in NEON instructions for ARM, even if we can't reliably check for
    whether our CPU is capable of running them yet.  The major problem
    remaining is that the sandbox security wrapper defeats any test of
    /proc/cpuinfo .
* debian/source/lintian-overrides:
  - Supress warnings about known intentional decisions: Package name, 
    statically linked bundled libraries, setuid root sandbox.
* debian/chromium-browser.sh.in:
  - Detect at startup the features of the CPU that we might be intersted
    in and export info into the environment.  This is step one of a longer
    workaround for sandbox /proc restrictions.
* Make a fall-back for when upstream fails to release a Release. Package up
  as best we can from source control.  debian/rules and 
  debian/checkout-orig-source.mk .
* debian/tests/:
  - Add smoketest to verify that chromium runs.
  - Add a empty webapps test file for notes about what parts of webapps will
    or should be tested.
* debian/keep-alive.sh.  Quit if disk environment disappears.

expand all expand all

Show diffs side-by-side

added added

removed removed

Lines of Context: