[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
[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] 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=Communityq=ibusmaintainer=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=yangtsesuSeB=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?
On 16 October 2012 16:48, Oon-Ee Ng ngoonee.t...@gmail.com 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
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=mK=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] ibus orphans in [community]
On Wed, Oct 17, 2012 at 12:20 AM, Felix Yan felixonm...@gmail.com 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, 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=Communityq=ibusmaintainer=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=yangtsesuSeB=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 cyberdup...@gmail.com 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=Communityq=ibusmaintainer=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=yangtsesuSeB=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]
On Tue, Oct 16, 2012 at 12:55 PM, Allen Li cyberdup...@gmail.com 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=Communityq=ibusmaintainer=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=yangtsesuSeB=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 Tue, Oct 16, 2012 at 1:30 PM, Rashif Ray Rahman sc...@archlinux.org wrote: On 17 October 2012 00:55, Allen Li cyberdup...@gmail.com 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=Communityq=ibusmaintainer=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=yangtsesuSeB=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 1:47 PM, Yichao Yu yyc1...@gmail.com wrote: On Tue, Oct 16, 2012 at 1:30 PM, Rashif Ray Rahman sc...@archlinux.org wrote: On 17 October 2012 00:55, Allen Li cyberdup...@gmail.com 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=Communityq=ibusmaintainer=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=yangtsesuSeB=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 17 October 2012 02:05, Yichao Yu yyc1...@gmail.com wrote: On Tue, Oct 16, 2012 at 1:47 PM, Yichao Yu yyc1...@gmail.com wrote: On Tue, Oct 16, 2012 at 1:30 PM, Rashif Ray Rahman sc...@archlinux.org wrote: On 17 October 2012 00:55, Allen Li cyberdup...@gmail.com 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=Communityq=ibusmaintainer=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=yangtsesuSeB=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.) Thanks, that makes things clearer. Either way it looks like we do need someone to take care of these things (who should also have an up-to-date knowledge about the stuff like what you have demonstrated). -- GPG/PGP ID: C0711BF1
[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] 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] 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] Packages depends on either python 2 or 3
On Wed, Oct 17, 2012 at 4:01 AM, Felix Yan felixonm...@gmail.com 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, Oct 16, 2012 at 9:08 PM, Masato Hashimoto cabezon.hashim...@gmail.com wrote: On Tue, 16 Oct 2012 12:55:39 -0400 Allen Li cyberdup...@gmail.com wrote: snip 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] python-foo and python2-foo - should they conflict?
On Tue, Oct 16, 2012 at 5:02 PM, Felix Yan felixonm...@gmail.com 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 =)
