* Package name : libnih.la Version : 1.0.4 (git snapshot) Upstream Author : Dimitri John Ledkov (DD), Scott James Remnant (DD) * URL or Web page : https://github.com/xnox/libnih/tree/kfreebsd http://libnih.la/ * License : GPL v2 Architecture : kfreebsd-any (hurd-any - maybe later) Description : portable libnih implementation I would like to package a temporary fork of libnih, which has been ported to kFreeBSD/eglibc platform. My plan for this package is to provide same packages as the src:libnih, but for non-Linux ports only. At the moment I have a port to kFreeBSD/eglibc. This is separate source package as the supported set of APIs is not yet fully same as of the Linux port of libnih. For example kqueue/kevent technology is not yet used to provide, e.g. file level notification as done with inotify in the linux port. Some of my patches have already been accepted upstream (https://github.com/keybuk/libnih), others are under review and some are not ready for submission yet. All libnih test-suite passes on kFreeBSD for those components that have been ported. Together with this effort, I am staging patches for Upstart itself for kFreeBSD/eglibc https://code.launchpad.net/~xnox/upstart/kfreebsd. It compiles, but at the moment is still incomplete. The test-suite does not pass yet and there are no kFreeBSD specific bridges yet (e.g. devd events, instead of udev, etc.). I'm hoping to have a bootable kFreeBSD/eglibc port soon, with full support ahead of Jessie freeze on 5th of November 2014. The requirements for libnih/kfreebsd, at the moment are, eglibc 2.18 & kFreeBSD kernels with fixed waitid/wait6 syscalls. These are all present in Debian experimental. Alternatively, if lower eglibc versions are required I could easily use wait6 syscall directely, without eglibc wrapper. In that case only requirements would be patched kFreeBSD kernels for the kern/184002 http://www.freebsd.org/cgi/query-pr.cgi?pr=184002&cat= bug which I discovered in FreeBSD. It's fixed in current/11, and is on track to be fixed in 9.2, 10 stable updates. I believe patch for that issue is already in debian packaging of FreeBSD kernels. I haven't started HURD port just yet, as I'm more familiar with FreeBSD. Regards, Dimitri.
Dmitri, Why do you not use libinotify-kqueue? I know you mentioned not wanting to have a lot of external dependencies, but I think using that library will allow other linux applications to more easily port to kFreeBSD. Great work, Cameron Norman
Dmitri, Why do you not use libinotify-kqueue? I know you mentioned not wanting to have a lot of external dependencies, but I think using that library will allow other linux applications to more easily port to kFreeBSD. Great work, Cameron Norman
I have packaged it and attempted to use it. [1] Unfortunately it doesn't provide sufficient compatibility and I see a lot of unit-test failures. Instead of enabling something partially broken, i'd rather not provide the facility full stop and instead implement a native kqueue/kevent. Granted I could spend time improving libinotify-kqueue. At the moment I'm focusing on booting a kFreeBSD/eglibc system with upstart, since file notifications are optional in upstart (well to be precise, they may fail / raise errors at runtime and upstart handles that gracefully) [1] http://packages.qa.debian.org/libi/libinotify-kqueue.html Regards, Dimitri.
Dimitri John Ledkov writes ("Bug#733743: ITP: libnih.la -- portable libnih implementation"):
Thanks for this work.
I don't have an opinion on whether this temporary fork is the right
way to manage the code here.
Ian.
Hi Dimitri, I assume porting Upstart is the whole reason you've ported libnih? I haven't been following the discussion about Upstart vs Systemd vs OpenRC debate. Are you doing this because you expect that Upstart will be adopted? Note the waitid/wait6 fix is in unstable, too (since 10.0~svn258623-1). If I had to choose, I think I'd rather break old libc than break old kernels. The former is readily fixed by proper use of Depends field, while the later breaks kfreebsd-downloader and all sort of chroot/jail environments. Uhm doesn't seem so. Nobody MFCed it to stable/10 yet. I think we can take 10.1 support for granted. 10.0 is probably difficult (but I will try anyway).
Hi Dimitri, Thanks for packaging libinotify-kqueue for Debian. Could you please specify which tests fail on Debian/kFreeBSD? IN_OPEN, IN_CLOSE_WRITE, IN_CLOSE_NOWRITE will always fail because there seems no way to implement it with a stock kqueue(). Does Upstart really need it for work? Other notifications are implemented and working. With best regards, Dmitry
retitle 733743 RFP: libnih.la -- portable libnih implementation noowner 733743 tag 733743 - pending thanks Hi, A long time ago, you expressed interest in packaging libnih.la. Unfortunately, it seems that it did not happen. In Debian, we try not to keep ITP bugs open for a too long time, as it might cause other prospective maintainers to refrain from packaging the software. This is an automatic email to change the status of libnih.la from ITP (Intent to Package) to RFP (Request for Package), because this bug hasn't seen any activity during the last 12 months. If you are still interested in packaging libnih.la, please send a mail to <control@bugs.debian.org> with: retitle 733743 ITP: libnih.la -- portable libnih implementation owner 733743 ! thanks It is also a good idea to document your progress on this ITP from time to time, by mailing <733743@bugs.debian.org>. If you need guidance on how to package this software, please reply to this email, and/or contact the debian-mentors@lists.debian.org mailing list. Thank you for your interest in Debian,