January 2010 - openSUSE Features - openSUSE Mailing Lists

[openFATE 308334] Distribute individual letters across cell width and height (aka 均等割符)
by fate_noreply＠suse.de 11 Jan '10

11 Jan '10

Feature changed by: Kohei Yoshida (kohei_yoshida) Feature #308334, revision 20 Title: Distribute individual letters across cell width and height (aka 均等割符) Requested by: Kohei Yoshida (kohei_yoshida) Description: Distribute letters at equal intervals across cell's width such that the first and last letters are aligned with the left and right edge of the cell, respectively. Also support similar distribution mechanism in a vertical direction. This functionality is also known as Kin-tou Wari-fu (均等割符) in Japanese, and is very common operation among Japanese Excel users. Relations: - i#107467 - Excel import issue with cells with distributed content (url: http://qa.openoffice.org/issues/show_bug.cgi?id=107467) - i#107470 - Request for this feature in the upstream IZ (url: http://qa.openoffice.org/issues/show_bug.cgi?id=107470) + - User-contributed doc on text justification in Japanese text. (url: http://wiki.services.openoffice.org/wiki/User:Foral/Spec/Justification) Use Case: Sentences in the Japanese language do not normally break at each word unlike most Western languages. The normal justification functionality is therefore useless for the Japanese users. Instead, they typically justify sentences by adjusting spaces between letters, which is what this requested functionality will provide. Discussion: #3: Kohei Yoshida (kohei_yoshida) (2010-01-05 14:22:02) I've started looking into this. #4: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:36:46) Here is the initial hurdle: Calc uses XSL-FO for all text formatting, and fo:text-align specifies the alignment of a text (I assume for both horizontal and vertical directions). The bad news is that, this attribute does not allow a "distributed" alignment, but in order for us to implement this feature, we need that to allow a distributed alignment. Reference: http://www.w3.org/TR/xsl/#text-align #5: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:45:10) (reply to #4) Well, I guess I could use the "justify" alignment and additional flag to specify how the content is justified. The spec allows user-agent- specific justification algorithm, so it's doable without breaking the standard. #6: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:49:15) (reply to #5) And we could perhaps use the 'text-justify' attribute to specify the justification algorithm. See below: http://www.w3.org/TR/1999/WD-i18n-format-19990910/#a5 #7: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:59:37) (reply to #6) This one is the latest spec of the fore-cited: http://www.w3.org/TR/i18n-format/#text-justify #8: Kohei Yoshida (kohei_yoshida) (2010-01-08 12:39:43) Ok. Here is how I've decided to store this in ODF. For both normal justifiation and distributed justification, the style attribute 'fo:text-align' is saved as 'justify'. Then, for the distributed justification, an additional style attribute 'csstext3:text- justify' gets stored with a value of 'distribute'. For the normal justification, either this value is 'auto', or this attribute won't get stored at all. It took me a while to get to this point since OOo's handling of style attributes and how they are exported to xml are very complex. But I eventually got it to save and load correctly. #9: Kohei Yoshida (kohei_yoshida) (2010-01-11 13:23:40) For alignment in vertical direction, the current ODF uses style: vertical-align attribute which can be either one of: automatic, bottom, middle, top. First, we need to add a new alignment type 'justify' to the style:vertical-align, and use another attribute to specify the justification method. This would be similar to how the horizontal justification is handled. The problem is that we can't reuse the same 'text-justify' attribute name since that would clash with the horizontal justification method attribute. We need a new attribute name for this to avoid such naming clash. The first name that comes to mind is style:vertical-justify , which specifies the same set of values that the csstext3:text-justify supports. Of course, this imlies that to finalize this feature we need to get blessing from the ODF TC, which may not happen in a timely manner. We need to come up with a "solution" for that as well. -- openSUSE Feature: https://features.opensuse.org/308334

1 0

[openFATE 307476] Make WebKam or any other KDE webcam client work
by fate_noreply＠suse.de 11 Jan '10

11 Jan '10

Feature added by: Manuel Ramirez (elpreto) Feature #307476, revision 1 Title: Make WebKam or any other KDE webcam client work Hackweek IV: Unconfirmed Priority Requester: Important Requested by: Manuel Ramirez (elpreto) Description: KDE don't have any other webcam client (at least i don't know about other one), and WebKam is not working in openSUSE, since a lot of notebooks comes with integrated webcams, is really bad to don't have a software to use the webcam. -- openSUSE Feature: https://features.opensuse.org/307476

1 3

[openFATE 308334] Distribute individual letters across cell width and height (aka 均等割符)
by fate_noreply＠suse.de 11 Jan '10

11 Jan '10

Feature changed by: Kohei Yoshida (kohei_yoshida) Feature #308334, revision 19 Title: Distribute individual letters across cell width and height (aka 均等割符) Requested by: Kohei Yoshida (kohei_yoshida) Description: Distribute letters at equal intervals across cell's width such that the first and last letters are aligned with the left and right edge of the cell, respectively. Also support similar distribution mechanism in a vertical direction. This functionality is also known as Kin-tou Wari-fu (均等割符) in Japanese, and is very common operation among Japanese Excel users. Relations: - i#107467 - Excel import issue with cells with distributed content (url: http://qa.openoffice.org/issues/show_bug.cgi?id=107467) - i#107470 - Request for this feature in the upstream IZ (url: http://qa.openoffice.org/issues/show_bug.cgi?id=107470) Use Case: Sentences in the Japanese language do not normally break at each word unlike most Western languages. The normal justification functionality is therefore useless for the Japanese users. Instead, they typically justify sentences by adjusting spaces between letters, which is what this requested functionality will provide. Discussion: #3: Kohei Yoshida (kohei_yoshida) (2010-01-05 14:22:02) I've started looking into this. #4: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:36:46) Here is the initial hurdle: Calc uses XSL-FO for all text formatting, and fo:text-align specifies the alignment of a text (I assume for both horizontal and vertical directions). The bad news is that, this attribute does not allow a "distributed" alignment, but in order for us to implement this feature, we need that to allow a distributed alignment. Reference: http://www.w3.org/TR/xsl/#text-align #5: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:45:10) (reply to #4) Well, I guess I could use the "justify" alignment and additional flag to specify how the content is justified. The spec allows user-agent- specific justification algorithm, so it's doable without breaking the standard. #6: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:49:15) (reply to #5) And we could perhaps use the 'text-justify' attribute to specify the justification algorithm. See below: http://www.w3.org/TR/1999/WD-i18n-format-19990910/#a5 #7: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:59:37) (reply to #6) This one is the latest spec of the fore-cited: http://www.w3.org/TR/i18n-format/#text-justify #8: Kohei Yoshida (kohei_yoshida) (2010-01-08 12:39:43) Ok. Here is how I've decided to store this in ODF. For both normal justifiation and distributed justification, the style attribute 'fo:text-align' is saved as 'justify'. Then, for the distributed justification, an additional style attribute 'csstext3:text- justify' gets stored with a value of 'distribute'. For the normal justification, either this value is 'auto', or this attribute won't get stored at all. It took me a while to get to this point since OOo's handling of style attributes and how they are exported to xml are very complex. But I eventually got it to save and load correctly. + #9: Kohei Yoshida (kohei_yoshida) (2010-01-11 13:23:40) + For alignment in vertical direction, the current ODF uses style: + vertical-align attribute which can be either one of: automatic, bottom, + middle, top. First, we need to add a new alignment type 'justify' to + the style:vertical-align, and use another attribute to specify the + justification method. This would be similar to how the horizontal + justification is handled. The problem is that we can't reuse the same + 'text-justify' attribute name since that would clash with the + horizontal justification method attribute. We need a new attribute name + for this to avoid such naming clash. + The first name that comes to mind is style:vertical-justify , which + specifies the same set of values that the csstext3:text-justify + supports. Of course, this imlies that to finalize this feature we need + to get blessing from the ODF TC, which may not happen in a timely + manner. We need to come up with a "solution" for that as well. -- openSUSE Feature: https://features.opensuse.org/308334

1 0

[openFATE 300758] Show unneeded packages
by fate_noreply＠suse.de 10 Jan '10

10 Jan '10

Feature changed by: Rafael Belmonte (EagleScreen) Feature #300758, revision 112 Title: Show unneeded packages openSUSE-10.2: Rejected by Thorsten Kukuk (kukuk) reject date: 2006-08-02 11:31:19 reject reason: For SL10.2 we have to get libzypp really stable and fast before we add new features. Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-17 17:03:57 reject reason: Postponing. Priority Requester: Important Projectmanager: Desirable openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-11-21 12:16:20 reject reason: Out of scope for 11.0 Priority Requester: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-07 13:34:02 reject reason: Postponing, needs underlaying infrastructure to be fixed first. Priority Requester: Important openSUSE-11.2: Rejected by Stanislav Visnovsky (jkupec) reject date: 2009-11-30 14:20:26 reject reason: Marked as done by mistake. The feature is not done. Priority Requester: Important Projectmanager: Important openSUSE-11.3: New Priority Requester: Desirable Requested by: JP Rosevear (jproseve) Description: The package manager should learn to show unneeded packages (packages which are not required by other packages and are not in wanted selections) and allow to deinstall them like the popular debfoster/deborphan tools. A typical use case: user installs an application which pulls in some dependencies to test it, uninstalls the application shortly after or way later but the dependencies stay unused installed on the system. Commandline UI (zypper) only. References: https://bugzilla.novell.com/show_bug.cgi?id=166132 Discussion: #1: Jiri Srain (jsrain) (2007-06-05 13:46:00) Schubi, is there any possibility to make solver tell which packages are orphanized? It would be interesting especially if the packages which are marked for deletion were considered as non-installed (eg. if foo- devel is installed but marked for deletion and nothing else requires foo, then foo is orphanized). #2: Stefan Schubert (schubi2) (2007-06-06 11:04:04) (reply to #1) Currently not cause the solver has no information about who (user, package,...) has triggered the installation of a package. If we are storing this information it would be possible for solver to remove these kind of packages too. It is not simple but doable. By the way, we will have to store this kind of information in the future. E.g. we need to save the "keep state by user" in a database in order to regard this state in future solver runs. #3: Jiri Srain (jsrain) (2007-06-06 14:25:07) (reply to #2) Looks like a missunderstanding. Basically every package wihch is not required/recommended/suggested or doesn't enhance anything that is installed and not marked for deletion is IMO considered to be orphanized. If user eg. wants to remove a pattern including all its packages (which are not required by something else), solver providing this kind of information would help a lot (and I don't think that we would need any other information to be stored. #4: Stefan Schubert (schubi2) (2007-06-06 15:33:44) (reply to #3) I do not think so. What does "orphanized" mean ? Let me take your example from comment #1. foo should be deleted too if the user delete foo-devel and foo has been installed due the requirement of foo-devel. BUT the user will kill us if we are deleting foo although the user has installed foo explicit sometime ago in a seperate installation workflow. So this information ( The USER has installed foo) will be currently not saved and is needed here to decide if foo has to be deleted or not. #5: Stefan Schubert (schubi2) (2007-06-06 15:39:47) (reply to #3) Lets take your example concerning the erasing of patterns. That is much more complex. I have already described the problem here: http://en.opensuse.org/Libzypp/Solver#Known_Problems " Proper behaviour of erasing patterns" There are already some bugzilla entries: Bug 274283 - Delete iFolder from YaST makes eDirectory Delete mandatory Bug 238250 - YaST does not upgrade an Add-on Product #6: Jiri Srain (jsrain) (2007-06-08 16:46:32) See also https://bugzilla.novell.com/show_bug.cgi?id=166132 This is another use case for the same solver functionality #8: Federico Lucifredi (flucifredi) (2008-06-12 20:46:17) this should be commandline-only, definitely an advanced-user option. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:47:28) cut from description: See Bug 140346 #10: Duncan Mac-Vicar (dmacvicar) (2008-11-03 11:24:53) As discussed in Prague, this could be done using the package history once we have a reader. #11: Karsten König (remur) (2009-01-19 10:09:49) How about using rpmorphan, I agree with flucifredi about the command line idea... http://rpmorphan.sourceforge.net/ And otherwise you could use their system to find orphanized packages and display them in yast but make clear that deleting -all orphanized packages will also delete the ones explicitly installed... (it only detects wether the package fullfiles any requirement...) #12: Ján Kupec (jkupec) (2009-01-19 14:48:38) (reply to #11) I'm not the solver developer, but i'm pretty sure it's easy (and probably more effective) to find the 'leaf' packages (that's what rpmorphan seems to do) using existing solver (see satsolver package). But we don't want to just highlight leaf packages, we want to remove unused packages, that is all leaves minus those explicitly installed. So we will feed the solver with this 'explicitly-installed' information. The package history will be the source of this info for now. Maybe later we find some way to store this info that could be used across tools (e.g. directly in the rpm db). So rpmorphan will be able to use this info as well. #13: Pavol Rusnak (prusnak) (2009-01-19 15:44:26) (reply to #12) Yes, that's good idea. Detecting leaf packages is the first step. Detecting which ones to remove (i.e. not explicitly installed) is the second. I think that rpmorphan shows all leaf packages, but it selects only the ones that start with "lib". If we strictly followed library packaging policy that would do the trick. btw. rpmorphan is packaged in Contrib (http://en.opensuse.org/Contrib) #14: Michal Smrž (ilfirin) (2009-03-07 20:05:22) (reply to #11) I am afraid of using rpmorphan to do this. Cause last time, I tested it, it wants to remove libdvdnav and libdvdcss libraries. This is very bad. It leads to many not advanced users to ask in phorums "Why OpenSUSE is not playing DVDs anymore?" I see many problems this could make. #15: Christoph Thiel (cthiel1) (2009-04-21 15:23:06) We don't have the resources to implementing this. Seems to be a prefect fit for a community project. #17: Piotrek Juzwiak (benderbendingrodriguez) (2009-04-22 07:58:47) Maybe the idea to accomplish this would be simply by using the packages. xml file and diff it. We can already export what packages we got right? So if it would compare the packages.xml before installation and after it would then delete it. There is a problem when installing many packages, they would all have to be "grouped" which pulled which dependencies. #20: Vladimirs Kuzmins (vovachaka) (2009-10-26 16:27:51) This feature is a specially important, now when we have distro upgrade, which changes a lot of dependencies and a lot of obsolete packages remain installed. Please, someone implement it! #21: Thomas Göttlicher (tgoettlicher) (2009-10-26 16:41:29) I've added a view for orphaned packages in yast2-qt-pkg. There is a package group "orphaned packages" similar to "suggested packages" and "recommended packages" in yast2-qt-pkg version 2.18.17. #22: Atri Bhattacharya (badshah400) (2009-10-31 14:55:26) (reply to #21) Thanks for implementing this much needed feature. But this feature does not work with the gtk interface in 11.2 RC2; please have this added for the final release of 11.2. #23: Kornél Jahn (cornail) (2009-11-02 07:48:05) (reply to #21) Tried to test this but didn't seem to work on RC2: Orphaned packages view is empty. E.g. installed blender, which pulled yafray. After uninstalling blender, yafray remained installed but didn't show up as an orphaned package. Also installing audacity or inkscape pulled a lot of dependencies which were not showed as orphaned after uninstalling them. #24: Kornél Jahn (cornail) (2009-11-02 08:06:38) (reply to #23) Since it is marked as done, I filed a bug for it: https://bugzilla.novell.com/show_bug.cgi?id=551771 (https://bugzilla.novell.com/show_bug.cgi?id=551771) #25: Ján Kupec (jkupec) (2009-11-30 14:18:55) (reply to #21) There has been a misunderstanding here. What Thomas implemented is a view of packages that no longer have update candidates (those which are probably no longer maintained, thus 'orphaned'). This very fate request (IMO) incorrectly uses the word 'orphaned' for what is better described as "unused packages" or "no longer needed packages", or "unnecessary packages". Definitely not orphans (deborphan/rpmorphan is also a misfortunate name IMO). Anyway, whether orphan or unused, this feature is not implemented yet, thus i'm reopening it for 11.3. #26: Ján Kupec (jkupec) (2009-11-30 14:21:27) reopening for 11.3 (see comment #25) #27: Ján Kupec (jkupec) (2009-11-30 14:30:44) I suggest to call these packages unused instead of orphaned . I don't want to decide this by myself, so please speak up. Here are my arguments: 1) the word 'orphan' describes something that has lost its parent(s). In this case, it is actually the child that was lost - a package that depended on other package has been removed. The parent package is still installed, but there's no more use for it - it's unused . 2) we (and a few other distros and communities as well) already use orphaned to describe packages that are no longer cared for - unmaintained packages, packages dropped from distros. #28: Ján Kupec (jkupec) (2009-11-30 15:05:21) (reply to #27) Thomas suggests that perhaps not needed (or no longer needed ) would be better than unused since 'unused' can be confused with 'not used by user' rather than 'not used by other packages'. #29: Roberto Mannai (robermann79) (2009-11-30 15:40:37) Undependent packages : packages which don't have any(more) dependency. #30: Kornél Jahn (cornail) (2009-11-30 16:15:08) I also support the not needed / no longer needed version. Orphaned is bad since it can be misunderstood, just like "undependent package", if Roberto meant to suggest it as a description for this phenomenon. Case A: If I install manually package X, which doesn't have any dependencies nor is it referred to by any other package, it is not a "not needed" one. 'Cause it was manually installed by the user. Case B: Package X is installed automatically as a dependency while installing package Y. Package Y is then removed, but X stays, with no other package referring to it as a dependency. X is then a "not needed" package. #31: Roberto Mannai (robermann79) (2009-11-30 17:00:02) (reply to #30) +1 Kornél Regarding Case A: of course "not needed package" is a subset "undependent package" - "not needed" catches the user's point of view and it is more precise. Nevertheless, determining that "not needed" packages is a hard job, so it could be a good starting point just knowing which are the "undependent" ones (at least as a first step). #32: Roberto Mannai (robermann79) (2009-11-30 17:47:05) (reply to #31) The user could have a graphical list of "undependent packages", which then he could mark each of them as "used/not used". The GUI then could suggest the "unused packages" for removal (this being a temporary but useful use case). #33: Ken Schneider (kensch) (2009-12-15 18:15:55) When you install a package using package management it checks to make sure all dependencies are also installed or adds them to the install list via the "Requires" feature. When de-installing the package check the list of "Requires" packages and see which ones can also be de- installed. That way there are no left over packages. If one of the "Requires" packages are also needed by other packages they are left installed. I am no where near being a programmer but that would seem to be simple to do. #34: Ján Kupec (jkupec) (2009-12-15 18:47:57) (reply to #33) Such procedure would also wipe out packages that you still want to use. E.g. you have nagios-plugins-zypper, which requires zypper. Now, 'zypper remove nagios-plugins-zypper' would realize that after removing nagios-plugins-zypper nothing requires zypper, and would want to remove zypper as well. So what your idea lacks is a list of packages that were installed in the past based on explicit request by user. The procedure must avoid removing these. See also c#12 #36: Ján Kupec (jkupec) (2009-12-15 18:47:02) So i'm renaming this fate request to 'Show unneeded packages' (to make it shorter) to avoid further confustion. #37: Don Hughes (dehughes) (2009-12-15 19:10:53) I also would like to see this feature. I currently use rpmorphan with a list of things that it will mark that I know that I need. I also occationally go through yast2 and try to uninstall things that I do not recognize and see if they are flagged as being needed by something else. Both time consuming and error prone. And, a lot of packages seem to be some what careless in what the require for prereqs - pulling in KDE,gnome, and X11 packages on text- only machines for example; which then triggers a flood of KDE, gnome, and X11 library installations which I then have to mannually uninstall and mark as taboo. On my external facing servers I do not like to have any extra/unneeded/unwanted packages to provide possible attack vectors. + #39: Rafael Belmonte (eaglescreen) (2010-01-10 22:43:40) + Hello, this is one of the main causes of I use more Debian/Ubuntu than + OpenSuse. Debian & Ubuntu already have this implemented. + I think this is a fundamental aspect to work in OpenSuse. + Debian & Ubuntu can distinguish packages that were manually installed + and packages that were installed just to satisfy dependencies. OpenSuse + needs to do this too. -- openSUSE Feature: https://features.opensuse.org/300758

1 0

[New: openFATE 308691] JFractionLab
by fate_noreply＠suse.de 10 Jan '10

10 Jan '10

Feature added by: Jochen Georges (MrGeo) Feature #308691, revision 1 Title: JFractionLab Package Wishlist: Unconfirmed Priority Requester: Neutral Requested by: Jochen Georges (mrgeo) Description: i would like to see JFractionLab in OpenSuSE. http://sourceforge.net/projects/jfractionlab/ :-) -- openSUSE Feature: https://features.opensuse.org/308691

1 0

[openFATE 306476] Install boot entry configurable in kernel git file
by fate_noreply＠suse.de 10 Jan '10

10 Jan '10

Feature changed by: Stefan Dirsch (sndirsch) Feature #306476, revision 18 Title: Install boot entry configurable in kernel git file - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by (sndirsch) + reject date: 2010-01-10 10:12:41 + reject reason: Obviously this has not been implemented for 11.2. Priority Requester: Important Projectmanager: Important + openSUSE-11.3: Evaluation + Priority + Requester: Important + Projectmanager: Important Requested by: Thomas Renninger (trenn) Description: Provide a file in the kernel git which describes an installation boot entry including: - help/description - specific boot parameters - active on which arch The installation image (e.g. DVD) will then provide these specific boot entries to make it easy for: - kernel developers to add critical boot parameters required for specific HW for booting - users by providing a meaningful help at boot loader start up Currently most important settings that are coming to my mind are: - apic=bigsmp (for i386 machines with a lot cores might require that) - disable Kernel Mode Settings -> disable kernel graphics parts which won't work on all HW if set by default soon The idea originally comes from Bernhard Walle. Steffen and myself discussed that already and agreed that it makes sense to do that. On longterm it would be great to get rid of the "Failsafe" Yast boot loader functionality. This would not be necessary anymore then. This currently totally useless and outdated anyway. With the new approach, soon as one successfully booted an entry from the installation image, these boot options will be the default forever (or manually adjusted). Discussion: #1: Stefan Dirsch (sndirsch) (2009-06-22 10:09:05) I think the X' team' would like to get involved here WRT KMS. Also I believe we still want to have a possibility to detect that the user wants to start the Xserver from installation (usually fbdev driver) instead of the apparently broken native X driver. This was boot param 'x11failsafe' in the past. #2: Thomas Renninger (trenn) (2009-06-22 14:27:39) Yeah, in this case we probably need some advise from the X guys which boot params have to be passed, eventually other extra quirks are needed for KMS, no idea. But in general the responsibility and possibilty to generate/modify extra boot entries and with them passing extra kernel boot parameters and a description when to use them should rely in the kernel teams hands and thus the config file should lie in the kernel repo. Coolo, can you set this fate entry a project manager state, so that we can finally work on that at some time, thanks. #3: Stefan Dirsch (sndirsch) (2009-06-22 14:52:39) Probably the modeset option needs to be used for all relevant KMS capable DRM modules, like i915, radeon. Possibily also radeonhd (still to be implemented) and nouveau (in case it's installed, we don't ship it). So something like this: i915.modeset=0, radeon.modeset=0, radeonhd. modeset=0, nouveau.modeset=0. #5: Andreas Jaeger (a_jaeger) (2009-07-10 11:47:39) I'm a bit confused what you want to do here. What advantage will this bring us? #6: Andreas Jaeger (a_jaeger) (2009-07-14 15:13:04) (reply to #5) Just talked with Thomas: The idea is to safe the information about kernel-parameters as part of the kernel package and let the installation get this information from there - instead of hardcoding it in the installation workflow. Also the kernel would provide different options that the developers think make sense. #8: Michal Marek (michal-m) (2009-09-04 13:05:51) Adding such file(s) to git and packaging them in the binary rpms is not a problem, I think this is mainly a feature for installation images build to get the configuration from the kernels and use it when generating the menu. Steffen, what do you think? #9: Thomas Renninger (trenn) (2009-09-04 13:47:04) Yep. Steffen and I already fiddled out a config file format. It's mainly on me to add an example file to our git repo. Steffen then can implement the installation image part. I just did not found the time (and wanted to poke graphics guys about sane KMS kernel boot params to provide which should be most important for 11.2). #10: Stefan Dirsch (sndirsch) (2009-12-12 07:14:04) About KMS integration for openSUSE 11.3 and SLE11-SP1, please see Bug #560438. -- openSUSE Feature: https://features.opensuse.org/306476

1 0

[New: openFATE 308470] Default console IRC Chat pointed to IRC freenode #suse
by fate_noreply＠suse.de 09 Jan '10

09 Jan '10

Feature added by: Lee Matheson (oldcpu) Feature #308470, revision 1 Title: Default console IRC Chat pointed to IRC freenode #suse openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Lee Matheson (oldcpu) Description: Have all fresh openSUSE installs include an already configured console IRC chat program (irssi, weechat or more user friendly text chat program if available) with default config file already setup to point to freenode to IRC#suse. The intent is that if the user finds themselfs stuck in run level 3 (with internet access) with no GUI they will have an option to type the chat program via a single command, and then go to #suse for support. There would need be some design work to ensure this functions, with some way of telling new users this program is available when they find them selves suddently at run level 3 (or at a gui broken run level 5). -- openSUSE Feature: https://features.opensuse.org/308470

1 2

[openFATE 305285] dictionary and DoS attack protection based using log scanning and dynamic firewall ban
by fate_noreply＠suse.de 09 Jan '10

09 Jan '10

Feature changed by: P Linnell (mrdocs) Feature #305285, revision 23 Title: dictionary and DoS attack protection based using log scanning and dynamic firewall ban openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-08-12 11:12:41 reject reason: no volunteer - 14 votes are about the limit not to reject it for all, so I open 11.3 Priority Requester: Important Projectmanager: Desirable openSUSE-11.3: Evaluation Priority Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) Description: Detailed Description For these attackss, usually the application/service will not allow the attacker to break in, however once a malicious password guess or DoS attack is done, baning the connection for some minutes and then an unban time of several minutes is usually enough to stop a network connection being flooded, as well as reducing the likelihood of a successful dictionary attack. The situation goes this way: - attacker starts a password guess - the system detects Y continuous failed attempts to login in the log file of the service - the system issues an iptables action to block the ip for X minutes. - after X minutes, the ip is allowed again - attacker starts a DoS attack - the system detects Y continuous connections without login - the system issues an iptables action to block the ip for X minutes. - after X minutes, the ip is allowed again Scope To provide an extra option in the firewall which allows to select which services to monitor (usually by looking at patterns in the log file ) and block the ip for a configurable interval once a dictionary attack or DoS is suspected. The option could be as well in the service module (or in both) or even in the specific service configuration module. Usually parameters to configure are the patterns and the actions. Also, YaST should tell the user to install the required packages if this option is enabled. To be defined in the scope is how much configurability is needed. If known services will be protected, or if a generic way to define protection for an arbitrary service is desired. Possible Implementation Fail2Ban provices right now most of the functionality. Provides a service that allows to define jails, a jail is a pattern and an action. A service can have more than one jail. For example the patterns for an ssh DoS attack is different than a dictionary attack on the same service, and the ban times may be different. Fail2Ban provides generic functionality not tied to any specific service and comes with predefined patterns and actions for various popular services as sshd, apache2 http authentication and others. http://en.wikipedia.org/wiki/Fail2ban http://www.fail2ban.org YaST would need to write the configuration about which patterns to use depending on the service to protect, or optionally define patterns for unknown services, same with actions, and start or stop the service depending on this functionality being enabled or not. Test Plan Doing serveral failed attempts on the ssh server should block the user for 3 minutes. Simple testcase. User Experience The functionality should be availabe in a clever location (which can be more than one, for example, firewall, services or the specific module), allowing to turn it on with sane defaults (hopefully provide the defaults fail2ban provides). The user can see the blocked attempts in the logs. Dependencies Using the fail2ban approach would require the fail2ban package, which in turns requires python, available in the openSUSE build service from a community user home project. (home:leonardocf) Contingency Plan None, as the functionality was not available before. Relations: - Preventing Brute Force Attacks With Fail2ban On OpenSUSE 10.3 (url: http://www.howtoforge.com/fail2ban_opensuse10.3) Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:50:52) I don't know about the enteprise angle (I need to think), but for the community distro it seems quite a cool feature. #3: Christoph Thiel (cthiel1) (2009-05-26 18:50:09) We won't be able to implement this feature in 11.2 within the YaST teams. Maybe still something for the community? + #5: P Linnell (mrdocs) (2010-01-09 19:20:12) + Denyhosts is a python module running as a daemon available in network: + utilities with similar functionality.I've used it with good success on + several SLES servers and desktops. -- openSUSE Feature: https://features.opensuse.org/305285

1 0

[openFATE 308334] Distribute individual letters across cell width and height (aka 均等割符)
by fate_noreply＠suse.de 08 Jan '10

08 Jan '10

Feature changed by: Kohei Yoshida (kohei_yoshida) Feature #308334, revision 18 Title: Distribute individual letters across cell width and height (aka 均等割符) Requested by: Kohei Yoshida (kohei_yoshida) Description: Distribute letters at equal intervals across cell's width such that the first and last letters are aligned with the left and right edge of the cell, respectively. Also support similar distribution mechanism in a vertical direction. This functionality is also known as Kin-tou Wari-fu (均等割符) in Japanese, and is very common operation among Japanese Excel users. Relations: - i#107467 - Excel import issue with cells with distributed content (url: http://qa.openoffice.org/issues/show_bug.cgi?id=107467) - i#107470 - Request for this feature in the upstream IZ (url: http://qa.openoffice.org/issues/show_bug.cgi?id=107470) Use Case: Sentences in the Japanese language do not normally break at each word unlike most Western languages. The normal justification functionality is therefore useless for the Japanese users. Instead, they typically justify sentences by adjusting spaces between letters, which is what this requested functionality will provide. Discussion: #3: Kohei Yoshida (kohei_yoshida) (2010-01-05 14:22:02) I've started looking into this. #4: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:36:46) Here is the initial hurdle: Calc uses XSL-FO for all text formatting, and fo:text-align specifies the alignment of a text (I assume for both horizontal and vertical directions). The bad news is that, this attribute does not allow a "distributed" alignment, but in order for us to implement this feature, we need that to allow a distributed alignment. Reference: http://www.w3.org/TR/xsl/#text-align #5: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:45:10) (reply to #4) Well, I guess I could use the "justify" alignment and additional flag to specify how the content is justified. The spec allows user-agent- specific justification algorithm, so it's doable without breaking the standard. #6: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:49:15) (reply to #5) And we could perhaps use the 'text-justify' attribute to specify the justification algorithm. See below: http://www.w3.org/TR/1999/WD-i18n-format-19990910/#a5 #7: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:59:37) (reply to #6) This one is the latest spec of the fore-cited: http://www.w3.org/TR/i18n-format/#text-justify + #8: Kohei Yoshida (kohei_yoshida) (2010-01-08 12:39:43) + Ok. Here is how I've decided to store this in ODF. + For both normal justifiation and distributed justification, the style + attribute 'fo:text-align' is saved as 'justify'. Then, for the + distributed justification, an additional style attribute 'csstext3:text- + justify' gets stored with a value of 'distribute'. For the normal + justification, either this value is 'auto', or this attribute won't get + stored at all. + It took me a while to get to this point since OOo's handling of style + attributes and how they are exported to xml are very complex. But I + eventually got it to save and load correctly. -- openSUSE Feature: https://features.opensuse.org/308334

1 0

[openFATE 307882] golf513
by fate_noreply＠suse.de 07 Jan '10

07 Jan '10

Feature added by: Juan De La O (golf513_2001) Feature #307882, revision 1 Title: golf513 openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Juan De La O (golf513_2001) Description: Solo lo que necesito -- openSUSE Feature: https://features.opensuse.org/307882

1 1