April 2010 - i18n-bugs - Fedora Mailing-Lists

[Fedora-i18n-bugs] [Bug 583545] Enable building Kimpanel and make a subpackage for it

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=583545 Robin Lee <robinlee.sysu(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #408331|0 |1 is obsolete| | --- Comment #22 from Robin Lee <robinlee.sysu(a)gmail.com> 2010-04-22 12:43:32 EDT --- Created an attachment (id=408379) --> (https://bugzilla.redhat.com/attachment.cgi?id=408379) Enable building Kimpanel and make a subpackage for it fix directory ownership and requirement -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

14 years, 2 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 583545] Enable building Kimpanel and make a subpackage for it

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=583545 --- Comment #21 from Robin Lee <robinlee.sysu(a)gmail.com> 2010-04-22 10:13:10 EDT --- Created an attachment (id=408334) --> (https://bugzilla.redhat.com/attachment.cgi?id=408334) Plasma desktop script adding Kimpanel to panel automatically -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

14 years, 2 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 583545] Enable building Kimpanel and make a subpackage for it

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=583545 Robin Lee <robinlee.sysu(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #407609|0 |1 is obsolete| | --- Comment #20 from Robin Lee <robinlee.sysu(a)gmail.com> 2010-04-22 10:08:57 EDT --- Created an attachment (id=408331) --> (https://bugzilla.redhat.com/attachment.cgi?id=408331) Enable building Kimpanel and make a subpackage for it A new build. Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=2132394 In this build: 1. A plasma desktop script is added. Kimpanel will be added to the panel automatically after a new login when the package installed. And I wrote little JavaScript, so somebody may optimise the codes. 2. The subpackage is named 'plasma-applet-kimpanel' after the same convention of 'plasma-wallpaper-marble'. 3. 'panel.py' is moved to '%{_kde4_appsdir}/kimpanel/backend/ibus/'. And I had a test showing that the IBus backend will not work if this file is not executable. By the way, plasma desktop scripts may use two new directories: '%{_kde4_appsdir}/plasma-desktop/updates' and '%{_kde4_appsdir}/plasma-desktop/init'. So these directories should be added to the 'kdebase-workspace' package. Refer to: http://techbase.kde.org/KDE_System_Administration/PlasmaDesktopScripting -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

14 years, 2 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 575005] Review Request: zinnia-tomoe - Online hand recognition system with machine learning

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=575005 Liang Suilong <liangsuilong(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |liangsuilong(a)gmail.com --- Comment #42 from Liang Suilong <liangsuilong(a)gmail.com> 2010-04-22 10:01:51 EDT --- The data is not architecutre dependent. It should be endian dependent. If different architectures blog to the same endian, the package can share with another architectures. An x86_64 users does not want to install a package in order to keep compatibie if it is not recommended, because an extra package means it will take more spaces. I wrote a spec sample for zinnia-tomoe. It will be built independently for little-endian and big-endian. https://dl.dropbox.com/u/1352061/zinnia-tomoe/zinnia-tomoe-sample.spec And I modify the zinnia-tomoe-fixes-makefile.patch. The default installation path will switch to %{_datadir}. Here is koji result: http://koji.fedoraproject.org/koji/taskinfo?taskID=2132276 SPEC: https://dl.dropbox.com/u/1352061/zinnia-tomoe/zinnia-tomoe.spec SRPM: https://dl.dropbox.com/u/1352061/zinnia-tomoe/zinnia-tomoe-0.6.0.20080911... As we know, maintaining source codes is much more difficult to maintain spec files, especially for me, not an professional coder. For many packagers, they have no enough skill to modify the codes. So we can see the best way to modify the spec file under packaging guideline. If we put endian-dependent data to %{_libdir}, it will mean that quite many package should be requested to change their codes. Comparing to codes, it is an easy job to edit spec files. At last, in my opinion, Fedora should have a new guideline to teach packagers how to build a endian-dependent package. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

14 years, 2 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 584646] New: [abrt] crash in scim-bridge-0.4.16-4.fc13: Process /usr/bin/scim-bridge was killed by signal 11 (SIGSEGV)

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: [abrt] crash in scim-bridge-0.4.16-4.fc13: Process /usr/bin/scim-bridge was killed by signal 11 (SIGSEGV) https://bugzilla.redhat.com/show_bug.cgi?id=584646 Summary: [abrt] crash in scim-bridge-0.4.16-4.fc13: Process /usr/bin/scim-bridge was killed by signal 11 (SIGSEGV) Product: Fedora Version: 13 Platform: i686 OS/Version: Linux Status: NEW Status Whiteboard: abrt_hash:0a7da8f833d72bf85ed635d824b5c145098e463a Severity: medium Priority: low Component: scim-bridge AssignedTo: phuang(a)redhat.com ReportedBy: csuwhm(a)gmail.com QAContact: extras-qa(a)fedoraproject.org CC: petersen(a)redhat.com, phuang(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org, pwu(a)redhat.com Classification: Fedora abrt 1.0.9 detected a crash. architecture: i686 Attached file: backtrace cmdline: scim-bridge component: scim-bridge executable: /usr/bin/scim-bridge global_uuid: 0a7da8f833d72bf85ed635d824b5c145098e463a kernel: 2.6.33.1-24.fc13.i686.PAE package: scim-bridge-0.4.16-4.fc13 rating: 4 reason: Process /usr/bin/scim-bridge was killed by signal 11 (SIGSEGV) release: Fedora release 13 (Goddard) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

14 years, 2 months

1
2
0 / 0

[Fedora-i18n-bugs] [Bug 584647] New: [abrt] crash in scim-bridge-0.4.16-4.fc13: Process /usr/bin/scim-bridge was killed by signal 11 (SIGSEGV)

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: [abrt] crash in scim-bridge-0.4.16-4.fc13: Process /usr/bin/scim-bridge was killed by signal 11 (SIGSEGV) https://bugzilla.redhat.com/show_bug.cgi?id=584647 Summary: [abrt] crash in scim-bridge-0.4.16-4.fc13: Process /usr/bin/scim-bridge was killed by signal 11 (SIGSEGV) Product: Fedora Version: 13 Platform: i686 OS/Version: Linux Status: NEW Status Whiteboard: abrt_hash:44706bda501801d668480a2bb98a24783524c9c4 Severity: medium Priority: low Component: scim-bridge AssignedTo: phuang(a)redhat.com ReportedBy: csuwhm(a)gmail.com QAContact: extras-qa(a)fedoraproject.org CC: petersen(a)redhat.com, phuang(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org, pwu(a)redhat.com Classification: Fedora abrt 1.0.9 detected a crash. architecture: i686 Attached file: backtrace cmdline: scim-bridge component: scim-bridge executable: /usr/bin/scim-bridge global_uuid: 44706bda501801d668480a2bb98a24783524c9c4 kernel: 2.6.33.1-24.fc13.i686.PAE package: scim-bridge-0.4.16-4.fc13 rating: 4 reason: Process /usr/bin/scim-bridge was killed by signal 11 (SIGSEGV) release: Fedora release 13 (Goddard) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

14 years, 2 months

1
2
0 / 0

[Fedora-i18n-bugs] [Bug 575005] Review Request: zinnia-tomoe - Online hand recognition system with machine learning

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=575005 --- Comment #41 from Dennis Gilmore <dennis(a)ausil.us> 2010-04-22 01:18:17 EDT --- You are readding way to litterally the files on the filesystem. lots of applications show the endianess of the architecture that it was created on. but the applications deals with it just fine regardless of what it was created on. until such point as your application deals with them being created on any arc/endianess, it is application specific data that is architecture dependent and as such belongs in %{_libdir}/%{name}/ -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

14 years, 2 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 575005] Review Request: zinnia-tomoe - Online hand recognition system with machine learning

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=575005 --- Comment #40 from Chen Lei <supercyper(a)163.com> 2010-04-22 01:01:28 EDT --- (In reply to comment #38) > If and only if you can use big endian data on a little endian system or little > endian data on a big endian system you can put it in %{_datadir} > because while the data references the endianness its created on it is > architecture independent. > In your case the data it seems can not be used cross endian and so it is > architecture dependent and must go in %{_libdir} For this package its easy to fix because all data files are arch specfic. If we decide to fix some other fedora packages(normally input method db, game data, voice db and etc.), it'll be very complicated. e.g. espeak http://koji.fedoraproject.org/koji/rpminfo?rpmID=1829417 It contain both noarch files and endian-specfic data files, the default install path for those files are {_datadir}/%{name}-data. The source code defines a macro for its datadir, if we simply cheat dadadir macro to {_libdir}, then we need to install all other noarch files to %{_libdir} too. Also according to FHS, lib64 is designed for 64bit libraries, it seems more reasonable to install those data files to /usr/lib instead of %{_libdir}. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

14 years, 2 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 575005] Review Request: zinnia-tomoe - Online hand recognition system with machine learning

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=575005 --- Comment #39 from Peng Huang <phuang(a)redhat.com> 2010-04-22 00:46:44 EDT --- (In reply to comment #37) > (In reply to comment #35) > > Reading though this it will be simpler for long term management for this to be > > architecture specific. rpm doesn't understand endianness and trying to shoehorn > > it in makes it much more complicated and difficult to work with. > > Where should we install those endian-specfic files %{_prefix}/lib, %{_datadir} > or %{_libdir}? The default install path for those files are normally > %{_datadir} and many softwares which utilize endian-specfic data hardcode > /usr/share/%{name} in its code. It'll be a bit complicated to patch some > package to install or utilize those files from %{_datadir} to %{_libdir}. I think it is acceptable to install arch specified *DATA* files in %{_datadir} too. Probably we can not find out a 100% perfect solution right now, but I think we could improve it in future. I still suggest resolving this problem in upstream. Let zinnia use non endian-specific data file. BTW, I think our major platfroms (i386 and x86_64) using the same endian. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

14 years, 2 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 575005] Review Request: zinnia-tomoe - Online hand recognition system with machine learning

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=575005 --- Comment #38 from Dennis Gilmore <dennis(a)ausil.us> 2010-04-22 00:33:04 EDT --- If and only if you can use big endian data on a little endian system or little endian data on a big endian system you can put it in %{_datadir} because while the data references the endianness its created on it is architecture independent. In your case the data it seems can not be used cross endian and so it is architecture dependent and must go in %{_libdir} -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

14 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

i18n-bugs April 2010