Processing of freebsd-glue_0.1.10_kfreebsd-amd64.changes
freebsd-glue_0.1.10_kfreebsd-amd64.changes uploaded successfully to localhost along with the files: freebsd-glue_0.1.10.dsc freebsd-glue_0.1.10.tar.gz freebsd-glue_0.1.10_kfreebsd-amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.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/e1vxqjd-0004dc...@franck.debian.org
freebsd-glue_0.1.10_kfreebsd-amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 20 Oct 2013 12:56:14 +0200 Source: freebsd-glue Binary: freebsd-glue Architecture: source kfreebsd-amd64 Version: 0.1.10 Distribution: unstable Urgency: low Maintainer: GNU/kFreeBSD Maintainers debian-bsd@lists.debian.org Changed-By: Robert Millan r...@debian.org Description: freebsd-glue - Emulate a FreeBSD build environment Changes: freebsd-glue (0.1.10) unstable; urgency=low . * Add libdb-dev to Depends / Build-Depends. Checksums-Sha1: 3294440f5c10dbfd83abe45ab0efe2d2e0be0bb2 1015 freebsd-glue_0.1.10.dsc 5d55d3bfddc4e2764ea8256ce761366492a5eb30 37229 freebsd-glue_0.1.10.tar.gz e8c3a6aa27f9ba7b5a99db36ed7472ee141a77d8 32512 freebsd-glue_0.1.10_kfreebsd-amd64.deb Checksums-Sha256: 9acf33b931095f19d205973a0dd2ce585e9262648972a643fc0604a5ebfbd9a3 1015 freebsd-glue_0.1.10.dsc 6d1108f69750e7e1726c85e9a3d204ba4f91ebf15a86d9bd8959caa94e1801ee 37229 freebsd-glue_0.1.10.tar.gz 013edb92a55063b219c7df0040b09eeff59f1dd50a753b8fa7d6166cc704b25e 32512 freebsd-glue_0.1.10_kfreebsd-amd64.deb Files: c80e0f15ad221e44248130255d1a325b 1015 devel extra freebsd-glue_0.1.10.dsc 389ba25479f64d0854a7d6acf5f9e691 37229 devel extra freebsd-glue_0.1.10.tar.gz 8291a01bb161a3dec3cf2be82f1b3a8f 32512 devel extra freebsd-glue_0.1.10_kfreebsd-amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/kFreeBSD) iEYEARECAAYFAlJjtwgACgkQC19io6rUCv+p0gCeOJceewfkfga/riZxCukVOzaL DE0AnjNOl9Hc+E6rtI0aXYqmeFUAXUfU =wWJR -END PGP SIGNATURE- Thank you for your contribution to Debian. -- 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/e1vxqn3-0005eg...@franck.debian.org
Processing of freebsd-glue_0.1.11_kfreebsd-amd64.changes
freebsd-glue_0.1.11_kfreebsd-amd64.changes uploaded successfully to localhost along with the files: freebsd-glue_0.1.11.dsc freebsd-glue_0.1.11.tar.gz freebsd-glue_0.1.11_kfreebsd-amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.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/e1vxt0a-xe...@franck.debian.org
Re: Bug#726248: sdt.h conflict with kfreebsd-kernel-headers and systemtap-sdt-dev
On Sun, Oct 20, 2013 at 01:07:33AM +0200, Robert Millan wrote: But then programs that expect the header to be in the default place wouldn't build. The whole idea is that programs that use sys/sdt.h (and optionally the dtrace script) to use DTRACE_PROBE macros to define SDT probe points get them without having to change anything to their build system. They just detect in configure the sys/sdt.h is available (possibly checking for the dtrace script and whether the compiler is capable of building with DTRACE_PROBE macros). That is how for example qemu, java hotspot or libreoffice do it. So the probes you're referring to were added for DTrace, and SystemTap takes advantage of them by providing a DTrace-compatible API. Is this correct? It is a two way street. Or multi-way, it isn't just systemtap, gdb and perf for example also take advantage of them. For java the SDT markers were already there and all it took was build them with the right sys/sdt.h installed and now you can use them with any tool (stap, gdb, perf) that can read the right ELF section magic. For qemu it was the other way around, they were specifically added for stap, but you can also use them from gdb or perf. And when rebuild on Solaris with their sys/sdt.h they are also usable by dtrace. See e.g. https://www.berrange.com/posts/2011/11/30/watching-the-libvirt-rpc-protocol-using-systemtap/ The default sys/sdt.h header should match the toolchain and user space you are using. Toolchain and user space are very generic terms. Which components do you have in mind? sys/sdt.h and compiler as producer of the SDT ELF section, gdb/binutils, perf and stap as consumers at a minimum. If I understand correctly, we can't support both SystemTap and DTrace at the same time, because SystemTap only aims for API compatibility, not ABI compatibility, so we have to choose one to link everything against? SystemTap is a Linux tool. What is the advantage of using it on kFreeBSD, in comparison with DTrace? It really isn't just systemtap, that is just one of the programs that can consume the SDT markers produced in the special ELF notes. gdb and perf at least can also use them for debugging and profiling. I don't know about dtrace, but on a system with a GNU toolchain I assume it can be made to work with the SDT ELF section too. It is all documented https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation For systemtap that is just one of the probe sources you can use. There are others inside the kernel, timers, syscalls, etc. I assume dtrace also has various sources from which it can generate traces? As DTrace is fully integrated in FreeBSD upstream, theoretically we could use it to debug both kernel and userland. Is it possible to do the same with SystemTap? Yes, systemtap can also use both kernel and userland probes. perf also can profile both kernel and user space. gdb only does user space, but there is a special linux kernel kgdb. But if you think that on kfreebsd programs should be build against a different sys/sdt.h that is fine too (but then programs like gdb will not work with the SDT probes in programs and libraries or will be less efficient when handling things in glibc and libgcc). So you're saying that GDB has features which work with SystemTap, but not with DTrace? I don't know what your sys/sdt.h produces when it sees a DTRACE_PROBE macro. I don't believe gdb knows how to interpret those. But it does know how to interpret the SDT markers produced by the sys/sdt.h header from std-dev. You can set (conditional) breakpoints on them, etc. And it even knows about some special ones in glibc and libgcc that help gdb with exceptions or shared library loading issues. You can think of DTRACE_PROBE macros as special places to set a breakpoint on. gdb uses those in one specific way, systemtap uses it for tracing, perf uses them for profiling, etc. This would only work if SystemTap could be adjusted to use the same ABI as DTrace. That would be the best solution IMHO. But it might not be feasible. Systemtap doesn't work on any system/kernel that has a dtrace ABI as far as I know. Is there a discription of this ABI? I guess if there is a specification of how SDT probes are embedded in could be made to also interpret them (given we find some volunteers). BTW. This isn't a new thing on GNU/Linux. This has been integrated in various distributions for years. That is why the request came to make sdt-dev an integral part (arch:all) for Debian too. Then tools like gdb can rely on it and do several things currently not possible or less efficiently. Does any user space program Debian actually use the kfreebsd sys/sdt.h variant? Well, I guess that anything that has support for DTRACE_PROBE is already using it. Haven't checked if this actually works though. It would be good to know if it actually works and has any programs/users. I was only asking because if user space dtrace does work then it
freebsd-glue_0.1.11_kfreebsd-amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 20 Oct 2013 15:14:22 +0200 Source: freebsd-glue Binary: freebsd-glue Architecture: source kfreebsd-amd64 Version: 0.1.11 Distribution: unstable Urgency: low Maintainer: GNU/kFreeBSD Maintainers debian-bsd@lists.debian.org Changed-By: Robert Millan r...@debian.org Description: freebsd-glue - Emulate a FreeBSD build environment Changes: freebsd-glue (0.1.11) unstable; urgency=low . * Fix unresolved dependencies on libc hidden symbols (_open, _read, _close), libdb and cpuset family of functions. * Add zlib1g-dev to Build-Depends and Depends. * getosreldate.c: Move mib and size to kFreeBSD-specific area. Checksums-Sha1: 6852e8b369b7575757b41fe6af6cd16ccfaf087c 1027 freebsd-glue_0.1.11.dsc b69b734e11e6d2bcf5b7d76ea8d563e153765012 37420 freebsd-glue_0.1.11.tar.gz d7c90a499f4d484aada274195b568652e5d3d4a3 33312 freebsd-glue_0.1.11_kfreebsd-amd64.deb Checksums-Sha256: 7f807a16c1655a46f85bd1f78dafe5e92c573a9a16e4990f39a4bd60b0778b2d 1027 freebsd-glue_0.1.11.dsc 5111626169dff06b5d168aa4efa541e4757e114bcab4a6fbd884661785d64e66 37420 freebsd-glue_0.1.11.tar.gz 9e302445ceb333698ea9006f1ddc7900083ca05d9a52b462eea98ba8ca7be24c 33312 freebsd-glue_0.1.11_kfreebsd-amd64.deb Files: 472b7dfa5d4d9f3dac89817032b11d8e 1027 devel extra freebsd-glue_0.1.11.dsc d0f70190b5008dc660a82e30088f720e 37420 devel extra freebsd-glue_0.1.11.tar.gz c39ca87616a93fff2f0fb63c986a2c84 33312 devel extra freebsd-glue_0.1.11_kfreebsd-amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/kFreeBSD) iEYEARECAAYFAlJj2HYACgkQC19io6rUCv/JhACcDLYGBXEi1kGkS6dGD+qmgMOL dsAAnRG69zKezjkWUcNzQa6O1JgHUE5m =w3TX -END PGP SIGNATURE- Thank you for your contribution to Debian. -- 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/e1vxt8h-0002ry...@franck.debian.org
Re: grub on ZRaid2
Hi, On 20/10/2013 22:54, Klaus Melchior wrote: Hi, using Debian GNU/kFreeBSD 7.2.0 _Wheezy_ DVD-1 20131012-20:22 on 4x 2TB drive amd64 system. I'm using the expert install with kernel 9 and installing kernel 9.0.2 on the target. The Installation of GRUB on /dev/ada0 works on 4x 2TB ZFS stripe. But GRUB installation failes on ZRAID2 with 1 logical volume tank/root mounted as /: Install GRUB to the master boot record: Yes Unable to install GRUB in /dev/ada0 Did you create this pool yourself? Debian installer always creates zpools within MSDOS partitions, in order to leave room for embedding. If you created a full-disk pool, GRUB doesn't support this setup AFAIK. -- Robert Millan -- 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/526456a5.3010...@debian.org
Re: Bug#726248: sdt.h conflict with kfreebsd-kernel-headers and systemtap-sdt-dev
On 20/10/2013 15:31, Mark Wielaard wrote: It would be good to know if it actually works and has any programs/users. I was only asking because if user space dtrace does work then it might be a good idea to make it understand the sys/sdt.h variant ELF notes. But if there are no programs/users for it currently then it would be easier to resolve the conflict between the packages. I don't know enough about Debian kfreebsd to tell what (user space) solution is best. Thank you (and Frank) for the in-depth explanation. Well I think it doesn't hurt to let systemtap-sdt-dev provide sys/sdt.h at least for the time being. If later on (i.e. when we actually have DTrace) we find out that there are significant shortcomings, we can always revert that decision. In the meantime this will allow us to verify that the magic in GDB also works on GNU/kFreeBSD. My suggestion, assuming everyone is okay with it, would be that you make this package arch-all and add a: Replaces: kfreebsd-kernel-headers [kfreebsd-any] to debian/control. -- Robert Millan -- 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/52645959.8020...@debian.org
Re: Re: grub on ZRaid2
Hi, on Mon, 21 Oct 2013 00:18:13 +0200, Robert Millan wrote: Did you create this pool yourself? No, partman-base did while expert installation. But I did a ZFS stripe installation prior, so the partitions were physical volume for ZFS. /dev/ada0 - 2.0 TB Generic IDE #1 primary 2.0 TBK zfs /dev/ada1 - 2.0 TB Generic IDE #1 primary 2.0 TBK zfs /dev/ada2 - 2.0 TB Generic IDE #1 primary 2.0 TBK zfs /dev/ada3 - 2.0 TB Generic IDE #1 primary 2.0 TBK zfs Debian installer always creates zpools within MSDOS partitions, in order to leave room for embedding. If you created a full-disk pool, GRUB doesn't support this setup AFAIK. My new try... Deleting the partition tables of the 4 discs. /dev/ada0 - 2.0 TB Generic IDE pri/log 2.0 TB FREE SPACE /dev/ada1 - 2.0 TB Generic IDE pri/log 2.0 TB FREE SPACE /dev/ada2 - 2.0 TB Generic IDE pri/log 2.0 TB FREE SPACE /dev/ada3 - 2.0 TB Generic IDE pri/log 2.0 TB FREE SPACE After selecting Configure ZFS, Create ZFS pool, name: tank and selecting the 4 devices for the new ZFS pool, partman-base created a ZFS stripe: NAME USED AVAIL REFER MOUNTPOINT tank 106K 7.14T31K none There was no chance to select Striped, Mirror, RAID-Z! If I delete the ZFS pool and re-created it without changing the partitions, I'm able to select RAID-Z with parity level 2: NAME USED AVAIL REFER MOUNTPOINT tank 139K 3.55T 44.8K none But this will fail grub-installer. What is a MSDOS partition -- k...@gmx.de smime.p7s Description: S/MIME cryptographic signature
Re: Re: grub on ZRaid2
In continuation to my previous post: On Mon, 21 Oct 2013 00:18:13 +0200, Robert Millan wrote: Debian installer always creates zpools within MSDOS partitions, in order to leave room for embedding. If you created a full-disk pool, GRUB doesn't support this setup AFAIK. What is a MSDOS partition? A disc with an empty MSDOS partition table? Or is the partition table filled with empty primary/logical partitions? Is partman-base able to create MSDOS partitions for a ZRAID? -- k...@gmx.de -- 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/ioenkagbbnkhenkpbeimaekcglab.k...@gmx.de
Bug#726970: freebsd-glue: Broken funopen() implementation
Source: freebsd-glue Source-Version: 0.1.11 Severity: important Hi, The funopen() implementation in this package uses nested functions to wrap the argument hooks, but it returns a FILE structure pointing to those nested functions and their references to arguments from the stack, to be accessed outside of the function lexical scope, which is just wrong. I've not tested if this currently breaks, but this is explicitly stated as broken usage. In 2011 I started some draft code to add funopen() support to libbsd, but left it aside given the various issues with the interface. I've just finished and polished a full implementation, and pushed to libbsd's git master, it will be included in 0.7.0. Regards, Guillem -- 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/20131021042049.ga13...@gaara.hadrons.org
