Control: block 954831 with -1
Control: severity -1 serious
On Tue, 05 Nov 2019 13:22:46 + Matthias Klose wrote:
> Package: kfreebsd-10
> Severity: important
> Tags: sid bullseye
> User: debian-...@lists.debian.org
> Usertags: non-standard-compiler, gcc-8, gcc-8-legacy
>
> This package
Source: boost1.67
Version: 1.67.0-9
Severity: important
Hi,
boost1.67 fails to build on kbsd:
...failed updating 2 targets...
...skipped 6 targets...
...updated 1912 targets...
debian/rules:50: recipe for target 'override_dh_auto_build' failed
This may be due to these earlier errors:
Control: tags -1 confirmed
On 11/04/18 11:12, Alastair McKinstry wrote:
>
>
> On 11/04/2018 10:07, John Paul Adrian Glaubitz wrote:
>> On 04/11/2018 10:53 AM, Alastair McKinstry wrote:
>>> As of 3.0.1, openmpi now works on Big-Endian powerpc (which was to be a
>>> problem; it had been dropped
On 16/06/16 02:12, Hector Oron wrote:
> I have put up the classical wiki page for Stretch at:
> https://wiki.debian.org/ArchiveQualification/Stretch
>
> Please review and comment if required.
That page is now outdated wrt mips concerns (see below). Do we need to duplicate
the information that
Source: libvigraimpex
Version: 1.10.0+git20160211.167be93+dfsg-1
Severity: important
Your package failed to build on hurd and kfreebsd-i386:
Entering test suite GraphAlgorithmTestSuite
Failure in GraphAlgorithmTest::testEdgeWeightComputation()
Assertion failed: Sequence items differ at index 5
On 17/12/15 03:59, Steven Chamberlain wrote:
> Dear wanna-build team,
>
> Please give back monit for rebuild on kfreebsd-*, as the cause of the
> failure should be fixed now in kfreebsd-kernel-headers/10.1~8, and the
> buildd chroots should now all have that version installed:
>
> gb
On 11/12/15 11:51, Steven Chamberlain wrote:
> Dear wanna-build team,
>
> Please could all of these be given back on the indicated kfreebsd
> architectures. I expect most to build successfully now, or they
> will fail in a way that is different than before (as explained in
>
On 23/10/15 13:21, Emilio Pozuelo Monfort wrote:
> On 23/10/15 13:02, Thorsten Glaser wrote:
>> On Fri, 23 Oct 2015, Adam D. Barratt wrote:
>>
>>> wanna-build does, yes, but at least the Release Team tend to use the "wb"
>>> wrapper tool which automatic
On 23/10/15 13:02, Thorsten Glaser wrote:
> On Fri, 23 Oct 2015, Adam D. Barratt wrote:
>
>> wanna-build does, yes, but at least the Release Team tend to use the "wb"
>> wrapper tool which automatically works out the next free number on each
>> architecture.
>
> Ah, cool – so we have only to
On 23/10/15 11:20, Thorsten Glaser wrote:
> On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote:
>
>> I can go back to scheduling binNMUs for release architectures only, or for
>> ANY
>> -x32. But I don't have the time to look at every architecture and determine
>
On 23/10/15 12:23, Wookey wrote:
> +++ Emilio Pozuelo Monfort [2015-10-23 11:49 +0200]:
>> On 23/10/15 11:20, Thorsten Glaser wrote:
>
>>> How about, scheduling them all at once, but using the same version
>>> number across arches when doing it (i.e. the larges
[ Sorry for the cross-post, but I believe the people in -release and -wb-team
should see this ]
On 23/10/15 09:05, Thorsten Glaser wrote:
> Hi,
>
> whoever is scheduling binNMUs now should do so with a little
> bit more care, please.
>
> Case in point, frameworkintegration – x32 already was
On 15/06/15 18:25, Steven Chamberlain wrote:
tags 788709 + patch
thanks
Michael Biebl wrote:
Am 14.06.2015 um 16:08 schrieb Christoph Egger:
Steven Chamberlain ste...@pyro.eu.org writes:
__FreeBSD_kernel_version
I guess I knew once about this one, thanks!
Thanks for the quick reply
On 31/10/14 15:09, Christoph Egger wrote:
Ahoi!
Christoph Egger christ...@christoph-egger.org writes:
Emilio Pozuelo Monfort po...@debian.org writes:
On 31/10/14 12:43, Steven Chamberlain wrote:
kfreebsd-10 migrated last night; is there a chance another upload of
the kernel could go
On 12/09/14 16:32, Emilio Pozuelo Monfort wrote:
Yes, this doesn't seem like a traditional transition. So as long as you think
there won't be any/much breakage, and you fix the potential fallout, I think you
can go ahead with this. Of course doing the test rebuilds *before* starting this
would
Package: ftp.debian.org
Severity: normal
Hi,
mutter currently requires libgbm, which is only available on Linux. I'm
requesting the removal of the ood binaries from !linux architectures,
until that dependency can be made optional and mutter can build there
again. Since the only rdep of mutter is
Control: severity -1 important
On 01/10/14 23:04, Andreas Henriksson wrote:
Hello again!
On Wed, Oct 01, 2014 at 09:50:45PM +0100, Steven Chamberlain wrote:
[...]
Thanks, this is useful. According to this, the only reverse-deps are
linux-any packages:
| $ reverse-depends src:mutter
Source: virtuoso-opensource
Version: 6.1.6+dfsg2-1
Severity: serious
Your package failed to build on kbsd:
https://buildd.debian.org/status/fetch.php?pkg=virtuoso-opensourcearch=kfreebsd-amd64ver=6.1.6%2Bdfsg2-1stamp=1410539349
Control: tags -1 confirmed
On 10/09/14 22:10, Steven Chamberlain wrote:
Hi Emilio,
On 10/09/14 20:16, Emilio Pozuelo Monfort wrote:
[...] what
packages are involved, what packages need rebuilds, and of those, which ones
currently fail.
The root of this is kfreebsd-source-10.0, from
Control: tags -1 moreinfo
On 31/08/14 23:55, Steven Chamberlain wrote:
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Hi, This is not a mere transition but our ambition to use kFreeBSD 10.1
as our kernel version for jessie.
This is
Source: calibre
Version: 2.0.0+dfsg-1
Severity: serious
Your package started to build depend on libudev on kfreebsd (and hurd),
making it unbuildable there as libudev is linux-only.
Emilio
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
(Adding -bsd to Cc)
On 19/07/14 12:12, Bálint Réczey wrote:
Hi Emilio,
2014-07-19 11:51 GMT+02:00 Emilio Pozuelo Monfort po...@debian.org:
On 19/07/14 11:28, Balint Reczey wrote:
Control: tags -1 upstream
Control: forwarded -1 https://github.com/sahlberg/libnfs/pull/87
Hi Cyril,
Could
On 07/06/14 12:59, Romain Francoise wrote:
Package: kfreebsd-kernel-headers
Version: 10.0~5
Severity: serious
libpcap is broken on kfreebsd since kfreebsd-kernel-headers was updated
to the FreeBSD 10 headers, which apparently include this change:
On 13/06/14 15:10, Romain Francoise wrote:
Emilio Pozuelo Monfort po...@debian.org writes:
This is the last blocker for the libgnutls-deb0-28 transition. It'd be
great if someone could take a look.
If necessary I can work around this issue by disabling zerocopy BPF in
libpcap until
On 10/06/14 23:45, Emilio Pozuelo Monfort wrote:
On 02/06/14 20:13, Sebastian Ramacher wrote:
On 2014-06-02 19:59:41, Petr Salinger wrote:
I'm not sure if the file should be built on kfreebsd/hurd, or if it
shouldn't
but there should be some fallback code in python3.4. Adding the python
On 02/06/14 20:13, Sebastian Ramacher wrote:
On 2014-06-02 19:59:41, Petr Salinger wrote:
I'm not sure if the file should be built on kfreebsd/hurd, or if it
shouldn't
but there should be some fallback code in python3.4. Adding the python
maintainer, and the bsd and hurd porters to Cc.
Control: reassign -1 src:libsigsegv 2.10-2
Control: fixed -1 2.10-4
Control: affects -1 src:clisp
On 05/06/14 03:44, Steven Chamberlain wrote:
Source-Version: 1:2.49-9
Control: notfound -1 clisp/1:2.49-9
Hey, what happened to this bug?
18:17 pochu oh libdb5.1 is still in testing
18:18
On 02/06/14 19:56, Steven Chamberlain wrote:
Hi Robert,
On 02/06/14 14:36, Adam D. Barratt wrote:
There's also gnome-session. gnome-core depends on gnome-session, which
in turn depends on gnome-shell.
We'll need to make gnome-session Architecture: linux-any and remove it.
And I wonder
On 01/06/14 12:13, Sebastian Ramacher wrote:
On 2014-05-29 00:55:09, Scott Kitterman wrote:
Source: morse-simulator
Version: 1.2-2
Severity: serious
Justification: fails to build from source (but built successfully in the
past)
FTBFS on both Kfreebsd i386 and amd64. The end of the build
On 11/05/14 23:01, Robert Millan wrote:
On 11/05/14 21:06, Julien Cristau wrote:
On Sun, May 11, 2014 at 17:37:29 +0200, Robert Millan wrote:
I've uploaded an NMU with the removal of kfreebsd-any (and hurd-any
as per porter's request) from Architecture. A debdiff is attached.
Do you plan on
On 30/05/14 17:57, Steven Chamberlain wrote:
Hi Emilio,
On 16:01, Emilio Pozuelo Monfort wrote:
Just a reminder: there are still various things depending on the removed
packages, preventing things from migrating to testing.
Do you agree it's just the two metapackages from src:meta-gnome3
On 07/11/13 11:35, Emilio Pozuelo Monfort wrote:
Great! I even see you have already committed a fix to eglibc. :-)
That's been uploaded and built. It'd be great to have pango1.0 given back when
the chroots are updated.
Thanks,
Emilio
--
To UNSUBSCRIBE, email to debian-bsd-requ
On 07/11/13 09:07, Petr Salinger wrote:
ulimit -S of stack size:
linux-i386: 8 MB
linux-amd64:8 MB
kfreebsd-i386: 8 MB
kfreebsd-amd64: 8 MB
ulimit -H of stack size:
linux-i386: unlimited
linux-amd64:unlimited
kfreebsd-i386: 64 MB
kfreebsd-amd64: 512 MB
On 29/10/13 00:46, Emilio Pozuelo Monfort wrote:
On 28/10/13 23:49, Steven Chamberlain wrote:
On 28/10/13 14:33, Emilio Pozuelo Monfort wrote:
The test is trying to create 100 threads, but pthread_create returns EAGAIN
because it hits some limit, which makes g_thread_new() abort (as stated
Hi,
On 06/11/13 21:57, Steven Chamberlain wrote:
I found this is caused by 'make' raising RLIMIT_STACK from the default
setting of 8192k to its maximum, 65536k. It is reproducible from the
shell by setting ulimit -s 65536 before running the test program directly.
Thanks for the analysis!
I
On 21/10/13 15:54, Michael Biebl wrote:
Source: pango1.0
Version: 1.36.0-1
Severity: serious
User: debian-bsd@lists.debian.org
pango1.0 FTBFS on kfreebsd-i386 when executing the test-suite:
/«PKGBUILDDIR»/./test-driver: line 95: 41714 Trace/breakpoint trap $@
$log_file 21
FAIL:
On 28/10/13 23:49, Steven Chamberlain wrote:
On 28/10/13 14:33, Emilio Pozuelo Monfort wrote:
The test is trying to create 100 threads, but pthread_create returns EAGAIN
because it hits some limit, which makes g_thread_new() abort (as stated in
the
docs, g_thread_try_new() wouldn't abort
Version: 2.0.2-1
On 25/06/13 23:18, Emilio Pozuelo Monfort wrote:
On 25/06/13 22:41, Christoph Egger wrote:
Aurelien Jarno aurel...@aurel32.net writes:
That's something I can try if the above fails, but I first need to
setup a machine with enough swap, mine currently don't have so much
Hi,
On 20/06/13 18:41, Petr Salinger wrote:
The test-suite for glib2.0 fails to complete on kfreebsd-* as can be
seen at [1]. On both kfreebsd-amd64 and kfreebsd-i386 the test-suite is
killed after 150 min of inactivity.
We would appreciate any help and insight from the kfreebsd to fix
On 17/06/13 09:43, Emilio Pozuelo Monfort wrote:
On 16/06/13 12:11, Christoph Egger wrote:
Hi!
Petr Salinger petr.salin...@seznam.cz writes:
Please, could it be rescheduled on buildd with really
lot of RAM and swap space ?
We have fano and fayrfax. Both of which have 3GiB real RAM
On 25/06/13 11:01, Emilio Pozuelo Monfort wrote:
On 17/06/13 09:43, Emilio Pozuelo Monfort wrote:
On 16/06/13 12:11, Christoph Egger wrote:
Hi!
Petr Salinger petr.salin...@seznam.cz writes:
Please, could it be rescheduled on buildd with really
lot of RAM and swap space ?
We have fano
On 16/06/13 12:11, Christoph Egger wrote:
Hi!
Petr Salinger petr.salin...@seznam.cz writes:
Please, could it be rescheduled on buildd with really
lot of RAM and swap space ?
We have fano and fayrfax. Both of which have 3GiB real RAM and 0.5GiB
SWAP. I can probably ask DSA to give me some
Hi,
Thanks for the info!
On 11/06/13 22:28, Steven Chamberlain wrote:
Hi,
On kfreebsd-* arches it is the lt-ntlm-test that doesn't finish and
causes the build process to hang.
In the buildd logs its output is not shown, probably being buffered
somehow, but running it manually it gets
On 15/06/13 23:53, Emilio Pozuelo Monfort wrote:
On 11/06/13 22:28, Steven Chamberlain wrote:
Sometimes it completes the whole testsuite, in which case it (always)
returns 2 errors instead:
External helper support
Round 2: NTLM Connection, user=alice
(S:sent) (S:alice) /noauth
On 17/05/13 05:37, Jeff Epler wrote:
OK, this seems crazy to me but I feel obliged to note it:
When I build 3.8.1-3 in /usr/src or /tmp/wat, I can observe the failure when I
subsequently 'make check' in build-2.7/tests. When I build it in /tmp or
Hurd seems to hang at the same place[1]. Perhaps that helps in determining where
the bug may lie (e.g. if both Hurd and kfreebsd use the same pthread library
implementation).
[1]
https://buildd.debian.org/status/fetch.php?pkg=pygobjectarch=hurd-i386ver=3.8.1-3stamp=1368332988
--
To
On 12/05/13 15:40, Christoph Egger wrote:
Emilio Pozuelo Monfort po...@debian.org writes:
Package: pygobject
Version: 3.8.1-2
Severity: serious
(CCing BSD porters, help wanted here)
pygobject currently fails to build on kfreebsd, see [1]
I've tried to debug this on falla. I can reproduce
Package: pygobject
Version: 3.8.1-2
Severity: serious
(CCing BSD porters, help wanted here)
pygobject currently fails to build on kfreebsd, see [1]
I've tried to debug this on falla. I can reproduce the hang somewhat reliably
by running:
dpkg-buildpackage
And if it doesn't hang or if you want
48 matches
Mail list logo
