Bug#431724: misdn packaging of latest versions
On Tue, 2007-07-17 at 14:36 +0200, Simon Richter wrote: I'm a member of pkg-voip, however mISDN is not team maintained and won't be for the forseeable future. Hello Simon, why not? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431724: misdn packaging of latest versions
Hi, Lee Garrett wrote: Would it be a viable option to drop the misdn-modules-* packages from misdn-kernel? It would greatly ease the maintenance of misdn-kernel, as the new kernel modules needn't go through NEW. I would volunteer to write an HOWTO for the doc section so people could build their custom kernel with misdn support. Yes, that could be done. misdn-source should already build with module-assistant. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431724: misdn packaging of latest versions
Hello Simon, Would it be a viable option to drop the misdn-modules-* packages from misdn-kernel? It would greatly ease the maintenance of misdn-kernel, as the new kernel modules needn't go through NEW. I would volunteer to write an HOWTO for the doc section so people could build their custom kernel with misdn support. This would give us the best of both worlds: The maintainer (you) wouldn't have to go through the upload mess for every new kernel version, and the user in return would have up-to-date packages from the misdn-kernel and misdn-user source packages. As misdn is a fast moving target, this is quite important. As chan-misdn build-depends on libmisdn-dev and libisdnnet-dev, this way asterisk-chan-misdn could be built on regular basis, too. The only downside would be that there are no debian stock modules. But if someone is willing to use misdn, this person is probably prepared to do some footwork (e.g. compiling custom kernels). Just an idea. Kind regards, Lee Garrett -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431724: misdn packaging of latest versions
I have have packaged misdn-kernel and misdn-user for 1_1_5 and I've been talking to people on the pkg-voip list about it. All I need to know is where to put my patches so the maintainer can pick them up... Stirk, Lamont Associates Ltd. Registered Address: Thomas Andrews House, Queens Road, Belfast, BT3 9DU Registered in Northern Ireland, Number: NI 47983. VAT Number: 832 2778 22
Bug#431724: misdn packaging of latest versions
Hi, Dermot Bradley wrote: I have have packaged misdn-kernel and misdn-user for 1_1_5 and I've been talking to people on the pkg-voip list about it. I'm a member of pkg-voip, however mISDN is not team maintained and won't be for the forseeable future. All I need to know is where to put my patches so the maintainer can pick them up... The main problem isn't updating the packages, but rather doing the necessary work to keep existing installations going. The main reason why I asked for the removal of the packages from etch was precisely that, lack of backwards compatibility. Combine that with the fact that asterisk-config still provides /etc/asterisk/misdn.conf (thus making the asterisk-chan-misdn package fail installation) and that the chan_misdn shipped with asterisk cannot be synchronized to mISDN releases sanely, and the problem that kernel module uploads have to go through NEW (where they usually get ACCEPTED from as soon as the next kernel version is ready) and you might understand the current mess. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431724: misdn packaging of latest versions
I'm a member of pkg-voip, however mISDN is not team maintained and won't be for the forseeable future. Hi Simon. Kilian Krause had actually suggested that I check my version into pkg-voip SVN and I'm actually in the process of doing that at the minute. Combine that with the fact that asterisk-config still provides /etc/asterisk/misdn.conf (thus making the asterisk-chan-misdn package fail installation) and that the chan_misdn shipped with asterisk cannot be synchronized to mISDN releases sanely, I didn't look at asterisk-chan-misdn in the past (as I was using asterisk-chan-capi) but the recent versions of asterisk shipping with chan_misdn seem fine - I'm not sure what the issue is with synchronizing asterisk and mISDN - I've used several mISDN and several Asterisk versions together. Well I'll check my stuff into pkg-voip and then we can maybe have a chat on the list to see what the others think... Stirk, Lamont Associates Ltd. Registered Address: Thomas Andrews House, Queens Road, Belfast, BT3 9DU Registered in Northern Ireland, Number: NI 47983. VAT Number: 832 2778 22
Bug#431724: misdn packaging of latest versions
Hi, I didn't look at asterisk-chan-misdn in the past (as I was using asterisk-chan-capi) but the recent versions of asterisk shipping with chan_misdn seem fine - I'm not sure what the issue is with synchronizing asterisk and mISDN - I've used several mISDN and several Asterisk versions together. The interfaces are a huge mess and not properly versioned. There are reasons why I asked for the package to be pulled from etch. Using the chan_misdn in the asterisk tree will make it impossible to keep mISDN out of the release until it can be said that it is stable enough for us to be able to support it for three years. Whenever the kernel version changes, you need at least two approvals from ftpmaster before the package can enter unstable (the first upload only allows the new version for that particular architecture it was uploaded for, the other architectures need to go through NEW again when the autobuilders have picked up the package as they use different binary package names). Usually a new kernel version is out before that has happened. The userspace code is heavily patched to allow for it to work on other architectures than i386, and building shared libraries is disabled to allow for the library ABI to change. However, the kernel ABI also changed since the last upload, and it will be necessary to add proper runtime detection code, which I want to do only when there is a chance that the code ends up in a release (i.e. it is stable enough for me to commit to it for a few years); doing it now would add more compatibility code to be pushed along for the next two releases. This package needs to be maintained in a very conservative way. I doubt this can be done in a team setting. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
