Bug#971264: mediawiki: ParseError after 1.27.7-1~deb9u4 upgrade (blame patch for User::pingLimiter)

2020-09-28 Thread carandraug
Package: mediawiki
Version: 1:1.27.7-1~deb9u4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

After the update to 1.27.7-1~deb9u4 (from 1.27.7-1~deb9u3), the mediawiki site
errors in all pages with:

Exception encountered, of type "ParseError"

Enabling some debug messages, gives a bit more detail:

Exception encountered, of type "ParseError"
[a5b5213be767b7723077eae1] /w/ ParseError from line 1813 of 
/usr/share/mediawiki/includes/user/User.php: syntax error, unexpected 'else' 
(T_ELSE)
Backtrace:
#0 [internal function]: AutoLoader::autoload(string)
#1 /usr/share/mediawiki/includes/session/SessionBackend.php(125): 
spl_autoload_call(string)
#2 /usr/share/mediawiki/includes/session/SessionManager.php(854): 
MediaWiki\Session\SessionBackend->__construct(MediaWiki\Session\SessionId, 
MediaWiki\Session\SessionInfo, CachedBagOStuff, MediaWiki\Logger\LegacyLogger, 
integer)
#3 /usr/share/mediawiki/includes/session/SessionManager.php(301): 
MediaWiki\Session\SessionManager->getSessionFromInfo(MediaWiki\Session\SessionInfo,
 WebRequest)
#4 /usr/share/mediawiki/includes/session/SessionManager.php(235): 
MediaWiki\Session\SessionManager->getEmptySessionInternal(WebRequest)
#5 /usr/share/mediawiki/includes/session/SessionManager.php(185): 
MediaWiki\Session\SessionManager->getEmptySession(WebRequest)
#6 /usr/share/mediawiki/includes/WebRequest.php(700): 
MediaWiki\Session\SessionManager->getSessionForRequest(WebRequest)
#7 /usr/share/mediawiki/includes/session/SessionManager.php(121): 
WebRequest->getSession()
#8 /usr/share/mediawiki/includes/Setup.php(747): 
MediaWiki\Session\SessionManager::getGlobalSession()
#9 /usr/share/mediawiki/includes/WebStart.php(137): require_once(string)
#10 /usr/share/mediawiki/index.php(40): require(string)
#11 {main}

Looking at User.php lines 1813, the whole thing looks odd.  This comes from the
Debian patch "0009-User-pingLimiter-add-user-global-rate-limit-type.patch"

-- System Information:
Debian Release: 9.13
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-13-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mediawiki depends on:
ii  apache2 [httpd] 2.4.25-3+deb9u9
ii  mediawiki-classes   1:1.27.7-1~deb9u4
ii  mime-support3.60
ii  php 1:7.0+49
ii  php-common  1:49
ii  php-mbstring1:7.0+49
ii  php-mysql   1:7.0+49
ii  php-xml 1:7.0+49
ii  php7.0 [php]7.0.33-0+deb9u9
ii  php7.0-mbstring [php-mbstring]  7.0.33-0+deb9u9
ii  php7.0-mysql [php-mysqlnd]  7.0.33-0+deb9u9
ii  php7.0-xml [php-xml]7.0.33-0+deb9u9

Versions of packages mediawiki recommends:
ii  mariadb-server-10.1 [virtual-mysql-server]  10.1.45-0+deb9u1
ii  php-curl1:7.0+49
ii  php-intl1:7.0+49
ii  php-wikidiff2   1.4.1-1
ii  php7.0-cli [php-cli]7.0.33-0+deb9u9
ii  php7.0-curl [php-curl]  7.0.33-0+deb9u9
ii  php7.0-intl [php-intl]  7.0.33-0+deb9u9
ii  python  2.7.13-2

Versions of packages mediawiki suggests:
pn  clamav   
pn  hhvm 
ii  imagemagick  8:6.9.7.4+dfsg-11+deb9u10
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11+deb9u10
ii  memcached1.4.33-1+deb9u1
pn  php-apcu 

-- Configuration Files:
/etc/apache2/conf-available/mediawiki.conf changed [not included]
/etc/mediawiki/mediawiki.conf changed [not included]

-- no debconf information



Bug#912661: python-tifffile: tifffile is not installed as distribution

2018-11-02 Thread carandraug
Package: python-tifffile
Version: 20170929-1
Severity: important

Python's tifffile is available in two forms:

1) download as individual files at https://www.lfd.uci.edu/~gohlke/
2) python package at PyPI https://pypi.org/project/tifffile/

Debian makes use of the individual files via a mirror at
https://github.com/malaterre/tifffile which seems to exist for Debian
only.

Because it's not installed as a package, setuptools will not "see" it
and report it as not being installed.  The effect of this is that
installing a package dependent on tifffile, will require installation
of the package, even if the module is already available.

Effectively, the following needs to succeed:

$ python -c 'import pkg_resources; 
pkg_resources.get_distribution("tifffile")'
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
476, in get_distribution
dist = get_provider(dist)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
352, in get_provider
return working_set.find(moduleOrReq) or require(str(moduleOrReq))[0]
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
895, in require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
781, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'tifffile' distribution was not 
found and is required by the application

The change would make

  1) the Debian package play nicer with other python packages
  2) the github repo no longer necessary
  3) easier to track dependencies (looking through the changelog file in
 Debian sources, seems that it was a problem a few times)

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python-tifffile depends on:
ii  libc6 2.27-8
ii  python [python-importlib] 2.7.15-3
ii  python-concurrent.futures 3.2.0-2
ii  python-enum34 1.1.6-2
ii  python-numpy [python-numpy-abi9]  1:1.14.5-1+b1
ii  python2 [python-importlib]2.7.15-3

Versions of packages python-tifffile recommends:
ii  python-matplotlib  2.2.2-4+b1

python-tifffile suggests no packages.

-- no debconf information



Bug#863332: mediawiki: poweredby_debian image links broken unless ScriptPath is /wiki

2017-05-25 Thread carandraug
Package: mediawiki
Version: 1:1.27.3-1
Severity: minor

The generated LocalSettings uses the value of wgScriptPath for the icon
poweredby_debian which is used in $wgFooterIcons['poweredby']['debian']
at time that the config is run.  Changing wgScriptPath later breaks the
link.  This can be fixed by modifying the debian patch
debian_installer_overrides.diff to leave the $wgScriptPath instead.

Carnë

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.9.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mediawiki depends on:
ii  apache2 [httpd] 2.4.25-3
ii  mediawiki-classes   1:1.27.3-1
ii  mime-support3.60
ii  php 1:7.0+49
ii  php-common  1:49
ii  php-mbstring1:7.0+49
ii  php-mysql   1:7.0+49
ii  php-xml 1:7.0+49
ii  php7.0 [php]7.0.19-1
ii  php7.0-mbstring [php-mbstring]  7.0.19-1
ii  php7.0-mysql [php-mysqlnd]  7.0.19-1
ii  php7.0-xml [php-xml]7.0.19-1

Versions of packages mediawiki recommends:
ii  mariadb-server-10.1 [virtual-mysql-server]  10.1.23-8
ii  php-curl1:7.0+49
ii  php-intl1:7.0+49
ii  php-wikidiff2   1.4.1-1
ii  php7.0-cli [php-cli]7.0.19-1
ii  php7.0-curl [php-curl]  7.0.19-1
ii  php7.0-intl [php-intl]  7.0.19-1
ii  python  2.7.13-2

Versions of packages mediawiki suggests:
pn  clamav   
pn  hhvm 
ii  imagemagick  8:6.9.7.4+dfsg-8
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-8
ii  memcached1.4.33-1
pn  php-apcu 

-- Configuration Files:
/etc/apache2/conf-available/mediawiki.conf changed [not included]
/etc/mediawiki/mediawiki.conf changed [not included]

-- no debconf information


Bug#828622: xul-ext-greasemonkey: unable to manage scripts since Iceweasel -> Firefox ESR transition

2016-06-26 Thread carandraug
Package: xul-ext-greasemonkey
Version: 2.2-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The greasemonkey plugin has suddenly stopped working.  I believe this to
have happened after upgrading to debian 8.5 where Iceweasel was upgraded
and is now Firefox ESR.

How it does not work:

* its menu "Manage user scripts..." opens "about:addons instead
* its menu "New user script" does nothing
* button to install on websites with scripts to install, such as
greasyfork.org, no longer works and firefox displays the source
of the script instead.

In addition, previously enabled scripts have been disabled (or
just no longer work but since the script manager is not accessible
I can't check the issue).

Carnë


-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xul-ext-greasemonkey depends on:
ii  iceweasel  45.2.0esr-1~deb8u1

xul-ext-greasemonkey recommends no packages.

xul-ext-greasemonkey suggests no packages.

-- no debconf information



Bug#778917: texlive-latex-extra: missing dependency - textgreek.sty requires lgrenc.def (texlive-lang-greek)

2015-02-21 Thread carandraug
Package: texlive-latex-extra
Version: 2014.20141024-1
Severity: normal

Dear Maintainer,

The Tex textgreek package is part of the texlive-latex-extra debian package.
This Tex package depends on lgrenc.def which in Debian, is part of the Debian
texlive-lang-greek package.  This package should then be listed as a
dependency for texlive-latex-extra but it is not.  A simple example:

\documentclass{article}
\usepackage{textgreek}
\begin{document}
Hello \textalpha world!
\end{document}

Building this sample document will cause the error (trimeed to show the
relevant issue):

This is pdfTeX, Version 3.14159265-2.6-1.40.15 (TeX Live 2015/dev/Debian) 
(preloaded format=pdflatex)
.
.
.
(/usr/share/texlive/texmf-dist/tex/latex/textgreek/textgreek.sty

! Package textgreek Error: Cannot find the file lgrenc.def.

See the textgreek package documentation for explanation.
Type  H return  for immediate help.
 ...  
  
l.39  Maybe it comes with the babel package.}}

unless the texlive-lang-greek package is installed in which case it finishes
with no issues.

-- System Information:
Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages texlive-latex-extra depends on:
ii  dpkg   1.17.23
ii  preview-latex-style11.87-3+deb8u1
ii  tex-common 5.03
ii  texlive-base   2014.20141024-2
ii  texlive-binaries   2014.20140926.35254-6
ii  texlive-latex-recommended  2014.20141024-2
ii  texlive-pictures   2014.20141024-2

Versions of packages texlive-latex-extra recommends:
ii  texlive-fonts-recommended  2014.20141024-2
ii  texlive-latex-extra-doc2014.20141024-1

Versions of packages texlive-latex-extra suggests:
ii  libfile-which-perl  1.09-1
ii  python-pygments 2.0.1+dfsg-1

Versions of packages tex-common depends on:
ii  debconf [debconf-2.0]  1.5.55
ii  dpkg   1.17.23
ii  ucf3.0030

Versions of packages tex-common suggests:
ii  debhelper  9.20141022

Versions of packages texlive-latex-extra is related to:
ii  tex-common5.03
ii  texlive-binaries  2014.20140926.35254-6

-- debconf information:
  tex-common/check_texmf_missing:
  tex-common/check_texmf_wrong:


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#745437: pyro4: 'serpent' dependency is not installed

2015-02-07 Thread carandraug
Package: python2-pyro4
Version: 4.23-1
Followup-For: Bug #745437

I have just faced installed Pyro4 and am now facing this bug. Serpent
is a dependecy of Pyro4 and is not being installed. Two simple examples
showing this, straight for the very first example on Pyro4 documentation.
One starts Pyro4 name server while the other queries a runing server.

This shows that without serpent, Pyro4 is failing both as server and as
client.  Please list python serpent as dependency of Pyro4.

$ python -m Pyro4.nsc list
Failed to locate the name server: serializer 'serpent' is unknown or not 
available

$ python -m Pyro4.naming
Traceback (most recent call last):
  File /usr/lib/python2.7/runpy.py, line 162, in _run_module_as_main
__main__, fname, loader, pkg_name)
  File /usr/lib/python2.7/runpy.py, line 72, in _run_code
exec code in run_globals
  File /usr/lib/python2.7/dist-packages/Pyro4/naming.py, line 384, in module
main(sys.argv[1:])
  File /usr/lib/python2.7/dist-packages/Pyro4/naming.py, line 381, in main
nathost=options.nathost, natport=options.natport)
  File /usr/lib/python2.7/dist-packages/Pyro4/naming.py, line 220, in 
startNSloop
daemon=NameServerDaemon(host, port, unixsocket, nathost=nathost, 
natport=natport)
  File /usr/lib/python2.7/dist-packages/Pyro4/naming.py, line 121, in __init__
super(NameServerDaemon, self).__init__(host, port, unixsocket, 
nathost=nathost, natport=natport)
  File /usr/lib/python2.7/dist-packages/Pyro4/core.py, line 601, in __init__
self.__serializer_ids = set([util.get_serializer(ser_name).serializer_id 
for ser_name in Pyro4.config.SERIALIZERS_ACCEPTED])
  File /usr/lib/python2.7/dist-packages/Pyro4/util.py, line 455, in 
get_serializer
raise Pyro4.errors.ProtocolError(serializer '%s' is unknown or not 
available % name)
Pyro4.errors.ProtocolError: serializer 'serpent' is unknown or not available


-- System Information:
Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python2-pyro4 depends on:
ii  python  2.7.8-2

python2-pyro4 recommends no packages.

Versions of packages python2-pyro4 suggests:
pn  pyro4  none
pn  pyro4-doc  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#777381: python-stdeb: py2dsc fails with non-ascii characters

2015-02-07 Thread carandraug
Package: python-stdeb
Version: 0.8.2-4
Severity: normal

The py2dsc program errors with non-ascii characters.  My environment is set
up for UTF-8:

$ env | grep LC
LC_PAPER=en_GB.utf8
LC_MONETARY=en_GB.utf8
LC_NUMERIC=en_GB.utf8
LC_MEASUREMENT=en_GB.utf8
LC_TIME=en_GB.utf8

And my terminal (gnome-terminal) has character encoding set to Unicode (UTF-8)

Showing the error:

$ py2dsc -m 'Carnë Draug carandraug+...@gmail.com' serpent-1.8.tar.gz 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
running the following command in directory: deb_dist/tmp_py2dsc/serpent-1.8
/usr/bin/python setup.py --command-packages stdeb.command sdist_dsc 
--dist-dir=/home/carandraug/dev/debian/deb_dist 
--use-premade-distfile=/home/carandraug/dev/debian/serpent-1.8.tar.gz 
--maintainer=Carnë Draug carandraug+...@gmail.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
running sdist_dsc
running egg_info
writing serpent.egg-info/PKG-INFO
writing top-level names to serpent.egg-info/top_level.txt
writing dependency_links to serpent.egg-info/dependency_links.txt
reading manifest file 'serpent.egg-info/SOURCES.txt'
writing manifest file 'serpent.egg-info/SOURCES.txt'
Traceback (most recent call last):
  File setup.py, line 164, in module
Topic :: Software Development
  File /usr/lib/python2.7/distutils/core.py, line 151, in setup
dist.run_commands()
  File /usr/lib/python2.7/distutils/dist.py, line 953, in run_commands
self.run_command(cmd)
  File /usr/lib/python2.7/distutils/dist.py, line 972, in run_command
cmd_obj.run()
  File /usr/lib/python2.7/dist-packages/stdeb/command/sdist_dsc.py, line 141, 
in run
remove_expanded_source_dir=self.remove_expanded_source_dir,
  File /usr/lib/python2.7/dist-packages/stdeb/util.py, line 1166, in build_dsc
-- %(maintainer)s  %(date822)s\n%debinfo.__dict__)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 104: 
ordinal not in range(128)
ERROR running: /usr/bin/python setup.py --command-packages stdeb.command 
sdist_dsc --dist-dir=/home/carandraug/dev/debian/deb_dist 
--use-premade-distfile=/home/carandraug/dev/debian/serpent-1.8.tar.gz 
--maintainer=Carnë Draug carandraug+...@gmail.com
ERROR in deb_dist/tmp_py2dsc/serpent-1.8

-- System Information:
Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-stdeb depends on:
ii  debhelper  9.20141022
ii  python 2.7.8-2
ii  python-requests2.4.3-4
ii  python-setuptools  5.5.1-1
pn  python:any none

Versions of packages python-stdeb recommends:
ii  apt-file2.5.4
ii  dpkg-dev1.17.23
ii  python-all  2.7.8-2

Versions of packages python-stdeb suggests:
pn  python-all-dev  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#768877: libgdcm2-dev: CMake reports that GDCM is not installed

2014-11-09 Thread carandraug
Package: libgdcm2-dev
Version: 2.4.4-3
Severity: important

Dear Maintainer,

the GDCM project has a ProjectConfig.cmake file to be used by other projects.
This was working fine on Wheezy (with gdcm 2.2 but seems to be broken in
Jessie):

In Wheezy:

$ cmake --find-package -DNAME=GDCM -DLANGUAGE=CXX -DCOMPILER_ID=GNU 
-DMODE=COMPILE
-I/usr/include/gdcm-2.2  

While in Jessie:

$ cmake --find-package -DNAME=GDCM -DLANGUAGE=CXX -DCOMPILER_ID=GNU 
-DMODE=COMPILE
GDCM not found.
CMake Error: Problem processing arguments. Aborting.

This breaks build of other project that uses GDCM since it is required to get
the include flags (cmake's m4 macro for autoconf is pretty much a wrapper to
such system call).

Carnë

-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libgdcm2-dev depends on:
ii  libgdcm2.4  2.4.4-3

libgdcm2-dev recommends no packages.

libgdcm2-dev suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#758384: avahi-daemon: eth0:avahi interface created although it's disconnected

2014-08-16 Thread carandraug
Package: avahi-daemon
Version: 0.6.31-4
Severity: normal

Dear Maintainer,

the avahi daemon keeps creating an eth0:avahi interface even though I have
nothing connected to eth0. Even after bringing the eth0 down, avahi brings
it back up after a few minutes.

The big problem with this is that when eth0:avahi is created, it steals
all other connections meaning I lose access to the internet. The result is
that a few minutes after turning on the PC, I lose internet connection. This
can be diagnosed by running 'ip route get 130.89.148.14' (www.debian.org)
which will show that eth0 is being used.

Doing 'ifconfig eth0 down' will only fix for a few minutes.

I'm unsure if this is related but this machine (Lenovo X1 carbon 2nd gen), has
a built-in gigabit ethernet port (requires an adapter).

While I understand that the *:avahi interfaces are created when it fails to get
an IP address, I'd guess it should not be creating one when it's not connected
so it uses the other interfaces (wlan0 in my case) which are working fine.

Carnë

-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages avahi-daemon depends on:
ii  adduser  3.113+nmu3
ii  bind9-host [host]1:9.9.5.dfsg-4
ii  dbus 1.8.6-1
ii  host 1:9.9.5.dfsg-4
ii  init-system-helpers  1.20
ii  libavahi-common3 0.6.31-4
ii  libavahi-core7   0.6.31-4
ii  libc62.19-7
ii  libcap2  1:2.24-4
ii  libdaemon0   0.14-6
ii  libdbus-1-3  1.8.6-1
ii  libexpat12.1.0-6
ii  lsb-base 4.1+Debian13

Versions of packages avahi-daemon recommends:
ii  libnss-mdns  0.10-6

Versions of packages avahi-daemon suggests:
ii  avahi-autoipd  0.6.31-4

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org