mozilla :: #releng

7 Aug 2017
05:42travis-cibuild-buildbot-configs#2800 (master - 02a8136 : Justin Wood): The build passed. (
05:49travis-cibuild-buildbot-configs#2801 (production - 14a846c : Mihai Tabara): The build passed. (
07:35Tomcat|sheriffdutyaselagea|buildduty: hi
07:35Tomcat|sheriffduty[09:26am] whimboo: 22:44:42 INFO - uses an insecure transport scheme (http). Consider using https if has it available
07:35Tomcat|sheriffduty[09:26am] whimboo: so a releng issue
07:35Tomcat|sheriffduty[09:27am] whimboo: seems to happen for all packages we are trying to download from our internal mirror
07:35Tomcat|sheriffdutydo you know whats going on or if there is a known failure ?
07:36* aselagea|buildduty looks
07:38Tomcat|sheriffdutyaselagea|buildduty: is a example of the failure
07:48aselagea|builddutyTomcat: I can see the same warning for jobs older than one week
07:48aselagea|builddutyI assume that's a known thing
07:48Tomcathm seems this jobs are new from today
07:49Tomcataselagea|buildduty: doing now retrigger to check if this is just a code regression somehow
07:49aselagea|builddutyTomcat: do you think the failure above is related to the warning message about using http instead of https?
07:49Tomcataselagea|buildduty: hm not sure whimboo pointed me to this
07:49Tomcatmight be a http vs https issue
07:52whimbooits only on OSX btw
07:52whimboomaybe the TC folks made some changes?
07:52aselagea|builddutywhimboo: would be worth asking in #taskcluster
07:53whimboo pip 1.5.5 from /Users/cltbld/tasks/task_1502083007/build/venv/lib/python2.7/site-packages/pip-1.5.5-py2.7.egg (python 2.7)
07:53whimboowhy do we download such a very old release
07:53aselagea|builddutyfrom what I can see, the warning message when trying to download from our internal pypi is not something new
07:54Tomcat|sheriffdutyaselagea|buildduty: hm now formerly green task fail too
07:57whimboowe only have 0.8.2 and 1.5.5 on our internal mirror
07:57whimbooand there is Using partial env: {'VIRTUALENV_NO_DOWNLOAD': '1'}
07:58whimbooi wonder which virtualenv release it tries to use
07:59whimbooTomcat|sheriffduty: i will file the bug for now
08:03whimbooTomcat|sheriffduty: so you can star against bug 1387970
08:03firebot NEW, Intermittent pkg_resources.DistributionNotFound: requests ( use
08:05Tomcat|sheriffdutywhimboo: hm maybe would be good to n-i some people or ?
08:05Tomcat|sheriffdutydustin at least i guess
08:05whimbooi asked pmoore
08:05whimboooh, wiat... pmoore|PTO-back-aug21
08:05whimboowho else is up earlier
08:05Tomcat|sheriffdutycatlee is out till aug 14
08:05whimboowcosta then
08:06Tomcat|sheriffdutythanks whimboo
08:07whimbooi will try to check with a one click loaner
08:09whimboolet me also check on beta
08:10whimboohm, no one click loaner for os x yet :/
08:11whimbooTomcat|sheriffduty: cross branches
08:11whimbooso clearly a change for the worker I would assum
08:12whimbooaselagea|buildduty: do we know if we had more recent versions of pip on our internal mirror?
08:12whimboomaybe someone deleted it?
08:12whimbooi will check some passing tests
08:12mtabarawhimboo, Tomcat|sheriffduty: could it be ?
08:13Tomcat|sheriffdutyi think would match timewise
08:15mtabarawe can easily test the culprit if we a) remove the files added this morning or just `requests-2.18` to being with b) rerun some of the failing tasks.
08:15whimboomtabara: it happens for different packages
08:15aselagea|builddutythere's only pip 0.8.2 and 1.5.5..and from what I know, we only use the latter
08:15whimbooalso for mozsystemmonitor==0.3
08:15whimboowhich hasn't been updated
08:15whimbooyes, passing tests also use 1.5.5
08:17whimboooh wait
08:17whimboo uses an insecure transport scheme
08:17whimboois just a info
08:18aselagea|builddutyyeah, it's a warning message
08:20whimboomtabara: so yes, this bug might be related
08:20mtabaralet me remove at least requests for just a minute and see if rerunning tasks result in green.
08:25mtabaraok, out of the packages that I added, looks like certifi, chardet, idna, urllib and requests got picked-up by latest version.
08:27whimboomtabara: k, should I retrigger a job?
08:28mtabarawhimboo: 1min, I haven't deleted yet. also, i can rerun it should you want me to, no need to recreate it by retriggering
08:28whimboomtabara: k, so let us know. thanks
08:52mtabarawhimboo, Tomcat|sheriffduty: removing requests + rerunning worked for that particular tasks. if you have other tasks running different tests or whatsoever, let me know.
08:53mtabarathis sounds like a separate problem, mozharness script or alike
08:54whimboomtabara: good. now I wonder how to best reproduce it locally
08:54whimboomtabara: i will try it once I'm through bug mail
08:54whimboomtabara: can we leave it removed for now?
08:56mtabarawhimboo: yes. not sure though how urgent that requests-2.18.3 is edmorley
08:56mtabara*is for edmorley
08:58mtabarawhimboo: mind if we close the current bug or change component though? It's not buildduty related anymore. if it's RelEng, it should stay under Mozharness, if its different, not sure though where to put it
08:58whimboomtabara: lets do mozharness for now
08:58whimboobut I'm not sure either
08:58mtabaraok, sgtm, thanks!
08:58whimboomaybe we have to release mozinstall
08:59whimboothe requests addition was lately, and is not in a public release yet
09:00whimboomtabara: i will move
09:01mtabarawhimboo: ah, my bad, already pressed the buttons :P
09:01whimbook, reloading
09:02aselagea|builddutymtabara: thanks!
10:55heftigis the 55.0 release on ftp still just a rc that could be replaced?
12:10whimboomtabara: out of interest... what is WNP for updates?
12:16Callek"Whats New Page"
12:29* mtabara nods along
13:23CallekFYI - I just had sheriff close try due to
13:23firebotBug 1387407 NEW, pushlog for Try isn't showing pushes for recent commits
13:36Callekjmaher: yea, looks like try's pushlog is broken
13:38jmaherCallek: fun times
13:40jmaherCallek: this looks really hard to solve in buildbot-configs
13:40jmaherCallek: the mochitest-jetpack-clipboard
13:40Callekdamn :/
13:41PikeI'm pretty sure try knows when I'm hacking on l10n builds
13:44Callekjmaher: I can probably come up with a really hacky fix for in buildbot ;-)
13:45jmaherCallek: ok, I think you would be better served at it than me. Why I think it is tricky-
13:45Calleksomething pseudo code like "for branches if gecko_version > 56: if suite == mochitest-clipboard: suite['extra-args'].sub('jetpack-package-clipboard', '')`
13:45jmaher1) it is used for e10s tests on at_least v.46
13:45jmaher2) enabled for try
13:45jmaheroh, that is good!
13:47Callekits not a solution I'd be ok with if buildbot were sticking around, but if we can write a quick hack rather than a more involved, multiple-repo fix, I think I'm going to go with quick hack :-)
13:51jmaherCallek: I do think it is interesting that we had ~10K of hacky buildbot-config code to run all our automation, and I think when we are done with the migration we will have ~10K of taskcluster code
13:53Callekjmaher: well the TC code will be much much easier to maintain/edit/change
13:53Callekbuildbot was very very constraining, we've already done MUCH more with TC, much easier than we ever could with buildbot
14:02jmaherCallek: true, although I am finding that we are hitting odd exceptions and having to do funky hacks
14:03Callekmuch of that "odd exceptions" and "funky hacks" are just because we're still in the mid-transition, and a bunch of that can (and imo should) be cleaned up heavily once we can say we're off buildbot
14:05jmaherI think we will have those hacks in place for a while given ESR timelines
14:11Callekwell once all <branch> is off buildbot we don&#39;t need in tree stuff for <branch> to care about buildbot :-)
14:15CallekPike: try is open again ;-)
14:15jmaheryay for try being open again!
14:18Callekjmaher: do we want/need that bb mochi-clipboard change for 56 (beta) too?
14:18Callekjmaher: or is it just 57 at this point?
14:19jmaherCallek: just 57
14:19jmaherlast week most of the jetpack tests were removed thanks to web extensions by default for 57
14:19Callekjmaher: so, we want mochi-clipboard running on 56, just with the jetpack stuff there...
14:19Callekmakes sense
14:20jmaherCallek: clipboard needs to run on all branches, esr,release,beta will include jetpack-package-clipboard, and trunk (57) will not have any jetpack-package-clipboard
14:22Calleksfink: mrgiggles isn&#39;t monitoring try. (tomcat flapped try and no mention of it in #treestatus)
15:01Callekphilor: elaborate?
15:01Callekphilor: ooooo we stopped it!?
15:01* Callek grumbles
15:02philornot this time, this time it broke and we lack any monitoring to cause us to tell core::security it broke
15:03Callekoooooo, broke is even sadder...
15:03philorJavaScript error: /builds/slave/m-cen-l64-periodicupdate-00000/getHSTSPreloadList.js, line 22: NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIXPCComponents_Utils.import]
15:08Callekphilor: have the log link handy?
15:08Callekor the bug
15:12philorfor the way it broke on the 25th, or the separate way it has been broken since the 26th?
15:14Callekis there two ways?
15:14Callekon the bright side, I want to move the scheduling of that to TC this quarter, which if I am right would have a side affect of the job *always* showing on treeherder ;-)
15:17Pikedo we test stub installer build and repacking on try?
15:18CallekPike: no, but its possible actually
15:18Callek(*should be*)
15:18CallekPike: if you use the `./mach try fuzzy` support, anyway. Sorta.
15:19CallekPike: nightly stuff is not exposed to mach try fuzzy yet, but if you manually edit the .json like ./mach try fuzzy would produce, you can add a nightly repackage job which would do stub installer
15:19CallekPike: noteworthy of course is that stub installer is guarded in tree on update channel, and hardcodes against m-c... so there is some extra patching required
15:22PikeI wonder if I should really pile things I don&#39;t know on things I don&#39;t know
15:22CallekPike: that hardcodes against m-c is the stub installers &quot;what to download&quot; url so the hardcode won&#39;t hurt if you just want to be sure it builds
15:22Callekjust make sure that update channel block executes as true for your try job if you want to test it there :-)
15:23CallekPike: but, regarding `./mach try fuzzy` the logic ends up being just &quot;write out a json file like this, with the task labels for the jobs you want to run&quot; --
15:23Callekbut it uses nicer UX for humans to wrap it ;-)
15:25* Pike tries once more on his local VM
15:25Pikeit&#39;s just 5 mins
15:25* Pike curses vmware
16:34Callekrstrong: ping
16:34rstrongCallek: hi
16:34Callekrstrong: soo, we&#39;re testing the WNP for 55.0 and I&#39;m getting very confused
16:35rstrongCallek: can you give me the steps for testing
16:35Callekrstrong: if we install 53.0.3 and update to 54.0.1 we get the 54 WNP, then if we switch the channel to release-cdntest and update to 55.0 it gets a WNP with version &quot;54.0/.../OLDVERSION=54.0.1&quot;
16:35Callekrstrong: however if I first install 54.0.1 and launch, close, switch channel, update, restart I get no WNP at all
16:35rstrongCan you give me the steps you are using for testing
16:36Callekthe balrog results look correct
16:36rstrongCan you give me the steps you are using for testing
16:36* Callek suspects irccloud is also messing up and saying your entries are not &quot;sending&quot;
16:36jmaherCallek: are you able to review buildbot-configs changes?
16:36Callek(I saw it elsewhere)
16:37Callekjmaher: yes, but I generally avoid it these days
16:37jmaherI had a review for k.moir, but it is canada day
16:37jmaherCallek: if you are ok with it, there is a patch up at
16:37firebotBug 1383789 ASSIGNED, Enable Stylo Talos tests on more desktop platforms
16:37Callekjmaher: ok, I&#39;ll peek in a few moments
16:38jmaherCallek: thanks!
16:38Callekrstrong: my update url, from 54.0.1 -> 55.0 -- afaict
16:39rstrongCallek: what are the steps that are being used to test so I can test it vs. trying to visualize everything in my head.
16:39Callekmy current &quot;left field&quot; theory is that the updater metadata that is used from 53.0.3->54.0.1 gets stored, and is not overwritten in 54.0.1->55.0&#39;s update, and thus the code that determines us to show a WNP is actually dependent on the update from 53.0.3
16:39rstrongsimilar to steps to reproduce in a bug.
16:40Callekrstrong: download 53.0.3 --> open in fresh profile (dismiss any errant tabs) --> update --> close firefox --> set update channel to &quot;release-cdntest&quot; --> open firefox --> update again --> expect to see a WNP with &quot;;
16:41Callekrstrong: and seperately: download 54.0.1 --> open in fresh profile (dismiss any errant tabs) --> close --> set update channel to &quot;release-cdntest&quot; --> open firefox --> update --> expect to see a WNP with same url as above
16:42Callekactual is from original of 53.0.3 you get -- and from 54.0.1 you get no WNP at all
16:42Callek(and yes, I confirmed that if I close the WNP after the 53.0.3 -> 54.0.1, and then close and restart firefox, it doesn&#39;t come back up into my tab strip)
16:46rstronglooking... downloading 53.0.3 and 54.0.1 which is for some reason slow
17:00selenamariewin goto #developers
17:00selenamarieoops :)
17:02PikeCallek: so, fuzzy has neither l10n nor nightly ?
17:02CallekPike: no[t yet] -- can add teh stuff to the .json manually though
17:02CallekPike: one example where I used that for a push was
17:07PikeCallek: how can I find out my options?
17:07CallekPike: `mach taskgraph full -p <parameters file>`
17:08CallekPike: can take a param file from an m-c decision task
17:09CallekPike: that try push I pointed at has patches that make some l10n work that would be otherwise broken on try right now...
17:09Piketbh, this is all above my head
17:10CallekPike: shall we backup then and I just hand you a fish?
17:10CallekPike: what are you trying to test, and what do you think you need
17:12PikeCallek: pushed to try so that we have something to work on:
17:12CallekPike: ok, you want to have an l10n repack for all platforms, that goes all the way down through installer generation, is that accurate?
17:13PikeI&#39;ll want android multilocale nightlies, which, IIRC, I can trigger through treeherder
17:13CallekPike: ok, android multi-locale and desktop-all :-)
17:13Pikelinux l10n builds are in the taskgraph, as are android l10n builds
17:14CallekPike: you likely need to make osx and android stuff work
17:14Pikesomehow, the tc windows and osx builds don&#39;t work the way the linux builds do
17:15Pikeit&#39;s OK if they repack the latest nightly from ftp. For this patch, I don&#39;t need the actual round-robin
17:16Callekit could break due to trying to download from non target.tar.bz2 and such
17:17Pikelinux works, just windows and osx fail with that, filed bug 1386537
17:17firebot NEW, L10n try builds shouldn&#39;t set EN_US_PACKAGE_NAME to target.*
17:17CallekPike: ok, you want &quot;set of things on your push&quot; + &quot;android multi locale&quot; and &quot;windows installer / l10n stuff&quot;
17:18CallekPike: yea my patch helps fix that for at least OSX
17:18* Callek thinks win will be fixed too this way)
17:22mtabaraCallek: yeah, did the same 54.0.1 on mac as well with fresh profile and get the 55.0 correctly but not the WNP
17:23CallekPike: if you put this in the root of your source tree as `try_task_config.json` and push to try (without a try: message!) you should get nightlies for all desktop platforms, + l10n for all platforms, including an android multi-locale nightly
17:24CallekPike: and yea that android fail on my try push was because I had pushed it to test a patch glandium was making (he&#39;s fixed that issue on his patch)
17:25CallekPike: if there are issues unrelated to your patch on the try push using that try_task_config.json I just handed you, you can let me know and I&#39;ll work on fixing them
17:25Callek[its high on my list to make all l10n easily testable on try]
17:26Callekrstrong: any luck reproducing the issue yet?
17:26rstrongCallek: yes, trying to figure out what&#39;s going on.
17:27rstrongCallek: chances are there is nothing I can do about this for this release so I&#39;ll file a bug.
17:29PikeCallek: decision task failed with a 403,
17:31mtabararstrong: thanks for your help. can you please link whatever bug you fill chained to 1386224 as well for reference?
17:31Pikelooks like bug 1386544
17:31firebot NEW, Action task fails with missing scopes when trying to trigger new-style l10n builds
17:36CallekPike: was it the decision task though?
17:37CallekPike: woa that looks *really* odd to be
17:38Pikeyep, even
17:38Pikesame thing I got a couple of days ago when trying to trigger those builds through th
17:39Callekthrough TH wouldn&#39;t shock me, but here it shocks me
17:41* RyanVM idly wonders if that push to Try he did from Beta will try to run tests off the broken buildbot builds or the working TC ones
17:42CallekRyanVM: if beta 56 TC builds, if 55 BB
17:42RyanVM56, great
17:42RyanVMI see them in the decision task, just wasn&#39;t sure how it decides
17:42CallekRyanVM: for BB those tests get kicked via code in mozharness that after the TC flip will not execute
17:43RyanVMworst-case, I&#39;ll just graft glandium&#39;s changes and re-push
17:43RyanVMwould just be annoying
17:44CallekPike: this hacky patch should fix the scopes issue for your push (I think)
17:53PikeCallek: same bustage
17:53Callekhrm :(
17:55RyanVMCallek: btw, it would appear that failed win TC l10n nightlies don&#39;t auto-retrigger?
17:55CallekRyanVM: :(
17:55* RyanVM did the retrigger for that green N4 next to it - which led to the failed Ns4 job of course (assume that&#39;s expected)
17:55CallekRyanVM: yea retriggers stink when it comes to validation things....
17:56CallekRyanVM: that part is on aki&#39;s plate to figure out
17:56akialready figured out
17:56akiwe just have to do it
17:56RyanVMyeah, I kinda figured it&#39;d fail but decided it was worth trying anyway :)
17:57RyanVMcan someone manually trigger that job at least so users on those locales aren&#39;t stuck with broken tab dragging?
17:58CallekPike: updated patch: (p.s. sorry for this pain)
17:58CallekRyanVM: whats the taskid of the N# ?
17:58Callek(the broken one)
17:58RyanVM Task: HNSArHzPSFasO4eTWkDBGQ
18:03CallekRyanVM: I think I just did it correctly
18:03RyanVMi see it running, so we&#39;ll see :)
18:04CallekPike: ugh failed again :(
18:04* Callek is no longer thinking this is funny, himself, I can&#39;t imagine how you feel
18:05PikeI&#39;m just throwing stuff back over teh wall
18:06Pikealso, after last week, any day is a good day
18:06CallekOooo this is a &quot;add scope to TC&quot; type of thing
18:14RyanVMCallek: tests are running on my Try push :)
18:15RyanVMare we intending to ship the TC builds off 56?
18:15heftigis the 55.0 release on ftp still just a rc that could be replaced? just wondering because i didn&#39;t see a tag appear yet
18:16CallekRyanVM: yes
18:16RyanVMCallek: are we planning to turn off the buildbot builds at some point?
18:16RyanVMheftig: it&#39;s still in final testing
18:17CallekRyanVM: current thinking is short-term we&#39;ll investigate renaming to `bbwin` or something in terms of try syntax, but yes turning them off is a goal
18:17heftigokay, thanks
18:17RyanVMCallek: sorry, to be more specific
18:17RyanVMthey&#39;re still running on Beta
18:17RyanVMwondering if that&#39;s on purpose?
18:17CallekRyanVM: bonus points, if you use `./mach try fuzzy` you don&#39;t even get bb windows
18:17heftigRyanVM: I assume if it does get replaced we would see the first announced release be 55.0.1?
18:17CallekRyanVM: &quot;bb builds still running on beta&quot; as in for normal nightly/on-checkin or are you talking the deved B&#39;s
18:18RyanVMheftig: I have no clue. Pretty unlikely at this point anyway.
18:20CallekRyanVM: oo we have addon devel&#39;s too -- but yea I noticed the deved B&#39;s were running that I fixed yesterday
18:21RyanVMCallek: yeah, I&#39;m not entirely convinced we&#39;ve got the optimal set of builds/tests running on Beta at the moment
18:23CallekPike: you can push that exact same code to try once more, I *think* this is the last over-the-wall for it
18:26PikeCallek: on its way
18:29Pikethat triggered stuff
18:44Callekjmaher: looking at that patch, I can&#39;t imagine anything wrong, but I think we should wait on kim since I don&#39;t have a test env up to validate and won&#39;t be able to set one up before my EOD
18:44Callekjmaher: sorry for delay in responding about it
18:47jmaherCallek: ok, I will wait until tomorrow
18:47jmaherI just sent another one your way as well
18:48Callekjmaher: on that other one was the CLIPBOARD line intended?
18:48jmaherCallek: no, that isn&#39;t intended
18:48jmaherlet me fix, thanks@!
18:49Callekjmaher: and perf-reftest-singleton default flip
18:49jmaherCallek: yes, I wanted that on by default
18:49jmahereverywhere (talos only runs on beta/trunk
19:03jmaherCallek: thanks for the preliminary review- ideally I can get both those patches reviewed tomorrow by Kim and get a reconfig
19:31jmaherCallek: last week I was asking about running tests on win10; I tried that, got sort of far, but wasn&#39;t able to get many tests to run on there
19:35jmaherAlso do we have gpu instances for the win10 machines?
19:36Callekjmaher: I don&#39;t know for sure on &#39;gpu instances for win10&#39; I think not, grenade|pto or pmoore|PTO-back-aug21 may know
19:39jmaherCallek: I added [&#39;try&#39;] to all the windows10.* run-on-project
19:39jmaherbut it didn&#39;t work
19:39jmaherto be fair I found a lot to clean up
19:39jmaherwe will make a pass on figuring out what small number of tests to disable or run in a different suite
19:40jmaherso the short term goal is to run everything on win10, and what we cannot we will run on win10 hardware
19:41jmaherso far I have 14 tests that I skipped to get mostly green for browser-chrome,media,devtools,mochitest
19:45tomprinceIs there any way to see what buildbot builders are used by buildbot-bridge?
19:46tomprinceI&#39;m looking to change some of the update verification builders to get libgk3 on them for thunderbird&#39;s code, and I don&#39;t want to break firefox in doing so.
19:48akitomprince: i think you can find them via grepping for &#39;buildbot-bridge&#39; in m-c/taskcluster/ and
19:49akithe latter are probably going to be the update-verify ones
19:51tomprinceaki: It looks like that is it. Thanks.
20:26philorRyanVM: remember offhand when we want to have the hsts/hpkp expiration be for a release?
20:26RyanVMtwo weeks after the next one, give or take IIRC
20:26RyanVM(and yes, we&#39;ve been having to manually update every one for the past few cycles)
20:27philoroh, good, then we won&#39;t mind updating yet another one
20:27RyanVMi&#39;ll file it
20:27RyanVMwe also found out last cycle that if you bump it *too* early, tests can break
20:27jcristauRyanVM: i think we went for &quot;56 release date&quot; for 54, and &quot;57 release date&quot; for 55
20:27RyanVMjcristau: go away, you!
20:27RyanVMPTO harder :)
20:29philoror maybe I can&#39;t count, and it doesn&#39;t matter that we didn&#39;t update for the last week because this is the time when we have the six weeks we won&#39;t be on aurora for extra room
20:29RyanVMyeah, we went with 2017-11-14 for 55
20:31RyanVM56 is going to expire on October 30
20:31RyanVMthat&#39;s cool, 56 will expire before 55 does
20:31RyanVMbut no, it needs to get to at least late november
20:31* RyanVM will file
20:33philorwoo, somebody filed *both* the hsts update bustage and the hpkp update bustage before me
20:33* philor declares it No Longer My Job for all time
20:34tomprinceDoes the source for exist anywhere?
21:31PikeCallek: things are looking better on my latest try push (had to uplift your other changes, too), but puzzles me
21:32Pikebuildbot_json_path shows up around the error message :-?
23:06nthomasif I have a unified gecko repo, and want to know the changes between 54.0.1 and what will be 55.0 (9e30e915f132) in toolkit/mozapps/update/, how do I ask hg to not show me inbound and other changes ?
23:06nthomas&quot;hg log -r FIREFOX_54_0_1_RELEASE:9e30e915f132 -l40 toolkit/mozapps/update/&quot; shows me revs like 43c421b4a763
23:10Pikenthomas: ::
23:10Callektomprince: offhand I forgot what I knew there, but it does exist *somewhere*
23:11Pikenthomas: &#39;:&#39; is just number to number, :: is graph
23:11nthomasPike: that sounds helpful, but I get nothing back
23:11Pikeoth, you might end up with nothing
23:11Pikenthomas: yeah, &#39;cause there&#39;s a branch point
23:12CallekPike: that also confuses me, make we need to update_to_enUS: false or some such
23:12CallekPike: but it certainly looks suspect/confusing
23:13Callek(since buildbot needs that codepath for releases)
23:13Pikenthomas: try 9e30e915f132 % FIREFOX_54_0_1_RELEASE
23:13Pikethat wouldn&#39;t give you anything from that branch point to 54.0.1, though
23:14Pikeyou&#39;d have to do that in reverse for each, I think
23:15nthomas&quot;hg log -r &quot;9e30e915f132 % FIREFOX_54_0_1_RELEASE&quot; -l40 toolkit/mozapps/update/&quot; looks more plausible
23:15CallekPike: either way, I&#39;ll file bug(s) on that stuff with try
23:15Callekthanks for the guinea pig help
23:16Pikehappy to help
23:17nthomasthank you sir
23:41travis-cibuild-tools#1900 (master - a7f69f4 : ffxbld): The build passed. (
8 Aug 2017
No messages
Last message: 14 days and 13 hours ago