Bug#644669: freebsd-utils: Consider importing iostat from upstream
2011/10/8 Mats Erik Andersson mats.anders...@gisladisker.se: A priori the package sysstat installs the file /usr/bin/iostat at the most natural location for Debian. Observe, however, that FreeBSD locates its native executable in /usr/sbin/iostat. Does sysstat even work on kernels other than Linux? It looks very Linux-specific. If it's not intended for !Linux platforms, it should be made linux-any instead. -- 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/caofdtxpumr0xvj1ql0tqujochhz8g1xefpwomiw4h6vpuvt...@mail.gmail.com
Bug#644669: freebsd-utils: Consider importing iostat from upstream
lördag den 8 oktober 2011 klockan 13:55 skrev Robert Millan detta: 2011/10/8 Mats Erik Andersson mats.anders...@gisladisker.se: A priori the package sysstat installs the file /usr/bin/iostat at the most natural location for Debian. Observe, however, that FreeBSD locates its native executable in /usr/sbin/iostat. Does sysstat even work on kernels other than Linux? It looks very Linux-specific. If it's not intended for !Linux platforms, it should be made linux-any instead. Well, I have sysstat_9.0.6.1-2 running on kfreebsd-amd64. Without having examined all options, the only deficiency I know is its inability to produce disk statistics. On the other hand, the most recent version 10.0.2-1 was changed to linux-any. I gather sysstat would require compatibility files in linprocfs to run properly on kfreebsd-any. -- 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/20111008122621.ga21...@mea.homelinux.org
Bug#644669: freebsd-utils: Consider importing iostat from upstream
Hi! On Sat, 2011-10-08 at 01:50:19 +0200, Mats Erik Andersson wrote: in order to avoid the conflict with sysstat. However, the [...] Could you explain this conflict in more detail? Why can't iostat be in /usr/bin? A priori the package sysstat installs the file /usr/bin/iostat at the most natural location for Debian. Observe, however, that FreeBSD locates its native executable in /usr/sbin/iostat. It could as long as the interface is the same (either that or a wrapper would be needed). But on the other hand, the same package builds as [!kfreebsd-any] so there is supposedly no instanteous conflict. Even if they are not installable on the same architecture, I think the same concerns apply as any Conflicting package. Installing on a different pathname would not be right either (see #562863). The alternative solution, worthy of consideration, would be /usr/bin/iostat.bsd /usr/share/man/man1/iostat.bsd.1.gz where the manual page has a new location in relation to FreeBSD, which prefers iostat(8). All opposition is welcome! The man page could also be installed as iostat.1freebsd.gz or similar, but I don't think iostat.bsd would be a good idea, it would mask the conflict in a path arch specific way, which adds unportability to the integration with other packages or sysadmins expectations. 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/20111008190407.gb22...@gaara.hadrons.org
Bug#644669: freebsd-utils: Consider importing iostat from upstream
Package: freebsd-utils
Version: 8.2+ds2-5
Severity: wishlist
Tags: patch
Please consider including FreeBSD's own iostat in this package.
Until I have finished writing the addition of diskstats to linprocfs,
the package netstat produces an executable iostat which gives no
information at all about diskstatus for GNU/kFreeBSD; hence this
solution to bring into action a known utility.
The present patch takes the upstream code and deposits the
executable as
/lib/freebsd/iostat
in order to avoid the conflict with sysstat. However, the
corresponding manual page is not installed by the patch.
Personally I would prefer to have it as
iostat.bsd (8)
Best regards,
Mats Erik Andersson, DM
Index: debian/patches/series
===
--- debian/patches/series (revision 3725)
+++ debian/patches/series (arbetskopia)
@@ -37,3 +37,4 @@
038_jail.diff
039_geom.diff
040_kdump_multiarch.diff
+041_iostat.diff
Index: debian/patches/041_iostat.diff
===
--- debian/patches/041_iostat.diff (revision 0)
+++ debian/patches/041_iostat.diff (revision 0)
@@ -0,0 +1,18 @@
+--- freebsd-utils-8.2+ds2/usr.sbin/iostat/iostat.c.orig
freebsd-utils-8.2+ds2/usr.sbin/iostat/iostat.c
+@@ -104,6 +104,7 @@
+ #include sys/errno.h
+ #include sys/resource.h
+ #include sys/sysctl.h
++#include sys/ioctl.h
+
+ #include err.h
+ #include ctype.h
+@@ -118,6 +119,7 @@
+ #include limits.h
+ #include devstat.h
+ #include math.h
++#include signal.h
+
+ struct nlist namelist[] = {
+ #define X_TK_NIN 0
Index: debian/rules
===
--- debian/rules (revision 3725)
+++ debian/rules (arbetskopia)
@@ -78,6 +78,7 @@
include/rpcsvc/nlm_prot.x include/rpcsvc/mount.x \
sys/kgssapi/gssd.x \
usr.bin/showmount \
+ usr.sbin/iostat \
; do \
svn export $(SVN)/$$i $(ORIGDIR)/$$i ; \
done
@@ -126,6 +127,7 @@
$(PMAKE) -C usr.bin/ktrace
$(PMAKE) -C usr.bin/mkuzip
$(PMAKE) -C usr.sbin/acpi/acpiconf
+ $(PMAKE) -C usr.sbin/iostat
$(PMAKE) -C usr.sbin/rpc.umntall
$(PMAKE) -C usr.sbin/jail
touch $@
@@ -231,6 +233,7 @@
$(PMAKE) -C usr.bin/ktrace clean
$(PMAKE) -C usr.bin/mkuzip clean
$(PMAKE) -C usr.sbin/acpi/acpiconf clean
+ $(PMAKE) -C usr.sbin/iostat clean
$(PMAKE) -C usr.sbin/rpc.umntall clean
$(PMAKE) -C usr.sbin/jail clean
Index: debian/freebsd-utils.install
===
--- debian/freebsd-utils.install (revision 3725)
+++ debian/freebsd-utils.install (arbetskopia)
@@ -4,6 +4,8 @@
sbin/umount/umount /lib/freebsd
sbin/sysctl/sysctl /lib/freebsd
+usr.sbin/iostat/iostat /lib/freebsd
+
usr.bin/kdump/kdump /usr/bin
usr.bin/ktrace/ktrace /usr/bin
usr.bin/mkuzip/mkuzip /usr/bin
Bug#644669: freebsd-utils: Consider importing iostat from upstream
Hi Mats, 2011/10/8 Mats Erik Andersson mats.anders...@gisladisker.se: The present patch takes the upstream code and deposits the executable as /lib/freebsd/iostat in order to avoid the conflict with sysstat. However, the corresponding manual page is not installed by the patch. Personally I would prefer to have it as iostat.bsd (8) Could you explain this conflict in more detail? Why can't iostat be in /usr/bin? -- 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/caofdtxovw250h9ncqo.f_im4ydvq9zr6c8kdvmky94zwm...@mail.gmail.com
Bug#644669: freebsd-utils: Consider importing iostat from upstream
in order to avoid the conflict with sysstat. However, the [...] Could you explain this conflict in more detail? Why can't iostat be in /usr/bin? A priori the package sysstat installs the file /usr/bin/iostat at the most natural location for Debian. Observe, however, that FreeBSD locates its native executable in /usr/sbin/iostat. But on the other hand, the same package builds as [!kfreebsd-any] so there is supposedly no instanteous conflict. However, when (I am now attempting to code an addition to linprocfs) we activate the compatibility entry /proc/diskstats, a fair amount of packages will make sense also for us, packages which at the moment are judged as too Linux centric for architecture kfreebsd-any. The commendable BSD porters have -- before my time -- located some alternate executables brought in from FreeBSD in either of /lib/freebsd/ and /usr/lib/freebsd/, so my initial suggestion followed this route. The alternative solution, worthy of consideration, would be /usr/bin/iostat.bsd /usr/share/man/man1/iostat.bsd.1.gz where the manual page has a new location in relation to FreeBSD, which prefers iostat(8). All opposition is welcome! Regards, Mats -- 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/20111007235019.ga14...@mea.homelinux.org
