Re: [aur-general] python-foo and python2-foo - should they conflict?
On Tue, Oct 16, 2012 at 5:02 PM, Felix Yan wrote:
> As mentioned in the Arch Packaging Standards [1]:
> /usr/share/doc/{pkg}Application documentation
>
> You should rename the documentation folder of your packages to
> /usr/share/doc/$pkgname, so there would be not anymore conflict.
>
> [1] https://wiki.archlinux.org/index.php/Arch_Packaging_Standards
The thing is both use /usr/share/doc/python-foo. Yeah I guess it makes
sense that one should use /usr/share/doc/python2-foo, thanks =)
Re: [aur-general] ibus orphans in [community]
On Tue, Oct 16, 2012 at 9:08 PM, Masato Hashimoto wrote: > On Tue, 16 Oct 2012 12:55:39 -0400 > Allen Li wrote: > > >> so dropping it >> is extremely unfavorable I think. >> >> Just my two cents. >> >> Allen Li > > +1 > > AFAIK, ibus is default input method framework of Fedora, Ubuntu and > openSUSE. Not really for openSUSE[1] now. [1] http://en.opensuse.org/Features#Input_Methods > It's most popular in CJK wide. It's popular because it is the default and it is the default because of their names and some historical reasons. > -- > HASHIMOTO, Masato
Re: [aur-general] Packages depends on either python 2 or 3
On Wed, Oct 17, 2012 at 4:01 AM, Felix Yan wrote: > Hi all, > > I have written a tool [1] in python and packaged it in AUR [2], now I > have the following problem: > > 1) The tool is written compatible with python 2.7 and 3.x, so I'd like > to depends on something like (python>=2.7), but the package python2 > does not provides python=$pkgver. So what should the package depend > on? (is there an "or"-like operator in depends=?) You can't specify an "OR dependency relation" in a PKGBUILD, so it's up to you whether it'll depend on 'python' or 'python2'. > 2) How about the shebang line then? Now it is "/usr/bin/env python" > but if the user only installed python2 this won't work correctly in > the default case. "/usr/bin/env python3" if you decide on Python 3; "/usr/bin/env python2" otherwise. It may be a good idea to keep "/usr/bin/env python" on Github and change it using sed(1) in the PKGBUILD. This way the upstream script will support both major Python versions, while the AUR package can be tailored for Arch. > I've been keeping a watchful eye on recent rebuilds of python > packages, but still confused about the above situation, thanks for any > ideas :) > > [1] https://github.com/felixonmars/ydcv > [2] https://aur.archlinux.org/packages.php?ID=62759 > > Felix Yan > Twitter: @felixonmars > Wiki: http://felixc.at
Re: [aur-general] ibus orphans in [community]
On Tue, 16 Oct 2012 12:55:39 -0400 Allen Li wrote: > so dropping it > is extremely unfavorable I think. > > Just my two cents. > > Allen Li +1 AFAIK, ibus is default input method framework of Fedora, Ubuntu and openSUSE. It's most popular in CJK wide. -- HASHIMOTO, Masato
[aur-general] Packages depends on either python 2 or 3
Hi all, I have written a tool [1] in python and packaged it in AUR [2], now I have the following problem: 1) The tool is written compatible with python 2.7 and 3.x, so I'd like to depends on something like (python>=2.7), but the package python2 does not provides python=$pkgver. So what should the package depend on? (is there an "or"-like operator in depends=?) 2) How about the shebang line then? Now it is "/usr/bin/env python" but if the user only installed python2 this won't work correctly in the default case. I've been keeping a watchful eye on recent rebuilds of python packages, but still confused about the above situation, thanks for any ideas :) [1] https://github.com/felixonmars/ydcv [2] https://aur.archlinux.org/packages.php?ID=62759 Felix Yan Twitter: @felixonmars Wiki: http://felixc.at
Re: [aur-general] Removal request: libtcod-beta
On 16/10/12 04:40 PM, Joao Cordeiro wrote: > Hi, > > Can you please remove the AUR package libtcod-beta [1]? > > I am the maintainer but there is not longer a beta version of the library. > It has become stable. > > Thanks > João > > [1] http://aur.archlinux.org/packages.php?ID=48698 Deleted, thanks. signature.asc Description: OpenPGP digital signature
[aur-general] Removal request: libtcod-beta
Hi, Can you please remove the AUR package libtcod-beta [1]? I am the maintainer but there is not longer a beta version of the library. It has become stable. Thanks João [1] http://aur.archlinux.org/packages.php?ID=48698
Re: [aur-general] ibus orphans in [community]
Hi all, Another FYI about the ibus integration in gnome-shell: There is an official instruction [1] from gnome to disable ibus-integration, that brings us at least two ways to go: 1) Packaging gnome-settings-daemon and gnome-control-center as-is, and split ibus package to something like ibus-common or libibus. (Obviously better) 2) Disable ibus-integration at compile time and thus no option for user to enable it without a re-compilation. [1] https://live.gnome.org/ThreePointFive/Features/IBus Felix Yan Twitter: @felixonmars Wiki: http://felixc.at
Re: [aur-general] ibus orphans in [community]
On 17 October 2012 02:05, Yichao Yu wrote: > On Tue, Oct 16, 2012 at 1:47 PM, Yichao Yu wrote: >> On Tue, Oct 16, 2012 at 1:30 PM, Rashif Ray Rahman >> wrote: >>> On 17 October 2012 00:55, Allen Li wrote: Hi, I would like to point out that ibus does Japanese and Korean, whereas fcitx only does simplified Chinese (at least according to the wiki). Thus ibus is one of the only input options for those languages on arch at the moment (barring that other one whose name I'm having trouble recalling at the moment, which I found inferior to ibus), so dropping it is extremely unfavorable I think. Just my two cents. Allen Li On Tue, Oct 16, 2012 at 05:30:30PM +0200, Alexander Rødseth wrote: > Hello, > > > ibus is used for keyboard input for a few major non-English languages. > > Several of the ibus packages has been unmaintained for a while now: > https://www.archlinux.org/packages/?sort=&repo=Community&q=ibus&maintainer=orphan > For instance, ibus-sunpinyin, was last updated almost a year ago > (2011-10-02). > > These ibus-packages have survived at least one package-cleanup, being > neither adopted nor moved. > While there is interest amongst the trusted users to maintain these, > none of the trusted users are currently using ibus. > > After visiting #archlinux-cn, a couple of friendly people expressed > interest in maintaining the ibus packages, but they had only few > packages on AUR to show for. > I also learned that mostly, fcitx (currently in [extra], is used > instead of ibus). Dropping ibus could have been an option, but I also > heard rumors that ibus will be a dependency of gnome-settings-daemon. > > There is also a canidate for asking to maintain the ibus packages, > that has not yet been contacted, but which already maintains several > related packages on AUR: > https://aur.archlinux.org/packages.php?K=yangtsesu&SeB=m > > If you think that his packages look ok, my plan is to contact > yangtsesu and ask if he wants to maintain the ibus packages in > [community] (and thus becoming a TU). > > If you know of other canidates that have a comparable selection of > relevant AUR packages, please let us know who they are. > > Please correct me if any of the above is incorrect or let us know if > you have additional information. > > Sounds like a plan? > > > -- > Cordially, > Alexander Rødseth > Arch Linux Trusted User > (xyproto on IRC, trontonic on AUR) >>> >>> Also, fcitx looks very CJK-specific to me, whereas ibus is a >>> multilingual input bus (think SCIM). So, not really directly >>> comparable. I'm all for finding someone to maintain the stuff, be it >>> in the repos or AUR. >> >> No, fcitx is also not cjk-specific at all. There is fcitx-keyboard >> (which is already merged into fcitx itself) that you can use keyboard >> layout as input method to input all languages that just need a layout >> switching. It also has spell check/hint(as you can see on the fcitx >> wiki main page..) which ibus cannot provide. Here[1] is also a list of >> input method fcitx support now (basically covers all major input >> method ibus supports). Yes most of them are Chinese input method but >> that's because Chinese input method is the single most complicated >> one. (also true for ibus). >> >> Yes the original name of fcitx suggest it is a Chinese input method >> but it is not anymore now >> >> And no, I am not talking about dropping ibus packages (taking into >> account the *stupid* thing gnome3.6 have been doing on input method >> integration, it might not be a good idea to move those into AUR >> either..). Just want to clarify that fcitx is not CJK specific (in >> fact it provides more non-CJK specific features than ibus and scim >> now, e.g. spell, clipboard, lua, xkb, quickphrase etc...) and want to >> encourage people to try fcitx for its handful features even for >> non-CJK ppl. >> >> [1] http://fcitx-im.org/wiki/Distribution_Package_Status >> >>> >>> >>> -- >>> GPG/PGP ID: C0711BF1 > > Just a little bit more noise about fcitx and ibus packages. > > Among those fcitx package in AUR, either fcitx-configtool or kcm-fcitx > is already a implicit dependency of fcitx (depending on the DE u r > using) since editing the configure file is no longer supported. > fcitx-sunpinyin and fcitx-cloudpinyin are also installed by most > Chinese fcitx users so it will be really nice to see these package > (along with Japanese and Korean ones) in the official repo (which I am > sure Felix Yan can be a good maintainer). > > For ibus packages, it is also not a good idea to drop any of the > existing ibus input methods which is already in the official repo. All > of them are required package if you want to use ibus to input in those > languages. (Since the upstream of most of the pa
Re: [aur-general] ibus orphans in [community]
On Tue, Oct 16, 2012 at 1:47 PM, Yichao Yu wrote: > On Tue, Oct 16, 2012 at 1:30 PM, Rashif Ray Rahman > wrote: >> On 17 October 2012 00:55, Allen Li wrote: >>> Hi, >>> >>> I would like to point out that ibus does Japanese and Korean, whereas >>> fcitx only does simplified Chinese (at least according to the wiki). >>> Thus ibus is one of the only input options for those languages on arch >>> at the moment (barring that other one whose name I'm having trouble >>> recalling at the moment, which I found inferior to ibus), so dropping it >>> is extremely unfavorable I think. >>> >>> Just my two cents. >>> >>> Allen Li >>> >>> On Tue, Oct 16, 2012 at 05:30:30PM +0200, Alexander Rødseth wrote: Hello, ibus is used for keyboard input for a few major non-English languages. Several of the ibus packages has been unmaintained for a while now: https://www.archlinux.org/packages/?sort=&repo=Community&q=ibus&maintainer=orphan For instance, ibus-sunpinyin, was last updated almost a year ago (2011-10-02). These ibus-packages have survived at least one package-cleanup, being neither adopted nor moved. While there is interest amongst the trusted users to maintain these, none of the trusted users are currently using ibus. After visiting #archlinux-cn, a couple of friendly people expressed interest in maintaining the ibus packages, but they had only few packages on AUR to show for. I also learned that mostly, fcitx (currently in [extra], is used instead of ibus). Dropping ibus could have been an option, but I also heard rumors that ibus will be a dependency of gnome-settings-daemon. There is also a canidate for asking to maintain the ibus packages, that has not yet been contacted, but which already maintains several related packages on AUR: https://aur.archlinux.org/packages.php?K=yangtsesu&SeB=m If you think that his packages look ok, my plan is to contact yangtsesu and ask if he wants to maintain the ibus packages in [community] (and thus becoming a TU). If you know of other canidates that have a comparable selection of relevant AUR packages, please let us know who they are. Please correct me if any of the above is incorrect or let us know if you have additional information. Sounds like a plan? -- Cordially, Alexander Rødseth Arch Linux Trusted User (xyproto on IRC, trontonic on AUR) >> >> Also, fcitx looks very CJK-specific to me, whereas ibus is a >> multilingual input bus (think SCIM). So, not really directly >> comparable. I'm all for finding someone to maintain the stuff, be it >> in the repos or AUR. > > No, fcitx is also not cjk-specific at all. There is fcitx-keyboard > (which is already merged into fcitx itself) that you can use keyboard > layout as input method to input all languages that just need a layout > switching. It also has spell check/hint(as you can see on the fcitx > wiki main page..) which ibus cannot provide. Here[1] is also a list of > input method fcitx support now (basically covers all major input > method ibus supports). Yes most of them are Chinese input method but > that's because Chinese input method is the single most complicated > one. (also true for ibus). > > Yes the original name of fcitx suggest it is a Chinese input method > but it is not anymore now > > And no, I am not talking about dropping ibus packages (taking into > account the *stupid* thing gnome3.6 have been doing on input method > integration, it might not be a good idea to move those into AUR > either..). Just want to clarify that fcitx is not CJK specific (in > fact it provides more non-CJK specific features than ibus and scim > now, e.g. spell, clipboard, lua, xkb, quickphrase etc...) and want to > encourage people to try fcitx for its handful features even for > non-CJK ppl. > > [1] http://fcitx-im.org/wiki/Distribution_Package_Status > >> >> >> -- >> GPG/PGP ID: C0711BF1 Just a little bit more noise about fcitx and ibus packages. Among those fcitx package in AUR, either fcitx-configtool or kcm-fcitx is already a implicit dependency of fcitx (depending on the DE u r using) since editing the configure file is no longer supported. fcitx-sunpinyin and fcitx-cloudpinyin are also installed by most Chinese fcitx users so it will be really nice to see these package (along with Japanese and Korean ones) in the official repo (which I am sure Felix Yan can be a good maintainer). For ibus packages, it is also not a good idea to drop any of the existing ibus input methods which is already in the official repo. All of them are required package if you want to use ibus to input in those languages. (Since the upstream of most of the packages is not really active, it shouldn't be hard either.)
Re: [aur-general] ibus orphans in [community]
On Tue, Oct 16, 2012 at 1:30 PM, Rashif Ray Rahman wrote: > On 17 October 2012 00:55, Allen Li wrote: >> Hi, >> >> I would like to point out that ibus does Japanese and Korean, whereas >> fcitx only does simplified Chinese (at least according to the wiki). >> Thus ibus is one of the only input options for those languages on arch >> at the moment (barring that other one whose name I'm having trouble >> recalling at the moment, which I found inferior to ibus), so dropping it >> is extremely unfavorable I think. >> >> Just my two cents. >> >> Allen Li >> >> On Tue, Oct 16, 2012 at 05:30:30PM +0200, Alexander Rødseth wrote: >>> Hello, >>> >>> >>> ibus is used for keyboard input for a few major non-English languages. >>> >>> Several of the ibus packages has been unmaintained for a while now: >>> https://www.archlinux.org/packages/?sort=&repo=Community&q=ibus&maintainer=orphan >>> For instance, ibus-sunpinyin, was last updated almost a year ago >>> (2011-10-02). >>> >>> These ibus-packages have survived at least one package-cleanup, being >>> neither adopted nor moved. >>> While there is interest amongst the trusted users to maintain these, >>> none of the trusted users are currently using ibus. >>> >>> After visiting #archlinux-cn, a couple of friendly people expressed >>> interest in maintaining the ibus packages, but they had only few >>> packages on AUR to show for. >>> I also learned that mostly, fcitx (currently in [extra], is used >>> instead of ibus). Dropping ibus could have been an option, but I also >>> heard rumors that ibus will be a dependency of gnome-settings-daemon. >>> >>> There is also a canidate for asking to maintain the ibus packages, >>> that has not yet been contacted, but which already maintains several >>> related packages on AUR: >>> https://aur.archlinux.org/packages.php?K=yangtsesu&SeB=m >>> >>> If you think that his packages look ok, my plan is to contact >>> yangtsesu and ask if he wants to maintain the ibus packages in >>> [community] (and thus becoming a TU). >>> >>> If you know of other canidates that have a comparable selection of >>> relevant AUR packages, please let us know who they are. >>> >>> Please correct me if any of the above is incorrect or let us know if >>> you have additional information. >>> >>> Sounds like a plan? >>> >>> >>> -- >>> Cordially, >>> Alexander Rødseth >>> Arch Linux Trusted User >>> (xyproto on IRC, trontonic on AUR) > > Also, fcitx looks very CJK-specific to me, whereas ibus is a > multilingual input bus (think SCIM). So, not really directly > comparable. I'm all for finding someone to maintain the stuff, be it > in the repos or AUR. No, fcitx is also not cjk-specific at all. There is fcitx-keyboard (which is already merged into fcitx itself) that you can use keyboard layout as input method to input all languages that just need a layout switching. It also has spell check/hint(as you can see on the fcitx wiki main page..) which ibus cannot provide. Here[1] is also a list of input method fcitx support now (basically covers all major input method ibus supports). Yes most of them are Chinese input method but that's because Chinese input method is the single most complicated one. (also true for ibus). Yes the original name of fcitx suggest it is a Chinese input method but it is not anymore now And no, I am not talking about dropping ibus packages (taking into account the *stupid* thing gnome3.6 have been doing on input method integration, it might not be a good idea to move those into AUR either..). Just want to clarify that fcitx is not CJK specific (in fact it provides more non-CJK specific features than ibus and scim now, e.g. spell, clipboard, lua, xkb, quickphrase etc...) and want to encourage people to try fcitx for its handful features even for non-CJK ppl. [1] http://fcitx-im.org/wiki/Distribution_Package_Status > > > -- > GPG/PGP ID: C0711BF1
Re: [aur-general] ibus orphans in [community]
On Tue, Oct 16, 2012 at 12:55 PM, Allen Li wrote: > Hi, > > I would like to point out that ibus does Japanese and Korean, whereas > fcitx only does simplified Chinese (at least according to the wiki). No, not true. There is fcitx-mozc[1][2], fcitx-anthy[3][4], fcitx-m17n[5][6], fcitx-hangul[7][8] which you can use to input Japanese and Korean. Yes, the arch wiki on this is REALLY out-of-date (especially the english version) [1] http://fcitx-im.org/wiki/Mozc [2] https://aur.archlinux.org/packages.php?ID=59251 [3] http://fcitx-im.org/wiki/Anthy [4] https://aur.archlinux.org/packages.php?ID=60146 [5] http://fcitx-im.org/wiki/M17N [6] https://aur.archlinux.org/packages.php?ID=61028 [7] http://fcitx-im.org/wiki/Hangul [8] https://aur.archlinux.org/packages.php?ID=59733 > Thus ibus is one of the only input options for those languages on arch > at the moment (barring that other one whose name I'm having trouble > recalling at the moment, which I found inferior to ibus), so dropping it > is extremely unfavorable I think. > > Just my two cents. > > Allen Li > > On Tue, Oct 16, 2012 at 05:30:30PM +0200, Alexander Rødseth wrote: >> Hello, >> >> >> ibus is used for keyboard input for a few major non-English languages. >> >> Several of the ibus packages has been unmaintained for a while now: >> https://www.archlinux.org/packages/?sort=&repo=Community&q=ibus&maintainer=orphan >> For instance, ibus-sunpinyin, was last updated almost a year ago >> (2011-10-02). >> >> These ibus-packages have survived at least one package-cleanup, being >> neither adopted nor moved. >> While there is interest amongst the trusted users to maintain these, >> none of the trusted users are currently using ibus. >> >> After visiting #archlinux-cn, a couple of friendly people expressed >> interest in maintaining the ibus packages, but they had only few >> packages on AUR to show for. >> I also learned that mostly, fcitx (currently in [extra], is used >> instead of ibus). Dropping ibus could have been an option, but I also >> heard rumors that ibus will be a dependency of gnome-settings-daemon. >> >> There is also a canidate for asking to maintain the ibus packages, >> that has not yet been contacted, but which already maintains several >> related packages on AUR: >> https://aur.archlinux.org/packages.php?K=yangtsesu&SeB=m >> >> If you think that his packages look ok, my plan is to contact >> yangtsesu and ask if he wants to maintain the ibus packages in >> [community] (and thus becoming a TU). >> >> If you know of other canidates that have a comparable selection of >> relevant AUR packages, please let us know who they are. >> >> Please correct me if any of the above is incorrect or let us know if >> you have additional information. >> >> Sounds like a plan? >> >> >> -- >> Cordially, >> Alexander Rødseth >> Arch Linux Trusted User >> (xyproto on IRC, trontonic on AUR)
Re: [aur-general] ibus orphans in [community]
On 17 October 2012 00:55, Allen Li wrote: > Hi, > > I would like to point out that ibus does Japanese and Korean, whereas > fcitx only does simplified Chinese (at least according to the wiki). > Thus ibus is one of the only input options for those languages on arch > at the moment (barring that other one whose name I'm having trouble > recalling at the moment, which I found inferior to ibus), so dropping it > is extremely unfavorable I think. > > Just my two cents. > > Allen Li > > On Tue, Oct 16, 2012 at 05:30:30PM +0200, Alexander Rødseth wrote: >> Hello, >> >> >> ibus is used for keyboard input for a few major non-English languages. >> >> Several of the ibus packages has been unmaintained for a while now: >> https://www.archlinux.org/packages/?sort=&repo=Community&q=ibus&maintainer=orphan >> For instance, ibus-sunpinyin, was last updated almost a year ago >> (2011-10-02). >> >> These ibus-packages have survived at least one package-cleanup, being >> neither adopted nor moved. >> While there is interest amongst the trusted users to maintain these, >> none of the trusted users are currently using ibus. >> >> After visiting #archlinux-cn, a couple of friendly people expressed >> interest in maintaining the ibus packages, but they had only few >> packages on AUR to show for. >> I also learned that mostly, fcitx (currently in [extra], is used >> instead of ibus). Dropping ibus could have been an option, but I also >> heard rumors that ibus will be a dependency of gnome-settings-daemon. >> >> There is also a canidate for asking to maintain the ibus packages, >> that has not yet been contacted, but which already maintains several >> related packages on AUR: >> https://aur.archlinux.org/packages.php?K=yangtsesu&SeB=m >> >> If you think that his packages look ok, my plan is to contact >> yangtsesu and ask if he wants to maintain the ibus packages in >> [community] (and thus becoming a TU). >> >> If you know of other canidates that have a comparable selection of >> relevant AUR packages, please let us know who they are. >> >> Please correct me if any of the above is incorrect or let us know if >> you have additional information. >> >> Sounds like a plan? >> >> >> -- >> Cordially, >> Alexander Rødseth >> Arch Linux Trusted User >> (xyproto on IRC, trontonic on AUR) Also, fcitx looks very CJK-specific to me, whereas ibus is a multilingual input bus (think SCIM). So, not really directly comparable. I'm all for finding someone to maintain the stuff, be it in the repos or AUR. -- GPG/PGP ID: C0711BF1
Re: [aur-general] ibus orphans in [community]
Hi, I would like to point out that ibus does Japanese and Korean, whereas fcitx only does simplified Chinese (at least according to the wiki). Thus ibus is one of the only input options for those languages on arch at the moment (barring that other one whose name I'm having trouble recalling at the moment, which I found inferior to ibus), so dropping it is extremely unfavorable I think. Just my two cents. Allen Li On Tue, Oct 16, 2012 at 05:30:30PM +0200, Alexander Rødseth wrote: > Hello, > > > ibus is used for keyboard input for a few major non-English languages. > > Several of the ibus packages has been unmaintained for a while now: > https://www.archlinux.org/packages/?sort=&repo=Community&q=ibus&maintainer=orphan > For instance, ibus-sunpinyin, was last updated almost a year ago (2011-10-02). > > These ibus-packages have survived at least one package-cleanup, being > neither adopted nor moved. > While there is interest amongst the trusted users to maintain these, > none of the trusted users are currently using ibus. > > After visiting #archlinux-cn, a couple of friendly people expressed > interest in maintaining the ibus packages, but they had only few > packages on AUR to show for. > I also learned that mostly, fcitx (currently in [extra], is used > instead of ibus). Dropping ibus could have been an option, but I also > heard rumors that ibus will be a dependency of gnome-settings-daemon. > > There is also a canidate for asking to maintain the ibus packages, > that has not yet been contacted, but which already maintains several > related packages on AUR: > https://aur.archlinux.org/packages.php?K=yangtsesu&SeB=m > > If you think that his packages look ok, my plan is to contact > yangtsesu and ask if he wants to maintain the ibus packages in > [community] (and thus becoming a TU). > > If you know of other canidates that have a comparable selection of > relevant AUR packages, please let us know who they are. > > Please correct me if any of the above is incorrect or let us know if > you have additional information. > > Sounds like a plan? > > > -- > Cordially, > Alexander Rødseth > Arch Linux Trusted User > (xyproto on IRC, trontonic on AUR)
Re: [aur-general] ibus orphans in [community]
On Wed, Oct 17, 2012 at 12:20 AM, Felix Yan wrote: > Hi, > > Thanks for your attention to CJK input methods. > > FWIK yangtsesu is currently a fcitx user and packager of openSUSE [1]. > His packages are okay and updated regularly, but I'm afraid he doesn't > have enough time to maintain all ibus stuff too. Oh a BIG sorry that yangtsesu and margueritesu are not the same person and I've mistaken them for long, and thus the information is wrong :( Felix Yan Twitter: @felixonmars Wiki: http://felixc.at
Re: [aur-general] ibus orphans in [community]
Hi, Thanks for your attention to CJK input methods. FWIK yangtsesu is currently a fcitx user and packager of openSUSE [1]. His packages are okay and updated regularly, but I'm afraid he doesn't have enough time to maintain all ibus stuff too. Besides, I would like to maintain fcitx stuff as I am an active user and current maintainer of some other fcitx-related popular packages in AUR [2], and a Chinese native speaker too. I posted an e-mail [3] to look for sponsor August this year, and jsteel contacted me and told me lots of useful stuff. I realized I'm not ready at that time as I had still several obvious problems in my AUR packages. But I would like to apply again now if applicable. You may refer to the fcitx packaging status page [4], as mentioned in my previous mail [3] I am currently maintaining some popular fcitx packages in the [archlinuxcn] community repo to help CJK users, but it would be obviously much better if they could be in [community] :) Sorry, as I am a fcitx user and wishing to maintain fcitx packages, I can't help with the ibus stuff. Just a FYI: gnome-settings-daemon will depends on ibus and start ibus-daemon automatically in the coming 3.6 series, but a user will still have an option to choose fcitx by setting related env params such as GTK_IM_MODULE to fcitx. There should be a clean way to do this though I didn't find one yet :( Thanks. [1] http://fcitx-im.org/index.php?title=User:Marguerite_Su [2] https://aur.archlinux.org/packages.php?SeB=m&K=felixonmars [3] http://mailman.archlinux.org/pipermail/aur-general/2012-August/020104.html [4] http://fcitx-im.org/wiki/Distribution_Package_Status Felix Yan Twitter: @felixonmars Wiki: http://felixc.at
Re: [aur-general] python-foo and python2-foo - should they conflict?
On 16 October 2012 16:48, Oon-Ee Ng wrote: > python-foo and python2-foo - should they conflict? Absolutely not. At least, ideally. I may work with both Python versions and in that case will need libraries for each. Shared files have been a problem, and so far the (painful) route is to split them into a -common package (since upstream does not care to handle such inconveniences). See pyqt for an example. -- GPG/PGP ID: C0711BF1
[aur-general] ibus orphans in [community]
Hello, ibus is used for keyboard input for a few major non-English languages. Several of the ibus packages has been unmaintained for a while now: https://www.archlinux.org/packages/?sort=&repo=Community&q=ibus&maintainer=orphan For instance, ibus-sunpinyin, was last updated almost a year ago (2011-10-02). These ibus-packages have survived at least one package-cleanup, being neither adopted nor moved. While there is interest amongst the trusted users to maintain these, none of the trusted users are currently using ibus. After visiting #archlinux-cn, a couple of friendly people expressed interest in maintaining the ibus packages, but they had only few packages on AUR to show for. I also learned that mostly, fcitx (currently in [extra], is used instead of ibus). Dropping ibus could have been an option, but I also heard rumors that ibus will be a dependency of gnome-settings-daemon. There is also a canidate for asking to maintain the ibus packages, that has not yet been contacted, but which already maintains several related packages on AUR: https://aur.archlinux.org/packages.php?K=yangtsesu&SeB=m If you think that his packages look ok, my plan is to contact yangtsesu and ask if he wants to maintain the ibus packages in [community] (and thus becoming a TU). If you know of other canidates that have a comparable selection of relevant AUR packages, please let us know who they are. Please correct me if any of the above is incorrect or let us know if you have additional information. Sounds like a plan? -- Cordially, Alexander Rødseth Arch Linux Trusted User (xyproto on IRC, trontonic on AUR)
Re: [aur-general] python-foo and python2-foo - should they conflict?
As mentioned in the Arch Packaging Standards [1]:
/usr/share/doc/{pkg}Application documentation
You should rename the documentation folder of your packages to
/usr/share/doc/$pkgname, so there would be not anymore conflict.
As for the use-case one, maybe a user would not USE them both, but he
may be using two other packages that depends the two at the same time
:)
[1] https://wiki.archlinux.org/index.php/Arch_Packaging_Standards
Felix Yan
Twitter: @felixonmars
Wiki: http://felixc.at
On Tue, Oct 16, 2012 at 4:48 PM, Oon-Ee Ng wrote:
> Was just trying out some python packages and I realized I can't have
> both the python and python2 variants installed at the same time for
> python-networkx.
>
> Of course, there's conflicts with the license files and perhaps
> documentation, but other than that I wonder whether there's a use-case
> for having both installed (I'm in an academic setting, and I use both
> python3 and python2).
>
> Should I simply custom-PKGBUILD such issues or does it make sense to
> have, for example:-
> 1. python-foo provides all files shared between python3 and python2 variants
> 2. python2-foo depends on python-foo
> ?
[aur-general] python-foo and python2-foo - should they conflict?
Was just trying out some python packages and I realized I can't have both the python and python2 variants installed at the same time for python-networkx. Of course, there's conflicts with the license files and perhaps documentation, but other than that I wonder whether there's a use-case for having both installed (I'm in an academic setting, and I use both python3 and python2). Should I simply custom-PKGBUILD such issues or does it make sense to have, for example:- 1. python-foo provides all files shared between python3 and python2 variants 2. python2-foo depends on python-foo ?
[aur-general] Signoff report for [community-testing]
=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 0 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 4 packages missing signoffs * 4 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == Incomplete signoffs for [community] (4 total) == * clementine-1.1.0rc1-1 (i686) 0/2 signoffs * qtcreator-2.6.0beta-1 (i686) 0/2 signoffs * clementine-1.1.0rc1-1 (x86_64) 0/2 signoffs * qtcreator-2.6.0beta-1 (x86_64) 0/2 signoffs == All packages in [community-testing] for more than 14 days (4 total) == * qtcreator-2.6.0beta-1 (i686), since 2012-09-17 * qtcreator-2.6.0beta-1 (x86_64), since 2012-09-17 * clementine-1.1.0rc1-1 (i686), since 2012-09-28 * clementine-1.1.0rc1-1 (x86_64), since 2012-09-28 == Top five in signoffs in last 24 hours == 1. tpowa - 8 signoffs 2. stephane - 2 signoffs 3. thomas - 2 signoffs
