Source: cups
Version: 2.2.4-8
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Thank you for applying my patch from #837936 to make cups cross build.
Unfortunately, that no longer works. When cross building cups, mantohtml
fails to run again (and #837936 was meant to fix that).
It
Your message dated Thu, 12 Oct 2017 20:19:24 +0200
with message-id <2486291.79f8y2u...@odyx.org>
and subject line Re: Bug#878148: cups: Default ServerName wrong/not in sync
with manual
has caused the Debian Bug report #878148,
regarding cups: Default ServerName wrong/not in sync with manual
to be
Hi,
> > I said that I cannot access CUPS from the local network, not from loopback.
>
> The title of this bug is "Default ServerName wrong/not in sync with manual".
> I'm not sure I understand whether you think the documentation should be
> changed, or whether the _code_ should be changed.
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 12 Oct 2017 17:57:16 +0200
Source: foomatic-db
Binary: foomatic-db foomatic-db-compressed-ppds openprinting-ppds
Architecture: source
Version: 20171012-1
Distribution: unstable
Urgency: medium
Maintainer: Debian
foomatic-db_20171012-1_source.changes uploaded successfully to localhost
along with the files:
foomatic-db_20171012-1.dsc
foomatic-db_20171012.orig.tar.xz
foomatic-db_20171012-1.debian.tar.xz
foomatic-db_20171012-1_source.buildinfo
Greetings,
Your Debian queue daemon (running on
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 12 Oct 2017 17:42:54 +0200
Source: epson-inkjet-printer-escpr
Binary: printer-driver-escpr
Architecture: source
Version: 1.6.16-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Printing Team
epson-inkjet-printer-escpr_1.6.16-1_source.changes uploaded successfully to
localhost
along with the files:
epson-inkjet-printer-escpr_1.6.16-1.dsc
epson-inkjet-printer-escpr_1.6.16.orig.tar.gz
epson-inkjet-printer-escpr_1.6.16-1.debian.tar.xz
Le jeudi, 12 octobre 2017, 16.34:48 h CEST Dominik George a écrit :
> I said that I cannot access CUPS from the local network, not from loopback.
The title of this bug is "Default ServerName wrong/not in sync with manual".
I'm not sure I understand whether you think the documentation should be
On Thu 12 Oct 2017 at 16:34:48 +0200, Dominik George wrote:
> >CUPS' behaviour is intentional. It rejects requests addressed to the
> >system's FQDN host which are received over the local loopback
> >interface.
> >127.0.1.1 uses the loopback interface.
>
> Good thing I do not route 127.0.0.0/8
> Does either 127.0.0.1 or 127.0.1.1 in /etc/hosts map to your FQDN?
The base host name of the system is resolvable to its FQDN and
`hostname -f` returns the correct FQDN.
Yet, as reported, CUPS only accepts the base name as reported by
`hostname`.
-nik
On Thu 12 Oct 2017 at 12:18:51 +0200, Dominik George wrote:
> Hi,
>
> >> What I report - and what is a fact - is that CUPS as installed from
> >> the Debian package does NOT WORK under normal network conditions,
> >> because it REFUSES to accept requests under its own FQDN.
> >>
> >> That the
Hi,
>> What I report - and what is a fact - is that CUPS as installed from
>> the Debian package does NOT WORK under normal network conditions,
>> because it REFUSES to accept requests under its own FQDN.
>>
>> That the docs tell it should accept those requests is another part of
>> the bug.
>
On Wed 11 Oct 2017 at 23:25:48 +0200, Dominik George wrote:
> >If you feel there is an upstream issue in the documentation there is
> >
> > https://github.com/apple/cups/issues/new
>
> Have you read devref? It's your responsibility as package maintainer
> to forward bugs upstream.
I am not a
Package: hplip
Version: 3.17.9+repack0-1
Severity: serious
Justification: Policy 3.5
The package hplip is not installable in unstable. Or if already installed,
the python3 dependency-package is not upgradable to 3.6.
$ apt-cache show hplip | grep Depends | tr "," "\n" | grep "python3 "
python3
14 matches
Mail list logo
