Alrighty, talking this over with Alessandro he made the case that we should
keep tests that don't rely on *external *network connections. See e.g.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753944 which makes the
case for a loopback interface in pbuilder.
Tobi, to that effect I modified
Am Sonntag, den 30.11.2014, 00:21 -0800 schrieb Tom Lee:
Alrighty, talking this over with Alessandro he made the case that we
should keep tests that don't rely on external network connections. See
e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753944 which
makes the case for a loopback
On dom, nov 30, 2014 at 03:06:55 +0100, Tobias Frost wrote:
Am Sonntag, den 30.11.2014, 00:21 -0800 schrieb Tom Lee:
Alrighty, talking this over with Alessandro he made the case that we
should keep tests that don't rely on external network connections. See
e.g.
On Sun, 30 Nov 2014 17:36:04 +0100, Alessandro Ghedini wrote:
On dom, nov 30, 2014 at 03:06:55 +0100, Tobias Frost wrote:
Am Sonntag, den 30.11.2014, 00:21 -0800 schrieb Tom Lee:
Also, I feel like the serious severity is overstating the issue
given that 0.11.0-4 builds fine in
Talked this over with the release team on #debian-release, they agree it's
a serious bug indicated that they'd prefer the fix to be something more
along the lines of what Gregor is suggesting. I feel like the test should
call out the fact it's skipped not passed, but otherwise imagine it would
On Sun, 30 Nov 2014 10:51:56 -0800, Tom Lee wrote:
Talked this over with the release team on #debian-release,
Except that noone who responded is a member of the release team :)
Cheers,
gregor
--
.''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian
D'oh :) There I go making assumptions.
All the same, I feel like we can argue back and forth about the severity of
this issue but we've got a potential fix ready to go. Might as well get the
release team involved -- if we can arrange an unblock the whole issue is
moot.
On Sun, Nov 30, 2014 at
Rather than add to the overhead of getting this change accepted, I'm going
to roll back the DEB_BUILD_OPTS=nocheck change given it's unrelated to this
bug (per the freeze policy
https://release.debian.org/jessie/freeze_policy.html). I'll roll it back in
after the freeze.
Proposed change to
On Sun, Nov 30, 2014 at 07:17:46PM +0100, gregor herrmann wrote:
On Sun, 30 Nov 2014 17:36:04 +0100, Alessandro Ghedini wrote:
On dom, nov 30, 2014 at 03:06:55 +0100, Tobias Frost wrote:
Am Sonntag, den 30.11.2014, 00:21 -0800 schrieb Tom Lee:
Also, I feel like the serious severity
On Sun, Nov 30, 2014 at 1:31 PM, Alessandro Ghedini gh...@debian.org
wrote:
This is, I think, the exact same problem as #759799 (which is btw severity:
important). If the consensus is that this should be fixed in the affected
packages (e.g. by disabling the tests), I'm all for it, but I really
On Sun, 30 Nov 2014 22:31:20 +0100, Alessandro Ghedini wrote:
On Sun, Nov 30, 2014 at 07:17:46PM +0100, gregor herrmann wrote:
On Sun, 30 Nov 2014 17:36:04 +0100, Alessandro Ghedini wrote:
What does this yet even mean? Except inside pbuilder, hiredis builds
fine [1].
The fact that it
gregor herrmann dixit:
That fact that pbuilder copies /etc/resolv.conf into the chroot each
time also does not help :/
Ouch. How about if USENETWORK=no then CHROOT/etc/resolv.conf is
created with values sane for that? Can you do the NMU?
A simple and stupid solution would be to turn off DNS
On Sun, 30 Nov 2014 22:23:13 +, Thorsten Glaser wrote:
gregor herrmann dixit:
That fact that pbuilder copies /etc/resolv.conf into the chroot each
time also does not help :/
Ouch. How about if USENETWORK=no then CHROOT/etc/resolv.conf is
created with values sane for that? Can you do the
gregor herrmann dixit:
Ouch. How about if USENETWORK=no then CHROOT/etc/resolv.conf is
created with values sane for that? Can you do the NMU?
What would these sane values be?
I guess, no nameserver. On BSD, a single line “lookup file”,
but I think glibc’s syntax differs. Best to ask one of
Alrighty, patch applied pbuilder's clean. Now just waiting on Alessandro
to review my changes push the package. On master here if you want to try
things out in the interim: git://anonscm.debian.org/collab-maint/hiredis.git
Daniel, I also added support for DEB_BUILD_OPTS=nocheck since it caused
On Mon, 24 Nov 2014 00:45:04 -0800 Tom Lee deb...@tomlee.co wrote:
Alrighty, patch applied pbuilder's clean. Now just waiting on Alessandro
to review my changes push the package. On master here if you want to try
things out in the interim: git://anonscm.debian.org/collab-maint/hiredis.git
Package: src:hiredis
Followup-For: Bug #770648
Dear Maintainer,
As already mentioned by David, you must not use network when building the
package,
even lo might not be available.
The attached patch disables the network-based tests.
PS: The pid-file location hardcoded to /tmp looks weird..
Thanks so much Daniel for the bug report Tobi for your patch. I'll get a
new build together over the next day or so.
Alessandro Ghedini has been pretty responsive wrt sponsoring my uploads,
but I'll reach out if I can't get a hold of him.
On Sun, Nov 23, 2014 at 2:52 AM, Tobias Frost
Source: hiredis
Version: 0.11.0-4
Severity: serious
From my pbuilder build log (on amd64):
echo \
daemonize yes\n \
pidfile /tmp/hiredis-test-redis.pid\n \
port 56379\n \
bind 127.0.0.1\n \
unixsocket /tmp/hiredis-test-redis.sock \
|
19 matches
Mail list logo
