ts-7000
[Top] [All Lists]

[ts-7000] Re: Rebuilding a kernel

To:
Subject: [ts-7000] Re: Rebuilding a kernel
From: "j.chitte" <>
Date: Wed, 11 Feb 2009 17:53:31 -0000
--- In  "Anouk Ahamitet" <> 
wrote:
>
> --- In  "charliem_1216" <charliem_1216@>
> wrote:
> > No, this is wrong.  Note that the failure is when compiling a 
script
> > on the *host*, using the *host* gcc.  It means only that your
> > Ubuntu-supplied gcc/glibc/headers were tripped up by the bug, and 
that
> > the (probably older) host gcc/glibc/headers used at TS was not.
> >
> > Even in reading the text of Sam's patch you linked to, it implies 
that
> > it failed only on some host systems, notably OS X, at the time
> > (May-07).  As other distros updated gcc/glibc/headers, I'm sure 
the
> > bug hit them too in time, like Ubuntu.
> 
> OK, I can accept that.  Technologic didn't mention that their
> package only worked with certain distros, just that it required
> an x86 linux, which I provided.  When I reported the error, I
> was only told that *I* did something wrong and, eventually,
> that they were no longer going to support me unless I convinced
> the president of their company to do so.
> 
> The least that could have done was to tell me what linux platform
> they are using, then I could get that and use it, too.  Especially 
if,
> as it seems, the patch I found explained that there could be a
> distro problem.  I never expected anything to compile locally in
> a cross-compile build as it sounds like a logical contradiction,
> but on second thought, I guess the thing might actually need to
> build local tools to produce the kernel.
> 
> > > When I reporting the bug, the fix and asked my contact at
> Technologic
> > > about this, he told me that I probably needed to run make 
menuconfig
> to
> > > change a setting (but he didn't say which one that might be) so 
that
> the
> > > broken file is not included.  If that is true, then it concerns 
me
> even
> > > more than the bug, because I wanted to start with exactly the 
same
> > > settings as Technologic so that the kernel we built as just like
> theirs
> > > except for the things we specifically wanted to change.
> > >
> > > Perhaps these things don't bother the linux gurus among
> Technologic's
> > > customers, but they concern me.
> >
> > I think there is no conspiracy here ... Probably TS was trying to
> > offer some help, without saying "I don't know why it fails for 
you, it
> > works for me".
> 
> Again, I wasn't thinking 'conspiracy' as much help pointing in the 
wrong
> direction, which is often worse than no help at all.  The problem 
was
> with
> my choice of an x86 linux distro, nothing else, which the support 
guy
> probably would have noticed if he is as proficient with linux as you
> sound,
> and bothered to look.
> 

Hi,

I think it would be instructive for TS management to read the 
following guide to GPL compliance. It appears they may have not yet 
done so.

http://www.softwarefreedom.org/resources/2008/compliance-guide.html


4.2.2  Building the Sources

Few distributors, particularly of embedded systems, take care to read 
the actual definition of Corresponding Source in the GPL. Consider 
carefully the definition, from GPLv3:

The "Corresponding Source" for a work in object code form means all 
the source code needed to generate, install, and (for an executable 
work) run the object code and to modify the work, including scripts 
to control those activities.

and the definition from GPLv2:

The source code for a work means the preferred form of the work for 
making modifications to it. For an executable work, complete source 
code means all the source code for all modules it contains, plus any 
associated interface definition files, plus the scripts used to 
control compilation and installation of the executable.



So they MUST supply the precise means to rebuild exactly what they 
distribute with thier products. This means , to refer to your earlier 
problem in reproducing and identicatl kernel, that they must supply 
the .config along with the kernel source code.

They are also required to supply the source for busybox they 
distribute and the relevent config to build EXACTLY the binary they 
distribute.

It is not sufficient to say "go get the source and fiddle around 
until you hit on a config that works about the same". 


None of this would be particularly hard to conform to nor would it 
disclose any trade secrets. It may however result in a lot less 
wasted time and frustration for thier customers. This would be good 
for everyone. It would reduce thier support overhead, improve 
customer relations, thier image and promote sales and confidence in 
their products.

This would seem to make sense from every angle and would go down a 
lot better than the dismissive responces sometimes given.

It would appear that there are some significant gaps in what is 
currently provided. Hopefully this can be improved to fully conform 
to GPL requirements.

best regards.






------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/ts-7000/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/ts-7000/join
    (Yahoo! ID required)

<*> To change settings via email:
     
    

<*> To unsubscribe from this group, send an email to:
    

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

<Prev in Thread] Current Thread [Next in Thread>
Admin

Disclaimer: Neither Andrew Taylor nor the University of NSW School of Computer and Engineering take any responsibility for the contents of this archive. It is purely a compilation of material sent by many people to the birding-aus mailing list. It has not been checked for accuracy nor its content verified in any way. If you wish to get material removed from the archive or have other queries about the archive e-mail Andrew Taylor at this address: andrewt@cse.unsw.EDU.AU