> p.wassi at gmx.at wrote on Wed Nov 2 01:45:28 PDT 2016:
> I've just gone throgh the changes, and there is definitely more than just
'refreshing' the line numbers/offsets. This is seen at [1]. Have a special
look at [2] at the bottom of this mail, the line containing the caiman target
is compl
p.wassi at gmx.at wrote on Wed Nov 2 03:12:32 PDT 2016:
> What may be my problem here is, that I'm totally stuck to the kernel
changelog, which leads to my question: is it the case, that the patches
getting refreshed here are not directly related to the upstream kernel changes.
Being "stuck to
On 2.11.2016 13:48, p.wa...@gmx.at wrote:
I come to this conclusion: it may happen, that local changes/patches have
effect on other patches in the chain, resulting in a fuzzed applying of these.
That is right. Patches are chained and 'quilt' applies them in order. The
same file can be touched
I like your release approach in general.
I would prefer to have clear branches like "lede-16.11" for all the repos.
Tags will not be sufficient when updates are made to the packages after the
release and people compile new builds. (case for branch arises when a package
has after a release firs
On 19.11.2016 19:42, Jo-Philipp Wich wrote:
> $version = the base version number, e.g. 16.11 - this is what I'd like to
be the main identifier
> $nickname = the symbolic name for a release branch, e.g. "Rolling Rabbit"
- due to its arbitrary nature I do not want it to be part of directories or
Hi Jow,
I tested your patch in my build and it seemd to work ok for the current
master branch. Also LuCI showed version info sensibly.
But you might clarify a bit the config option explanation texts. Especially
VERSION_CODE could be hard to understand If the reader does not know the
intended
On 3.1.2017 0:22, Christian Lamparter wrote:
This patch updates musl to 1.1.16 [0] and removes all the
backported patches.
...
delete mode 100644
toolchain/musl/patches/099-Add-format-attribute-to-some-function-declarations.patch
Like I commened on the Github PR 660 about the same version b
On 3.1.2017 14:22, Jo-Philipp Wich wrote:
Right now there are more or less two approaches proposed:
a) Keep libpolarssl available for the initial 17.01.0 release and drop
it with the first maintenance release 17.01.1 about 6-8 weeks later
b) Drop libpolarssl now, even before branching and u
On 6.1.2017 0:28, Heinrich Schuchardt wrote:
> Hello Hannu,
> why should a variable be called MD5 if it holds an SHA256 hash? That does
not make any sense.
>
> Could you, please, point me to the thread on the openwrt or lede list that
discussed this weird idea.
Not sure if that widely discuss
> With the old 'trac' there was a possibility to get an email for every new
bug. I miss that for 'flyspray'. Maybe I just can not find the button?
Haven't found such a button, either.
But an easy solution is to subscribe / monitor the bugs mailing list.
http://lists.infradead.org/mailman/listin
John Crispin wrote at Fri Feb 10 21:37:19 PST 2017:
> jow posted some instructions on how to overload parts of a packages
install template using one of buildroots built-in features, but i am failing
to find the mail in the archive.
You are likely referring to this:
http://lists.infradead.org/p
On 17.2.2017 12.42, danrl wrote:
We are trying to make passwords on LEDE a tiny bit more secure by refusing weak
or short (read: less than 6 characters) passwords.
Please see related discussion over here, where the inconsistencies were
discovered:
https://github.com/openwrt/luci/pull/878
Not
I noticed this with a mvebu device but the bug may concern all kernel 4.9
users with ubifs, and possibly also jffs2 users, meaning practically all
targets...
Router fails to rename files that are both in /rom and in /overlay, i.e. they
were part of the original flash and have been modified lat
On 9.4.2017 17.14, Jo-Philipp Wich wrote:
I'd like to start preparing the v17.01.1 release during the upcoming
week with the goal to release final binaries during the easter holidays
(~14.04. - 17.04.).
...
Also, please reply with a quick ACK / NACK on whether you'd like to see
an -RC build befor
On 21.4.2017 16.12, Mauro Mozzarelli wrote:
I built trunk r3987 and luci mwan3 is no longer there.
My previous build was r3680 and all was good.
What happened to mwan3?
The mwan3 Luci app was moved to the LuCI repo in March.
https://github.com/openwrt/luci/tree/master/applications/luci-app-m
On 5.5.2016 9:59, David Woodhouse wrote:
It's the Mailman default, but it is deliberately disabled on this list
(as on many other technical lists where the members are expected to be
able to drive their email client properly).
That sounds pretty funny on 2010s when most of us use multiple devic
On 8.5.2016 7:35, John Crispin wrote:
On 06/05/2016 02:16, l...@daniel.thecshore.com wrote:
package/base-files/files/etc/openwrt_release | 7 --
package/base-files/files/etc/openwrt_version | 1 -
these 2 files cannot simply be removed as that would break luci.
we need to eit
a) LEDE r146 build after "make clean"
b) ar71xx/WNDR3700 build. Only the device and htop selected for minimal config
c) htop does not build, it fails in the configure step due to missing libncurses
d) try building htop after make clean
e) nothing
f) LEDE buildbot has not noticed this failure
I no
On 10.5.2016 15:58, Jo-Philipp Wich wrote:
Hi Hannu,
yes, this is caused by one of Felix quickfixes ;)
The buildbot did notice the error, see
http://downloads.lede-project.org/snapshots/faillogs/arm_cortex-a9_neon-vfpv4/packages/htop/compile.txt
Fixes are underway.
Thanks. The fixes made t
On 10/05/16 21:00, Ben Greear wrote:
If someone could add a way to put the git commit ID(s) into
the file system somewhere, I think that would be an excellent
addition.
And once the script is in place, a way to call it through the web UI would
be most welcome.
I use the following script to fet
On 13.5.2016 9:23, Alexandru Ardelean wrote:
Coming back to the patches. Is it a problem with:
1) The UCI C changes ?
2) The dynamic log resize ?
3) The whole thing ?
Depending on what the problem is, we can adapt the patchset.
Or simply drop the whole thing if it's deemed un-needed by the commu
The line with "... Reboot (%C, %R) ..." will fail in real use, as the %C and
%R will be replaced with version strings. Currently there are short strings
"HEAD" and "r222" that fit ok, but try applying "Designated Driver" and
"r45678" and the line will overflow.
The contents of that line should
On 14.5.2016 11:54, John Crispin wrote:
i pushed a tiny patch to fix a regression which i believe was the root
cause for v4.4 not working for most folks. if anyone has time to test
please do so.
Sorry but no beef. I still end up in a reboot loop with my WNDR3800.
I applied your two 4.4. patches
On 14.5.2016 14:03, Felix Fietkau wrote:
On 2016-05-14 12:56, Hannu Nyman wrote:
On 14.5.2016 11:54, John Crispin wrote:
i pushed a tiny patch to fix a regression which i believe was the root
cause for v4.4 not working for most folks. if anyone has time to test
please do so.
Sorry but no beef
On 14.5.2016 21:33, Felix Fietkau wrote:
On 2016-05-14 12:56, Hannu Nyman wrote:
Sorry but no beef. I still end up in a reboot loop with my WNDR3800.
I applied your two 4.4. patches manually to my sources.
As far as I could see from the LEDs, the router reboots before the failsafe
entrance
On 14.5.2016 22:59, Felix Fietkau wrote:
On 2016-05-14 21:32, Hannu Nyman wrote:
However, a negative symptom is that the radios are disabled. I did not apply
your new mac80211 patch, so that might be a reason. "wifi detect" produces no
output.
Please use the commits from my staging
On 15.5.2016 10:42, Hannu Nyman wrote:
I made a build from Felix's commits, but no help. No trace of the radios
with kernel 4.4.
There is some difference in the kernel bootlog regarding the PCI
initialisation. The later part of "PCI: enabling device..." is missing
complete
On 15.5.2016 15:42, John Crispin wrote:
On 15/05/2016 14:39, Hannu Nyman wrote:
The newest fix from Felix seems to have fixed kernel 4.4 for me.
( 102-MIPS-ath79-fix-regression-in-PCI-window-initializati.patch from
82e373bc )
PCI items look normal in the bootlog and the radios work.
do work
On 15.5.2016 15:47, John Crispin wrote:
does USB also work for you ?
USB seems to work ok.
I attached an USB memory stick and it gets recognised normally.
Log items look rather normal to me.
root@lede:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root
I already said to Felix yesterday that I felt that with kernel 4.4 my ar71xx
WNDR3800 seemed somehow more sluggish. Now I tested the matter with "flent".
And sadly, with kernel 4.4 my router's performance decreases significantly.
With kernel 4.1 the router achieves about 20% higher download thr
Please allow users to select to receive lede-dev messages in digests.
The lede-dev mailing list is already rather high volume list and if the
possible PR discussion messages from Github is also piped here, the amount of
messages might be rather high.
Devs have disabled the "digest mode" in th
On 18.5.2016 14:02, Jo-Philipp Wich wrote:
Hi Hannu,
Please allow users to select to receive lede-dev messages in digests.
Done, please let me know whether it is working.
~ Jo
Thanks, it works great. I enabled digest mode and the first digest message
just arrived :-(
And the MIME digest
On 27.5.2016 1:59, Carl-Daniel Hailfinger wrote:
Error message during installation of luci-app-ddns:
Installing luci-app-ddns (2.4.4-1) to root...
Downloading
http://downloads.lede-project.org/snapshots/packages/mips_34kc/luci/luci-app-ddns_2.4.4-1_all.ipk.
Configuring luci-app-ddns.
//usr/lib/o
On 27.5.2016 1:14, Carl-Daniel Hailfinger wrote:
Error message during installation of luci-theme-bootstrap:
[...]
Configuring luci-theme-bootstrap.
//usr/lib/opkg/info/luci-theme-bootstrap.postinst: .: line 130: can't
open './30_luci-theme-bootstrap'
[...]
That sounds like the same error that
On 21.6.2016 11:23, John Crispin wrote:
it would be nice if people could help test the following patch from my
staging tree
https://git.lede-project.org/?p=lede/blogic/staging.git;a=commit;h=75773d43cd44ee70e293343fad11db654c35a4ed
My WNDR3700/3800 firmware gets compiled ok with the patch. The
git.lede-project.org is currently serving a stale Luci version:
https://git.lede-project.org/?p=project/luci.git;a=shortlog
https://github.com/openwrt/luci/commits/master
Git server was apparently down again today (visible in phase1 buildbot) and
in connection to that it has apparently missed th
On 25.10.2016 9:13, p.wa...@gmx.at wrote:
It seems I'm experiencing the same crazy problem. Local builds work
for me (as explained in commit message), but image from buildbot
doesn't boot. This is some totally crazy thing :|
I opt for staying at 4.4 and not reverting, since the issue already occ
I think that I have stumbled upon a possible force-push that has been done on
LEDE git master branch yesterday.
I submitted yesterday two LEDE PRs in Github and got notified today that they
contain extra commits.
https://github.com/lede-project/source/pull/1076#issuecomment-298112905
After in
Jo-Philipp Wich kirjoitti 24.5.2017 klo 23.34:
If you want specific fixes cherry-picked/backported to lede-17.01,
please mention them in a reply to this mail.
I propose three commits related to ath10k-firmware that have been committed
by mkresin on 24 March 2017.
The commits fix the faulty
This patch has been applied as commit f7528ed0a8 and I think that it has
broken dropbear compilation (and naturally also phase1 buildbot)
The files are installed into /bin but that directory has not been created
with INSTALL_DIR first. That was forgotten from the patch...
My own build (after
Thanks.
I compiled kernel 4.9 for my old WNDR3700v2 and WNDR3800. Both routers booted
ok and seem to work ok at the first glance.
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
I upgraded my buildhost to new Ubuntu 17.10 and noticed that Ubuntu has
dropped python 2.7 from the packages installed by default, and only python3
is installed. There is no symlink for "python", so LEDE prerequisite check fails.
LEDE prerequisite check looks for Python2:
https://github.com/le
Hauke Mehrtens wrote on Sat Oct 21 12:26:04 PDT 2017:
> I think your problem is fixed in ec04d122f1182aeb91f39b0e80ae40c68e4d9605
> fix regression in glob with literal . or .. path component
Based on musl mailing list, there will likely be a new musl release rather soon:
Rich Felker wrote in htt
Zoltan HERPAI kirjoitti 24.10.2017 klo 14:46:
Given that we've decided to sail under the same flag for
the benefit of the whole community, and acknowledge the
achievements of the LEDE project, let's start the final
steps of the merge.
The git and other sources are untouched until the infra
Zoltan HERPAI kirjoitti 26.10.2017 klo 18:41:
+ -
+ * 2 oz. Orange Juice Combine all juices in a
+ * 2 oz. Pineapple Juice tall glass filled with
+ * 2 oz. Grapefruit Juice ice, stir well.
+ * 2 oz. Cranberry Juice
+ ---
Lucian Cristian wrote Wed Nov 1 2017
> Mainline - 1.1.18 is available
>
> on the first try, brief test, for dhcp wan, only issuing manual dhcpc
worked, or maybe the tree wasn't clean enough
I tested compiling LEDE with musl 1.1.18 (using the patch here plus the
1.1.18 version bump). And I c
Hauke Mehrtens kirjoitti 21.1.2018 klo 19:53:
This add support for kernel 4.14 to the mvebu target. My main reason to
add kernel 4.14 support is to make it easier to also add support for the
Marvell Armada 3700LP ARM64 SoCs especially the ESPRESSObin board.
I wonder if 4.14 adds support for the
The interesting part is that for ipq806x there has been an extra definition
for Winbond W25N01GV where the pagesize has been finetuned:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ipq806x/patches-4.9/104-mtd-nand-add-Winbond-manufacturer-and-chip.patch;hb=HEAD
That has
New WRT3200ACM routers are unflashable due to a changed flash chip that is
unsupported.
There is a fix proposal from Kaloz, authored on 15th of February, in his
staging repo, but that is still uncommitted to the main sources for some
reason. Announcing the fix:
https://forum.openwrt.org/vie
Custom files work quite normally for me.
Just compiled and flashed r6763-746c590882, and I can see my custom files
quite normally in /etc.
At the first glance I do not see any obvious mistake in your workflow.
Koen Vandeputte kirjoitti 26.4.2018 klo 16:58:
Hi All,
I'm checking this function
I think that the main source tree is in pretty good shape, so branching off
the 18.0X rather soon might make sense.
There is alweays the next new exiting feature to be included in, but if the
intention is still to make several major releases per year, the next feature
will get into the next re
51 matches
Mail list logo
