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

RESOLVED FIXED

Status

Release Engineering
Mozharness
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: nthomas, Assigned: Camilo, Mentored)

Tracking

unspecified
x86
All

Firefox Tracking Flags

(b2g-v2.0 fixed, b2g-v2.1 fixed, b2g-v2.1S fixed, b2g-v2.2 fixed, b2g-master fixed)

Details

(Whiteboard: [simple][lang=python])

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
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.
Can we make `as` shut up about this? or do you think mozharness should swallow it (convert it into a DEBUG line perhaps)?
(Reporter)

Comment 2

3 years ago
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.
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.
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.
(Reporter)

Comment 5

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

Updated

3 years ago
Whiteboard: [simple][lang=python][good first bug][mentor=catlee]
Mentor: catlee@mozilla.com
Whiteboard: [simple][lang=python][good first bug][mentor=catlee] → [simple][lang=python][good first bug]
(Assignee)

Comment 6

3 years ago
Hello Chris
I would be willing to work on this bug. If you are willing to provide me some guidance it would be great.
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

Updated

3 years ago
Whiteboard: [simple][lang=python][good first bug] → [simple][lang=python]
(Assignee)

Comment 8

3 years ago
Created attachment 8578781 [details] [diff] [review]
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.
Flags: needinfo?(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.
Flags: needinfo?(catlee)
(Assignee)

Comment 10

3 years ago
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.
(Assignee)

Comment 11

3 years ago
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/carocad@unal.edu.co-6b6db5af7ef8
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/carocad@unal.edu.co-6b6db5af7ef8/try-emulator/b2g_try_emulator_dep-bm75-try1-build1118.txt.gz

Looks like it worked!
(Assignee)

Comment 13

3 years ago
oh great :)
So what would be the next step?
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!

Updated

3 years ago
Attachment #8578781 - Flags: review+
Attachment #8578781 - Flags: checked-in+
mozharness production tag moved to: https://hg.mozilla.org/build/mozharness/rev/8faa188c6306
(Assignee)

Comment 16

3 years ago
Shouldn't this bug be closed?
(Reporter)

Comment 17

3 years ago
Yes indeed, thanks for the patch!
Assignee: nobody → carocad
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
(Reporter)

Comment 18

3 years ago
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.
status-b2g-v2.0: --- → fixed
status-b2g-v2.1: --- → fixed
status-b2g-v2.1S: --- → fixed
status-b2g-v2.2: --- → fixed
status-b2g-master: --- → fixed
You need to log in before you can comment on or make changes to this bug.