<feed xmlns='http://www.w3.org/2005/Atom'>
<title>openembedded-core.git/meta/recipes-devtools/m4, branch thud</title>
<subtitle>Mirror of openembedded-core</subtitle>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/'/>
<entry>
<title>m4: Workaround gnulib's fseeko.c implementation</title>
<updated>2018-08-08T09:51:28+00:00</updated>
<author>
<name>Khem Raj</name>
<email>raj.khem@gmail.com</email>
</author>
<published>2018-08-06T22:57:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=acca7f964bf9c21f3777085563a7928b8246f17f'/>
<id>acca7f964bf9c21f3777085563a7928b8246f17f</id>
<content type='text'>
exposed by glibc 2.28 for details see
https://lists.gnu.org/r/bug-gnulib/2018-03/msg00000.html

Signed-off-by: Khem Raj &lt;raj.khem@gmail.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
exposed by glibc 2.28 for details see
https://lists.gnu.org/r/bug-gnulib/2018-03/msg00000.html

Signed-off-by: Khem Raj &lt;raj.khem@gmail.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>m4: refresh patches</title>
<updated>2018-03-11T13:25:21+00:00</updated>
<author>
<name>Ross Burton</name>
<email>ross.burton@intel.com</email>
</author>
<published>2018-03-09T18:55:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=87118e6a2ed6da1ceaf484c326ec6d0ac8c1b8be'/>
<id>87118e6a2ed6da1ceaf484c326ec6d0ac8c1b8be</id>
<content type='text'>
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.

Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450).  This is obviously bad.

We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.

Signed-off-by: Ross Burton &lt;ross.burton@intel.com&gt;
Signed-off-by: Alexander Kanavin &lt;alexander.kanavin@linux.intel.com&gt;
Signed-off-by: Ross Burton &lt;ross.burton@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.

Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450).  This is obviously bad.

We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.

Signed-off-by: Ross Burton &lt;ross.burton@intel.com&gt;
Signed-off-by: Alexander Kanavin &lt;alexander.kanavin@linux.intel.com&gt;
Signed-off-by: Ross Burton &lt;ross.burton@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>m4: Add missing append whitespace</title>
<updated>2018-01-13T14:53:02+00:00</updated>
<author>
<name>Richard Purdie</name>
<email>richard.purdie@linuxfoundation.org</email>
</author>
<published>2018-01-13T14:52:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=33116dfc018fd387fa70131dcabc653745c32fde'/>
<id>33116dfc018fd387fa70131dcabc653745c32fde</id>
<content type='text'>
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>m4: merge two .inc files</title>
<updated>2018-01-09T11:45:20+00:00</updated>
<author>
<name>Ross Burton</name>
<email>ross.burton@intel.com</email>
</author>
<published>2018-01-08T12:48:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=a67391afd7fe8b7dc40e49c66cfd6250a077361c'/>
<id>a67391afd7fe8b7dc40e49c66cfd6250a077361c</id>
<content type='text'>
Now that oe-core only has one copy of m4, there's no need to maintain two inc
files.

Signed-off-by: Ross Burton &lt;ross.burton@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now that oe-core only has one copy of m4, there's no need to maintain two inc
files.

Signed-off-by: Ross Burton &lt;ross.burton@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>m4-native: fix upstream version check</title>
<updated>2017-12-02T11:24:37+00:00</updated>
<author>
<name>Alexander Kanavin</name>
<email>alexander.kanavin@linux.intel.com</email>
</author>
<published>2017-11-22T16:32:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=cfdee980fe48a081c489ff3e1bfd5d0b149c5e8f'/>
<id>cfdee980fe48a081c489ff3e1bfd5d0b149c5e8f</id>
<content type='text'>
Signed-off-by: Alexander Kanavin &lt;alexander.kanavin@linux.intel.com&gt;
Signed-off-by: Ross Burton &lt;ross.burton@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Alexander Kanavin &lt;alexander.kanavin@linux.intel.com&gt;
Signed-off-by: Ross Burton &lt;ross.burton@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>m4: Add HOMEPAGE info into recipe file.</title>
<updated>2017-09-13T20:59:57+00:00</updated>
<author>
<name>Huang Qiyu</name>
<email>huangqy.fnst@cn.fujitsu.com</email>
</author>
<published>2017-09-12T07:51:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=7ccb76ff4644194bb20159affe9d573695205e63'/>
<id>7ccb76ff4644194bb20159affe9d573695205e63</id>
<content type='text'>
Signed-off-by: Huang Qiyu &lt;huangqy.fnst@cn.fujitsu.com&gt;
Signed-off-by: Ross Burton &lt;ross.burton@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Huang Qiyu &lt;huangqy.fnst@cn.fujitsu.com&gt;
Signed-off-by: Ross Burton &lt;ross.burton@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>meta: Drop remnants of uclibc support</title>
<updated>2017-06-16T09:58:25+00:00</updated>
<author>
<name>Richard Purdie</name>
<email>richard.purdie@linuxfoundation.org</email>
</author>
<published>2017-06-15T14:21:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=653704e9cf325cb494eb23facca19e9f05132ffd'/>
<id>653704e9cf325cb494eb23facca19e9f05132ffd</id>
<content type='text'>
uclibc support was removed a while ago and musl works much better. Start to
remove the various overrides and patches related to uclibc which are no longer
needed.

uclibc support in a layer would still be possible. I have strong reasons to
believe nobody is still using uclibc since patches are missing and I doubt
the metadata even parses anymore.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
uclibc support was removed a while ago and musl works much better. Start to
remove the various overrides and patches related to uclibc which are no longer
needed.

uclibc support in a layer would still be possible. I have strong reasons to
believe nobody is still using uclibc since patches are missing and I doubt
the metadata even parses anymore.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>m4: do_configure: fix "Argument list too long"</title>
<updated>2017-04-08T21:48:05+00:00</updated>
<author>
<name>Robert Yang</name>
<email>liezhi.yang@windriver.com</email>
</author>
<published>2017-04-06T10:05:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=7e8fece3a09bed18bc72c529b8b471ccbc144bf5'/>
<id>7e8fece3a09bed18bc72c529b8b471ccbc144bf5</id>
<content type='text'>
Fixed when len(TMPDIR) =  410:
Can't exec "/bin/sh": Argument list too long at /usr/lib/perl/5.18/IO/File.pm line 65.

This is becuase it has a lot of m4 files, use relative path for them
can fix the problem.

Signed-off-by: Robert Yang &lt;liezhi.yang@windriver.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fixed when len(TMPDIR) =  410:
Can't exec "/bin/sh": Argument list too long at /usr/lib/perl/5.18/IO/File.pm line 65.

This is becuase it has a lot of m4 files, use relative path for them
can fix the problem.

Signed-off-by: Robert Yang &lt;liezhi.yang@windriver.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>recipes: Move out stale GPLv2 versions to a seperate layer</title>
<updated>2017-03-07T20:04:58+00:00</updated>
<author>
<name>Richard Purdie</name>
<email>richard.purdie@linuxfoundation.org</email>
</author>
<published>2017-03-02T12:04:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=19b7e950346fb1dde6505c45236eba6cd9b33b4b'/>
<id>19b7e950346fb1dde6505c45236eba6cd9b33b4b</id>
<content type='text'>
These are recipes where the upstream has moved to GPLv3 and these old
versions are the last ones under the GPLv2 license.

There are several reasons for making this move. There is a different
quality of service with these recipes in that they don't get security
fixes and upstream no longer care about them, in fact they're actively
hostile against people using old versions. The recipes tend to need a
different kind of maintenance to work with changes in the wider ecosystem
and there needs to be isolation between changes made in the v3 versions
and those in the v2 versions.

There are probably better ways to handle a "non-GPLv3" system but right
now having these in OE-Core makes them look like a first class citizen
when I believe they have potential for a variety of undesireable issues.

Moving them into a separate layer makes their different needs clearer, it
also makes it clear how many of these there are. Some are probably not
needed (e.g. mc), I also wonder whether some are useful (e.g. gmp)
since most things that use them are GPLv3 only already. Someone could
now more clearly see how to streamline the list of recipes here.

I'm proposing we mmove to this separate layer for 2.3 with its future
maintinership and testing to be determined in 2.4 and beyond.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
These are recipes where the upstream has moved to GPLv3 and these old
versions are the last ones under the GPLv2 license.

There are several reasons for making this move. There is a different
quality of service with these recipes in that they don't get security
fixes and upstream no longer care about them, in fact they're actively
hostile against people using old versions. The recipes tend to need a
different kind of maintenance to work with changes in the wider ecosystem
and there needs to be isolation between changes made in the v3 versions
and those in the v2 versions.

There are probably better ways to handle a "non-GPLv3" system but right
now having these in OE-Core makes them look like a first class citizen
when I believe they have potential for a variety of undesireable issues.

Moving them into a separate layer makes their different needs clearer, it
also makes it clear how many of these there are. Some are probably not
needed (e.g. mc), I also wonder whether some are useful (e.g. gmp)
since most things that use them are GPLv3 only already. Someone could
now more clearly see how to streamline the list of recipes here.

I'm proposing we mmove to this separate layer for 2.3 with its future
maintinership and testing to be determined in 2.4 and beyond.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>m4: 1.4.17 -&gt; 1.4.18</title>
<updated>2017-02-16T04:06:32+00:00</updated>
<author>
<name>Robert Yang</name>
<email>liezhi.yang@windriver.com</email>
</author>
<published>2017-02-10T03:23:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=d87a41d2dc611259989cb1252c34d0c6ef802971'/>
<id>d87a41d2dc611259989cb1252c34d0c6ef802971</id>
<content type='text'>
Rebased remove-gets.patch.

Signed-off-by: Robert Yang &lt;liezhi.yang@windriver.com&gt;
Signed-off-by: Ross Burton &lt;ross.burton@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Rebased remove-gets.patch.

Signed-off-by: Robert Yang &lt;liezhi.yang@windriver.com&gt;
Signed-off-by: Ross Burton &lt;ross.burton@intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
