On 12/01/2016 10:29 PM, Rafał Miłecki wrote:
> On 1 December 2016 at 12:48, Zefir Kurtisi wrote:
>> On 12/01/2016 08:28 AM, Rafał Miłecki wrote:
>>> So you still may end up with base-files installed and /etc/banner
>>> being different. If you re-install that package, e.g.
>>> opkg install base-fil
On 1 December 2016 at 12:48, Zefir Kurtisi wrote:
> On 12/01/2016 08:28 AM, Rafał Miłecki wrote:
>> So you still may end up with base-files installed and /etc/banner
>> being different. If you re-install that package, e.g.
>> opkg install base-files*.ipk
>> you'll get banner changed to package's v
On 12/01/2016 08:28 AM, Rafał Miłecki wrote:
> On 28 November 2016 at 09:33, Zefir Kurtisi wrote:
>> We had the approach you describe for a long time (company-basefiles adding
>> to and
>> overwriting files in base-files package), but this does not work any more.
>> With
>> recent build-system c
On 28 November 2016 at 09:33, Zefir Kurtisi wrote:
> We had the approach you describe for a long time (company-basefiles adding to
> and
> overwriting files in base-files package), but this does not work any more.
> With
> recent build-system changes you can't have the same rootfs file in two
>
On 11/25/2016 08:14 AM, Rafał Miłecki wrote:
> On 16 October 2016 at 01:04, Jo-Philipp Wich wrote:
>> let me introduce a not strictly new way but another heavily under
>> documented buildroot feature which you can use to implement custom
>> modifications to packages which do not require source cod
On 25 November 2016 at 08:14, Rafał Miłecki wrote:
> I think a perfect model for organization/company that wants to be LEDE
> friendly would be to:
> 1) Ask them for complete LEDE-upstream support for their device
> 2) Handle all modifications using an own feed with their packages
>
> This is a pr
On 16 October 2016 at 01:04, Jo-Philipp Wich wrote:
> let me introduce a not strictly new way but another heavily under
> documented buildroot feature which you can use to implement custom
> modifications to packages which do not require source code edits.
>
> For every processed package Makefile,
Please revert this patch. This obvious breaks legitimate use cases.
On 10/04/2016 12:59 AM, Russell Senior wrote:
Fwiw, I ran into trouble with things busybox provides by default, but
where I've add packages with fuller versions. In my case it is
procps-ng from the packages feed. In order t
On 10/28/2016 05:21 PM, Jo-Philipp Wich wrote:
> Hi Zefir,
>
> what do you mean with overlay patches exactly?
>
> ~ Jo
>
I mean adding some private patches on top of those already contained in the
package's patches directory without touching the package itself. I thought the
same overlay mechani
Hi Zefir,
what do you mean with overlay patches exactly?
~ Jo
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
On 10/17/2016 11:38 AM, Zefir Kurtisi wrote:
> On 10/16/2016 01:04 AM, Jo-Philipp Wich wrote:
>> Hi Karl,
>>
>> let me introduce a not strictly new way but another heavily under
>> documented buildroot feature which you can use to implement custom
>> modifications to packages which do not require s
On 10/16/2016 01:04 AM, Jo-Philipp Wich wrote:
> Hi Karl,
>
> let me introduce a not strictly new way but another heavily under
> documented buildroot feature which you can use to implement custom
> modifications to packages which do not require source code edits.
>
Wow! - this really deserves an
Hi Karl,
let me introduce a not strictly new way but another heavily under
documented buildroot feature which you can use to implement custom
modifications to packages which do not require source code edits.
For every processed package Makefile, the buildroot tries to include a a
Makefile fragmen
David Lang wrote:
>
> I think this is a bad idea, your priority for packages may not
> match someone else's priority, and what happens if someone
> wants something from one package and something else from
> another.
>
> I could see the ability to say "This package is explicitly
> designed to ov
On Tue, 11 Oct 2016, Rafał Miłecki wrote:
On 3 October 2016 at 15:26, Karl Palsson wrote:
What's the "new" way of doing this? In the past, in OpenWrt CC
and before, a package could install files like /etc/banner and
/etc/inittab that were provided by the base-files package. It was
always liste
On 2016-10-11 12:38, Rafał Miłecki wrote:
On 3 October 2016 at 15:26, Karl Palsson wrote:
What's the "new" way of doing this? In the past, in OpenWrt CC
and before, a package could install files like /etc/banner and
/etc/inittab that were provided by the base-files package. It was
always list
On 3 October 2016 at 15:26, Karl Palsson wrote:
> What's the "new" way of doing this? In the past, in OpenWrt CC
> and before, a package could install files like /etc/banner and
> /etc/inittab that were provided by the base-files package. It was
> always listed as "unreliable" as apparently you co
> "Karl" == Karl Palsson writes:
Karl> What's the "new" way of doing this? In the past, in OpenWrt CC and
Karl> before, a package could install files like /etc/banner and
Karl> /etc/inittab that were provided by the base-files package. It was
Karl> always listed as "unreliable" as apparently
On 10/03/2016 11:00 PM, Karl Palsson wrote:
> Alberto Bursi wrote:
>>
>> On 10/03/2016 03:26 PM, Karl Palsson wrote:
>>> What's the "new" way of doing this? In the past, in OpenWrt CC
>>> and before, a package could install files like /etc/banner and
>>> /etc/inittab that were provided by the ba
Alberto Bursi wrote:
>
>
> On 10/03/2016 03:26 PM, Karl Palsson wrote:
> > What's the "new" way of doing this? In the past, in OpenWrt CC
> > and before, a package could install files like /etc/banner and
> > /etc/inittab that were provided by the base-files package. It was
> > always listed as
On 10/03/2016 03:26 PM, Karl Palsson wrote:
> What's the "new" way of doing this? In the past, in OpenWrt CC
> and before, a package could install files like /etc/banner and
> /etc/inittab that were provided by the base-files package. It was
> always listed as "unreliable" as apparently you could
What's the "new" way of doing this? In the past, in OpenWrt CC
and before, a package could install files like /etc/banner and
/etc/inittab that were provided by the base-files package. It was
always listed as "unreliable" as apparently you couldn't rely on
the order. In practice it actually worked
22 matches
Mail list logo
