Hardy LRM git repository

[Stefan Bader]

Tony Espy wrote:
> Stefan Bader wrote:
>> Hi Tony,
>>
>> Tony Espy wrote:
>>
>>  > 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?
>>
>> This is correct. The latest Hardy LRM was changed to look like the 
>> Intrepid and Jaunty repo (which makes it simpler to update all). 
>> Basically the tarballs from broadcom were identical, except the binary.
>>
>>> 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 )?
>>
>> If you look at the output of git-format patch, it already produces 
>> some mail compliant output. In order to get things over and applied, 
>> however, it is simpler to pull that from another repo.
>>
>>> 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 all the broadcom drivers now should be on the same level, there 
>> would be one SRU request (bug report) with tasks for all releases. 
>> This also requires only one mail.
> 
> OK.  Since I've never gone through the SRU process before, I may need a 
> little guidance.
> 
> It sounds like step (1) is for me to open a bug against the l-r-m source 
> package for the driver update, correct?  Next, it sounds it needs to be 
> nominated for the various releases.
>

Right, the bug would be the first step. Due to historical naming for lrm this 
might end up with multiple affected packages as the hardy package contained the 
2.6.24 in that name. With Intrepid it was named l-r-m only.
So, you open it against lrm, which will by default be against the trunk 
(Karmic), then add nominations for Intrepid and Jaunty and add the l-r-m-2.6.24 
for Hardy.

> The SRU process states that the bug needs to be marked FixReleased 
> before nominating it as an SRU for earlier releases, however at this 
> point there is no git tree for karmic lrm.
> 

Atually I am not sure we always kept to that. Though it sort of makes sense. 
Usually it sort of went in parallel and the Trunk, usually get released sooner 
than the older releases. This is different if we drop the lrm package for 
Karmic completely.
> Should I just enter the bug, and nominate it for the various releases 
> anyways?
> 
So, yes, I would say do the nominations and we start with Jaunty and proceed 
backwards.

>>> 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.
>>
>> The new Hardy LRM git is public on zinc. The paths are historically 
>> slightly different (updates/ubuntu-resticted). So whatever repo you 
>> choose as a base, be so kind to mention it. ;-)
>>
>>> 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.
>>
>> Best use separate commits to (re-)add those. And probably add a note 
>> about this to the BOM file. So the next one that feels like just 
>> extracting the new tarball is warned.
> 
> OK, sounds good.
> 
> Ciao,
> /tony
> 


-- 

When all other means of communication fail, try words!