Re: [OpenWrt-Devel] [PATCH] Add Support for WeIO Board (Chaos Calmer)
Hi John, On Mon, Jun 15, 2015 at 8:56 AM, John Crispin wrote: > > > On 14/06/2015 23:56, Drasko DRASKOVIC wrote: >> +/** >> + * WEIO Web Of Things Platform >> + * >> + * Copyright (C) 2013 Drasko DRASKOVIC and Uros PETREVSKI >> + * >> + * ## ## ### >> + * ## ## ## #### ## ## >> + * ## ## ## #### ## ## >> + * ## ## ## #### ## ## >> + * ## ## ## #### ## ## >> + * ## ## ## #### ## ## >> + * ### ### ### >> + * >> + * Web Of Things Platform >> + * >> + * Authors : >> + * Drasko DRASKOVIC >> + * Uros PETREVSKI >> + */ >> + > > we expect submitted kernel patches to have a gplv2 license This is a copyright info, not a licensing information - license is GPLv2. There is many files in OpenWrt that do not have a license info in the headers. Do you want me to change the patch and add licensing information also? BR, Drasko ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] base-files: add /etc/profile.d support
* Hendrik [15.06.2015 09:02]: > i just wanted to ask for your oppinions on the second verison of my > patch. why didnt you pay attention for all the suggestions? bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] x86/xen_domu: enable image generation
Add features ext4 targz to target x86/xen_domu in order to generate images in defconfig. This fixes #18074. Signed-off-by: Luiz Angelo Daros de Luca --- target/linux/x86/xen_domu/target.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/x86/xen_domu/target.mk b/target/linux/x86/xen_domu/target.mk index 80bac3b..f7a69bf 100644 --- a/target/linux/x86/xen_domu/target.mk +++ b/target/linux/x86/xen_domu/target.mk @@ -1,3 +1,3 @@ BOARDNAME:=Xen Paravirt Guest DEFAULT_PACKAGES += kmod-xen-fs kmod-xen-evtchn kmod-xen-netdev kmod-xen-kbddev -FEATURES:=display +FEATURES:=display ext4 targz -- 2.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/5] elfutils: import package from packages.git
OK, Sent the PR in order to remove it. I already have a update patch that I'll send to list. However, I guess that perf pkg maintainer (or other) should be the one to keep the maintenance as I have no current uses for elfutils and probably I'll not give the love it desires. --- Luiz Angelo Daros de Luca, Me. luizl...@gmail.com 2015-06-14 14:22 GMT-03:00 Felix Fietkau : > On 2015-05-19 03:43, Luiz Angelo Daros de Luca wrote: > > I'm curious, as current elfutils packager, how I should play in this > import? > > > > Should this package be removed from package.git (but there is no PR for > it)? > > > > Or will it be periodically synchronized with packages.git? > > > > Also, as I'm not a core developer, maybe it would be better to a core > > developer to take its maintainance. > I will apply this package. When you have updates to it, please send them > as patches to this list. The package should be removed from github > afterwards. > > - Felix > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] elfutils: bump to 0.162
Besides source.tgz, 001-elfutils-portability.patch (provided by upstream project) where updated. Other patches where updated to fix hulk warnings and minor conflicts. Signed-off-by: Luiz Angelo Daros de Luca --- package/libs/elfutils/Makefile |4 +- .../patches/001-elfutils-portability.patch | 1005 .../elfutils/patches/002-argp_standalone.patch |6 +- .../libs/elfutils/patches/003-libint-stub.patch| 20 +- .../elfutils/patches/004-maybe-uninitialized.patch |6 +- .../elfutils/patches/005-build_only_libs.patch | 12 +- package/libs/elfutils/patches/006-libdw_LIBS.patch | 10 +- .../libs/elfutils/patches/100-musl-compat.patch| 10 +- package/libs/elfutils/patches/101-no-fts.patch |8 +- 9 files changed, 634 insertions(+), 447 deletions(-) diff --git a/package/libs/elfutils/Makefile b/package/libs/elfutils/Makefile index d3e1552..d13e15d 100644 --- a/package/libs/elfutils/Makefile +++ b/package/libs/elfutils/Makefile @@ -7,12 +7,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=elfutils -PKG_VERSION:=0.161 +PKG_VERSION:=0.162 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 PKG_SOURCE_URL:=http://fedorahosted.org/releases/e/l/$(PKG_NAME)/$(PKG_VERSION) -PKG_MD5SUM:=e1b9847c9a6a1ad340de8d47a863ec52 +PKG_MD5SUM:=9334cbcc0df7669b7bf07cf7fc3ad52c PKG_MAINTAINER:=Luiz Angelo Daros de Luca PKG_LICENSE:=GPL-3.0+ PKG_LICENSE_FILES:=COPYING COPYING-GPLV2 COPYING-LGPLV3 diff --git a/package/libs/elfutils/patches/001-elfutils-portability.patch b/package/libs/elfutils/patches/001-elfutils-portability.patch index 7539f8b..068235a 100644 --- a/package/libs/elfutils/patches/001-elfutils-portability.patch +++ b/package/libs/elfutils/patches/001-elfutils-portability.patch @@ -1,6 +1,6 @@ elfutils/backends/ChangeLog -+++ elfutils/backends/ChangeLog -@@ -433,6 +433,10 @@ +--- a/backends/ChangeLog b/backends/ChangeLog +@@ -498,6 +498,10 @@ * ppc_attrs.c (ppc_check_object_attribute): Handle tag GNU_Power_ABI_Struct_Return. @@ -11,7 +11,7 @@ 2008-10-04 Ulrich Drepper * i386_reloc.def: Fix entries for TLS_GOTDESC, TLS_DESC_CALL, and -@@ -760,6 +764,11 @@ +@@ -825,6 +829,11 @@ * sparc_init.c: Likewise. * x86_64_init.c: Likewise. @@ -23,7 +23,7 @@ 2005-11-19 Roland McGrath * ppc64_reloc.def: REL30 -> ADDR30. -@@ -782,6 +791,9 @@ +@@ -847,6 +856,9 @@ * Makefile.am (uninstall): Don't try to remove $(pkgincludedir). (CLEANFILES): Add libebl_$(m).so. @@ -33,8 +33,8 @@ * ppc_reloc.def: Update bits per Alan Modra . * ppc64_reloc.def: Likewise. elfutils/backends/Makefile.am -+++ elfutils/backends/Makefile.am +--- a/backends/Makefile.am b/backends/Makefile.am @@ -119,7 +119,7 @@ libebl_%.so libebl_%.map: libebl_%_pic.a $(LINK) -shared -o $(@:.map=.so) \ -Wl,--whole-archive $< $(cpu_$*) -Wl,--no-whole-archive \ @@ -44,17 +44,19 @@ @$(textrel_check) libebl_i386.so: $(cpu_i386) elfutils/backends/Makefile.in -+++ elfutils/backends/Makefile.in -@@ -83,6 +83,7 @@ host_triplet = @host@ +--- a/backends/Makefile.in b/backends/Makefile.in +@@ -83,7 +83,8 @@ host_triplet = @host@ DIST_COMMON = $(top_srcdir)/config/eu.am $(srcdir)/Makefile.in \ $(srcdir)/Makefile.am $(top_srcdir)/config/depcomp \ $(noinst_HEADERS) ChangeLog +-@SYMBOL_VERSIONING_TRUE@am__append_1 = -DSYMBOL_VERSIONING +@BUILD_WERROR_TRUE@am__append_1 = $(if $($(*F)_no_Werror),,-Werror) ++@SYMBOL_VERSIONING_TRUE@am__append_2 = -DSYMBOL_VERSIONING subdir = backends ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 am__aclocal_m4_deps = $(top_srcdir)/m4/biarch.m4 \ -@@ -285,6 +286,7 @@ INSTALL_PROGRAM = @INSTALL_PROGRAM@ +@@ -289,6 +290,7 @@ INSTALL_PROGRAM = @INSTALL_PROGRAM@ INSTALL_SCRIPT = @INSTALL_SCRIPT@ INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@ LDFLAGS = @LDFLAGS@ @@ -62,7 +64,7 @@ LEX = @LEX@ LEXLIB = @LEXLIB@ LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@ -@@ -316,6 +318,7 @@ SHELL = @SHELL@ +@@ -320,6 +322,7 @@ SHELL = @SHELL@ STRIP = @STRIP@ USE_NLS = @USE_NLS@ VERSION = @VERSION@ @@ -70,24 +72,29 @@ XGETTEXT = @XGETTEXT@ XGETTEXT_015 = @XGETTEXT_015@ XGETTEXT_EXTRA_OPTIONS = @XGETTEXT_EXTRA_OPTIONS@ -@@ -378,11 +381,11 @@ zip_LIBS = @zip_LIBS@ - AM_CPPFLAGS = -I. -I$(srcdir) -I$(top_srcdir)/lib -I.. \ - -I$(top_srcdir)/libebl -I$(top_srcdir)/libasm \ - -I$(top_srcdir)/libelf -I$(top_srcdir)/libdw +@@ -387,14 +390,14 @@ AM_CPPFLAGS = -I. -I$(srcdir) -I$(top_sr + + # Warn about stack usage of more than 256K = 262144 bytes. + @ADD_STACK_USAGE_WARNING_TRUE@STACK_USAGE_WARNING = -Wstack-usage=262144 -AM_CFLAGS = -std=gnu99 -Wall -Wshadow -Wformat=2 \ - $(if $($(*F)_no_Werror),,-Werror) \ - $(if $($(*F)_no_Wunused),,-Wunused -Wextra) \ +- $(if $($(*F)_no_Wstack_usage),,$(STACK_USAGE_WARNING)) \ - $($(*F)_CFLAGS)
Re: [OpenWrt-Devel] [PATCH v2] base-files: add /etc/profile.d support
Am 2015-06-15 09:17, schrieb Bastian Bittorf: * Hendrik [15.06.2015 09:02]: i just wanted to ask for your oppinions on the second verison of my patch. why didnt you pay attention for all the suggestions? bye, bastian After the discussion on the list this was what I thought was the state of the discussion: - don't run /etc/profile.d/* in failsafe ( i added this) - only execute shell-scripts (added this also) What else is there i forgot? regards, Hendrik ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] reproducible OpenWrt?
Hi H01gi, just for the record here are some of the links that are relevant... http://anonscm.debian.org/cgit/reproducible/dpkg.git/commit/?h=pu/reproducible_builds&id=3373ffd07e016ae1a81d12cb246fc6787f0bdbe1 http://anonscm.debian.org/cgit/reproducible/dpkg.git/commit/?h=pu/reproducible_builds&id=3b8c480943929bbeabcbbc46831c356170a1ca98 http://anonscm.debian.org/cgit/reproducible/dpkg.git/commit/?h=pu/reproducible_builds&id=d84881f3f4faa57a2d61ba40bcdc7c2d7537fdf8 http://anonscm.debian.org/cgit/reproducible/dpkg.git/commit/?h=pu/reproducible_builds&id=a09849333b2ca211a1fa2ed02674c6af7b49c112 John On 14/06/2015 23:53, Holger Levsen wrote: > Dear OpenWrt developers, > > to quote https://reproducible.debian.net/openwrt/ ;-) > > Reproducible builds enable anyone to reproduce bit by bit identical binary > packages from a given source, so that anyone can verify that a given binary > derived from the source it was said to be derived. There is a lot more > information about reproducible builds on the Debian wiki at > https://wiki.debian.org/ReproducibleBuilds and on > https://reproducible.debian.net - The wiki has a lot more information, eg. > why > this is useful, what common issues exist and which workarounds and solutions > are known. > > Reproducible OpenWrt is an effort to apply this to OpenWrt Thus each OpenWR > target is build twice, with a few varitations added and then the resulting > images and packages from the two builds are compared using debbindiff, which > currently cannot detect .bin files as squashfs filesystems. Thus the > resulting > debbindiff output is not nearly as clear as it could be - hopefully this > limitation will be overcome soon. Also please note that the toolchain is not > varied at all as the rebuild happens on exactly the same system. More > variations are expected to be seen in the wild. > > There is a monthly run jenkins job to test the master branch of openwrt.git. > Currently this job is triggered more often though, because this is still > under > development and brand new. The jenkins job is simply running > reproducible_openwrt.sh in a Debian environment and this script is solely > responsible for creating this page. Feel invited to join #debian-reproducible > (on irc.oftc.net) to request job runs whenever sensible. Patches and other > feedback are very much appreciated! > > ---end-quote-- > > And that's basically it. Go have a look at the above URLS and you might also > be interested to know that https://reproducible.debian.net/coreboot shows > 100% > success for coreboot _atm_ (there are more variations in the wild and not all > payloads tested) and Debian sid is currently at 82% reproducibility. > > I've only looked at very few .ipk packages linked in openwrt.html but all > I've > looked at only need a simple modification when creating the inside tarballs > to > set that these creation dates to the time+date of the last modification of > the > source code... > > Support to better analyze .bin squashfs files with debbindiff will be added > eventually, also we will build more openwrt targets soon too. > > And then we might actually do full release rebuilds too and see if we can > reproduce your released files bit by bit one day ;-) > > > Last and definitly not least: thanks a lot for OpenWrt - I happily use it > daily! :) > > cheers, > Holger > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Update dnsmasq to v2.73.
Thanks, applied to trunk and CC. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] jffs2 CRC failed (many times after reboot) - Ralink MT7628
Hello, The first boot, after flashing a new image, runs fine. I edit my /etc/config/network configuration then reboot and I get those errors (every reboot): [8.13] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x0046000c: Read 0x, calculated 0x4900568b ... ... (many times) ... [ 15.41] jffs2: notice: (306) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. The flash driver seems to not work correctly after reboot. Any ideas? Baptiste ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
On 2015-06-15 10:20, Miklos Szeredi wrote: > On Thu, Jun 11, 2015 at 2:01 PM, Miklos Szeredi wrote: >> On 7 May 2015 at 15:49, Felix Fietkau wrote: >>> On 2015-05-07 08:01, Wojciech Dubowik wrote: Try to boot with kernel locking enabled. I have seen jffs2 deadlocks on readdir. As far as I remember with this patch it went through but I don't know anymore whether I have changed sth in config. Have a look at (search engine...) [PATCH] fs: jffs2: Add setup code for spi nor flash. Even with this patch I got some possible dead lock warnings so it might be just a partial cure. BTW it's a bit scary for future use. Looks like jffs2 doesn't get enough care... >>> I believe the locking issues are an overlayfs regression, maybe even >>> the same one as this one (which I fixed years ago): >>> http://linux-fsdevel.vger.kernel.narkive.com/XRtXLDlf/patch-1-2-overlayfs-fix-a-deadlock-in-ovl-dir-read-merged >>> >>> I believe this is the cause of the regression: >>> >>> commit 49c21e1cacd74a8c83407c70ad860c994e606e25 >>> Author: Miklos Szeredi >>> Date: Sat Dec 13 00:59:42 2014 +0100 >>> >> >> I'm working on 4.0 support for ar71xx and found that >> /etc/rc.d/S00sysfixtime is not able to finish it's job after second >> boot after flashing (t.i. after overlayfs is switched to jffs). I've >> run strace and found that find hangs on the very last getdents64 call >> (before calling it succesfully many times on previous >> files/directories). >> I've reverted every change up to >> 49c21e1cacd74a8c83407c70ad860c994e606e25 to overlayfs and it started >> working. Applying 49c21e1cacd74a8c83407c70ad860c994e606e25 back breaks >> it. So this commit is indeed the cause of regression. >> >> Miklos, any ideas how to fix it in current tree? I'm using 4.0.5 now >> but AFAIK there were no more changes to overlayfs. > > What's the full mount setup? (cat /proc/mounts) /dev/root /rom squashfs ro,relatime 0 0 proc /proc proc rw,noatime 0 0 sysfs /sys sysfs rw,noatime 0 0 tmpfs /tmp tmpfs rw,nosuid,nodev,noatime 0 0 /dev/mtdblock8 /overlay jffs2 rw,noatime 0 0 overlayfs:/overlay / overlay rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work 0 0 tmpfs /dev tmpfs rw,relatime,size=512k,mode=755 0 0 devpts /dev/pts devpts rw,relatime,mode=600 0 0 debugfs /sys/kernel/debug debugfs rw,noatime 0 0 - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] reproducible OpenWrt?
Hi, On Montag, 15. Juni 2015, John Crispin wrote: > just for the record here are some of the links that are relevant... > > http://anonscm.debian.org/cgit/reproducible/dpkg.git/commit/?h=pu/reproduci > ble_builds&id=3373ffd07e016ae1a81d12cb246fc6787f0bdbe1 > http://anonscm.debian.org/cgit/reproducible/dpkg.git/commit/?h=pu/reproduc > ible_builds&id=3b8c480943929bbeabcbbc46831c356170a1ca98 > http://anonscm.debian.org/cgit/reproducible/dpkg.git/commit/?h=pu/reproduc > ible_builds&id=d84881f3f4faa57a2d61ba40bcdc7c2d7537fdf8 > http://anonscm.debian.org/cgit/reproducible/dpkg.git/commit/?h=pu/reproduc > ible_builds&id=a09849333b2ca211a1fa2ed02674c6af7b49c112 I showed these patches to John to explain how we taught dpkg to create reproducible metadata - which is what is unreproducible in eg. https://reproducible.debian.net/openwrt/dbd/ar71xx/base/dropbear_2015.67-1_ar71xx.ipk.html So something similar needs to be done for ipkg. Btw, does anyone know whom to attribute the OpenWrt artwork too? I'd like to mention it's copyright correctly in the footer of https://reproducible.debian.net/openwrt/ (like it is done for /coreboot/) cheers, Holger signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] reproducible OpenWrt?
On 15/06/2015 10:50, Holger Levsen wrote: > Hi, > > On Montag, 15. Juni 2015, John Crispin wrote: >> just for the record here are some of the links that are relevant... >> >> http://anonscm.debian.org/cgit/reproducible/dpkg.git/commit/?h=pu/reproduci >> ble_builds&id=3373ffd07e016ae1a81d12cb246fc6787f0bdbe1 >> http://anonscm.debian.org/cgit/reproducible/dpkg.git/commit/?h=pu/reproduc >> ible_builds&id=3b8c480943929bbeabcbbc46831c356170a1ca98 >> http://anonscm.debian.org/cgit/reproducible/dpkg.git/commit/?h=pu/reproduc >> ible_builds&id=d84881f3f4faa57a2d61ba40bcdc7c2d7537fdf8 >> http://anonscm.debian.org/cgit/reproducible/dpkg.git/commit/?h=pu/reproduc >> ible_builds&id=a09849333b2ca211a1fa2ed02674c6af7b49c112 > > I showed these patches to John to explain how we taught dpkg to create > reproducible metadata - which is what is unreproducible in eg. > https://reproducible.debian.net/openwrt/dbd/ar71xx/base/dropbear_2015.67-1_ar71xx.ipk.html > > So something similar needs to be done for ipkg. > agreed. i am in the middle of the last steps of the CC release. once that is done i will have a look at this todo. thanks for the hints. John > > Btw, does anyone know whom to attribute the OpenWrt artwork too? I'd like to > mention it's copyright correctly in the footer of > https://reproducible.debian.net/openwrt/ (like it is done for /coreboot/) > > > cheers, > Holger > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add Support for WeIO Board (Chaos Calmer)
Hi Karl, On Mon, Jun 15, 2015 at 11:48 AM, Karl Palsson wrote: > > A lot of this messes up the alphabetical ordering. Can you point me to exact spots? I tried to add WeIO support next to Carambola2, as in many cases it is practically the same. I might be that I did not notice alphabetical ordering in some files, so please point me to the right places. BR, Drasko ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add Support for WeIO Board (Chaos Calmer)
Drasko DRASKOVIC wrote: > Hi Karl, > > On Mon, Jun 15, 2015 at 11:48 AM, Karl Palsson > wrote: > > > > A lot of this messes up the alphabetical ordering. > > Can you point me to exact spots? > > I tried to add WeIO support next to Carambola2, as in many cases it is > practically the same. I might be that I did not notice alphabetical > ordering in some files, so please point me to the right places. > All of them. I don't believe it's particularly relevant that it's based on a carambola2 module, it's soldered down, it's for all intents and purposes just another ar9331. Until/Unless ar71xx moves to device tree, then by all means it could include a dtsi for the carambola2 module but when they have separate board files, it's not relevant. target/linux/ar71xx/base-files/lib/upgrade/platform.sh changes are probably ok, that's already a bit of a mess? Further, if WeIO doens't use eht0, I think it should just be removed, not #ifdeffed out. Cheers, Karl P___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Package list signing keys: Does the release build system use different keys than snapshots?
I created my first build from the brand-new CC15.05 chaos_calmer branch. I patched include/version.mk to get the version right, but no other changes were needed. The build is otherwise ok, but opkg does not accept package list signatures from the 15.05-rc2 directory. When I try opkg update, I get this: >> Downloading http://downloads.openwrt.org/chaos_calmer/15.05-rc2/ar71xx/generic/packages/base/Packages.gz. >> Updated list of available packages in /var/opkg-lists/chaos_calmer_base. >> Downloading http://downloads.openwrt.org/chaos_calmer/15.05-rc2/ar71xx/generic/packages/base/Packages.sig. >> Signature check failed. >> Remove wrong Signature file. Have the rc2 binaries been created with a different key than the snapshots? r45905 added the snapshot key to the base-files, which enables private builds to fetch snapshot package lists from the snapshots. https://dev.openwrt.org/changeset/45905/ Probably something similar needs to be done for the release build keys. Right? I propose that developers add the release build signing keys to base-files, at least in the chaos_calmer branch, but probably also into trunk so that the next branches will avoid the problem. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
On 15 June 2015 at 15:52, Miklos Szeredi wrote:
> On Mon, Jun 15, 2015 at 10:24:28AM +0200, Felix Fietkau wrote:
>> On 2015-06-15 10:20, Miklos Szeredi wrote:
>> > On Thu, Jun 11, 2015 at 2:01 PM, Miklos Szeredi wrote:
>> >> On 7 May 2015 at 15:49, Felix Fietkau wrote:
>> >>> On 2015-05-07 08:01, Wojciech Dubowik wrote:
>> Try to boot with kernel locking enabled. I have seen jffs2 deadlocks on
>> readdir. As far as I remember
>> with this patch it went through but I don't know anymore whether I have
>> changed sth in config.
>>
>> Have a look at (search engine...) [PATCH] fs: jffs2: Add setup code for
>> spi nor flash.
>>
>> Even with this patch I got some possible dead lock warnings so it might
>> be just a partial cure. BTW it's
>> a bit scary for future use. Looks like jffs2 doesn't get enough care...
>> >>> I believe the locking issues are an overlayfs regression, maybe even
>> >>> the same one as this one (which I fixed years ago):
>> >>> http://linux-fsdevel.vger.kernel.narkive.com/XRtXLDlf/patch-1-2-overlayfs-fix-a-deadlock-in-ovl-dir-read-merged
>> >>>
>> >>> I believe this is the cause of the regression:
>> >>>
>> >>> commit 49c21e1cacd74a8c83407c70ad860c994e606e25
>> >>> Author: Miklos Szeredi
>> >>> Date: Sat Dec 13 00:59:42 2014 +0100
>> >>>
>> >>
>> >> I'm working on 4.0 support for ar71xx and found that
>> >> /etc/rc.d/S00sysfixtime is not able to finish it's job after second
>> >> boot after flashing (t.i. after overlayfs is switched to jffs). I've
>> >> run strace and found that find hangs on the very last getdents64 call
>> >> (before calling it succesfully many times on previous
>> >> files/directories).
>> >> I've reverted every change up to
>> >> 49c21e1cacd74a8c83407c70ad860c994e606e25 to overlayfs and it started
>> >> working. Applying 49c21e1cacd74a8c83407c70ad860c994e606e25 back breaks
>> >> it. So this commit is indeed the cause of regression.
>> >>
>> >> Miklos, any ideas how to fix it in current tree? I'm using 4.0.5 now
>> >> but AFAIK there were no more changes to overlayfs.
>> >
>> > What's the full mount setup? (cat /proc/mounts)
>> /dev/root /rom squashfs ro,relatime 0 0
>> proc /proc proc rw,noatime 0 0
>> sysfs /sys sysfs rw,noatime 0 0
>> tmpfs /tmp tmpfs rw,nosuid,nodev,noatime 0 0
>> /dev/mtdblock8 /overlay jffs2 rw,noatime 0 0
>> overlayfs:/overlay / overlay
>> rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work 0 0
>> tmpfs /dev tmpfs rw,relatime,size=512k,mode=755 0 0
>> devpts /dev/pts devpts rw,relatime,mode=600 0 0
>> debugfs /sys/kernel/debug debugfs rw,noatime 0 0
>>
>> - Felix
>
>
> Following patch should fix the locking issue.
>
> Please test.
>
It worked! Thanks Miklos!
Felix, attaching tested and ready to commit patch.
Or do you want me to send it separately to the list?
Regards,
Roman
--- a/fs/overlayfs/readdir.c
+++ b/fs/overlayfs/readdir.c
@@ -23,6 +23,7 @@ struct ovl_cache_entry {
u64 ino;
struct list_head l_node;
struct rb_node node;
+ struct ovl_cache_entry *next_maybe_whiteout;
bool is_whiteout;
char name[];
};
@@ -39,7 +40,7 @@ struct ovl_readdir_data {
struct rb_root root;
struct list_head *list;
struct list_head middle;
- struct dentry *dir;
+ struct ovl_cache_entry *first_maybe_whiteout;
int count;
int err;
};
@@ -79,7 +80,7 @@ static struct ovl_cache_entry *ovl_cache
return NULL;
}
-static struct ovl_cache_entry *ovl_cache_entry_new(struct dentry *dir,
+static struct ovl_cache_entry *ovl_cache_entry_new(struct ovl_readdir_data *rdd,
const char *name, int len,
u64 ino, unsigned int d_type)
{
@@ -98,29 +99,8 @@ static struct ovl_cache_entry *ovl_cache
p->is_whiteout = false;
if (d_type == DT_CHR) {
- struct dentry *dentry;
- const struct cred *old_cred;
- struct cred *override_cred;
-
- override_cred = prepare_creds();
- if (!override_cred) {
- kfree(p);
- return NULL;
- }
-
- /*
- * CAP_DAC_OVERRIDE for lookup
- */
- cap_raise(override_cred->cap_effective, CAP_DAC_OVERRIDE);
- old_cred = override_creds(override_cred);
-
- dentry = lookup_one_len(name, dir, len);
- if (!IS_ERR(dentry)) {
- p->is_whiteout = ovl_is_whiteout(dentry);
- dput(dentry);
- }
- revert_creds(old_cred);
- put_cred(override_cred);
+ p->next_maybe_whiteout = rdd->first_maybe_whiteout;
+ rdd->first_maybe_whiteout = p;
}
return p;
}
@@ -148,7 +128,7 @@ static int ovl_cache_entry_add_rb(struct
return 0;
}
- p = ovl_cache_entry_new(rdd->dir, name, len, ino, d_type);
+ p = ovl_cache_entry_new(rdd, name, len, ino, d_type);
if (p == NULL)
return -ENOMEM;
@@ -169,7 +149,7 @@ static int ovl_fill_lower(struct ovl_rea
if (p) {
list_move_tail(&p->l_node, &rdd->middle);
} else {
- p = ovl_cache_entry_new(rdd->dir, name, namelen, ino, d_type);
+ p = ovl_cache_entry_new(rdd, name, namelen, ino, d_type);
if (p == NULL)
rdd->err = -ENOMEM;
else
@@ -219,6 +199,43 @@ static int ovl_fill_merge(struc
Re: [OpenWrt-Devel] procd/libubox mangles command-line arguments
This gets more curious... You are certainly correct that the strings passed to
procd are marshaled correctly. It turns out that the shells I have tried to pass
the numeric-colon-separated list as an option value gets the list split apart as
I noted earlier. Barring any quick solution to this issue I may develop a patch
to the application source to accept a different delimiter. Go figure
Thanks,/ted
-Original Message-
From: Yousong Zhou
Sent: Sunday, June 14, 2015 10:10 PM
To: Ted Hess
Cc: OpenWrt developers
Subject: Re: [OpenWrt-Devel] procd/libubox mangles command-line arguments
Hi, Ted,
On 15 June 2015 at 04:57, Ted Hess wrote:
Somewhere in the processing of "procd_set_param command ..." certain
command-line parameters which have colons (":") get treated as argument
delimiters. Example:
procd_set_param command "foo -a 200:4:16:0 -o hw:0,0"
The correct usage should be something like the following.
procd_set_param command "foo" "-a" "200:4:16:0" "-o" "hw:0,0"
gets the command-line string "-a 200 4 16 0 -o hw:0,0" actually passed to
the program. This is not what I wanted. Is there special handling for colon
delimited numbers?? The 2nd parameter does not get this treatment - why?
AFAIK, procd will not try any shell-like command line parsing. I
tried the following script
. /lib/functions/procd.sh
service_triggers() { true; }
procd_open_service foo foo
procd_open_instance bar
procd_set_param command 'baz -a 200:4:16:0 -o hw:0,0'
procd_close_instance
procd_close_service
ubus call service list | jsonfilter -e '$["foo"]'
And the result seems expected.
root@OpenWrt:/# ubus call service list | jsonfilter -e '$["foo"]'
{ "instances": { "bar": { "running": false, "command": [ "baz -a
200:4:16:0 -o hw:0,0" ] } } }
yousong
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ar71xx: add 4.0 support
On 14 June 2015 at 20:15, Roman Yeryomin wrote: > Tested on UAP-PRO > Please discard this, it's broken because of 45954. I will send rebased version. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/5] ar71xx/image: move ubnt images to new BuildCode
On 7 June 2015 at 15:27, Alexander Couzens wrote: > Signed-off-by: Alexander Couzens > --- > target/linux/ar71xx/image/Makefile | 264 > - > 1 file changed, 175 insertions(+), 89 deletions(-) > At least UAP-PRO image is broken after this (applied in 45983): MIPS: machine is Generic AR71XX/AR724X/AR913X based board Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ar71xx: add 4.0 support
On Mon, Jun 15, 2015 at 06:15:58PM +0300, Roman Yeryomin wrote: > On 14 June 2015 at 20:15, Roman Yeryomin wrote: > > Tested on UAP-PRO > > > > Please discard this, it's broken because of 45954. > I will send rebased version. Yes, I saw that and manually fixed it to test on TL-WDR3500. Apart from the breakage introduced by r45954 (which was trivial to fix) everything seems to work well. Thanks for the good work! Cheers Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ar71xx: add 4.0 support
On 15 June 2015 at 19:09, Daniel Golle wrote: > On Mon, Jun 15, 2015 at 06:15:58PM +0300, Roman Yeryomin wrote: >> On 14 June 2015 at 20:15, Roman Yeryomin wrote: >> > Tested on UAP-PRO >> > >> >> Please discard this, it's broken because of 45954. >> I will send rebased version. > > Yes, I saw that and manually fixed it to test on TL-WDR3500. > Apart from the breakage introduced by r45954 (which was trivial to fix) > everything seems to work well. > > Thanks for the good work! > Did you have any problems with overlayfs? Or did you apply the patch from parallel thread? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenWrt switches to musl by default
Hi, I just committed a change making musl the new default libc in OpenWrt trunk, replacing uclibc. We've been preparing this for quite a while. Some packages might still be broken, so please test and open up bug reports for any issues that you find. Please remember to open up trac tickets only for packages from trunk; send reports of broken feed packages as PR on the relevant github project. Cheers, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt switches to musl by default
Just to clarify, this is only for trunk, not for the CC branch, correct? On Mon, Jun 15, 2015 at 6:24 PM Felix Fietkau wrote: > Hi, > > I just committed a change making musl the new default libc in OpenWrt > trunk, replacing uclibc. We've been preparing this for quite a while. > Some packages might still be broken, so please test and open up bug > reports for any issues that you find. > Please remember to open up trac tickets only for packages from trunk; > send reports of broken feed packages as PR on the relevant github project. > > Cheers, > > - Felix > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] firewall instead of routing rules to keep ULAs from escaping
I wonder why in https://dev.openwrt.org/changeset/35012 the choice was made to use the firewall to prevent ULA destination addresses from trying to be reached on the WAN vs. using routing rules and "unreachable" routes. Something like: unreachable fc00::/7 dev lo metric 1024 error -128 in the routing table for example. Cheers, b. signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt switches to musl by default
On 16 June 2015 at 01:31, Jonathan Bennett wrote: > Just to clarify, this is only for trunk, not for the CC branch, correct? Read again: "in OpenWrt trunk" ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt switches to musl by default
On Mon, Jun 15, 2015 at 11:37 PM Rafał Miłecki wrote: > On 16 June 2015 at 01:31, Jonathan Bennett wrote: > > Just to clarify, this is only for trunk, not for the CC branch, correct? > > Read again: "in OpenWrt trunk" > Sometimes, even apparently obvious things are important enough to be stated explicitly. It was just a couple days ago that CC was branched from trunk, and without a lot of fanfare. I understood that the musl change was not for CC, but thought it was worth stating explicitly. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] firewall instead of routing rules to keep ULAs from escaping
That commit got reverted 4 months later and was never really in use for long. Source-Destination routing has been used to replace it for egress traffic, i.e. there are simply no external (e.g. default) routes that have a matching source-restriction. For ingress traffic the stateful firewall handles this automatically (unless you manually open it, then you might want to consider adding a rule again here). Using policy rules for incoming would be possible yes, however since we have a zone-based firewall replicating the zones with policy rules is awkward. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
