June 2010 - openSUSE Features - openSUSE Mailing Lists

[openFATE 307620] Parenta Control
by fate_noreply＠suse.de 11 May '11

11 May '11

Feature added by: J Thimm (thimm) Feature #307620, revision 1 Title: Parenta Control openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Package Wishlist: Unconfirmed Priority Requester: Mandatory Requested by: J Thimm (thimm) Description: I would love to see a parental control feature (with GUI) that allows families -- to use the OS by kids. Parental Control features: - easy configurable and usable This should be compulsory -- because how do you want to educate the youngsters to use the interne? Currently parents cannot "easily" administer such features -- one has to be a professional to get this to work!! I would rather let my kids use Windows because of this -- since there are a number of program do do this job! Am I wrong? Thanks -- openSUSE Feature: https://features.opensuse.org/307620

1 4

[New: openFATE 309579] Dependency tree in zypper summary
by fate_noreply＠suse.de 11 May '11

11 May '11

Feature added by: Ján Kupec (jkupec) Feature #309579, revision 1 Title: Dependency tree in zypper summary Requested by: Ján Kupec (jkupec) Partner organization: openSUSE.org Description: Visualize dependencies of packages (from the installation summary or given on command line) using colored (by type of dependency - recommends, requires, etc) ASCII tree/graph. The feature can be enabled in the info command (zypper info --dep-tree package) and in the installation summary prompt (in which case it would show the graph from the requested packages via all the to-be-installed ones, ending with the installed ones). This feature is meant to be kept simple, and leave more complex analysis to other tools (FATE 309572). Business case (Partner benefit): openSUSE.org: Visualization of package dependencies in a tree makes it easier for packagers to spot incorrect/unneeded dependencies and manage systems, save space, or analyze dependency problems for administrators and users. -- openSUSE Feature: https://features.opensuse.org/309579

1 2

[openFATE 306116] Better lock handling in zypper
by fate_noreply＠suse.de 06 May '11

06 May '11

Feature added by: Marek Stopka (m4r3k) Feature #306116, revision 1, last change by Title: Better lock handling in zypper openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Marek Stopka (m4r3k) Description: Currently only two states in locking of packages are available (keep package as is/do not care about package) but I think it would be much more better to have a possibility lock only some parameters of package... For example you have a 64bit machine, but you want keep some package always in i586 version, but you still wanna version updates in this case there should be a possibility to lock only this parameter. Of course there is a lot of options what else can be locked, for example version of package, meaning that you can't change package version, but release number can change... -- openSUSE Feature: https://features.opensuse.org/306116

1 12

[openFATE 307310] Good CJK / East Asian input support (esp. KDE)
by fate_noreply＠suse.de 05 May '11

05 May '11

Feature added by: Markus K (KAMiKAZOW) Feature #307310, revision 1 Title: Good CJK / East Asian input support (esp. KDE) openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Markus K (kamikazow) Description: Setting up CJK support for typing kanji has always been a bitch for me and I always failed -- especially under KDE 4, even though I consider myself an experienced computer user. Wang Hoi developed an applet that should make it all easier. It's currently in KDE-Review. He wrote about it: http://qiacat.blogspot.com/2009/03/as-my-first-post-first-say-hello-to.html http://mail.kde.org/pipermail/plasma-devel/2009-May/005420.html -- openSUSE Feature: https://features.opensuse.org/307310

1 9

[openFATE 307873] Add the uuid-ossp module to postgresql-contrib
by fate_noreply＠suse.de 04 May '11

04 May '11

Feature added by: Reinhard Max (rmax) Feature #307873, revision 1 Title: Add the uuid-ossp module to postgresql-contrib openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Reinhard Max (rmax) Partner organization: openSUSE.org Description: As it has been pointed out in bnc#534050 and in private mail, we are missing the uuid-ossp module from our postgresql-contrib package. The reason for this is, that it depends on the ossp-uuid library, for which we do not yet have an official package in Factory. For 11.3 both, the library package and the contrib modules should be added. Business case (Partner benefit): openSUSE.org: To stay compatible with the PostgreSQL packages of other distributions and with applications that require this module. -- openSUSE Feature: https://features.opensuse.org/307873

1 4

[openFATE 306471] auto create torrent files for images created
by fate_noreply＠suse.de 20 Apr '11

20 Apr '11

Feature added by: Jigish Gohil (cyberorg) Feature #306471, revision 1, last change by Title: auto create torrent files for images created Buildservice: Unconfirmed Priority Requester: Important Requested by: Jigish Gohil (cyberorg) Description: Currently only metalink is created for the images created on the build service, it would be nice to have torrent files created too at the time of publishing the images. -- openSUSE Feature: https://features.opensuse.org/306471

1 4

[New: openFATE 308351] Make Live Updates Easy
by fate_noreply＠suse.de 14 Apr '11

14 Apr '11

Feature added by: Andreas Jaeger (a_jaeger) Feature #308351, revision 1 Title: Make Live Updates Easy openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Description: The infrastructure is there for Live updates and it works with "zypper dup" but there are many manual steps. This is too complicated, users need first to google for the details before using it. We need an easy way to update from 11.2 to Factory, from 11.2 to 11.3 and from Factory to 11.3. Easy means: A single command line that does by default the update from 11.2 to 11.3 and offers the others as well. -- openSUSE Feature: https://features.opensuse.org/308351

1 12

[openFATE 305849] Provide the Ability to Natively Load More Than One Protocol Stack
by fate_noreply＠suse.de 14 Apr '11

14 Apr '11

Feature added by: Scott Couston (zczc2311) Feature #305849, revision 1, last change by Title: Provide the Ability to Natively Load More Than One Protocol Stack openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Scott Couston (zczc2311) Description: Currently we natively support only an IP protocol stack, however I would hazard a guess that SLES has the ability to load IPX as well even as we have moved away from IPX. The Other Misgiving is that natively we cannot support more than an IP Protocol Stack and the lack of very good open/proprietary 3270 type Terminal Emulation shipped by default. I would be much happier if opensuse OR SLED could cope with another Protocol Stack - In Australia there is an enormous market we currently offer no solution to in only providing an IP Protocol Stack. In my home Country Australia All Federal Government- Health-Social Security- etc./All Banking Sectors/Most all Military Sectors/All State and Federal Law enforcement/Others (Thats a big Market Place) need to support a 3270 type Terminal Emulator and directly address SNA or X.25 or STLC comms. To compete we must at least be equal in the market place! The other mass market world wide particularly in the US are PC's that all Travel Agents use to make their bookings. World Wide They would use either Saber or Apollo or Galileo or Amadeus or Abacus - that about covers the whole World now. The issue all user face with M.S is that they most likely have a dedicated comms server as M.S cannot even load the required Protocol Stack. Depending on which Global System is used they mostly stick to their preferred stack and this could vary from ALC/STLC/X.25/IP/IPX/MATIP/etc..... Enough said - I think we all understand how we can better appeal to other huge markets if we invest in the functional ability to load more than just IPV4/6. I think we need to look far and wide at ALL Industry comms and we CAN do what MS cannot - We could easily bundle off a very very good 3270 type emulator and support SNA AND IP directly without the possible need for a comms servers packet stacking and promiscuous translation to IP. So we have 2 huge untaped Markets we cannot help right now and these are Australian - .GOV/.MIL and internal Banks and credit unions Global - The travel Industry is their varying, but constant use of say STLC/MATIP If we need to pull apart IP coms in the future for IPV6 this would be golden to support more than an IP Protocol only. __________________ -- openSUSE Feature: https://features.opensuse.org/305849

1 4

[openFATE 305842] Provide RPM Update Server to Update All openSUSE/SLED Workstations
by fate_noreply＠suse.de 14 Apr '11

14 Apr '11

Feature added by: Scott Couston (zczc2311) Feature #305842, revision 1, last change by Title: Provide RPM Update Server to Update All openSUSE/SLED Workstations openFATE: Unconfirmed Priority Requester: Important Requested by: Scott Couston (zczc2311) Description: *Please be Patient - This is my First FATE request* Definitions in this Submission Workstation == Any openSUSE/SLED installation that functions without direct server support Installation Server == Any designated PC that holds a repository for the complete RPM's contained at time of software Release. Update Server == Any designated PC that holds a repository(s) that contain online update RPM's The 'Server' would be accessible by normal NFS... et al Services currently available. Current Situation The Installation of a PC with openSUSE/SLED requires a huge number of Online Updates a situation that may never change whilst development continues. The Installation of openSUSE has the ability to perform many NFS Installations at one time whilst being able to create 1 repository server for the entire Installation RPM's for future addition of features and groups not included in the base installation. Feature Request Along the same notion of an NFS Installation I propose that we an Installation Server or Other to be an Update Server which downloads ALL RPM updates as they become available. Each Workstation then selects Online Updates from the Update Server per chosen update check cycle period. In this way each workstation needs only to connect with the Update Server rather than each workstation downloading its required updates. This has the potential to cut update traffic by the number of workstations installed on a LAN and this weighed against the traffic of downloading ALL updates and the traffic on ALL Online update Server Repositories and Mirrors external to the LAN. The concept is notedly simple however this has a huge technical repercussion and link to FATE #120340. This concept is open for addition to FATE #120340 or it can stand alone at the discretion of Novell.DE Whilst this concept is created by the author the technical impact/problems will require much input from Novell.De and Suse.DE and the author. -- openSUSE Feature: https://features.opensuse.org/305842

1 10

[openFATE 305919] Hunspell as a system wide spellchecker
by fate_noreply＠suse.de 13 Apr '11

13 Apr '11

Feature added by: Stephan Kulow (coolo) Feature #305919, revision 1, last change by Title: Hunspell as a system wide spellchecker openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Kálmán Kéménczy (kkemenczy) Description: Why Hunspell? MySpell is not developed for quite a long time either in Mozilla and in OpenOffice.org. Hunspell is a fork of MySpell, it has great improvements is several ways, and fully backward compatible with MySpell. Main features: * Extended support for language peculiarities; Unicode character ncoding, compounding and complex morphology. * Improved suggestion using n-gram similarity, rule and dictionary ased pronounciation data. * Morphological analysis, stemming and generation. * Hunspell is based on MySpell and works also with MySpell dictionaries. * GPL/LGPL/MPL tri-license http://en.wikipedia.org/wiki/Hunspell http://hunspell.sourceforge.net/ Fedora project: http://fedoraproject.org/wiki/Releases/FeatureDictionary I also find a reference in the wishlist: http://en.opensuse.org/Wishlist_Various Relations: - Hunspell as a system wide spellchecker (novell/bugzilla/id: 354554) https://bugzilla.novell.com/show_bug.cgi?id=354554 Discussion: #1: Stephan Kulow (coolo) (2008-01-18 06:18:21) For reference: http://lists.opensuse.org/opensuse-factory/2008-01/msg00156.html #2: Petr Mladek (pmladek) (2008-01-18 07:20:54) * ** Bug 301458 has been marked as a duplicate of this bug. *** #3: Petr Mladek (pmladek) (2008-01-18 07:24:25) I'll do my best to do it for openSUSE-11.0. I am still busy with some other things. Or Michael, do you have time to look at it? #4: Kálmán Kéménczy (kkemenczy) (2008-01-27 12:17:56) patch for gtkspell (2.0.11): http://www.abisource.com/~dom/gtkspell-2.0.11-enchant.patch using this patch makes obsolate the gtkspell-gcc-err-fix.diff patch for gnome-spell 1.0.7: based on https://bugzilla.redhat.com/show_bug.cgi?id=426347 attached #5: Petr Mladek (pmladek) (2008-01-28 05:44:13) Adding gtkspell maintainer to CC. #6: Kálmán Kéménczy (kkemenczy) (2008-01-28 05:52:56) Created an attachment (id=191980) gnome spell check patch #7: Kálmán Kéménczy (kkemenczy) (2008-02-04 02:24:22) now available in Build Service (without dictionaries) http://download.opensuse.org/repositories/home:/kkemenczy/openSUSE_Factory/ #8: Ladislav Michnovič (lmich) (2008-02-04 02:49:51) Proposed patch for gtkspell has been added. #9: Kálmán Kéménczy (kkemenczy) (2008-02-04 12:38:37) dictionaries http://download.opensuse.org/repositories/home:/kkemenczy/openSUSE_Factory/… #10: Martin Schlander (cb400f) (2008-02-05 01:30:16) For Danish (da_DK) there's a dictionary being developed that's optimized for hunspell at http://www.stavekontrolden.dk http://www.stavekontrolden.dk/main/sspinputfiles/da_DK.dic http://www.stavekontrolden.dk/main/sspinputfiles/da_DK.aff I believe it's already a better option for hunspell than the dictionary from http://da.speling.org which is currently packaged. If not already it will become so soon as it's developed a lot more actively. Furthermore it's available under these licenses: GPL version 2 LGPL version 2.1 MPL version 1.1 Don't hesitate to ask if there are further questions. #11: Kálmán Kéménczy (kkemenczy) (2008-02-05 07:25:42) da_DK dictionary updated what is the next step? Someone had to decide to add it to the factory for further test. #12: Petr Mladek (pmladek) (2008-02-05 09:57:30) Lado. is there any chance that you could create the hunspell package for STABLE/FACTORY? I am still busy with some other stuff. #13: Ladislav Michnovič (lmich) (2008-02-06 02:49:05) O.K. I'll do it. It won't be in Alpha 2 because it is already under mastering process. It should appear in Alpha 3. #14: Ladislav Michnovič (lmich) (2008-02-19 06:14:25) Package is in Factory. #15: Kálmán Kéménczy (kkemenczy) (2008-02-21 03:48:22) imho several tasks left: * I am not sure that gnome-spell is Enchant-enable or not. ttps://bugzilla.novell.com/attachment.cgi?id=191980 * Sonnet's enchant backend backport to kdelibs / kspell ttp://bugs.kde.org/show_bug.cgi?id=154560 more info: https://www.redhat.com/archives/fedora-devel-list/2007-December/msg01493.ht… * Removing hunspell from Enchant ttps://bugzilla.redhat.com/show_bug.cgi?id=426402 * vim patch for hunspell: ttps://bugzilla.redhat.com/show_bug.cgi?id=219777 Should I create seperate bugs or we should keep them together here? #16: Ladislav Michnovič (lmich) (2008-02-21 04:13:53) (In reply to comment #15 from kalman kemenczy) > imho several tasks left: > > * I am not sure that gnome-spell is Enchant-enable or not. > https://bugzilla.novell.com/attachment.cgi?id=191980 > > * Sonnet's enchant backend backport to kdelibs / kspell > http://bugs.kde.org/show_bug.cgi?id=154560 > more info: > https://www.redhat.com/archives/fedora-devel-list/2007-December/msg01493.ht… > > * Removing hunspell from Enchant > https://bugzilla.redhat.com/show_bug.cgi?id=426402 > > * vim patch for hunspell: > https://bugzilla.redhat.com/show_bug.cgi?id=219777 > > Should I create seperate bugs or we should keep them together here? Adding kde-maintainers and gnome-maintainers to CC. Reassigning to vim maintainer. #17: Bjoern Jacke (bjacke) (2008-03-23 12:43:01) * ** Bug 237828 has been marked as a duplicate of this bug. *** #18: Bjoern Jacke (bjacke) (2008-05-01 15:57:47) - any news from vim maintainer on this? - enchant still needs rework or update - gnome-spell still needs enchant support added #19: Ladislav Michnovič (lmich) (2008-05-05 04:40:12) Adding JP. What do you think about this? See comment #15 and #18. #20: Matthias Koenig (makoenig) (2008-05-05 06:42:03) There are some problems with the vim patch. Currently we have /bin/vim-normal as default vim and /usr/bin/vim-enhanced. As the patch links against libhunspell which lives in /usr/lib{,64} we cannot link /bin/vim-normal against this. This would require either moving libhunspell to /lib{,64} which is not want we want (libhunspell itself also links against /usr/lib{,64}/libstdc++), or building /bin/vim-normal without syntax features at all (as the spell features seem to be tightly coupled to the general syntax features), which I also don't want. The best solution would be to provide a /bin/vim-tiny with minimal features and moving /bin/vim-normal to /usr/bin/vim-normal. But this will not happen for 11.0, as it will need yet another vim package restructuring. But, despite of this, yes, I think using hunspell is a good idea, as the vim dictionaries are derived from the OO ones and would otherwise waste a lot of space by duplicated data. Also worth mentioning, that this patch has been sent a year ago to upstream. While the idea has been appreciated, the patch has been rejected as is, AFAIK there has not been any work to improve this: http://www.mail-archive.com/vim-dev@vim.org/msg03252.html #21: Kálmán Kéménczy (kkemenczy) (2008-05-09 22:54:06) Created an attachment (id=214116) Gnome spell enchant patch here is the latest and greatest patch wirtten by Szilveszter Farkas from Ubuntu community, however this is created for gnome-spell 1.0.7, maybe it could use for 1.0.8. #22: Kálmán Kéménczy (kkemenczy) (2008-05-09 22:57:46) Rodrigo, could you check this patch to gnome-spell, please? https://bugzilla.novell.com/attachment.cgi?id=214116 Hopefully you are the maintainer for this packge. Many thanks, kalman #23: Stanislav Brabec (sbrabec) (2008-05-21 04:21:49) Patch applied (autogenerated files removed from it). #24: Jan Engelhardt (jengelh) (2009-01-11 18:53:30) There's a ton of spelling tools, why could not it have used one of the previously packaged ones, aka aspell or ispell? #25: Kálmán Kéménczy (kkemenczy) (2009-01-12 01:19:59) Jan, Hunspell already packaged in openSUSE. To answer your why's please read comment#1 #26: Jan Engelhardt (jengelh) (2009-01-12 03:06:41) >Hunspell already packaged in openSUSE But was not in 10.3. Hence the question. >comment#1 First comment says "Myspell". I asked about aspell/ispell. #27: Kálmán Kéménczy (kkemenczy) (2009-01-12 03:41:41) I think there are some reasons why choose Mozilla and OpenOffice.org and why Fedora decided as well, and slowly Ubuntu will go this way. In my comment#1 you should find the awesome summary: http://fedoraproject.org/wiki/Releases/FeatureDictionary Hunspell is not a question, the question is when? -- openSUSE Feature: https://features.opensuse.org/305919

1 3