Update linux sysroot images from debian/wheezy to debian/jessie

Update linux sysroot images from debian/wheezy to debian/jessie

CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_arm

[Sam Clegg, 2016-02-04 18:30:14]

The CQ bit was checked by sbc@chromium.org to run a CQ dry run

[Sam Clegg, 2016-02-04 18:30:29]

Description was changed from

==========
Update linux sysroot images from dedian/wheezy to debian/jessie
==========

to

==========
Update linux sysroot images from dedian/wheezy to debian/jessie

CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_arm
==========

[commit-bot: I haz the power, 2016-02-04 18:33:40]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1665223002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1665223002/20001

[Sam Clegg, 2016-02-04 18:51:11]

sbc@chromium.org changed reviewers:
+ thestig@chromium.org

[Sam Clegg, 2016-02-04 18:51:12]

I think we are not ready to land this yet, but this change will update the
sysroot used by the linux build.

Mostly just uploading it to make sure the trybots pass.

[Sam Clegg, 2016-02-04 18:51:21]

Description was changed from

==========
Update linux sysroot images from dedian/wheezy to debian/jessie

CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_arm
==========

to

==========
Update linux sysroot images from debian/wheezy to debian/jessie

CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_arm
==========

[commit-bot: I haz the power, 2016-02-04 18:52:37]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-04 18:52:38]

Dry run: Try jobs failed on following builders:
  linux_arm on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_arm/build...)

[Lei Zhang, 2016-02-04 19:15:38]

Have you tried an official Chrome Linux build with the new sysroot? I'm
surprised there's no chrome/installer/linux changes as a result of this.

I already have the official build setup here. I can do the build if you'd like.

[Sam Clegg, 2016-02-04 19:16:27]

On 2016/02/04 19:15:38, Lei Zhang wrote:
> Have you tried an official Chrome Linux build with the new sysroot? I'm
> surprised there's no chrome/installer/linux changes as a result of this.
> 
> I already have the official build setup here. I can do the build if you'd
like.

Sure.  I'm not setup to build the official build.

[Lei Zhang, 2016-02-04 19:42:16]

On 2016/02/04 19:16:27, Sam Clegg wrote:
> Sure.  I'm not setup to build the official build.

I kicked it off, but it's goma-less, so it might be a while.

[Lei Zhang, 2016-02-04 21:51:56]

On 2016/02/04 19:42:16, Lei Zhang wrote:
> I kicked it off, but it's goma-less, so it might be a while.

We are failing when linking the chrome binary:

ld.gold: warning: hidden symbol 'hb_font_destroy' in
obj/third_party/harfbuzz-ng/libharfbuzz-ng.a(hb-font.o ...
ld.gold: error: treating warnings as errors

I know we've hit this before, but I can't remember how we dealt with it. Trying
to jog my memory.

[Sam Clegg, 2016-02-04 22:02:26]

On 2016/02/04 21:51:56, Lei Zhang wrote:
> On 2016/02/04 19:42:16, Lei Zhang wrote:
> > I kicked it off, but it's goma-less, so it might be a while.
> 
> We are failing when linking the chrome binary:
> 
> ld.gold: warning: hidden symbol 'hb_font_destroy' in
> obj/third_party/harfbuzz-ng/libharfbuzz-ng.a(hb-font.o ...
> ld.gold: error: treating warnings as errors
> 
> I know we've hit this before, but I can't remember how we dealt with it.
Trying
> to jog my memory.

Can I see more of the error messages?

Is it relevant that the new version of pango now depends on harfbuzz so harfbuzz
was added to the sysroot...

[Lei Zhang, 2016-02-05 19:47:20]

On 2016/02/04 22:02:26, Sam Clegg wrote:
> Can I see more of the error messages?
> 
> Is it relevant that the new version of pango now depends on harfbuzz so
harfbuzz
> was added to the sysroot...

I think we ran into some form of https://crbug.com/353127 - if I change the
GYP/GN logic to disable the usage of bundled harfbuzz, then it compiles. After
which, we then hit packaging issues on Precise:

stable_rpm target - DEPS changes, not a big deal:
+libc.so.6(GLIBC_2.14)(64bit)
+libc.so.6(GLIBC_2.15)(64bit)
+libharfbuzz.so.0()(64bit)
+libstdc++.so.6(GLIBCXX_3.4.18)(64bit)
+libstdc++.so.6(GLIBCXX_3.4.19)(64bit)

stable_deb target - Precise does not have a libharfbuzz package, so we get:

dpkg-shlibdeps: error: couldn't find library libharfbuzz.so.0 needed by
/path/to/out/Release/chrome (ELF format: 'elf64-x86-64'; RPATH: '').


To get this CL to land in a sane manner, we probably need to take "official"
build bots and add libharfbuzz.so.0 in a way that dpkg-shlibdeps finds it. We'll
then work on upgrading the build bots to Trusty separately, where the
libharfbuzz package exists. (I've prodded infrastructure folks on several bugs
relating to distro upgrades.)

[Sam Clegg, 2016-02-05 20:22:57]

On 2016/02/05 19:47:20, Lei Zhang wrote:
> On 2016/02/04 22:02:26, Sam Clegg wrote:
> > Can I see more of the error messages?
> > 
> > Is it relevant that the new version of pango now depends on harfbuzz so
> harfbuzz
> > was added to the sysroot...
> 
> I think we ran into some form of https://crbug.com/353127 - if I change the
> GYP/GN logic to disable the usage of bundled harfbuzz, then it compiles. After
> which, we then hit packaging issues on Precise:
> 
> stable_rpm target - DEPS changes, not a big deal:
> +libc.so.6(GLIBC_2.14)(64bit)
> +libc.so.6(GLIBC_2.15)(64bit)
> +libharfbuzz.so.0()(64bit)
> +libstdc++.so.6(GLIBCXX_3.4.18)(64bit)
> +libstdc++.so.6(GLIBCXX_3.4.19)(64bit)
> 
> stable_deb target - Precise does not have a libharfbuzz package, so we get:
> 
> dpkg-shlibdeps: error: couldn't find library libharfbuzz.so.0 needed by
> /path/to/out/Release/chrome (ELF format: 'elf64-x86-64'; RPATH: '').
> 
> 
> To get this CL to land in a sane manner, we probably need to take "official"
> build bots and add libharfbuzz.so.0 in a way that dpkg-shlibdeps finds it.
We'll
> then work on upgrading the build bots to Trusty separately, where the
> libharfbuzz package exists. (I've prodded infrastructure folks on several bugs
> relating to distro upgrades.)

I think we should just wait for for the official bots to be updated to trusty.

Since this change drops support for running on precise, trying to build and
package it on precise seems rather backwards/pointless.

We are not in a hurry to make this change, so I think waiting for infra to
update the official builder so trusty should be ok.

[Sam Clegg, 2016-02-05 20:24:30]

On 2016/02/05 20:22:57, Sam Clegg wrote:
> On 2016/02/05 19:47:20, Lei Zhang wrote:
> > On 2016/02/04 22:02:26, Sam Clegg wrote:
> > > Can I see more of the error messages?
> > > 
> > > Is it relevant that the new version of pango now depends on harfbuzz so
> > harfbuzz
> > > was added to the sysroot...
> > 
> > I think we ran into some form of https://crbug.com/353127 - if I change the
> > GYP/GN logic to disable the usage of bundled harfbuzz, then it compiles.
After
> > which, we then hit packaging issues on Precise:
> > 
> > stable_rpm target - DEPS changes, not a big deal:
> > +libc.so.6(GLIBC_2.14)(64bit)
> > +libc.so.6(GLIBC_2.15)(64bit)
> > +libharfbuzz.so.0()(64bit)
> > +libstdc++.so.6(GLIBCXX_3.4.18)(64bit)
> > +libstdc++.so.6(GLIBCXX_3.4.19)(64bit)
> > 
> > stable_deb target - Precise does not have a libharfbuzz package, so we get:
> > 
> > dpkg-shlibdeps: error: couldn't find library libharfbuzz.so.0 needed by
> > /path/to/out/Release/chrome (ELF format: 'elf64-x86-64'; RPATH: '').
> > 
> > 
> > To get this CL to land in a sane manner, we probably need to take "official"
> > build bots and add libharfbuzz.so.0 in a way that dpkg-shlibdeps finds it.
> We'll
> > then work on upgrading the build bots to Trusty separately, where the
> > libharfbuzz package exists. (I've prodded infrastructure folks on several
bugs
> > relating to distro upgrades.)
> 
> I think we should just wait for for the official bots to be updated to trusty.
> 
> Since this change drops support for running on precise, trying to build and
> package it on precise seems rather backwards/pointless.
> 
> We are not in a hurry to make this change, so I think waiting for infra to
> update the official builder so trusty should be ok.

Also, we we sure that the bundled harfbuzz is not needed for some other reason? 
i.e. is it patched, or pinned to a specifically required revision?

[Lei Zhang, 2016-02-05 20:57:19]

On 2016/02/05 20:24:30, Sam Clegg wrote:
> Also, we we sure that the bundled harfbuzz is not needed for some other
reason? 
> i.e. is it patched, or pinned to a specifically required revision?

We can ask kochi / kojii about that.

The relevant changes are:
- remove the pangoft2_link_hack GN target
- remove the is_chromeos check for the use_system_harfbuzz variable in
third_party/harfbuzz-ng/BUILD.gn
- do the GYP equivalent

Let's wait on the Trusty upgrade then. The relevant bug is
https://crbug.com/564904

[jungshik at Google, 2016-07-20 21:44:35]

jshin@chromium.org changed reviewers:
+ jshin@chromium.org

[jungshik at Google, 2016-07-20 21:55:09]

On 2016/02/05 20:57:19, Lei Zhang wrote:
> On 2016/02/05 20:24:30, Sam Clegg wrote:
> > Also, we we sure that the bundled harfbuzz is not needed for some other
> reason? 
> > i.e. is it patched, or pinned to a specifically required revision?

Actually, we still need to bundle our copy of libharfbuzz because harfbuzz is
updated very frequently and Debian/Ubuntu is not good at keeping it up to date.
(the same is, to less degree, of FreeType; there's a proposal to statically link
FT). 


> 
> We can ask kochi / kojii about that.
> 
> The relevant changes are:
> - remove the pangoft2_link_hack GN target
> - remove the is_chromeos check for the use_system_harfbuzz variable in
> third_party/harfbuzz-ng/BUILD.gn
> - do the GYP equivalent
> 
> Let's wait on the Trusty upgrade then. The relevant bug is
> https://crbug.com/564904

[drott, 2016-07-21 07:38:44]

On 2016/07/20 at 21:55:09, jshin wrote:
> On 2016/02/05 20:57:19, Lei Zhang wrote:
> > On 2016/02/05 20:24:30, Sam Clegg wrote:
> > > Also, we we sure that the bundled harfbuzz is not needed for some other
> > reason? 
> > > i.e. is it patched, or pinned to a specifically required revision?
> 
> Actually, we still need to bundle our copy of libharfbuzz because harfbuzz is
updated very frequently and Debian/Ubuntu is not good at keeping it up to date.
(the same is, to less degree, of FreeType; there's a proposal to statically link
FT). 

Thanks for emphasizing this jshin@, we definitely need the shortest possible
roundtrip cycle between a HarfBuzz release and integration in order to always
include latest critical fixes.

[petarj, 2016-09-22 16:41:32]

Sam, can we expect the switch to debian/jessie to happen soon?
Using old linux sysroot images for mipsel starts to cause issues, and
the update is very welcome.

[Lei Zhang, 2016-09-22 17:07:52]

On 2016/09/22 16:41:32, petarj wrote:
> Sam, can we expect the switch to debian/jessie to happen soon?
> Using old linux sysroot images for mipsel starts to cause issues, and
> the update is very welcome.

We are still stuck waiting for some of the Chrome / Chromium infrastructure to
get off of Ubuntu Precise. :\

[Sam Clegg, 2016-09-22 18:59:10]

On 2016/09/22 17:07:52, Lei Zhang wrote:
> On 2016/09/22 16:41:32, petarj wrote:
> > Sam, can we expect the switch to debian/jessie to happen soon?
> > Using old linux sysroot images for mipsel starts to cause issues, and
> > the update is very welcome.
> 
> We are still stuck waiting for some of the Chrome / Chromium infrastructure to
> get off of Ubuntu Precise. :\

I've been away for 6 months, so I need to re-familiarize myself here.  I can't
remember how but I think perhaps the sysroot update is blocked on the host
system being updated as @thestig says.  I'll take a look not and update this PR.

[Sam Clegg, 2016-09-22 20:17:05]

The CQ bit was checked by sbc@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-22 20:18:06]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-22 20:18:07]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-22 20:18:08]

Dry run: Your CL was about to rely on recently removed CQ feature(s):
 * Specifying master names in CQ_INCLUDE_TRYBOTS part of description without
"master." prefix is no longer supported:
     tryserver.chromium.linux
   For more details, see http://crbug.com/617627.

[Sam Clegg, 2016-09-22 20:22:51]

The CQ bit was checked by sbc@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-22 20:23:32]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-22 20:23:33]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-22 20:23:34]

Dry run: Your CL was about to rely on recently removed CQ feature(s):
 * Specifying master names in CQ_INCLUDE_TRYBOTS part of description without
"master." prefix is no longer supported:
     tryserver.chromium.linux
   For more details, see http://crbug.com/617627.

[Sam Clegg, 2016-09-22 20:29:42]

On 2016/09/22 18:59:10, Sam Clegg wrote:
> On 2016/09/22 17:07:52, Lei Zhang wrote:
> > On 2016/09/22 16:41:32, petarj wrote:
> > > Sam, can we expect the switch to debian/jessie to happen soon?
> > > Using old linux sysroot images for mipsel starts to cause issues, and
> > > the update is very welcome.
> > 
> > We are still stuck waiting for some of the Chrome / Chromium infrastructure
to
> > get off of Ubuntu Precise. :\
> 
> I've been away for 6 months, so I need to re-familiarize myself here.  I can't
> remember how but I think perhaps the sysroot update is blocked on the host
> system being updated as @thestig says.  I'll take a look not and update this
PR.

Cloned into https://codereview.chromium.org/2361223002.

This change is so old the CQ seems to be broken somehow.