Bug#732796:
Package: kbd Version: 1.15.5-1 Severity: wishlist Dear Maintainer, This package uses open(1). This usage is neither standard (in terms of LSB and POSIX) nor popular. The unpopularity can be seen as BusyBox implements openvt(1) only [1] while toybox has no plan for openvt(1) or open(1) [2]. Meanwhile, some other OS like OSX (and probably Haiku) use open(1) to provide desktop integration [3]. Similar functionality is provided by xdg-open(1) now on Linux. Some people, including I, believe that giving open(1) to xdg stuff is probably a good idea [4][5]. The very first step would be discontinue open(1) that is symbol linked to openvt(1). In other words, it is to remove open(1) from this package. 1. http://www.busybox.net/downloads/BusyBox.html 2. http://www.landley.net/toybox/status.html 3. https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/open.1.html 4. http://lists.freedesktop.org/archives/xdg/2013-December/012936.html 5. http://lists.freedesktop.org/archives/xdg/2013-December/012969.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729203: Tired of Libav virus
Libav is an annoying virus. On one hand, it pretends itself to be FFmpeg; maybe this is due to the fact that many software don't bother to port. On the other hand, it tries very hard to discredit FFmpeg and doesn't bother to be compatible with new FFmpeg development. ( The converse is not true. ) The end result is that breakage occurs here and there, users are confused and ended up compiling FFmpeg manually. In case Debian insists on weird choice, interested people may instead try getting FFmpeg reappear in Ubuntu. I've filed a bug here: https://bugs.launchpad.net/ubuntu/+source/libav/+bug/1263278 Ubuntu is arguably the biggest contributor of the spreading of Libav virus. Innocent, uninformed Ubuntu users just get confused: http://stackoverflow.com/questions/12651816/libswresample-in-recent-ubuntu-version http://stackoverflow.com/questions/9477115/who-can-tell-me-the-difference-and-relation-between-ffmpeg-libav-and-avconv https://github.com/hrydgard/ppsspp/issues/2322 They need our help. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662731: ITA: hwinfo -- Hardware identification system
Any updates on this item? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693457: unblock: ibus-table/1.4.99.20121012-1
On Wed, Mar 13, 2013 at 4:39 AM, Jonathan Wiltshire j...@debian.org wrote: Closing. There has been no helpful response from the requestor or maintainers since November, despite intrigeri's prompts. I can find no bug that would be justification for an unblock, just this vague mention of the Cangjie Chinese input method being unusable. The proposed debian/changelog merely has new upstream release, twice. OK, I'd say you are uninformed about the state of ibus-table. If you ship the version in testing, you'd continue to have old bugs like: https://code.google.com/p/ibus/issues/detail?id=1188 https://code.google.com/p/ibus/issues/detail?id=861 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700076: [Pkg-ime-devel] Bug#700076: ibus: non-functional, setup breaks
On Wed, Feb 13, 2013 at 3:26 PM, Norbert Preining prein...@logic.at wrote: I would propose to re-upload 1.4 with a new epoch to unstable, to unbreak current sitatuon. I prefer Let IBus be IBus. Debian is not a one-stop shop like some other distros. I guess we don't have to hide something from the users. Or do you see any chance that ibus upstream fixes this? No, that issue is not new; bothered some users in Fedora 17 already. I've contacted origin developer of IBus in private mail but no related action take place. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700076: [Pkg-ime-devel] Bug#700076: ibus: non-functional, setup breaks
Hi, all. FYI, manually compiled IBus 1.5.0 works fine on my Ubuntu 12.10 box (with MATE as DE); I have used that box for many days. For errors like ERROR:root:Could not find any typelib for IBus Have you installed GI stuff properly? Have you got gir1.2-ibus-1.0 installed? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700076: [Pkg-ime-devel] Bug#700076: ibus: non-functional, setup breaks
On Wed, Feb 13, 2013 at 1:46 PM, Norbert Preining prein...@logic.at wrote: Is this really gone? (BTW, even if they remove it, I would consider it a bug that should be reintroduced upstream ) Yes. http://code.google.com/p/ibus/issues/detail?id=1568 But GNOME blog says such feature is reintroduced in GNOME 3.7.4, not verified by any means. http://blogs.gnome.org/mclasen/2013/01/14/input-sources-in-gnome-3-7-4-continued/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700076: [Pkg-ime-devel] Bug#700076: ibus: non-functional, setup breaks
On Wed, Feb 13, 2013 at 3:11 PM, Aron Xu happyaron...@gmail.com wrote: The option has been hidden in ibus-setup, but I'm worry that whether ibus 1.5 itself has removed the capability. I believe that it is removed since changing dconf key has no effect either. For IBus (1.4.99+) + GNOME combo, it really depend on which IBus UI is being used. For 3.4 in particular, it means IBus built-in UI or ibsu-gjs, they don't have capacity of local IM state AFAIK. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700076: [Pkg-ime-devel] Bug#700076: Bug#700076: ibus: non-functional, setup breaks
You have latest ibus and ibus-table upstream release in unstable now. I just want to remind you guys that other components of IBus may need update also. For example latest upstream release of ibus-anthy is 1.5.0 while you have 1.2.x something. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700076: [Pkg-ime-devel] Bug#700076: Bug#700076: Bug#700076: ibus: non-functional, setup breaks
As I checked the debian/rules file and the errors given, it should be clear that the IBus itself is not built correctly. You build flags looks reasonable but they are different from Arch's and Fedora's. (Arch and Fedora have been using IBus 1.5 for a while.) You probably hit some build system quirk? You probably also need to update dconf somehow as a post install action. (Since make install from source code would trigger such action.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699474: RFS: b43-fwcutter/1:017-1 [ITA]
On Fri, Feb 1, 2013 at 5:25 AM, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de wrote: No, unfortunately the package is not ok yet. When I install the package b43-fwcutter, it will prompt the debconf question in Spanish. Really? Where to check the source package content? Also, after installing b43-fwcutter, nothing further happens. I have to install the firmware-b43-debs manually which is very confusing. Ideally, the package b43-fwcutter should detect the hardware and prompt for the installation of the proper package or at least depend on them. b43-fwcutter itself is just a firmware cutter as its name suggests. http://linuxwireless.org/en/users/Drivers/b43#Install_b43-fwcutter firmware-b43-installer runs helper script of firmware installation. I think such arrangement is OK and existed for some time already. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682427: firmware-b43-installer incorrectly reports device with PCI id, 14e4:4331 as unsupported and aborts
Ping? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694775: Add mate-power-manager to powerbtn.sh
Package: acpid Version: 1:2.0.17-1 Since the current list doesn't contain mate-power-manager, MATE users (including me) will get a immediately shut down after pressing power button. See also: https://github.com/mate-desktop/mate-power-manager/issues/23 powerbtn.diff Description: Binary data
Bug#658783: MATE Desktop Environment in Debian
I strongly support inclusion of MATE. Why not packaging GNOME 2 directly? GNOME 2 and GNOME 3 are not parallel installable. And MATE renamed binaries. Why not GNOME Fallback? It is dropped in GNOME 3.8 It is indeed different from GNOME 2, though non-heavy users may not notice the difference. It is not well maintained and have several technical issues (so GNOME devs decided to drop it). Why not GNOME Shell with extensions? I'm aware of the fact that GNOME dev promised to provide a set extensions that resemble GNOME 2 experience. However: 1. 3D hardware issue still exists. 2. Change in applications are visible anyway, e.g., Nautilus 3.6+. 3. We haven't see the end result Why not contributing GNOME project? I guess many people tried. However: 1. GNOME devs' vision is strongly towards dummy proof tablet rather a sane, enterprise / scientific suitable desktop. Check their design mockups for inspiration: https://live.gnome.org/Design/Apps Nautilus 3.6, again, is a good real world example. https://live.gnome.org/Nautilus/Roadmap/3.6 Some features that some users use heavily looks annoying in the eye of GNOME devs; GNOME devs urge to remove these features. I'm pretty sure same thing happened / will happen in other GNOME applications. For example, Empathy 3.6 removed compact mode of contact list. https://bugzilla.gnome.org/show_bug.cgi?id=687351 2. GNOME becomes more and more *proprietary* these days. proprietary -- one that possesses, owns, or holds exclusive right to something (Merriam-Webster) Once in IRC, I heard that you don't use GDM with GNOME 3.6, the screen won't lock. And I'm pretty sure GNOME would definitely depends on systemd at some point. Then what for Debian? Also for input sources white listing debate in recent days, you can see how much control GNOME devs want over their upstreams (IBus project) and downstream (distributions). The white lists even break Fedora's input experience but GNOME devs don't feel bad. http://git.gnome.org/browse/gnome-control-center/tree/panels/region/gnome-region-panel-input.c#n67 http://git.gnome.org/browse/gnome-shell/tree/js/ui/status/keyboard.js#n188 https://mail.gnome.org/archives/desktop-devel-list/2012-November/msg00091.html https://mail.gnome.org/archives/desktop-devel-list/2012-November/msg00123.html https://bugzilla.gnome.org/show_bug.cgi?id=688914 https://bugzilla.gnome.org/show_bug.cgi?id=688916 https://bugzilla.redhat.com/show_bug.cgi?id=880007 Third-party developers and theme designer are also unhappy with GNOME project probably. http://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/ Why about MATE's 'stupid duplication'? I guess those who know much about these issues and care MATE should try contributing MATE. In a distribution level, I don't think such technical ugliness, if any, is big concern. Many other package may also use ugly techniques in source code, but who cares? As FOSS world allows people with different ideas and visions to fork, I really hope that Debian can help MATE reaching a wider audience, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591459: GNOME's ibus integration issue
On Sun, Nov 25, 2012 at 1:18 AM, Aron Xu a...@debian.org wrote: We are going to release Wheezy with IBus 1.4.x + GNOME 3.4.x, which is working. GNOME 3.6 has made IBus not useable when the integration is enabled, details are in GNOME's desktop-devel-list. ibus-mozc isn't in its white list so there is no possibility to make it behave normally in current context. To be accurate, ibus-mozc is in the white list of engine. http://git.gnome.org/browse/gnome-control-center/tree/panels/region/gnome-region-panel-input.c#n88 And as I just tried on Fedora 18 (Alpha with entire update). Mozc can appear in Input Source list. However, you can neither enter its setup nor have any embedded property (context) menu. In other word, handicapped experience. I cannot hate more about the idea of white listing. I have filed a bug against gnome-settings-daemon in Debian, although gnome-control-center needs to be configured with --disable-ibus either. Ref: http://bugs.debian.org/694301 Best thing a distributor can do if you don't want to be controlled by GNOME. https://bugzilla.gnome.org/show_bug.cgi?id=688914#c10 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694301: gnome-settings-daemon: ibus integration makes ibus useless
IBus integration in GNOME = 3.6.0 is filtering input method engines and properties, which makes most of the commonly used engines being filtered out, or being completely broken because their configuration menu items (properties) are almost all being filtered out. Although engines that are not in its white list can be exposed in gnome-control-center by manually change a gsettings value, those engines cannot be used because the existence of white list filtering. Though the description here is not very accurate. I still agree this is a grave bug. The items in white list are selected by GNOME developers that they think are most sophisticated based on their opinion that inputting using IME is just as easy as input Spanish using an US keyboard which only needs one or very few options, but the actual situation is in the contrary. It's a very complicated thing just like there are different editors including vim, emacs, gedit and even more, and those editors can't be limited by a DE. Maintaining a patch to that white list to enable commonly used engines and properties is not feasible for a downstream project, at least pkg-ime does not have any plan to support such a move, so the best option is to drop IBus integration in GNOME by configuring gnome-settings-daemon and gnome-control-center with --disable-ibus, which preserves the original behavior. Agree, we should never follow the problematic path. There has been lots of complains in GNOME's desktop-devel-list from Chinese users and developers, and there isn't real progress on figuring such collision out right away. Currently Ubuntu has decided to go with --disable-ibus for Raring with GNOME 3.6, and OpenSuSE does not have the plan to support such a feature in foreseeable time. Only Fedora has been officially being the test ground of GNOME so they have the integration. I see no reason to enable it in Debian, as we are not yet another test ground. In case some people want keep up with GNOME. Please help correcting GNOME's decision. The bugzilla discussion is probably more on topic than that ones of d-d-l. https://bugzilla.gnome.org/show_bug.cgi?id=688914 https://bugzilla.gnome.org/show_bug.cgi?id=688916 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591459: [Pkg-ime-devel] Bug#591459: Could not activate Ibus and Mozc from experimental.
On Sat, Nov 24, 2012 at 5:44 AM, Osamu Aoki os...@debian.org wrote: Anyway, GNOME 3.6 is not stable enough platform yet. It needs to stabilize itself before we package for Debian unstable (at least around IME related things.) We are shipping GNOME 3.4 so ibus 1.4.? is good choice. I'm not aware of any concrete stability issue. However, some methods they are currently using are really problematic. https://bugzilla.gnome.org/show_bug.cgi?id=688914 https://bugzilla.gnome.org/show_bug.cgi?id=688916 https://mail.gnome.org/archives/desktop-devel-list/2012-November/msg00091.html https://mail.gnome.org/archives/desktop-devel-list/2012-November/msg00123.html I did not initiate this experimental upload (Asias He and Aron Xu did). I think we should keep us out of these new GNOME for unstable. Once we see the next RHEL release with newer GNOME 3.8, we will be OK. Otherwise, GNOME development releases are really alpha stage quality as a whole distribution. Rumors said RHEL7 is based Fedora 18 and it is clear that Fedora will use GNOME 3.6. But GNOME 3.6 integration is very problematic as I mentioned above. I guess we better correct what GNOME is doing wrong whether than hopelessly waiting. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692424: [Pkg-ime-devel] Bug#692424: Bug#692424: ibus: Merge fixes from Ubuntu
On Sun, Nov 11, 2012 at 6:34 AM, Aron Xu happyaron...@gmail.com wrote: Integration isn't always a good thing, and it is good only when people have done it correctly. Ubuntu has not used the whole stack of GNOME for several cycles, and it shouldn't be an excuses that GNOME got the keyboard indicator work so the experience of input method users can be forgotten. Not got your point. I know, I'm suggesting not to use a pre-release version of ibus as Ubuntu has suffered lots of troubles by shipping versions of such kind, especially you'll have to invest more manpower to pick upstream fixes and make SRUs from time to time, even some of the difficult ones are left there because it's not possible to get them fixed through SRU. I don't think pre-release version is particularly bad. Released versions can also be buggy. IBus, in general, is just not sophisticated enough to make any upgrade uninteresting. In old days (2008-2010), some IBus people maintain a PPA to mitigate the software outdated issue. IBus upstream people most use Fedora now. Fedora ships 1.4.99 versions since Fedora 17 and upgrade from time to time. I believe that they don't feel bad for Ubuntu's sticking on broken versions. No, you are not correct by saying ibus is the only one supported by Ubuntu, actually it needs to be changed to supported by Canonical. This does not imply others aren't supported, even not by the community. Or you are telling me most part of Ubuntu is just hell, I don't believe this is what you mean. I'm not pedantic on the terminology. However, what's the real meaning of supported or included in main, leaving bug reports unanswered since 2009? I'm trying to improve IBus's costumer service since I joined the IBus project. Even though many problems belong to upstream, what about the indicator icon issue? We spent 1 year to come up with a problematic sleep 10 workaround? Don't forget that IBus's default embedded menu is still blocked by IBus indicator and people have to enable language panel manually. I wonder if Ubuntu people is not competent enough to maintain a really working IBus indicator, why don't they just whitelist IBus's GtkStatusIcon and everything would just be fine? End users don't care the real reason behind, they just switch to another IMF using PPA or source compilation and laugh at Ubuntu and/or IBus. Right, but you may not want to add all available engines to the list, or there design is totally non-sense. But in deed, all the engines are useful to someone, and they need to be enlisted in some way, not this way IMHO. There is already a must for some users to run gsettings command to expose all the engines, but that's not desired for good UX. Actually the Chinese list is quite short. The number of Chinese input methods out there is really crazy. I left Windows world so I forgot most of them. Anyway, Chinese users should be the most unhappy user group of IBus. Even if we spent most effort on it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692424: [Pkg-ime-devel] Bug#692424: Bug#692424: ibus: Merge fixes from Ubuntu
On Sat, Nov 10, 2012 at 8:20 PM, Aron Xu happyaron...@gmail.com wrote: GNOME 3.6 can live with older version of ibus if you don't enable the compile time integration, and currently the integration makes input experience gets downgraded heavily, it's highly recommended not to enable it at least for this cycle. In theory you're right. In practice I doubt it. I guess Ubuntu 12.10 is indeed GNOME 3.6 without IBus integration. However, IBus 1.4 doesn't work in this environment; no tray icon at all. I guess it's because GNOME Shell in 3.6 block old school GtkStatusIcon. (GTK3 UI of IBus is only available in 1.4.99) ( I end up use GNOME Fallback to see the tray icon, SO SAD. Fallback will be dropped in GNOME 3.8) Reasons behind are the integration hides most input method engines in ibus that GNOME developers think useless, they believe that only a small number of high quality engines will be able to handle all the users' needs, while most of them have never tried a input method, not mentioning how users depend on the existence of many many different engines that they never heard about. Actually I believe that a desktop system should offer input functionality for all languages regardless of UI language; that's the most friendly to users. We cannot archive this before because IMF and XKB covers different language groups. Even modern IMF can handle XKB, XKB using people don't want to switch to IMF. My claim is from a thread in kde-devel. http://lists.kde.org/?l=kde-develm=134081368017885w=2 So I agree with the high level idea of GNOME integration, but the implementation detail has many stuff to be improved. Another reason is when you have the integration enabled and ibus-daemon available, any other input method framework will not work because gnome-settings-daemon will continusly reset the input method related variables and try to start ibus. In this case nether the alternative input method framework nor ibus can behave normally. I think this is the desirable behaviour. This eliminates the need of manual of distribution specific configuration before one can really use IBus. g-s-d used to set environmental variables blindly. Then Weng made a already merged patch that check whether ibus-daemon is in PATH. I guess we can go a little bit further that g-s-d should check a configuration key before it check whether ibus-daemon is in PATH. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690605: [Pkg-ime-devel] Bug#690605: Bug#690605: Bug#690605: Bug#690605: ibus-xkbc: not installed on with desktop metapackage
As I tried ibus-xkbc recently on (I'm sorry) Ubuntu 12.04 and checked its upstream repo in https://github.com/sun-im/ibus-xkbc It seems like ibus-xkbc is not in good state, there is no commits for about 2 years and it may not work well with newer systems, say Wheezy. For example, its setup script explicitly call python2.6, but newer system would have Python 2.7. https://github.com/sun-im/ibus-xkbc/blob/master/setup/ibus-setup-xkbc.in#L25 There are no bugs reported for the issue yet. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692423: [Pkg-ime-devel] Bug#692423: ibus-anthy: Missing python dependencies
If you are trying to package ibus-anthy for Raring, please consider ibus-anthy 1.4.99 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692423: [Pkg-ime-devel] Bug#692423: ibus-anthy: Missing python dependencies
On Mon, Nov 5, 2012 at 9:03 PM, Jeremy Bicha jbi...@ubuntu.com wrote: Yes, we'll be switching to the new ibus in Raring soon but we need to port our indicator patch to the new ibus first. We also have a bit more work to do with gnome-settings-daemon and gnome-control-center 3.6 first. For indicator patch, I hope you can make it upstream this time There is an old issue already: https://code.google.com/p/ibus/issues/detail?id=780 . Old g-s-d and g-c-c doesn't affect IBus only. It seems like natural scrolling is added in 3.6 which is an important feature for Ubuntu users on MacBook. Your package dependencies showed that you have IBus 1.4.99 installed already. So I'd add a reminder here, in 1.4.99, ibus Python module considered deprecated, engines should port to GObject Introspection. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691396: [Pkg-ime-devel] Bug#691396: ibus-anthy: Engine fails to start
On 10/25/12 1:18 AM, Marcus Lundblad wrote: Trying to use ibus-anthy with gnome-shell 3.6.1 in experimental. I add a Japanese keyboard layout using anthy. Things don't work. After some digging around, I found that the file /usr/share/ibus-anthy/engine/_config.py contains invalid paths. These paths (PKGDATADIR, LIBEXECDIR, and LOCALEDIR) starts with /usr/share Thus, python won't find the modules defined by the engine. Manually changing these paths to have a prefix of /usr/ actually makes it work. I can now type in text with the Japanese input method (and also the input method options appears in gnome-shell's keyboard menu in the top bar). Did you notice similar issue in the upstream tracker? http://code.google.com/p/ibus/issues/detail?id=1513 I guess the upstream developer assume that you are using /usr I think non /usr prefix should be supported so I kept the upstream issue open. However, this issue is not a high priority issue at least for me personally. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691071: [Pkg-ime-devel] Bug#691071: RC fixed in unstable for #691071
I didn't follow previous bugs. However, have you noticed IBus 1.4.2? It fixed some trivial bugs from 1.4.1: https://github.com/ibus/ibus/commits/1.4.y Released tarball is here: http://code.google.com/p/ibus/downloads/list -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691080: RFP: tegaki-zinnia-traditional-chinese -- Traditional Chinese handwriting model for Zinnia
Package: wnpp Severity: wishlist * Package name: tegaki-zinnia-traditional-chinese Version : 0.3 * URL : http://tegaki.org/ * License : LGPL 2.1 Description : Traditional Chinese handwriting model for Zinnia. The upstream offer Japanese, Simplified Chinese and Traditional Chinese models simultaneously. Our repository, however, offers tegaki-zinnia-japanese and tegaki-zinnia-simplified-chinese for long but no tegaki-zinnia-traditional-chinese. On the other hand, even NetBSD seems to have tegaki-zinnia-traditional-chinese. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690605: [Pkg-ime-devel] Bug#690605: Bug#690605: Bug#690605: ibus-xkbc: not installed on with desktop metapackage
(Sorry, Aron, forgot reply to all) On Sat, Oct 20, 2012 at 2:10 AM, Aron Xu happyaron...@gmail.com wrote: The situation here isn't that optimistic, because if one has enabled IBus integration at build time, then whenever a ibus-daemon exist no other input method can work because gnome-settings-daemon will force to use ibus by monitoring and resetting various variables. They are integrating configuration interface of IBus into gnome-control-center, but that's another thing for us to think about. Are you thinking of multi-user environment where individual users can select different IMFs? Otherwise I don't think removing IBus is a burden, people like other IMF tends to do it anyway. As yesterday the discussion about making systemd a hard dependency of some important GNOME components, how to deal with the problem for Debian and Ubuntu remains a question. But we can port language-selector to im-config by a easy patch, and the reason for not porting it for such a long time is because of the lack of hands. Ubuntu developers have thought about using GNOME's input method configuration UI, but it's far more harder for them to stick with current language-selector. The original author of language-selector left the company for more than a year ago, and that piece of software is just being maintained to work, no new plans so far. Ubuntu is focusing on Unity, which is largely based GNOME. So they cannot tolerate GNOME regression such as Nautilus propagates to Unity, you know, they ship earlier version of Nautilus in 12.10. For Debian, let GNOME be GNOME. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690605: [Pkg-ime-devel] Bug#690605: Bug#690605: Bug#690605: ibus-xkbc: not installed on with desktop metapackage
On Thu, Oct 18, 2012 at 9:27 AM, Osamu Aoki os...@debian.org wrote: I am a bit neutral to this. I do not think we need to be confrontational to upstream (GNOME3 mainly by Fedora=RH). Fedora is their test ground with little regards to the stability. They have reason to do so. If we want such thing as stability, we need to be careful what part to follow and how fast we follow. RH provides stability with their commercial distribution still with GNOME2. I think RH is still providing customer with security updates with source on them. RH and Debian have different positions on how software get integrated. RH needs one good working solution for upcoming their commercial distribution by testing them on FEDORA. Debian is community thus needs to make as much reasonable software to live together. This is our task and we should not complain too much to upstream RH on their single combination strategy. True. GNOME people are integrating IM into GNOME shell. I do not know how to handle this new situation yet. What I know now is Gnome-shell is reconfuarable by external javascript code. Even if GNOME people tightly integrate ibus into gnome-shell, it does not theoretically prevent fcitx to replace ibus as long as someone can write codes to replace functionalities as a hot patch. Considering next Debian release comes after several GNOME3 releases, situation will be easier to handle than how it looks now. Fcitx people already have their GNOME extension. https://extensions.gnome.org/extension/261/kimpanel/ This extension is necessary even before 3.6 since otherwise you cannot use IM in Shell integrated chat, say. In contract, what GNOME 3.6 really breaks is IBus. Because they changed the way of IBus usage and the new way is not good enough yet. For example, they enforce global input source state. They offer no switching shortcut by default. They offer no OSD like ibus-gjs. Fedora users are going to enjoy all these once they have their long awaited Fedora 18. To be fair, the issues I mentioned is known to GNOME people already, having good chance to be fixed in 3.8. (Global input source state is still being discussed. ) The challenge is GNOME3 may not be as compatible as other desktop environment and it requires a lot of GObject and introspection internal things. GNOME3 documentation for developer is not well organized yet. It is not so easy to learn ... No API documentation for Vala or Python bindings in packaged form. Just C one is available as package. http://people.debian.org/~osamu/fun2prog.html#_vala_3 http://people.debian.org/~osamu/fun2prog.html#_pygobject With the speed I am learning, I am not sure if I can propose good path forward ... I'm not a fan of GNOME's development stack. But GObject Introspection gives us free language bindings, say Python 3 bindings. How many manually maintained Python libraries don't support Python 3 yet? Vala or Python API should be direct mapping of C API, yes, a bit awkward. IBus follows GNOME technology closely which may not be appealing for KDE users, say. But making a choice between GTK+ and Qt is just natural. Fcitx seems to be more compatible is more of a historical heritage rather than a design advantage I guess. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661065: What should I do next?
I've done the not-so-hard package upgrading. You may find the source package here: https://code.launchpad.net/~damage3025/ubuntu/quantal/rar/v420 What should I do next? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690605: [Pkg-ime-devel] Bug#690605: Bug#690605: ibus-xkbc: not installed on with desktop metapackage
On Tue, Oct 16, 2012 at 12:51 PM, Aron Xu happyaron...@gmail.com wrote: I see your point, and I agree it's not intuitive. But unfortunately we can't add ibus to Recommends for all desktop tasks, and even if any GNOME package do that then it is a bug. It's a long story to tell the whole thing, but in short it is not an ideal solution because some (significant amount of) users have other preference on input method framework other than ibus. It could be added to ibus package so that users of ibus get this feature by default. It's up to you. Why we integrate Vi when user base of Emacs, Nano is also huge? Provide a default and let the tweakers do whatever they want. There were some discussions about how the input method integration should be implemented in GNOME, but the outcome was that GNOME designers and developers disagreed to accept the advices from input method developers and took an approach that has led us to an embarrassing situation. Better to summarize as the developer and fans of one IMF try to prevent GNOME from integrating another IMF. If you'd like to choose which input method framework to use, try im-config. After you have installed the package, run the command im-config from a terminal and then follow the guide. Ubuntu has language-selector, a tool said to be deprecated by GNOME's new control center component, but the replace won't happen in the upcoming 12.10 at least. The input method framework selection part of language-selector is a frontend of im-switch, which has been deprecated by im-config in Debian. If the tool won't get out of 13.04, I'll try to push patch to migrate it from im-switch to im-config. We won't have that tool because it manages language packs and fonts as well, which are pointless for Debian. That's the solution favored by some people. They know im-config on Debian, im-switch on Ubuntu, im-chooser on Fedora, System/Environment/Language/INPUT_METHOD on openSUSE... They also know input method related environmental variables (apply to all distribution). Happy tweaking! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690605: [Pkg-ime-devel] Bug#690605: Bug#690605: ibus-xkbc: not installed on with desktop metapackage
On Tue, Oct 16, 2012 at 7:33 PM, Aron Xu happyaron...@gmail.com wrote: From a distribution's perspective, we should preserve the possibility of choosing their favorites to users, but not always given them a default and tell them use it or go away. Your claim on those editors are not related to this issue anyhow. aptitude purge or apt-get purge if someone don't like the default provided IMF. Adding ibus-xkbc to Recommends of ibus package will solve this problem for ibus users, even they are not your so-called tweakers, and won't cause trouble for users of other input method frameworks. If you see there is any flaw in this design please speak up then. Well, you may end up Recommends all available engines of IBus? Who knows which engine provides what? Not sure. GNOME developers care about their integration and does not accept opinions from other users and developers. Your claim shows that you are an ibus fan who tries to prevent other GNOME users from using whatever others they want, especially I help working on ibus as well as fcitx in Debian and Ubuntu. If you are in doubt of my last sentence, read on. I have never been a fan of IBus. I know its flaws. I'm a fan works-out-of-the-box. GNOME 3.6's integration is not good enough currently for sure. But it eliminates the need to rely on distribution specific tool of IMF Enabling/Switching and/or automatic installation of input methods based on particular language, this is the point. Fcitx is still usable on GNOME 3.6 if you want. http://fcitx-im.org/wiki/Note_for_GNOME_Later_than_3.6 I think the procedure is no harder than replacing existing IBus with Fcitx on other environments. Actually Ubuntu uses almost whatever provided in Debian on input method perspective. They know there are im-config in Debian, and the migration was blocked by no one is changing the code, and this is the only reason of not moving away from im-switch. It's not a matter of choice among distributions, just a man power problem. I can't say that I know in and out about the whole thing of input method in Debian/Ubuntu, but I'm sure that I'm one of the most active developer who keeps ibus and fcitx running on both distribution, it's quite unfair to classify me as a fanboy of something, ;-) Thank you for contributions. Using switching tools in various distributions are already much better than changing environmental variables directly. But concept trickiness of IMF switching and the unintuitive nature of these tools make me believe that a working default is quite important. Ubuntu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690261: RFP: ibus-libpinyin -- Intelligent Pinyin engine based on libpinyin for IBus
Package: wnpp Severity: wishlist Package name : ibus-libpinyin Version : 1.4.92 Upstream Author : Peng Wu alexep...@gmail.com URL : https://github.com/libpinyin/ibus-libpinyin License : GPL2 Description : Its UI is similar to ibus-pinyin, but its internal language model is more advanced. Smooth pinyin inputting experience (powered by advanced language model) is common expectation of Mainland China desktop users now. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680047: RFP: librime -- librime is RIME's backend.
Package: wnpp Severity: wishlist RIME, or Rime Input Method Engine, is an excellent Chinese Input Method. URL: http://code.google.com/p/rimeime/ License: GNU GPL v3 Notes: You may refer to http://aur.archlinux.org/packages/li/librime/PKGBUILD -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680048: RFP: ibus-rime -- ibus-rime is RIME's IBus frontend.
Package: wnpp Severity: wishlist RIME, or Rime Input Method Engine, is an excellent Chinese Input Method. URL: http://code.google.com/p/rimeime/ License: GNU GPL v3 Notes: You may refer to http://aur.archlinux.org/packages/ib/ibus-rime/PKGBUILD -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678422: [Pkg-ime-devel] Bug#678422: ibus depens on gnome-icon-theme
I'm sorry Debian ninjas. I first noted the problem on Kubuntu. I don't have a working Debian system currently. I just checked http://packages.debian.org/sid/ibus and concluded that same problem could (in theory) also happen on Debian. You know, Debian is the ultimate upstream of Ubuntu. I also add ibus-devel to CC. I'd like know whether upstream developers of ibus have idea of Debian packaging of ibus. Regards, Ma Xiaojun -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678422: [Pkg-ime-devel] Bug#678422: ibus depens on gnome-icon-theme
I'm sorry. CCing ibus-devel didn't work. Let's CC main ibus upstream developer. This is a Debian bug regarding ibus packaging. ibus ui needs certain icons that are not yet declared as dependency. However, different themes of icons are all OK for ibus. So the dependency declaration is a bit hard. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678422: ibus depens on gnome-icon-theme
Package: ibus Version: 1.4.1-6 ibus-ui (included in ibus package) need certain GNOME/GTK icons to start up. https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/854333 But it is not treated as dependency currently. http://packages.debian.org/sid/ibus So users may encounter strange error in non-GNOME/GTK environments. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674980: Section 13.5 (About Wine) is Misleading
Package: debian-handbook Version: 6.0+20120509 Severity: wishlist The way of using wine mentioned by section 13.5 is strongly against wine project's official recommendation. http://wiki.winehq.org/FAQ#head-878d4f6d1d0654ac8c0806990af095a4a4cafa13 In general, wine project recommend users to install any Windows applications using wine itself. On the other hand, running Windows applications on a existing Windows partition is not supported and is likely to damage the Windows installation. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
