Bugzilla Bug 71022

Ok, as promised, part one of my ISDN works.

I cleaned up net-dialup/capi4k-utils-20041006-r1

- stripped down patch-files, so version bumping is easier
- using SuSE 9.2 src.rpm for AVM firmware files, since SuSE seems to be the most reliable source for it. SuSE is AVMs only official supported distribution, so latest fixes are first available on/for SuSE.
- all files are now in ${FILESDIR}/${PV} for easier version bumping
- compile/install only PPP-Plugins for version 2.4.1 and 2.4.2, since this are the only versions in portage
- install /usr/bin/isdncause
- wrote and install /etc/xinetd.d/rcapid
- new /etc/init.d/capi init-script (looks better, works better)
- install 'makedev.sh' into $DOCDIR for reference
- wrote and install quick HOWTO
- some minor cosmetics ;-)


Reproducible: Always
Steps to Reproduce:

Created an attachment (id=43835) [details]
capi4k-utils-20041006-r2.tar.bz2

all files together in one tar:

capi4k-utils-20041006-r2.ebuild
files/
files/20041006/
files/20041006/capi4k-utils.patch
files/20041006/capi.init
files/20041006/config
files/20041006/rcapid.xinetd
files/20041006/README.gentoo
files/digest-capi4k-utils-20041006-r2

RDEPEND means Runtime DEPEND
whereas DEPEND is Buildtime DEPEND.

Otherwise your ebuild looks good, nice work :)

the way I see it, RDEPEND is indeed empty.

I've made several changes to the posted ebuild:
  - put PPPVERSIONS=2.4.2 since it is the latest stable version and it does not have another unstable version greater than that
  - let make install its dev nodes
  - put message in dies 

good work, Stefan! are you interested in becoming gentoo dev? 'cause we need new guys :)
see http://www.gentoo.org/proj/en/devrel/staffing-needs/index.xml for more info.

reopened 'cause not all users like the idea of downloading huge files with no
relevance to them
need to make a separate ebuild for firmware files. suggestions about name?

Alin, hover your mouse over Stefans name and observe his new email address ;)

daniel: no change yet :|

Stefan, I thought we should name the ISDN firmware ebuild as suse-isdn-firmware-2004.9.27 in which we copy the entire firm directory in /usr/share/isdn. 
What do you think? 

Where does the firmware come from? What is with the stuff in in-berlin (linked
in the old ebuilds <ftp://ftp.in-berlin.de/pub/capi4linux/firmware>)?
Or the stuff on avm's server, e.g.
<ftp://ftp.avm.de/cardware/b1/linux/suse.81/>?

Can you try to make the firmware available without leeching the whole
isdn4k-utils sources from suse?

Hi! ;-)

short of time right now.

An USE-flag would be perfect. Maybe with an extra ISDN_FIRMWARE variable in make.conf. If this variable is empty, and "firmware" is set, then we install all firmware files, otherwise only the specified. USE-flags for every card are stupid. But a Use-Flag "firmware" would be nice. Should be easy to do.

Alin? Do you want to implement it or should I do it? But I can't do it *now*, because I have to go to a party right now. ;-) Later folks!

the firmware files come from AVM. But SuSE is german, AVM is german. So SuSE is
AVMs only official supported distributiuon and they work closely together. They
always say on their FTP: "already built-in in latest SuSE releases". So the
only reliable source for all the AVM stuff is the SuSE FTP.

ok, what about a:

  net-dialup/capi4k-firmware

ebuild. So we could remove that stuff here?

tove: didn't found anywhere that firmware.tar.bz2. maybe you are luckiest than
me...

I've already submitted a modified -r2 in which suse rpm is no longer in
SRC_URI.

we can't add firmware USE because SRC_URI cannot depend on flags, so everyone
will download the rpm in question whether they have +firmware or not. the only
thing we can do is to create a separate ebuild.

ok, we could name capi4k-firmware, but what version do we put? with
suse-isdn-firmware, version is not our problem ;)

rpm -qlp <i4l...>.rpm

firmware.tar.bz2 is part of that RPM.

Ok, bye, later folks. Seperate ebuild is the best solution! But we really need the firmware files somehow in an ebuild.

Oops. i was referring to  Stefan Schweizer (new dev) and not Stefan Briesenick
. sorry for the confusion, i should not post to bugzilla so early in the
morning :P

oh, one last hint:

don't add all firmware files of firmware.tar.bz2. Most/some of them are part of isdn4k-utils and installed with this ebuild.

looking at /etc/capi.conf i'd expect the following filenames:
b1.t4, c4.bin, c2.bin, t1.t4

And these files can be fetched from ftp://ftp.in-berlin.de/pub/capi4linux/firmware
ftp://ftp.in-berlin.de/pub/capi4linux/firmware/b1/3-11-03/b1.t4
ftp://ftp.in-berlin.de/pub/capi4linux/firmware/c2/3-11-04/c2.bin
ftp://ftp.in-berlin.de/pub/capi4linux/firmware/c4/3-11-04/c4.bin
ftp://ftp.in-berlin.de/pub/capi4linux/firmware/t1/3-09-07/t1.t4

But i don't have an active card and don't know much about these firmwares. If questions are open wouldn't it be best to get information from avm? Aren't there other active capi cards that needs some firmware? Will Gentoo redistribute all firmware for all cards (or only avm cards)?

I've found the best source for firmware package. see
http://rpmfind.net//linux/RPM/suse/9.1/i386/suse/i586/i4lfirm-2004.4.5-0.i586.html
for more info.

capi4k-firmware-2004.4.5.ebuild submitted to tree.

stefan: the simple fact that some firmware files are also found in isdn4k-utils
should not constitute a problem. if they have same name it must contain the
same info, right?

ok, back

1. same name, same content. But either we have a single firmware ebuild for all firmwares or we have to split. Dupes are a very bad idea!

2. rpmfind found the ordinary SuSE-package. The best source for it is NOT rpmfind, but the official SuSE FTP server. ;-)

3. AVM don't offer these firmware files on their FTP. It's included in some of their tar.gz for older SuSEs. For 8.1 and above, they say, that "all you need" is included on the SuSE CDs. So believe me, SuSE is the very best source top pickup the firmware files. There's the i4l_firm-xxxxx.rpm packages. We can use them. I used the src.rpm which may be not a good idea because of the size.

btw: another source could be the debian mirrors.

But SuSE is really source #1.

So you aren't happy with the rpm found by me at
ftp://ftp.suse.com/pub/suse/i386/9.1/suse/i586/ ? It seems the most up2date and
it does not contain additional garbage!

Yes, dupes are not preferred, but in case the duplicate are the same I think we
could turn the eyes to the other way. It is bad for maintenance to be selective
about files you want to install from an archive.
Besides, I am waiting your promised contribution to isdn4k-utils ;)

1. the current capi4k-firmware ebuild is ok for the time being ;)

2. I was too busy today, but tomorrow (this is today, but later after sleep), I will continue my work on isdn4k-utils. But this is a little bit more work than capi4k. But I promised it, I do it. And it will be smart as capi4k! ;-)

3. next topic on the horizon: passive cards + capi. On one hand, we need *working* ebuilds for the AVM Fritz! card series (closed source drivers but with G3 fax support), on the other hand there's mISDN.

* please remove the generated device again (see old ebuilds)

  dodir /dev /usr/share/isdn
  emake DESTDIR=${D} install || die "make install failed"
+ rm -rf ${D}/dev


* files/20041006/config

- CONFIG_MANDIR='/usr/man'
+ CONFIG_MANDIR='/usr/share/man'

reopen at tove's request

no harm done if we create a device (/dev/capi20) which will be overwritten by
udev/devfs, but if udev fails to create it, our users will bless us, especially
when they have RC_DEVICE_TARBALL=yes. motion denied ;)

I've corrected the man path. not issued a new release because the result isn't
in fact any different as precedent (/usr/man is a symlink to /usr/share/man).

But we should not add the dev if the user uses udev, because we shoudl not
overwrite the udev device:

if [ -e ${ROOT}/dev/.udev ]
then
   rm ${D}/dev -R
fi

And we should not have the /dev in qpkg -l for udev users.

First, the device doesn't get into qpkg -l, probably because packages cannot
have devices.
Second, if the udev creates its capi20 device, it will overwrite the device
installed by ebuild; udev create devices when the module is loaded.
This is the safe way.