Re: llvm-toolchain-* future on kfreebsd
Hello,
Le 19/10/2019 à 12:09, Sylvestre Ledru a écrit :
Hello,
Le 03/02/2019 à 15:28, Svante Signell a écrit :
Currently llvm-toolchain-7 FTBFS on GNU/kFreeBSD dues to a missing
port to that
architecture. Attached are 14 patches...
clang_lib_Basic_Targets.diff
[...]
tools_llvm-shlib_CMakeLists.txt.diff
Additionally, the install file for liblldb-7 needs a separate file:
liblldb-
7.install.kfreebsd. Adding [!kfreebsd-any] to the last row of
liblldb-7.install
(or liblldb-X.Y.install.in) did not work.
I will submit these patches to upstream too, in due time.
AFAIK, this didn't happen. I have been spending a bunch of time
rebasing kfreebsd
patches for llvm-toolchain-{8,9,snapshot}.
Also, llvm-toolchain-8 never built on kfreebsd
https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-8=kfreebsd-amd64
https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-8=kfreebsd-i386
I am ok to keep them if there are some work on the llvm & clang to see
them upstreamed but
i am wondering if we should not disable them.
Please let me know if there is any plan for kfreebsd.
As I didn't get any answer, I disabled the application of kfreebsd
specific patches.
I am spending too much time rebasing them.
Cheers
Sylvestre
llvm-toolchain-* future on kfreebsd
Hello,
Le 03/02/2019 à 15:28, Svante Signell a écrit :
Currently llvm-toolchain-7 FTBFS on GNU/kFreeBSD dues to a missing port to that
architecture. Attached are 14 patches...
clang_lib_Basic_Targets.diff
[...]
tools_llvm-shlib_CMakeLists.txt.diff
Additionally, the install file for liblldb-7 needs a separate file: liblldb-
7.install.kfreebsd. Adding [!kfreebsd-any] to the last row of liblldb-7.install
(or liblldb-X.Y.install.in) did not work.
I will submit these patches to upstream too, in due time.
AFAIK, this didn't happen. I have been spending a bunch of time rebasing
kfreebsd
patches for llvm-toolchain-{8,9,snapshot}.
Also, llvm-toolchain-8 never built on kfreebsd
https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-8=kfreebsd-amd64
https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-8=kfreebsd-i386
I am ok to keep them if there are some work on the llvm & clang to see
them upstreamed but
i am wondering if we should not disable them.
Please let me know if there is any plan for kfreebsd.
Thanks!
Cheers,
Sylvestre
Re: GNU/kFreeBSD sprint, fast porterbox access
On 14/09/2014 00:50, Steven Chamberlain wrote: Hi, I'm going to privately rent a VM from BigV.io for approximately one week to do some Debian GNU/kFreeBSD work: * to test jessie d-i, particularly partman-zfs * clang-3.4, #759303: Does not have multiarch include paths on !linux * kfreebsd 10.1, #760114: transition: kfreebsd-kernel-headers * gcc-4.9, #761277: gdc uninstallable on kfreebsd because of missing dep. libphobos-4.9-dev If anyone would find it useful, please send me your SSH public key (via GPG-signed email, please) and you can have access. But remember the machine will be gone in 7 to 10 days from now. I can help with the clang issue. I will send you my key in the separate email. If you can start the build + provide a test case, it would help a lot :) I know I am stating the obvious but having that permanent would help a lot... With whatever time is left I'll try to rebuild (only once) all of build-essential and perhaps other things. Maybe you could be interested to get in touch with David Suarez (as cc) who is doing the rebuild of Debian for amd64 using our Debian AWS credit. Cheers, Sylvestre -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54155d62.7030...@debian.org
Re: Bug#759303: Does not have multiarch include paths on !linux
On 02/09/2014 01:57, Steven Chamberlain wrote: severity 759303 grave thanks Hi, Sorry - this bug prevents us from migrating src:kfreebsd-10 away from clang-3.3, so by implication this bug has RC-severity too. The fix is possibly the same one mentioned (but wasn't disclosed) in: https://bugs.debian.org/731711#20, if that helps at all. I tried a few times to fix that but the porterbox failed at some point (too slow or not enough memory to link libclang...). Christoph told me that should be improved soon, I could have a look. Sylvestre -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54055dbb.9010...@debian.org
Re: qiime REMOVED from testing
On Wed, 22 Jan 2014 13:02:39 +0100 Andreas Tille andr...@an3as.eu wrote: Hi Steven, If the libjogl-java dependency is dropped, king should be installable on kfreebsd and then so would qiime. And libjogl2-java transition can go ahead. Most probably this would be the most simple solution. OK. Any progress on this ? I would like to remove jogl v1 for Jessie and it is the last package using it. Thanks Sylvestre -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e77499.8000...@debian.org
Bug#754799: kfreebsd-10: Please update the clang dependency from 3.3 to 3.4
On 15/07/2014 13:37, Steven Chamberlain wrote: On 14/07/14 15:08, Steven Chamberlain wrote: [...] 10.0 is very likely to work with clang-3.4, and 10-STABLE already been heavily tested with it, perhaps only needing some small changes backported to 10.0, if anything. [...] Depending how soon the clang-3.3 removal ought to happen, after some testing in experimental, we could upload a 10.0 built with clang-3.4 and these patches (but no DEBUG options) to sid. I would like to see the removal done before Jessie... So, that should give you some time. Cheers, Sylvestre signature.asc Description: OpenPGP digital signature
Bug#754799: kfreebsd-10: Please update the clang dependency from 3.3 to 3.4
Source: kfreebsd-10 Severity: important Hello, Could you update the clang build dep from 3.3 to 3.4? It prevents the removal of llvm clang 3.3. Thanks, Sylvestre -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (600, 'unstable'), (500, 'stable-updates'), (500, 'stable'), (300, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140714121126.26480.82203.report...@leyte.mozilla.com
llvm-toolchain-snapshot FTBFS kfreebsd-amd64
Hello LLVM snapshot is failing to build because of: if g++-4.9 -I/«PKGBUILDDIR»/build-llvm/include -I/«PKGBUILDDIR»/build-llvm/tools/lldb/source/Host/freebsd -I/«PKGBUILDDIR»/include -I/«PKGBUILDDIR»/tools/lldb/source/Host/freebsd -DNDEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/«PKGBUILDDIR»/tools/lldb/source/Host/freebsd/../../../include -I/«PKGBUILDDIR»/build-llvm/tools/lldb/source/Host/freebsd/../../../include -I/«PKGBUILDDIR»/tools/clang/include -I/«PKGBUILDDIR»/build-llvm/tools/clang/include -I/«PKGBUILDDIR»/tools/lldb/source/Host/freebsd/../../../source -I/«PKGBUILDDIR»/tools/lldb/source/Host/freebsd/../../../source/Utility -I/«PKGBUILDDIR»/tools/lldb/source/Host/freebsd/../../../source/Plugins/Process/Utility -I/«PKGBUILDDIR»/tools/lldb/source/Host/freebsd/../../../source/Plugins/Process/POSIX -I/usr/include/python2.7 -I/usr/include/x86_64-kfreebsd-gnu/python2.7 -g -O2 -std=c++11 -fvisibility-inlines-hidden -fno-exceptions -fPIC -Woverloaded-virtual -ffunction-sections -fdata-sections -Wcast-qual -fno-strict-aliasing -std=c++0x -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 -I/usr/local/include -D_FORTIFY_SOURCE=2 -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-unknown-pragmas -Wno-sign-compare -Wno-sign-compare -Wno-unused-function -Wno-maybe-uninitialized -Wno-missing-field-initializers -c -MMD -MP -MF /«PKGBUILDDIR»/build-llvm/tools/lldb/source/Host/freebsd/Release/Host.d.tmp -MT /«PKGBUILDDIR»/build-llvm/tools/lldb/source/Host/freebsd/Release/Host.o -MT /«PKGBUILDDIR»/build-llvm/tools/lldb/source/Host/freebsd/Release/Host.d /«PKGBUILDDIR»/tools/lldb/source/Host/freebsd/Host.cpp -o /«PKGBUILDDIR»/build-llvm/tools/lldb/source/Host/freebsd/Release/Host.o ; \ then /bin/mv -f /«PKGBUILDDIR»/build-llvm/tools/lldb/source/Host/freebsd/Release/Host.d.tmp /«PKGBUILDDIR»/build-llvm/tools/lldb/source/Host/freebsd/Release/Host.d; else /bin/rm /«PKGBUILDDIR»/build-llvm/tools/lldb/source/Host/freebsd/Release/Host.d.tmp; exit 1; fi /«PKGBUILDDIR»/tools/lldb/source/Host/freebsd/Host.cpp: In static member function 'static std::string lldb_private::Host::GetThreadName(lldb::pid_t, lldb::tid_t)': /«PKGBUILDDIR»/tools/lldb/source/Host/freebsd/Host.cpp:101:55: error: 'reallocf' was not declared in this scope kp = (struct kinfo_proc *)reallocf(kp, len); ^ Can someone have a look? Full log: https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-snapshotarch=kfreebsd-amd64ver=1%3A3.5~svn211669-1stamp=1403792372 FYI, 3.4 is building. Thanks, Sylvestre -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ac4e25.9010...@debian.org
New upstream of libedit + UTF8
Hello, You receive this email because of your package has libedit as build-dep [1] (and because libedit has a crazy popcon and I don't want to break all packages). A few days ago, I uploaded a new upstream version of libedit (3.1-20140213-1~exp1). I also turned on the utf-8 support (for more information, http://bugs.debian.org/737786 https://bugs.launchpad.net/ubuntu/+source/libedit/+bug/816758 https://bugs.launchpad.net/ubuntu/+source/libedit/+bug/1276836 ) Both changes are available in experimental I would appreciate if you could test if these changes haven't break your packages. I am planning to upload March 7th (Friday). Thanks, Sylvestre [1] grep-dctrl -F Build-Depends libedit-dev -s Maintainer -s Uploaders /var/lib/apt/lists/*unstable*_Sources -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/530e2f82.3040...@debian.org
Re: where is eclipse?
On 06/09/2013 23:24, Steven Chamberlain wrote: On 06/09/13 21:55, Robert Millan wrote: The way I see it, as things stand now it makes a lot more sense to bypass default-jdk in order to get things working... What do you mean by that? To tighten the build-dependencies of eclipse and others, that can't build with gcj? I think the risk is that openjdk-7 could be removed from kfreebsd-* in sid at the request of the maintainer, if we're unable to keep it building+working. We may then lose packages that FTBFS without it (but if we don't change, we'd never have had them in the first place). Other packages should fall back to gcj and still be okay. I think that pushing to upstream the changes done for the Kfreebsd port would be the way to ensure that it is maintained... It seems we could go ahead without treating this like a transition. I was thinking we may want to ask the Release Team for rebuilds of some already-built packages to use the new java-defaults. Even if that's refused, it's still not a problem. And given the risk of maybe losing openjdk-7 or otherwise having to go back to gcj, maybe we shouldn't bother doing that at all. So, what do you say we just go ahead with changing java-defaults? I think it is the best solution that we have for Kfreebsd currently. Sylvestre -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/522a494f.4080...@debian.org
Re: FreeBSD 9.1 and Clang
Hello First, I am really sorry for the lag about this message. I missed it :/ On 24/06/2013 16:32, Robert Millan wrote: 2013/6/23 Sylvestre Ledru sylves...@debian.org: I would like to ask which versions of clang are expected to be released with jessie? Clearly, I cannot exactly answer to that question. For now, there are two releases per year. 3.3 just been released. A basic (and probably wrong) estimate could be 3.7 [1]. Also, is there a possibility of clang-3.2 or newer being available through wheezy-backports? I would prefer the 3.3 if that is OK with you. Hi Sylvestre, What is your policy for removal of old releases in general? One of the reasons we want this is because of the GCC maintainers' aggressive policy towards removal of old releases. We've been burnt a few times because of a version of GCC we depend on being remove at inappropiate time. I don't really have any policy for now. I am trying to maintain 2.5 releases of the llvm toolchain in Debian. Currently, we have: * 3.2 * 3.3 The 0.5 is for the snapshot release. For now, I am not really planning to maintain 3 of them (except for the month or couple of months after an upstream release). In general, our needs are determined by what FreeBSD is using for their releases (the less we diverge from them, the less trouble for us). For wheezy, we're considering a backport of kfreebsd 9.1. For this version, we could do with clang-3.1 which is what upstream used for that release. Is there any chance we can have clang-3.1 in wheezy/updates (or wheezy/backports)? This version is starting to pretty old... :/ For jessie, it is likely that we'll need clang-3.2 or clang-3.3. However it is not clear yet, as it depends on the version that will be finally used for newer releases in kfreebsd 9.x series. Let's say that the llvm community continues at the same pace. We will probably be at clang 3.5 or 3.6. That is an important difference ... :/ It is possible to obtain a commitment from you to provide whichever version of clang FreeBSD uses for the latest 9.x release at any given time? This would basically just imply not removing certain versions until FreeBSD has moved on to the next one. I am not sure to be able to commit to such things for now unfortunately. As you can imagine, the llvm-toolchain packages are big packages which can be tricky to maintain... Anyway, I will keep in mind your needs and I propose you contact me again once you know what you need (and I will try not skipping your email :p) Sylvestre -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/521f1b60.7010...@debian.org
Re: default-jdk change on kfreebsd
On 17/08/2013 16:21, Christoph Egger wrote: Moin! Steven Chamberlain ste...@pyro.eu.org writes: On 16/08/13 13:15, Christoph Egger wrote: I talked to rene here at DebConf. The problems did show up in the past when running the testsuite (hangs). Rene tried with current OpenJDK on falla -- in current kfreebsd sid -- and it does now works as well as anywhere on !linux-x86 which means we should be fine from this side. Should we treat this as a transition co-ordinated with the release team, so that all rdepends are rebuilt? I'd actually prefer this in any case; it would fix some past build failures such as eclipse. And possibly libjogl-java, leading to scilab and more being built. (But perhaps these packages should also have had tighter Build-Depends if gcj is insufficient.) I've been talking with Julien from the release team and Damien, the openjdk maintainer here at DebConf. Switching could -- as far as I understand -- work as follows: * Make openjdk-7 default. No other actions needed and should work for a start I will be happy to perform this change when you want. Thanks, Sylvestre -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/520fb6d1.5060...@debian.org
Re: New version of libedit in experimental: tests welcome
Hello, The release in experimental of libedit received some good feedbacks (btw, thanks to Guillem Jover). I am planning to upload it soon in the archive. So, if you haven't tested libedit yet, please go ahead! Thanks! Cheers, Sylvestre On 02/08/2013 19:34, Sylvestre Ledru wrote: Hello, You are receiving this email because you maintain one (or more) package using libedit. I just uploaded in experimental a new upstream version of libedit published here: http://www.thrysoee.dk/editline/ It would be nice if you could test if your packages still behave the same. I am not really worried but since it is an important package, I would like confirmations. Thanks, Sylvestre Here is the list: $ build-rdeps --print-maintainer libedit-dev Reverse Build-depends in contrib: - No reverse build-depends found for libedit-dev. Reverse Build-depends in main: -- boxbackup (Reinhard Tartler siret...@tauware.de) heimdal (Brian May b...@debian.org) varnish (Varnish Package Maintainers pkg-varnish-de...@lists.alioth.debian.org) repmgr (Marco Nenciarini mnen...@debian.org) ocropus (Jeffrey Ratcliffe jeffrey.ratcli...@gmail.com) mapserver (Debian GIS Project pkg-grass-de...@lists.alioth.debian.org) gnuplot (Debian Science Team debian-science-maintain...@lists.alioth.debian.org) llvm-toolchain-snapshot (LLVM Packaging Team pkg-llvm-t...@lists.alioth.debian.org) php5 (Debian PHP Maintainers pkg-php-ma...@lists.alioth.debian.org) ufsutils (GNU/kFreeBSD Maintainers debian-bsd@lists.debian.org) ntp (Debian NTP Team pkg-ntp-maintain...@lists.alioth.debian.org) ceph (Laszlo Boszormenyi (GCS) g...@debian.hu) haskell-editline (Debian Haskell Group pkg-haskell-maintain...@lists.alioth.debian.org) llvm-toolchain-3.3 (LLVM Packaging Team pkg-llvm-t...@lists.alioth.debian.org) postgresql-9.1 (Debian PostgreSQL Maintainers pkg-postgresql-pub...@lists.alioth.debian.org) chrony (Debian QA Group packa...@qa.debian.org) firebird2.5 (Debian Firebird Group pkg-firebird-gene...@lists.alioth.debian.org) freebsd-utils (GNU/kFreeBSD Maintainers debian-bsd@lists.debian.org) openssh (Debian OpenSSH Maintainers debian-...@lists.debian.org) uim (HIGUCHI Daisuke (VDR dai) d...@debian.org) llvm-toolchain-3.2 (LLVM Packaging Team pkg-llvm-t...@lists.alioth.debian.org) libreadline-java (Debian Java Maintainers pkg-java-maintain...@lists.alioth.debian.org) prerex (Ryan Kavanagh r...@debian.org) postgres-xc (Vladimir Stavrinov vstavri...@gmail.com) Found a total of 24 reverse build-depend(s) for libedit-dev. Reverse Build-depends in non-free: -- ngspice (Debian Science Team debian-science-maintain...@lists.alioth.debian.org) Found a total of 1 reverse build-depend(s) for libedit-dev. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/520c8aaa.2080...@debian.org
New version of libedit in experimental: tests welcome
Hello, You are receiving this email because you maintain one (or more) package using libedit. I just uploaded in experimental a new upstream version of libedit published here: http://www.thrysoee.dk/editline/ It would be nice if you could test if your packages still behave the same. I am not really worried but since it is an important package, I would like confirmations. Thanks, Sylvestre Here is the list: $ build-rdeps --print-maintainer libedit-dev Reverse Build-depends in contrib: - No reverse build-depends found for libedit-dev. Reverse Build-depends in main: -- boxbackup (Reinhard Tartler siret...@tauware.de) heimdal (Brian May b...@debian.org) varnish (Varnish Package Maintainers pkg-varnish-de...@lists.alioth.debian.org) repmgr (Marco Nenciarini mnen...@debian.org) ocropus (Jeffrey Ratcliffe jeffrey.ratcli...@gmail.com) mapserver (Debian GIS Project pkg-grass-de...@lists.alioth.debian.org) gnuplot (Debian Science Team debian-science-maintain...@lists.alioth.debian.org) llvm-toolchain-snapshot (LLVM Packaging Team pkg-llvm-t...@lists.alioth.debian.org) php5 (Debian PHP Maintainers pkg-php-ma...@lists.alioth.debian.org) ufsutils (GNU/kFreeBSD Maintainers debian-bsd@lists.debian.org) ntp (Debian NTP Team pkg-ntp-maintain...@lists.alioth.debian.org) ceph (Laszlo Boszormenyi (GCS) g...@debian.hu) haskell-editline (Debian Haskell Group pkg-haskell-maintain...@lists.alioth.debian.org) llvm-toolchain-3.3 (LLVM Packaging Team pkg-llvm-t...@lists.alioth.debian.org) postgresql-9.1 (Debian PostgreSQL Maintainers pkg-postgresql-pub...@lists.alioth.debian.org) chrony (Debian QA Group packa...@qa.debian.org) firebird2.5 (Debian Firebird Group pkg-firebird-gene...@lists.alioth.debian.org) freebsd-utils (GNU/kFreeBSD Maintainers debian-bsd@lists.debian.org) openssh (Debian OpenSSH Maintainers debian-...@lists.debian.org) uim (HIGUCHI Daisuke (VDR dai) d...@debian.org) llvm-toolchain-3.2 (LLVM Packaging Team pkg-llvm-t...@lists.alioth.debian.org) libreadline-java (Debian Java Maintainers pkg-java-maintain...@lists.alioth.debian.org) prerex (Ryan Kavanagh r...@debian.org) postgres-xc (Vladimir Stavrinov vstavri...@gmail.com) Found a total of 24 reverse build-depend(s) for libedit-dev. Reverse Build-depends in non-free: -- ngspice (Debian Science Team debian-science-maintain...@lists.alioth.debian.org) Found a total of 1 reverse build-depend(s) for libedit-dev. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51fbed89.8070...@debian.org
::waitpid under kfreebsd ?
Hello I am trying to fix the build of lldb as part of the llvm-toolchain-3.2 package. However, it is failing on: lvm-toolchain-3.2-3.2repack/tools/lldb/source/Host/common/Host.cpp:156:38: error: '::waitpid' has not been declared The code is: const lldb::pid_t wait_pid = ::waitpid (pid, status, options); The full log is available here: https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-3.2arch=kfreebsd-amd64ver=1%3A3.2repack-3stamp=1368549460 Does it ring a bell to anyone ? Thanks Sylvestre -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/519359aa.9070...@debian.org
Re: ::waitpid under kfreebsd ?
On 15/05/2013 15:04, Petr Salinger wrote: However, it is failing on: lvm-toolchain-3.2-3.2repack/tools/lldb/source/Host/common/Host.cpp:156:38: error: '::waitpid' has not been declared The code is: const lldb::pid_t wait_pid = ::waitpid (pid, status, options); The full log is available here: https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-3.2arch=kfreebsd-amd64ver=1%3A3.2repack-3stamp=1368549460 Does it ring a bell to anyone ? waipid() is declared in sys/wait.h and provided by libc. Missing include ? Right, thanks :) #elif defined (__linux__) #include sys/wait.h #elif defined (__FreeBSD__) Sylvestre -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51938b9e.1070...@debian.org
Re: Bug#645546: clang: FTBFS(kfreebsd): error: Operating system is unknown, configure can't continue
Le dimanche 13 novembre 2011 à 01:06 +0100, Julien Cristau a écrit : On Mon, Oct 17, 2011 at 19:40:56 +0200, Christoph Egger wrote: Hi! Sylvestre Ledru sylves...@debian.org writes: Le dimanche 16 octobre 2011 à 23:26 +0200, Christoph Egger a écrit : cd build-clang \ ../llvm-2.9/configure CC=x86_64-kfreebsd-gnu-gcc CXX=x86_64-kfreebsd-gnu-g++ CPP=x86_64-kfreebsd-gnu-cpp --with-c-include-dirs=/usr/include/x86_64-kfreebsd-gnu:/usr/include --with-cxx-include-root=/usr/include/c++/4.6 --with-cxx-include-arch=x86_64-kfreebsd-gnu --host=x86_64-kfreebsd-gnu --build=x86_64-kfreebsd-gnu --with-cxx-include-32bit-dir=32 --prefix=/usr --disable-assertions --enable-shared --enable-optimized --with-optimize-option=' -g -O2' --enable-pic --enable-libffi CLANG_VENDOR=Debian checking build system type... x86_64-pc-kfreebsd-gnu checking host system type... x86_64-pc-kfreebsd-gnu checking target system type... x86_64-pc-kfreebsd-gnu checking type of operating system we're going to host on... Unknown checking type of operating system we're going to target... Unknown configure: error: Operating system is unknown, configure can't continue make: *** [/build/buildd-clang_2.9-16-kfreebsd-amd64-JQnCYR/clang-2.9/debian/stamps/configure-stamp-clang] Error 1 I wonder if it is not caused by an update of a dependency. Could it be possible to have access to the config.log file ? It is generally not possible to get at the files from the buildds. I've run a build on my local kfreebsd box (though with ocaml-nox installed) and put the log on http://people.debian.org/~christoph/clang.config.log Any progress here? Salut Julien, clang 3.0 will be released in the new few days. http://llvm.org/ November 16th — Release! I will have a look at this time since I started to package this release ;) Sylvestre -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1321157192.2646.1.ca...@pomegues.inria.fr
Re: LLVM 2.8 on kfreebsd
Le samedi 25 juin 2011 à 13:28 +, Christoph Egger a écrit : Hi all! Looking into that again. I have now built llvm-2.8 successfully in the buildd chroot with the following patch. So it seems to indeed be a problem with running the testsuite in parallel. Additionally the (seemingly) same problem manifests itself with llvm-2.9 without wrapping in a schroot or something so that might help debugging. I'll dig a bit deeper still and will report when I find something. If you don't hear back today it will unfortunately be stuck behind work again, I'll come back as I find time but would be happy if someone else finds a way to resolv this. The patch might even work as a workaround (potentially conditionalized on kFreeBSD). Impressive result. Thanks for digging this issue. Can I ask how you found the issue ? You just though Ok, I am going to try without the parallel testsuite ! or you found a lead before ? Your patch is (almost) fine for me as a workaround. I just would like to enable the sequential build just for kfreebsd . We could report a bug upstream. Well done! Sylvestre -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1309026291.27677.40.ca...@losinj.inria.fr
Re: Different behavior in the chroot and build services
Hello, Le mardi 31 mai 2011 à 15:33 +0200, Petr Salinger a écrit : Anyway, the difference between buildd and porter machine is also CPU. On one my machine (and seems also on both GNU/kFreeBSD builld) make getarch_2nd fails. The param.h handles OPTERON, but not INTEL_UNKNOWN as generated by getarch 1: Thanks for spotting that. I think it is the issue. Could you share the output of /proc/cpuinfo ? I would like to report a bug upstream on this (looks like it does not fall-back on the generic define if it cannot detect the CPU). Since I have no way to reproduce myself the issue, would you mind to test some stuff for me ? 1) Just apply displayCpuInfo.diff (forceGeneric.diff should not be applied here) and type make getarch 2) Apply forceGeneric.diff it should fix the report issue. If you don't have time for that, no worries. many thanks, Sylvestre -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1307543129.10829.37.ca...@losinj.inria.fr
Different behavior in the chroot and build services
Hello, I am trying to port Openblas / Gotoblas to Kfreebsd. It is building fine with asdfasdf io (chroot unstable) but it fails with the build services: https://buildd.debian.org/status/package.php?p=openblassuite=experimental Any hints ? Thanks Sylvestre PS: Please C/C me. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1306825316.4606.62.ca...@korcula.inria.fr
Re: Different behavior in the chroot and build services
Hello, Thanks for the quick answer. Le mardi 31 mai 2011 à 09:59 +0200, Petr Salinger a écrit : Hello, I am trying to port Openblas / Gotoblas to Kfreebsd. It is building fine with asdfasdf io (chroot unstable) but it fails with the build services: https://buildd.debian.org/status/package.php?p=openblassuite=experimental Any hints ? Some time-skew ? Pardon my ignorance but what is time-skew ? I guess that getarch_2nd.c should not be compiled during make clean. It is indeed a bug but I don't think it is related to my problem here. Sylvestre -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1306844795.4606.99.ca...@korcula.inria.fr
Re: Different behavior in the chroot and build services
Le mardi 31 mai 2011 à 14:46 +0200, Cyril Brulebois a écrit : Sylvestre Ledru sylves...@debian.org (31/05/2011): Pardon my ignorance but what is time-skew ? That's described a bit in that documentation: /usr/share/doc/autotools-dev/README.Debian.gz OK thanks. However, openblas is not using autotools here... Sylvestre -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1306846129.4606.101.ca...@korcula.inria.fr
