Re: [PATCH v2] fakeroot: fix to work with glibc 2.33

2021-02-11 Thread Philip Prindeville
Comments...


> On Feb 11, 2021, at 10:42 PM, Ilya Lipnitskiy  
> wrote:
> 
> The following commit removed _STAT_VER definitions from glibc:
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=8ed005daf0ab03e142500324a34087ce179ae78e
> 
> That subsequently broke fakeroot:
> https://bugs.archlinux.org/task/69572
> https://bugzilla.redhat.com/show_bug.cgi?id=1889862#c13
> https://forum.openwrt.org/t/unable-to-build-toolchain-fakeroot-fails-perhaps-others-after-it/87966
> 
> Make the patch based on Jan Pazdziora's suggestion from here:
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/SMQ3RYXEYTVZH6PLQMKNB3NM4XLPMNZO/
> 
> Additionally, add wrappers for newly exported symbols in glibc.
> 
> Tested on my x86_64 Arch Linux machine, fakeroot unit tests pass.
> Also tested by building various .ipks and examining the tar contents, to
> ensure that the owner uid/gid was 0/0.
> 
> Signed-off-by: Ilya Lipnitskiy 
> ---
> .../300-glibc-2.33-compatibility.patch| 74 +++
> 1 file changed, 74 insertions(+)
> create mode 100644 tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
> 
> diff --git a/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch 
> b/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
> new file mode 100644
> index 00..2e6beab095
> --- /dev/null
> +++ b/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
> @@ -0,0 +1,74 @@
> +--- a/libfakeroot.c
>  b/libfakeroot.c
> +@@ -90,6 +90,16 @@
> + #define SEND_GET_XATTR64(a,b,c) send_get_xattr64(a,b)
> + #endif
> + 
> ++#ifndef _STAT_VER
> ++ #if defined (__aarch64__)
> ++  #define _STAT_VER 0
> ++ #elif defined (__x86_64__)
> ++  #define _STAT_VER 1
> ++ #else
> ++  #define _STAT_VER 3
> ++ #endif
> ++#endif
> ++
> + /*
> +These INT_* (which stands for internal) macros should always be used when
> +the fakeroot library owns the storage of the stat variable.
> +@@ -1358,6 +1368,54 @@ int renameat(int olddir_fd, const char *
> + #endif /* HAVE_FSTATAT */
> + 
> + 
> ++#ifdef __GLIBC__
> ++#if __GLIBC_PREREQ(2,33)

Minor nit, but please combine these into a single line:

#if defined(__GLIBC__) && __GLIBC_PREREQ(2,33)

As that's easier to grep.


> ++/* Glibc 2.33 exports symbols for these functions in the shared lib */
> ++int lstat(const char *file_name, struct stat *statbuf) {
> ++   return WRAP_LSTAT LSTAT_ARG(_STAT_VER, file_name, statbuf);
> ++}
> ++int stat(const char *file_name, struct stat *st) {
> ++   return WRAP_STAT STAT_ARG(_STAT_VER, file_name, st);
> ++}
> ++int fstat(int fd, struct stat *st) {
> ++   return WRAP_FSTAT FSTAT_ARG(_STAT_VER, fd, st);
> ++}
> ++#ifdef HAVE_FSTATAT

Please indent nested #if or #ifdef's.


> ++int fstatat(int dir_fd, const char *path, struct stat *st, int flags) {
> ++   return WRAP_FSTATAT FSTATAT_ARG(_STAT_VER, dir_fd, path, st, flags);
> ++}
> ++#endif
> ++#ifdef STAT64_SUPPORT
> ++int lstat64(const char *file_name, struct stat64 *st) {
> ++   return WRAP_LSTAT64 LSTAT64_ARG(_STAT_VER, file_name, st);
> ++}
> ++int stat64(const char *file_name, struct stat64 *st) {
> ++   return WRAP_STAT64 STAT64_ARG(_STAT_VER, file_name, st);
> ++}
> ++int fstat64(int fd, struct stat64 *st) {
> ++   return WRAP_FSTAT64 FSTAT64_ARG(_STAT_VER, fd, st);
> ++}
> ++#ifdef HAVE_FSTATAT

Ditto.


> ++int fstatat64(int dir_fd, const char *path, struct stat64 *st, int flags) {
> ++   return WRAP_FSTATAT64 FSTATAT64_ARG(_STAT_VER, dir_fd, path, st, flags);
> ++}
> ++#endif
> ++#endif
> ++int mknod(const char *pathname, mode_t mode, dev_t dev) {
> ++   return WRAP_MKNOD MKNOD_ARG(_STAT_VER, pathname, mode, );
> ++}
> ++#ifdef HAVE_FSTATAT
> ++#ifdef HAVE_MKNODAT

Combine as:

#if defined(HAVE_FSTATAT) && defined(HAVE_MKNODAT)


> ++int mknodat(int dir_fd, const char *pathname, mode_t mode, dev_t dev) {
> ++   return WRAP_MKNODAT MKNODAT_ARG(_STAT_VER, dir_fd, pathname, mode, );
> ++}
> ++#endif
> ++#endif

Combined...


> ++
> ++#endif /* __GLIBC_PREPREQ */
> ++#endif /* __GLIBC__ */

Combined...

> ++
> ++
> + #ifdef FAKEROOT_FAKENET
> + pid_t fork(void)
> + {
> -- 
> 2.30.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[PATCH v2] fakeroot: fix to work with glibc 2.33

2021-02-11 Thread Ilya Lipnitskiy
The following commit removed _STAT_VER definitions from glibc:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=8ed005daf0ab03e142500324a34087ce179ae78e

That subsequently broke fakeroot:
https://bugs.archlinux.org/task/69572
https://bugzilla.redhat.com/show_bug.cgi?id=1889862#c13
https://forum.openwrt.org/t/unable-to-build-toolchain-fakeroot-fails-perhaps-others-after-it/87966

Make the patch based on Jan Pazdziora's suggestion from here:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/SMQ3RYXEYTVZH6PLQMKNB3NM4XLPMNZO/

Additionally, add wrappers for newly exported symbols in glibc.

Tested on my x86_64 Arch Linux machine, fakeroot unit tests pass.
Also tested by building various .ipks and examining the tar contents, to
ensure that the owner uid/gid was 0/0.

Signed-off-by: Ilya Lipnitskiy 
---
 .../300-glibc-2.33-compatibility.patch| 74 +++
 1 file changed, 74 insertions(+)
 create mode 100644 tools/fakeroot/patches/300-glibc-2.33-compatibility.patch

diff --git a/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch 
b/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
new file mode 100644
index 00..2e6beab095
--- /dev/null
+++ b/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
@@ -0,0 +1,74 @@
+--- a/libfakeroot.c
 b/libfakeroot.c
+@@ -90,6 +90,16 @@
+ #define SEND_GET_XATTR64(a,b,c) send_get_xattr64(a,b)
+ #endif
+ 
++#ifndef _STAT_VER
++ #if defined (__aarch64__)
++  #define _STAT_VER 0
++ #elif defined (__x86_64__)
++  #define _STAT_VER 1
++ #else
++  #define _STAT_VER 3
++ #endif
++#endif
++
+ /*
+These INT_* (which stands for internal) macros should always be used when
+the fakeroot library owns the storage of the stat variable.
+@@ -1358,6 +1368,54 @@ int renameat(int olddir_fd, const char *
+ #endif /* HAVE_FSTATAT */
+ 
+ 
++#ifdef __GLIBC__
++#if __GLIBC_PREREQ(2,33)
++/* Glibc 2.33 exports symbols for these functions in the shared lib */
++int lstat(const char *file_name, struct stat *statbuf) {
++   return WRAP_LSTAT LSTAT_ARG(_STAT_VER, file_name, statbuf);
++}
++int stat(const char *file_name, struct stat *st) {
++   return WRAP_STAT STAT_ARG(_STAT_VER, file_name, st);
++}
++int fstat(int fd, struct stat *st) {
++   return WRAP_FSTAT FSTAT_ARG(_STAT_VER, fd, st);
++}
++#ifdef HAVE_FSTATAT
++int fstatat(int dir_fd, const char *path, struct stat *st, int flags) {
++   return WRAP_FSTATAT FSTATAT_ARG(_STAT_VER, dir_fd, path, st, flags);
++}
++#endif
++#ifdef STAT64_SUPPORT
++int lstat64(const char *file_name, struct stat64 *st) {
++   return WRAP_LSTAT64 LSTAT64_ARG(_STAT_VER, file_name, st);
++}
++int stat64(const char *file_name, struct stat64 *st) {
++   return WRAP_STAT64 STAT64_ARG(_STAT_VER, file_name, st);
++}
++int fstat64(int fd, struct stat64 *st) {
++   return WRAP_FSTAT64 FSTAT64_ARG(_STAT_VER, fd, st);
++}
++#ifdef HAVE_FSTATAT
++int fstatat64(int dir_fd, const char *path, struct stat64 *st, int flags) {
++   return WRAP_FSTATAT64 FSTATAT64_ARG(_STAT_VER, dir_fd, path, st, flags);
++}
++#endif
++#endif
++int mknod(const char *pathname, mode_t mode, dev_t dev) {
++   return WRAP_MKNOD MKNOD_ARG(_STAT_VER, pathname, mode, );
++}
++#ifdef HAVE_FSTATAT
++#ifdef HAVE_MKNODAT
++int mknodat(int dir_fd, const char *pathname, mode_t mode, dev_t dev) {
++   return WRAP_MKNODAT MKNODAT_ARG(_STAT_VER, dir_fd, pathname, mode, );
++}
++#endif
++#endif
++
++#endif /* __GLIBC_PREPREQ */
++#endif /* __GLIBC__ */
++
++
+ #ifdef FAKEROOT_FAKENET
+ pid_t fork(void)
+ {
-- 
2.30.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] fakeroot: fix to work with glibc 2.33

2021-02-11 Thread Ilya Lipnitskiy
Hi Felix,

On Thu, Feb 11, 2021 at 2:39 AM Felix Fietkau  wrote:
> Defining _STAT_VER fixes the compile error and should work with binaries
> compiled against old glibc, but I wonder if this also works with newer
> binaries that now reference different functions.
> Did you explicitly test that?
Good catch, I did some more work and added wrappers for the newly
exported symbols. I'll post the v2 patch soon.

Ilya

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


OpenWrt 21.02 planning

2021-02-11 Thread Hauke Mehrtens

Hi,

We just had our developer meeting and want to do branch the next release 
soon. I just want to coordinate the release planning here, the full 
meeting notes will be published later.


We want to merge the mac80211 update to version 5.10 found here:
https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/mac80211-5.10
Felix uses this since some time now and found no problems, I am also not 
aware of any problems. Kernel 5.10 is an LTS kernel which makes security 
maintenance easier for us.

I plan to merge this at the weekend.

We would also like to get this busybox update in:
https://patchwork.ozlabs.org/project/openwrt/list/?series=227292
It also works well and should make it easier to maintain busybox in our 
stable release.

I plan to merge this at the weekend.

It would be nice to get DSA support in LuCI. We have this pull request:
https://github.com/openwrt/luci/pull/4307
This still has problems with Wireless bridge-vlan.
If this is not ready in time for the branching we will backport it later.

Rafał is asking about the general LuCI status here:
https://lists.openwrt.org/pipermail/openwrt-devel/2021-February/033715.html


For more details, we have this release goals page:
https://openwrt.org/docs/guide-developer/releases/goals/21.02

lynxis and ynezz will prepare the build bot setup to build snapshots of 
the 21.02 release branch and the releases (candidates).


If everything will look good, we will branch 21.02 sometime next week.

If the update of mac80ß211 or busybox breaks something, we will fix it 
or revert the update this should not delay the branching.


I would like to have a 21.02-rc1 in 2 or 3 weeks after the branching, so 
we get more test coverage.


Do we still have some important bugs we should really fix in master or 
anything which could be blocking for the release?

Any objections to this plan?

Hauke



OpenPGP_signature
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


RE: [PATCH] ath79/nand: fix factory image generation for Netgear boards

2021-02-11 Thread Adrian Schmutzler
Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Paul Fertser
> Sent: Donnerstag, 11. Februar 2021 22:11
> To: openwrt-devel@lists.openwrt.org
> Cc: Paul Fertser ; Marcin Juszkiewicz  open...@juszkiewicz.com.pl>
> Subject: [PATCH] ath79/nand: fix factory image generation for Netgear
> boards
> 
> The factory images need to embed specific IDs to pass verification with the
> OEM firmware (including TFTP recovery), so they need to be per-device
> variables.
> 
> Fixes: ab1584a797 ("ath79: netgear: trim down uImage customisations")
> Acked-By: Marcin Juszkiewicz 
> Signed-off-by: Paul Fertser 
> ---
>  target/linux/ath79/image/nand.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/linux/ath79/image/nand.mk
> b/target/linux/ath79/image/nand.mk
> index 37fcb36937..351239e2b3 100644
> --- a/target/linux/ath79/image/nand.mk
> +++ b/target/linux/ath79/image/nand.mk
> @@ -1,4 +1,4 @@
> -DEVICE_VARS += RAS_ROOTFS_SIZE RAS_BOARD RAS_VERSION
> +DEVICE_VARS += RAS_ROOTFS_SIZE RAS_BOARD RAS_VERSION
> NETGEAR_BOARD_ID
> +NETGEAR_HW_ID

These are in common-netgear.mk. I'd say either just include that file here 
(like done in generic.mk) or move just the DEVICE_VARS addition to 
image/Makefile.

Best

Adrian

> 
>  # attention: only zlib compression is allowed for the boot fs  define
> Build/zyxel-buildkerneljffs
> --
> 2.20.1
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[no subject]

2021-02-11 Thread Jonathan Lancett via openwrt-devel
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

On 11/02/2021 21:28, Rafał Miłecki wrote:

We're planning a 21.xx release and for a lot of our end users LuCI is
an important part of OpenWrt.

I'd like to ask: what's the current state of LuCI?
One thing that probably requires some extra focus is DSA. Are there
any remaining issues regarding it?

I'd be also nice to get some extra LuCI testing before the release. If
you can, please install & test LuCI on your device & provide a
feedback if something appears broken.



      �

From my POV just this:

https://github.com/openwrt/luci/issues/4801

It's better for screen reader users.


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Question about LuCI state (incl DSA) & request for testing

2021-02-11 Thread Rafał Miłecki
We're planning a 21.xx release and for a lot of our end users LuCI is
an important part of OpenWrt.

I'd like to ask: what's the current state of LuCI?
One thing that probably requires some extra focus is DSA. Are there
any remaining issues regarding it?

I'd be also nice to get some extra LuCI testing before the release. If
you can, please install & test LuCI on your device & provide a
feedback if something appears broken.

-- 
Rafał

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[PATCH] ath79/nand: fix factory image generation for Netgear boards

2021-02-11 Thread Paul Fertser
The factory images need to embed specific IDs to pass verification with
the OEM firmware (including TFTP recovery), so they need to be
per-device variables.

Fixes: ab1584a797 ("ath79: netgear: trim down uImage customisations")
Acked-By: Marcin Juszkiewicz 
Signed-off-by: Paul Fertser 
---
 target/linux/ath79/image/nand.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ath79/image/nand.mk b/target/linux/ath79/image/nand.mk
index 37fcb36937..351239e2b3 100644
--- a/target/linux/ath79/image/nand.mk
+++ b/target/linux/ath79/image/nand.mk
@@ -1,4 +1,4 @@
-DEVICE_VARS += RAS_ROOTFS_SIZE RAS_BOARD RAS_VERSION
+DEVICE_VARS += RAS_ROOTFS_SIZE RAS_BOARD RAS_VERSION NETGEAR_BOARD_ID 
NETGEAR_HW_ID
 
 # attention: only zlib compression is allowed for the boot fs
 define Build/zyxel-buildkerneljffs
-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[PATCH] mvebu: espressobin: drop COMPHY removement patch

2021-02-11 Thread Tomasz Maciej Nowak
There are proper workarounds merged to 5.4 stable tree for ESPRESSObin
boards with older bootloader:
4e1a23779bde ("ata: ahci: mvebu: Make SATA PHY optional for Armada 3720")
40af962eb1d4 ("usb: host: xhci: mvebu: make USB 3.0 PHY optional for
Armada 3720")

Signed-off-by: Tomasz Maciej Nowak 
---
 ...l-espressobin-remove-COMPHY-nodes-as.patch | 53 ---
 ...itch-PHY-operation-mode-to-2500base.patch} |  0
 2 files changed, 53 deletions(-)
 delete mode 100644 
target/linux/mvebu/patches-5.4/316-arm64-dts-marvell-espressobin-remove-COMPHY-nodes-as.patch
 rename 
target/linux/mvebu/patches-5.4/{317-arm64-dts-uDPU-switch-PHY-operation-mode-to-2500base.patch
 => 316-arm64-dts-uDPU-switch-PHY-operation-mode-to-2500base.patch} (100%)

diff --git 
a/target/linux/mvebu/patches-5.4/316-arm64-dts-marvell-espressobin-remove-COMPHY-nodes-as.patch
 
b/target/linux/mvebu/patches-5.4/316-arm64-dts-marvell-espressobin-remove-COMPHY-nodes-as.patch
deleted file mode 100644
index 44e9a9237b42..
--- 
a/target/linux/mvebu/patches-5.4/316-arm64-dts-marvell-espressobin-remove-COMPHY-nodes-as.patch
+++ /dev/null
@@ -1,53 +0,0 @@
-From e928880bd8b26fd704231549456ae7da88cecda6 Mon Sep 17 00:00:00 2001
-From: Tomasz Maciej Nowak 
-Date: Mon, 20 Apr 2020 14:35:34 +0200
-Subject: [PATCH] arm64: dts: marvell: espressobin: remove COMPHY nodes
- assignmet
-
-This commit removes changes from upstream commits:
-8e18c8e58da6 arm64: dts: marvell: armada-3720-espressobin: declare SATA
-PHY property
-bd3d25b07342 arm64: dts: marvell: armada-37xx: link USB hosts with their
-PHYs
-For most boards which have factory bootloader this caused that devices
-connected to USB 3.0 and SATA port were not detected. For them to
-function users would need to upgrade the bootloader to version with ARM
-Trusted Firmware 2.1 or later. Unfortunately there is no official
-bootloader image with updated ATF component, therefore drop these
-properties from nodes. This change was also tested briefly with
-bootloader with updated ATF and the ports functioned properly.
-
-Signed-off-by: Tomasz Maciej Nowak 

- arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts | 8 ++--
- 1 file changed, 6 insertions(+), 2 deletions(-)
-
 a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
-+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
-@@ -64,8 +64,6 @@
- /* J6 */
-  {
-   status = "okay";
--  phys = < 0>;
--  phy-names = "sata-phy";
- };
- 
- /* J1 */
-@@ -131,11 +129,17 @@
- /* J7 */
-  {
-   status = "okay";
-+
-+  /delete-property/ phys;
-+  /delete-property/ phy-names;
- };
- 
- /* J8 */
-  {
-   status = "okay";
-+
-+  /delete-property/ phys;
-+  /delete-property/ phy-names;
- };
- 
-  {
diff --git 
a/target/linux/mvebu/patches-5.4/317-arm64-dts-uDPU-switch-PHY-operation-mode-to-2500base.patch
 
b/target/linux/mvebu/patches-5.4/316-arm64-dts-uDPU-switch-PHY-operation-mode-to-2500base.patch
similarity index 100%
rename from 
target/linux/mvebu/patches-5.4/317-arm64-dts-uDPU-switch-PHY-operation-mode-to-2500base.patch
rename to 
target/linux/mvebu/patches-5.4/316-arm64-dts-uDPU-switch-PHY-operation-mode-to-2500base.patch
-- 
2.30.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] fakeroot: fix to work with glibc 2.33

2021-02-11 Thread Felix Fietkau


Hi Ilya,

On 2021-02-11 04:14, Ilya Lipnitskiy wrote:
> The following commit removed _STAT_VER definitions from glibc:
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=8ed005daf0ab03e142500324a34087ce179ae78e
> 
> That subsequently broke fakeroot:
> https://bugs.archlinux.org/task/69572
> https://bugzilla.redhat.com/show_bug.cgi?id=1889862#c13
> https://forum.openwrt.org/t/unable-to-build-toolchain-fakeroot-fails-perhaps-others-after-it/87966
> 
> Make the patch based on Jan Pazdziora's suggestion from here:
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/SMQ3RYXEYTVZH6PLQMKNB3NM4XLPMNZO/
> 
> Tested on my x86_64 Arch Linux machine, fakeroot unit tests pass.
> 
> Signed-off-by: Ilya Lipnitskiy 
If I'm not misreading the code, it seems to me that this patch might be
incomplete. The old glibc version was carrying inline wrappers for stat,
stat64, etc. Because binaries compiled against the old glibc version
were only containing references to the wrapped internal functions and
never the main functions directly, fakeroot seems to be handling only
the __ prefixed internal functions.
Defining _STAT_VER fixes the compile error and should work with binaries
compiled against old glibc, but I wonder if this also works with newer
binaries that now reference different functions.
Did you explicitly test that?

Thanks for looking into this,

- Felix

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel