[00:00:09] <zbehan> Flameeyes: i'm guessing dhcp-4.2.2-r1 has the same problem
[00:00:22] <Flameeyes> zbehan: present on host?
[00:00:26] <darinski> sjg: it will cycle, i don't think we need to clobber
[00:00:57] <Flameeyes> my chroot does not include any dhcp installation right now, and ./build_packages does not bring that in
[00:01:11] <sjg> OK - given it is a temp directory I suppose it will start again anyway
[00:01:11] <darinski> sjg: archive steps might be running in parallel with some other step
[00:01:15] <zbehan> Flameeyes: actually, nvm, i just accidentally had dhcp in the chroot world, it's not supposed to be there
[00:01:20] <darinski> sjg: so it might be a race...
[00:01:23] <sjg> Is there a bug for this? Can't see one
[00:01:28] <darinski> i'm checking with davidjames
[00:01:37] <darinski> sjg: i haven't file a bug -- could you please file?
[00:03:28] <sjg> Will do
[00:05:06] *** Solet has quit IRC
[00:06:28] <sjg> crosbug.com/19956
[00:08:05] *** lipsinV2 has quit IRC
[00:08:25] *** saintlou is now known as saintlou|away
[00:10:30] <darinski> davidjames said he's seen this race before, taking over the bug
[00:10:42] <darinski> we can reopen the tree now, i think (based on his feedback)
[00:10:53] <davidjames> darinski: Yes please :)
[00:10:54] <ferringb> curious, anyone know the details of how we push changes from gerrit to the mirror tier?
[00:11:07] *** flackr has quit IRC
[00:11:23] <crosbot> tree became 'Tree is open (crosbug.com/19956)'
[00:12:23] *** vicencb has joined #chromium-os
[00:12:48] *** vicencb has left #chromium-os
[00:23:12] *** cjb has quit IRC
[00:24:37] *** Solet has joined #chromium-os
[00:31:10] *** cjb has joined #chromium-os
[00:42:49] *** deshantm has quit IRC
[00:47:32] *** saintlou|away is now known as saintlou
[00:49:17] <darinski> internal builders seem to be down?
[00:49:27] <darinski> maybe because of the internal pfq?
[00:51:16] *** flackr has joined #chromium-os
[00:52:54] <sjg> How do you know they are down?
[00:59:00] <darinski> well, scottz just fixed it..
[00:59:12] <darinski> internal pfq didn't run between 12:45 and 15:56
[00:59:16] <sjg> Magic
[00:59:16] <darinski> that was a clue :-)
[00:59:30] <darinski> and then binary builders didn't run either cause pfq was down..
[00:59:39] <darinski> now they should all cycle ... with 70+ commits...
[00:59:48] <darinski> not nice
[01:00:02] <sjg> I will start writing a mass revert script :-)
[01:07:15] <darinski> so sheriffs started writing all these hand-off notes, etc... why don't we overlap sheriffs instead?
[01:07:50] <kliegs> darinski: i'm guessing administrative overhead of managing multiple calendar invites/schedules
[01:08:10] <darinski> kliegs: this sounds like a good reason :-) haha...
[01:08:42] <darinski> it will double the number of calendar entries, i guess...
[01:08:43] <kliegs> darinski: There's a fairly krufty script I believe that creates all the calendar events.  and it has some bad limitations if I understand correctly (like the calendar can't have anything on it other than the events it makes)
[01:09:04] <darinski> it's so much easier to write notes and get confused by what happened before you're in charge
[01:09:18] <kliegs> darinski: It has some merit, although with the docs and if the sheriffs from the previous day are available for questions and communicate well that should hopefully be sufficient
[01:09:52] <kliegs> darinski: true.  I like your concept though.
[01:10:01] <darinski> still -- it's one thing to communicate, it's different to have been immersed into it for a day or so
[01:10:03] <kliegs> i'm also not sure how often items hang over across shift boundaries only
[01:10:23] <darinski> recently, quite frequently it seems...
[01:10:27] <kliegs> darinski: the shift I did earlier this week was fairly isolated - no real issues coming in our out
[01:10:54] <kliegs> darinski: although the shift I did at the start of the month had a lot of items come in and some go out.  so much for my anecdotal data
[01:10:55] <darinski> yeah, ok. it doesn't seem like there's a real downside to overlapping though
[01:11:17] <kliegs> darinski: yah. i think just the administrative bit.  and also managing across timezones.  as there are two calendars
[01:11:35] <darinski> i'd say it might be enough to overlap just the MTV sheriffs
[01:11:38] <kliegs> darinski: but it makes sense.  if its easy to implement it makes sense.
[01:11:55] <kliegs> darinski: you can't really overlap the non-MTV as there's only going to be a single non-MTV sheriff on duty
[01:12:11] <kliegs> although you could shift it that way. where the MTV & non-MTV sheriff's get offset.
[01:12:31] <darinski> so no real issues with time zones if you overlap just MTV, and leave the rest as is
[01:12:39] <kliegs> darinski: yah true
[01:13:09] *** Keybuk has quit IRC
[01:13:11] <kliegs> darinski: was just saying that the non-mtv could be the offset.  so their first day they'd get brought up to speed by the mtv sheriffs. then on the 2nd day they'd bring the new mtv ones up to speed
[01:13:31] <kliegs> although the non-mtv's often go on duty first due to timezones so might not be as effective. overlapping just the mtv might be simpler
[01:13:40] <kliegs> either way it makes some sense if it doesn't add too big an overhead
[01:13:54] <darinski> it seems the only overhead is some script somewhere :)
[01:14:14] <kliegs> darinski: did I mention krufty?  I think even the grue avoided eating that script
[01:14:25] <darinski> :D
[01:14:25] <kliegs> darinski: ping rtc - I believe he's managing the process now if not the script
[01:15:12] <kliegs> anyways. got to run.  ice time soon :)
[01:15:25] <darinski> ... and you're serious...
[01:15:43] <kliegs> about the kruftiness, ice time or overlapping being good? :)
[01:15:58] <darinski> ice time
[01:16:20] <kliegs> yup! although I think we're short a few - got any skates and a way to get to Waterloo in an hour?
[01:17:05] <darinski> haha... let me ask if i can borrow the plane :-)
[01:17:50] <kliegs> take care. and good luck on the proposal - it makes sense to me and can help keep some consistency.  although I really do like the docs and am glad to see those being used
[01:32:49] <grundler> we've proposed overlap before.
[01:33:09] <grundler> and it was also "sounds like a good idea but we've got to make a schedule now"
[01:33:27] *** behdad has joined #chromium-os
[01:33:28] <grundler> maybe rtc is more interested
[01:33:37] <darinski> well, we're at the start of the schedule now is it won't hurt to make it for the next round
[01:33:51] <darinski> rtc pointed to mal or bdavirro..
[01:36:21] *** behdad has quit IRC
[01:36:51] *** behdad has joined #chromium-os
[01:53:20] *** behdad has quit IRC
[02:05:28] *** wfrichar has quit IRC
[02:15:56] <darinski> one MTV sheriff checking out...
[02:17:06] *** ysr has quit IRC
[02:17:25] *** sadrul has joined #chromium-os
[02:17:25] *** ChanServ sets mode: +v sadrul
[02:20:25] *** seventh has joined #chromium-os
[02:23:54] *** grundler has quit IRC
[02:24:14] <sjg> <Second MTV sheriff slopes off>
[02:26:23] *** petermayo has joined #chromium-os
[02:26:24] *** ChanServ sets mode: +v petermayo
[02:31:35] *** D|sT has quit IRC
[02:37:52] *** behdad has joined #chromium-os
[02:48:38] *** D|sT has joined #chromium-os
[02:51:21] *** stevenjb has quit IRC
[02:53:25] <crosbot> tree became 'Tree is closed (Automatic: "cbuildbot" on "lumpy-binary" from 492fe5d6c0c5bd75934d5d5453d9799b992291b9: sehr at google dot com <sehr at google dot com@0039d316-1c4b-4281-b951-d872f2087c98>)'
[03:05:23] *** saintlou has quit IRC
[03:18:15] <petermayo> scottz:  are you going to flip the tree back?
[03:19:21] <crosbot> tree became 'Tree is open (lumpy doesn't count yet)'
[03:21:13] *** stevenjb has joined #chromium-os
[03:53:51] *** stevenjb has quit IRC
[03:55:49] *** Sarten-X has joined #chromium-os
[03:55:53] *** jrbarnette has quit IRC
[03:59:36] *** ferringb has quit IRC
[04:01:39] *** ferringb has joined #chromium-os
[04:01:43] *** behdad has quit IRC
[04:08:41] *** lipsinV2 has joined #chromium-os
[04:08:59] *** oc80z has quit IRC
[04:08:59] *** oc80z has joined #chromium-os
[04:19:27] *** dennisjeffrey has quit IRC
[04:51:48] <crosbot> tree became 'Tree is closed (Automatic: "cbuildbot_master" on "x86 generic PFQ" from d987382407bc2ed91aed4dacb8d8efe736e48a0c: Peter Mayo <petermayo at chromium dot org>)'
[04:55:24] <crosbot> tree became 'Tree is open (another autotest flake ..looking up a bug)'
[05:29:53] <crosbot> tree became 'Tree is open (crosbug.com/19972)'
[05:30:23] <petermayo> crosbot: status sleep
[05:30:23] <crosbot> petermayo: No such command 'status'. Try 'help'.
[05:30:38] <petermayo> crosbot: help
[05:30:38] <crosbot> petermayo: admin [[+-]<nick>]*, announce [[+-]<stat>]*, help, ping, quiet, speak, stat <stat-name>
[05:30:56] <petermayo> crosbot: help stat
[05:30:56] <crosbot> petermayo: admin [[+-]<nick>]*, announce [[+-]<stat>]*, help, ping, quiet, speak, stat <stat-name>
[05:31:05] <petermayo> crosbot: stat
[05:31:06] <crosbot> petermayo: Stats: bots sheriffs sickbots tree troopers waterfall
[05:31:25] <petermayo> crosbot: stat troopers
[05:31:25] <crosbot> petermayo: troopers: djmm, scottz, bradnelson, maruel (EST), kliegs (EST)
[05:31:46] <petermayo> crosbot: stat waterfall
[05:31:46] <crosbot> petermayo: waterfall: http://build.chromium.org/p/chromiumos/waterfall
[05:32:15] *** petermayo has quit IRC
[05:54:42] *** seventh has quit IRC
[06:03:56] *** unreal has quit IRC
[06:11:42] *** unreal has joined #chromium-os
[06:21:21] *** gfrog has quit IRC
[06:24:59] *** gfrog has joined #chromium-os
[07:45:15] *** Erfolg has joined #chromium-os
[07:47:09] *** satorux_ has quit IRC
[07:50:12] *** vmil86 has joined #chromium-os
[07:54:47] *** satorux_ has joined #chromium-os
[07:54:47] *** ChanServ sets mode: +v satorux_
[08:09:12] *** Erfolg has quit IRC
[08:14:39] *** ferringb has quit IRC
[08:14:39] *** ferringb has joined #chromium-os
[08:14:39] *** ChanServ sets mode: +v ferringb
[08:15:54] *** srao has quit IRC
[08:16:09] *** srao has joined #chromium-os
[08:16:09] *** ChanServ sets mode: +v srao
[08:31:25] *** mnissler has quit IRC
[08:31:39] *** mnissler has joined #chromium-os
[08:31:40] *** ChanServ sets mode: +v mnissler
[08:47:57] *** Adys has quit IRC
[08:49:46] *** Sergiu_ has joined #chromium-os
[08:50:04] *** Adys has joined #chromium-os
[08:59:44] *** silverroots has joined #chromium-os
[09:04:15] *** jujugre has joined #chromium-os
[09:12:10] *** cooled has quit IRC
[09:13:50] *** cooled has joined #chromium-os
[09:28:00] *** gfrog has quit IRC
[09:33:37] *** silverroots has quit IRC
[09:45:12] *** gfrog has joined #chromium-os
[09:47:10] *** cooled has quit IRC
[09:47:21] *** cooled has joined #chromium-os
[10:02:57] *** gfrog has quit IRC
[10:08:49] *** silverroots has joined #chromium-os
[10:09:27] *** sadrul has quit IRC
[10:24:00] *** patcito has quit IRC
[10:24:25] <crosbot> tree became 'Tree is closed (Automatic: "cbuildbot" on "x86-zgb_he canary" from None: )'
[10:49:53] *** Sergiu_ has quit IRC
[11:04:22] *** silverroots has quit IRC
[12:03:49] <crosbot> tree became 'Tree is open (x86-zgb_he canary: sig 6 during desktopui_ChromeFirstRender -> crosbug.com/19975)'
[12:11:20] *** elly has quit IRC
[12:14:35] *** gfrog has joined #chromium-os
[12:19:23] *** elly has joined #chromium-os
[12:45:40] <crosbot> tree became 'Tree is closed (Automatic: "cbuildbot" on "x86-zgb-binary" from da73e7186c96ad3b41c88b918e17b0541ee4da7b: _third_party_ at chromium dot org, nirnimesh at chromium dot org <nirnimesh at chromium dot org@0039d316-1c4b-4281-b951-d872f2087c98>, pdox at google dot com <pdox at google dot com@fcba33aa-ac0c-11dd-b9e7-8d5594d729c2>)'
[13:15:30] <Flameeyes> zbehan: aren't you also running a 3.x Linux kernel series?
[13:32:36] *** gfrog has quit IRC
[13:50:52] *** gfrog has joined #chromium-os
[15:10:28] *** petermayo has joined #chromium-os
[15:10:41] *** ChanServ sets mode: +v petermayo
[15:11:22] <crosbot> tree became 'Tree is closed (petermayo looking at "x86-zgb-binary")'
[15:12:23] <crosbot> tree became 'Tree is open (petermayo looking at "x86-zgb-binary" ... is now green)'
[15:13:40] <crosbot> tree became 'Tree is open (petermayo will look at "x86-zgb-binary" ... is now green)'
[15:17:30] *** behdad has joined #chromium-os
[15:18:35] *** seumas has left #chromium-os
[15:21:07] <petermayo> about to go offline to commute to office ... anyone have sheriff items before ?
[15:21:28] *** wjmaclean has joined #chromium-os
[15:21:29] *** ChanServ sets mode: +v wjmaclean
[15:27:43] *** petermayo has left #chromium-os
[15:28:41] *** wjmaclean is now known as seumas
[15:32:14] *** BigWookie has quit IRC
[15:48:32] *** cros_ has joined #chromium-os
[16:08:40] *** cwolfe has quit IRC
[16:08:57] *** cwolfe has joined #chromium-os
[16:08:57] *** ChanServ sets mode: +v cwolfe
[16:14:18] *** petermayo has joined #chromium-os
[16:14:18] *** ChanServ sets mode: +v petermayo
[16:36:23] <crosbot> tree became 'Tree is open (crosbug.com/19975)'
[16:36:39] <crosbot> tree became 'Tree is open'
[16:45:30] *** Nikki_ has joined #chromium-os
[16:45:37] *** Nikki_ has left #chromium-os
[16:47:38] *** behdad has quit IRC
[16:51:41] *** sadrul has joined #chromium-os
[16:51:42] *** ChanServ sets mode: +v sadrul
[17:01:47] *** behdad has joined #chromium-os
[17:01:49] *** ChanServ sets mode: +v behdad
[17:12:51] *** jrbarnette has joined #chromium-os
[17:20:09] *** jrbarnette has quit IRC
[17:20:24] *** jrbarnette has joined #chromium-os
[17:26:59] *** cooled_ has joined #chromium-os
[17:30:07] *** cooled has quit IRC
[17:31:47] *** jrbarnette_ has joined #chromium-os
[17:34:43] *** jrbarnette has quit IRC
[17:34:44] *** jrbarnette_ is now known as jrbarnette
[17:35:43] *** jujugre has left #chromium-os
[17:43:27] *** cooled_ has quit IRC
[17:45:01] *** jrbarnette_ has joined #chromium-os
[17:45:08] *** jrbarnette has quit IRC
[17:45:17] *** jrbarnette has joined #chromium-os
[17:48:26] *** jrbarnette__ has joined #chromium-os
[17:48:38] *** jrbarnette_ has quit IRC
[17:50:29] *** jrbarnette_ has joined #chromium-os
[17:50:46] *** jrbarnette has quit IRC
[17:50:48] *** jrbarnette_ is now known as jrbarnette
[17:52:53] *** jrbarnette__ has quit IRC
[17:59:41] *** Solet has quit IRC
[18:03:32] *** ysr has joined #chromium-os
[18:04:59] *** yoshiki_ has quit IRC
[18:05:25] *** yoshiki_ has joined #chromium-os
[18:06:06] <rochberg> I have a chrome crash.  I'd like symbols so I can file a proper bug report.   How can I do this?   I've turned on chrome core dumps with touch /mnt/stateful_partition/etc/collect_chrome_crashes
[18:08:50] *** rbyers_ has joined #chromium-os
[18:10:08] <satorux_> rochberg: did you build chrome yourself?
[18:10:47] <rochberg> Yes and no.  I built it as part of build_packages
[18:10:59] <satorux_> that should be good
[18:11:01] <rochberg> but did not manually compile it.
[18:11:54] <satorux_> rochberg: something like this would work: gmerge chromeos-chrome with "export KEEP_CHROME_DEBUG_SYMBOLS=1; ./start_devserver", and on the device, attach gdb to the chrome process with "gdb -p CHROME_PID"
[18:12:25] <satorux_> `pgrep chrome|head -1` should give you the right chrome pID
[18:13:36] <rochberg> Is there any way I can just symbolize the core I have?
[18:14:11] <satorux_> export KEEP_CHROME_DEBUG_SYMBOLS=1; gives you chrome with symbols included.
[18:14:12] <rochberg> http://pastebin.com/qFQF68Qm shows my failure.  Or do I need to do KEEP_CHROME_DEBUG_SYMBOLS=1 even if I'm using the symbols from
[18:14:21] <rochberg> /build/x86-alex/usr/lib/debug/opt/google/chrome/chrome.debug
[18:14:38] <satorux_> i have no idea about the file
[18:16:20] <satorux_> oh, i found that file in my chroot
[18:16:32] <satorux_> this binary is gigantic
[18:16:35] <satorux_> this seems to contain everything
[18:17:15] <satorux_> then, something like "gdb chrome.debug core" works?
[18:17:54] <rochberg> I ran gdb on the chrome binary and then used "symbol-file" to load the symbols
[18:19:18] <satorux_> what happens if you specify chrome.debug as the gdb command line, instead of using symbol-file?
[18:20:49] *** rbyers_ has quit IRC
[18:22:27] <satorux_> the result would be the same, but worth trying
[18:22:44] *** petermayo has quit IRC
[18:22:51] *** petermayo has joined #chromium-os
[18:22:52] *** ChanServ sets mode: +v petermayo
[18:23:00] <rochberg> I get warning: (Internal error: pc 0x1e in read in psymtab, but not in symtab.)
[18:23:05] *** Solet has joined #chromium-os
[18:23:07] <rochberg> and ??'s for all the function names
[18:23:29] <satorux_> what gdb binary are you using?
[18:23:54] <satorux_> /build/x86-alex/usr/bin/gdb ?
[18:24:09] <rochberg> i686-pc-linux-gnu-gdb built by building cross-gdb
[18:24:46] <satorux_> i see
[18:24:53] <satorux_> i haven't used it
[18:24:57] *** rbyers_ has joined #chromium-os
[18:24:58] *** ChanServ sets mode: +v rbyers_
[18:24:58] <rochberg> This is on the host
[18:25:09] *** saintlou has joined #chromium-os
[18:25:09] *** ChanServ sets mode: +v saintlou
[18:25:09] <satorux_> maybe copy the chrome.debug file to the device, and run gdb on the device?
[18:25:41] <satorux_> if the crash can be reproduced determnistically, you could go with KEEP_CHROME_DEBUG_SYMBOLS as I described earlier.
[18:25:55] <rochberg> My attempt to build chromeos-chrome started SVN checking-out all of the source and eventually failed.
[18:26:30] <satorux_> if it's easily reproducible, i could give it a try on my device
[18:26:36] <rochberg> Though this might have something to do with cros_package_to_live
[18:27:06] <satorux_> do you have a local chrome tree? i always build chrome from my local tree, with cros_sdk --enter --chrome_root=...
[18:27:08] <rochberg> If you have a ToT chrome and a GSM modem, try adding a custom APN
[18:27:50] <satorux_> export CHROME_ORIGIN=LOCAL_SOURCE; export FEATURES="-usersandbox";  this also needs to be set inside the chroot. nice to have in ~/.bashrc
[18:28:15] <satorux_> I don't know if my alex has a GSM modem..
[18:28:38] <rochberg> lsusb and look for y3300
[18:29:07] <satorux_> it does not.
[18:30:12] <satorux_> export USE="-build_tests" is also nice to be set.
[18:37:06] *** dennisjeffrey has joined #chromium-os
[18:37:07] *** ChanServ sets mode: +v dennisjeffrey
[18:37:11] *** cooled has joined #chromium-os
[18:37:42] <rochberg> I'm going to file a bug on making things work without a chrome tree.
[18:37:45] <rochberg> Thansk for your help.
[18:39:15] *** drZZ has joined #chromium-os
[18:43:51] *** lipsinV2 has quit IRC
[18:45:39] <cros_> On the topic of building the chrome browser. I ran into a situation where the chrome browser was using a newer version of libcros than chromium OS was built with. I found something about modifying the DEPS file so chrome uses a specific version of libcros. Would that work or what's the best way to handle this?
[18:46:13] <satorux_> cros_: maybe your chrome tree is not synced?
[18:46:42] <cros_> i did a glient sync
[18:46:45] *** Sergiu_ has joined #chromium-os
[18:46:46] *** Sergiu_ has joined #chromium-os
[18:46:49] *** drZZ has left #chromium-os
[18:47:04] *** Sergiu_ has quit IRC
[18:47:27] <cros_> satorux_: I think the problem is that I pulled the chromium OS code using repo a few weeks ago but I pulled the chrome browser code a few days ago so I could build from local source.
[18:47:33] <satorux_> you can check what version of libcros that chrome is using from cros_deps/DEPS
[18:47:37] <kliegs> cros_: Normally there's a range of libcros that's supported
[18:47:37] <kliegs> cros_: If you look in the file, you can find bits that say "minversion=foo, maxversion=bar".  so as long as the version falls within those you're fine
[18:48:41] *** dlaurie has quit IRC
[18:48:55] <cros_> kliegs: Right, but what I found is that the version chrome is built against is 1 version higher than the max version. So if I modify the DEPS file to point to the same cros git commit SHA1 for libcros as chromium OS is using would taht work?
[18:48:57] <kliegs> cros_: I'd recommend against down-revving the version of libcros in the browser
[18:49:16] <kliegs> cros_: as its likely done because there are features in the new libcros that chromium is using
[18:49:25] <kliegs> cros_: instead you should rev the libcros version in chromeos
[18:49:29] <cros_> kliegs: Ok, I suspected down-revving may not work due to API changes. I wanted to avoid having to upgrade my chromium OS source.
[18:49:31] <kliegs> cros_workon start libcros
[18:49:38] <kliegs> I believe that will uprev it
[18:49:50] <kliegs> cros_: unfortunately your best bet is to update chromium os source
[18:50:03] <kliegs> cros_: while in some cases down revving will work, its more likely to lead to frustration
[18:50:06] <cros_> kliegs: Appreciated. Upgrading libcros should be acceptable.
[18:50:35] <cros_> kliegs: What is the normal procedure for upreving just one particular package?
[18:50:50] <kliegs> cros_: The easiest way is to cros_workon libcros as above
[18:52:06] <cros_> kliegs: Ok. One thing I never figured out was I have to use cros_workon_make --install so that when I build the package and run build_image it picks up the new package binaries.
[18:52:12] <kliegs> cros_: then sync just the libcros directory (cd .../src/platform/cros && repo sync .)
[18:52:27] <kliegs> cros_: You don't need to worry about cros_workon_make
[18:52:30] <kliegs> I'd do these commands:
[18:52:39] <kliegs> cros_workon --board=something start libcros
[18:52:44] <kliegs> cd ../src/platform/cros
[18:52:45] <kliegs> repo sync .
[18:52:50] <kliegs> emerge-board libcros
[18:52:56] <kliegs> that should rev libcros and nothing else
[18:53:24] <kliegs> then whenever you want to rev just libcros, go to the directory, repo sync and emerge.  the '.' in repo sync means "only the repository who's directory I'm in"
[18:53:28] <cros_> kliegs: But then the new libcros won't make it into my build image. I have to emerge -k to get it there.
[18:53:37] *** dlaurie has joined #chromium-os
[18:53:37] *** ChanServ sets mode: +v dlaurie
[18:54:02] <kliegs> cros_: when you run build_images it will take the libcros you just built
[18:54:20] <kliegs> I assume you're running build_image after emerging chrome?
[18:54:39] <cros_> kliegs: Ok, I thought in the past I tried it and it didn't work but maybe I am mistaken.
[18:54:50] *** rbyers_ has quit IRC
[18:54:50] <kliegs> cros_: you may not have cros_workon'ed it
[18:55:36] <cros_> kliegs: I am pretty sure I did. I only got the correct behavior when I cros_workon_make --install instead of using emerge.
[18:55:51] <cros_> kliegs: But anyways if you say it should work I'll try it again.
[18:55:59] <kliegs> cros_: weird.  i've actually never used cros_workon_make
[18:56:28] <cros_> kliegs: No problem, appreciate the help.
[18:57:30] *** rbyers_ has joined #chromium-os
[19:00:45] <kliegs> cros_: Good luck!  And I'm curious if you don't mind me asking - what are you building?
[19:01:40] <cros_> kliegs: Just trying to bring up chromium OS on a new SoC.
[19:01:58] <kliegs> cros_: raspberry pi? :)
[19:02:21] <cros_> kliegs: LOL, no, just exploring chromium OS really. No product right now.
[19:02:43] <kliegs> cros_: No problem.  I'm just always curious about new platforms.  And I want a raspberry when they come out - looks really cool
[19:19:56] *** ysr has quit IRC
[19:22:06] *** saintlou is now known as saintlou|away
[19:42:30] <darinski> external pfq hasn't built since 9:17am
[19:42:38] <darinski> i guess it's stuck again?
[19:42:46] <darinski> i'll kick it off to check
[19:43:41] <sjg> OK
[19:44:38] <oshima> varunjain: ping
[19:44:51] <oshima> oops, wrong window, sorry about that.
[19:46:16] *** Keybuk has joined #chromium-os
[19:46:16] *** ChanServ sets mode: +v Keybuk
[19:46:20] <darinski> yep
[19:46:32] <darinski> it seems it didn't see changes from 10:15am
[19:47:40] <darinski> scottz checking...
[19:50:16] *** saintlou|away is now known as saintlou
[19:51:13] *** saintlou has joined #chromium-os
[19:51:13] *** ChanServ sets mode: +v saintlou
[19:53:27] *** jrbarnette has quit IRC
[19:57:27] *** ysr has joined #chromium-os
[20:01:58] *** D|sT has quit IRC
[20:09:16] *** jrbarnette has joined #chromium-os
[20:09:16] *** ChanServ sets mode: +v jrbarnette
[20:13:13] *** rbyers_ has quit IRC
[20:29:32] *** patcito has joined #chromium-os
[20:30:51] <njw> Do autotest tests with cross-compiled code work these days? I'm trying to write one, my prototype is logging_UserCrash, but it doesn't seem to work either. (run_remote_tests.sh eventually logs "Unhandled OSError: [Errno 2] No such file or directory: '/usr/local/autotest/tests/logging_UserCrash/src'")
[20:33:26] <ellyjones> huh... I don't have a submit option on http://gerrit.chromium.org/gerrit/#change,7174
[20:34:56] <njw> there's mail about this, I think.
[20:35:23] <njw> "PSA: Commit Queue turning on for crosutils/chromite"
[20:35:35] <pstew> Yeah.  It'll go into the commit queue.
[20:35:47] <kliegs> I for one welcome our new commit queue overlords
[20:35:57] <ellyjones> how do I actually submit it then?
[20:36:06] <pstew> Wait, mostly.
[20:36:09] * kliegs actually is happy about this, bad jokes aside
[20:36:21] <pstew> If you're really impatient you can find an owner to put it in manually.
[20:36:23] <kliegs> ellyjones: I believe it will just get committed soon by the commit queue
[20:36:24] <ellyjones> so as soon as I mark it verified and +2, it automatically goes in...?
[20:36:37] <pstew> ellyjones: That's the theory.
[20:36:52] <ellyjones> that seems extremely dangerous
[20:37:08] <kliegs> ellyjones: just look at is as hitting +1 is the same as hitting submit before
[20:37:14] <kliegs> so only hit +1 when ready for submission
[20:37:24] <pstew> I never set "verified" on my changes before I'm ready for them to go in, and now I'll not do it even moreso. :-)
[20:37:49] <ellyjones> I tend to mark 'verified' as soon as tests pass
[20:38:04] <kliegs> pstew: same - I'd save the verify bit for "it can be committed at any point forward".  so either when I'd go to submit or if its a trivial enough change I didn't care if someone submitted later when i wasn't around
[20:41:25] <sjg> Ick, I think this is wrong. Verify means it is verified, not that it is ready for submission. It's a signal to reviewers that it has been tested
[20:43:01] <sergiu> people could Verifiy, then others could LGTM and just publish afaik
[20:43:09] <ellyjones> kliegs: you confused the heck out of me :P
[20:43:21] <kliegs> ellyjones: i'm confusing the heck out of me too
[20:43:42] <kliegs> sjg: i'm not sure how much the verify bit has actually been used.  I've mostly ignored it when reviewing CL's
[20:44:04] <njw> This does seem like conceptual abuse of the verify bit, but I haven't seen much "real" use. == kliegs.
[20:44:29] <pstew> It's cute how entrenched people already are in the current model.
[20:44:56] <kliegs> sjg: But I see your point about the overloading.  Maybe a new button/checkbo x of "send to commit queue"?
[20:45:22] <ferringb> or just rename verify
[20:45:28] <marcheu> pstew: I think the issue is not so much the current vs new as the increasing layers of complexity to being able to commit something
[20:45:34] <ferringb> if people are that attached to it's interpretation
[20:45:36] <kliegs> marcheu: +1
[20:45:58] <kliegs> sjg: I'm not so sure about how many people really do anything with the current verfiied bit beyond going "oops, submit is greyed out, +1 verified"
[20:46:13] <kliegs> ellyjones: and sorry about confusing your CL
[20:46:27] <ellyjones> s'ok
[20:46:42] *** saintlou is now known as saintlou|away
[20:46:51] <pstew> I think this might just be a question of the semantics of "verified".  Is it a signal to the reviewers that this is close enough to final-copy to start some serious nit-picking, or is it a signal to the system that the code is ready to start in the commit queue.
[20:47:46] <sjg> Verified means it has passed the tests, and verified to work
[20:48:09] <sjg> It doesn't mean that everything is ready for it to be submitted.
[20:48:09] <kliegs> pstew: I'm probably a bit trained from reitveld.  where if I put up a CL that isn't ready I mention it in the comments
[20:48:26] <sjg> For example, some changes may rely on others
[20:49:03] <ferringb> curious... do we use topic branches at all?
[20:49:15] <ferringb> afaik, we don't, but I'm wondering *why* we don't push that info up?
[20:49:22] <kliegs> So never really saw a need for the verified bit as I assume most CL's are ready for review unless otherwise stated
[20:49:37] <ferringb> it doesn't give you transactional commits (dependant changes referenced by sjg), but it is at least a hint that there is a grouping
[20:51:29] <sosa> interesting conversations
[20:51:49] <kliegs> was wondering when sosa would join in :)
[20:51:52] <sosa> wondering why the hate just isn't over the emails talking about the commit queue?
[20:52:04] <sosa> the verified bit issue is temporary
[20:52:21] <sosa> it'll take a couple weeks for the Gerrit overlords to add a feature to add a new category for commit
[20:52:45] <sosa> but it didn't seem like a major blocker for dogfooding
[20:52:51] <sosa> but i do understand the issue
[20:53:08] <ellyjones> sosa: where can I see the commit queue? I want to know if my commit will go in soon
[20:53:09] <sosa> i honestly have been using verified email myself to always give more info (if i want) to how i actually tested
[20:53:19] <sosa> ellyjones: it's a builder on the waterfall
[20:53:26] <ellyjones> the major problem I'm having right now is that I put this commit in early precisely so I'd see fallout before I went home
[20:53:31] <sosa> ellyjones: it prints links to CL's it's trying as part of the sync stage
[20:53:32] <ellyjones> and I'm worried the fallout will now occur later
[20:53:56] <sosa> ellyjones: right now it's sort of like an enforced trybot
[20:54:16] <sosa> if you're patch breaks the build, nothign really bad happens expcet the commit queue telling you to try again later once you've fixed the issue
[20:54:36] <sosa> eventually the commit queue is planning to remove the pfq (eventually meaning once out of dogfood)
[20:54:40] <ellyjones> but presumably it only tries on x86, right?
[20:54:42] <sjg> OK so before it is rolled out for all repos, we will have a 'submit' button?
[20:54:56] <sosa> so you'll actually have the same exact timeline to have others see your commit for workon items
[20:55:04] <sosa> not a submit button
[20:55:09] <sosa> but something attunded to +1 for ready for commit
[20:55:23] <sosa> hmm, i don't think attunded is a word
[20:55:26] <sosa> hehehe
[20:55:36] <sjg> attuned or intended?
[20:55:41] <sjg> what did you mean?
[20:55:43] <sosa> but yeah, basically then the commit queue would check for +2, +1, +1 ready for submit
[20:56:05] <sosa> something exactly like
[20:56:13] <sosa> pretty much gerrit only understands categories with ranges
[20:56:21] <sosa> the submit button is a special case that isn't tunable
[20:56:40] <sjg> OK, so we 'release' a change to the commit q with a radio button or something
[20:56:51] <sosa> it'd show up as another category
[20:57:11] <sosa> Code Review and Verified are just categories where certain values are required to submit
[20:57:22] <sjg> OK that sounds good
[20:57:31] <sjg> OK, while the overlords are busy on this, I wonder if there is any chance of reducing the spam?
[20:57:41] <sosa> which spam?
[20:57:43] <sosa> the submit spam?
[20:57:47] <sosa> the i can't test your spam?
[20:57:52] <sosa> the i can't apply your spam?
[20:58:00] <sjg> The constant emails whenever anything changes
[20:58:08] <sjg> It would be nice to have a tick button to say 'spam them now!'
[20:58:13] <sosa> specifically?
[20:58:25] <sjg> Basically adding a new patch should not cause an email to be sent out to everyone
[20:58:28] <sjg> It might just be a rebase
[20:58:33] <kliegs> I do miss being able to upload a CL, add a bunch of reviewers.  then add a comment to all the reviewers that gets sent out at once
[20:58:35] <sjg> I might have another version coming
[20:58:35] <sosa> are we having another conversation now?
[20:58:44] <sjg> Yes we are having another conversation
[20:58:46] <sosa> hahaha
[20:58:55] <sjg> I am very happy with the result of the last, so am pushing my luck
[20:59:12] <njw> hmmmm. "./run_remote_tests.sh --remote 172.31.195.201 suite_Smoke" -> only passes 6 out of 22.
[20:59:16] <sosa> i wish i knew how to
[20:59:22] <sosa> i would also like less spam
[20:59:24] <sjg> If I have 10 commits in the queue and upload them, everyone gets a message even if they have LGTMed the previous ones
[20:59:32] <sosa> but it seems outside the scope of simple configurability
[20:59:37] <sjg> Say I only actually changed the top commit, then no one can actually tell
[20:59:44] <sjg> So people ignore the emails
[20:59:54] <sjg> Another case is that I have just added a comment but NOT uploaded a new patch set
[21:00:06] <sjg> In that case, I want the commit to show up bold in their queue
[21:00:08] <kliegs> i mostly ignore the gerrit emails and just make sure to periodically refresh both gerrit windows
[21:00:12] <sjg> ...so they will take notice
[21:00:31] <sosa> which means it would require a reasonable amount of work to implement which means someone would really have to push for it or try to submit patches either on the build team or rest of the team.  but that requires balancing with other priorities etc and i'm not sure who on the build team has extra cycles right now
[21:00:35] <kliegs> as parsing the gerrit emails seems to troublesome.  things seem to come out of order sometimes even
[21:00:47] <kliegs> well, show up in the email conversation out of order
[21:01:24] <sjg> OK, I will take to some people about how this might work
[21:01:38] <sjg> Is gerrit all JS or Python or PHP or Ruby or something?
[21:01:46] <sosa> Python sexiness
[21:01:47] <ellyjones> probably python
[21:01:52] <kliegs> I thought someone told me Go?
[21:01:57] <sosa> ...
[21:01:59] <ellyjones> you were lied to
[21:02:02] <sjg> OK Python I can handle
[21:02:03] <kliegs> but I never actually checked
[21:02:15] <sjg> ...(badly)
[21:02:28] <sosa> yeah i looked at some code the other day trying to figure out what Gerrit cherry-pick actuallly means and it is indeed python
[21:02:39] <sjg> I will see what I can do. Of course this means that the overlords will have to put up with a newby in their code
[21:02:44] <sjg> ...submitting patches
[21:02:49] <sjg> ...agitating for change
[21:03:02] <sjg> ...spoiling their nice clean look
[21:03:29] <sosa> you seem well-versed in Python, you should be fine :)
[21:03:52] <sjg> It's not *me* I'm worried about, it's Gerrit
[21:03:59] <sosa> but i would also not necessarily look forward to it :(
[21:04:07] <sosa> (off the record)
[21:04:17] <ellyjones> chrome-bot just addressed me as "Paladin"
[21:04:21] <ellyjones> http://gerrit.chromium.org/gerrit/#change,7174
[21:04:31] <ellyjones> it is disturbingly correct about which class I play in D&D, but what does it mean?
[21:04:32] <sjg> I'm looking forward to not having to apologize for spamming people with my reviews
[21:04:33] <sosa> i need to change that messaging
[21:04:35] <sosa> it is called Paladin
[21:04:48] <ellyjones> what is? the preflight?
[21:04:50] <sjg> I used to play Paladin too - how do I get called that?
[21:04:57] <sosa> as you may have noticed my english is not so amaaaazing
[21:05:25] <sosa> elly looks like you got burned by flakiness
[21:05:28] <sosa> i'll commit your change
[21:05:36] <ellyjones> danger!
[21:05:36] <sosa> (it is validating very much like the pfq)
[21:05:44] <sosa> or rather
[21:05:46] <sosa> would you like me to?
[21:06:34] <sjg> I have one more small question...will the change show state change from 'ready to submit to queue', 'sitting in queue', 'testing now', 'merged'?
[21:06:45] <sosa> no
[21:06:45] <ellyjones> if you checked the test log and it's flakiness, go for it
[21:06:56] <sosa> but if you would like more messages, i can easily add them
[21:06:57] <sosa> ;)
[21:07:06] <sosa> i just can't take the default ones away
[21:07:10] <sosa> more is easy
[21:07:33] <sjg> It's nice to see what is going on
[21:08:14] <sjg> Want to avoid the appearance of an evil demon in the jar, scheming to submit your commits in just the right order to mess everything up
[21:11:51] <ellyjones> sosa: how do I get the mystical power to bypass the paladin and, uh, land my change?
[21:12:09] <sjg> Roll D20
[21:12:17] <ellyjones> crosbot can't do that yet :(
[21:12:31] <kliegs> Make a save against flakiness
[21:12:35] <sjg> D6?
[21:12:37] <ellyjones> I failed, clearly
[21:14:05] *** Delizia has joined #chromium-os
[21:14:30] *** unreal has quit IRC
[21:16:24] <sjg> unreal has left the room, normality can return
[21:17:14] <ellyjones> crosbot: tree?
[21:17:14] <crosbot> ellyjones: tree: Tree is open
[21:17:16] <ellyjones> disturbing
[21:18:49] <ellyjones> cool, so verity salting is now in!
[21:19:35] *** saintlou|away is now known as saintlou
[21:19:38] <sjg> I don't know what you mean, but it sounds jolly fine
[21:21:38] <ellyjones> it adds a sort of tangy flavor to rootfs verifications
[21:22:07] <ellyjones> sosa: does bugdroid still do the right stuff?
[21:22:41] *** Delizia has quit IRC
[21:23:24] <sjg> I've never tried licking my SSD
[21:23:31] <sjg> But it is lunch tmie
[21:24:06] <ellyjones> power it down first
[21:25:07] <sjg> Thanks for the tip :-) Could have been messy
[21:25:38] <ellyjones> at 12v, how much trouble can you really get into?
[21:27:11] <sjg> It depends on the tangy-ness I suppose. If I am still here next week then perhaps not much
[21:29:09] *** grundler has joined #chromium-os
[21:29:10] *** ChanServ sets mode: +v grundler
[21:29:28] <cros_> kliegs: I tried upreving the cros package using 'repo sync .' but repo fails because from what I can tell it is trying to do something with the manifest and is looking for a git commit that is newer than what is in my tree. Any idea what's going on?
[21:30:04] <cros_> kliegs: Final message is about GitError: manifest rev-list ..... : fatal: bad object 25000....
[21:30:17] *** kliegs has quit IRC
[21:30:31] <cros_> kliegs: I looked on gitweb and saw that object is a later commit to the manifest git tree.
[21:31:57] *** rbyers_ has joined #chromium-os
[21:35:44] <ellyjones> sosa: my change got bounced again after you submitted it
[21:35:48] <cros_> kliegs: After more digging it looks like repo updates the manifest too so you can't really update just one package necessarily.
[21:35:49] <ellyjones> is it now in tree or not?
[21:39:28] *** rbyers_ has quit IRC
[21:40:58] *** rbyers_ has joined #chromium-os
[21:42:32] <pstew> Oo.  I got bug 19997.  20000 is about to roll over.
[21:43:04] <ellyjones> that's a lot of bugs
[21:51:02] <sjg> Got it :-)
[21:51:03] <njw> And there it is.
[21:51:42] <njw> Hey, 20k bugs isn't so bad! Over 80% of them have been closed!
[21:52:12] <ellyjones> sosa: did my commit go in or not?
[21:52:32] <ellyjones> sjg: :)
[21:52:54] <ellyjones> this weekend I'm going to make crosbot understand 'bug <n>' and 'cl <n>'
[21:53:43] <pstew> ellyjones: This is gerrit.  I'm sure you'll get email when _anything_ happens.
[22:04:02] *** rbyers_ has quit IRC
[22:05:16] <crosbot> tree became 'Tree is closed (Automatic: "cbuildbot_master" on "TOT Pre-Flight Queue" from fe3d11c89ee8df4010dbcb2bdc9cc0a65aca705d: nirnimesh at chromium dot org <nirnimesh at chromium dot org@0039d316-1c4b-4281-b951-d872f2087c98>)'
[22:06:46] *** rbyers_ has joined #chromium-os
[22:06:46] *** ChanServ sets mode: +v rbyers_
[22:06:58] *** rbyers_ has quit IRC
[22:10:10] *** rbyers_ has joined #chromium-os
[22:10:25] <sjg> Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in <type 'exceptions.AttributeError'> ignored
[22:14:14] <crosbot> tree became 'Tree is closed (davidjames, sjg looking)'
[22:14:24] <ellyjones> that one is always ignored, sjg
[22:14:27] <ellyjones> it happens every time
[22:14:43] <sjg> Yes davidjames told me
[22:14:59] *** GodoPPL has quit IRC
[22:16:07] <davidjames> update.log has some juicy errors: Root filesystem has been modified unexpectedly!
[22:21:58] <sjg> Will file a bug and reopen
[22:22:11] <sjg> No, will reopen and file a bug
[22:26:11] <sjg> Actually it looks like crosbug.com/16591
[22:27:25] <davidjames> sjg: Yeah does look like that bug. It's disturbing though that 3 builders are failing at once  (x86-generic-full, x86-mario preflight, chrome pfq)
[22:28:27] <sosa> ellyjones: sorry i missed your messages, your commit went in, it's just Paladin was trying your commit at the same time and got confused
[22:29:59] <sjg> Well the fix was just to reduce parallelism
[22:30:02] <sjg> Does it need locking?
[22:30:21] <ellyjones> ah, ok
[22:30:24] <sergiu> ellyjones, as promised, some info on Ramoops on ChromeOS (the changes got in yesterday) https://sites.google.com/a/chromium.org/dev/chromium-os/how-tos-and-troubleshooting/ramoops-in-chromium-os
[22:30:35] <ellyjones> sergiu: cool :)
[22:30:36] <sergiu> if you need any other info just ping me here
[22:30:49] <sjg> Does this replace preserved completely now?
[22:30:53] <sergiu> yes
[22:31:01] <sergiu> the next change is to remove the preserved.c file
[22:31:07] <sjg> Great!
[22:31:11] <sergiu> but that's pending review :)
[22:31:22] <sergiu> but it is live in the tree
[22:31:30] <sjg> Stick me on the review if you like
[22:32:13] <sjg> No, the Tot PFQ failed again
[22:33:21] <sosa> sjg:  yup looks unrelated to 16591
[22:33:33] <sergiu> sjg, done .. so yes, now we're now using ramoops instead of preserved, with the crash reporter infrastructure updated as well :)
[22:33:48] <sjg> ERROR: cgpt find: invalid argument to -u: quiet
[22:33:53] <sjg> What about that?
[22:34:16] <darinski> harmless
[22:35:24] <sosa> Failed to copy syslinux files in and make them bootable.
[22:35:33] <sosa> ah its what davidjames said:  Root filesystem has been modified unexpectedly!
[22:35:35] <darinski> Root filesystem has been modified unexpectedly!
[22:35:37] <sosa> verity failed
[22:36:26] <sjg> Is it verify_rootfs_chksum.sh
[22:36:28] <darinski> let's revert ellyjones
[22:36:35] <sjg> or /src/platform/installer/chromeos-setimage?
[22:36:42] <darinski> i mean -- her change, not her :-)
[22:36:48] <darinski> http://gerrit.chromium.org/gerrit/#change,7174
[22:37:00] <ellyjones> :<
[22:37:09] <sjg> I don't know, maybe your first idea might be more interesting?
[22:37:15] <ellyjones> yeah, sounds like time to revert 7174
[22:37:26] <ellyjones> I will debug and fix
[22:37:33] <davidjames> sosa: Why did that change get cherry picked? It says it failed verification
[22:37:33] <darinski> elly -- would you like to revert it?
[22:37:34] <sjg> ok
[22:37:46] <sjg> Will just click the revert button...
[22:37:49] <sjg> Er...
[22:37:54] <ellyjones> which bot broke?
[22:38:01] <darinski> internal pfq
[22:38:10] *** grundler has quit IRC
[22:38:11] <darinski> somebody revert pls :-) or i will :-)
[22:38:21] *** chocobo__ has quit IRC
[22:38:28] <ellyjones> I am debugging, someone else please revert
[22:38:29] <darinski> davidjames: sosa says he made it bypass the commit queue
[22:38:33] <darinski> i'll revert
[22:38:38] *** stevenjb has joined #chromium-os
[22:38:38] *** ChanServ sets mode: +v stevenjb
[22:39:39] <davidjames> darinski: Ah, so it bypassed the commit queue because the commit queue was failing with "Root filesystem has been modified unexpectedly" errors?
[22:39:45] <ellyjones> whare are you guys seeing rootfs modified errors?
[22:40:23] <davidjames> ellyjones: It first showed up in the commit queue when it was testing your change, in update.log (inside test_results.tgz)
[22:40:28] <ellyjones> darinski: lgtmed
[22:40:30] <sjg> https://sandbox.google.com/storage/?arg=chromeos-x86-mario/pre-flight-master/0.15.982.0-a1-b5190#chromeos-x86-mario%2Fpre-flight-master%2F0.15.982.0-a1-b5190
[22:40:44] <darinski> ellyjones: thanks, i was going to tbr it anyway
[22:40:45] <davidjames> ellyjones: Then, after it was pushed, bypassing the commit queue, we saw it on the other builders too
[22:40:57] <ellyjones> alright, cool
[22:41:03] <darinski> davidjames: sosa thought commit queue was flaky or something and let it through
[22:41:14] <darinski> davidjames: is the revert pushed now?
[22:41:17] <davidjames> Aha, yeah, looks like a flaky error at first :)
[22:41:30] <darinski> davidjames: or does it need to go through the commit queue?
[22:41:38] <darinski> ellyjones: you need to download the build artifacts
[22:41:55] <darinski> ellyjones: test_results.tgz, UpdateAndVerify test, update_engine.log
[22:41:58] <davidjames> darinski: Reverts by sheriffs can go in immediately, looks like you already pushed it though :)
[22:41:59] <ellyjones> yeah, I got them
[22:42:18] <darinski> ellyjones: you'll postinstall failing with root filesystem changed error
[22:42:32] <sjg> Can we restart PFQ or doesn't it work like that?
[22:43:00] <darinski> davidjames: yeah, i just did what i normally do -- push :-) i guess with commit queue i shouldn't ... but not in this case
[22:43:32] <davidjames> darinski: Yeah you were right to push... this time :)
[22:43:33] <ellyjones> ah, dammit, I forgot to reinvoke verity with the salt in the installer
[22:43:40] <darinski> stopped the pfq
[22:43:56] <sjg> It seems to have started Kaen :-(
[22:44:07] <davidjames> darinski: External PFQ looks doomed also
[22:44:12] <ellyjones> :( sorry all
[22:44:24] <sjg> And I don't get to lick my SSD :-(
[22:45:11] <davidjames> sjg, ellyjones: You can stop external PFQ from here: http://buildbot.jail.google.com/i/chromiumos/waterfall
[22:45:14] <darinski> davidjames: yeah, external will probalby fail too but will cycle
[22:45:42] <darinski> ok, i've stopped external pfq too
[22:46:20] <sjg> Shouldn't we kick them off again?
[22:46:26] <darinski> davidjames: the builders should come online without a kick, right?
[22:46:52] <davidjames> darinski: Yup
[22:46:58] <darinski> sjg: if it's purple, it's offline and not responding, i think
[22:47:15] <davidjames> darinski, sjg: Can you take a look at x86-generic-full failure? That occurred prior to ellyjones' change
[22:47:27] <darinski> internal pfq doesn't see the revert yet
[22:49:07] <crosbot> tree became 'Tree is closed (ellyjones change reverted, should cycle green -> sjg, petkov)'
[22:49:11] <darinski> davidjames: i think this is a known flakiness
[22:49:30] <davidjames> darinski: Yeah, just interested in why it failed if you have any insight into that :)
[22:50:14] <darinski> heh, it's a known P0 issue -- crosbug.com/16591
[22:50:38] <davidjames> darinski: Yeah but that bug doesn't say why either :(
[22:50:44] *** cros_ has quit IRC
[22:51:04] <darinski> davidjames: nobody knows why every now and then update_engine fails to contact the dev server...
[22:51:30] <darinski> davidjames: i think sosa was going to insert so tcp monitoring and logging code to see exactly where the packets are dropped
[22:51:32] <davidjames> darinski: So where is that error?
[22:51:43] <darinski> davidjames: i.e., if it's a client or a server side error
[22:52:04] <darinski> davidjames: again, update_engine.log, there's an "unable to get http response code"
[22:53:56] <davidjames> darinski: That error occurs at 13:11, dev server started at 13:12
[22:54:12] <davidjames> darinski: Maybe update was too fast and happened before dev server started?
[22:55:26] *** grundler has joined #chromium-os
[22:55:26] *** ChanServ sets mode: +v grundler
[22:56:02] <darinski> davidjames: you're right -- in this case the issue seems obvious :-)
[23:04:16] <dhendrix> anyone from build infrastructure on-line today? cmp is OOO.
[23:05:15] <davidjames> dhendrix: Yeah, trooper schedule is linked from chromium waterfall
[23:06:39] <davidjames> dhendrix: Hmm, looks like the trooper for today is on Munich time, you might want to just file a bug for infrastructure team on crbug.com
[23:06:58] <davidjames> (because it's past 11pm there)
[23:07:19] *** chocobo__ has joined #chromium-os
[23:07:19] *** ChanServ sets mode: +v chocobo__
[23:07:25] <dhendrix> davidjames:  bug filed, heh.
[23:10:35] *** chocobo___ has joined #chromium-os
[23:10:43] *** ChanServ sets mode: +v chocobo___
[23:11:48] *** chocobo__ has quit IRC
[23:11:49] *** chocobo___ is now known as chocobo__
[23:15:41] *** rbyers_ has quit IRC
[23:16:03] *** saintlou is now known as saintlou|away
[23:16:03] *** Solet has quit IRC
[23:16:09] *** Solet has joined #chromium-os
[23:16:21] <davidjames> darinski: Time to reopen?
[23:16:41] <darinski> davidjames: i want one VMTest to cycle green
[23:16:44] <davidjames> darinski: We still have a few doomed builds going but they can be cancelled and the tree reopened
[23:16:50] <davidjames> darinski: k
[23:17:20] <darinski> davidjames, sjg: i'd suggest reopen as soon as one PFQ VMtest cycles green. i'll run and grab a sandwich
[23:17:36] *** saintlou|away is now known as saintlou
[23:17:37] <davidjames> darinski, sjg: pineview and generic full look doomed, there are probably others
[23:17:50] *** rbyers_ has joined #chromium-os
[23:19:32] *** rbyers_ has quit IRC
[23:20:14] <sjg> Yes, but does it matter? We are still waiting for a successful build
[23:21:39] *** unreal has joined #chromium-os
[23:23:28] <sjg> Build 5193 went through ok
[23:27:35] *** katier has joined #chromium-os
[23:27:35] *** ChanServ sets mode: +v katier
[23:27:37] <davidjames> sjg: Cool, now if you want to reopen the tree you'll want to kill the doomed builds first
[23:27:43] <crosbot> tree became 'Tree is open (5193 went through testing OK)'
[23:27:48] <davidjames> sjg: If you don't kill the doomed builds they'll close the tree when they fail
[23:28:11] <sjg> Oops, just opened; will look for more
[23:31:25] <sjg> Do did the change go past the PFQ, and that's why everything has to be stopped?
[23:31:34] <sjg> Looks like I should stop the ARM ones also
[23:33:55] <sjg> OK hopefully that is enough, will keep an eye on it
[23:35:07] <crosbot> tree became 'Tree is closed (Automatic: "cbuildbot" on "tegra2_arthur-binary" from 89faa7bf977b6e17813b1e89c505c9e1a0cdebf1: dominich at google dot com <dominich at google dot com@72b347f9-1636-4932-8204-c47f5100e119>, glider at chromium dot org <glider at chromium dot org@0039d316-1c4b-4281-b951-d872f2087c98>)'
[23:35:19] <sjg> That didn't take long
[23:37:13] <sjg> Start Stage Sync: Write failed: Broken pipe
[23:38:58] <crosbot> tree became 'Tree is closed (sjg looking)'
[23:39:47] <sjg> arthur seemed broken, and hung around for hours
[23:40:11] <sjg> I am going to re-open since I can't see any useful error and it looks unrelated to any of today's commits
[23:41:15] <crosbot> tree became 'Tree is open (closure due to sync taking hours - restarted arthur builder)'
[23:42:08] *** Solet has quit IRC
[23:43:40] *** saintlou is now known as saintlou|away
[23:44:34] *** saintlou|away is now known as saintlou
[23:59:43] *** saintlou is now known as saintlou|away





top