Log of Software meeting, 2008-01-03

[Mitch Bradley]

[16:00] *** now talking in #olpc-meeting

[16:01] <Mitch_Bradley> Happy New Year, everyone.
[16:02] <m_stone> hear, hear.
[16:02] <cjb> You too.
[16:02] <jg> evening all.
[16:02] <jg> 'appy new year
[16:03] <jg> Mitch_Bradley: I gather you don't have to deal with our 
intel friends anymore....
[16:03] <cjb> I gather we don't have Intel friends anymore :)
[16:03] <jg> heh.
[16:03] <Mitch_Bradley> Sadly, no.  I was starting to have fun working 
with them.
[16:04] <jg> yeah....  it's a jeckle and hyde outfit.
[16:04] <m_stone> what's the bug list for this evening?
[16:04] <Mitch_Bradley> In any company that size, there are some number 
of good people.
[16:06] <jg> Mitch_Bradley: could you take a look at 5680, from your 
friend and ours, gnu?
[16:07] <Mitch_Bradley> That is a tradeoff.
[16:08] <cjb> I'd be more happy with the decision to ship G1G1 with dev 
keys needed if someone would own up to having made that decision and 
would explain it.
[16:09] <cjb> It seems like at the moment people who didn't make the 
decision are providing retrofitted explanations for why it might have 
made sense.
[16:09] <jg> who is taking minutes tonight?
[16:09] <Mitch_Bradley> cjb: You know that decisions at OLPC are never 
made for clear reasons.
[16:09] <Mitch_Bradley> There are made in meetings where everybody talks 
at the same time.
[16:10] <cjb> Mitch_Bradley: Right.  But if someone says "Actually, this 
wasn't intentional, and someone at Quanta thought it was what we 
wanted.", then we can correct it without having to go through the 
retrofitted argument.
[16:10] <Mitch_Bradley> I think it was intentional
[16:10] <Mitch_Bradley> But was wasn't made for a crystal clear reason.
[16:10] <dgilmore> Mitch_Bradley: isnt that all meetings
[16:10] <m_stone> It was definitely intentional and made for 
multifarious reasons.
[16:11] <dgilmore>  /decsisons
[16:11] <jg> m_stone: in practice, it's not working out well.
[16:11] <Mitch_Bradley> I expect that the majority of G1G1 users are 
perfectly happy with the status quo - apart from the ones that have DOAs.
[16:11] <m_stone> jg: so are we currently attempting to reach a decision 
on whether to change the policy?
[16:12] <Mitch_Bradley> but the developers are much more visible to us
[16:12] <m_stone> or are we simply attempting to decide on why we think 
the policy was put in place?
[16:12] <jg> m_stone: not at the moment...
[16:12] <cjb> m_stone: I don't think either decision can happen without 
neuralis.
[16:12] <jg> I was mostly just asking Mitch to look at the part of gnu's 
suggestion that made the most sense to me...
[16:13] <Mitch_Bradley> which part is that, exactly?
[16:13] <cjb> I'm guessing the last part of the second-to-last comment
[16:13] <jg> protecting the flash from malware does not require locking 
off the firmware, just write protecting before transferring control.
[16:13] <cjb> which states that the reason we turned it on can't involve 
malware.
[16:14] <jg> since the update is done using signed firmware, and by the 
firmware.
[16:14] <cjb> so we need to know whether the decision to turn it on was 
made for that (malware) reason.
[16:15] <m_stone> I had always understood the point of the developer key 
mechanism to be 'by requesting and using this developer key, you assert 
that you are taking full responsibility for maintaining the system in 
your possession'
[16:15] <cjb> so that we can know whether the reasoning behind the 
decision is vacated.  I think the hypothetical people who would have 
made the decision already understand/understood that.
[16:15] <jg> enough of this topic for the moment, I think....
[16:15] <m_stone> From that perspective, requiring G1G1 customers to 
request and use developer keys to access the firmware serves two purposes:
[16:15] <cjb> But arguing based on so much mindreading and with so 
little presence of people who actually made the decision is irritating.  
Moving on sounds good.
[16:16] <m_stone> as a 'warning flag' that by using such a mechanism, 
they have entered dangerous waters.
[16:16] <Mitch_Bradley> we need to have a scheduled meeting on the 
topic, with an invite list, and a voting procedure.  Robert's Rules of 
Order, perhaps.
[16:16] <m_stone> and as a means to generally perserve our ability to 
remotely restore machines to a known-good state by distributing signed 
firmware scripts as necessary.
[16:17] <m_stone> I am content with Mitch's suggestion.
[16:17] <jg> subject for another time and meeting.
[16:17] <Mitch_Bradley> There is a reason why formal meeting procedures 
evolved...
[16:18] <jg> OK, Mitch, please take minutes.  I call this meeting to 
(dis)order ;-).
[16:18] <jg> cjb: how goes OHM?
[16:18] <cjb> good!  I have four or five bugs waiting to be tested fixed 
in latest joyride before closing.
[16:19] <cjb> including our X crash bug.
[16:19] <jg> cool.
[16:19] <cjb> Bernie had a bright idea.
[16:19] <jg> ?
[16:19] <cjb> The way the X signal stuff works is that you can register 
a signal handler for if there is a fatal X error, and you will be killed 
directly after control reaches the end of the handler whether you want 
to or not
[16:19] <cjb> but you can exec() yourself again in that handler.  so now 
we do.
[16:19] <jg> yeah, my mistake.
[16:19] <cjb> ie. OHM restarts when X does.
[16:19] <jg> ah, ok.
[16:20] <jg> cool
[16:20] <jg> you'll be testing #1396 as  well I hope?
[16:20] <cjb> sure.  if suspend on idle works at all, that will too.
[16:21] <jg> is there any hope for 2765, or do we push it out?
[16:21] <cjb> ugh
[16:21] <cjb> Trac is giving me a "No space left on device"
[16:21] <cjb> when trying to view that ticket
[16:21] <jg> ouch.
[16:22] <jg> not good.
[16:23] <cjb> seems to have recovered.  Yes, I think we have to push 
that out.  Jordan says there's still a risk of crashes when setting RTC 
alarms, if they have a short duration.
[16:23] <cjb> So let's get it robust for Update.2.
[16:23] <cjb> the alternative was to use a EC-based timer instead of the 
RTC.  That might still be the way we go.
[16:24] <cjb> because we'll eventually want an EC timer to get subsecond 
wakeup accuracy.
[16:24] <jg> yup.
[16:24] <jg> 5243 should be closed....
[16:24] <cjb> agreed.
[16:24] <cjb> will do.
[16:25] <m_stone> jg: do you have a query that you're going over or is 
this all from personal notes?
[16:25] <cjb> m_stone: we're looking at all OHM-related bugs.
[16:25] <m_stone> cjb: thanks.
[16:25] <jg> blockers against cjb.
[16:26] <cjb> the last OHM bug to cover is http://dev.laptop.org/ticket/3355
[16:26] <cjb> but it isn't assigned to me
[16:27] <cjb> and it involves an EC change and then a kernel change and 
then an OHM change
[16:27] <cjb> and since Richard hasn't started on it yet, I think we 
should slip it.
[16:27] <jg> ouch...  Probably so.  no smithbone tonight.  Let's check 
with him in the morning.
[16:28] <jg> Right now, we really lose if the machine is suspended left on.
[16:28] <jg> maybe we need a temporary policy if the machine is idle for 
n hours to shutdown.
[16:28] <cjb> Okay.  I think he has a lot of blockers that haven't seen 
progress.. for example, the repeated game-key on wakeup bug is back
[16:28] <jg> yeah.
[16:29] <jg> Let's corner him tomorrow.  He's having too much fun with 
the battery charger ;-).
[16:29] <cjb> not saying he hasn't been working on them, but that Trac 
isn't up to date, and they're critical bugs, so maybe you could go 
through his bugs with him?
[16:29] <cjb> yup yup.
[16:29] <jg> cjb: the other piece of ohm is to reset the touchpad.
[16:30] <jg> Any progress there, or did holidays intervene as I expect?
[16:30] <cjb> jg: yup.  also not my bug.
[16:30] <jg> awaiting dilinger?
[16:30] <cjb> yeah.
[16:30] <cjb> he needs to tell me what conditions to perform the rest 
under, and how to perform it.
[16:30] <cjb> s/rest/reset/
[16:31] <jg> cjb: when going on/off external power.
[16:31] *** _bernie (n=bernie at 1cc-dhcp-123.media.mit.edu) joined
[16:31] <cjb> ah.  he could do that in the kernel, then.
[16:31] <jg> When reopening the laptop.
[16:31] <cjb> I think he's more concerned about fixing the jumpiness 
problem that *isn't* related to recalibration
[16:31] <jg> when closing, in principle, we should power it down into 
its deep sleep.
[16:31] <cjb> but to corrupt packets coming out of the touchpad
[16:31] <jg> yeah, I know.
[16:32] <jg> I need to get a braindump from him on where we are with it.
[16:32] <cjb> yeah.  again, there's no kernel interface yet.  but I'll 
be able to add to ohm as soon as there is, if we decide ohm is the place 
for it.
[16:32] <cjb> _bernie: maybe you have some info?
[16:32] <cjb> _bernie: we're wondering how touchpad 
reset/autorecalibration is going, but dilinger isn't here
[16:33] <_bernie> cjb: I've not been following that particular bug
[16:33] <cjb> righto.  we'll have to move on.
[16:33] <jg> ok, bernie next.
[16:33] <jg> tablet mode?
[16:34] <jg> 5268?
[16:34] <_bernie> jg: something broken in the kernel...
[16:34] <_bernie> jg: hal does not see the device as an input.mouse or 
input.tablet any more...
[16:34] <_bernie> I've done some forensics, but it seems we've not 
screwed up when we applied/reverted/reapplied evdev changes lately
[16:34] <jg> has hal changed at all recently?
[16:35] <_bernie> I checked, the current rpm is a few months old
[16:35] <jg> hmmm....  maybe time for a consult with davidz....
[16:36] <m_stone> jg: for what it's worth, we've seen a lot of breakage 
this week that can't be explained by changes in the buildlog.
[16:36] * bemasc is an example
[16:36] <_bernie> 6-8 months ago I had to fix the very same bug... I 
just don't remember what I have done and whay it got lost :-)
[16:36] <jg> m_stone: not related, tablet is broken for quite a while.
[16:36] <cjb> yes, I was going to mention that; networking is broken in 
Joyride, and we can't work out why.
[16:36] <m_stone> jg: bemasc's bug today, the latent incomplete 
dependency graph issues that _bernie has been triggering, and so forth
[16:36] <bemasc> cjb: Update.1 too
[16:37] <cjb> eek!
[16:37] <cjb> I didn't know that
[16:37] <jg> dgilmore: ????
[16:37] <cjb> that's awful, then.  we have a new critical blocker.
[16:37] <_bernie> why Update.1 too?
[16:37] <cjb> dgilmore doesn't have any ideas either.
[16:37] <cjb> bemasc: you sure?
[16:37] <_bernie> ah, so it's not ping
[16:37] <bemasc> I'm running 672, and I can't connect to any wireless 
routers, secure or open
[16:37] <cjb> maybe it's one of the ~30 packages we threw in from Fedora 
updates recently
[16:37] *** cahalan (n=albert at user-0c6t4ba.cable.mindspring.com) joined
[16:37] <bemasc> has anyone here done that succesfully under 672 or 
other recent?
[16:38] <cjb> that was just under a week ago, I think?  there's a bug 
about it..
[16:38] <_bernie> works in 1489
[16:38] <m_stone> bemasc: you tested some builds before and after the 
inclusion of the fedora updates, right?
[16:38] <dgilmore> jg: iputils got dropped in joyride because 
initscripts no longer required it
[16:38] <bemasc> m_stone: yeah, but I wasn't testing for router connection
[16:38] <jg> dgilmore: that was causing the breakage?
[16:38] <dgilmore> thats one example of things breaking for odd reasone
[16:39] <dgilmore> we have seen deps change and different packages come 
and go
[16:39] *** RickEvans (n=RickEvan at 197.158.243.24.cfl.res.rr.com) joined
[16:39] <jg> good point.
[16:39] <_bernie> also in Update.1?
[16:39] <m_stone> it's not immediately obvious why that would kill 
networking though.
[16:39] <jg> we can compare package inventories for things that have 
vanished.
[16:40] <jg> m_stone: if you forget to declare a dependency, then the 
command yuo might need to run a script can evaporate.
[16:40] <bemasc> #5749 is connected to this
[16:40] <m_stone> jg: true, but we don't have a mechanism at the moment 
for explaining why those changes are occuring.
[16:40] <cjb> bemasc: also perhaps http://dev.laptop.org/ticket/5650
[16:40] <jg> heh.  sometimes people screw up.
[16:40] <dgilmore> m_stone: i know what caused iputils to get dropped
[16:40] <m_stone> dgilmore: yes, I too know _now_.
[16:40] <jg> Like the "feature" of cleaning up the font aliases that the 
people involved didn't understand...
[16:40] <dgilmore> but ive not looked at why it was dropped as a 
dependancy for initscripts
[16:41] <cjb> _bernie: you should know that, right?  :)
[16:41] <bemasc> does the package changelog list _all_ packages added or 
dropped, or just top-level changes (and not their dependencies)?
[16:41] <m_stone> dgilmore: I was trying (and failing, it seems) to make 
a point about the completeness of our changelogs.
[16:41] <_bernie> hmm.. but this wouldn't explain why networking doesn't 
work in update.1...
[16:41] <dgilmore> bemasc: have you tried with no power plugged into 
your laptop
[16:41] <m_stone> which are actually fairly good for the .xo packages 
now, but not for RPM-level changes made to pilgrim and to rpms stored in 
koji.
[16:41] <bemasc> dgilmore: no.  Should I unplug and reboot?
[16:41] <dgilmore> m_stone: indeed they are not complete
[16:41] <_bernie> and we'd benefit from seeing changelogs from koji too
[16:42] <dgilmore> bemasc: try that ive been meaning to file a bug  i 
can only connect if unpowered
[16:42] * cjb blinks.
[16:42] <jg> dgilmore: it seems like some work is needed on the 
buildlogs, as we are losing quite a bit of time by lack of visibility....
[16:42] <dgilmore> _bernie:  yes we need to get that info also
[16:43] <dgilmore> jg: ill make them better
[16:43] <m_stone> jg: I think there's a bug lying around.
[16:43] <jg> dgilmore: thanks.
[16:43] <bemasc> _bernie: I recall something about the touchpad not 
being detected as a tablet due to a lack of pressure-sensing.
[16:43] <jg> m_stone: no doubt...
[16:43] <_bernie> I've been working at cleaning up dependencies... now I 
believe olpc-utils requires what it uses... I also opened bugs for sugar 
and other packages I felt had dependency problems
[16:43] *** mchua (n=mchua at 210.213.195.117) joined
[16:43] <mchua> #join olpc-groups
[16:43] <m_stone> #4253
[16:43] * mchua slaps head
[16:43] <jg> _bernie: there is a time for cleanup, and a time for 
stability...
[16:43] <jg> we're at the time for stability....
[16:44] <jg> cleanup *after* the release.
[16:44] <cjb> _bernie: surely not again after the mkinitrd fiasco?
[16:44] <_bernie> bemasc: hmm... yes! now I remember... hal required 
absolute x+y and pressure to tell it apart from a joystick
[16:44] <jg> yeah.
[16:44] <jg> a crock in hal.
[16:44] <jg> we need to talk to davidz about fixing it right.
[16:44] <jg> But for now, let's put the kludge in.
[16:44] <_bernie> cjb: I fixed that too.  we could reiterate the 
mkinitrd thing any time safely now (but of course we may postpone it to 
update.1)
[16:45] <_bernie> jg: ok, I will.
[16:45] <cjb> _bernie: yeah, we should postpone it.
[16:45] <cjb> (another question in case happens to know:  where is cscott?)
[16:45] <_bernie> jg: davidz is currently offline.
[16:45] <jg> _bernie: please also enter a bug against hal, though, 
explaining the hal crock.
[16:45] <cjb> s/in case/in case anyone/
[16:45] <jg> _bernie: no, he's live on Gimpnet #fedora-desktop this moment.
[16:45] <dgilmore> _bernie: i wont change that until after update.1
[16:46] <_bernie> gimpnet??
[16:46] <cjb> dgilmore: good man :)
[16:46] <cjb> _bernie: irc.gnome.org
[16:46] <jg> _bernie: 5626?
[16:46] <jg> m_stone: you too...
[16:47] <bemasc> dgilmore: unplugged, rebooted, same failure.  I'll post 
logs to one bug or another
[16:48] <_bernie> cjb, jg: irc.gimp.org 6667
[16:48] <m_stone> ah yes. apologies. 775 or 755 would be appropriate.
[16:48] <cjb> m_stone: update the bug and reassign to bernie, then (or 
dgilmore?)
[16:49] <jg> _bernie: let's get that one done immediately.  it's a 
trivial blocker that has rotted for several weeks.
[16:49] <_bernie> m_stone: is networking still broken in joyride after 
you fix too?
[16:49] <cjb> _bernie: why not have dgilmore do the 775/755 fix after 
generating the image?
[16:49] <m_stone> cjb: I'm working on it.
[16:49] <m_stone> cjb: I've answered this one before.
[16:49] <m_stone> cjb: I'm not sure why this bug came up.
[16:49] <jg> _bernie: is 5735 (legacy fonts) fixed?
[16:49] <m_stone> cjb: and the answer is a bit subtle.
[16:50] <m_stone> cjb: the problem concerns directories that are created 
on first boot and also directories that we've inherited from an old 
install after running olpc-update.
[16:50] <_bernie> jg, m_stone: I'm waiting for feedback on #5626
[16:50] <dgilmore> cjb: id rather fix it in a package  than in pilgrim
[16:51] <cjb> dgilmore: why?  isn't that *less* robust?
[16:51] <_bernie> m_stone: specifically, shouldn't I make /home/olpc 
world aXessible?
[16:51] <cjb> I guess it's debatable.  Why rely on something to happen 
at run-time that you already know at build-time will need to happen?
[16:51] <_bernie> jg: we have a fontpath bug in X that prevents adding 
anything to the fontpath
[16:51] <cjb> anyway, your call, I'm just surprised.
[16:52] <_bernie> jg: this is why I did not see the legacy fonts used in 
the first place
[16:52] <jg> that's breaking aliases too?
[16:52] <dgilmore> cjb: because pilgrim is not the place for permanent fixes
[16:53] <_bernie> cjb: we're trying to reduce the number of 
postprocessing hacks that pilgrim does.  ideally, there should be 0.
[16:53] <cjb> fair enough.
[16:53] <_bernie> cjb: fedora does not need any... because their 
packages are done the way they need them already. it's us that tried not 
to branch too many packages by customizing things in pilgrim instead.
[16:54] <_bernie> bernieadmin --quiet
[16:54] <m_stone> _bernie: I'll reply in detail in the bug.
[16:55] <cjb> so, no leads on the "networking broke and we don't know 
why" bug?
[16:55] <_bernie> m_stone: I now realize I should have reassigned it to 
you to solicit feedback... cscott also suggested it to me a couple of times
[16:55] <bemasc> cjb: I just uploaded shell.log to #5749
[16:56] <jg> _bernie: so we sort of think/hope the touchpad is behaving 
better with the 2 line patch?
[16:56] *** HoboPrimate (n=jobezone at a213-22-209-55.cpe.netcabo.pt) joined
[16:56] <bemasc> HoboPrimate knows something about the "networking 
suddenly broke" bug too
[16:57] <_bernie> jg: I'm very confident we'll have #2804 (and #5799, 
which is a dupe) fixed by it
[16:58] <HoboPrimate> bemasc: I don't know much more than what you know 
:) only noticed that it sometimes uses random channels. I've seen it use 
1,6,8 and 11 (my router uses 11), but doesn't work.
[16:58] <_bernie> jg: a user already reported success (but we can't 100% 
trust success stories because the behavior is intermittent)
[16:58] <jg> _bernie: do we have other weirdness to chase?
[16:59] <_bernie> cjb, bemasc: can anyone remember last build that 
worked? I have 1489 here and it works
[16:59] <cjb> and 1490 doesn't, right?
[16:59] <HoboPrimate> 663 works (667 was the first that I tested that 
was broken)
[16:59] <_bernie> jg: the vertical mouse bug is still open, but we know 
it's the hardware and maybe we should reassign it to alps, or quanta 
people... or maybe wad.
[16:59] <_bernie> cjb: I dunno
[17:00] <_bernie> so it wasn't ping after all. this is a change from *today*
[17:00] <jg> _bernie: assign that one to wad for now.
[17:00] <_bernie> jg: ok
[17:00] <jg> I closed 5799 as a dup.
[17:01] <jg> we'll see if we can get a few more success reports on the 
touchpad to be sure on it before closing the other, though it seems 
we've got it.
[17:01] <jg> _bernie: have you looked at 5706 at all?
[17:02] <_bernie> jg: kimquirk reassigned it already: owner changed from 
dilinger to victorchao
[17:02] <jg> ok, great.
[17:02] <_bernie> jg: I thought #5706 was an EC problem?
[17:02] <jg> bemasc: since you are here: #5818
[17:03] <jg> _bernie: probably.
[17:03] <jg> I'll talk with richard tomorrow.
[17:03] <bemasc> between 669 and 670, something happened to break 
Distance-11
[17:03] <bemasc> specifically, to break Distance-11's stream-tubes code, 
which uses UNIX sockets
[17:03] <jg> bemasc: any clues from the buildlog?
[17:04] <_bernie> jg: it has to be EC because it also happens on Windows 
and because they say they receive garbage from PS2, but the ALPS does 
not know about the game buttons
[17:04] <cjb> bemasc: does it work if you rm /etc/olpc-security?
[17:04] <bemasc> jg: the buildlog seems completely innocent.
[17:04] <bemasc> cjb: ooh, I haven't tried
[17:04] <cjb> (and reboot)
[17:04] <cjb> m_stone: is that the right filename?
[17:04] <bemasc> jg: at a minimum, the packages that changed are all 
irrelevant
[17:04] <bemasc> jg: so it would have to be some other fluke during the 
build
[17:04] <bemasc> jg: but it's still broken the same way in 672
[17:05] <bemasc> jg: so it's pretty mysterious to me
[17:05] <_bernie> bemasc: the build log does not include pilgrim 
changes. have we checked?
[17:05] <bemasc> _bernie: I have no understanding of pilgrim, so no
[17:05] *** mchua_ (n=mchua at 58.69.229.231) joined
[17:06] <dgilmore> bemasc: 664 was the first build that got security 
really turned on
[17:06] <bemasc> dgilmore: it works great in 669
[17:06] <_bernie> bemasc: I see nothing suspect... 
http://dev.laptop.org/git?p=users/cscott/pilgrim
[17:07] <m_stone> cjb: just got back from editing #5626 - one second 
while I read the backlog.
[17:07] <_bernie> dgilmore: another suggestion: I think we should tag 
pilgrim's git tree with build numbers as we go
[17:07] <m_stone> _bernie: yes, I checked.
[17:08] <dgilmore> _bernie: that could be useful
[17:08] <jg> seems like it should be a plan.
[17:08] <m_stone> _bernie: there were no obvious changes in pilgrim. I 
also checked for uncommited changes, but none were apparent.
[17:08] <jg> _bernie: add a trac item for the suggestion, so we can't 
forget.
[17:08] <m_stone> I think we already are doing some tagging, actually.
[17:08] <m_stone> We certainly keep track of what pilgrim commit was 
used to build each build somewhere.
[17:09] <_bernie> jg: ok
[17:09] <dgilmore> m_stone: that would involve some changes in the work 
flow  but would not be horrible
[17:09] <dgilmore> right now the git tree on pilgrim.l.o  is read only
[17:10] *** tseago quit ( )
[17:10] <jg> m_stone: your turn...
[17:11] <jg> 5033?
[17:11] <m_stone> jg: putting the pieces together this evening.
[17:11] *** mchua quit (Read error: 110 (Connection timed out))
[17:11] <m_stone> bernie's going to help me spin a test-build to try 
them out before we throw them on joyride.
[17:11] <_bernie> m_stone: sure
[17:11] <jg> ok.
[17:12] <jg> 3801?
[17:12] <m_stone> the current minor hangup is that scott doesn't build 
olpcrd in a standard fashion.
[17:12] <m_stone> but we'll work around that.
[17:12] <m_stone> all my remaining blockers are tracking bugs for 
long-term work.
[17:12] <jg> 3801 should have what for a milestone then?
[17:13] <bemasc> cjb: yep, it works without security
[17:13] <m_stone> bemasc: ooh.
[17:13] <jg> shouldn't be update.1, by that statement.
[17:13] <jg> m_stone: heh.
[17:13] <_bernie> bemasc: are there rainbow changes in between?
[17:13] <bemasc> _bernie: not that I can see
[17:13] <m_stone> jg: you could put them all in FutureFeatures if you 
wanted, but I don't really see how it would help.
[17:13] <_bernie> that's ultra weird
[17:14] <m_stone> jg: my recommendation is that we just bump them along 
as we go.
[17:14] <jg> m_stone: gives us better clarity on what is left to get 
update1 out the door.
[17:14] <jg> it matters...
[17:14] <jg> (that it not be against the current release).
[17:14] <m_stone> jg: my point is that we picked out chunk of the 
overall work described by that bug and said 'this is the update.1 stuff'
[17:15] <m_stone> 5033 is the only remaining part of that work.
[17:15] <m_stone> well, that plus bemasc's issue.
[17:15] <m_stone> :)
[17:15] <jg> what should I target 3801 against?  update.2?
[17:15] <m_stone> that's what I'd recommend.
[17:15] *** soGritty quit ("Leaving" )
[17:15] <m_stone> We'll carve out another chunk as update.2 progresses, 
at which time we can push it out further.
[17:15] <_bernie> jg: #5827 filed
[17:16] <cjb> bemasc: ouch
[17:16] <cjb> bemasc: that's both good and bad, I guess.
[17:16] <bemasc> cjb: well, it helps clarify what's going on
[17:17] <jg> bemasc: is version 10 in update.1?
[17:17] <m_stone> jg: you should probably reassign #5346 to someone 
appropriate.
[17:17] <bemasc> jg: version 11 is in 672 and up
[17:17] <bemasc> jg: but version 11 only works in 669 and lower
[17:18] <bemasc> jg: and nobody knows what changed to make it stop working
[17:18] <jg> heh....
[17:19] <cjb> on that note, shall we finish up?  :)
[17:19] <jg> yeah....
[17:19] <cjb> in summary:  networking and security are broken, and we 
don't know why.  :)
[17:19] <jg> feh.
[17:19] <m_stone> cjb: that was a foul summary.
[17:19] <dgilmore> bemasc: did it work in 669?
[17:19] <bemasc> dgilmore: yes
[17:20] <jg> seems like tomorrows problems, unless someone has a 
blinding insight tonight...
[17:20] <bemasc> dgilmore: more accurately, it works if you install it 
into 669
[17:20] <dgilmore> bemasc: good  it wasnt the adding of fedora updates 
that broke it
[17:20] <dgilmore> just looking at what changed in between
[17:20] <bemasc> dgilmore: yeah, I was surprised by that
[17:20] <m_stone> cjb: rainbow changed in 666 and not since.
[17:21] <bemasc> dgilmore: the only thing in the changelog that I can't 
immediately rule out is python-jinja
[17:21] <bemasc> I have no idea what that is
[17:21] <m_stone> so I agree that it's interesting that it's broken in 
670 and I'm happy to help bemasc figure out why.
[17:21] <jg> m_stone: to ask the obvious question: how goes the tool for 
detecting bad permissions?
[17:21] <cjb> m_stone: yeah.  it doesn't look like networking changed 
explicitly either.
[17:21] <m_stone> jg: haven't worked on it yet.
[17:21] <HoboPrimate> well, if security was turned on in 664, and I had 
wireless in 663 but not starting at 667, could security be the problem?
[17:21] <dgilmore> bemasc: python-jinja  was in olpc-library-core  and 
got broken out
[17:21] <jg> ok, I declare this meeting over....