mozilla :: #build

14 Jul 2017
14:13larsberg(also asking here, in case #github is the wrong place)
14:13larsbergDoes anybody here know who might be the right contact to talk about travis capacity for the mozilla and mozilla-b2g github orgs? James Lal requested an increase back in 2014, and as part of putting together a master service agreement with them, we're auditing if we're using it and want to continue to do so.
14:13larsbergIt sounds like mozilla-b2g is (unsurprisingly) dead but mozilla is using all the extra capacity we are... borrowing :-)
14:18dmajorthank you to everyone who helped with the mac stuff to get the tree back open
15:05tjrI've got a gcc compilation problem I'm stuck on...
15:05tjrI am hitting this error when compiling mingw-gcc with my (new) build script - https://treeherder.mozilla.org/logviewer.html#?job_id=112801492&repo=try&lineNumber=17359
15:05tjr(In https://reviewboard.mozilla.org/r/155334/diff/5#index_header the new script is 'taskcluster/scripts/misc/build-gcc-mingw.sh' the old one that worked is 'taskcluster/scripts/misc/build-mingw-linux.sh')
15:05tjrI traced the error to https://stackoverflow.com/questions/31600600/compilation-error-stddef-h-no-such-file-or-directory and observed that gcc-objdir/./gcc/xgcc is version 5.1 but system gcc is 4.4.7
15:06tjrI'm not sure why that would cause a problem, but it does not match my other machines...
17:29zeeHi.. im trying to upgrade my application from firefox esr 38.7 to esr52.2.1
17:30zeebut when i build i get "No preprocessor found error" for rkioskbrowser.xul.. im adding rkiosk to the build
17:52nalexanderzee: are you actually getting http://searchfox.org/mozilla-central/source/python/mozbuild/mozbuild/preprocessor.py#322
17:52nalexanderzee: which is not what you wrote?
17:54zeeyes thats right
17:55rillianglandium: thanks for working on the rust jobserver bug. I was getting quite worried about that one.
17:57nalexanderzee: you are preprocessing the file that you list, but there are no actual preprocessor directives. The build system complains; you should stop preprocessing it, since it doesn't need to be preprocessed.
17:57nalexanderzee: that might mean removing the '*' in a `jar.mn` file.
18:00zeenalexander: thanks for the info.. ill try remove the '*' and build again .. im doing this the first time.. appreciate your help !!
18:00nalexanderzee: yw.
18:17mjfI need some help with the pip that is used in our build directory. Im currently seeing lines like: Using cached passlib-1.6.5-py2.py3-none-any.whl
18:17mjfI would like to clear pips cache in order to rebuild everything. Any thoughts?
18:17mjfAt the moment, Im in permafail for mochitests on OS X.
18:18* ng is also experiencing this issue ^
18:25nalexandergps: ^
18:29ngmjf: the build worked for you when you created a new user and bootstrapped there correct?
18:29coopgps is out this morning, should be back in a bit
18:30ngcoop: thanks
18:30mjfng: correct. Nothing else, including pulling a new repo in the old acct, and rebootstrapping after deleting every directory I could think of that was mozilla related has workd.
18:35brianMy patch for BUG 1380195 is failing the try build. Does anyone know what version of xz used for the official builds?
18:35firebothttps://bugzil.la/1380195 UNCONFIRMED, nobody@mozilla.org Fennec Build can produce XZ Files that are not compatible with Mozglue Elfloader
18:45Alex_GaynorWhat part of the build process is responsible for creating symlinks inside of $objdir/dist/NightlyDebug.app/Contents/Resources/components/ ?
18:50nalexanderAlex_Gaynor: it's browser/app/Makefile.in, the repackage target.
18:51Alex_Gaynornalexander: thanks
18:51Alex_Gaynoroh my, this is quite a make target
18:51nalexanderAlex_Gaynor: yeah, it's pretty terrible.
18:52nalexanderAlex_Gaynor: it's 'cuz it interacts with l10n. I'd like to see it be a Python script that accepts an l10n directory as a parameter rather than be shell.
18:52nalexanderglandium: do you know how `xz` gets onto the builders? I don't see it in the Task Cluster images.
18:52nalexanderDo we build xz-embedded during the buidl?
18:56Alex_Gaynornalexander: `rsync -a --exclude '*.in' $(srcdir)/macbuild/Contents $(dist_dest)` is the magic bit, yeah?
18:56nalexanderAlex_Gaynor: pretty much.
18:56Alex_GaynorOk, so really that's just copying the symlink into place. So who creates the original symlink :-)
19:10nalexanderAlex_Gaynor: the build system does, using things called install manifests.
19:10nalexanderAlex_Gaynor: you can see the simple cases (for things like components) in the |mach build faster| implementation.
19:11nalexanderAlex_Gaynor: http://searchfox.org/mozilla-central/source/python/mozbuild/mozbuild/backend/fastermake.py
19:11nalexanderAlex_Gaynor: then the Makefiles actually install / update the manifests at build time.
19:11Alex_Gaynornalexander: gotcha, thanks!
19:11nalexanderAlex_Gaynor: if you tell us what you are trying to achieve, we might be able to save you a lot of investigation.
19:12Alex_Gaynornalexander: I'm exploring what woudl be involved in https://bugzilla.mozilla.org/show_bug.cgi?id=1380416
19:12firebotBug 1380416 NEW, nobody@mozilla.org Investigate using hardlinks instead of symlinks in the dev build on mac/linux
19:27nalexanderAlex_Gaynor: in any case, the file that deals with the mechanics of the links is http://searchfox.org/mozilla-central/source/python/mozbuild/mozpack/copier.py#234
19:27nalexanderAlex_Gaynor: and as you can see, we really care about performance in that loop, so my guess is that my suggestion to always copy will be refuted with data :)
19:28nalexanderAlex_Gaynor: you'll want to add a new class sibling to http://searchfox.org/mozilla-central/source/python/mozbuild/mozpack/files.py#300
19:29Alex_Gaynornalexander: perfect, thanks
19:29nalexanderAlex_Gaynor: and use it around http://searchfox.org/mozilla-central/source/python/mozbuild/mozpack/manifests.py#347
19:44Alex_Gaynorit... appears to work
19:49Alex_Gaynorooop, no, one bug
20:52ngmjf, gps: update: on OS X, peerconnection mochitests work if I build in-tree (OBJDIR is not set), or I disable e10s when building out of tree. I need to step out for a few.
20:52mjfng: Im in the process of verifying that in-tree obj-dir fixes the mochitest failures.
21:11mjfng: gps: confirmed. peerconnection mochitests fail when setting MOZ_OBJDIR outside of the source tree.
21:14mjfng: gps: So next question: Is this potentially a sandboxing thing?
21:36nalexanderAlex_Gaynor: sounds like you would know ^
21:43Alex_Gaynormjf: macOS? Yeah, obj-dir-outside-source-dir is a known bug, one sec I'll find it
21:45mjfAlex_Gaynor: sigh - that bug just cost me 2 days
21:45Alex_Gaynormjf: https://bugzilla.mozilla.org/show_bug.cgi?id=1380132
21:45firebotBug 1380132 NEW, haftandilian@mozilla.com SSL info in url bar broken when launching from symlinked path or when objdir outside of repo
21:45Alex_GaynorSorry :-(
21:46mjf:-( not your fault though. Just couldnt figure out why a fresh build was suddenly failing without any of my changes.
21:59nalexanderAlex_Gaynor: there are two places to update in manifests.py; don't know if that's your lib* issue. (You may have seen both places searching for symlink.)
22:00nalexanderAlex_Gaynor: there are places in the build system that don't use install manifests (lots!); they use nsinstall, which I think will create symlinks if possible. You could change that script too to hardlink.
22:00nalexanderAlex_Gaynor: http://searchfox.org/mozilla-central/source/config/nsinstall.py, I think
22:00Alex_Gaynornalexander: cheers, I'll dig further in Monday
15 Jul 2017
No messages
   
Last message: 13 days and 39 minutes ago