October 2009 - openSUSE Features - openSUSE Mailing Lists

[openFate 305099] please have yast do a fsck before attempting to mount existing filesystems
by fate_noreply＠suse.de 28 Jan '15

28 Jan '15

Feature added by: Arvin Schnell <aschnell(a)novell.com> Feature #305099, revision 1, last change by Title: please have yast do a fsck before attempting to mount existing filesystems openSUSE-11.2: New Priority Requester: Important Requested by: Per Jessen <per.jessen(a)enidan.com> Partner organization: openSUSE.org Description: I was doing a new install, but wanted to keep my /home filesystem (JFS). No problem, except that the filesystem wasn't clean and needed an fsck. As far as I can tell, yast didn't do this, so mounting of the /home filesystem failed, which caused the entirely installation process to abend and start over. Discussion: #1: Stefan Hundhammer <sh(a)novell.com> (2008-02-21 06:26:43) I'd really hate to have my 100+ GB ext3 partitions fscked. That takes forever. #2: Per Jessen <per.jessen(a)enidan.com> (2008-02-21 07:15:33) Even when they're clean? It's done on every bootup anyway. See /etc/init.d/boot.localfs #3: Jozef Uhliarik <juhliarik(a)novell.com> (2008-02-21 08:21:41) What is your opinion Thomas? #4: Thomas Fehr <fehr(a)novell.com> (2008-02-21 08:24:13) That would need an feature request, not a bug report. #6: Stephan Kulow <coolo(a)novell.com> (2008-02-21 12:04:27) I think it's not too uncommon that people reinstall their system _because_ the old one had a problem, so dirty file systems may not be too uncommon. #7: Thomas Fehr <fehr(a)novell.com> (2008-02-25 03:00:03) What the customer described happens on JFS, this is an unsupported filesystem exactly for the reason that it behaves quite fundamentally different to most other filesystems. Filesystems like ext3 or reiser simply do their log reply when they are dirty and all is fine. So if you want such things to be added, please specify it as a feature request. Since there needs to be an interactive user interface to the filesystem check program this is in no way a simple change. Or would you prefer for example do a rebuild of reiserfs internal tree as default without asking the user first? Problem is that the questions the filesystem check tools ask the user are quite special and of course totally different for different filesystem types. #8: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2008-07-17 08:13:00) I happen to suffer from this bug too once. I think the bug is not that the installation cleans the disk, but at least say that is not clean instead of crashing (in my case it was an installation where yast thought the disk was mounted but it was not) #9: Arvin Schnell <aschnell(a)novell.com> (2008-07-17 08:22:23) No time for 11.1. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305099

1 9

[openFATE 307255] Less scary yast conflict dialogs
by fate_noreply＠suse.de 23 Jul '14

23 Jul '14

Feature added by: Martin Schlander (cb400f) Feature #307255, revision 1 Title: Less scary yast conflict dialogs openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Martin Schlander (cb400f) Description: The YaST2 sw_single dialog for conflicts, vendor change, architecture change etc. is very scary for many users. The dialog asks the user to select one of usually three offered solutions for each problem without giving much help. This is a cause for many complaints, and contributes to myths of RPM dependency hell still existing today. Zypper on the other hand, does things differently. Zypper will select an action for the user, then informs the user of the changes that will be made, and asks a Yes or No question whether the user wishes to proceed or not. I suggest to implement behaviour similar to zypper in the YaST dialog. However, the old functionality of letting the user select a solution manually for each individual problem should probably be kept, as a "hidden" expert/advanced option in the dialog. -- openSUSE Feature: https://features.opensuse.org/307255

1 10

[openFate 305249] Remove agfa-fonts from openSUSE 11.1
by fate_noreply＠suse.de 22 Jul '14

22 Jul '14

Feature added by: Michael Loeffler <michl(a)novell.com> Feature #305249, revision 1, last change by Title: Remove agfa-fonts from openSUSE 11.1 openSUSE-11.1: Evaluation Priority Requester: Important Requested by: Michael Loeffler <michl(a)novell.com> Partner organization: openSUSE.org Description: As Liberation fonts looking really good meanwhile I propose to replace the proprietary agfa-fonts with the open source fonts for openSUSE 11.1 and future versions. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305249

1 17

[openFATE 306193] Provide download statistics in OBS
by fate_noreply＠suse.de 07 Jul '14

07 Jul '14

Feature added by: Carsten Hoeger (choeger) Feature #306193, revision 1, last change by Title: Provide download statistics in OBS Buildservice: Unconfirmed Priority Requester: Important Requested by: Carsten Hoeger (choeger) Description: It would be great to see how popular the packages are. That's an important feature especially for management people. Use Case: Manager John would like to see whether the investment in providing packages for the community did show any results. Is the community interested at all? Did the last press announcement result in increased download numbers? -- openSUSE Feature: https://features.opensuse.org/306193

1 9

[openFATE 306322] Accessing PDFs from within the help centers
by fate_noreply＠suse.de 15 May '14

15 May '14

Feature added by: Karl Eichwalder (keichwa) Feature #306322, revision 1, last change by Title: Accessing PDFs from within the help centers openSUSE-11.2: New Priority Requester: Mandatory Requested by: Karl Eichwalder (keichwa) Partner organization: openSUSE.org Description: Make PDFs available from within the help centers. For yelp something along these lines works: /usr/share/help/opensuse-startup-pdf_en.document : [Document] DocPath=file:///usr/share/doc/manual/opensuse-startup_en-pdf/opensuse-startup_en.pdf DocType=text/pdf DocLang=en Icon=document2 Categories=System;Core;Translation;Documentation Name=PDF of the openSUSE Startup Guide (en) Name[en]=PDF of the openSUSE Startup Guide (en) DocIdentifier=com.novell.opensuse-startupen DocWeight=0 Business case (Partner benefit): openSUSE.org: User will find documentation... -- openSUSE Feature: https://features.opensuse.org/306322

1 8

[openFATE 306637] Test
by fate_noreply＠suse.de 25 Mar '14

25 Mar '14

Feature added by: Stephen Shaw (decriptor) Feature #306637, revision 1 Title: Test openFATE: Unconfirmed Priority Requester: Important Requested by: Stephen Shaw (decriptor) Description: Test -- openSUSE Feature: https://features.opensuse.org/306637

1 8

[openFATE 307846] Kolab groupware server support by openSUSE
by fate_noreply＠suse.de 20 Nov '13

20 Nov '13

Feature added by: Richard Bos (rbos) Feature #307846, revision 1 Title: Kolab groupware server support by openSUSE openSUSE-11.3: Unconfirmed Priority Requester: Neutral Requested by: Richard Bos (rbos) Description: Kolab (http://kolab.org) is a free and open software groupware solution. It allows seamless support of mixed clients environments (Outlook/KDE/Web). The following functionality is provided by kolab; groupware (free/busy information), email, spam and virus filtering, a webinterface for the system administrator and end user. The web interface can be used to add, modify and remove users, domains, distributions list, shared folders, among other things. Kolab is build from only open source software, and the data it stores is freely available by the end user. This means that if the end user is not satisfied with the provided service delivered by the service provider, the end user can retrieve his or her data and move it to somewhere else. The Kolab groupware server is assembled with postfix, cyrus, amavis, openldap, apache among other open source projects. Due to its design the kolab server supports multiple domains and thousands of end users. Clients that can be used with Kolab groupware server are for example KDE's kontact, horde, MS Outlook in combination with a connector. Kolab for openSUSE has been available for a long time already, but it was always necessary to patch multiple projects to provide all (groupware) functionality. Since September 2009, it is only necessary to extend cyrus with some patches to get the required functionality. Hence in order to have Kolab working on openSUSE cyrus must be patched. The patched cyrus version can be retrieved from the build service. Kolab is it worth to be supported by openSUSE as it is composed of only open source software, it supports thousands of end users, and very unique end users have full control over all their data including their groupware information! -- openSUSE Feature: https://features.opensuse.org/307846

1 21

[openFATE 306960] support update of systems with encrypted physical volumes
by fate_noreply＠suse.de 28 Oct '13

28 Oct '13

Feature added by: Arvin Schnell (aschnell) Feature #306960, revision 1 Title: support update of systems with encrypted physical volumes openSUSE-11.3: New Priority Requester: Mandatory Requested by: Arvin Schnell (aschnell) Description: Since openSUSE 11.2 can install systems with encrypted physical volumes (see fate #305633) openSUSE 11.3 must be able to update such systems. -- openSUSE Feature: https://features.opensuse.org/306960

1 14

[openFATE 307745] Let the admin ("root") download and install untrusted third-party RPMs from known URLs guided via YaST
by fate_noreply＠suse.de 24 Oct '13

24 Oct '13

Feature added by: Johannes Meixner (jsmeix) Feature #307745, revision 1 Title: Let the admin ("root") download and install untrusted third-party RPMs from known URLs guided via YaST openSUSE-11.3: New Priority Requester: Neutral Requested by: Johannes Meixner (jsmeix) Description: I would like to have it evaluated whether or not it is allowed to implement a dialog in YaST which lets the system admin (i.e. "root") download and install untrusted third-party RPMs from known URLs. In any case "root" can download and install any software manually. This reques is about to provide a guided and restricted way for some particular cases. My current use-case are the printer driver packages which are available via OpenPrinting at the Linux Foundation: http://www.openprinting.org/driver_list.cgi where LSB compliant driver RPM packages are available. >From my point of view those packages are on the one hand untrusted third-party RPMs but on the other hand their download location is "well known" which makes those packages "well known third-party packages". I assume that from a strict security point of view any kind of third party software is "strictly forbidden" but I like to propose a more useful way here: The system adminj (i.e. "root") can in any case download and install whatever software he likes. This man invalidate e.g. whatever support contract but it is up to the admin to know what he does. Currently we have no idea at all which third-party printer drivers an admin may download an install on his own. When he has a printer for which there is no driver provided by us, the admin may download whatever driver software from any totally unknown location and install it with any unknown consequences. (E.g. some time ago there was a printer driver from a printer manufacturer where its installation script set setuid root bits on various user application programs to mak it "just work".) Currently we even do not tell the admin about the well known printer driver locations at OpenPrinting. >From my point of view it would be a big improvement when I could implement a dialog in the YaST printer module which shows a very explicite text that this is about untrusted unsupported third-party software. This text would require explicite confirmation by the admin. Then it downloads RPMs only from hardcoded URLs from OpenPrinting and inspects the downloaded RPM whether it overwrites already installed files on the system and if not, it installs it without running any RPM scripts because normal printer drivers do not need to run RPM scripts during installation. If the above conditions are not fulfilled it shows a very explicite warning text and does not install anything. In contrast to now where we leave the admin totally on its own how to get a driver for a printer for which we do not provide a driver, the above described guided and restricted way to download and install drivers via YaST would help both the admin and us because in many cases we could make sure this way that we know at least which third-party driver the admin has installed. Please do not confuse this request with the different request how a third-party (e.g. OpenPrinting or a printer manufacturer) could provide software packages in a way which is in full compliance to our package installation and management tools (i.e. via a repository which provides also updates and so on). This request is meant for third-party RPMs "as is" where the vendor/provider simply does not want (because of whatever reason which is beyond our control) to provide his RPMs in compliance to our package installation and management tools. -- openSUSE Feature: https://features.opensuse.org/307745

1 9

[openFATE 306974] Additional columns in software management
by fate_noreply＠suse.de 03 Sep '13

03 Sep '13

Feature added by: Todd R (TheBlackCat) Feature #306974, revision 1 Title: Additional columns in software management openSUSE-11.2: Unconfirmed Priority Requester: Desirable openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Todd R (theblackcat) Description: It would be nice if there were a few additional columns in the software management interface. One specific column I am interested in would be an architecture column, to show you the architecture of an installed package or the architecture the package would have if you were to install it. The other column would show the repository of the package, either the repository of an installed package or the repository the package would be downloaded from if you were to install it. -- openSUSE Feature: https://features.opensuse.org/306974

1 6