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)?
Maybe with as -W: -W --no-warn suppress warnings The flame builds are using 'GNU assembler (GNU Binutils) 184.108.40.20620727' 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.
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
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.
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.
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.
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://firstname.lastname@example.org
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://email@example.com/try-emulator/b2g_try_emulator_dep-bm75-try1-build1118.txt.gz Looks like it worked!
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!
mozharness production tag moved to: https://hg.mozilla.org/build/mozharness/rev/8faa188c6306
Shouldn't this bug be closed?
Yes indeed, thanks for the patch!
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.