Re: [OE-core] Why openembedded-core mailing list is now author of some patches?
On Sat, Mar 23, 2019 at 6:25 AM wrote: > > On Fri, 2019-03-22 at 16:26 -0700, Taras Kondratiuk wrote: > > Quoting Burton, Ross (2018-10-12 07:04:38) > > > On Fri, 12 Oct 2018 at 15:03, Ruslan Bilovol > > > wrote: > > > > > This is basically due to SPF, and people sending email from > > > > > non-authoritive hosts. Concrete example: Richard Purdie's mail > > > > > comes > > > > > from a machine which the linuxfoundation.org SPF records > > > > > doesn't > > > > > recognise as an authorised sender. > > > > > > > > Hmm.. I've just sent an email from rbilo...@cisco.com to another > > > > Gmail > > > > address, and Gmail says SPF checks passed: > > > > SPF: PASS with IP 173.38.203.51 > > > > DKIM: 'PASS' with domain cisco.com > > > > DMARC:'PASS' > > > > > > > > Does it mean oe-core mailing list's software is incorrectly > > > > configured, > > > > or there is something else missing on @cisco.com side? > > > > > > CCing yet more people, specifically Michael Halstead who admins the > > > machines and actually knows what he is talking about (unlike me). > > > > The issue seems to be still there. It doesn't seem to be cisco.com > > specific. I see actia.fr and globallogic.com too: > > https://patchwork.openembedded.org/patch/159446/ > > https://patchwork.openembedded.org/patch/157540/ > > The cause is the same though, the senders are sending from addresses > which the SPF records at those domains say shouldn't be sending emails. > > I'm trying to catch these and fix them up in before committing them. I > thought I had local hooks which would not allow them, clearly the hooks > need more work as things are getting through those filters. > > We are looking at a different email list hosting solution which may > help. Adding "From:" lines directly in the patches where the domains > are problematic would also help. We could also in theory teach mailman > how to do that for patches but its a question of people/time/resources. > Has anyone considered the (perhaps radical?) idea that the sending changes as an email patch series should be replaced? For example, if git.openembedded.org and git.yoctoproject.org were overlaid with Pagure[0] frontends (it uses Gitolite internally, so you can have multiple frontends in place for the same Git repos), it would be easy enough to support pull requests, even from external Git servers. And with that model, OE/Yocto can use CI properly (e.g. using Jenkins, Zuul, or something else) rather than building more hacks on top of emails. Email is getting harder and harder to deal with for handling contributions, and it's only more difficult as mail servers extend and mutate emails as they work to try to combat all kinds of other problems with email these days. [0]: https://pagure.io/pagure -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] musl thoughts
On Sat, Mar 23, 2019 at 10:53 PM Adrian Bunk wrote: > > On Sat, Mar 23, 2019 at 10:22:15PM +0100, Andreas Müller wrote: > > On Sat, Mar 23, 2019 at 10:16 PM Adrian Bunk wrote: > > > > > > On Fri, Mar 22, 2019 at 03:18:01PM -0700, Khem Raj wrote: > > > >... > > > > There are certain design aspects of musl which are actually turning > > > > out to be good > > > > e.g. there is no __MUSL__ define, so non-portable code can not be > > > > hidden which is a good thing, > > > >... > > > > > > Please take a closer look at some of the musl changes to NM that made > > > upgrading NM so hard for Andreas. > > > > > > +#if defined(__GLIBC__) > > > #include > > > +#else /* musl libc */ > > > +#define ETH_ALEN 6 /* Octets in one ethernet addr > > > */ > > > +#endif > > > > > > Using __GLIBC__ in workarounds for bugs in musl is wrong, > > > and cannot be upstreamed since it would do the wrong thing > > > on other non-broken C libraries. > > > > > > > While the eyes may hurt > > > > to see them, it does serve a > > > > good reminder of whats needed for a given package. > > > >... > > > > > > Who is responsible for fixing the root causes of such bugs in musl, > > > so that the workaround patches can be dropped from packages like NM? > > > > > > cu > > > Adrian > > If I am not mistaken nobody is responsible. It is recipe wise: Sending > > out a patch that fails for musl is rejected usually. > > As you have experienced, it does create a huge technical debt to ship > workaround patches in several recipes instead of fixing the bug in musl. > > > The last example could be fixed easily at musl shipping a ethernet.h > > containing > > #define ETH_ALEN 6 > >... > > That's already shipped by musl. > > But there seems to be some incompatibility between musl and the > kernel headers used by musl. > > This has to be sorted out in musl and/or the kernel headers. > Although I did not want to I'll start a musl build to create a cleanup for NM (and maybe) other musl patches. Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] musl thoughts
On Sat, Mar 23, 2019 at 10:22:15PM +0100, Andreas Müller wrote: > On Sat, Mar 23, 2019 at 10:16 PM Adrian Bunk wrote: > > > > On Fri, Mar 22, 2019 at 03:18:01PM -0700, Khem Raj wrote: > > >... > > > There are certain design aspects of musl which are actually turning > > > out to be good > > > e.g. there is no __MUSL__ define, so non-portable code can not be > > > hidden which is a good thing, > > >... > > > > Please take a closer look at some of the musl changes to NM that made > > upgrading NM so hard for Andreas. > > > > +#if defined(__GLIBC__) > > #include > > +#else /* musl libc */ > > +#define ETH_ALEN 6 /* Octets in one ethernet addr */ > > +#endif > > > > Using __GLIBC__ in workarounds for bugs in musl is wrong, > > and cannot be upstreamed since it would do the wrong thing > > on other non-broken C libraries. > > > > > While the eyes may hurt > > > to see them, it does serve a > > > good reminder of whats needed for a given package. > > >... > > > > Who is responsible for fixing the root causes of such bugs in musl, > > so that the workaround patches can be dropped from packages like NM? > > > > cu > > Adrian > If I am not mistaken nobody is responsible. It is recipe wise: Sending > out a patch that fails for musl is rejected usually. As you have experienced, it does create a huge technical debt to ship workaround patches in several recipes instead of fixing the bug in musl. > The last example could be fixed easily at musl shipping a ethernet.h > containing > #define ETH_ALEN 6 >... That's already shipped by musl. But there seems to be some incompatibility between musl and the kernel headers used by musl. This has to be sorted out in musl and/or the kernel headers. > Andreas cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] musl thoughts
On Sat, Mar 23, 2019 at 10:16 PM Adrian Bunk wrote: > > On Fri, Mar 22, 2019 at 03:18:01PM -0700, Khem Raj wrote: > >... > > There are certain design aspects of musl which are actually turning > > out to be good > > e.g. there is no __MUSL__ define, so non-portable code can not be > > hidden which is a good thing, > >... > > Please take a closer look at some of the musl changes to NM that made > upgrading NM so hard for Andreas. > > +#if defined(__GLIBC__) > #include > +#else /* musl libc */ > +#define ETH_ALEN 6 /* Octets in one ethernet addr */ > +#endif > > Using __GLIBC__ in workarounds for bugs in musl is wrong, > and cannot be upstreamed since it would do the wrong thing > on other non-broken C libraries. > > > While the eyes may hurt > > to see them, it does serve a > > good reminder of whats needed for a given package. > >... > > Who is responsible for fixing the root causes of such bugs in musl, > so that the workaround patches can be dropped from packages like NM? > > cu > Adrian If I am not mistaken nobody is responsible. It is recipe wise: Sending out a patch that fails for musl is rejected usually. The last example could be fixed easily at musl shipping a ethernet.h containing #define ETH_ALEN 6 or at NM #ifndef ETH_ALEN #define ETH_ALEN 6 #endif Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] musl thoughts
On Fri, Mar 22, 2019 at 03:18:01PM -0700, Khem Raj wrote: >... > There are certain design aspects of musl which are actually turning > out to be good > e.g. there is no __MUSL__ define, so non-portable code can not be > hidden which is a good thing, >... Please take a closer look at some of the musl changes to NM that made upgrading NM so hard for Andreas. +#if defined(__GLIBC__) #include +#else /* musl libc */ +#define ETH_ALEN 6 /* Octets in one ethernet addr */ +#endif Using __GLIBC__ in workarounds for bugs in musl is wrong, and cannot be upstreamed since it would do the wrong thing on other non-broken C libraries. > While the eyes may hurt > to see them, it does serve a > good reminder of whats needed for a given package. >... Who is responsible for fixing the root causes of such bugs in musl, so that the workaround patches can be dropped from packages like NM? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [OE-Core][PATCH] wget: Convert EXTRA_OECONF to PACKAGECONFIG, extend PACKAGECONFIG
Convert existing EXTRA_OECONF and DEPENDS to PACKAGECONFIG, fill out
remaining PACKAGECONFIG options. Note we pass in --without-libpsl, which
we didn't previously, but all this actually ends up doing is silencing a
warning from the configure script, the code still uses an internal
implemention when using this option.
Signed-off-by: Alex Kiernan
---
meta/recipes-extended/wget/wget.inc | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-extended/wget/wget.inc
b/meta/recipes-extended/wget/wget.inc
index 3cff656a68d9..99af039f417a 100644
--- a/meta/recipes-extended/wget/wget.inc
+++ b/meta/recipes-extended/wget/wget.inc
@@ -3,12 +3,11 @@ HOMEPAGE = "https://www.gnu.org/software/wget/";
SECTION = "console/network"
LICENSE = "GPLv3"
LIC_FILES_CHKSUM = "file://COPYING;md5=c678957b0c8e964aa6c70fd77641a71e"
-DEPENDS = "gnutls zlib libpcre"
inherit autotools gettext texinfo update-alternatives pkgconfig
-EXTRA_OECONF = "--with-ssl=gnutls --disable-rpath --disable-iri \
---without-libgnutls-prefix ac_cv_header_uuid_uuid_h=no"
+EXTRA_OECONF = "--without-libgnutls-prefix --without-libssl-prefix \
+--disable-rpath ac_cv_header_uuid_uuid_h=no"
EXTRA_OEMAKE += 'TOOLCHAIN_OPTIONS="${TOOLCHAIN_OPTIONS}" \
DEBUG_PREFIX_MAP="${DEBUG_PREFIX_MAP}"'
@@ -21,9 +20,17 @@ RRECOMMENDS_${PN} += "ca-certificates"
BBCLASSEXTEND = "nativesdk"
-PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)}"
-PACKAGECONFIG[libuuid] = "--with-libuuid, --without-libuuid,util-linux"
+PACKAGECONFIG ??= "gnutls pcre zlib \
+ ${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)}"
+PACKAGECONFIG[ares] = "--with-cares,,c-ares"
+PACKAGECONFIG[gnutls] = "--with-ssl=gnutls,,gnutls"
PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6,"
+PACKAGECONFIG[iri] = ",--disable-iri,libidn2"
+PACKAGECONFIG[libpsl] = ",--without-libpsl,libpsl"
+PACKAGECONFIG[libuuid] = "--with-libuuid,--without-libuuid,util-linux"
+PACKAGECONFIG[openssl] = "--with-ssl=openssl,,openssl"
+PACKAGECONFIG[pcre] = ",--disable-pcre,libpcre"
+PACKAGECONFIG[zlib] = ",--without-zlib,zlib"
# Let aclocal use the relative path for the m4 file rather than
# absolute, otherwise there might be an "Argument list too long" error
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] musl thoughts
On Fri, Mar 22, 2019 at 03:20:19PM -0700, Khem Raj wrote: > On Fri, Mar 22, 2019 at 1:03 PM Adrian Bunk wrote: > > > > On Fri, Mar 22, 2019 at 02:11:35AM +0100, Andreas Müller wrote: > > >... > > > 3. Change our musl slightly: Many patches we currently have are > > > trivial. Missing headers or #defines for missing functions... So if we > > > add few headers > > > * Empty chunks for e.g > > >... > > > Some other ideas? > > > > Not upstreamable hacks aren't a long-term sustainable way, > > no matter where you do the patching. > > > > net/ethernet.h header problems are requiring 2 patches in NM. > > > > It would be good to get whatever is the actual root cause fixed properly, > > and that fix upstreamed. > > > > E.g. I wonder whether this was supposed to be fixed by > > 0001-if_ether-move-muslc-ethhdr-protection-to-uapi-file.patch > > > > Or is this patch in linux-libc-headers even the cause of the problem? > > > > linux-libc-headers applying 6 patches just for musl is not a good sign > > in any case. > > Is that much patching also done by other distributions that use musl? > > Why are these patches Upstream-Status: Pending/Submitted for a long > > time without having been applied upstream? > > > > Long-term it would be less work if everything would get fixed properly > > with fixes reviewed and applied by upstream. > > agreed, meanwhile we have to also ensure that musl users keep going and make > it > possible, if OE devs are fixing musl related issues in upstream > packages then it is also good reputation for the project. >... Some of the NM patches are obviously just quick hacks to workaround bugs that are elsewhere. Trying to push such stuff upstream would not exactly improve the reputation. A problem with a "keep going" approach is that you might end up spending much work on working around symptoms, or even working around OE-specific bugs without noticing that they are OE-specific. Building an image (with things like NM included) for musl builds for me, and it also builds for me with all 6 musl patches not applied to the kernel headers. Are these patches still required at all? Could they be the cause of other musl related issues in OE? Patching leaf packages can create a huge mess if the core packages are not in a good state. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] ninja: update to 1.9.0
Signed-off-by: Oleksandr Kravchuk
---
.../ninja/ninja/fix-musl.patch| 39 +++
.../ninja/{ninja_1.8.2.bb => ninja_1.9.0.bb} | 6 ++-
2 files changed, 43 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-devtools/ninja/ninja/fix-musl.patch
rename meta/recipes-devtools/ninja/{ninja_1.8.2.bb => ninja_1.9.0.bb} (87%)
diff --git a/meta/recipes-devtools/ninja/ninja/fix-musl.patch
b/meta/recipes-devtools/ninja/ninja/fix-musl.patch
new file mode 100644
index 00..543d4f1c48
--- /dev/null
+++ b/meta/recipes-devtools/ninja/ninja/fix-musl.patch
@@ -0,0 +1,39 @@
+2ff54ad7478a90bd75c91e434236a Mon Sep 17 00:00:00 2001
+From: makepost
+Date: Mon, 24 Dec 2018 03:13:16 +0200
+Subject: [PATCH] Use st_mtim if st_mtime is macro, fix #1510
+
+In POSIX.1-2008, sys_stat has a st_mtim member and a st_mtime backward
+compatibility macro. Should help avoid hardcoding platform detection.
+---
+ src/disk_interface.cc | 14 --
+ 1 file changed, 4 insertions(+), 10 deletions(-)
+
+diff --git a/src/disk_interface.cc b/src/disk_interface.cc
+index d4c2fb087..dc297c449 100644
+--- src/disk_interface.cc
/src/disk_interface.cc
+@@ -202,19 +202,13 @@ TimeStamp RealDiskInterface::Stat(const string& path,
string* err) const {
+ // that it doesn't exist.
+ if (st.st_mtime == 0)
+ return 1;
+-#if defined(__APPLE__) && !defined(_POSIX_C_SOURCE)
++#if defined(_AIX)
++ return (int64_t)st.st_mtime * 10LL + st.st_mtime_n;
++#elif defined(__APPLE__)
+ return ((int64_t)st.st_mtimespec.tv_sec * 10LL +
+ st.st_mtimespec.tv_nsec);
+-#elif (_POSIX_C_SOURCE >= 200809L || _XOPEN_SOURCE >= 700 ||
defined(_BSD_SOURCE) || defined(_SVID_SOURCE) || \
+- defined(__BIONIC__) || (defined (__SVR4) && defined (__sun)) ||
defined(__FreeBSD__))
+- // For glibc, see "Timestamp files" in the Notes of
http://www.kernel.org/doc/man-pages/online/pages/man2/stat.2.html
+- // newlib, uClibc and musl follow the kernel (or Cygwin) headers and define
the right macro values above.
+- // For bsd, see
https://github.com/freebsd/freebsd/blob/master/sys/sys/stat.h and similar
+- // For bionic, C and POSIX API is always enabled.
+- // For solaris, see
https://docs.oracle.com/cd/E88353_01/html/E37841/stat-2.html.
++#elif defined(st_mtime) // A macro, so we're likely on modern POSIX.
+ return (int64_t)st.st_mtim.tv_sec * 10LL + st.st_mtim.tv_nsec;
+-#elif defined(_AIX)
+- return (int64_t)st.st_mtime * 10LL + st.st_mtime_n;
+ #else
+ return (int64_t)st.st_mtime * 10LL + st.st_mtimensec;
+ #endif
diff --git a/meta/recipes-devtools/ninja/ninja_1.8.2.bb
b/meta/recipes-devtools/ninja/ninja_1.9.0.bb
similarity index 87%
rename from meta/recipes-devtools/ninja/ninja_1.8.2.bb
rename to meta/recipes-devtools/ninja/ninja_1.9.0.bb
index c6fcfef3dd..1b06328961 100644
--- a/meta/recipes-devtools/ninja/ninja_1.8.2.bb
+++ b/meta/recipes-devtools/ninja/ninja_1.9.0.bb
@@ -5,9 +5,11 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=a81586a64ad4e476c791cda7e2f2c52e"
DEPENDS = "re2c-native ninja-native"
-SRCREV = "253e94c1fa511704baeb61cf69995bbf09ba435e"
+SRCREV = "b25c08bda4949192c69cea4cee057887341a2ffc"
-SRC_URI = "git://github.com/ninja-build/ninja.git;branch=release"
+SRC_URI = "git://github.com/ninja-build/ninja.git;branch=release \
+ file://fix-musl.patch \
+"
UPSTREAM_CHECK_GITTAGREGEX = "v(?P.*)"
S = "${WORKDIR}/git"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] ninja: upate to 1.9.0
Signed-off-by: Oleksandr Kravchuk
---
.../ninja/ninja/fix-musl.patch| 39 +++
.../ninja/{ninja_1.8.2.bb => ninja_1.9.0.bb} | 6 ++-
2 files changed, 43 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-devtools/ninja/ninja/fix-musl.patch
rename meta/recipes-devtools/ninja/{ninja_1.8.2.bb => ninja_1.9.0.bb} (87%)
diff --git a/meta/recipes-devtools/ninja/ninja/fix-musl.patch
b/meta/recipes-devtools/ninja/ninja/fix-musl.patch
new file mode 100644
index 00..543d4f1c48
--- /dev/null
+++ b/meta/recipes-devtools/ninja/ninja/fix-musl.patch
@@ -0,0 +1,39 @@
+2ff54ad7478a90bd75c91e434236a Mon Sep 17 00:00:00 2001
+From: makepost
+Date: Mon, 24 Dec 2018 03:13:16 +0200
+Subject: [PATCH] Use st_mtim if st_mtime is macro, fix #1510
+
+In POSIX.1-2008, sys_stat has a st_mtim member and a st_mtime backward
+compatibility macro. Should help avoid hardcoding platform detection.
+---
+ src/disk_interface.cc | 14 --
+ 1 file changed, 4 insertions(+), 10 deletions(-)
+
+diff --git a/src/disk_interface.cc b/src/disk_interface.cc
+index d4c2fb087..dc297c449 100644
+--- src/disk_interface.cc
/src/disk_interface.cc
+@@ -202,19 +202,13 @@ TimeStamp RealDiskInterface::Stat(const string& path,
string* err) const {
+ // that it doesn't exist.
+ if (st.st_mtime == 0)
+ return 1;
+-#if defined(__APPLE__) && !defined(_POSIX_C_SOURCE)
++#if defined(_AIX)
++ return (int64_t)st.st_mtime * 10LL + st.st_mtime_n;
++#elif defined(__APPLE__)
+ return ((int64_t)st.st_mtimespec.tv_sec * 10LL +
+ st.st_mtimespec.tv_nsec);
+-#elif (_POSIX_C_SOURCE >= 200809L || _XOPEN_SOURCE >= 700 ||
defined(_BSD_SOURCE) || defined(_SVID_SOURCE) || \
+- defined(__BIONIC__) || (defined (__SVR4) && defined (__sun)) ||
defined(__FreeBSD__))
+- // For glibc, see "Timestamp files" in the Notes of
http://www.kernel.org/doc/man-pages/online/pages/man2/stat.2.html
+- // newlib, uClibc and musl follow the kernel (or Cygwin) headers and define
the right macro values above.
+- // For bsd, see
https://github.com/freebsd/freebsd/blob/master/sys/sys/stat.h and similar
+- // For bionic, C and POSIX API is always enabled.
+- // For solaris, see
https://docs.oracle.com/cd/E88353_01/html/E37841/stat-2.html.
++#elif defined(st_mtime) // A macro, so we're likely on modern POSIX.
+ return (int64_t)st.st_mtim.tv_sec * 10LL + st.st_mtim.tv_nsec;
+-#elif defined(_AIX)
+- return (int64_t)st.st_mtime * 10LL + st.st_mtime_n;
+ #else
+ return (int64_t)st.st_mtime * 10LL + st.st_mtimensec;
+ #endif
diff --git a/meta/recipes-devtools/ninja/ninja_1.8.2.bb
b/meta/recipes-devtools/ninja/ninja_1.9.0.bb
similarity index 87%
rename from meta/recipes-devtools/ninja/ninja_1.8.2.bb
rename to meta/recipes-devtools/ninja/ninja_1.9.0.bb
index c6fcfef3dd..1b06328961 100644
--- a/meta/recipes-devtools/ninja/ninja_1.8.2.bb
+++ b/meta/recipes-devtools/ninja/ninja_1.9.0.bb
@@ -5,9 +5,11 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=a81586a64ad4e476c791cda7e2f2c52e"
DEPENDS = "re2c-native ninja-native"
-SRCREV = "253e94c1fa511704baeb61cf69995bbf09ba435e"
+SRCREV = "b25c08bda4949192c69cea4cee057887341a2ffc"
-SRC_URI = "git://github.com/ninja-build/ninja.git;branch=release"
+SRC_URI = "git://github.com/ninja-build/ninja.git;branch=release \
+ file://fix-musl.patch \
+"
UPSTREAM_CHECK_GITTAGREGEX = "v(?P.*)"
S = "${WORKDIR}/git"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] ninja: upate to 1.9.0
Alright, I have fixed the musl build.
doxygen issue will require changes to doxygen itself:
https://github.com/doxygen/doxygen/pull/712
On 22/03/2019 22:51, Khem Raj wrote:
> On Fri, Mar 22, 2019 at 4:44 AM Richard Purdie
> wrote:
>> On Thu, 2019-03-21 at 00:05 +0100, Oleksandr Kravchuk wrote:
>>> Signed-off-by: Oleksandr Kravchuk >> ---
>>> meta/recipes-devtools/ninja/{ninja_1.8.2.bb => ninja_1.9.0.bb} | 2
>>> +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> rename meta/recipes-devtools/ninja/{ninja_1.8.2.bb =>
>>> ninja_1.9.0.bb} (92%)
>> Fails to build on musl:
>>
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/423
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/424
>>
> doxygen fails too
>
> https://errors.yoctoproject.org/Errors/Details/234025/
>
>> Cheers,
>>
>> Richard
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Why openembedded-core mailing list is now author of some patches?
On Fri, 2019-03-22 at 16:26 -0700, Taras Kondratiuk wrote: > Quoting Burton, Ross (2018-10-12 07:04:38) > > On Fri, 12 Oct 2018 at 15:03, Ruslan Bilovol > > wrote: > > > > This is basically due to SPF, and people sending email from > > > > non-authoritive hosts. Concrete example: Richard Purdie's mail > > > > comes > > > > from a machine which the linuxfoundation.org SPF records > > > > doesn't > > > > recognise as an authorised sender. > > > > > > Hmm.. I've just sent an email from rbilo...@cisco.com to another > > > Gmail > > > address, and Gmail says SPF checks passed: > > > SPF: PASS with IP 173.38.203.51 > > > DKIM: 'PASS' with domain cisco.com > > > DMARC:'PASS' > > > > > > Does it mean oe-core mailing list's software is incorrectly > > > configured, > > > or there is something else missing on @cisco.com side? > > > > CCing yet more people, specifically Michael Halstead who admins the > > machines and actually knows what he is talking about (unlike me). > > The issue seems to be still there. It doesn't seem to be cisco.com > specific. I see actia.fr and globallogic.com too: > https://patchwork.openembedded.org/patch/159446/ > https://patchwork.openembedded.org/patch/157540/ The cause is the same though, the senders are sending from addresses which the SPF records at those domains say shouldn't be sending emails. I'm trying to catch these and fix them up in before committing them. I thought I had local hooks which would not allow them, clearly the hooks need more work as things are getting through those filters. We are looking at a different email list hosting solution which may help. Adding "From:" lines directly in the patches where the domains are problematic would also help. We could also in theory teach mailman how to do that for patches but its a question of people/time/resources. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
