Hardy LRM git repository

[Tony Espy]

Tim Gardner wrote:
> Steve Conklin wrote:
>> On 04/24/2009 02:05 AM, Stefan Bader wrote:
>>> Tim Gardner wrote:
>>>> Stefan,
>>>>
>>>> I think its worthwhile to create a git repository for Hardy LRM,
>>>> especially since you've unrolled the Broadcom tarball. It will also make
>>>> it easier to manage the netbook-lpia branch. The other LRM binaries are
>>>> not changing enough that it will trigger the inefficiencies with git
>>>> that we saw during Hardy development.
>>>>
>>>> rtg
>>> While probably not changing that much, they are huge (6x~10MB for Nvidia and 
>>> one 52MB pack for ATI). The question is how gracefully git will handle such 
>>> amounts. On the other hand I saw that it seems to do some sort of binary diff even.
>>> It certainly helps our sanity to have a git repo, so our packages are found and 
>>> can be handled the same. And hopefully my connection up is better now as I 
>>> remember an upload tried while still in Canada suffered from the huge amount of 
>>> data and had to be ass-kicked to the DC(s) first.
>>> Andy, what would you think from the git side and Steve, you think this would 
>>> help your workflow?
>>>
>>> Stefan
>>>
>> Since we're still establishing work flow and we don't yet have lrm under management,
>> I'll be happy to use whatever works for the rest of the distro, with the same
>> caveats that have applied to the netbook-lpia in kernel and lum - that we maintain
>> a branch that is synced as often as is convenient with the main branch, and have the
>> ability (though discouraged) to create additional (very short-term) branches as needed to
>> support specific releases when we are unable to put them into our primary netbook-lpia
>> branch.
>>
>> Steve
>>
> 
> Such was my intent when I suggested subjecting LRM to git management. I 
> see no reason to treat it different then the other Hardy packages with 
> respect to LPIA branch management.

Tim --

I have a few questions for you re: the new lrm git trees and the 
Broadcom 'wl' driver, as a new version has been released by Broadcom 
recently ( 5.10.91.9 ).  I have the new version prep'd for update, 
however I want to be sure I have the full process in mind before I start 
sending patch requests...

1. The old lrm source tarballs contained separate broadcom architecture 
specific tarballs for 32 / 64 bit.  From poking around the new git 
trees, and staging the new update, it looks like the only difference 
between the tarballs was the prebuilt wlc_hybrid.o file.  Now it looks 
like we've just re-named this file to include an architecture suffix, so 
there are actually two files in /lib now, and the right one is copied 
and stripped of it's suffix on build.  Is that correct?

2. If a git commit includes a binary file, does that preclude the use of 
email-formatted patches ( ie. you need to use a pull-request )?

3. How do we handle uniform patches across multiple distro series?  For 
instance, in order to upgrade the 'wl' driver across hardy ( needed for 
netbooks ), intrepid, and jaunty ( there's no karmic tree yet ), do I 
need to a separate lrm bug against each series?  Do I also need to send 
four patch requests or is there a way to do this in a single email?

As I mentioned earlier, I have the new version staged, and would like to 
submit my patch(es) as soon as I'm comfortable with testing.

I also have a patch for wl's MODULE_LICENSE ( it's "" ), which somehow 
was dropped along the way ( it used to be included in the vlan patch ).

Finally, I have one final patch which fixes a permission / capability 
problem with the driver which prevents a user from running iwconfig or 
iwlist if not privileged.

Thanks,
/tony