at bottom :-
On 4/7/15, Michael Lustfield wrote:
> severity 779825 normal
> thanks
>
> The initial report here was about Nginx failing to install. We've now
> determined this is because the user disabled IPv6 support on their
> system. This isn't simply a non-standard case, it's a nonsensical one
severity 779825 normal
thanks
The initial report here was about Nginx failing to install. We've now
determined this is because the user disabled IPv6 support on their
system. This isn't simply a non-standard case, it's a nonsensical one.
Accommodating this use case would cause headaches for pretty
at bottom :-
On 3/13/15, Ivan Baldo wrote:
> And I filled
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780403 just in case.
>
> I wonder, what would happen if the config just says "listen 80" or
> "listen *:80"? It will listen in both IPv4 and IPv6 and if IPv6 isn't
> available fa
And I filled
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780403 just in case.
I wonder, what would happen if the config just says "listen 80" or
"listen *:80"? It will listen in both IPv4 and IPv6 and if IPv6 isn't
available fall back gracefully to only IPv4?
Can someone test
severity 779825 important
thanks
Setting severity to important as per discussion above.
On Wed, Mar 11, 2015 at 12:28 AM, Michael Lustfield
wrote:
> I've seen this in other packages such as mysql. Admittedly, it can be a bit
> frustrating that an inability to cleanly update/install a package can
I've seen this in other packages such as mysql. Admittedly, it can be a bit
frustrating that an inability to cleanly update/install a package can cause
issues during an upgrade.
However, it is possible that something else may depend on a package cleanly
upgrading before it can proceed. I can think
Shirish, doesn't matter if your ISP doesn't have IPv6, thats no
reason to disable it system wide and not using it, loopback connections
will use it, as well maybe LAN connections.
Nginx will listen on both IPv4 and IPv6.
You are using a non standard setup so problems like this will h
at bottom :-
On 3/10/15, Christos Trochalakis wrote:
>
> This is definitely the problem, nginx cannot bind an ipv6 socket so it
> fails to start.
>
> The package stays in unconfigured state when nginx could not be started,
> this is standard behaviour: dh_installinit by default adds a stanga i
On Mon, Mar 09, 2015 at 10:58:52PM +0530, shirish शिरीष wrote:
at bottom :-
On 3/9/15, Ivan Baldo wrote:
Ok, decided to check current Debian Policy Manual and there isn't a
specific mention of what to do when starting a service after dpkg's
configuration phase and that service fails.
at bottom :-
On 3/9/15, Ivan Baldo wrote:
> Ok, decided to check current Debian Policy Manual and there isn't a
> specific mention of what to do when starting a service after dpkg's
> configuration phase and that service fails.
> So I guess is up to maintainers of this package to decide
Ok, decided to check current Debian Policy Manual and there isn't a
specific mention of what to do when starting a service after dpkg's
configuration phase and that service fails.
So I guess is up to maintainers of this package to decide.
For what is worth, I vote for just continuing
Hello Shirish!
Good news, thats it, you don't have IPv6 at all configured, not
even for the loopback interface, which is a pretty non standard setup
nowadays so be careful, other services could act badly.
I don't know what the Policy document says about this situation,
but shouldn't
Hi Ivan,
The output is :-
$ ip -6 addr
$
On 3/9/15, Ivan Baldo wrote:
> Hello.
> Maybe you don't have IPv6 at all configured, not even in the "lo"
> interface?
> Whats the output of "ip -6 addr"?
> Thanks!
>
> --
> Ivan Baldo - iba...@adinet.com.uy - http://ibaldo.codigolibre
Hello.
Maybe you don't have IPv6 at all configured, not even in the "lo"
interface?
Whats the output of "ip -6 addr"?
Thanks!
--
Ivan Baldo - iba...@adinet.com.uy - http://ibaldo.codigolibre.net/
From Montevideo, Uruguay, at the south of South America.
Freelance programmer and G
at bottom :-
On 3/9/15, Kartik Mistry wrote:
> On Mon, Mar 9, 2015 at 12:08 PM, shirish शिरीष
> wrote:
>> AFA /etc/nginx/nginx.conf test failure is concerned, I haven't changed
>> anything at that file, it's in the default state.
>
> It should not fail if in default state,
>
> _ ~/ sudo /usr/sbi
On Mon, Mar 9, 2015 at 12:08 PM, shirish शिरीष wrote:
> AFA /etc/nginx/nginx.conf test failure is concerned, I haven't changed
> anything at that file, it's in the default state.
It should not fail if in default state,
_ ~/ sudo /usr/sbin/nginx -t
nginx: the configuration file /etc/nginx/nginx.c
Hi all,
First of all thank you Norbert Fischer and Kartik for jumping on this
quickly. For some reason I am not subscribed to the bug even though I
reported this, hence have tried to subscribe to it let's see what
happens.
I had a look at the questions asked :-
a. Have you made an aptitude update
On Sun, Mar 8, 2015 at 7:07 PM, Norbert Fischer wrote:
> Have you already started another web server which has been bound to
> TCP port 80? You should stop any of those services beforehand. Bound
> ports can be seen by issuing "sudo netstat -ntlp" which also gives you
> the name of the service.
L
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I'm not a maintainer but just tried to reproduce this issue on two
different fresh headless systems and failed to do so.
nginx-full has been installed successfully on multiple tries on debian
unstable and debian testing.
As test setup I used:
Package: nginx-full
Version: 1.6.2-5
Justification: renders package unusable
Severity: grave
Dear Maintainer,
I was trying to install nginx-full to learn and play with it and was
unable to install it.
I first looked at nginx package
$ aptitude show nginx
Package: nginx
State: not installed
Versi
20 matches
Mail list logo
