openembedded-core.git/meta/recipes-connectivity/avahi, branch thud Mirror of openembedded-core avahi: fix CVE-2017-6519 2019-04-13T19:58:01+00:00 Kai Kang kai.kang@windriver.com 2019-04-02T07:44:26+00:00 cf787f8eab1c85dbafb5e74bf12eb4ddb5c5cbf7 Backport patch to fix CVE-2017-6519. CVE: CVE-2017-6519 Signed-off-by: Kai Kang <kai.kang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> 
Backport patch to fix CVE-2017-6519.

CVE: CVE-2017-6519

Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
avahi: avoid depending on skipped package 2019-02-25T22:25:05+00:00 Jens Rehsack sno@netbsd.org 2018-11-28T08:15:30+00:00 0e65ddb5873c6d32ae3c8e86b269ada730cf6e9c When built without D-Bus, libavahi-client is not build: Building libavahi-client: no (You need avahi-daemon and D-Bus!) which causes avahi-dev RDEPENDS failing when creating an image containing development-tools: * - nothing provides libavahi-client = 0.7-r0 needed by avahi-dev-0.7-r0.cortexa8hf-neon (From OE-Core rev: 319532792435be73e96c8319e90336e1298ac2a1) Signed-off-by: Jens Rehsack <sno@netbsd.org> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> 
When built without D-Bus, libavahi-client is not build:
  Building libavahi-client:           no   (You need avahi-daemon and D-Bus!)
which causes avahi-dev RDEPENDS failing when creating an image
containing development-tools:
 *   - nothing provides libavahi-client = 0.7-r0 needed by avahi-dev-0.7-r0.cortexa8hf-neon

(From OE-Core rev: 319532792435be73e96c8319e90336e1298ac2a1)

Signed-off-by: Jens Rehsack <sno@netbsd.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
avahi: fix error at boot time for avahi-daemon.service 2018-06-27T12:53:28+00:00 Chen Qi Qi.Chen@windriver.com 2018-06-21T06:00:23+00:00 647db1d9eb65b225ffbb6953f796232026bfa935 The following error messages appear now and then at boot time. avahi-daemon/chroot.c: open() failed: No such file or directory Failed to open /etc/resolv.conf: Invalid argument The problem is about /etc/resolv.conf. In Yocto's systemd based systems, it's a symlink to /etc/resolv-conf.systemd which in turn is a symlink to /run/systemd/resolve/resolv.conf. The systemd-resolved service handles creation of /run/systemd/resolve/resolv.conf file. So if avahi-daemon is started before systemd-resolved, the error messages appear. Fix this problem by making avahi-daemon start after systemd-resolved. Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
The following error messages appear now and then at boot time.

  avahi-daemon/chroot.c: open() failed: No such file or directory
  Failed to open /etc/resolv.conf: Invalid argument

The problem is about /etc/resolv.conf. In Yocto's systemd based
systems, it's a symlink to /etc/resolv-conf.systemd which in turn
is a symlink to /run/systemd/resolve/resolv.conf. The systemd-resolved
service handles creation of /run/systemd/resolve/resolv.conf file.

So if avahi-daemon is started before systemd-resolved, the error messages
appear.

Fix this problem by making avahi-daemon start after systemd-resolved.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
avahi: reorganize codes 2018-06-27T12:53:28+00:00 Chen Qi Qi.Chen@windriver.com 2018-06-21T06:00:22+00:00 75529d384bfeaf52befccb892cf41f22dc02668b This patch does nothing but reorganizing codes. avahi.inc is shared by avahi and avahi-ui recipes. Move common things into it, and move uncommon things out of it. Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
This patch does nothing but reorganizing codes.

avahi.inc is shared by avahi and avahi-ui recipes. Move common things
into it, and move uncommon things out of it.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
avahi: refresh patches 2018-03-11T13:25:20+00:00 Ross Burton ross.burton@intel.com 2018-03-09T18:55:42+00:00 6c0329389ffd82552c9302d70c8b2a1dfc94ce00 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 <ross.burton@intel.com> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
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 <ross.burton@intel.com>
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
avahi: remove explicit avahi-dev RDEPENDS 2018-01-09T11:45:20+00:00 Ross Burton ross.burton@intel.com 2018-01-08T15:53:19+00:00 00ae3e03185f1044f3610dc7ba7da7bd3beb868a These were added to the avahi-dev package back in 2011 before avahi-ui existed at all. The problem of GTK+ being pulled in via avahi-dev was finally solved with the avahi-ui split, so these explicit (and by being manually maintained, incomplete) dependencies can be removed. This also results in gettext-dev being removed from the dependency tree (the gettext library API is provided by glibc/musl), which means that for a standard image we don't need to build target gettext at all anymore. Signed-off-by: Ross Burton <ross.burton@intel.com> 
These were added to the avahi-dev package back in 2011 before avahi-ui existed
at all.  The problem of GTK+ being pulled in via avahi-dev was finally solved
with the avahi-ui split, so these explicit (and by being manually maintained,
incomplete) dependencies can be removed.

This also results in gettext-dev being removed from the dependency tree (the
gettext library API is provided by glibc/musl), which means that for a standard
image we don't need to build target gettext at all anymore.

Signed-off-by: Ross Burton <ross.burton@intel.com>
avahi: upgrade to 0.7 2018-01-02T17:24:12+00:00 Dengke Du dengke.du@windriver.com 2017-12-12T01:46:23+00:00 80b408ae48eb091fc2af8b1570a7aac3cdc0b009 Delete the unneeded patch, because the upstream contains the needed changes. The new version of avahi 0.7 use "/run" directory to place some run-time variable data, not /var/run, so in avahi.inc, we should remove the "/run" not "/var/run". Remove PACKAGECONFIG for pygtk which already dropped in upstream. Signed-off-by: Dengke Du <dengke.du@windriver.com> Signed-off-by: Yi Zhao <yi.zhao@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
Delete the unneeded patch, because the upstream contains the needed changes.
The new version of avahi 0.7 use "/run" directory to place some run-time
variable data, not /var/run, so in avahi.inc, we should remove the "/run"
not "/var/run".

Remove PACKAGECONFIG for pygtk which already dropped in upstream.

Signed-off-by: Dengke Du <dengke.du@windriver.com>
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
avahi-ui: reduce local pending patches 2017-07-06T13:38:09+00:00 Dengke Du dengke.du@windriver.com 2017-07-05T08:33:29+00:00 9e18fc1aa4aa0ead854bb4e02eb3af2e7909f597 [Yocto #11548] Signed-off-by: Dengke Du <dengke.du@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
[Yocto #11548]

Signed-off-by: Dengke Du <dengke.du@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
meta: Drop remnants of uclibc support 2017-06-16T09:58:25+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2017-06-15T14:21:42+00:00 653704e9cf325cb494eb23facca19e9f05132ffd 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 <richard.purdie@linuxfoundation.org> 
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 <richard.purdie@linuxfoundation.org>
avahi: Don't remove users/groups in postrm 2016-11-01T10:10:04+00:00 Jussi Kukkonen jussi.kukkonen@intel.com 2016-10-31T13:40:17+00:00 c1be2196e7ffb23b7b243ecd8aca1827cbdfa443 There's no way to ensure that files owned by the users aren't left on the system at postrm time: Removing the user would mean those files are now owned by a non-existing user, and later may be owned by a completely unrelated new user. [YOCTO #10442] Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
There's no way to ensure that files owned by the users aren't left
on the system at postrm time: Removing the user would mean those
files are now owned by a non-existing user, and later may be owned
by a completely unrelated new user.

[YOCTO #10442]

Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>