Source: pcre2
Version: 10.39-1
Severity: important
Tags: patch ftbfs
User: debian-hurd@lists.debian.org
Usertags: hurd
This packages fails to build on hurd-i386 as of version 10.39-1;
from the last build log for 10.39-3 [1]:
| gcc -DHAVE_CONFIG_H -I. -I./src "-I./src" -Wdate-time -D_FORTIFY_SOUR
Control: reopen -1
On Wed, 09 Jan 2019 13:39:46 +0200,
Yavor Doganov wrote:
> Package: gnustep-back-common
> Version: 0.26.2-4
>
> I noticed that gnumail and adun.app have been given back a few hundred
> times because gnustep-back-common's postinst fails on GNU/Hurd.
Thi
Package: gnustep-back-common
Version: 0.26.2-4
Severity: important
User: debian-hurd@lists.debian.org
Usertags: hurd-i386
I noticed that gnumail and adun.app have been given back a few hundred
times because gnustep-back-common's postinst fails on GNU/Hurd. I would
appreciate if you investigate an
Samuel Thibault wrote:
> Yavor Doganov, on dim. 18 févr. 2018 23:52:32 +0200, wrote:
> > | checking kernel support for /proc filesystem... no
> It seems there was a temporary issue on mahler:
> [...]
> Rebooting seems to fix it, I have requeued gnustep-base.
Thanks very much, built successfully.
I was unpleasantly surprised to see gnustep-base/1.25.1-2 FTBFS on
GNU/Hurd because of a testsuite failure (NSProcessInfo -systemUptime
returning 0).
The reason for the test failure is this:
| checking kernel support for /proc filesystem... no
| checking support for /proc psinfo struct... no
| ch
[ Apologies for cross-posting. ]
I am bewildered why cynthiune.app FTBFS on hurd-i386 and powerpc:
| g++ -shared -rdynamic
| -L../../Frameworks/Cynthiune/Cynthiune.framework/Versions/Current
| -lCynthiune -lmcheck -Wl,-z,defs -Wl,--as-needed
| -Wl,-rpath,/usr/lib/cynthiune.app -shared-libgc
On Fri, Dec 18, 2009 at 10:49:30AM +0100, Pino Toscano wrote:
> > Note, thought, that this will not work with parallel builds.
Right :-(. I admit I haven't thought about this (valid) scenario...
> Hm, or make the patch-stamp target a requirement for the
> configure-stamp, like in the patch atta
Pino Toscano wrote:
> The solution I found (patch attached) is to apply the patches before the
> configure run.
*Blush* I wonder how I missed that, it's so obvious...
Thanks, I'm reuploading with build-stamp prerequisites swapped.
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.o
Christoph Egger wrote:
> Hm ok I guess I personally would prefer a the see some notice if
> there are some tags > pedantic
If this is a generally desirable thing among sponsors, we'll of course
comply. (Some info tags are only a matter of style, though.)
> OK it took me some more ti
I noticed that ruby-gnome2 has a Dep-Wait on libdrm-dev, which doesn't
look right to me.
I was trying to figure out why libdrm-dev was added as a
build-dependency in ruby-gnome2/0.19.1-1. It seems that due to
extconf-strict.patch, the package fails to build because pkg-config.rb
invokes pkg-confi
proper way to solve the problem? Maybe it was just a quick
temporary fix as porting xulrunner is probably not trivial? Anyway,
should I apply my patch or resort to a similar hack given the fact
that xulrunner has hardcoded PATH_MAX? The latter doesn't look right
to me.
2009-08-20 Yavo
11 matches
Mail list logo
