remove some more unneeded checks

remove some unneeded tests

require C99

move the rtnetlink.h/C99 check and always fail configure if it fails

AC_HEADER_STDC is officially obsolescent

use AC_LANG_SOURCE to silence warnings from autoconf

we don't need the C preprocessor on its own

we don't need the C++ compiler

always build core docs

get rid of autogen.sh and bootstrap.sh

enable config.publish_no_reverse in examples/core-publish-service to allow friendly coexistence with a running avahi daemon

let core-browse example look for the type used by core-publish example

call ./configure from bootstrap.sh

put some useful info into the README

remove unneeded and per-user cruft from bootstrap.sh

add some ignores

kill some more references to removed stuff

./configure doesn't belong in autogen.sh

remove i18n from the build alltogether

make avahi_init_i18n a no-op when compiling without NLS

don't require GETTEXT_PACKAGE unless compiling with ENABLE_NLS

remove references to removed components from po/POTFILES.in

remove all but avahi-common and avahi-core and adjust build system accordingly

fix avahi_netlink_new to allow multiple netlinks per process

publish_no_reverse configuration flag added

workaround: disable PTR records for local interfaces to make it compatible with concurrently running mdns instances

avahi-daemon: add option "host-name-from-machine-id="

Signed-off-by: David Zeuthen <zeuthen@chromium.org>

avahi-common: typo fix

build-sys: fix previous commit for recent automake

build-sys: fix parallel install in avahi-utils

The moment install-exec-local is called, we might still not have
created ${DESTDIR}/${bindir} so we should make sure to create it
first, and then try to chdir into it.

build-sys: fix MKDIR_P for recent automake

core: don't leak hinfo/workstation even if the configuration file doesn't exist

avahi-daemon: don't leak host info by default

avahi-daemon: don't add 0pointer.de and zeroconf.org to default browse list

build-sys: actually, we need to place the service type database in lib64, not unconditionally in lib/

gdbm creates word width dependent files, hence this needs to be included
in the multi-arch logic.

update NEWS

build-sys: prepare release

build-sys: compatibility with newer automake

Place the service type database in $(prefix)/lib/avahi instead of
$(libdir)/avahi.

systemd: syslog.target is not longer useful

database: add Mumble to service type database

http://mumble.sourceforge.net/

doc,build-sys: prepare new release

socket: minor beautification

iface: use interface values only when valid

https://bugzilla.redhat.com/show_bug.cgi?id=690416

i18n: run make update-po

Merge remote-tracking branch 'origin/master-tx'

avahi-discover: Fix type being inserted into tree model (Bug #332)

iface: look for both IFA_ADDRESS and IFA_LOCAL

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617948
http://avahi.org/ticket/333

systemd: fix sd_is_socket() invocation

general: various smaller fixes

systemd: drop ExecReload= line since avahi-dnsconfd -r is not actually a config reload

update README

build-sys: update package version and soname

systemd: update sd-daemon.[ch]

l10n: Updated Finnish (fi) translation to 99%

New status: 164 messages complete with 1 fuzzy and 0 untranslated.

Transmitted-via: Transifex (www.transifex.net).

l10n: Updated Catalan (ca) translation to 100%

New status: 165 messages complete with 0 fuzzies and 0 untranslated.

Transmitted-via: Transifex (www.transifex.net).

l10n: Updated Malay (ms) translation to 24%

New status: 40 messages complete with 68 fuzzies and 57 untranslated.

Transmitted-via: Transifex (www.transifex.net).

chroot: suppress error messages if the chroot pipe is closed

core: avahi on Linux uses incorrect address for P-t-P interface

Hi,

I sent a less knowledgeable question about avahi-daemon and
point-to-point links a few days ago,
http://lists.freedesktop.org/archives/avahi/2011-January/001969.html.
When I didn't get a response to this, I decided to build avahi from
source and step through it and see how it builds its list of interfaces
and their addresses.

This is in iface-linux.c, netlink_callback(). It looks for a RTM_NEWADDR
message, then extracts the payload of type IFA_ADDRESS.

Short story: I think it should be using the payload of type IFA_LOCAL,
not the payload of type IFA_ADDRESS.

In the VM where I was running these experiments, there are 3 interfaces
-- lo, eth0 and tun0. I printed out the IFA_ADDRESS and IFA_LOCAL for
all 3 of these; for lo and eth0 these are the same address; for tun0
(IFF_POINTOPOINT), IFA_ADDRESS is the remote end and IFA_LOCAL is the
local end.

I'm no expert on Linux rtnetlink or these IFA fields, but quoting
/usr/include/linux/if_addr.h:

/*
 * Important comment:
 * IFA_ADDRESS is prefix address, rather than local interface address.
 * It makes no difference for normally configured broadcast
 * interfaces,
 * but for point-to-point IFA_ADDRESS is DESTINATION address,
 * local address is supplied in IFA_LOCAL attribute.
 */

See also this stackoverflow question/answer:
http://stackoverflow.com/questions/4678637/what-is-difference-between-ifa-local-and-ifa-address-in-rtnetlink-linux

Does anyone know why avahi is looking for IFA_ADDRESS here, and whether
there's any reason not to use IFA_LOCAL instead?

Assuming there's not a specific reason to use IFA_ADDRESS here, I
propose the patch attached at the end of this message, which works for
me. (The bug this fixes is described in the earlier message linked above
-- avahi chooses the wrong address to associate with the P-t-P
interface, and if you enable avahi's reflector, avahi tries to call
sendmsg() using that as the source address and the kernel always,
correctly, fails the sendmsg() call with EINVAL.)

(And when/why this changed -- I was able to use avahi over P-t-P
interfaces on Linux several years ago; I don't know what avahi version I
was using at the time.)

thanks,

Matt

reflector: cache entry link-local addresses filter

Do not reflect cache entry with ipv6 link-local addresses on query.

init: suse, avahi-dnsconfd status reports dead instead of unused

Keep emacs configuration in one configuration file.

On 07.03.2011 19:04, Lennart Poettering wrote:
>
> Oh, I had assumed that .vimrc trick would allow project-wide vim
> modelines without having to edit each and every single file.
>
> Currently, every file does contain an emacs modeline at the top. It
> would be fair I guess to add a vim modeline to all those files too, even
> though it's not necessarily pretty.
Hi,
maybe it makes sense to go in the opposite direction: add .dir-locals.el
in the top directory. The settings are actually identical in all .[ch]
files.

gobject: ga_service_browser_new() should accept const gchar*

ga_service_browser_new() and ga_service_browser_new_full() should
accept const gchar*.

setproctitle: use defined() around __linux__ in #elif

socket: Still read corrupt packets from the sockets

Else, we end up with an infinite loop with 100% CPU.

http://www.avahi.org/ticket/325
https://bugzilla.redhat.com/show_bug.cgi?id=667187

man: more spelling fixes

https://bugzilla.redhat.com/show_bug.cgi?id=673812
https://bugzilla.redhat.com/show_bug.cgi?id=673810

man: spelling fixes

https://bugzilla.redhat.com/show_bug.cgi?id=673812
https://bugzilla.redhat.com/show_bug.cgi?id=673810

avahi-ui: gtk3 fix

netlink: fix wrong use of netlink flags for dump operations

The avahi-daemon uses a wrong flag combination to operate with
rtnetlink. This patch fixes the problems.

No need to set NLM_F_ACK since the dump operation already includes
the trailing NLMSG_DONE message that informs about the end of the
dump operation.

daemon: we better stay away from SIGQUIT since it is supposed to cause a core dump

l10n: Updated Finnish (fi) translation to 99%

New status: 164 messages complete with 1 fuzzy and 0 untranslated.

Transmitted-via: Transifex (www.transifex.net).

systemd: update sd-daemon.[ch]

init: update the suse initscripts

Here are two patches for avahi. The avahi website is extremly slow
today, so I didn't file them.

 - avahi-fix-howl.pc.patch: fix a small issue introduced in
   c8eacc0f13f6df529f2f40961e2ddb3a45dc9f93
 - avahi-init-lsb.patch: update the suse initscripts, with a patch
   we've had for a while

Cheers,

Vincent

--
Les gens heureux ne sont pas pressés.

howl: fix small issue

Here are two patches for avahi. The avahi website is extremly slow
today, so I didn't file them.

 - avahi-fix-howl.pc.patch: fix a small issue introduced in
   c8eacc0f13f6df529f2f40961e2ddb3a45dc9f93
 - avahi-init-lsb.patch: update the suse initscripts, with a patch
   we've had for a while

Cheers,

  Vincent

--
Les gens heureux ne sont pas pressés.

l10n: Updated Catalan (ca) translation to 100%

New status: 165 messages complete with 0 fuzzies and 0 untranslated.

Transmitted-via: Transifex (www.transifex.net).

l10n: Updated Malay (ms) translation to 24%

New status: 40 messages complete with 68 fuzzies and 57 untranslated.

Transmitted-via: Transifex (www.transifex.net).

systemd: update configure.ac snippet

update NEWS

bump version

client: use Ping() to test whether avahi is around

Ping() should work more reliably on systems where dbus activation of
avahi is not available.

http://avahi.org/ticket/319

systemd: pull in avahi from dbus activation indirectly to make it possible to deactivate it

systemd: update sd-daemon.[ch]

i18n: update LINGUAS

Merge remote branch 'origin/master-tx'

l10n: Updated Slovenian translation

New status: 160 messages complete with 0 fuzzies and 5 untranslated.

Transmitted-via: Transifex (www.transifex.net).

gtk: avahi build fix

Hey,

avahi-0.26.7 braucht einen kleinen fix, um mit gtk+ 2.21.8/2.90.7 zu
bauen. See attachment.

gobject: Fix avahi build with gobject-introspection

Hi Lennart,

Here's a patch to fix avahi to build with g-i 0.9.5 and later.

Cheers,

Vincent

--
Les gens heureux ne sont pas pressés.

l10n: Updated Slovenian translation.

New status: 135 messages complete with 10 fuzzies and 20 untranslated.

Transmitted-via: Transifex (www.transifex.net).

l10n: Updated Slovenian translation.

New status: 40 messages complete with 100 fuzzies and 25 untranslated.

Transmitted-via: Transifex (www.transifex.net).

l10n: Preliminary faroese translation

New status: 113 messages complete with 5 fuzzies and 47 untranslated.

Transmitted-via: Transifex (www.transifex.net).

l10n: Updated German (de) translation to 98%

New status: 162 messages complete with 2 fuzzies and 1 untranslated.

Transmitted-via: Transifex (www.transifex.net).

l10n: Updated Italian (it) translation to 100%

New status: 165 messages complete with 0 fuzzies and 0 untranslated.

Transmitted-via: Transifex (www.transifex.net).

l10n: Updated Japanese (ja) translation to 100%

New status: 165 messages complete with 0 fuzzies and 0 untranslated.

Transmitted-via: Transifex (www.transifex.net).

l10n: Updated French (fr) translation to 99%

New status: 164 messages complete with 1 fuzzy and 0 untranslated.

Transmitted-via: Transifex (www.transifex.net).

l10n: Updated Hungarian (hu) translation to 100%

New status: 165 messages complete with 0 fuzzies and 0 untranslated.

Transmitted-via: Transifex (www.transifex.net).

l10n: Updated Hungarian (hu) translation to 98%

New status: 163 messages complete with 2 fuzzies and 0 untranslated.

Transmitted-via: Transifex (www.transifex.net).

l10n: Updated Danish (da) translation to 100%

New status: 165 messages complete with 0 fuzzies and 0 untranslated.

Transmitted-via: Transifex (www.transifex.net).

l10n: Updated Danish (da) translation to 100%

New status: 165 messages complete with 0 fuzzies and 0 untranslated.

Transmitted-via: Transifex (www.transifex.net).

l10n: Updated Italian (it) translation to 99%

New status: 164 messages complete with 1 fuzzy and 0 untranslated.

Transmitted-via: Transifex (www.transifex.net).

l10n: Updated Chinese (Taiwan) (zh_TW) translation to 66%

New status: 109 messages complete with 1 fuzzy and 55 untranslated.

Transmitted-via: Transifex (www.transifex.net).

l10n: Updated Russian (ru) translation to 100%

New status: 165 messages complete with 0 fuzzies and 0 untranslated.

Transmitted-via: Transifex (www.transifex.net).