Re: [ptxdist] [PATCH v2] template-src-linux-driver: Only install driver if selected
On 18/01/2019 17:37, Ian Abbott wrote:
On 13/12/2018 12:07, Ian Abbott wrote:
If a local package "foo-mod" for a Linux kernel module is selected by a
local tristate configuration option PTXCONF_FOO_MOD, then based on the
template for Linux drivers, it would include the following in its
foo-mod.make file:
ifdef PTXCONF_FOO_MOD
$(STATEDIR)/kernel.targetinstall.post: $(STATEDIR)/foo-mod.targetinstall
endif
However, this rule will be invoked even if the PTXCONF_FOO_MOD option
has been configured with the tristate option 'm' and has not been
changed to 'y' by a selected_collectionconfig. This causes the Linux
kernel module to be built and installed unintentionally. To prevent
that happening, the above lines in the foo-mod.make file can be changed
as follows (using a conditional test suggested by Michael Olbrich):
ifneq ($(filter foo-mod,$(PTX_PACKAGES_SELECTED)),)
$(STATEDIR)/kernel.targetinstall.post: $(STATEDIR)/foo-mod.targetinstall
endif
This patch changes the template for Linux driver packages in accordance
with the above change.
Signed-off-by: Ian Abbott
Cc: Michael Olbrich
---
v2: Changed the conditional test to that suggested by Michael Olbrich in
Message-ID <20181212111846.zb3kxfs6jsc5r...@pengutronix.de> to avoid
breaking the build if the package is configured using the tristate 'm'
option and no collection is selected.
rules/templates/template-src-linux-driver-make | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rules/templates/template-src-linux-driver-make
b/rules/templates/template-src-linux-driver-make
index e06a22497..c13857924 100644
--- a/rules/templates/template-src-linux-driver-make
+++ b/rules/templates/template-src-linux-driver-make
@@ -22,7 +22,7 @@ PACKAGES-$(PTXCONF_@PACKAGE@) += @package@
@PACKAGE@_DIR := $(BUILDDIR)/$(@PACKAGE@)
@PACKAGE@_LICENSE := unknown
-ifdef PTXCONF_@PACKAGE@
+ifneq ($(filter @package@,$(PTX_PACKAGES_SELECTED)),)
$(STATEDIR)/kernel.targetinstall.post:
$(STATEDIR)/@package@.targetinstall
endif
I know this is in 2019.01.0 now, but I don't think the new conditional
test for adding this kernel.targetinstall.post dependency is actually
working properly. I've had a few `ptxdist go` commands running with the
-j N option, and quite often the kernel.targetinstall.post completes
before the @package@.targetinstall, meaning that the module does not get
installed to the
${PTXDIST_PLATFORMDIR}/root/lib/modules/$UNAME_RELEASE/extra as it
should (where $UNAME_RELEASE is the kernel `uname -r` value).
The conditional test from v1 of the patch:
ifdef PTXCONF_@PACKAGE@)
still works for me, but will break the build for other people.
I'll try and work out why the new conditional test isn't working for me
reliably (especially when building with parallel jobs), but I welcome
any suggestions to try and fix it properly.
The following conditional test seems to work, but it's quite ugly:
ifeq ($(and $(PTXCONF_@PACKAGE@),$(if
$(PTX_COLLECTION),$(PTXCONF_@PACKAGE@),y)),y)
--
-=( Ian Abbott || Web: www.mev.co.uk )=-
-=( MEV Ltd. is a company registered in England & Wales. )=-
-=( Registered number: 02862268. Registered address:)=-
-=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-
___
ptxdist mailing list
ptxdist@pengutronix.de
Re: [ptxdist] [PATCH v2] template-src-linux-driver: Only install driver if selected
On 13/12/2018 12:07, Ian Abbott wrote:
If a local package "foo-mod" for a Linux kernel module is selected by a
local tristate configuration option PTXCONF_FOO_MOD, then based on the
template for Linux drivers, it would include the following in its
foo-mod.make file:
ifdef PTXCONF_FOO_MOD
$(STATEDIR)/kernel.targetinstall.post: $(STATEDIR)/foo-mod.targetinstall
endif
However, this rule will be invoked even if the PTXCONF_FOO_MOD option
has been configured with the tristate option 'm' and has not been
changed to 'y' by a selected_collectionconfig. This causes the Linux
kernel module to be built and installed unintentionally. To prevent
that happening, the above lines in the foo-mod.make file can be changed
as follows (using a conditional test suggested by Michael Olbrich):
ifneq ($(filter foo-mod,$(PTX_PACKAGES_SELECTED)),)
$(STATEDIR)/kernel.targetinstall.post: $(STATEDIR)/foo-mod.targetinstall
endif
This patch changes the template for Linux driver packages in accordance
with the above change.
Signed-off-by: Ian Abbott
Cc: Michael Olbrich
---
v2: Changed the conditional test to that suggested by Michael Olbrich in
Message-ID <20181212111846.zb3kxfs6jsc5r...@pengutronix.de> to avoid
breaking the build if the package is configured using the tristate 'm'
option and no collection is selected.
rules/templates/template-src-linux-driver-make | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rules/templates/template-src-linux-driver-make
b/rules/templates/template-src-linux-driver-make
index e06a22497..c13857924 100644
--- a/rules/templates/template-src-linux-driver-make
+++ b/rules/templates/template-src-linux-driver-make
@@ -22,7 +22,7 @@ PACKAGES-$(PTXCONF_@PACKAGE@) += @package@
@PACKAGE@_DIR := $(BUILDDIR)/$(@PACKAGE@)
@PACKAGE@_LICENSE := unknown
-ifdef PTXCONF_@PACKAGE@
+ifneq ($(filter @package@,$(PTX_PACKAGES_SELECTED)),)
$(STATEDIR)/kernel.targetinstall.post: $(STATEDIR)/@package@.targetinstall
endif
I know this is in 2019.01.0 now, but I don't think the new conditional
test for adding this kernel.targetinstall.post dependency is actually
working properly. I've had a few `ptxdist go` commands running with the
-j N option, and quite often the kernel.targetinstall.post completes
before the @package@.targetinstall, meaning that the module does not get
installed to the
${PTXDIST_PLATFORMDIR}/root/lib/modules/$UNAME_RELEASE/extra as it
should (where $UNAME_RELEASE is the kernel `uname -r` value).
The conditional test from v1 of the patch:
ifdef PTXCONF_@PACKAGE@)
still works for me, but will break the build for other people.
I'll try and work out why the new conditional test isn't working for me
reliably (especially when building with parallel jobs), but I welcome
any suggestions to try and fix it properly.
--
-=( Ian Abbott || Web: www.mev.co.uk )=-
-=( MEV Ltd. is a company registered in England & Wales. )=-
-=( Registered number: 02862268. Registered address:)=-
-=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-
___
ptxdist mailing list
ptxdist@pengutronix.de
Re: [ptxdist] [ANNOUNCE] OSELAS.Toolchain() 2018.02.0 released - host-m4 build error on Ubuntu 18.10
On Fri, Jan 18, 2019 at 02:23:02PM +0100, Roland Hieber wrote: > On Fri, Jan 18, 2019 at 11:34:22AM +0100, Michael Olbrich wrote: > > On Fri, Jan 18, 2019 at 10:07:45AM +0100, Roland Hieber wrote: > > > On Sat, Sep 29, 2018 at 05:57:53PM +0200, Andreas Pretzsch wrote: > > > > During build of the toolchain (at least in configs arm-v7a-linux- > > > > gnueabihf, arm-v7m-eabi, arm-v7em-eabihf) on an Ubuntu 18.10-beta host, > > > > build stopped here with an host-m4 error: > > > > fseeko.c: In function 'rpl_fseeko': > > > > fseeko.c:110:4: error: #error "Please port gnulib fseeko.c to your > > > > platform! Look at the code in fseeko.c, then report this to bug-gnulib." > > > >#error "Please port gnulib fseeko.c to your platform! Look at the > > > > code in fseeko.c, then report this to bug-gnulib." > > > > ^ > > > > GEN charset.alias > > > > make[4]: *** [Makefile:1910: fseeko.o] Error 1 > > > > make[4]: *** Waiting for unfinished jobs > > > > CC vasprintf.o > > > > freadahead.c: In function 'freadahead': > > > > freadahead.c:92:3: error: #error "Please port gnulib freadahead.c to > > > > your platform! Look at the definition of fflush, fread, ungetc on your > > > > system, then report this to bug-gnulib." > > > > #error "Please port gnulib freadahead.c to your platform! Look at the > > > > definition of fflush, fread, ungetc on your system, then report this to > > > > bug-gnulib." > > > >^ > > > > make[4]: *** [Makefile:1910: freadahead.o] Error 1 > > > > > > > > Reason is the glibc 2.28 on the build host (libc6:amd64 2.28-0ubuntu1). > > > > Same probably applies to other distributions. > > > > > > > > In up-to-date ptxdist, there is a patch included fixing this issue: > > > > commit cba1e28 "m4/coreutil: add gnulib patches for GLibc-2.28" from > > > > Rouven Czerwinski, dating 2018-08-23. > > > > With this, m4 is patched accordingly, and build succeeds. > > > > > > > > The OSELAS.Toolchain-2018.02.0 ptxdist project refers to ptxdist- > > > > 2018.02.0 by default. Above patch is part of ptxdist-2018.09.0. > > > > > > > > So until there is a revised version of OSELAS.Toolchain, either use > > > > ptxdist-2018.09.0 or later for building, or include the patch in the > > > > toolchain project. > > > > Did you try building the toolchain with ptxdist-2018.09.0 (with -f)? Does > > it work? > > > > > > @ PTX: This might be worth mentioning in the building instructions or > > > > at a similar place. > > > > Hmm, we don't really have a place to put version specific notes. And the > > generic build instructions are out of date too... :-/. > > > > > mol, do you think it is feasible to release a 2018.02.1 toolchain with > > > the host-m4 (and probably other host-glibc related) patches? > > > > Well, we could start fixing this in a stable branch. Any volunteers? :-) > > And maybe a source only release. That's easy. Building all the binary > > toolchains it what makes a release a lot of work. > > The m4 patch [1] works for me, but I've also run into issues with building > gdb against Python 3.7 on Debian unstable: > > python/python.c: In function 'bool do_start_initialization()': > python/python.c:1710:45: error: too few arguments to function 'int > _PyImport_FixupBuiltin(PyObject*, const char*, PyObject*)' >_PyImport_FixupBuiltin (gdb_module, "_gdb"); > ^ > > There is a patch [2] available upstream, but this will break if the > build host uses python < 3.7. Which configurations do we want to target > for a stable branch? The Debian packages for OSELAS.Toolchain-2018.12.0 use Python 3.5 on stretch and 3.7 on buster, so building against either version works for gdb 8.2 so maybe you're missing some other patch? Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [ANNOUNCE] OSELAS.Toolchain() 2018.02.0 released - host-m4 build error on Ubuntu 18.10
On Fri, Jan 18, 2019 at 11:34:22AM +0100, Michael Olbrich wrote: > On Fri, Jan 18, 2019 at 10:07:45AM +0100, Roland Hieber wrote: > > On Sat, Sep 29, 2018 at 05:57:53PM +0200, Andreas Pretzsch wrote: > > > During build of the toolchain (at least in configs arm-v7a-linux- > > > gnueabihf, arm-v7m-eabi, arm-v7em-eabihf) on an Ubuntu 18.10-beta host, > > > build stopped here with an host-m4 error: > > > fseeko.c: In function 'rpl_fseeko': > > > fseeko.c:110:4: error: #error "Please port gnulib fseeko.c to your > > > platform! Look at the code in fseeko.c, then report this to bug-gnulib." > > >#error "Please port gnulib fseeko.c to your platform! Look at the code > > > in fseeko.c, then report this to bug-gnulib." > > > ^ > > > GEN charset.alias > > > make[4]: *** [Makefile:1910: fseeko.o] Error 1 > > > make[4]: *** Waiting for unfinished jobs > > > CC vasprintf.o > > > freadahead.c: In function 'freadahead': > > > freadahead.c:92:3: error: #error "Please port gnulib freadahead.c to your > > > platform! Look at the definition of fflush, fread, ungetc on your system, > > > then report this to bug-gnulib." > > > #error "Please port gnulib freadahead.c to your platform! Look at the > > > definition of fflush, fread, ungetc on your system, then report this to > > > bug-gnulib." > > >^ > > > make[4]: *** [Makefile:1910: freadahead.o] Error 1 > > > > > > Reason is the glibc 2.28 on the build host (libc6:amd64 2.28-0ubuntu1). > > > Same probably applies to other distributions. > > > > > > In up-to-date ptxdist, there is a patch included fixing this issue: > > > commit cba1e28 "m4/coreutil: add gnulib patches for GLibc-2.28" from > > > Rouven Czerwinski, dating 2018-08-23. > > > With this, m4 is patched accordingly, and build succeeds. > > > > > > The OSELAS.Toolchain-2018.02.0 ptxdist project refers to ptxdist- > > > 2018.02.0 by default. Above patch is part of ptxdist-2018.09.0. > > > > > > So until there is a revised version of OSELAS.Toolchain, either use > > > ptxdist-2018.09.0 or later for building, or include the patch in the > > > toolchain project. > > Did you try building the toolchain with ptxdist-2018.09.0 (with -f)? Does > it work? > > > > @ PTX: This might be worth mentioning in the building instructions or > > > at a similar place. > > Hmm, we don't really have a place to put version specific notes. And the > generic build instructions are out of date too... :-/. > > > mol, do you think it is feasible to release a 2018.02.1 toolchain with > > the host-m4 (and probably other host-glibc related) patches? > > Well, we could start fixing this in a stable branch. Any volunteers? :-) > And maybe a source only release. That's easy. Building all the binary > toolchains it what makes a release a lot of work. The m4 patch [1] works for me, but I've also run into issues with building gdb against Python 3.7 on Debian unstable: python/python.c: In function 'bool do_start_initialization()': python/python.c:1710:45: error: too few arguments to function 'int _PyImport_FixupBuiltin(PyObject*, const char*, PyObject*)' _PyImport_FixupBuiltin (gdb_module, "_gdb"); ^ There is a patch [2] available upstream, but this will break if the build host uses python < 3.7. Which configurations do we want to target for a stable branch? [1]: https://git.pengutronix.de/cgit/rhi/OSELAS.Toolchain/commit/?h=rhi/for-stable/OSELAS.Toolchain-2018.02.x=15f8bd0a1a8c82fdc722793b429b47c31d85dbb4 [2]: https://sourceware.org/ml/gdb-patches/2018-05/msg00863.html -- Roland Hieber | r.hie...@pengutronix.de | Pengutronix e.K. | https://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim | Phone: +49-5121-206917-5086 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH v3 1/2] host-pyhton-scons: add new package
Hi, On Fri, Jan 18, 2019 at 09:05:28AM +, Denis OSTERLAND wrote: > I have tested it here with a minimal configuration and I fails to build... > > - > target: host-python-scons.compile > - > > ptxdist: executing: cd > /home/osterlad/BSPs/OSELAS.BSP-Pengutronix-Generic/platform-sabrelite/build-host/python-scons-3.0.1 > && PATH=\/home/osterlad/BSPs/OSELAS.BSP-Pengutronix-Generic/platform- > sabrelite/sysroot-host/lib/wrapper:/home/osterlad/BSPs/OSELAS.BSP-Pengutronix-Generic/platform-sabrelite/sysroot-host/bin:/home/osterlad/BSPs/OSELAS.BSP-Pengutronix-Generic/platform-sabrelite/sysroot- > host/sbin:/home/osterlad/BSPs/OSELAS.BSP-Pengutronix-Generic/selected_toolchain:/usr/lib/x86_64-linux-gnu/ptxdist- > 2018.12.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin > PKGCONFIG_WHITELIST_HOST='' PKGCONFIG_WHITELIST_TARGET='' > PKGCONFIG_WHITELIST_SRC='host-python-scons' > SYSROOT='/home/osterlad/BSPs/OSELAS.BSP-Pengutronix-Generic/platform-sabrelite/sysroot-host' > V=1 VERBOSE=1 KBUILD_BUILD_TIMESTAMP=2018-12-01T00:00:00+00:00 > KBUILD_BUILD_USER=ptxdist KBUILD_BUILD_HOST=ptxdist > enable_option_checking=fatal enable_maintainer_mode=no enable_static=no > CC="gcc" CXX="g++" PYTHONPATH="/home/osterlad/BSPs/OSELAS.BSP-Pengutronix- > Generic/platform-sabrelite/sysroot-host/lib/python2.7/site-packages" > /home/osterlad/BSPs/OSELAS.BSP-Pengutronix-Generic/platform-sabrelite/sysroot-host/bin/python2.7 > setup.py build > > /bin/bash: line 2: > /home/osterlad/BSPs/OSELAS.BSP-Pengutronix-Generic/platform-sabrelite/sysroot-host/bin/python2.7: > No such file or directory > > > The rules/host-python-setuptools.in selects HOST_PYTHON instead of > HOST_SYSTEM_PYTHON as well. > > I find only "python" as "pkg_conf_tool" in > scripts/lib/ptxd_make_world_common.sh. > Is there some "_CONF_TOOL := system-python"? Right, I forgot about this. Try master, I've pushed a fix that uses the system Python if the package selects HOST_SYSTEM_PYTHON. But maybe less magic and a explicit "_CONF_TOOL := system-python" would be better. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [ANNOUNCE] OSELAS.Toolchain() 2018.02.0 released - host-m4 build error on Ubuntu 18.10
On Fri, Jan 18, 2019 at 10:07:45AM +0100, Roland Hieber wrote: > On Sat, Sep 29, 2018 at 05:57:53PM +0200, Andreas Pretzsch wrote: > > During build of the toolchain (at least in configs arm-v7a-linux- > > gnueabihf, arm-v7m-eabi, arm-v7em-eabihf) on an Ubuntu 18.10-beta host, > > build stopped here with an host-m4 error: > > fseeko.c: In function 'rpl_fseeko': > > fseeko.c:110:4: error: #error "Please port gnulib fseeko.c to your > > platform! Look at the code in fseeko.c, then report this to bug-gnulib." > >#error "Please port gnulib fseeko.c to your platform! Look at the code > > in fseeko.c, then report this to bug-gnulib." > > ^ > > GEN charset.alias > > make[4]: *** [Makefile:1910: fseeko.o] Error 1 > > make[4]: *** Waiting for unfinished jobs > > CC vasprintf.o > > freadahead.c: In function 'freadahead': > > freadahead.c:92:3: error: #error "Please port gnulib freadahead.c to your > > platform! Look at the definition of fflush, fread, ungetc on your system, > > then report this to bug-gnulib." > > #error "Please port gnulib freadahead.c to your platform! Look at the > > definition of fflush, fread, ungetc on your system, then report this to > > bug-gnulib." > >^ > > make[4]: *** [Makefile:1910: freadahead.o] Error 1 > > > > Reason is the glibc 2.28 on the build host (libc6:amd64 2.28-0ubuntu1). > > Same probably applies to other distributions. > > > > In up-to-date ptxdist, there is a patch included fixing this issue: > > commit cba1e28 "m4/coreutil: add gnulib patches for GLibc-2.28" from > > Rouven Czerwinski, dating 2018-08-23. > > With this, m4 is patched accordingly, and build succeeds. > > > > The OSELAS.Toolchain-2018.02.0 ptxdist project refers to ptxdist- > > 2018.02.0 by default. Above patch is part of ptxdist-2018.09.0. > > > > So until there is a revised version of OSELAS.Toolchain, either use > > ptxdist-2018.09.0 or later for building, or include the patch in the > > toolchain project. Did you try building the toolchain with ptxdist-2018.09.0 (with -f)? Does it work? > > @ PTX: This might be worth mentioning in the building instructions or > > at a similar place. Hmm, we don't really have a place to put version specific notes. And the generic build instructions are out of date too... :-/. > mol, do you think it is feasible to release a 2018.02.1 toolchain with > the host-m4 (and probably other host-glibc related) patches? Well, we could start fixing this in a stable branch. Any volunteers? :-) And maybe a source only release. That's easy. Building all the binary toolchains it what makes a release a lot of work. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [RFC] ppp: Fixes to build with glibc >= 2.28
On Thu, Jan 10, 2019 at 12:32:43AM +0100, Ladislav Michl wrote:
> ppp does not build with glibc-2.28 as it dropped libcrypt. Upstream has patch:
> https://github.com/paulusmack/ppp/commit/3c7b86229f7bd2600d74db14b1fe5b3896be3875
>
> However it is a bit mystery to me as pppd/auth.c and pppd/session.c
> are still using crypt() and there is not anything to provide it
> (I mean in upstream package - there still is something remaining
> from -lcrypt, it can be linked against both -lcrypto and -lcrypt and
> crypt() will be satisfied - I just do not see how is upstream doing that).
> Thus activate no_crypt_hack. All this is done regardless glibc
> version as we do not currently have a way to detect it.
crypt() is still available. It's just encrypt() and setkey() that are
gone.
> GLIBC_VERSION from rules/glibc.make is not very usefull and we
> should probably introduce some magic in rules/pre/glibc.make
> Better ideas?
We could just disable the parts that use this stuff. Is this actually still
needed? We're talking about DES here and that's not secure anyways. Is that
actually still used?
Michael
> Thank you,
> ladis
> ---
> patches/ppp-2.4.7/0001-adaptive_echos.patch | 8 +-
> ...-for-the-DES-instead-of-the-libcrypt.patch | 109 ++
> ...31-pppd-make-makefile-sysroot-aware.patch} | 15 ++-
> ...the-self-made-configure-cross-aware.patch} | 0
> patches/ppp-2.4.7/series | 7 +-
> rules/ppp.in | 8 +-
> rules/ppp.make| 6 +-
> 7 files changed, 137 insertions(+), 16 deletions(-)
> create mode 100644
> patches/ppp-2.4.7/0030-pppd-Use-openssl-for-the-DES-instead-of-the-libcrypt.patch
> rename patches/ppp-2.4.7/{0030-pppd-make-makefile-sysroot-aware.patch =>
> 0031-pppd-make-makefile-sysroot-aware.patch} (77%)
> rename
> patches/ppp-2.4.7/{0031-pppd-make-the-self-made-configure-cross-aware.patch
> => 0032-pppd-make-the-self-made-configure-cross-aware.patch} (100%)
>
> diff --git a/patches/ppp-2.4.7/0001-adaptive_echos.patch
> b/patches/ppp-2.4.7/0001-adaptive_echos.patch
> index c736a350d..63b67d87e 100644
> --- a/patches/ppp-2.4.7/0001-adaptive_echos.patch
> +++ b/patches/ppp-2.4.7/0001-adaptive_echos.patch
> @@ -28,10 +28,11 @@ index 8ed2778bfb67..c97a64b7774f 100644
> { "lcp-restart", o_int, _fsm[0].timeouttime,
> "Set time in seconds between LCP retransmissions", OPT_PRIO },
> { "lcp-max-terminate", o_int, _fsm[0].maxtermtransmits,
> -@@ -2332,6 +2335,22 @@ LcpSendEchoRequest (f)
> +@@ -2331,6 +2334,22 @@ LcpSendEchoRequest (f)
> + }
> }
>
> - /*
> ++/*
> + * If adaptive echos have been enabled, only send the echo request if
> + * no traffic was received since the last one.
> + */
> @@ -47,10 +48,9 @@ index 8ed2778bfb67..c97a64b7774f 100644
> +}
> +}
> +
> -+/*
> + /*
>* Make and send the echo request frame.
>*/
> - if (f->state == OPENED) {
> diff --git a/pppd/pppd.8 b/pppd/pppd.8
> index e2768b135273..b7fd0bdaab52 100644
> --- a/pppd/pppd.8
> diff --git
> a/patches/ppp-2.4.7/0030-pppd-Use-openssl-for-the-DES-instead-of-the-libcrypt.patch
>
> b/patches/ppp-2.4.7/0030-pppd-Use-openssl-for-the-DES-instead-of-the-libcrypt.patch
> new file mode 100644
> index 0..84b8a3c7f
> --- /dev/null
> +++
> b/patches/ppp-2.4.7/0030-pppd-Use-openssl-for-the-DES-instead-of-the-libcrypt.patch
> @@ -0,0 +1,109 @@
> +From: =?UTF-8?q?Jaroslav=20=C5=A0karvada?=
> +Date: Fri, 6 Apr 2018 14:27:18 +0200
> +Subject: [PATCH] pppd: Use openssl for the DES instead of the libcrypt /
> glibc
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +It seems the latest glibc (in Fedora glibc-2.27.9000-12.fc29) dropped
> +libcrypt. The libxcrypt standalone package can be used instead, but
> +it dropped the old setkey/encrypt API which ppp uses for DES. There
> +is support for using openssl in pppcrypt.c, but it contains typos
> +preventing it from compiling and seems to be written for an ancient
> +openssl version.
> +
> +This updates the code to use current openssl.
> +
> +[pau...@ozlabs.org - wrote the commit description, fixed comment in
> + Makefile.linux.]
> +
> +Signed-off-by: Jaroslav Škarvada
> +Signed-off-by: Paul Mackerras
> +---
> + pppd/Makefile.linux | 7 ---
> + pppd/pppcrypt.c | 18 +-
> + 2 files changed, 13 insertions(+), 12 deletions(-)
> +
> +diff --git a/pppd/Makefile.linux b/pppd/Makefile.linux
> +index f1b2c90bb510..4d536f84c7ba 100644
> +--- a/pppd/Makefile.linux
> b/pppd/Makefile.linux
> +@@ -35,10 +35,10 @@ endif
> + COPTS = -O2 -pipe -Wall -g
> + LIBS =
> +
> +-# Uncomment the next 2 lines to include support for Microsoft's
> ++# Uncomment the next line to include support for Microsoft's
> + # MS-CHAP authentication protocol. Also, edit
> plugins/radius/Makefile.linux.
> + CHAPMS=y
> +-USE_CRYPT=y
Re: [ptxdist] [PATCH] doc: document local_src clean behaviour
On Fri, Jan 18, 2019 at 08:36:42AM +0100, Rouven Czerwinski wrote: > For local_src directories, ptxdist only calls the clean command on a full > clean, > not for a clean with the individual package. Document this in a note for the > workflow. > > Signed-off-by: Rouven Czerwinski > --- > doc/daily_work.inc | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/doc/daily_work.inc b/doc/daily_work.inc > index 47bc987e4..2636336d0 100644 > --- a/doc/daily_work.inc > +++ b/doc/daily_work.inc > @@ -118,6 +118,11 @@ To rebuild the kernel: > jbe@octopus:~/myprj$ ptxdist drop kernel compile > jbe@octopus:~/myprj$ ptxdist targetinstall kernel > > +.. note:: To clean the kernel, change into the local_src directory and call > + ``make clean`` or the clean command for the build system used by the > + package. A ``ptxdist clean kernel`` call will only delete the > + symlinks, but not clean the kernel compiled files. > + I would add a "symlinks in the build directory", to distinguish them from the symlinks in the local_src/ directory. - Roland -- Roland Hieber | r.hie...@pengutronix.de | Pengutronix e.K. | https://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim | Phone: +49-5121-206917-5086 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [ANNOUNCE] OSELAS.Toolchain() 2018.02.0 released - host-m4 build error on Ubuntu 18.10
On Sat, Sep 29, 2018 at 05:57:53PM +0200, Andreas Pretzsch wrote: > During build of the toolchain (at least in configs arm-v7a-linux- > gnueabihf, arm-v7m-eabi, arm-v7em-eabihf) on an Ubuntu 18.10-beta host, > build stopped here with an host-m4 error: > fseeko.c: In function 'rpl_fseeko': > fseeko.c:110:4: error: #error "Please port gnulib fseeko.c to your platform! > Look at the code in fseeko.c, then report this to bug-gnulib." >#error "Please port gnulib fseeko.c to your platform! Look at the code in > fseeko.c, then report this to bug-gnulib." > ^ > GEN charset.alias > make[4]: *** [Makefile:1910: fseeko.o] Error 1 > make[4]: *** Waiting for unfinished jobs > CC vasprintf.o > freadahead.c: In function 'freadahead': > freadahead.c:92:3: error: #error "Please port gnulib freadahead.c to your > platform! Look at the definition of fflush, fread, ungetc on your system, > then report this to bug-gnulib." > #error "Please port gnulib freadahead.c to your platform! Look at the > definition of fflush, fread, ungetc on your system, then report this to > bug-gnulib." >^ > make[4]: *** [Makefile:1910: freadahead.o] Error 1 > > Reason is the glibc 2.28 on the build host (libc6:amd64 2.28-0ubuntu1). > Same probably applies to other distributions. > > In up-to-date ptxdist, there is a patch included fixing this issue: > commit cba1e28 "m4/coreutil: add gnulib patches for GLibc-2.28" from > Rouven Czerwinski, dating 2018-08-23. > With this, m4 is patched accordingly, and build succeeds. > > The OSELAS.Toolchain-2018.02.0 ptxdist project refers to ptxdist- > 2018.02.0 by default. Above patch is part of ptxdist-2018.09.0. > > So until there is a revised version of OSELAS.Toolchain, either use > ptxdist-2018.09.0 or later for building, or include the patch in the > toolchain project. > > @ PTX: This might be worth mentioning in the building instructions or > at a similar place. mol, do you think it is feasible to release a 2018.02.1 toolchain with the host-m4 (and probably other host-glibc related) patches? - Roland -- Roland Hieber | r.hie...@pengutronix.de | Pengutronix e.K. | https://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim | Phone: +49-5121-206917-5086 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH v3 1/2] host-pyhton-scons: add new package
Hi Michael, I have tested it here with a minimal configuration and I fails to build... - target: host-python-scons.compile - ptxdist: executing: cd /home/osterlad/BSPs/OSELAS.BSP-Pengutronix-Generic/platform-sabrelite/build-host/python-scons-3.0.1 && PATH=\/home/osterlad/BSPs/OSELAS.BSP-Pengutronix-Generic/platform- sabrelite/sysroot-host/lib/wrapper:/home/osterlad/BSPs/OSELAS.BSP-Pengutronix-Generic/platform-sabrelite/sysroot-host/bin:/home/osterlad/BSPs/OSELAS.BSP-Pengutronix-Generic/platform-sabrelite/sysroot- host/sbin:/home/osterlad/BSPs/OSELAS.BSP-Pengutronix-Generic/selected_toolchain:/usr/lib/x86_64-linux-gnu/ptxdist- 2018.12.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin PKGCONFIG_WHITELIST_HOST='' PKGCONFIG_WHITELIST_TARGET='' PKGCONFIG_WHITELIST_SRC='host-python-scons' SYSROOT='/home/osterlad/BSPs/OSELAS.BSP-Pengutronix-Generic/platform-sabrelite/sysroot-host' V=1 VERBOSE=1 KBUILD_BUILD_TIMESTAMP=2018-12-01T00:00:00+00:00 KBUILD_BUILD_USER=ptxdist KBUILD_BUILD_HOST=ptxdist enable_option_checking=fatal enable_maintainer_mode=no enable_static=no CC="gcc" CXX="g++" PYTHONPATH="/home/osterlad/BSPs/OSELAS.BSP-Pengutronix- Generic/platform-sabrelite/sysroot-host/lib/python2.7/site-packages" /home/osterlad/BSPs/OSELAS.BSP-Pengutronix-Generic/platform-sabrelite/sysroot-host/bin/python2.7 setup.py build /bin/bash: line 2: /home/osterlad/BSPs/OSELAS.BSP-Pengutronix-Generic/platform-sabrelite/sysroot-host/bin/python2.7: No such file or directory The rules/host-python-setuptools.in selects HOST_PYTHON instead of HOST_SYSTEM_PYTHON as well. I find only "python" as "pkg_conf_tool" in scripts/lib/ptxd_make_world_common.sh. Is there some "_CONF_TOOL := system-python"? Regards Denis Am Donnerstag, den 17.01.2019, 10:53 + schrieb Denis OSTERLAND: > Hi Michael, > > Am Mittwoch, den 16.01.2019, 16:35 +0100 schrieb Michael Olbrich: > > > > On Tue, Jan 15, 2019 at 08:17:39AM +, Denis OSTERLAND wrote: > > > > > > > > > This patch adds support for scons build system. > > > https://scons.org/ > > > > > > Signed-off-by: Denis Osterland > > The prefix is not correct here. It installs everything to .../local/ > strange > on my system it is installed correct > platform-*/sysroot-host/bin/scons > I will try on buster. > > I used rules/host-python-setuptools.make as template. > Does this one gets installed correct on your system? > > Regards Denis > > > > > > > Michael > > Diehl Connectivity Solutions GmbH > Geschäftsführung: Horst Leonberger > Sitz der Gesellschaft: Nürnberg - Registergericht: Amtsgericht > Nürnberg: HRB 32315 > ___ > > Der Inhalt der vorstehenden E-Mail ist nicht rechtlich bindend. Diese E-Mail > enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. > Informieren Sie uns bitte, wenn Sie diese E-Mail faelschlicherweise erhalten > haben. Bitte loeschen Sie in diesem Fall die Nachricht. > Jede unerlaubte Form der Reproduktion, Bekanntgabe, Aenderung, Verteilung > und/oder Publikation dieser E-Mail ist strengstens untersagt. > The contents of the above mentioned e-mail is not legally binding. This > e-mail contains confidential and/or legally protected information. Please > inform us if you have received this e-mail by > mistake and delete it in such a case. Each unauthorized reproduction, > disclosure, alteration, distribution and/or publication of this e-mail is > strictly prohibited. > ___ > ptxdist mailing list > ptxdist@pengutronix.de Diehl Connectivity Solutions GmbH Geschäftsführung: Horst Leonberger Sitz der Gesellschaft: Nürnberg - Registergericht: Amtsgericht Nürnberg: HRB 32315 ___ Der Inhalt der vorstehenden E-Mail ist nicht rechtlich bindend. Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Informieren Sie uns bitte, wenn Sie diese E-Mail faelschlicherweise erhalten haben. Bitte loeschen Sie in diesem Fall die Nachricht. Jede unerlaubte Form der Reproduktion, Bekanntgabe, Aenderung, Verteilung und/oder Publikation dieser E-Mail ist strengstens untersagt. The contents of the above mentioned e-mail is not legally binding. This e-mail contains confidential and/or legally protected information. Please inform us if you have received this e-mail by mistake and delete it in such a case. Each unauthorized reproduction, disclosure, alteration, distribution and/or publication of this e-mail is strictly prohibited. ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] templates: file: update comments and improve wording
On Fri, Jan 18, 2019 at 09:13:01AM +0100, Michael Olbrich wrote: > On Wed, Jan 16, 2019 at 11:22:14AM +0100, Roland Hieber wrote: > > Yes indeed. I'll try to rework it with your comments in mind. Can you > > drop this patch for now, and apply the other two if there are no > > problems with them? > > You mean the two documentation patches, right? I've applied those. Yes, thank you! The mail I replied to was just above the two documentation patches, so I interpreted them as being the same thread. - Roland -- Roland Hieber | r.hie...@pengutronix.de | Pengutronix e.K. | https://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim | Phone: +49-5121-206917-5086 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] doc: document local_src clean behaviour
On Fri, Jan 18, 2019 at 08:36:42AM +0100, Rouven Czerwinski wrote: > For local_src directories, ptxdist only calls the clean command on a full > clean, > not for a clean with the individual package. Document this in a note for the > workflow. > > Signed-off-by: Rouven Czerwinski > --- > doc/daily_work.inc | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/doc/daily_work.inc b/doc/daily_work.inc > index 47bc987e4..2636336d0 100644 > --- a/doc/daily_work.inc > +++ b/doc/daily_work.inc > @@ -118,6 +118,11 @@ To rebuild the kernel: > jbe@octopus:~/myprj$ ptxdist drop kernel compile > jbe@octopus:~/myprj$ ptxdist targetinstall kernel > > +.. note:: To clean the kernel, change into the local_src directory and call > + ``make clean`` or the clean command for the build system used by the > + package. A ``ptxdist clean kernel`` call will only delete the > + symlinks, but not clean the kernel compiled files. Hmm, I think this is a bit misleading. The symlink in local_src/ is not deleted and I think the one in build-target/ is not mentioned in the documentation. Michael > + > Discovering Runtime Dependencies > > > -- > 2.20.1 > > > ___ > ptxdist mailing list > ptxdist@pengutronix.de -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] templates: file: update comments and improve wording
On Wed, Jan 16, 2019 at 11:22:14AM +0100, Roland Hieber wrote: > On Wed, Dec 12, 2018 at 02:35:16PM +0100, Michael Olbrich wrote: > > On Wed, Dec 12, 2018 at 12:29:26AM +0100, Roland Hieber wrote: > > > The way of building target packages has changed over the years, and > > > SYSROOT_TARGET is no longer filled in the install stage. But all of this > > > is also explained in the Reference Manual, so we don't have to duplicate > > > that here. > > > > > > Also add the definition of @PACKAGE@_DIR at the top, which is used in > > > the targetinstall stage later. > > > > > > Signed-off-by: Roland Hieber > > > --- > > > rules/templates/template-file-make | 45 ++ > > > 1 file changed, 9 insertions(+), 36 deletions(-) > > > > > > diff --git a/rules/templates/template-file-make > > > b/rules/templates/template-file-make > > > index ee2a612ef..4e322a39c 100644 > > > --- a/rules/templates/template-file-make > > > +++ b/rules/templates/template-file-make > > > @@ -4,25 +4,27 @@ > > > # > > > # See CREDITS for details about who has contributed to this project. > > > # > > > # For further information about the PTXdist project and license > > > conditions > > > # see the README file. > > > # > > > > > > # > > > # We provide this package > > > # > > > PACKAGES-$(PTXCONF_@PACKAGE@) += @package@ > > > > > > +@PACKAGE@:= @package@ > > > @PACKAGE@_VERSION:= @VERSION@ > > > +@PACKAGE@_DIR:= $(PKGDIR)/$(@PACKAGE@)-$(@PACKAGE@_VERSION) > > > > No, if _DIR is defined then the default compile and install stages are > > no longer no-ops. Change the example in targetinstall to > > install_alternative. > > Yes indeed. I'll try to rework it with your comments in mind. Can you > drop this patch for now, and apply the other two if there are no > problems with them? You mean the two documentation patches, right? I've applied those. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [ANNOUNCE] OSELAS.Toolchain() 2018.12.0 released
Hi,
On Mon, Jan 14, 2019 at 09:04:10AM +, Denis OSTERLAND wrote:
> I have tried to run busybox on STM32F469-disco board, but failed with OSELAS
> 2018.12.0.
> With OSELAS 2018.02.0 it works.
> The kernel complains about a reference to a shared library in the FLAT file.
> I had a look at busybox_unstripped.map to figure out why, but I cant find the
> address modulo page size.
> So I compiled a minimal program (int main() { return 0; }) and used it as
> /sbin/init. Same picture, kernel complains about a reference to a shared
> library.
> Is it possible that there is a bug in uclinux-ng-1.0.31?
>
> Has someone a hint, how to track down this issue?
I think the linker may be a candidate too. The strange thing is, that there
are no shared libraries in the uclibc toolchain.
I've not done anything with with the uclibc toolchains for some time. I've
just updated the versions for this release. I have no idea where else to
look. Maybe start downgrading the individual components to see which one
causes the problem. I'd start with the linker and uclibc.
Michael
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
ptxdist mailing list
ptxdist@pengutronix.de
