Bug#842634: Bug#851877: fails every time

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

Bug#851877: fails every time

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

Bug#842634: Bug#851877: fails every time

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

Bug#851877: fails every time

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 > >

Bug#842634: Bug#851877: fails every time

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

Bug#842634: Bug#851877: fails every time

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

Bug#842634: Bug#851877: fails every time

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

Bug#842634: Bug#851877: fails every time

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)

Bug#851877: fails every time

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

Bug#851877: fails every time

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

Bug#851877: fails every time

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

Bug#851877: fails every time

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, >

Bug#851877: fails every time

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,

Bug#851877: fails every time

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],

Bug#851877: fails every time

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 > >

Bug#851877: fails every time

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

Bug#851877: fails every time

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

Bug#851877: fails every time

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

Bug#851877: fails every time

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

Bug#851877: fails every time

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: