I'd like to provide a binary build of OpenWrt packages, however I want to
comply with the terms of the GPL. I figured the most obvious thing to do would
be to copy the way OpenWrt does things. I'm not convinced that OpenWrt
complies with the GPL with regard to section 3, as I have no idea how
--- On Tue, 20/9/11, harish badrinath wrote:
> Unless upstream ships binary blobs, freedom to demand
> "show me the
> code" is AFAIK satisfied.
I don't think you understood. I know how to build *a* version of OpenWrt. I
don't know how to build *the* version that created a snapshot.
The GPL s
--- On Tue, 20/9/11, edgar.sol...@web.de wrote:
> Did you see the first sentences of e.g.
> http://downloads.openwrt.org/backfire/10.03.1-rc5/README
That source revision wasn't my concern.
So let's see if I've got this right:
1) Check out correct revision as per instructions in release README
--- On Tue, 20/9/11, Bastian Bittorf wrote:
> If you "simply" want to be GPL-compliant,
> you can build your image and _then_ make
> an archiv of the hole builddir. so you have
This is better than nothing, but I suspect won't fit on a single DVD :(. It is
also unpleasant for the recipient, fo
--- On Tue, 20/9/11, edgar.sol...@web.de wrote:
> From: edgar.sol...@web.de
> Subject: Re: [OpenWrt-Devel] OpenWrt GPL compliance
> To: "OpenWrt Development List"
> Date: Tuesday, 20 September, 2011, 14:46
> On 20.09.2011 14:33, bifferos wrote:
> > So how do
--- On Tue, 20/9/11, Michael Heimpold wrote:
> From: Michael Heimpold
> Subject: Re: [OpenWrt-Devel] OpenWrt GPL compliance
> To: "OpenWrt Development List"
> Date: Tuesday, 20 September, 2011, 19:07
> Hi,
>
> > I can understand how it works for tagged feeds, e.g.
> >
> svn://svn.openwrt.org/
--- On Sun, 12/10/08, RHS Linux User <[EMAIL PROTECTED]> wrote:
> From: RHS Linux User <[EMAIL PROTECTED]>
> Subject: Re: [OpenWrt-Devel] Smallest Linux
> To: "OpenWrt Development List"
> Date: Sunday, 12 October, 2008, 11:26 AM
>
> I am very much looking forward to anyone's further
> commen
--- On Sat, 18/10/08, Stanislav Sinyagin <[EMAIL PROTECTED]> wrote:
> In the short term, I want to build a kernel which would
> have
> CONFIG_CMDLINE pointing the root to the USB stick --
> basically it's
> what bifferos is doing in his squidge distribution. But I
>
Stanislav,
I don't wish to belittle your efforts, and I think this will be
genuinely useful to quite a few people, however it's worth noting
that BR6104KP is not the only target that could benefit from
USB-root, therefore, one can see a series of profiles springing up alongside
every single ta
--- On Mon, 10/11/08, Brian J. Murrell <[EMAIL PROTECTED]> wrote:
> From: Brian J. Murrell <[EMAIL PROTECTED]>
> Subject: Re: [OpenWrt-Devel] repeated kernel config questions
> To: "OpenWrt Development List"
> Date: Monday, 10 November, 2008, 1:53 PM
> On Mon, 2008-11-10 at 08:44 -0500, Robert P.
--- On Mon, 10/11/08, Harald Schiöberg <[EMAIL PROTECTED]> wrote:
> From: Harald Schiöberg <[EMAIL PROTECTED]>
> Subject: Re: [OpenWrt-Devel] repeated kernel config questions
> To: "OpenWrt Development List"
> Date: Monday, 10 November, 2008, 2:52 PM
> -BEGIN PGP SIGNED MESSAGE-
> Hash: S
I'm not very familiar with the kernel Kconfig/makefile layout, but it seems the
mach-rdc321x stuff, namely gpio.c and platform.c in
arch/x86/mach-rdc321x/ don't get compiled. I couldn't work out if there was
some kernel option needed to enable them, but judging from the other x86
architecture
?
> To: openwrt-devel@lists.openwrt.org
> Cc: "bifferos"
> Date: Thursday, 26 March, 2009, 9:08 AM
>
> -Inline Attachment Follows-
>
> Hi Simon,
>
> Le Thursday 26 March 2009 01:10:25 bifferos, vous avez
> écrit :
> > I'm not very familia
--- On Thu, 26/3/09, Florian Fainelli wrote:
>
> now, the mainline
> kernel does not probably boot correctly on any RDC 321x SoC
> due to no way to
> set the tick rate properly with everything that it implies
> on the other
> peripherals.
I guess run-time detection is ideal, however not sure
I am trying to add a new OpenWrt target by introducing a new set of files under
target/linux//.
I would like to avoid applying any generic kernel patches for this target,
however I'm unable to work out how to do this, other than to just remove all
generic patches and files prior to the build:
Felix,
Any chance we can get the above ticket fixed, at least for RDC?
You introduced the problem with r22305, and 5 months later it's still there. I
produced a patch disabling crashlog just for RDC, maybe it's only a problem on
that platform?
If you want you can reproduce this without the r
16 matches
Mail list logo
