Or at least let us know how to apply the patch manually and I will add
it into my unofficial builds that I make with the ar71xx platform.
I'd love to see proper or even some sort of wwan support in the luci
side of things.
On 21/05/15 15:41, Cezary Jackiewicz wrote:
Dnia 2015-04-22, o godz
Hi all,
I was wondering why OpenWRT switched to musl -- is it purely because
uclibc hasn't actually maintained their code properly?
One of the things I have noticed since the CC trunk builds I did with
kernel 3.18.11 + uclibc is that the image sizes have ballooned out by a
fair bit.
For ex
Cheers
On 27/08/15 19:33, Felix Fietkau wrote:
On 2015-08-27 01:48, Adam Kuklycz wrote:
Hi all,
I was wondering why OpenWRT switched to musl -- is it purely because
uclibc hasn't actually maintained their code properly?
That's only part of the reason. Aside from the maintainen
B as
well, but it looks like using musl adds around 300KB too.
Have the devs determined that perhaps the increased performance of using
musl outweighs the hit on image sizes?
Cheers
Adam
On 27/08/15 22:17, Adam Kuklycz wrote:
Hi Felix
Thanks for clarifying. I've also noticed what
bigger in size. Regardless, I'm going to need to reduce features for
routers with 8MB of flash, as kernel bloat also adds around another 300KB.
On 28/08/15 09:11, Felix Fietkau wrote:
On 2015-08-28 01:03, Adam Kuklycz wrote:
Just following up on the suspected memory leak, and image build
T_INTERNAL=y
# CONFIG_UCLIBC_USE_VERSION_0_9_33 is not set
adamk@Precision-M4500:~/ChaosCalmer-r46734$
On 28/08/15 16:27, Felix Fietkau wrote:
On 2015-08-28 01:34, Adam Kuklycz wrote:
Fair enough.
MUSL:
-rw-r--r-- 1 adamk adamk 6700676 Aug 27 23:15 root.squashfs
UCLIBC:
-rw-r--r-- 1 a
Hi there,
I didn't see this fix come into the main CC trunk?
The package does generate these annoying messages in the syslog whenever
a user is on the overview page on the router:
Sat Aug 29 11:45:26 2015 daemon.err uhttpd[2507]: uci: Entry not found
Sat Aug 29 11:45:31 2015 daemon.err uhttpd
Hi there,
Yes I tried @wan to no avail, reverting back to an earlier build saw my
IPv6 connectivity restored.
I am trying a commit from Friday just gone, just before some commits
were put up fixing some issues that corrected routing. Bit of a long
shot as it's only IPv6 affected but never k
Built revision 48634, same deal. Will try building 48272 in the morning
and advise.
On 09/02/16 23:48, Adam Kuklycz wrote:
Hi there,
Yes I tried @wan to no avail, reverting back to an earlier build saw
my IPv6 connectivity restored.
I am trying a commit from Friday just gone, just before
00:55, John Crispin wrote:
Hi Adam,
please do not hijack threads. if you want to send us a mail then dont
click Reply on an un-related thread and then change the subject. this
will mess up patchwork, which did notice what you did ;)
--> https://patchwork.ozlabs.org/patch/580275/
John
On
trying to narrow down what is causing IPv6 to
not work.
A build I did on Oct 25, 2015 for revision 47245 works fine with IPv6.
Note that I am using Ubuntu 14.04.3 x64 to compile.
Any help appreciated
TIA
Adam
On 10/02/16 12:05, Adam Kuklycz wrote:
Hi all,
I've noticed with
commits somewhere and so that is also now working fine.
Boils down to firewall rules.
Heh. A few less hairs on my head.
On 10/02/16 16:27, Adam Kuklycz wrote:
Further to this, I have compiled trunk versions 47750 and 47458 which
both exhibit the same IPv6 non-routing issue, however with 47458
One thing I have observed is that some developers are on the TRAC system and
actively looking at tickets, while others are purely on the mailing list and
do not regularly (or at all) look at the TRAC system.
This can cause confusion and frustration for some who are wanting to report
a bug, and rep
I’m seeing the same thing:
Checking out files from the git repository...
Cloning into 'mtd-utils-1.4.5'...
fatal: unable to connect to git.infradead.org:
git.infradead.org: Name or service not known
It was also down a few days ago for quite a while; it would be nice if there
was a ba
Thanks Bastian, this has worked for me as well :)
Adam
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
Behalf Of Bastian Bittorf
Sent: Friday, 24 October 2014 7:12 PM
To: Claudio Thomas
Cc: OpenWrt Development List
Subject: Re: [OpenWrt-Devel] g
Hi all
I asked in the forums but nobody has replied so asking on here as well.
I'm running a Sierra 320U which supports 3G & LTE/4G.
Have compiled in the directip options as well as QMI etc so I now see
the wwan0 interface and there are some generic directip scripts in /etc/gcom
What is the
I think what everyone needs to just think and remember for a minute:
* OpenWRT is built by the community and not by highly paid engineers
* OpenWRT is often far more feature rich than stock firmwares written for
the devices supported
* OpenWRT is even used sometimes by hardware vendors as a bas
Guys if you need a guinea pig for testing the WNDR4300's I am happy to assist.
Since introducing the sysupgrade features, upon a router reboot all settings
are restored to factory defaults.
Also, is this mail list a channel that reaches most or all developers?
__
Geez, it must be true that you should only sleep when you're dead...damn Aussie
time zones...
I'll test with latest trunk as well & will confirm. But looks promising!
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf
Of Paul Blazejowski
y say.
glad we made much progress today!
thank you all!
On Wed, 2014-06-25 at 00:07 +, Adam Kuklycz wrote:
Geez, it must be true that you should only sleep when you're dead...damn Aussie
time zones...
I'll test with latest trunk as well & will confirm. But looks promising!
20 matches
Mail list logo
