Could you expand the yaps.rc by this entry: [Cityruf] protocol tap valid-pid 0168|0164 change-pid - convert *no-8bit,cv-default,cv-extend phone 016902 max-size 80 use-call-id False insert-pager-id False truncate True The Cityruf is missing in the original yaps.rc Reproducible: Always Steps to Reproduce: 1. n/a 2. 3. Expected Results: Native support of Cityruf by yaps
*** Bug 105677 has been marked as a duplicate of this bug. ***
does noone maintain this package anymore? I received no answers at all. Is a maintainer neeeded?
I will fix it when I'll have the time. right now I'm pretty busy in real life as well as in gentoo life. don't worry, the next version will have this entry in yaps.rc.
please attach the patch
Please attach a patch. I'm not sure where should I include this section (yaps.rc sounds like gibberish to me).
Created attachment 70578 [details, diff] Patchfile to yaps.rc to extend it for the service Cityruf sorry for the delay, I was quite busy the last days. This is my first patchfile so I hope I made it correct.
fixed in yaps-0.96-r1
>>> Unpacking yaps-0.96.c2.tgz to /var/tmp/.gentoo/portage/yaps-0.96-r1/work * Applying yaps-0.96-gentoo.patch ... * Failed Patch: yaps-0.96-gentoo.patch ! * ( /usr/portage/app-mobilephone/yaps/files/yaps-0.96-gentoo.patch ) * * Include in your bugreport the contents of: * * /var/tmp/.gentoo/portage/yaps-0.96-r1/temp/yaps-0.96-gentoo.patch-15280.out
Created attachment 70721 [details] yaps-0.96-gentoo.patch-15280.out hmmm. this package worked in the past.
hmm... work as expected on my machine: ss@alin ~/gentoo-cvs/app-mobilephone/yaps $ ebuild yaps-0.96-r1.ebuild unpack >>> md5 files ;-) yaps-0.96.ebuild >>> md5 files ;-) yaps-0.96-r1.ebuild >>> md5 files ;-) files/yaps-0.96.patch >>> md5 files ;-) files/digest-yaps-0.96-r1 >>> md5 files ;-) files/yaps-0.96-gentoo.patch >>> md5 files ;-) files/digest-yaps-0.96 >>> md5 files ;-) files/yaps-0.96-capiv3.patch >>> md5 src_uri ;-) yaps-0.96.tar.gz >>> Unpacking source... >>> Unpacking yaps-0.96.tar.gz to /var/tmp/portage/yaps-0.96-r1/work * Applying yaps-0.96-gentoo.patch ... [ ok ] * Converting 'yaps.doc' to UTF-8 >>> Source unpacked.
no, even after "emerge sync", your patch is still broken. but the old app-mobilephone/yaps-0.96 works perfectly.
please try USE-flag "capi" also, since it uses a different source-package!
I try to fix the patch-file.
ok, I found the error. You moved the cd ${S}, while your patch includes the basedir of the non-capi yaps. The capi-yaps has a different basedir! The original patch had no paths included for this specific reason. I will fix it! But next time, please check the ebuild with every USE flag if you modified it. Thanks.
ok, fixed ebuild & patch in portage now.
(In reply to comment #14) > I will fix it! But next time, please check the ebuild with every USE flag if > you modified it. Thanks. > hmmm... I don't think you could abuse of use function like that: use capi && S="${S}.c2" If I remember correctly, we are not allowed to call functions in global scope, not to mention the S="${S}.c2" that could lead to nasty side effects if is interpreted more than once. Instead, you should do: pkg_setup() { if use capi ; then S="${WORKDIR}/${P}.c2" fi }
no problem, I can fix this. But it has basically the same result then. So your patch would fail nonetheless. No matter where I place this command. Problem is, that I have to use 2 different source-packages, which contain different base dirs. The more ugly option would be to split this into two ebuilds.
pkg_setup() doesn't work for me. ${S} is always reset to the global value. I have to solve it (more ugly) differently.
ok, fixed in portage.
what about this solution: pkg_unpack() { unpack ${A} if use capi ; then mv ${S}.c2 ${S} fi } seems a better way of dealing with different $S
should be possible. I change this later, though I have a working solution now. nonetheless, I still don't understand why you included the base path in the patchfile.
modified version is in portage now.
(In reply to comment #21) > nonetheless, I still don't understand why you included the base path in the > patchfile. I always generate patches by running diff -Nru foo.orig foo, where foo is the source directory.
