Bug#752390: /usr/include/sys/_callout.h:56:2: error: unknown type name 'sbintime_t'
Hector Oron zu...@debian.org writes: https://buildd.debian.org/status/fetch.php?pkg=gdbarch=kfreebsd-amd64ver=7.7.1-2stamp=1403257387 Here's the relevant portion of the buildlog: x86_64-kfreebsd-gnu-gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security-I. -I/«PKGBUILDDIR»/gdb -I/«PKGBUILDDIR»/gdb/common -I/«PKGBUILDDIR»/gdb/config -DLOCALEDIR=\/usr/share/locale\ -DHAVE_CONFIG_H -I/«PKGBUILDDIR»/gdb/../include/opcode -I/«PKGBUILDDIR»/gdb/../opcodes/.. -I../bfd -I/«PKGBUILDDIR»/gdb/../bfd -I/«PKGBUILDDIR»/gdb/../include -I../libdecnumber -I/«PKGBUILDDIR»/gdb/../libdecnumber -I/«PKGBUILDDIR»/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -D_FORTIFY_SOURCE=2 -I/usr/include/python2.7 -I/usr/include/x86_64-kfreebsd-gnu/python2.7 -Wall -Wdeclaration-after-statement -Wpointer-arith -Wpointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wmissing-prototypes -Wdeclaration-after-statement -Wempty-body -Wmissing-parameter-type -Wold-style-declaration -Wold-style-definition -Wformat-nonliteral -c -o i386-nat.o -MT i386-nat.o -MMD -MP -MF .deps/i386-nat.Tpo /«PKGBUILDDIR»/gdb/i386-nat.c In file included from /usr/include/sys/callout.h:43:0, from /usr/include/sys/proc.h:41, from /«PKGBUILDDIR»/gdb/bsd-kvm.c:38: /usr/include/sys/_callout.h:55:2: error: unknown type name 'sbintime_t' sbintime_t c_time; /* ticks to the event */ ^ /usr/include/sys/_callout.h:56:2: error: unknown type name 'sbintime_t' sbintime_t c_precision; /* delta allowed wrt opt */ ^ Makefile:1008: recipe for target 'bsd-kvm.o' failed make[3]: *** [bsd-kvm.o] Error 1 -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! -- 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/87vbriuizz@naesten.mooo.com
Bug#734328: Bug#726248: Bug#734328: kfreebsd-kernel-headers: Don't ship sys/sdt.h here
Robert Millan r...@debian.org writes: What's wrong with Replaces: ? I proposed this in my last mail, but it went unanswered: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726248#105 I really don't see why you want us to remove legacy functionality from k-k-h. As far as I can see its presence doesn't stop you from providing an alternative and making other packages Build-Depend on it. Hmm, I must have thought this was covered well enough in: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726248#110 But I guess that left out the detail that Replaces is supposed to be accompanied by Breaks (or Conflicts?), which is iirc due to the unpleasent consequences that occur if you remove the replacing package before the replaced package: the files are just gone. So, if you want to continue to make those files available, it's best if you split them off into their own, non-build-essential package, which systemtap-sdt-dev could safely conflict with, but dtrace could still explicitly use. And having a -dev package that conflicts with something in build-essential is a non-starter: besides the impracticality of replacing the *rest* of the kFreeBSD headers, the buildds are NOT smart enough to allow installing a package conflicting with/providing one in build-essential. (I belive this is deliberate.) As for the dtrace userland, we don't have it yet, but we're much closer. There's a ctfutils package, and latest versions of the kernel are built with CTF debug information and dtrace support now. I think that eventually we can have both implementations of SDT probes. Systemtap obviously has better integration with the GNU toolchain but DTrace will most likely have better kernel integration for us. I think there's room for both options and I think it's great to have this choice. So why remove the BSD version of sys/sdt.h? Better to provide users with two great tools than just one, don't you think? Yes, that would be nicest, though I'd hope that they could eventually agree to use (something like) Systemtap's NOP-ful representation[1] for probe points rather than having their own incompatible ABIs for overlapping APIs like they do now. [1]: https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! -- 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/87k3dwtnk6@naesten.dyndns.org
Bug#734328: kfreebsd-kernel-headers: Don't ship sys/sdt.h here
Package: kfreebsd-kernel-headers Version: 9.2~5 Severity: normal Control: block 726248 by -1 Dear Maintainer, Given the facts: - nobody has ported the dtrace userspace to [e]glibc yet - there *are* packages that could benefit from systemtap's version of sys/sdt.h; in particular, GDB can use such probes, and has particular support for ones in [e]glibc and libgcc (see http://bugs.debian.org/726248) - this package and systemtap-sdt-dev can't *both* install sys/sdt.h it doesn't seem particularly useful for you to ship the dtrace-compatible sys/sdt.h in this package. http://bugs.debian.org/726248 has a lot of discussion about this. (It might *possibly* be useful for people running Debian in a chroot, but on the other hand wouldn't they need a copy of dtrace in there to be able to include all the necessary metadata in their binaries anyway? If so, it seems unlikely to be much more work for them to install the dtrace-compatible sys/sdt.h at the same time. Or, if that worries you, you could split it into its own package.) -- 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/874n5iugj4@naesten.dyndns.org
