mozilla :: #build

10 Aug 2017
01:13glandiumgps: I find it funny that you're now complaining about imports when you're the one who doesn't like imports in functions
01:14gpsglandium: eh? i've always said that mach_commands.py should lazy import
01:14gpsthat and import cycles are the main exceptions for my rule
01:14gpsor other high-perf areas
01:17tedmshal: have you seen whatever it is this guy is doing with tup? https://twitter.com/fasterthanlime/status/895310749815459841
01:19glandiumted: what the hell is he doing?
01:19tedI think trying to make it work in WSL
01:20tedjudging from prior tweets
01:20glandiumoh, apparently he's porting the LD_PRELOAD code
01:28mshalted: nope, haven't seen that before :)
01:46glandiummshal: I was testing something simple with tup, why does the order of the rules matter?
01:47mshalit puts the outputs into the database of available files as it processes them, so that *.o as an input would match files that don't exist yet
01:47glandiummshal: I'm not even using globs
01:47mshaladmittedly it's pretty dumb and should be fixed
01:48mshalwell, it has a check that any input you list is valid at parse time
01:48glandiummshal: my Tupfile is 2 lines. 1st: "foo.h |> cp foo.h test.h |> test.h" ; 2nd: "test.c test.h |> gcc test.c -o test |> test"
01:48glandiumit doesn't work if I put the 2nd line first
01:49mshalwhen it is looking at 'test.c test.h' as the inputs, it checks if they're files, or listed as outputs in previous rules when it parses the line
01:50glandiummshal: the resulting error is not particularly telling, btw
01:50glandiumtup error: Explicitly named file 'test.h' in subdir '.' is scheduled to be deleted (possibly the command that created it has been removed).
01:51glandiumso, anyways, rules that produce inputs need to come before rules that consume them
01:51glandiumcoming from makefile, it feels like a weird limitation
01:51glandiumI can see how it makes things simpler for tup, though
01:52mshalahh yeah, that's confusing... that message is intended for the case where you delete a rule (thinking it is no longer needed) and then tup finds another rule that is trying to use that output
01:52mshalagreed - for explicit files like you're doing it should be easy to remove the limitation in tup
01:52mshalI haven't figured out how to get it to work with the way tup handles wildcards, though
01:53mshalit's one of those unfortunate design decisions from early on that has stuck around :/
02:33glandiumI surely hope we're not actually building that extra zlib we got rust vendoring... because https://github.com/alexcrichton/libz-sys/issues/22
02:49nthomasdoes anyone know the magic to get a tc-based try build to upload dump_syms as an artifact ?
02:50glandiumnthomas: add it to UPLOAD_FILES in toolkit/mozapps/installer/upload-files.mk
02:50nthomasoh, that's the same. nice
02:50nthomasthanks
02:51glandiumRyanVM: what chain of trust issues prevent windows builds from being retriggered?
02:51RyanVMask aki
02:51RyanVMbasically TH retriggers break signing
02:52RyanVMwhich all TC windows builds now do
02:52RyanVMyou need to retrigger the task instead, which only a few people have scopes to do
02:52glandiumoh, I thought that was related to toolchain jobs
02:52RyanVMno, this is all in TC
02:53glandiumah, because the retrigger gets a new taskid, and the dependency chain for signing is not reproduce with the new task
02:53RyanVMso yeah, windows retriggering is basically broken right now and the jobs are more failure-prone than one would like
02:53glandium... but that's not chain of trust, so must be something differnet
02:54RyanVM"Part of Chain of Trust verification is making sure the task definition hasn't been altered since the decision task generated the graph. This would prevent all retriggers, but I added fuzzy matching [2] to allow for altered datetimes and taskIds. This means the first retriggered task will not fail chain of trust verification."
02:54RyanVM"However, the retrigger action task also retriggers all downstream dependent tasks. These will be altered from the original task definition, because task.dependencies will contain the new retriggered taskId, and task.payload.upstreamArtifacts and environment variables like SIGNED_ZIP will also point at different upstream taskIds. This means any downstream chain of trust verification will fail."
02:54RyanVMhttps://bugzilla.mozilla.org/show_bug.cgi?id=1384134
02:54firebotBug 1384134 NEW, nobody@mozilla.org Chain of Trust verification error! Can't find task signing:decision
02:54glandiumfnu
02:55RyanVMspeaking of which, look at that, another 4 broken windows builds I can't retrigger on the latest push to Beta
02:56glandiumabort: repository /home/worker/checkouts/gecko: timed out waiting for lock held by 91e29503d485:7
02:57glandiumthat's a funny one
02:57RyanVMbroken decision task?
02:57glandiumgps: ^
02:57glandiumRyanVM: yup
02:57RyanVMbug 1297153
02:57firebothttps://bugzil.la/1297153 NEW, nobody@mozilla.org Detect and recover from active locks and transactions
03:00glandiumgreat, and the retrigger got the same machine
03:00glandiumat least it's busy, which means another retrigger won't get it
03:02glandium\o/ woohoo got another poisoned one
03:04glandiumthird retrigger's the charm
03:17gpsSIGKILL FTL
09:36AutomatedTesterwhen doing a build I get this when the compiler goes through media
09:36AutomatedTester 3:31.23 warning: unknown warning option '-Wno-discarded-qualifiers'; did you mean '-Wno-ignored-qualifiers'? [-Wunknown-warning-option]
09:36AutomatedTester 3:31.23 warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean '-Wno-uninitialized'? [-Wunknown-warning-option]
09:36AutomatedTester 3:31.23 2 warnings generated.
09:36AutomatedTestershould I raise a bug for this or is it something we dont really care about?
10:00tedAutomatedTester: file a bug
10:00tedseems to be from here: https://dxr.mozilla.org/mozilla-central/source/media/ffvpx/ffvpxcommon.mozbuild#48
10:01tedfroydnj added that not long ago though: https://hg.mozilla.org/mozilla-central/rev/f0838868d075
11:41AutomatedTesterted: https://bugzilla.mozilla.org/show_bug.cgi?id=1389044
11:41firebotBug 1389044 NEW, nobody@mozilla.org Numerous "unknown warning option" notifications when building
11:42tedthx
11:42AutomatedTesterted: if you're happy to mentor I will take a stab at fixing
11:42tedwe've got a bunch of stuff in moz.configure for detecting whether warnings are supported
12:16tedmshal: https://github.com/fasterthanlime/tup-fuseless
13:17SylvestreChrome is now using clang on mac, linux & windows
13:18Sylvestremaybe, at some point, we should stop supporting 3 totally different compilers ...
13:30glandiumSylvestre: see the thread on dev-platform where I gave perfherder links
13:36Sylvestreok, I stopped reading the more rust code thread
13:37Sylvestreafaik, google didn't see these drop switching from msvc => clang, au contraire
13:37Sylvestremaybe they started to use proprietary versions of clang
13:41RyanVMOOC, what's keeping us from using clang on Linux?
13:43SylvestreRyanVM, a reason to do it
13:44RyanVMonly having to support 2 compilers? :P
13:44Sylvestre+1
13:44Sylvestrewe require clang now for bindgen now anyway ..
13:48* ted reviews glandium's sccache patch, understands why it took as long as it did
13:48tedRyanVM: i had this discussion with ehsan and jrmuizel a while ago, they were both on board with requiring clang
13:49Sylvestreted, about review, when you have 20 secs, could you r+ https://reviewboard.mozilla.org/r/164394/diff/2#index_header ? (trivial patch and this is the last of the list :)
13:49tedSylvestre: need to finish reviewing this sccache patch first
13:49Sylvestreted no worries, thanks
13:50tedi'm about a week behind on reviews in general
13:50SylvestreI created it a week ago, so, perfect timing :)
13:51tedhah
14:22ehsanted, iirc the last time this came up (which was years ago) glandium was opposed to it
14:22ehsanted, and there is also distros
14:23tedyeah
14:23tedit's at least more compelling if we switched on windows as well
14:23tedsupporting a single compiler across all platforms is a pretty good sell
14:23ehsan(and I don't understand why in 2017 we can't build with a compiler of our choosing rather than what $CC tells us...)
14:23ehsanbut I'm so tired of arguing over this
14:23tedalso i assume glandium's argument was about various weirdo architectures that LLVM didn't support, and we've crossed that bridge with rust anyway
14:24ehsanted, linux not switching would make pushing on windows switching a lot less appealing, so it's a circular argument I'm afraid
14:25ehsanted, do not care :)
14:25tedhah
14:25ehsan(about those weiro architectures)
14:27tedi can't imagine there are any linux distros that don't have clang packages at this point
14:28tedso it's really just whatever tier-3 platforms
14:28tedbut yeah, having this argument is tiring
14:28tedlet's just move everything to rust and move on in life
14:35Sylvestreehsan_, you can use different compilers in debian & ubuntu for example
14:35SylvestreI have people using clang to build their packages because gcc OOM
14:38ehsan_Sylvestre, chromium has a more grown up build system which actually knows what the right compiler for each revision is
14:39ehsan_Sylvestre, so even if you try to build it on a platform without clang it can pull it as a prerequisite for you
14:39ehsan_(last I checked at least)
14:39ehsan_this, plus the fact that LLVM can be built from source with any C++11 (14?) compiler should in theory fix all distro pains
14:43tedchromium's not actually using bazel or anything, they just have wrappers around ninja
14:44tedwe have all the pieces to do this nowadays, we are pulling in llvm that way for bindgen
14:45ehsan_bazel? no
14:45ehsan_did I suggest that? :)
14:47ehsan_ted, http://julio.meroh.net/2015/04/on-bazel-and-open-source.html :)
16:08* froydnj grumbles about cargo's "test" profile
16:09froydnjhaving a separate "test" profile means that you are basically forcing recompilation for one of release or debug if you compile tests
16:09froydnjsuch a silly policy
16:09snorpanyone know who knows things about the single-locale repacks for fennec?
16:09snorpbug 1372911
16:09firebothttps://bugzil.la/1372911 NEW, nobody@mozilla.org Single locale builds on Beta 55 don't open
17:17Pikegps, got some cycles for the review of bug 1385227 ?
17:17firebothttps://bugzil.la/1385227 NEW, nobody@mozilla.org Make l10n repack builds do what they're supposed to do
17:19gpsPike: today, no. i have a fire drill today.
17:20gpsdetails of that fire should become apparant in ~40 minutes :)
17:22Pikeoy
17:56snorpso I'm trying to build for desktop on linux
17:57snorpand I'm hanging during rust build
17:57snorpfor gkrust
17:57snorphttps://irccloud.mozilla.com/pastebin/0atWZ64r/
18:00froydnjsnorp: it just takes a while
18:00snorpfroydnj: but rustc is nearly idle
18:00snorpfroydnj: also, things don't build with the gcc in fedora 26
18:00snorphow do I make it use the clang that bootstrap downloads
18:01snorpenough to set CC/CXX?
18:01froydnjsnorp: yes
18:01froydnjsnorp: is that gcc 7?
18:01snorpfroydnj: aka the worst gcc ever, yes
18:02snorprust seems to be trying to use my system clang, hmm
18:06froydnjsnorp: oh, like use the clang that bootstrap downloads for the stylo bits?
18:07snorpfroydnj: is that what it's for
18:07froydnjsnorp: that is the idea, yes
19:53Sylvestreis there an option to refuse the download of clang binary ?
19:53Sylvestre(in the bootstrap)
19:58froydnjno
19:58froydnjSylvestre: ^
19:59Sylvestreok :(
20:14dmajorfroydnj: your no-lto patch only adds 400k to my xul.dll, on windows
20:16Sylvestreis there a way in moz.build file to do some thing like if '-Wnoexcept-type' in flags:
20:16Sylvestre CXXFLAGS += ['-Wno-error=noexcept-type']
20:16Sylvestre ?
20:16froydnjdmajor: that's a big difference between platforms!
20:16Sylvestrenoexcept-type only exists in gcc7 and I would like to force the desactivation on a file
20:18tedSylvestre: i don't believe so, no
20:18tedthat only exists in WARNINGS_CFLAGS or whatever it's called
20:36Sylvestrewhich doesnt seem to be accessible from moz.build
20:40tedright
20:52glandiumRyanVM: "what's keeping us from using clang on linux?" see the thread on dev-platform where I gave perfherder links
20:52glandiumand that's clang trunk against gcc 4.9, aka an old gcc
20:53glandiumI'm preparing to upgrade our builds to gcc 6
21:02froydnjdmajor: was that 64-bit or 32-bit?
21:02dmajor64
21:02froydnjdmajor: and 400k out of how much?
21:02dmajorseventy-someodd megs
21:03dmajorthe last paragraph of alex's post on internals just now has a plausible explanation
21:03glandiumELF sucks
21:03froydnjdmajor: amusingly enough, I was going to post your numbers as a fwiw
21:05glandiumfroydnj: btw, are your numbers from fully packaged firefox?
21:05froydnjglandium: my numbers were from my firefox nightly and a pgo build on try, so I assume so?
21:06glandiumok
21:08glandiumted: ping
21:16tedglandium: pong (leaving soon)
21:18glandiumted: I'd like feedback on my comments to your review, so that I know how to go forward with the patch
21:19tedOK
21:20tedglandium: i replied to a few of them earlier, is there anything left i hadn't? i just replied to the to_str one
21:20tedglandium: the only thing that i really wanted changed was the `pub use <enum>::*`
21:21tedi think `use <enum>::*` at the module-level is fine, but publicly re-exporting those isn&#39;t great
21:21tedglandium: but honestly at this point with the size of that patch and the fact that it unblocks updating the OS X SDK I could live with fixing that in a followup
21:22tedi&#39;m heading out, i&#39;ll stop back in later tonight briefly
21:23gpshttp://gecko-docs.mozilla.org.s3.amazonaws.com/index.html huzzah!
21:24gpsnow i need to create a proper hostname for it
11 Aug 2017
No messages
   
Last message: 67 days and 23 hours ago