This is automatic keyboard layout switcher (like Punto Switcher for Windows). It analise typing symbols and try to determine language. In case of invalid current layout it deletes typed word, changes layout and repeat typing in proper locale. Currently supported locales are: English, Russian, Ukrainian. As I understand, XNeur is main daemon. And gXNeur - GUI for XNeur. Reproducible: Always Steps to Reproduce:
Created attachment 112207 [details] x11-misc/xneur-0.4.0.ebuild I cannot determine proper categori for these ebuild and temporarily place it to x11-misc.
Created attachment 112208 [details] x11-misc/gxneur-0.4.0.ebuild
0.5.0 are out
Created attachment 113211 [details] x11-misc/xneur-0.5.0.ebuild
Created attachment 113213 [details] x11-misc/gxneur-0.5.0.ebuild
Created attachment 122829 [details] x11-misc/xneur-0.6.1.ebuild
Created attachment 122830 [details] x11-misc/gxneur-0.6.1.ebuild
New version of gxneur/xneur released. Added support for Romanian and French languages.
Created attachment 122832 [details] x11-misc/gxneur-0.6.1.ebuild Added desktop entry
Here is ebuilds for gentoo http://xneur.ru/wiki/Downloads (http://dists.xneur.ru/release-0.6.2/ebuilds/ebuilds-0.6.2.tar.bz2) Can you add them into portage ?
Created attachment 133405 [details] x11-apps/xneur/xneur-0.8.0.ebuild
Created attachment 133407 [details] x11-apps/gxneur/gxneur-0.8.0.ebuild
Created attachment 133408 [details] kde-misc/kxneur/kxneur-0.8.0.ebuild
IMO summary should be changed to: New ebuilds: xneur-0.8.0, gxneur-0.8.0 and kxneur-0.8.0
(In reply to comment #14) > IMO summary should be changed to: > New ebuilds: xneur-0.8.0, gxneur-0.8.0 and kxneur-0.8.0 > ok
Some notes on xneur-0.8.0 ebuild: 1. Please fix repoman warnings: LICENSE.missing ebuild.badheader ebuild.minorsyn 2. Better use econf $(use_with use feature) and $myconf is not necessary. 3. New ebuild should contain ~arch instead of arch (should be masked). 4. Why --with-x is required? 5. DEPEND on pkgconfig is missed (read configure.in) 6. Missed DEPEND on freealut. 7. Do not forgive to dodoc all documents but LICENSE, COPYING, INSTALL. BTW, all this list is for review only. I'll make ebuild with this changes applied available in a moment...
Well I've put all ebuilds with mentioned here and some other fixes here: http://overlays.gentoo.org/dev/pva/browser/x11-apps I need to test them more, and BTW kxneur crashs here. Does anybody reproduces the crash?
Created attachment 154125 [details] x11-apps/xneur/xneur-0.8.0.ebuild
Comment on attachment 154125 [details] x11-apps/xneur/xneur-0.8.0.ebuild Add USE-flag openal
lexa, that openal support is "fixed" in my overlay. Take a look at ebuilds there. But this package still no-go to the tree as it still crashes here... Also take a look at comment for ebuild in comment #16. Some of them still applies for your ebuild too ;)
(In reply to comment #14) > IMO summary should be changed to: > New ebuilds: xneur-0.8.0, gxneur-0.8.0 and kxneur-0.8.0 > authors provide new versions (0.9.0), please add it.
(In reply to comment #21) > authors provide new versions (0.9.0), please add it. Try svn version from my overlay. 0.9.0 still has some issues, svn is better, but still requires some tests...
Peter Volkov why gxneur and kxneur cannot be merged simultaneously?
I setup gxneur/xneur 0.9.0_p106 and cannot use it (under Gnome). Them works very strange and mostly when not need (for example when I write this text it try switch to russian), but when I before fifteen minutes try switch wrong text it does not work. Also it has problems with quality - try write "wrong", then remove four last letters by backspace and write also "wrong" (result should be "wwrong"), when you press space neur changes it to: "wwroццкщтп ".
Sergey could you report this problems to upstream mailing list, please? http://lists.net.ru/cgi-bin/mailman/listinfo/xneur And yes with this new version I'm completely unable to use xneur. Just nothing happens. But that could be my misconfiguration, I need to check... (In reply to comment #23) > why gxneur and kxneur cannot be merged simultaneously? That's because they install same files. So to avoid collisions I've added blocker. BTW, may be there is a nicer way to handle that, like installing icons in different locations for kxner and gxneur, but I have not investigated that yet... Note that with such approach you'll have icons installed twice but they are small, so not a big deal. Patches welcome ;)
gxneur installs pixmaps under /usr/share/pixmaps/gxneur, kxneur I do not test yet, but I think it is possible install gxneur and kxneur simultaneously.
Created attachment 158983 [details] x11-apps/xneur/xneur-0.9.0.ebuild add aplay use flasg
(In reply to comment #27) > Created an attachment (id=158983) [edit] > x11-apps/xneur/xneur-0.9.0.ebuild > > add aplay use flasg Chukchi is not reader, chukchi is writer... Jokes aside, please, read this bug? Have you seen ebuilds in my overlay? That use flag is already there... There is no need to duplicate efforts and write ebuild when one's already written. If you have improvements, attach patch to ebuild from MY OVERLAY here. I really appreciate comments, about ebuilds here and reports about xneur work at upstream mailing list. But really creating even more comments here with or without ebuilds is completely useless and takes time... Thank you for understanding. To simplify all further people life below are the command you need to run to get ebuilds: $ svn co http://overlays.gentoo.org/svn/dev/pva/x11-apps/ That's it. You have directory x11-apps with ebuilds inside. Enjoy.
Created attachment 160817 [details] x11-apps/xneur
Created attachment 160819 [details] kde-misc/kxneur-0.9.0
Comment on attachment 160819 [details] kde-misc/kxneur-0.9.0 Obsoletting completely dirty ebuilds. Don't use them. Alexy take a look at comment #28. It concerns you too.
Comment on attachment 160817 [details] x11-apps/xneur ><?xml version="1.0"?><html><body><pre># l6xus l6xus@jabber.ru on ira-station Linux 2.6.23-gentoo-r3 ># Sat, 19 Jul 2008 07:38:26 +0700 >DESCRIPTION="X auto keyboardlayout switcher" >HOMEPAGE="http://www.xneur.ru/" >RESTRICT="nomirror" >SRC_URI="http://dists.xneur.ru/release-${PV}/tgz/${P}.tar.bz2" >LICENSE="GPL-2" >SLOT="0" >KEYWORDS="~x86 x86" >IUSE="aspell gstreamer openal aplay debug xpm" >DEPEND="x11-base/xorg-x11 > openal? (>=media-libs/freealut-1.0.1) > aplay? (media-sound/alsa-utils) > gstreamer? (media-libs/gstreamer) > aspell? (app-text/aspell) > xpm? (x11-libs/libXpm)" >src_compile() { >for sound in gstreamer openal aplay ; do > if use "${sound}" ; then > export EXTRA_ECONF="${EXTRA_ECONF} --with-sound=${sound}" > fi >done >if [ -z "${EXTRA_ECONF}" ] ; then > export EXTRA_ECONF="--with-sound=no" >fi >export EXTRA_ECONF="${EXTRA_ECONF} $(use_with aspell) $(use_with debug) $(use_with xpm)" >econf || die "econf failed" >emake || die "emake failed" >} >src_install() { >make DESTDIR="${D}" install || die >} ></pre></body></html>
Status update and test request. Well, finally my own tests reveal that we are closer to our final point which is having working {,k,g}xneur packages in the tree. 0.9.2 release is very close so I've fixed some bugs and updated/cleaned ebuilds in my overlay and now I encourage everybody to test this package another time and report any problems you'll find. Reports should go either here or at upstream mailing list. For those who forgot how to get ebuilds this commands should help: $ cd /your/local/overlay $ svn co http://overlays.gentoo.org/svn/dev/pva/x11-apps/ Enjoy.
Small status update. I've moved xneur and gxneur ebuilds to Sunrise overlay: http://overlays.gentoo.org/proj/sunrise/browser/sunrise/x11-misc/xneur http://overlays.gentoo.org/proj/sunrise/browser/sunrise/x11-misc/gxneur You can use/improve them there. To use sunrise overlay just do # layman -a sunrise ... kxneur (qt3 version frontend for xneur) is not maintained any more. Probably at some point it'll be rewritten with qt4 and then kxneur gets new life, but ... it's still not happened.
Xneur 0.9.4 has been released. Please bump version in overlay.
Created attachment 193055 [details, diff] patch for xneur ebuild
Comment on attachment 193055 [details, diff] patch for xneur ebuild Thank you Jan. xneur was updated in Sunrise overlay. gxneur will be updated in few moments. BTW, guys, note: Sunrise is users overlay, so any user could update ebuild. Just check sunrise guide how to get access and move ahead! Enjoy.
Created attachment 207188 [details] Renamed xneur-0.9.5.ebuild from sunrise overlay(bumping new version)
Created attachment 207189 [details] Renamed gxneur-0.9.5.ebuild from sunrise overlay(bumping new version)
Pinkbyte, please, read bug before commenting/updating: ebuilds for this package are in Sunrise overlay and there is no need attach ebuilds here. And taking into account that you attached very old versions of ebuilds I wrote for versions before 0.9.3 was out, I really do not see how this crap could be useful. IOW, it's cool that you've managed to rename files in linux but this doesn't help to maintain ebuilds. E.g. in 0.9.7 imlib and xpm support was dropped; also upstream made clear that aspell should be enabled by default (read announcement). All of this should be followed in ebuilds. And also, in general, do not attach ebuilds to bugzilla in case ebuilds _are already commited_ to the tree/overlay. Attach only diff -u. This greatly simplifies review of changes you propose (and if there are no changes, then what's the point to attach it?). Thanks. BTW, guys, if anybody really wishes to help, next time, just read NEWS/announcement, compare configure.ac with previous version and update ebuild in sunrise appropriately. It's not hard, but just takes time as most things in this world. And yes, if you don't feel brave to update packages in Sunrise, just add a note here that new version was out... 0.9.7 bumped.
I am sorry, but i do not belong to sunrise community and i think that if ebuild can correctly compile and install program, then it is right ebuild. These ebuilds installed correctly on two Gentoo systems, that's why i decided to upload them here.
And, by the way, i read announcements, but i think that shit and crappy ebuild is better then none. I have no time right now to make good ebuild, but i think that i must report developers like you about this situation...
(In reply to comment #41) > I am sorry I've tried not to blame you, so sorry if that felt like that. And don't make my comments stop you in future... Just try to get something useful from them. > i do not belong to sunrise community Sunrise people help/teach how to write correct/clean ebuilds and such ebuilds are really appreciated by community. Since you know English I welcome you to join ;) > i think that if ebuild can correctly compile and install program, then it is > right ebuild. That's wrong assumption many people were led to by ease to write/understand ebuilds. Look most packages could be installed with ./configure && make && make install combo, so generally if ebuild defines correct SRC_URI and S and src_install() { emake DESTDIR=$D install } you'll manage to emerge xneur, gxneur and lot's of other software. BUT obviously ebuild will be wrong, since it does not have correct DEPEND, LICENSE information, it does not allow you to enable/disable features using USE flags. Of course what I wrote here is rough overestimation, but still it illustrates my vision. > And, by the way, i read announcements, but i think that shit and crappy ebuild > is better then none. I agree in case you use such ebuilds privately. But I disagree in case you suggest such ebuilds on Gentoo bugzilla for general consumption. Also since this ebuild was just a copy of previous version, it's much more useful if you add comment that cp xneur-0.9.5 xneur-0.9.7 worked for you. > I have no time right now to make good ebuild, but i think > that i must report developers like you about this situation... Right, just report version bumps for xneur/gxneur here. We really welcome that. And now, let's stop this discussion here. If you have more general questions, please ask me privately. Let's keep this bug for bug reports about {,g}xneur.
Created attachment 233151 [details] ebuild for xneur 0.9.8
Created attachment 233153 [details] ebuild for gxneur 0.9.8
Created attachment 233155 [details] ebuild for xneur 0.9.9
Created attachment 233157 [details] ebuild for gxneur 0.9.9
i've uploaded ebuilds for xneur/gxneur 0.9.8/0.9.9 works fine please, add them to sunrise overlay
Alex, please, attach diff. Also we need ebuilds for latest (0.9.9) versions only.
There isn't any diff. I've just renamed ebuilds and everything works fine. There were no ebuilds for a long time, so I've just uploaded them for other looking for latest xNeur version.
Alex, thank you. Next time just a short note that new version was out, previous ebuild works is enough. Both ebuilds were updated in sunrise. Guys if you use this package, please, step in and start maintaining this package! :) As always I can help but I'm not using this package and thus we need somebody to maintain it.
There is a new version. XNeur and gXNeur 0.11.1.
Yup, here is TODO, I hope somebody helps me to do: 1. Update aspell dependency on enchant and check that xneur works with myspell 2. Add support for openmp If you update ebuild, please, provide here only diff. TIA.
That is the first time I write ebuild, so it may be badly written. I attach the diff. I don't know to way to test Enchant support. I just removed all aspell packages and installed enchant with hunspell and myspell and xneur worked fine. Also, I don't know the way to test OpenMP support. For gXNeur, I guess it's unnecessary to make any changes in ebuild.
Created attachment 256406 [details, diff] Patch for xneur ebuild for 0.11.1 version.
Comment on attachment 256406 [details, diff] Patch for xneur ebuild for 0.11.1 version. Thank you Alex. New versions were bumped in Sunrise and will became available shortly.
xneur is 0.15.0 now. Will this version bumped in any overlay?
Yep, it's in Sabayon overlay.
And what in result? The xneur ebuild supported only in "sabayon" overlay? Stop ebuild bumping into "sunrise" overlay? Could we change instructions on apps site, where the user will install from?
A package can be in sunrise as long as it is not in the main portage tree. Its presence in another overlay does not prevent a sunrise user who is willing to do so from committing a new version.
I know it, thank you. The question is bout another problem. Why user commited to another overlay, not in sunrise? And why the assigneer didn't commit the new version in sunrise. It's not applicable to commit different versions in several overlays. The user need one guaranteed way to install the latest version of application. If last version app ebuild always will be in "sabayon" overlay, we just will change the instructions in app site to not confuse the user.
I understand your concern. However: > Why user commited to another overlay, not in sunrise? I work on Sabayon overlays. (Sabayon is a binary distribution that is based on Gentoo, and it's compatible with Gentoo.) Some time ago an user has requested these packages to be included, so - as it's not in Portage - it needs to be in one of Sabayon overlays. That's why I maintain it there. Anyone can commit it to Sunrise. For example one could duplicate my ebuild from Sabayon (as two overlays seem to do it already, so you have choice from where you want it) and put it there. > If last version app ebuild always will be in "sabayon" overlay, we just will > change the instructions in app site to not confuse the user. I don't use xneur/gxneur myself but I'm going to keep maintaining it in that overlay.
Ok. I understand that. Can we go to the result? I see several ways to resolve: 1. Peter Volkov make (copy) for the latest version of xneur/gxneur to "sunrise" 2. Enlik will start to maintain the ebuilds in 2 overlays: "sabayon" and "sunrise" - duplicate and commit, if Peter is busy. 3. Delete xneur from "sunrise" overlay and maintain only in "sabayon". We need Peter's opinion in this situation. P.S. Peter Volkov's ebuild and Enlik's are different. In depending to gxneur, for example.
There is one more solution: maintain xneur-related ebuilds in portage tree, not in overlay. Peter did not do this earlier for some reasons. Anyway, let's wait for his answer... P.S. And one more question - how about proxy-maintaining this ebuilds?
(In reply to comment #63) Why? Any user can commit an updated ebuild (after review). The concept of maintainer does not exist in sunrise. There is no need for a particular person to do anything. (In reply to comment #64) If you are willing to proxy maintain this package, contact the proxy-maintainers team.
(In reply to comment #65) > The concept of maintainer does not exist in sunrise. There is no need > for a particular person to do anything. I know it. But this is not a good solution by several reasons: - Addition changes could be appeared to pass the check. Addition time and knowledge are required. - The ebuild properties (like dependencies, I talked about) can be changed from one commiter to another. We will get different styles. - The guarantee to make ebuild for the latest version of xneur. Why I won't commit the ebuild? I've no time to maintain: check errors, read the ebuild documentation. Why Enlik not commiting to "sunrise"? Don't know. Maybe because "xneur ebuild" already has maintainer Peter Volkov?
Reassigning to maintainer-wanted@ due Peter's inactivity
Hello, everyone. It seems that at least one ebuild related to this bug exists in the Sunrise overlay at the moment. However, I have to regretfully announce that after a long inactivity period the Sunrise project has been discontinued and the related overlay will be eventually removed. For this reason, I'd like to ask you to reevaluate the ebuilds and consider moving them. If you'd like to maintain a package from Sunrise in Gentoo, please take a look at our Proxy Maintainers [1] project. Please make sure to take ebuilds from the unreviewed developer Sunrise repository [2] rather than the -reviewed one, since the latter has not been updated for over a year. While at it, please note that: 1. Adding a package to Gentoo requires declaring yourself as an active maintainer for it. All bugs regarding the package will be assigned to you, and you will be expected to maintain it. 2. Some packages may not be suitable for addition anymore. While there's no strong rules that would prevent you from adding a package, it may be a bad idea to add old-unmaintained packages that will shortly result in a large number of bugs reported with no solution. If that is the case, please close the bug as RESOLVED/OBSOLETE to make it easier to find packages worth adding. 3. Some of the bugs were already closed as WONTFIX/OBSOLETE/... while the relevant ebuild was kept in Sunrise. If you disagree with the original decision, you still can add the ebuild via proxy-maint. 4. Pleaes note that many of the Sunrise ebuilds are old and may be buggy. If you decide to move them, please make sure to update/clean them up. The proxy-maint team will also review your ebuilds, therefore making sure they land in Gentoo in good quality. Once again, thank you for your contribution. We hope that you will still want to contribute to Gentoo, through proxy-maint or otherwise. [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers [2]:https://gitweb.gentoo.org/proj/sunrise.git/
