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] ht
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
> open
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 packa
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
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
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, thank
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
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-com
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
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 acc
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 op
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]
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 ot
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
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 s
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
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
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 (20
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
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 havin
=== 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
21 matches
Mail list logo
