On Sat, Oct 06, 2018 at 11:38:59PM +0200, Santiago Vila wrote:
> On Mon, 15 May 2017, Adam Borowski wrote:
>
> > > Looking at /etc/hosts within the schroot, I see:
> > > 127.0.0.1 localhost
> > > 127.0.0.1 localhost ip6-localhost ip6-loopback
> > > 172.28.17.11abel.debian.org abel
>
On Sat, Oct 06, 2018 at 11:38:59PM +0200, Santiago Vila wrote:
> I'd like to clarify that most probably there was only one bug here
> after all, namely, the one in schroot (#842634).
Well, that one hasn't been fixed, yet I can't seem to reproduce any of the
failures in sslh on any of my build mach
On Mon, 15 May 2017, Adam Borowski wrote:
> > Looking at /etc/hosts within the schroot, I see:
> > 127.0.0.1 localhost
> > 127.0.0.1 localhost ip6-localhost ip6-loopback
> > 172.28.17.11abel.debian.org abel
> >
> > Modifying /etc/hosts by replacing ::1 with 127.0.0.1 results in be
On Mon, May 15, 2017 at 1:52 AM, Guillaume Delacour wrote:
> Hi,
>
> Le 15/05/2017 à 00:50, Adam Borowski a écrit :
>
> >
> > So it's a fully _reproducible_ bug, with a well-defined immediate cause
> > (even if we haven't identified the indirect cause yet) -- unlike the
> > original report by San
Control: severity -1 important
On Mon, May 15, 2017 at 01:52:09AM +0200, Guillaume Delacour wrote:
> Le 15/05/2017 à 00:50, Adam Borowski a écrit :
> > So it's a fully _reproducible_ bug, with a well-defined immediate cause
> > (even if we haven't identified the indirect cause yet) -- unlike the
>
Hi,
Le 15/05/2017 à 00:50, Adam Borowski a écrit :
>
> So it's a fully _reproducible_ bug, with a well-defined immediate cause
> (even if we haven't identified the indirect cause yet) -- unlike the
> original report by Santiago Villa. Thus, it looks we have two different
> bugs that just happen
On Sun, May 14, 2017 at 10:37:17PM +0200, Michael Stapelberg wrote:
> On Sun, May 14, 2017 at 7:59 AM, Adam Borowski wrote:
> > > Use: gcc -Wall -o gai gai.c && ./gai localhost 9002
> >
> > On all three machines, it looks fine:
> > ai_family = 10
> > host=::1, serv=9002
> > ai_family = 2
>
On Sun, May 14, 2017 at 7:59 AM, Adam Borowski wrote:
> On Sat, May 13, 2017 at 08:44:15PM +0200, Michael Stapelberg wrote:
> > Sorry for the late reply.
> >
> > Adam, could you run the attached example program (derived from the
> > getaddrinfo and getnameinfo manpages) please? The output should
On Sat, May 13, 2017 at 08:44:15PM +0200, Michael Stapelberg wrote:
> Sorry for the late reply.
>
> Adam, could you run the attached example program (derived from the
> getaddrinfo and getnameinfo manpages) please? The output should help us
> narrow down whether the problem is with the application
Sorry for the late reply.
Adam, could you run the attached example program (derived from the
getaddrinfo and getnameinfo manpages) please? The output should help us
narrow down whether the problem is with the application code of sslh or
something in the environment.
Use: gcc -Wall -o gai gai.c &&
Hi,
On Sat, 6 May 2017 20:57:44 +0200 Adam Borowski wrote:
> On Sat, May 06, 2017 at 08:00:11PM +0200, Michael Stapelberg wrote:
> > Thanks. It seems like getaddrinfo() is returning two results when resolving
> > localhost. Can you provide the contents of your hostname resolution-related
> > conf
On Sat, May 06, 2017 at 08:00:11PM +0200, Michael Stapelberg wrote:
> Thanks. It seems like getaddrinfo() is returning two results when resolving
> localhost. Can you provide the contents of your hostname resolution-related
> configuration please? I.e., /etc/hosts, /etc/resolv.conf,
> /etc/nsswitch
Thanks. It seems like getaddrinfo() is returning two results when resolving
localhost. Can you provide the contents of your hostname resolution-related
configuration please? I.e., /etc/hosts, /etc/resolv.conf,
/etc/nsswitch.conf, anything else you might have tweaked in that area.
On Sat, May 6, 20
Thanks for the strace. We can see that sslh creates two sockets of the same
address family, on the same host and port:
[…]
[pid 23812] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
[pid 23812] setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
[pid 23812] setsockopt(3, SOL_IP, IP_FREEBIND, [1], 4)
On Sat, May 6, 2017 at 4:02 PM, Adam Borowski wrote:
> On Sat, May 06, 2017 at 03:44:42PM +0200, Michael Stapelberg wrote:
> > I pushed a commit adding a patch which fixes the test by picking an
> > unused port. The mechanism is not atomic (i.e., the port is picked by
> > the test process, as opp
On Sat, May 06, 2017 at 03:44:42PM +0200, Michael Stapelberg wrote:
> I pushed a commit adding a patch which fixes the test by picking an
> unused port. The mechanism is not atomic (i.e., the port is picked by
> the test process, as opposed to the listening process itself and
> communicated back to
On Sat, May 06, 2017 at 03:44:42PM +0200, Michael Stapelberg wrote:
> Tomasz Buchert writes:
> > On 04/05/17 04:47, Adam Borowski wrote:
> >> [...]
> >
> > I cannot reproduce these failures. I've built in my stretch sbuild
> > around 15 times, and succedeed every time.
I found just one of my mach
control: tags -1 + pending
Hi,
Tomasz Buchert writes:
> On 04/05/17 04:47, Adam Borowski wrote:
>> [...]
>
> I cannot reproduce these failures. I've built in my stretch sbuild
> around 15 times, and succedeed every time.
>
> I use:
> gbp buildpackage --git-builder='sbuild --source-only-changes -
On 04/05/17 04:47, Adam Borowski wrote:
> [...]
I cannot reproduce these failures. I've built in my stretch sbuild
around 15 times, and succedeed every time.
I use:
gbp buildpackage --git-builder='sbuild --source-only-changes -v -As
--build-dep-resolver=apt --dist=stretch -j4' "$@"
Tomasz
sig
Control: severity -1 serious
Looks like for some reason it switched to failing 100% of the time now -- or
at least it does so on all of my setups. I have yet to see the build
succeed, despite tens of attempts on amd64, armhf and i386.
The fail reason is same as in your report:
cat: /tmp/ssl
20 matches
Mail list logo
