Bug#431724: Situation regarding mISDN
tzafrir.cohen at xorcom.com
Mon Aug 20 12:14:18 UTC 2007
On Mon, Aug 20, 2007 at 01:52:27PM +0200, Simon Richter wrote:
> Lee Garrett wrote:
> > Simon, if I get to write the HOWTO discussed in bug #431724, will you
> > drop (comment out in the scripts) building module packages for the
> > debian kernels?
> Already done in my local tree.
> > I guess for Lenny mISDN might have stabilized a little
> > and it would be easier to maintain them then. I think its ten times more
> > important to have up-to-date misdn libraries to work on than module
> > packages. Do you have any other plans or ideas with this?
> There will be a separate source package that builds these, but that
> depends on my "xcontrol" tool, so it probably will be another two weeks
> until I roll that out. Given that this has to go through NEW anyway, I
> don't think that matters much.
> The difficult bit is going to be a sane init system.
> Possible plan:
> 1. Upload 1.1.5-1 to unstable without any init system at all (so no
> change from earlier versions, should work as a drop-in replacement with
> whatever scripts users have built for themselves), and a DebConf note
> telling people to turn to experimental if they want to test the new init
> system (obviously, we keep that out of testing).
> 2. Upload 1.1.5-* to experimental with new udev-based init system. This
> will require a lot of scripting, as mISDN can coexist with I4L, and some
> people might want to run it in this way. Basically we need to get a list
> of all ISDN adapters (I guess the files in upstream's kernel package are
> going to be helpful there), and ask whether they want to use them with
> mISDN or I4L, then set up udev rules for that.
When exactly will this be done? modules are loaded at boot.
Note that qozap, zaphfc and vzaphfc from zaptel-modules also combat with
misdn in the fight to be the default for the device IDs.
> Also we probably need to
> set up fake dependencies from the hardware driver modules to the l1, l2
> and l3 modules, I haven't checked that yet.
> 3. When that init system works, upload to unstable. Whether or not to
> remove the testing blocker at this point should be decided then.
> 4. Work with/against upstream to get a real init system working, which
> means teaching the kernel to defer loading the l1-3 drivers (this will,
> guess what, change the kernel<->userspace API/ABI again, but we can
> probably catch that in libmISDN). That was originally my plan for the
> CCCamp, but I was sick in bed during that time.
What do you mean here?
Do you mean that every non-blacklisted module will get the hardware
before your module?
icq#16849755 jabber:tzafrir at jabber.org
+972-50-7952406 mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir
More information about the Pkg-voip-maintainers