1072026 - Suppress 'no version information available' messages from b2g build logs

Status: RESOLVED FIXED

(Release Engineering :: Applications: MozharnessCore, defect)

Description

[Nick Thomas [:nthomas] (UTC+12)]

Spun out from bug 1059992. We get a lot of this in b2g builds:

eg 15:55:15 INFO - /builds/slave/b2g_m-aurora_flm-kk_ntly-00000/build/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7/bin/../lib/gcc/arm-eabi/4.7/../../../../arm-eabi/bin/as: /lib64/libz.so.1: no version information available (required by /builds/slave/b2g_m-aurora_flm-kk_ntly-00000/build/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7/bin/../lib/gcc/arm-eabi/4.7/../../../../arm-eabi/bin/as)

This appears to be from the prebuilt being compiled on a newer OS than we're building on (per http://stackoverflow.com/questions/137773/what-does-the-no-version-information-available-error-from-linux-dynamic-linker). 

I want to suppress this because it adds no useful information, and pushes over the 50MB log limit we set in buildbot for some jobs. eg in a m-a flame eng job which is slightly over the 50M limit, we could save 8362034 bytes.

Comment 1

[Chris AtLee [:catlee]]

Can we make `as` shut up about this? or do you think mozharness should swallow it (convert it into a DEBUG line perhaps)?

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

Maybe with as -W:
  -W  --no-warn           suppress warnings

The flame builds are using 'GNU assembler (GNU Binutils) 2.22.90.20120727' at the moment.

Comment 3

[Mike Hommey [:glandium]]

That's not something as itself is outputing. That's the system dynamic linker complaining.
Essentially, it's telling you that the as program from the ndk was built against a libz.so.1 that has symbol versions, while the system libz.so.1 doesn't. There is no way to make the dynamic linker shut up for those, except to install a libz.so.1 that does have symbol versions.

Comment 4

[Chris AtLee [:catlee]]

Ok, so how about a mozharness output filter that identifies those lines and classifies them as DEBUG? They'd still end up in the raw and debug logs, but hidden from stdout/stderr captured by buildbot I think.

Comment 5

[Nick Thomas [:nthomas] (UTC+12)]

catlee pointed me at
http://hg.mozilla.org/build/mozharness/file/e52e8837783f/mozharness/mozilla/building/buildb2gbase.py#l36

Comment 6

[Camilo]

Hello Chris
I would be willing to work on this bug. If you are willing to provide me some guidance it would be great.

Comment 7

[Chris AtLee [:catlee]]

Hi!

So the basic idea here is to add an output filter that matches these 'no version information available' lines and categorizes them as DEBUG level output rather than INFO level output (which is the default).

You can test your mozharness changes on Try. Read up on this over at http://armenzg.blogspot.ca/2014/11/pinning-mozharness-from-in-tree-aka.html

Comment 8

[Camilo]

Attachment: no-version-information.patch

Hey Chris
Sorry for the huge delay ... studying + working doesn't leave a lot of free time :/

Here is a patch with the requested change for mozharness. I tested it on my computer and also on the travis server. You can check the log here (https://travis-ci.org/carocad/build-mozharness/builds/54752898)

Sadly I still don't understand how to do this step on the 'Try' server, to test the mozharness changes. I would appreciate if you could give me some more info there :)

PS: I also checked the github repo for the mozilla-inbound to see if I could clone it, but since it says that it is experimental, I avoided cloning it.

Comment 9

[Chris AtLee [:catlee]]

Patch looks good to me!

Regarding testing on Try, do you have access to push to try at the moment? Do you have an hg repository with mozharness with your patch landed?

If so, then you can edit testing/mozharness/mozharness.json in your gecko repository to point to your mozharness repository, and then push your change to try.

Comment 10

[Camilo]

Hey Chris
No, I don't have access to Try. I have filed a bug requesting access to the Try server (level 1). Here is the link: https://bugzilla.mozilla.org/show_bug.cgi?id=1144640. According to what I have read I would need your voucher to be granted access.

Regarding mozharness, yes I have a repository with the patch on it. I push it to the Try server as soon as I get access.

Comment 11

[Camilo]

Hey Chris
I pinned Mozharness as per instructions and push the changes to the try server. Here is the result: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6b6db5af7ef8

Nevertheless the address that I received in the email for the builds and logs, doesn't exist :/ I don't understand why https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-6b6db5af7ef8

Comment 12

[Chris AtLee [:catlee]]

Unfortunately the link given to you there is a bit misleading :\

If you click on the "B" label in treeherder, you can find a link to your log below:
http://ftp.mozilla.org/pub/mozilla.org/b2g/try-builds/[e-mail]-6b6db5af7ef8/try-emulator/b2g_try_emulator_dep-bm75-try1-build1118.txt.gz

Looks like it worked!

Comment 13

[Camilo]

oh great :)
So what would be the next step?

Comment 14

[Chris AtLee [:catlee]]

we land the patch!

I've pushed it here: https://hg.mozilla.org/build/mozharness/rev/e18f4351eb59

It will be included in a deployment in the next few days.

Thanks!

Comment 15

[Chris Cooper [:coop] (he/him)]

mozharness production tag moved to: https://hg.mozilla.org/build/mozharness/rev/8faa188c6306

Comment 16

[Camilo]

Shouldn't this bug be closed?

Comment 17

[Nick Thomas [:nthomas] (UTC+12)]

Yes indeed, thanks for the patch!

Comment 18

[Nick Thomas [:nthomas] (UTC+12)]

I needed to apply this fix to older b2g branches too.

https://hg.mozilla.org/build/mozharness/rev/6e837586892b
https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/7280924bba4c
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/03bfe12e50d0
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/cfbc39850ff2

The last is a fairly scary jump from mozharness 5d24cd109af6 (production branch on March 10), but 2_1 is was using the mozilla-b2g37_v2_2 branch already so hopefully it'll be OK.