Re: [Pkg-dns-devel] What to do with isc-dhcp-client-udeb?
Hi KiBi, I would also love to get rid of the isc-dhcp-client-udeb, but so far the message from the busybox team was that the dhcp client there doesn't compile there and needs some upstream work to get it working. (As a matter of fact, the busybox doesn't compile at all on kfreebsd-* and hurd-i386 right now.) As for the BIND libraries and libatomic. There has been some effort to replace the custom atomic code with a C-provided counterpart - it also fixes the mips deadlocks. But generally, I would prefer to move all BIND libraries into "custom" namespace, so the libraries are not used by anything else, and either: a) use the custom copy of the libraries inside isc-dhcp b) prepare separate package for the lib-udeb that would follow the BIND 9.11 development (BIND 9.11 is to be supported for next 4 years) and then remove those AND isc-dhcp from Debian. The upcoming ISC-DHCP release 4.4.0 is ought to be the _last_ major upgrade, see: https://www.isc.org/blogs/isc-dhcp-the-last-branch/ And if porting udhcpc to kFreeBSD proves to be much work, then perhaps porting dhclient from OpenBSD might be an option? Ondrej -- Ondřej Surý <ond...@sury.org> On Mon, Jan 22, 2018, at 16:20, Cyril Brulebois wrote: > Hi bind9 people, > > I've just gotten this: > > > Subject: udeb uninstallability trend: worse (+18/-) > udeb uninstallability watcher <debian-b...@lists.debian.org> (2018-01-22): > > Newly-broken packages in testing > > isc-dhcp-client-udeb armel mips mipsel > > libdns-export169-udebarmel mips mipsel > > libirs-export160-udebarmel mips mipsel > > libisc-export166-udebarmel mips mipsel > > libisccc-export160-udeb armel mips mipsel > > libisccfg-export160-udeb armel mips mipsel > > > > Uninstallability trend: worse (+18/-0) > > Uninstallability count: 397 > > I happened to have missed its unstable counterpart, because those come in > batches, depending on the current buildd status of packages. I thought the > “Newly-broken” packages for armel, mips, and mipsel were an artifact of > late builds. > > I don't know anything about this libatomic1; but from a look at the 0013 > patch, it seems to be a need for a platform rather than for a feature… > > Anyway, I'm not sure what to do with isc-dhcp-client-udeb; it's getting > broken on a regular fashion, and its purpose was mainly for non-Linux > ports AFAICR. > > I'm not sure how BSD is doing these days; maybe hurd is the only user > left? > > > Cheers, > -- > Cyril Brulebois (k...@debian.org)<https://debamax.com/> > D-I release manager -- Release team member -- Freelance Consultant > ___ > pkg-dns-devel mailing list > pkg-dns-de...@lists.alioth.debian.org > https://lists.alioth.debian.org/mailman/listinfo/pkg-dns-devel > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature)
Re: isc-dhcpd vs udhcpd
Just to rephrase my original request then... Personally, I don't really care about the DHCP client used in d-i, but I do care about complexity in the bind9 packaging. The --without-openssl support will go away (probably in BIND 9.13) and I would rather unify the two sets of libraries into one. If that means shuffling symbols around, so we don't end up with libxml2, libjson and libgeoip in d-i, then I will rather make it happen in upstream So the main difference between export and non-export libraries are: Are these a problem? * krb5 / gssapi # guess this is a problem, as krb5 has not udebs * libcap2 # guess not, there's a udeb These have to definitely go: * libgeoip1 (I have no idea why it's linked to libisc) * libxml2 (I have no idea why it's linked to libisc) Cheers, Ondrej -- Ondřej Surý <ond...@sury.org> On Mon, Oct 23, 2017, at 13:21, Philipp Kern wrote: > On 23.10.2017 09:36, Ondřej Surý wrote: > > while revising bind9 udebs, KiBi suggested that non-Linux architectures > > might be using isc-dhcpd instead of udhcpd due some problems and it > > might be a good idea to revise the decision now that we have a busybox > > maintainer? > > Ubuntu has used dhclient for a long time now in d-i. I think there are > at least two parts to it: a) consistency across architectures - it is > weird to support two completely different implementations and b) > actually use the same implementation than the installed system would > rather than something embedded that has less features. > > I recall times at work where we had severe issues with dhclient not > staying around in the background refreshing the lease. I have no idea if > this is still the case, I just recall that -1 behavior was kind of a > mess. Back then we bumped the lease duration. If picking udhcpc means > that we can address such issues more easily, that's better. > > At the same time people know how to configure dhclient and can use a > similar config as in the installed system. My understanding is that > udhcpc has essentially no options at all (like sending additional DHCP > options). > > netcfg also did not receive that much love in recent times and I wonder > if something more integrated wouldn't be better than the hacks layered > on top of each other to make it work we have today. But at the same time > I know that something modern like systemd-networkd won't work for d-i > either because of architecture consistency. :/ > > Kind regards > Philipp Kern
isc-dhcpd vs udhcpd
Hi, while revising bind9 udebs, KiBi suggested that non-Linux architectures might be using isc-dhcpd instead of udhcpd due some problems and it might be a good idea to revise the decision now that we have a busybox maintainer? Cheers, -- Ondřej Surý <ond...@sury.org>
Re: Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation
On Thu, Feb 28, 2013 at 8:49 PM, Julien Cristau jcris...@debian.org wrote: Is there any way you could work around this in opendnssec? E.g. by not building the doc on that arch for now? I could, and it was the plan if nobody comes up with some clever idea till the end of the week. O. -- Ondřej Surý ond...@sury.org -- 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/CALjhHG_77cPK6oX0rZ3LUMCKPfOggexRh=fhyxbitneljbb...@mail.gmail.com
Re: kfreebsd buildd
Just to add more information, the opendnssec build is failing due doxygen builds (and blocking the transition to testing). https://buildd.debian.org/status/logs.php?arch=kfreebsd-i386pkg=opendnssecver=1%3A1.3.9-4 It was successfully built before and there's no -3 to -4 related change which should make the doxygen to fail. Ondrej On Tue, Feb 26, 2013 at 8:29 PM, Christoph Egger christ...@debian.org wrote: Hi! To answer your question on irc: You get buildd maintainers on $a...@buildd.debian.org - kfreebsd-am...@buildd.debian.org. Currently that's me (and maybe still Aurelien). Doxygen likes to segfault. I assume the problem is actually doxygen but I think noone did actually debug the problem (yet) unfortunately. Cc-ing -bsd@ -- maybe one of the (other) porters has time right now and wants to look into it. Christoph -- Ondřej Surý ond...@sury.org -- 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/CALjhHG9SPG36q+=orcws_+jakan4inufbk0pp+yk4ftfjs1...@mail.gmail.com
Re: Bug#668794: reopen
severity 668794 important forwarded 668794 http://code.google.com/p/go/issues/detail?id=3533 thank you Hi Robert, (sorry for BTS juggling, I found your comment just after I sent the first email.) Anyway I agree that the problem needs to be fixed upstream, but I would suggest that we keep GNU/KFreeBSD build enabled for the moment and if this cannot be fixed before freeze, we can always disable it. It would be shame to disable this build right now, because there would be basically no push to make it work (if there is more stuff broken than just the tests). Thus I am downgrading the severity to important, so it doesn't block transition, and will take care of GNU/KFreeBSD builds somewhere around June. Is that ok with you? Ondrej On Mon, Apr 16, 2012 at 00:04, Robert Millan r...@debian.org wrote: found 668794 2:1-4 thanks Hi Ondřej, I notice you disabled the golang testsuite because it hangs on GNU/kFreeBSD. However, the problem is still present, and chances are it makes golang unusable on that platform. I gave the source a look, and it seems that on GNU/kFreeBSD golang is playing with thread primitives, bypassing libc. For example it invokes thr_new() kernel call directly, and also calls sigprocmask() to reset the signal mask in code that is clearly multithreaded [1]. This means that either golang intends to completely replace libpthread, or it intends to play along with existing libpthread. I'm not sure which one applies here, but in both cases there is a problem that needs to be fixed in golang. So please don't disable the testsuite. If golang can't be built on GNU/kFreeBSD, unless you know it's a bug in the system libraries the problem needs to be fixed in golang. If nobody can spend the time to fix it here, then you should consider not providing the package for kfreebsd-*. [1] On multithreaded programs, use of sigprocmask() is reserved to system libraries. -- Robert Millan -- Ondřej Surý ond...@sury.org -- 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/caljhhg_ncp_+svyx5wcajaxmgkxgzzdsjut-hr3f8v-t5qr...@mail.gmail.com
Re: Bug#668794: reopen
On Mon, Apr 16, 2012 at 12:58, Robert Millan r...@debian.org wrote: I'm worried that other packages could begin depending on golang on kfreebsd-*, and then it can be a mess if we have to pull it off. But I understand your interest in providing it. Please do keep in mind that we have very little manpower. I understand, but I think it will take some time before it will come to the point we will have packages depending on golang in the archive. Anyway I am prepared to clean the mess if there will be any. Anyway let's hope the upstream will take a look at this before freeze. O. -- Ondřej Surý ond...@sury.org -- 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/CALjhHG9=pJiS0LLN7O43HcXde5+qT9QW+MNad=VD5nCS=dj...@mail.gmail.com
RFH: golang dynamic linker
Hi, golang uses ld-elf.so.1 which is only present in freebsd-hackedutils which has been removed from archive. I have tried modifying the build scripts to use standard /lib/ld*.so.1, but that fails on kfreebsd-i386 with: cgo -dynimport _cgo1_.o _obj/_cgo_import.c_ mv -f _obj/_cgo_import.c_ _obj/_cgo_import.c Inconsistency detected by ld.so: dl-deps.c: 626: _dl_map_object_deps: Assertion `nlist 1' failed! make[3]: *** [_obj/_cgo_import.c] Error 127 make[3]: Leaving directory `/build/buildd-golang_2011.04.13-2~exp6-kfreebsd-i386-mL5F9f/golang-2011.04.13/src/pkg/runtime/cgo' make[2]: *** [runtime/cgo.install] Error 1 make[2]: Leaving directory `/build/buildd-golang_2011.04.13-2~exp6-kfreebsd-i386-mL5F9f/golang-2011.04.13/src/pkg' make[1]: *** [debian/build.stamp] Error 2 make[1]: Leaving directory `/build/buildd-golang_2011.04.13-2~exp6-kfreebsd-i386-mL5F9f/golang-2011.04.13' make: *** [build] Error 2 Which is basically beyond my skill (time to debug) to fix that. I was able to build kfreebsd-amd64 on asdfasdf, but it may also fail on buildd, but it hasn't been built yet. Ondrej -- Ondřej Surý ond...@sury.org -- 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/BANLkTi=djd8krnydmvty3tnng5phjgc...@mail.gmail.com
Re: RFH: golang dynamic linker
On Thu, Apr 28, 2011 at 14:24, Petr Salinger petr.salin...@seznam.cz wrote: I have tried modifying the build scripts to use standard /lib/ld*.so.1, but that fails on kfreebsd-i386 with: cgo -dynimport _cgo1_.o _obj/_cgo_import.c_ mv -f _obj/_cgo_import.c_ _obj/_cgo_import.c Inconsistency detected by ld.so: dl-deps.c: 626: _dl_map_object_deps: Assertion `nlist 1' failed! make[3]: *** [_obj/_cgo_import.c] Error 127 make[3]: Leaving directory `/build/buildd-golang_2011.04.13-2~exp6-kfreebsd-i386-mL5F9f/golang-2011.04.13/src/pkg/runtime/cgo' make[2]: *** [runtime/cgo.install] Error 1 make[2]: Leaving directory `/build/buildd-golang_2011.04.13-2~exp6-kfreebsd-i386-mL5F9f/golang-2011.04.13/src/pkg' make[1]: *** [debian/build.stamp] Error 2 make[1]: Leaving directory `/build/buildd-golang_2011.04.13-2~exp6-kfreebsd-i386-mL5F9f/golang-2011.04.13' make: *** [build] Error 2 Which is basically beyond my skill (time to debug) to fix that. I was able to build kfreebsd-amd64 on asdfasdf, but it may also fail on buildd, but it hasn't been built yet. It does not fail for me. The difference is at least that the experimental buildd uses experimental eglibc 2.13-0exp4, while I use eglibc 2.11.2-11. On the other hand, in my build log is: dh_strip -X.a -Xgoinstall -Xgodoc -Xgoyacc -Xbin/cgo -Xebnflint -Xgofmt -Xgovet BFD: debian/golang-go/usr/bin/st6sBHUC: section .rodata lma 0x80a2000 adjusted to 0x80a2010 BFD: debian/golang-go/usr/bin/st6sBHUC: section .plt lma 0x80a2010 adjusted to 0x813f74c BFD: debian/golang-go/usr/bin/st6sBHUC: section .dynstr lma 0x80a2020 adjusted to 0x813f75c BFD: debian/golang-go/usr/bin/st6sBHUC: section .hash lma 0x80a2034 adjusted to 0x813f76e BFD: debian/golang-go/usr/bin/st6sBHUC: section .dynamic lma 0x80a2048 adjusted to 0x813f782 BFD: debian/golang-go/usr/bin/st6sBHUC: section .gopclntab lma 0x80f8b1c adjusted to 0x813f7fa BFD: debian/golang-go/usr/bin/st6sBHUC: section .gosymtab lma 0x81002a4 adjusted to 0x8146f82 BFD: debian/golang-go/usr/bin/st6sBHUC: section .got.plt lma 0x81400a0 adjusted to 0x8141d98 BFD: debian/golang-go/usr/bin/st6sBHUC: section .bss lma 0x8141d98 adjusted to 0x8141da4 BFD: debian/golang-go/usr/bin/st6sBHUC: warning: allocated section `.interp' not in segment I have just realized that's the new gotest binary, I forgot to add -Xgotest to dh_strip. Thanks for pointing that out. The same is in (linux-)386 experimental buildd, it uses eglibc 2.11.2-11. May be the problem is not kfreebsd-* specific. Hmm, I'll go ahead and upload new version with kfreebsd-* support to unstable and see what happens. I'll get back if that's broken too. O. -- Ondřej Surý ond...@sury.org -- 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/BANLkTikd�+GoFiB=wj3vuzntaulyk...@mail.gmail.com
Re: gcj-4.4-jdk misses jni_md.h on kfreebsd platform
On Tue, Apr 19, 2011 at 23:34, Matthias Klose d...@debian.org wrote:
On 04/19/2011 11:11 PM, Ondřej Surý wrote:
reopen 621878
reassign 621878 gcj-4.4-jdk
retitle 621878 gcj-4.4-jdk misses jni_md.h on kfreebsd
affects 621878 +db4.6 db4.7 db4.8 db
thank you
Dear Debian GCC Team please look at http://bugs.debian.org/621878, it
looks like jni_md.h header is missing there which is causing FTBFSes
for dbX.Y packages.
You can find failed build logs here:
https://buildd.debian.org/status/fetch.php?pkg=dbarch=kfreebsd-i386ver=5.1.25-2stamp=1302733739
https://buildd.debian.org/status/fetch.php?pkg=dbarch=kfreebsd-amd64ver=5.1.25-2stamp=1302733541
is this a kfreebsd issue?
Version 5.1.25-1 built fine:
https://buildd.debian.org/status/fetch.php?pkg=dbarch=kfreebsd-amd64ver=5.1.25-1stamp=1297388366
Version 5.1.25-2 started to fail on kfreebsd-{amd64,amd32}. The buildd
failures on ia64, mips, s390 and sparc are of different nature.
The error from 5.1.25-2 build is:
libtool: compile: gcc -c -I. -I../src -I/usr/include/tcl8.5
-D_GNU_SOURCE -D_REENTRANT -I/usr/lib/jvm/default-java/include -Wall
-g -O2 -I/usr/lib/jvm/default-java/include -fno-strict-aliasing
../lang/java/libdb_java/db_java_wrap.c -fPIC -DPIC -o
.libs/db_java_wrap.o
In file included from ../lang/java/libdb_java/db_java_wrap.c:137:0:
/usr/lib/jvm/default-java/include/jni.h:52:20: fatal error: jni_md.h:
No such file or directory
The same line compiles with lots of warnings, but compiles. So
something must have changed on gcj side between the two builds which
broke it.
looks more like you are assuming that the default
version of gcc matches the one for gcj. please reassign back.
Could you please elaborate? Are you trying to say that calling:
gcc -c -I. -I../src -I/usr/include/tcl8.5 -D_GNU_SOURCE -D_REENTRANT
-I/usr/lib/jvm/default-java/include -Wall -g -O2
-I/usr/lib/jvm/default-java/include -fno-strict-aliasing
../lang/java/libdb_java/db_java_wrap.c -fPIC -DPIC -o .libs/db_java_wrap.o
is wrong when gcc is different version than gcj? Well the build log
say gcc-4.4 and gcj-4.4-*, so there should be nothing wrong.
O.
--
Ondřej Surý ond...@sury.org
db_5.1.25-1..2.diff.gz
Description: GNU Zip compressed data
Re: gcj-4.4-jdk misses jni_md.h on kfreebsd platform
Just a quick note, the difference in gcj version between successful and
unsuccessfull build is 4.4.5-9 vs 4.4.5-14
Ondřej Surý
On 20.4.2011, at 0:59, Ondřej Surý ond...@sury.org wrote:
On Tue, Apr 19, 2011 at 23:34, Matthias Klose d...@debian.org wrote:
On 04/19/2011 11:11 PM, Ondřej Surý wrote:
reopen 621878
reassign 621878 gcj-4.4-jdk
retitle 621878 gcj-4.4-jdk misses jni_md.h on kfreebsd
affects 621878 +db4.6 db4.7 db4.8 db
thank you
Dear Debian GCC Team please look at http://bugs.debian.org/621878, it
looks like jni_md.h header is missing there which is causing FTBFSes
for dbX.Y packages.
You can find failed build logs here:
https://buildd.debian.org/status/fetch.php?pkg=dbarch=kfreebsd-i386ver=5.1.25-2stamp=1302733739
https://buildd.debian.org/status/fetch.php?pkg=dbarch=kfreebsd-amd64ver=5.1.25-2stamp=1302733541
is this a kfreebsd issue?
Version 5.1.25-1 built fine:
https://buildd.debian.org/status/fetch.php?pkg=dbarch=kfreebsd-amd64ver=5.1.25-1stamp=1297388366
Version 5.1.25-2 started to fail on kfreebsd-{amd64,amd32}. The buildd
failures on ia64, mips, s390 and sparc are of different nature.
The error from 5.1.25-2 build is:
libtool: compile: gcc -c -I. -I../src -I/usr/include/tcl8.5
-D_GNU_SOURCE -D_REENTRANT -I/usr/lib/jvm/default-java/include -Wall
-g -O2 -I/usr/lib/jvm/default-java/include -fno-strict-aliasing
../lang/java/libdb_java/db_java_wrap.c -fPIC -DPIC -o
.libs/db_java_wrap.o
In file included from ../lang/java/libdb_java/db_java_wrap.c:137:0:
/usr/lib/jvm/default-java/include/jni.h:52:20: fatal error: jni_md.h:
No such file or directory
The same line compiles with lots of warnings, but compiles. So
something must have changed on gcj side between the two builds which
broke it.
looks more like you are assuming that the default
version of gcc matches the one for gcj. please reassign back.
Could you please elaborate? Are you trying to say that calling:
gcc -c -I. -I../src -I/usr/include/tcl8.5 -D_GNU_SOURCE -D_REENTRANT
-I/usr/lib/jvm/default-java/include -Wall -g -O2
-I/usr/lib/jvm/default-java/include -fno-strict-aliasing
../lang/java/libdb_java/db_java_wrap.c -fPIC -DPIC -o .libs/db_java_wrap.o
is wrong when gcc is different version than gcj? Well the build log
say gcc-4.4 and gcj-4.4-*, so there should be nothing wrong.
O.
--
Ondřej Surý ond...@sury.org
db_5.1.25-1..2.diff.gz
--
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/c661ae1d-4f71-4ffe-8e71-f8562d61c...@sury.org
Bug#594168: Trang Bus error on kfreebsd-amd64
Package: trang Version: 2009-2 Severity: important X-Debbugs-CC: debian-bsd@lists.debian.org Hi, there is an Bus error from trang when building opendnssec package on kfreebsd-amd64. It prevents opendnssec to enter squeeze. It doesn't fail on any other platform. Full build log: https://buildd.debian.org/fetch.cgi?pkg=opendnssecver=1.1.1-2arch=kfreebsd-amd64stamp=1281683281file=log Ondrej -- Ondřej Surý ond...@sury.org -- 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/aanlktindhsxsoflq9xmnbb3in+atrhssavxzphfld...@mail.gmail.com
