January 2010 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 308381] Firefox
by fate_noreply＠suse.de 19 Jan '10

19 Jan '10

Feature added by: Howdy Doody (wye4) Feature #308381, revision 1 Title: Firefox openFATE: Unconfirmed Priority Requester: Important Requested by: Howdy Doody (wye4) Partner organization: openSUSE.org Description: One of the nice features in the past concerning Firefox was the cookie management options and the clearing of private data options. The version of Firefox that comes with Suse 11.2 KDE4.3 doesn't have these options. I have always been a fanatic concerning private data. I was rather surprised to see everything work after a fresh installof Suse 11.2. Congratulations I am really happy with 11.2 KDE4.3. I only had a couple of hiccups. Accessing Kate, Kwrite or any other editor failed when using Dolphin or any file manager as the Super User. Easily fixed by bringing up a terminal and typing "xhost +local:0". I can't take credit for the fix it's been around since Suse 9 or earlier. I don't know how bad I am going to screw up your hard work but Firefox without the afore mentioned options has got to go. I'll try going to 11.1 dvd and stealing the Firefox off it. Actually I'm sure I am not alone in this concern. I understand the reasoning for setting Firefox as the default. I read the minutes. I had to smile about the ie8 under wine wise crack. Hope Konqueror gets it together by 11.3... Business case (Partner benefit): openSUSE.org: Data security and cookie management is obviously a security issue. As I stated before a lot of us set Firefox to delete all the personal data when Firefox is closed. -- openSUSE Feature: https://features.opensuse.org/308381

1 3

[New: openFATE 308850] performance: improved scheduling
by fate_noreply＠suse.de 18 Jan '10

18 Jan '10

Feature added by: Michael Meeks (michael_meeks) Feature #308850, revision 1 Title: performance: improved scheduling Buildservice: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: Currently, the global scheduling of packages appears rather crude. Some annoying things are - just looking at what is 'scheduled' in a single project (eg. Moblin) vs. 'building' - it would be nice to prioritise packages with a larger number of dependencies - at least within that Project. Then - the scheduler can more quickly, get a better overview of what is waiting to be built. Occassionally when we trigger a full re-build, we have bottlenecks that can be as thin as one or two packages; and it is sad to see them competing with some (immensely wide) openSUSE package-set: even though these key packages (which are competing against tens of other openSUSE pkgs), when built might enable ten others to build. Either way - first prioritising by project, to ensure an even balance of building, is perhaps easier than by dependency spread. Of course - perhaps what is there is 'fair' already, but it doesn't (somehow) seem that way; and it is unclear to me that the algorithms have been designed with the use-case of a vast re-build job running constantly in competition to any given task :-) -- openSUSE Feature: https://features.opensuse.org/308850

1 1

[New: openFATE 308849] performance: improved scheduling
by fate_noreply＠suse.de 18 Jan '10

18 Jan '10

Feature added by: Michael Meeks (michael_meeks) Feature #308849, revision 1 Title: performance: improved scheduling Buildservice: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: Currently, the global scheduling of packages appears rather crude. Some annoying things are - just looking at what is 'scheduled' in a single project (eg. Moblin) vs. 'building' - it would be nice to prioritise packages with a larger number of dependencies - at least within that Project. Then - the scheduler can more quickly, get a better overview of what is waiting to be built. Occassionally when we trigger a full re-build, we have bottlenecks that can be as thin as one or two packages; and it is sad to see them competing with some (immensely wide) openSUSE package-set: even though these key packages (which are competing against tens of other openSUSE pkgs), when built might enable ten others to build. Either way - first prioritising by project, to ensure an even balance of building, is perhaps easier than by dependency spread. Of course - perhaps what is there is 'fair' already, but it doesn't (somehow) seem that way; and it is unclear to me that the algorithms have been designed with the use-case of a vast re-build job running constantly in competition to any given task :-) -- openSUSE Feature: https://features.opensuse.org/308849

1 1

[New: openFATE 308848] performance: improved scheduling
by fate_noreply＠suse.de 18 Jan '10

18 Jan '10

Feature added by: Michael Meeks (michael_meeks) Feature #308848, revision 1 Title: performance: improved scheduling Buildservice: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: Currently, the global scheduling of packages appears rather crude. Some annoying things are - just looking at what is 'scheduled' in a single project (eg. Moblin) vs. 'building' - it would be nice to prioritise packages with a larger number of dependencies - at least within that Project. Then - the scheduler can more quickly, get a better overview of what is waiting to be built. Occassionally when we trigger a full re-build, we have bottlenecks that can be as thin as one or two packages; and it is sad to see them competing with some (immensely wide) openSUSE package-set: even though these key packages (which are competing against tens of other openSUSE pkgs), when built might enable ten others to build. Either way - first prioritising by project, to ensure an even balance of building, is perhaps easier than by dependency spread. Of course - perhaps what is there is 'fair' already, but it doesn't (somehow) seem that way; and it is unclear to me that the algorithms have been designed with the use-case of a vast re-build job running constantly in competition to any given task :-) -- openSUSE Feature: https://features.opensuse.org/308848

1 1

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

18 Jan '10

Feature changed by: Michael Löffler (michl19) Feature #300758, revision 114 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 + openSUSE-11.3: Evaluation 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 308834] Synchronized directory change for Dolphin
by fate_noreply＠suse.de 18 Jan '10

18 Jan '10

Feature added by: Frank Scheuer (Lacerta) Feature #308834, revision 1 Title: Synchronized directory change for Dolphin openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Frank Scheuer (lacerta) Description: I have a suggestion for the file manager DOLPHIN . I think it would be a useful extension to give Dolphin a synchronized directory change similar to the same thing in the ftp browser filezilla. If you use the Dolphin directory window in the split mode this could be a niceful supplement. -- openSUSE Feature: https://features.opensuse.org/308834

1 0

[openFATE 120373] Unified Button Labels
by fate_noreply＠suse.de 18 Jan '10

18 Jan '10

Feature changed by: Michael Löffler (michl19) Feature #120373, revision 54 Title: Unified Button Labels openSUSE-10.3: Rejected by Stephan Kulow (coolo) reject date: 2007-07-30 10:43:50 reject reason: not enough resources to do it right Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2009-03-30 09:27:47 reject reason: Did not happen completely in time. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 11:08:56 reject reason: out of resources for 11.2. Priority Requester: Desirable - openSUSE-11.3: New + openSUSE-11.3: Evaluation Priority Requester: Desirable Requested by: Klaus Kämpf (kwk) Description: Unify button labels YaST currently uses several different button labels for basically the same action, i.e. 'Ok', 'Accept', and 'Finish'. Decision: Only a single label per action should be used. Labels should be generally "OK" and "Cancel" for standard modules and "Back", "Next", "Cancel" and "Finish" for wizards. Documentation Impact: check YaST descriptions in manuals and update screen shots Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2006-06-27 11:36:42) I'm moving this from "future" to 10.3. 10.2 will share much with SP1, so we cannot make this kind of change there. Adding Coolo and Edith for usability and YaST, respectively. #2: Tanja Roth (ta-ro) (2007-06-11 16:37:21) This would also have documentation impact - we would have to check the YaST parts of the manuals and to redo a lot of screen shots, I guess. #3: Jiri Srain (jsrain) (2007-07-26 14:27:21) I don't think that we can solve this issue now, this must start being solved at the beginning of release cycle. Please, move to 11.0. #4: Stephan Kulow (coolo) (2007-11-20 11:48:19) the release cycle of 11.0 just started. Please kill Reject and Accept soonish. If I may add here: please do not overuse Ok and Cancel, but rather use explicit actions where appliying. "Do not delete 11 files? Ok/Cancel" is no-go, Delete/Cancel helps the user much more. #5: Jiri Srain (jsrain) (2008-03-10 13:36:56) (reply to #4) I don't think that such cases can be handled a different way than on the per-case basis as bugreports. #6: Jiri Srain (jsrain) (2008-03-10 13:39:16) This is the list of files which contain the Accept or Reject words (probably not complete and probably some of the files are superfluous due to non-perfect regext). Please, get rid of as many as possible of them. ./add-on/src/add-on_proposal.ycp ./add-on/src/inst_language_add-on.ycp ./apparmor/src/include/subdomain/reporting_archived_dialogs.ycp ./apparmor/src/include/subdomain/reporting_utils.ycp ./dhcp-server/src/dns-server-wizard.ycp ./fingerprint-reader/src/users_plugin_fingerprint_reader.ycp ./firewall/src/dialogs.ycp ./firewall/src/subdialogs.ycp ./ftp-server/src/complex.ycp ./ftp-server/src/dialogs.ycp ./inetd/src/dialogs.ycp ./installation/src/clients/inst_network_setup.ycp ./installation/src/clients/inst_proposal.ycp ./kdump/src/dialogs.ycp ./kerberos-client/src/dialogs.ycp ./ldap-client/src/LdapPopup.ycp ./ldap-client/src/ui.ycp ./live-installer/src/inst_live_simple_proposal.ycp ./ncurses-pkg/src/pkg_layout.ycp ./network/src/lan/complex.ycp ./nis-client/src/ui.ycp ./ntp-client/src/dialogs.ycp ./packager/doc/display_driver_popup.ycp ./packager/src/clients/inst_packages.ycp ./packager/src/clients/inst_productsources.ycp ./printer/src/common/dialogs.ycp ./registration/src/modules/Register.ycp ./restore/src/ui.ycp ./runlevel/src/runlevel_proposal.ycp ./samba-server/src/ldap-widget.ycp ./sound/sound/src/complex.ycp ./squid/src/complex.ycp ./storage/storage/src/inst_custom_part.ycp ./storage/storage/src/inst_prepdisk.ycp ./storage/storage/src/modules/StorageControllers.ycp ./system-update/src/system-update.ycp ./tune/hwinfo/src/newid.ycp ./tune/hwinfo/src/system_settings_dialogs.ycp ./update/src/clients/system_update.ycp ./update/src/clients/update.ycp ./update/src/include/rootpart.ycp ./users/src/dialogs.ycp ./users/src/users_plugin_ldap_all.ycp ./users/src/users_plugin_ldap_passwordpolicy.ycp ./users/src/users_plugin_ldap_shadowaccount.ycp ./users/src/users_plugin_quota.ycp ./yast2/library/modules/Label.ycp ./yast2/library/wizard/src/Wizard.ycp ./ycp-ui-bindings/examples/Wizard2.ycp #7: Martin Schmidkunz (mschmidkunz) (2008-03-10 17:18:59) Cool! When we are already touching the navigation buttons maybe we can also try to work out feature #303446 "Button order, positioning, labeling in YaST". Button order should be according to the selected desktop. If another desktop then KDE or GNOME is selected either KDE or GNOME button order should be used. The help button should be aligned left and the navigation buttons should be aligned right. Having too much space between the navigation buttons as we have no doesn't support grouping of buttons, which makes navigation difficult for the user. Labeling should be as stated in this feature. #8: Ladislav Slezak (lslezak) (2008-03-17 16:51:45) Fixed in yast2-sound-2.16.4, yast2-tune-2.16.0 and in yast2-packager- 2.16.27 #9: Arvin Schnell (aschnell) (2008-03-18 17:25:40) Is the decision documented in some style-guide? #10: Martin Schmidkunz (mschmidkunz) (2008-03-19 12:10:05) It is documented in http://en.opensuse.org/Image:Ysg.pdf However this is just a first draft which needs to be approved (FATE: 303041) #11: Jiří Suchomel (jsuchome) (2008-03-26 10:55:07) Done in yast2-ldap-client, yast2-fingerprint-reader, yast2-kerberos- client, yast2-nis-client, yast2-users #12: Jozef Uhliarik (juhliarik) (2008-03-27 10:18:07) Fixed in yast2-kdump-2.16.10, yast2-ftp-server-2.16.10 and in yast2- dhcp-server-2.16.7 #13: Arvin Schnell (aschnell) (2008-03-27 16:40:31) Done for storage. #14: J. Daniel Schmidt (jdsn) (2008-04-01 11:51:50) In case of registration the word "Reject" is used in context of a certificate. The user is asked to "Trust" or "Reject" the certificate. Changing it to "Trust" and "No" or to change the question and switch to "Yes"/"No" is not quite intuitive I think. So I'd keep the word "Reject" for registration. Btw: It will appear never in openSUSE but only during manual installation of a SLE product with registering agains a registration proxy aka. SMT. #15: Katarina Machalkova (kmachalkova) (2008-04-04 10:43:39) And what about installation proposals and installation clients? Are we suppose to substitute word "Accept" by something else there, too? If so, what is the suitable word in such case? Clearly not "Finish" (as it may let user think that it will finish the whole installation), is "OK" the right one then? #16: Martin Schmidkunz (mschmidkunz) (2008-04-04 11:21:54) What about using "Next"? #17: Jiri Srain (jsrain) (2008-04-04 10:51:20) (reply to #16) Next sounds to me like another step in a workflow should follow, which is not this case. I personally prefer simple "OK". #18: Lukas Ocilka (locilka) (2008-04-04 12:25:58) (reply to #17) I personally still prefer "Accept" as it was in the previous YaST Style Guide TM. But "OK" might work too. "Next" is definitely _not_ the right way to go. We have to distinguish between the main workflow and the step-workflows. #19: Martin Schmidkunz (mschmidkunz) (2008-04-04 12:33:28) (reply to #18) Why is it necessary to distinguish between main workflow and steps workflow? To the user it is just one installation process. Just out of curiosity: why is accepting the proposal not considered just another step in the installation workflow? basic settings => accepting proposal => perform installation #20: Lukas Ocilka (locilka) (2008-04-04 12:52:04) (reply to #19) For accepting the installation proposal, I'd even rather use [Install] than anything else. [Accept] has been used there because it's so important decision that in needs emphasizing. #21: Jiri Srain (jsrain) (2008-04-04 11:55:21) (reply to #19) Katarina's question was about the button e.g. in the partitioning dialog, not about the installation proposal as whole (if I understood it correctly). #22: Martin Schmidkunz (mschmidkunz) (2008-04-04 14:19:14) (reply to #21) Sorry for the misunderstanding and thanks for the correction! I suggest to use Cancel/OK as the only two buttons. Reason: the dialogs are side-steps from main installation workflow. I think now I got Lukas' comment about main worklfow and steps- workflow. :-) #23: Katarina Machalkova (kmachalkova) (2008-04-04 17:23:36) (reply to #21) Right, the partitioning dialog (or networking, gfx card, whatever) that is launched from installation proposal. For example, in yast2-network, we use (in the very same dialog) "Finish" on running system, but "Accept" in installation. My q. was whether to substitute the installation client's "Accept" button with something more suitable. #24: Lukas Ocilka (locilka) (2008-04-11 18:23:12) Changing Accept buttons to Install or Update (FATE #120373) >> yast2- installation-2.16.34 #25: Lukas Ocilka (locilka) (2008-04-11 18:45:41) Done in yast2-update-2.16.6 This is definitely going to break something as I can't check every change made... #26: Jiri Srain (jsrain) (2008-04-14 11:40:57) Most of the Accept/Reject buttons are gone now. Let's solve the remaining ones as bugs. #31: Michael Löffler (michl19) (2009-06-09 15:39:44) (reply to #26) Jiri, how much work needs to be done to clean it up by 100%? #27: Martin Schmidkunz (mschmidkunz) (2009-03-18 16:23:14) It is true that the Accept and Reject button labels are removed from the YaST modules. However the button labels are far from being unified. The biggest mess ist the crude mixture of "Cancel" and "Abort" labels and the second issue is the presentation of "Back" buttons which have the same functionality as "Cancel" but are shown in one screen configuration dialogs. The attempt to solve these issues via bugzilla (https://bugzilla.novell.com/show_bug.cgi?id=478089) revealed that this issue seems to aquire some ressources. One main reason for button labeling trouble seems to be that wizard.ycp is used in many places where the dialog is not a wizard, but where it is an overview. To get a professional, consistent GUI and in order to reduce translation efforts and development of new YaST modules one possible solution might be the development of two different templates: * * wizard.ycp for wizards and installation and * * overview.ycp for edit/singe configuration/overview dialogs Some possible layouts can be viewed at: * http://en.opensuse.org/Image:Wizard_dialog.png * http://en.opensuse.org/Image:Overview_dialog.png Buttons could use something like the button box widget developed sh or the button label widget developed by mzugec. As mentioned in the bug, it will take some effort and ressources but I think, that the outcomes will be worth it! #30: Martin Schmidkunz (mschmidkunz) (2009-04-01 15:39:33) The status of button labels in YaST (based on openSUSE 11.1/SLE 11) can be found at: http://en.opensuse.org/Media:Unified_buttons_yast.pdf Some basic numbers: * * 10 different button combinations for overview dialogs * * 5 different button combinations for wizard dialogs * * 3 different button combinations for progress dialogs Suggestions for a unification: * Use Cancel/OK for overview dialogs * Use Cancel/OK and Back/Cancel/Next (Back/Cancel/Finish) for wizards * Cancel for progress dialogs Necessary work for unified buttons in overview dialogs * Cancel/OK is already used in 28 of 78 overview dialogs * 50 overview dialogs which need adjustments (4 x relabeling 2 buttons, 9 x relabeling 1 button, 12 x hide 1 button, 25 x hide 1 Button and relabeling 2 buttons) Necessary work for unified buttons in wizard dialogs * Cancel/OK and Back/Cancel/Next are already used in 23 of 44 overview dialogs * 21 wizard dialogs which need adjustments (20 x relabeling 1 button, 1 x add “Cancel” button) Necessary work for unified buttons in progress dialogs * Cancel is already used in 3 of 46 progress dialogs * All progress dialogs can be easily adjusted by hiding “Back” and “Next” buttons and relabel “Abort” into “Cancel” in progress.ycp Final conclusions/questions * Unified button labels in wizards and progress dialogs can be achieved by just adjusting wizard.ycp and progress.ycp libraries * Overview dialogs need some manual adjustments as they base on wizards. ycp as well * Can adjustments be done by copying code from existing dialogs with OK/Cancel buttons (e.g. Date and Time)? * Does it make sense to invest into an overview.ycp dialog? -- openSUSE Feature: https://features.opensuse.org/120373

1 0

[openFATE 120326] Resume download
by fate_noreply＠suse.de 16 Jan '10

16 Jan '10

Feature changed by: Glenn Doig (doiggl) Feature #120326, revision 95 Title: Resume download openSUSE-10.2: Rejected by Stanislav Visnovsky (visnov) reject date: 2006-09-21 09:56:17 reject reason: Not enough resources to implement in time. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-25 15:20:32 reject reason: Out of time. Postponing. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.0: Rejected by Jiri Srain (jsrain) reject date: 2008-03-28 13:51:03 reject reason: Out of resources for 11.0. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-01 11:34:46 reject reason: Postponing, needs downloading refactor. Priority Requester: Desirable openSUSE-11.2: Rejected by (cthiel1) reject date: 2009-10-27 15:27:57 reject reason: Rejecting, as this will work for some cases (retry inside the same transaction, if it is not aborted yet), but not in general. -ENOTIMELEFT. Priority Requester: Desirable Projectmanager: Desirable Requested by: Klaus Kämpf (kwk) Description: YaST/YOU times out too easy when downloading large packages like kde- base (14 MB) over a single ISDN connection. Please cache the half downloaded package so I don't have to start from the beginning again. See http://bugzilla.novell.com/show_bug.cgi?id=suse9740 (http://bugzilla.novell.com/show_bug.cgi?id=suse9740) http://bugzilla.novell.com/show_bug.cgi?id=278507 (http://bugzilla.novell.com/show_bug.cgi?id=278507) https://bugzilla.novell.com/show_bug.cgi?id=545242 Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2006-06-30 17:40:31) Klaus, do you now whether this is still an issue? #2: Klaus Kämpf (kwk) (2006-06-30 18:38:23) We still have very large packages (kernel, OpenOffice_org) which might not download completely in one go. #5: Milisav Radmanic (radmanic) (2006-09-08 15:25:57) (reply to #4) this applies to the media manager and Jiri already agreed to return this back to the YAST team, since Marius only helped out during CODE 10. Marius will of course help with the implementation, by sharing his knowledge. #7: Stanislav Visnovsky (visnov) (2007-11-23 10:32:46) Related to commit-refactoring. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:21:33) Klaus, are you still running ISDN? just kidding :-) Stano, please your opinion on workload - is this easily achievable? if not, there are hgher priorities. #10: Stanislav Visnovsky (visnov) (2008-06-20 13:10:21) (reply to #9) Jiri, could we get estimate for this? #11: Jiri Srain (jsrain) (2008-08-04 08:59:34) (reply to #10) Since curl itself does support resuming download, then this feature should not be hard to be implemented. #12: Ruchir Brahmbhatt (ruchir) (2009-01-17 12:07:25) I also vote for this feature. #13: Dmitry Mittov (michael_knight) (2009-01-19 09:01:09) It is also a great problem when you use slow mirror. download.opensuse. org redirects me to one of yandex mirrors (score 20). And I have timeout on big packages. #14: Piotrek Juzwiak (benderbendingrodriguez) (2009-01-21 18:17:13) I'd vote at least for a way to change the timeout settings for YaST or it doesn't solve the problem? #15: Alam Aby Bashit (init7) (2009-01-22 09:35:17) I'd like to vote this feature implemented in 11.2. You surely want to have resume capability if you have unreliable yet slow internet connection for say, updating KDE 4.2 :) #16: Duncan Mac-Vicar (dmacvicar) (2009-01-22 15:14:44) (reply to #15) Please stop this "I vote for this" or "+1" or "mee too" comments. There is no voting system in FATE yet, but following a discussion about "I want this too" makes hard to evaluate features. #17: James Mason (bear454) (2009-01-24 06:05:01) Could this be accomplished using a bittorrent backend instead of curl ? #18: Jan Engelhardt (jengelh) (2009-01-30 15:31:33) (reply to #17) ISDN is already slow as it is. I would not want to spend more time downloading just because of the metadata traffic that is going to happen. Not to mention what happens if there are no peers around or they configured themselves to upload-limit themselves. Still, most download.opensuse.org downloads are faster than a torrent for me. #19: Pascal Bleser (pbleser) (2009-03-02 08:42:26) Caching is one thing. But even using retries in curl would help, see "curl --retries". #20: Piotrek Juzwiak (benderbendingrodriguez) (2009-04-23 16:38:17) It could be accomplished by using aria for downloading packages? There would be no more problems with timeouts and bad checksums ? #21: Ján Kupec (jkupec) (2009-04-23 17:36:18) (reply to #20) Actually we are already using aria in current development branch, so this is not so urgent anymore. Still, the download can be interrupted also in other ways than connection timeout, e.g. user decision, sudden power outage, etc... Does anyone know whether aria supports resuming? (Implementing this for the curl backend is not important anymore). #22: Markus K (kamikazow) (2009-04-25 12:49:41) (reply to #21) Yes, aria supports resuming -- even better than wget (don't know about curl), because aria uses the file size to check whether the to-be- downloaded file changed. #23: Peter Poeml (poeml) (2009-04-28 09:14:12) (reply to #21) It does. See section "Resuming Download" in its man page (http://aria2.sourceforge.net/aria2c.1.html#_resuming_download) ; and also note the -c option. #24: T. J. Brumfield (enderandrew) (2009-06-12 23:35:43) Perhaps as an addendum to this feature, I'd like to see the option to set a number of automatic retries. If Yast tells me it needs to download 3 gigs worth of packages, I don't want to watch for one package to timeout, hanging the whole process up. I'd like to configure it so that it will automatically retry the package X times, then skip the package and move on. #25: Michal Papis (mpapis) (2009-07-04 21:14:32) (reply to #24) Good thing would be here to watch network status (maybe by ping'ing the download server each few minutes, and resume download after it is back again. #30: Eduard Avetisyan (dich) (2009-09-15 09:21:41) (reply to #24) In fact, the system should keep on trying to download this particular package, and in the meantime try to download the next package in the list. I've had cases where a single package would fail to download (for unknown reason, since the same URL worked fine in firefox on the same machine), while the rest of the packages went fine. I also find 'curl' less robust and featurefull than 'wget', I wonder why the first was chosen as a backend... #28: Kahenya Kamunyu (kahenya) (2009-08-29 22:03:55) Yup, this should be there. One place Ubuntu kicks openSUSE ass #29: Vincent Petry (pvince81) (2009-09-03 07:24:15) Here in China I also experience timeouts sometimes, even over a regular ADSL connection (512 Mbps). It happens with my home connection as well as at my company's office. Resuming download would definitely be helpful, because sometimes I have to resume the same big package several times before it can finish. #31: Dave Plater (plater) (2009-10-08 13:45:48) It must be so simple to allow aria2c to use it's resume download feature, I don't understand why it hasn't been implemented yet. I've just completed a three day 2.1 gig zypper dup on a beta trial adsl line which caused many failures. The new download in advance feature would have made zypper into a super upgrade package if it wasn't blemished by libzypps inability to resume interupted downloads. I had to use aria2c manually to download two large packages directly into libzypps package cache to complete the upgrade. see https://bugzilla.novell.com/show_bug.cgi?id=545242 unfortunately the bug has been closed due to this feature request but not using aria2c's resume feature spoils an otherwise streamlined zypper + #32: Glenn Doig (doiggl) (2010-01-16 12:39:46) + I see aria2c does have a continue feature. aria2c --help option shows + the following -c, --continue Continue downloading a partially + downloaded file. Use this option to resume a download started by a web + browser or another program which downloads files sequentially from the + beginning. Currently this option is only applicable to http(s)/ftp + downloads. + Possible Values: true,false. Default: false. Tags: basic,ftp,http -- openSUSE Feature: https://features.opensuse.org/120326

1 0

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

16 Jan '10

Feature changed by: Kohei Yoshida (kohei_yoshida) Feature #308334, revision 26 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) - i#53373 - Jusitification issue in Draw/Impress for Japanese text. (url: http://qa.openoffice.org/issues/show_bug.cgi?id=53373) + - OASIS TC JIRA issue for the file format change proposal (url: + http://tools.oasis-open.org/issues/browse/OFFICE-2317) - User-contributed doc on text justification in Japanese text. (url: http://wiki.services.openoffice.org/wiki/User:Foral/Spec/Justification) - i#71067 - RFE: Distributed justification in Draw. (url: http://www.openoffice.org/issues/show_bug.cgi?id=71067) 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. #10: Kohei Yoshida (kohei_yoshida) (2010-01-11 22:20:20) So, I was wrong in thinking that this would be a very simple task. Not at all... Calculating text / char spacing involves at least 3 modules: sc, svx, and vcl. So, while the text attributes themselves originate from sc, the actual drawing of the text is done by svx and vcl. On the bright side, once we implement this feature, it would be trivial to extend this support to Draw and Impress as well, since those two apps simply re-use the same text rendering code. #11: Kohei Yoshida (kohei_yoshida) (2010-01-12 15:38:08) (reply to #10) Finally found where the text justification code is. Luckily fixing this there will automatically fix it for all of Calc/Impress/Draw for the Japanese text processing. #12: Kohei Yoshida (kohei_yoshida) (2010-01-12 16:01:07) (reply to #11) Just fixed i#53373 (http://qa.openoffice.org/issues/show_bug.cgi?id=53373) by accident. #13: Kohei Yoshida (kohei_yoshida) (2010-01-15 09:14:05) Implementation is nearing to a finish. What remains to be done are: 1) formally propose a file format change to ODF TC. At least file a change proposal to JIRA (TC's bug database). 2) work on the xls and xlsx import and export filters, to support the new text alignments. 3) support distributed justification in Impress and Draw. in order or priority. + #14: Kohei Yoshida (kohei_yoshida) (2010-01-15 20:40:03) + Drafted a file format change proposal here: + http://wiki.oasis-open.org/office/text_distributed_justification . + The corresponding JIRA issue is filed here + http://tools.oasis-open.org/issues/browse/OFFICE-2317 . -- openSUSE Feature: https://features.opensuse.org/308334

1 0

[openFATE 302628] Access to encrypted devices/partitons by dongle
by fate_noreply＠suse.de 15 Jan '10

15 Jan '10

Feature changed by: Ludwig Nussel (lnussel) Feature #302628, revision 53 Title: Access to encrypted devices/partitons by dongle openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-03-31 10:53:14 reject reason: too late - and still lacking a real concept behind the full story. Priority Requester: Desirable openSUSE-11.1: Rejected by Stephan Kulow (coolo) reject date: 2008-08-07 16:27:08 reject reason: out of resources. Priority Requester: Desirable - openSUSE-11.2: Candidate + openSUSE-11.2: Done Priority Requester: Desirable Projectmanager: Desirable Requested by: Stefan Fent (sfent) Description: Think of the following scenario: You store your files on an encrypted partition and if you want to access them you just insert your USB stick, flash card or whatever and gain access to your files. Another thought would be to encrypt the whole system and the only possibilty to access it is via dongle. Relations: - FATE#301352: Filesystem encryption using Smartcard certificate (feature/id: 301352) Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2007-10-05 23:04:19) Michele (desktop) / Matthias (storage) what do you think about this? #2: Michael Löffler (michl19) (2008-01-02 18:27:26) Nice to have but I miss a business case. #3: Stephan Kulow (coolo) (2008-01-07 14:42:28) (reply to #2) the business case of such a feature only works if you have a company to sell those dongle sticks I'd say. And those dongle vendors prefer custom boot loaders from those I know. So I don't think a solution with a stick that can be easily copied by dd is preferrable and I would rather reject this. #4: Guy Lunardi (glunardi) (2008-01-18 19:46:42) It's my understanding that Chris' work would allow for this to happen. This would be very neat indeed, we have discussed this with several customers who expressed interest. Using a simple USB key would be one inexpensive way to make this work. One alternative that a customer asked was to have the ability to unlock the data using certificates strored within a smart card. #7: Stephan Kulow (coolo) (2008-06-27 11:23:16) (reply to #4) Chris work? I fail to see the context. #9: Guy Lunardi (glunardi) (2008-07-02 15:27:37) (reply to #7) I do believe that Chris' work would be good for us to leverage however I do not know the details and could be wrong since it has been a few months now since we last talked about this. Chris, would you be able to assist me with provide insights on ways we could address this? #11: Chris Rivera (chrismrivera) (2008-07-06 23:52:49) (reply to #9) If you setup an encrypted home directory with cryptconfig it defaults to creating an encrypted container and a key file. The key file can reside anywhere, including removable media. If you use removable media you need to setup an fstab entry using the device label or device UUID to ensure that the dongle gets mounted automatically and the key file is in the right location. #12: Stephan Kulow (coolo) (2008-08-07 16:26:44) (reply to #11) ok, just talked about with Chris about this feature. We have no resources for yast work any more and the work required seem to be this: "so it would just mean moving the .key file to the media, changing the . key file location in pam_mount.conf, and adding an fstab entry" (quoting Chris). So this would be either put in a README or we wait for SPx. #13: Stephan Kulow (coolo) (2009-03-04 11:39:07) (reply to #12) any objection against opening this to openSUSE.org? #14: Marcus Meissner (msmeissn) (2009-03-04 11:40:59) (reply to #13) no, done #5: Stephan Kulow (coolo) (2008-03-31 10:52:41) I still have no clear picture of what cryptfs setups we're going to support - there are various fate entries about it: e,g, 302981 and 301352. So I would like PM to sort this out - and I personally think it's too late for 11.0. #6: Matthias Eckermann (mge1512) (2008-04-01 01:35:14) In an ideal world we would support: * TPM (incl. fingerprint readers etc.) * Smart Cards * simple devices with key on (USB sticks, memory cards) * passphrase (as today) * (optional) integration with a directory (LDAP, eDirectory, ...) #15: Mario Goppold (mgoppold) (2009-03-29 22:26:03) Hi, because I just need to unlook my root partition via USB stick I have build an rpm for it: http://download.opensuse.org/repositories/home:/mgoppold/openSUSE_11.1/x86_… _SVNr46_luks_key-64.1.x86_64.rpm The main changes are in /lib/mkinitrd/scripts/{setup,boot}-luks.sh and the new /etc/sysconfig/initrd.luks_key. The LUKS-Keyfile should on an Labled or UUIDed USB-Stick. You can unlook all partitions with a master key or define a separate for every luks_device. The approach is certainly not the best but there is no keyscript in /etc/crypttab jet (why not?). #16: Ludwig Nussel (lnussel) (2009-03-30 09:13:46) (reply to #15) mind creating a patch against http://git.opensuse.org/?p=projects/boot.crypto.git;a=summary so I can have a look? I'm not really fond of supporting the keyscript option but since debian now uses that askpass program that I like to integrate we'd basically get keyscript support for free at least wrt boot.crypto. For YaST it would be between hard and impossible to support as one can never know what the keyscript does. #17: Mario Goppold (mgoppold) (2009-03-30 22:14:47) (reply to #16) Have a look at #18: Mario Goppold (mgoppold) (2009-04-01 20:59:06) (reply to #16) I have made some little updates: * There is no need to add /dev/mapper/swap and /dev/mapper/what_else to setup-storage.sh. or /boot/grub/menu.lst * If the key-File is not within the luks-Container there is now a prompt fallback. * I added ext3 and jbd modules to have the Key on ext3 formatted USB- Sticks The new version is Build 77 (http://download.opensuse.org/repositories/home:/mgoppold/openSUSE_11.1/x86_…) #19: Marcus Meissner (msmeissn) (2009-06-24 15:12:33) (reply to #18) Mario, It would really help us if you could provide a patch against the current git state. The patch does not aspply to current :( (Ludwig is not in the office this and next week, will get back in 2 weeks.) #20: Mario Goppold (mgoppold) (2009-08-11 09:38:09) (reply to #19) The new patch against the boot.crypto- 2acb4efc564ca9af8e97162110987289f1206f11.tar.gz from 13.07.2009 is done. You can find it in my OBS: #21: Mario Goppold (mgoppold) (2009-08-11 17:42:20) (reply to #20) Now, it builds on Factory too. #22: Matthias Nagorni (mnagorni) (2009-08-21 13:37:03) (reply to #21) Certainly a nice feature and as I understand it is close to ready. Since I like the innovation and do agree that crypto FS features and the corresponding indentity issues are highly important, I set to "Important". If I had a real business case I would even consider "Mandatory". #24: Stephan Kulow (coolo) (2009-09-03 10:49:40) (reply to #22) Marcus is on vacation this week, so I talked to Ludwig and the feature as it is makes it _possible_ to implement your own keyscript (see #16). This does not make it enterprise ready at all as it's not supported at all by the system beyond that. So please reject for SP1. Perhaps we get a matured version for SLE12. #23: Marcus Meissner (msmeissn) (2009-08-25 11:02:43) (reply to #21) Ludwig, can we proceed? #25: Ludwig Nussel (lnussel) (2009-09-04 12:37:22) I've submitted boot.crypto with support for a debian compatible keyscript option to Factory. passdev.c from debian or an equivalent still needs to be packaged. #26: Marcus Meissner (msmeissn) (2010-01-15 16:21:20) (reply to #25) can we mark it done? + #27: Ludwig Nussel (lnussel) (2010-01-15 16:33:17) (reply to #26) + yes, marking as done. There is no and never will be an option in yast + to configure it. Neither do we have a ready made script. The boot. + crypto infrastructure supports ne necessary hooks for anyone to write + custom unlock methods though. -- openSUSE Feature: https://features.opensuse.org/302628

1 0