#733743 RFP: libnih.la -- portable libnih implementation

Package:
wnpp
Source:
wnpp
Submitter:
Dimitri John Ledkov
Date:
2015-12-27 12:29:46 UTC
Severity:
wishlist
#733743#5
Date:
2013-12-31 14:46:38 UTC
From:
To:
* 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.

#733743#10
Date:
2013-12-31 15:25:16 UTC
From:
To:
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

#733743#15
Date:
2013-12-31 15:25:16 UTC
From:
To:
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

#733743#20
Date:
2013-12-31 16:04:53 UTC
From:
To:
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.

#733743#25
Date:
2013-12-31 18:07:20 UTC
From:
To:
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.

#733743#30
Date:
2014-01-01 20:52:27 UTC
From:
To:
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).

#733743#35
Date:
2014-01-21 03:21:20 UTC
From:
To:
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

#733743#40
Date:
2015-12-27 12:17:00 UTC
From:
To:
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,