April 2012 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 311245] Add a nice slider to resize partition
by fate_noreply＠suse.de 10 Jun '12

10 Jun '12

Feature added by: Roman Bysh (Romanator) Feature #311245, revision 1 Title: Add a nice slider to resize partition openFATE: Unconfirmed Priority Requester: Important Requested by: Roman Bysh (romanator) Partner organization: openSUSE.org Description: I'm requesting that we add a nice slider to resize the partition with visual readout. This way we have two options: 1. Manual slider for resizing partitions 2. Manual text entry for resizing by partition/cylinder -- openSUSE Feature: https://features.opensuse.org/311245

1 14

[New: openFATE 309203] make sure harddrives with 4KiB sectors are handled correctly
by fate_noreply＠suse.de 04 Jun '12

04 Jun '12

Feature added by: John Lombardo (tempusfugit) Feature #309203, revision 1 Title: make sure harddrives with 4KiB sectors are handled correctly openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: John Lombardo (tempusfugit) Description: More and more harddrives with 4KiB physical sectors are showing up in the wild. Partitioned incorrectly starting on the traditional sector 63 these drives exhibit very poor performance. The linux partition toolchain is being updated to handle these drives correctly, make sure to ship up-to-date versions of the tools in question and teach yast to make the best of it. A complete overview of the issue and best practices can be found in this wiki article by kernel hacker Tejun Heo: https://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues -- openSUSE Feature: https://features.opensuse.org/309203

1 2

[New: openFATE 313375] Have zypper clean cached packages intelligently
by fate_noreply＠suse.de 31 May '12

31 May '12

Feature added by: Donovan Cameron (saultdon) Feature #313375, revision 1 Title: Have zypper clean cached packages intelligently openFATE: Unconfirmed Priority Requester: Desirable Requested by: Donovan Cameron (saultdon) Partner organization: openSUSE.org Description: When you tell zypper to clean the cached packages with the command: zypper clean This removes ALL cached packages. Over time, zypper will keep all versions of a package RPM file. This can result in a bloated /var/cache/zypp folder. It would be nice to be able to remove all OLD cached packages and keep the latest one, or even have more functionality like being able to specify how many previous versions (to control rollback ability when using the --force flag). Or if it finds that a package is the only one, just keep it. Pseudo code example: If package is installed then If package names are the same keep the newest version Else if package has no matches do not delete Else package is no longer installed delete cached package -- openSUSE Feature: https://features.opensuse.org/313375

1 3

[New: openFATE 311072] Turn quilt into a noarch package
by fate_noreply＠suse.de 31 May '12

31 May '12

Feature added by: Jean Delvare (jdelvare) Feature #311072, revision 1 Title: Turn quilt into a noarch package Hackweek VI: Unconfirmed Priority Requester: Desirable Requested by: Jean Delvare (jdelvare) Partner organization: openSUSE.org Description: Even though it is mainly made of bash and perl scripts, quilt is currently arch-specific. This is caused by one small helper binary names backup-files. The source code of this small helper binary accounts for about 7.5 % of the total code. The helper could be rewritten in bash, and actually this has been done already. Debian reportedly uses a patch that does exactly this for 4 years now: http://www.mail-archive.com/quilt-dev@nongnu.org/msg01137.html While having this helper in bash rather than binary form certainly has an impact on performance, it should be possible to minimize this impact with some work. Also, virtually every piece of quilt could be rewritten in C for better performance, but performance was hardly the point of quilt in the first place. So, the goal of this hackweek project is to get rid of backup-files in its C form, and convert it to bash. -- openSUSE Feature: https://features.opensuse.org/311072

1 16

[New: openFATE 311174] theme for gnome 3
by fate_noreply＠suse.de 30 May '12

30 May '12

Feature added by: ernesto figueroa (alolinux) Feature #311174, revision 1 Title: theme for gnome 3 openSUSE.org: Unconfirmed Priority Requester: Important Requested by: ernesto figueroa (alolinux) Partner organization: openSUSE.org Description: sonar is a theme for gnome 2.3 oxigen is a theme for kde but no themes for gnome 3 /gnome-shell would be really innovative and make a theme , and have to go in style from 11.4 -- openSUSE Feature: https://features.opensuse.org/311174

1 5

[New: openFATE 313288] Opensuse 12.2 - adopt kernel 3.4
by fate_noreply＠suse.de 28 May '12

28 May '12

Feature added by: Jedi Beeftrix (Jedibeeftrix) Feature #313288, revision 1 Title: Opensuse 12.2 - adopt kernel 3.4 openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Jedi Beeftrix (jedibeeftrix) Partner organization: openSUSE.org Description: Why? Better Btrfs support: http://www.phoronix.com/scan.php?page=news_item&px=MTA1ODY Better Intel graphics support: http://www.phoronix.com/scan.php?page=news_item&px=MTA2MTI Is it possible? Well, 3.3 is due in a weeks time: http://www.phoronix.com/scan.php?page=news_item&px=MTA2NTY And three months is the normal release period for the kernel, which puts it 3.4 at June 10th. This is before the first opensuse 12.2 release candidate: Thursday, 24 May 2012: openSUSE 12.2 Beta Thursday, 14 June 2012: openSUSE 12.2 RC 1 -- openSUSE Feature: https://features.opensuse.org/313288

1 8

[New: openFATE 312880] change QCAD to LibreCAD
by fate_noreply＠suse.de 14 May '12

14 May '12

Feature added by: Jose Soriano (Rallaz) Feature #312880, revision 1 Title: change QCAD to LibreCAD openSUSE 12.1: Unconfirmed Priority Requester: Desirable Package Wishlist: Unconfirmed Priority Requester: Desirable Requested by: Jose Soriano (rallaz) Partner organization: openSUSE.org Description: Remove the very old unmantained QCAD (it requires QT3!!!) and add LibreCAD a mantained port to QT4 http://librecad.org -- openSUSE Feature: https://features.opensuse.org/312880

1 16

[New: openFATE 312839] Creating SLES11 SP1(x86_64) as paravirtualized guest OS with Oracle VM 3.0
by fate_noreply＠suse.de 14 May '12

14 May '12

Feature added by: Chen wu (ericwu_vip) Feature #312839, revision 1 Title: Creating SLES11 SP1(x86_64) as paravirtualized guest OS with Oracle VM 3.0 Hackweek VII: Unconfirmed Priority Requester: Desirable Requested by: Chen wu (ericwu_vip) Partner organization: openSUSE.org Description: Oracle VM 3.0 is the latest release of Oracle's server virtualization and management solution. Currently, SLES does not in the platforms list that supported by Oracle VM 3.0. Hope that support for SLES can be added to OVM 3.0 release notes. -- openSUSE Feature: https://features.opensuse.org/312839

1 2

[New: openFATE 313435] Bring the old Package Finder on opensuse.org
by fate_noreply＠suse.de 10 May '12

10 May '12

Feature added by: gabriel byrne (assas1n) Feature #313435, revision 1 Title: Bring the old Package Finder on opensuse.org openSUSE.org: Unconfirmed Priority Requester: Important Requested by: gabriel byrne (assas1n) Partner organization: openSUSE.org Description: Some time ago, the library or package finder on opensuse.org was changed. The new version is too confusing to use, needing several unncesary clicks here and there. Plus, its a pain trying to find libraries or packages made by common users. Also, the link pointing to those users repositories is gone, making the task of installing user made packages a hasle. -- openSUSE Feature: https://features.opensuse.org/313435

1 1

[New: openFATE 310380] grub2 bootonce or bootnext command
by fate_noreply＠suse.de 09 May '12

09 May '12

Feature added by: Lee Matheson (oldcpu) Feature #310380, revision 1 Title: grub2 bootonce or bootnext command openSUSE-11.4: Unconfirmed Priority Requester: Desirable Requested by: Lee Matheson (oldcpu) Description:  With the possibility of Grub2 being implemented soon as a default boot manager, it would be useful to add to the Grub2 packaging a small script that fully emulates the older grubonce that is provided with openSUSE-11.3 and earlier. The philosophy is from run level 3, or from a desktop that does not support the capability to selectively reboot ONCE (and only ONCE) into another boot partition, one can run a command that allows this one time reboot functionality. This was achieved with the "grubonce" command on openSUSE-11.3 (and earlier) and other distributions (for the older grub version) used perl scripts such as bootnext (on Fedora: http://www.dcheng.members.sonic.net/friends/jspaar/pub/bootnext/ ). There is an example here on openSUSE forums as to the utility of the grubonce command and how it can be applied: http://forums.opensuse.org/english/information-new-users/unreviewed-how-faq… The grub2-reboot command is lacking (in comparison to grubonce) in that it appears it can not be used to generate the re-boot selection menu. Hence I propose a small script/application be provided with openSUSE-11.4 (or 12.0) that functions similar to the scripts proposed in http://forums.opensuse.org/english/information-new-users/unreviewed-how-faq… or as a minium functions with the full capability of the "grubonce" (which grub2-reboot lacks). -- openSUSE Feature: https://features.opensuse.org/310380

1 1

[openFATE 306928] Better integration of YaST webpin client into openSUSE
by fate_noreply＠suse.de 09 May '12

09 May '12

Feature added by: Katarina Machalkova (kmachalkova) Feature #306928, revision 1 Title: Better integration of YaST webpin client into openSUSE Package Wishlist: Unconfirmed Priority Requester: Desirable Requested by: Katarina Machalkova (kmachalkova) Description: <p><a href="http://hedgehogpainter.livejournal.com/#asset-hedgehogpainter-4686">YaST webpin client</a> is done and usable since quite some time already, yet its integration into platform is far from being smooth. openSUSE users have very few chances to learn about it in order to use it. This feature consists of two parts:<ul> <li> Webpin search client will be accessible and launchable from menu entry, added to Qt/Gtk/Ncurses package selectors </li><li> New package yast2-packager-webpin will be splitted off yast2-packager, containing webpin module, client + additional .desktop file </li></ul>The purpose of the latter is not to clutter YaST control centre with too many icons, installed along with yast2-packager (which is in default installation). This way, user will get extra icon only if yast2-packager-webpin</p> -- openSUSE Feature: https://features.opensuse.org/306928

1 5

[openFATE 306624] voting mechanism for membership approval on users.o.o
by fate_noreply＠suse.de 08 May '12

08 May '12

Feature added by: Hendrik Vogelsang (hennevogel) Feature #306624, revision 1 Title: voting mechanism for membership approval on users.o.o Hackweek IV: Unconfirmed Priority Requester: Important Requested by: Hendrik Vogelsang (hennevogel) Description: To be better able to vote on membership approvals the openSUSE board is looking for some ruby hacker willing to implement a voting mechanism in users.opensuse.org. users.o.o is a ruby on rails application. Pepple that want to become openSUSE members fill out an application form in users.o.o. This is then evaluated by the openSUSE board. Each application is voted upon. What is missing in users.o.o is the possiblity to vote on those applications. This would need a couple of things: Each application needs a state attribute with the following content: * New * To be Accepted * Accepted * To be Rejected * Rejected Also the respective listings in the interface are needed. And for each board member an voting field. (+1,0,-1) coupled with a free text field. -- openSUSE Feature: https://features.opensuse.org/306624

1 3

[openFATE 307436] Backup utility
by fate_noreply＠suse.de 07 May '12

07 May '12

Feature added by: Alin M Elena (ealin) Feature #307436, revision 1 Title: Backup utility openFATE: Unconfirmed Priority Requester: Desirable Requested by: Alin M Elena (ealin) Description: Hi, Would be nice if we can have an user backup application by default in kde4. I propose back-in-time http://backintime.le-web.org/ it has both kde4 and gnome interfaces and is relatively simple to use. regards, Alin -- openSUSE Feature: https://features.opensuse.org/307436

1 4

[New: openFATE 309311] GUI for PAM
by fate_noreply＠suse.de 04 May '12

04 May '12

Feature added by: The Liberator (L1B3RAT0R) Feature #309311, revision 1 Title: GUI for PAM openFATE: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Package Wishlist: Unconfirmed Priority Requester: Important Requested by: The Liberator (l1b3rat0r) Description: I would like to see some kind of YAST-like tool for implementing PAM features for all types of logins. As it is now you can attempt unlimited logins via the terminal or a locked KDE screen. If there was a GUI for PAM that allowed the user to set maximum password tries, time-frames that login is allowed, and how long a session can last, then our computers would be much more secure. I have an encrypted hard drive, but once the computer is booted up and the hard drive is decrypted, I have no way of stopping a brute force attack. For the average user, PAM is too complicated to use all its features without reading for hours. This seems like the perfect feature to add to YAST. -- openSUSE Feature: https://features.opensuse.org/309311

1 3

[New: openFATE 309577] auto remove unused dependencies using YaST and zypper
by fate_noreply＠suse.de 26 Apr '12

26 Apr '12

Feature added by: double chou (MargueriteSu) Feature #309577, revision 1 Title: auto remove unused dependencies using YaST and zypper openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: double chou (margueritesu) Description: in Debian, you can apt-get --autoremove if you uninstall a package. in Fedora, you can also find such feature. but YaST, nope, I can't. YaST only automatically install dependencies needed by packages you wanna install, but It does not automatically remove them. So after you tried lots of software to find your need. Your system will be huge and full of useless dependencies. That might cause disk over-usage or security problems. 'Coz users only do system update in the way "zypper dup" instead of " zypper update", so obselete packages that have bugs remain. Nowadays I have to write down dependencies mannually everytime I install softwares. That's boring. -- openSUSE Feature: https://features.opensuse.org/309577

1 4

[New: openFATE 313411] New mechanism to install locale-specific packages
by fate_noreply＠suse.de 21 Apr '12

21 Apr '12

Feature added by: Fuminobu Takeyama (ftake) Feature #313411, revision 1 Title: New mechanism to install locale-specific packages openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Fuminobu Takeyama (ftake) Partner organization: openSUSE.org Description: Some packages shipped with openSUSE are locale-specific packages. These packages are essential for non-English users. Current mechanism to install such packages is YaST's language setting module. However, it has problems like: * All of locale-specific packages are installed. We cannot select part of them. * If we use "zypper inr", other recommended packages are also installed. * It start to install packages suddenly after clicking OK without any messages. We cannot cancel. My feature request is improvement of installation mechanism for these packages. First of all, local-specific packages are classified into two types: * (a) translation * (b) input methods, fonts Since these types have different property each other, I think we should prepare new mechanisms for each type. For (a): A new button "Install translation packages" on the language setting modue A translation package contains transrated messages and it is created for each application or library. Since it is hard to install translations one by one for install packages, we need a special treat. The language setting module should not install automatically after changing locale. It should start to install after this button. If possible, we should support to install such packages for multiple (selected) locales and uninstall (unselected) ones. A new command corresponding to the button above for zypper like: $ zypper install-new-reccomends -t translations or $ zypper install-translations ja Add tags to translation packages like: provides: translation(zh) provides: translation(ja) provides: translation(kr) We should not describe like: provides: translation(zh;ja;kr) because we cannot search from "zypper search". For (b): New patterns that contains locale-specific packages The other type of language-specific packages can be installed relatively easily. Users can understand what packages are provided for the locale which they use. To install all of recommended packages as before, they just install a pattern like locale-ja. Another approach is welcome to fix these problem. How do you think? Related bugs: * https://bugzilla.novell.com/show_bug.cgi?id=722739 * https://bugzilla.novell.com/show_bug.cgi?id=721810 -- openSUSE Feature: https://features.opensuse.org/313411

1 2

[New: openFATE 313412] New mechanism to install locale-specific packages
by fate_noreply＠suse.de 21 Apr '12

21 Apr '12

Feature added by: Fuminobu Takeyama (ftake) Feature #313412, revision 1 Title: New mechanism to install locale-specific packages openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Fuminobu Takeyama (ftake) Partner organization: openSUSE.org Description: Some packages shipped with openSUSE are locale-specific packages. These packages are essential for non-English users. Current mechanism to install such packages is YaST's language setting module. However, it has problems like: * All of locale-specific packages are installed. We cannot select part of them. * If we use "zypper inr", other recommended packages are also installed. * It start to install packages suddenly after clicking OK without any messages. We cannot cancel. My feature request is improvement of installation mechanism for these packages. First of all, local-specific packages are classified into two types: * (a) translation * (b) input methods, fonts Since these types have different property each other, I think we should prepare new mechanisms for each type. For (a): A new button "Install translation packages" on the language setting modue A translation package contains transrated messages and it is created for each application or library. Since it is hard to install translations one by one for install packages, we need a special treat. The language setting module should not install automatically after changing locale. It should start to install after this button. If possible, we should support to install such packages for multiple (selected) locales and uninstall (unselected) ones. A new command corresponding to the button above for zypper like: $ zypper install-new-reccomends -t translations or $ zypper install-translations ja Add tags to translation packages like: provides: translation(zh) provides: translation(ja) provides: translation(kr) We should not describe like: provides: translation(zh;ja;kr) because we cannot search from "zypper search". For (b): New patterns that contains locale-specific packages The other type of language-specific packages can be installed relatively easily. Users can understand what packages are provided for the locale which they use. To install all of recommended packages as before, they just install a pattern like locale-ja. Another approach is welcome to fix these problem. How do you think? Related bugs: * https://bugzilla.novell.com/show_bug.cgi?id=722739 * https://bugzilla.novell.com/show_bug.cgi?id=721810 -- openSUSE Feature: https://features.opensuse.org/313412

1 0

[New: openFATE 313205] Restrict to whole-line comments in CodeMirror spec syntax
by fate_noreply＠suse.de 19 Apr '12

19 Apr '12

Feature added by: Christopher Yeleighton (yecril71pl) Feature #313205, revision 1 Title: Restrict to whole-line comments in CodeMirror spec syntax Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Christopher Yeleighton (yecril71pl) Partner organization: openSUSE.org Description: When you edit an RPM spec (http://rpm.org/) file, the CodeMirror engine (https://static.opensuse.org/hosts/build2.o.o/javascripts/cm2/mode/spec.js?1…) interprets the hash mark (#) as starting a comment and greys out the trailing part of the line. This should happen only when the line starts with the hash mark (#) when trimmed. Test Case: %{lua:print(#"");} Use Case: The hash mark is the length operator in lua (http://rpm.org/wiki/PackagerDocs/RpmLua) . Business case (Partner benefit): openSUSE.org: Even if trailing comments in RPM spec (http://rpm.org/) were supported, their use should be discouraged. -- openSUSE Feature: https://features.opensuse.org/313205

1 2

[openFATE 313143] YaST LDAP client refactor/cleanup
by fate_noreply＠suse.de 19 Apr '12

19 Apr '12

Feature changed by: Jiří Suchomel (jsuchome) Feature #313143, revision 10 Title: YaST LDAP client refactor/cleanup openSUSE Distribution: Unconfirmed Priority Requester: Mandatory Requested by: Ralf Haferkamp (rhafer) Partner organization: openSUSE.org Description: Jiri (jsuchome) an I recently discussed some cleanup work we'd like to see in the YaST ldap-client module. This feature lists the main items we'd like to see reworked to improve the Module: Remove no longer needed UI elements Candidates are: * The TLS/SSL checkbox (sssd has a hard requirement for SSL/TLS) * The "LDAP Version 2" checkbox in the advanced settings. (there is AFAIK no LDAPv2-only Server implementation left) * The "Use LDAP but Disable Login" Radio Button Restrict the UI to handle only really LDAP client related things Currently the UI contains quite some settings which are not strictly related to LDAP client (nss/pam) setup. Over the year ldap-client became a bit of a disposal site for all kinds of LDAP related things, which made the UI a bit hard to understand. We should move some things to YaST modules where make a better fit. This is mostly about the settings currently available in the "Administration Settings" Tab (in "Advanced Configuration") * The Password Policies settings seem to fit better into the ldap- server module which already contains some of this functionality * Default Configuration Objects for other YaST modules (e.g. mail, dns, dhcp). Where possible the need for those special configuration objects should be removed. When a specific service still requires those configuration objects the YaST module for that service should be able to handle those objects it self (we could still offer utils API for that in yast2-ldap/ldap-client). E.g. the user management related object should be configured from inside the yast2-users module. yast2- ldap-server could offer to create default objects during the initial LDAP server setup. * The Home Directories on This Machine checkbox seems to be better suite in the Users module as well. * The rest of the values which go to /etc/sysconfig/ldap could be written by yast2-ldap-servers. We still need to figure out how to setup /etc/sysconfig/ldap on machines which to not run the LDAP Server but need access to those settings. (yast2-mail, -dns-server, -dhcp-server) * Adapt the API: move the LDAP* functions from ldap-client (impact on other modules!) Relations: - related feature (feature/id: 313142) Discussion: #1: Jiří Suchomel (jsuchome) (2012-01-19 10:15:11) 1. Removing TLS/SSL is based on assumption that we configure SSSD only, which is feature 313142. 2. About The "Use LDAP but Disable Login" Radio Button: did we agree on some replacement of it? I cannot remember... #2: Jiří Suchomel (jsuchome) (2012-01-23 16:25:33) Added attachment proposal for simplified first screen (ldap-client- redesign2.png) #3: Jiří Suchomel (jsuchome) (2012-02-21 09:26:08) yast2-ldap-client-2.22.3 only offers SSSD configuration in UI, and the option to turn off TLS/SSL was removed. #5: Jiří Suchomel (jsuchome) (2012-02-21 11:37:45) (reply to #3) yast2-ldap-client-2.22.4 has the password policy configuration removed. Some parts were moved to yast2-ldap-server code (just svn), some other parts need to be added there. I've created a bug report to track it, see bnc#748004. #4: Jiří Suchomel (jsuchome) (2012-02-21 10:26:39) Default Configuration Objects for other YaST modules (e.g. mail, dns, dhcp). Where possible the need for those special configuration objects should be removed. Ralf, do you have any idea where it could/should be removed? Who can decide it? + #6: Jiří Suchomel (jsuchome) (2012-04-19 08:52:07) + OK, I've made most of the required changes in yast2-ldap-client, yast2- + users and yast2-ldap-server. + Ralf, could you take a look at current (Factory) versions of these and + comment what else should be done? I mean mostly UI-wise, that API + transition was not done. -- openSUSE Feature: https://features.opensuse.org/313143

1 0

[openFATE 305394] Move KDE software updates notifications to upstream infrastructure
by fate_noreply＠suse.de 18 Apr '12

18 Apr '12

Feature changed by: Will Stephenson (wstephenson) Feature #305394, revision 49 Title: Move KDE software updates notifications to upstream infrastructure openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 11:29:01 reject reason: out of resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Rejected by Sascha Peilicke (saschpe) reject reason: 11.3 is out for a while, wasn't done Priority Requester: Important openSUSE-11.4: Unconfirmed Priority Requester: Neutral openSUSE Distribution: Done Priority Requester: Desirable Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: Federico Lucifredi (flucifredi) Technical Contact: Stephan Binner (beineri) Partner organization: openSUSE.org Description: As kpackagekit matures, it may be the case that for 11.2 it is mature enough for replacing kupdateapplet. It already implements various aspects of kupdateapplet: * notifications (knotify) using a kded service (which takes care of refreshing too) * single update selection (kpackagekit gui) * uses a upstream client library for communication with PackageKit, which are better than our PackageKit communication code. Scope kpackagekit is meant here only to replace kupdateapplet. There is not relation with YaST here. Open Issues: * tray notification: may require implementing a plasma tray icon * SUSE specific code (smolt, registration, hardware search) * Requires some research how to introduce those extensions in kpackagekit, or move SUSE specific parts out, like another kded service. User experience Should stay the same Dependencies * PackageKit * libpackagekit-qt Contingency Plan In the case kpackagekit is not yet mature enough, the same resources invested now in kupdateapplet can be invested in improving kpackagekit. Otherwise, we can stay with kupdateapplet as a fallback. Relations: - kpackagekit author interview (url: http://polishlinux.org/kde/kpackagekit-interview/) - kpackagekit screenshot (url: http://www.packagekit.org/img/kpk-update.png) Test Case: * new patches should be notified by knotify * user should be able to see update availability * user should be able to see detailed update information, as well as selecting individual updates * user should get informed if the update repositories configuration has a problem * user should be informed of (available) drivers for plugged hardware Business case (Partner benefit): openSUSE.org: Right now software notifications are done using the kupdateapplet, which comes from the opensuse-updater code,(renamed in a non sucessful attept to upstream it). This applet come from a summer of code project, originally done as a zmd client, then evoluted to a zypper client, and now working as a PackageKit client. Sadly, during 10.3 cycle this applet got the feature to select updates individually and other small stuff which turned it into a very complicated piece of code, and started to became a package manager on its own. Later it became the favorite place to plug any kind of notifications, like registration needed, smolt participation, etc, and right now the code is much more complex that it should be (thus taking more maintenance and testing than it should require). This feature has the objective of cleaning up this situation to free resources in this area. With the progress of packagekit and recently, kpackagekit, this should be possible. kpackagekit already implements various of the needed aspects, and therefore it would mean getting rid of in house code for upstream code. Additionally, it would result in a much more consistant user experience as the tools would be similar across distributions. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 14:24:20) Looks like Duncan is in favor of this. Stano? If you guys are comfortable with the change, I am all for it. But remember, priority #1 is dist-upgrade. #5: Duncan Mac-Vicar (dmacvicar) (2009-06-02 18:00:54) I will evaluate this feature later, we don't know the status of KPackageKit, we have the package and Thomas contributed patches, so only the decision to switch or not to switch is important. Feedback from the KDE team about upstream KDE 4.3 would also be useful. #8: Lubos Lunak (llunak) (2010-03-12 11:40:52) Is it written down somewhere what are the requirements for a KUpdateApplet replacement? What is listed here as 'Testcase' looks incomplete to me. I'd personally prefer if KDE stayed away from this strange PackageKit experiment (in my experience most KUpdateApplet problems are in fact PackageKit problems), and in fact there are some plans upstream to have a KDE wrapper API for packaging (basically like PackageKit, but without the overdesigning and sucking). That would also solve the problem of switching to upstream infrastructure, and that's why I'd like to know the openSUSE requirements. The expected timeframe is KDE SC 4.4 or 4.5, i.e. too late for 11.3. #9: Martin Seidler (pistazienfresser) (2010-06-22 22:31:15) Is the proposal not just like the status with Gnome (in 11.2)? If so I would not recomend that (way of) change: I use the PackageKit Software in Gnome now only for notiforcation and not for making updates as I (and seems so - also many other users in the forums) had often problems that seems to be related to that applet (or simply the use of different applets for updating software). #10: Federico Lucifredi (flucifredi) (2010-06-22 22:50:50) (reply to #9) Bugs on the Gnome PK applet should be fixed -- lets make sure they are reported. -- The proposal here, as I understand it, was to bring about coherence with upstream in the KDE space. That is a valid objective, and quality is something that would be addressed as part of any change. No one is rushing. #11: Martin Seidler (pistazienfresser) (2010-06-28 23:29:07) (reply to #10) Sorry if my first comment seems to be so contra. I have only voted neutral and am not sure. If this proposted way would really work it seems to me desirable (if I could understand it at all ;-) ). If it would lead to a stable and easy way to update (without the possibility to add completely new programms) it may be also make sence to give a normal user access to that update tool (again?). But the developers may also look at possible complications or unreported bugs (just seach for "update" and "applet" or something like this in the forums - maybe that indicates more to replacing kupdateapplet than against?): for example (some of the first results of "update" and "applet" - some of 300): http://forums.opensuse.org/get-help-here/applications/441112-updater-applet… http://forums.opensuse.org/get-help-here/applications/440994-kupdater-apple… http://forums.opensuse.org/get-help-here/applications/440391-problem-updati… http://forums.opensuse.org/get-help-here/applications/440082-opensuse-updat… ... #12: Petar Petrov (siminin) (2010-07-02 09:23:55) (reply to #11) I also have problems with kpackagekit. That's why i uninstall packagekit and install kupdateapplet-zypp and the notification works like a charm. That's why i dislike this proposal and vote it down. #15: Duncan Mac-Vicar (dmacvicar) (2011-02-14 10:31:49) (reply to #12) If you have problems, please report concrete bugs. #13: Sascha Peilicke (saschpe) (2010-12-17 09:20:10) Seems like this is done for 11.4 #14: Fahim Murshed (inverbrass) (2011-02-11 19:28:25) Nice #16: Mindaugas Baranauskas (embar-) (2011-02-16 13:48:26) (reply to #14) I have openSUSE 11.4RC1 and the first time I used KpackageKit to install an RPM pakage - it chashed! see https://bugs.kde.org/show_bug.cgi?id=266448 #17: Roger Luedecke (shadowolf7) (2011-06-01 23:07:35) Kpackagekit is not only problematic and inefficient, it is redundant. Remove from 12.1. #18: Jos Poortvliet (jospoortvliet) (2011-06-02 13:42:49) (reply to #17) If we want to have Bretzn and Appstream -> cross-distro app installers, packagekit is crucial. The GUI might be replaced by Bretzn, or augmented - but the underlying tech will have to stay in any case. + #19: Will Stephenson (wstephenson) (2012-04-18 13:16:07) + 'Done' for 12.1 with Apper, modulo bugs... -- openSUSE Feature: https://features.opensuse.org/305394

1 0

[openFATE 305394] Move KDE software updates notifications to upstream infrastructure
by fate_noreply＠suse.de 18 Apr '12

18 Apr '12

Feature changed by: Will Stephenson (wstephenson) Feature #305394, revision 48 Title: Move KDE software updates notifications to upstream infrastructure openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 11:29:01 reject reason: out of resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Rejected by Sascha Peilicke (saschpe) reject reason: 11.3 is out for a while, wasn't done Priority Requester: Important openSUSE-11.4: Unconfirmed Priority Requester: Neutral + openSUSE Distribution: Done + Priority + Requester: Desirable Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: Federico Lucifredi (flucifredi) Technical Contact: Stephan Binner (beineri) Partner organization: openSUSE.org Description: As kpackagekit matures, it may be the case that for 11.2 it is mature enough for replacing kupdateapplet. It already implements various aspects of kupdateapplet: * notifications (knotify) using a kded service (which takes care of refreshing too) * single update selection (kpackagekit gui) * uses a upstream client library for communication with PackageKit, which are better than our PackageKit communication code. Scope kpackagekit is meant here only to replace kupdateapplet. There is not relation with YaST here. Open Issues: * tray notification: may require implementing a plasma tray icon * SUSE specific code (smolt, registration, hardware search) * Requires some research how to introduce those extensions in kpackagekit, or move SUSE specific parts out, like another kded service. User experience Should stay the same Dependencies * PackageKit * libpackagekit-qt Contingency Plan In the case kpackagekit is not yet mature enough, the same resources invested now in kupdateapplet can be invested in improving kpackagekit. Otherwise, we can stay with kupdateapplet as a fallback. Relations: - kpackagekit author interview (url: http://polishlinux.org/kde/kpackagekit-interview/) - kpackagekit screenshot (url: http://www.packagekit.org/img/kpk-update.png) Test Case: * new patches should be notified by knotify * user should be able to see update availability * user should be able to see detailed update information, as well as selecting individual updates * user should get informed if the update repositories configuration has a problem * user should be informed of (available) drivers for plugged hardware Business case (Partner benefit): openSUSE.org: Right now software notifications are done using the kupdateapplet, which comes from the opensuse-updater code,(renamed in a non sucessful attept to upstream it). This applet come from a summer of code project, originally done as a zmd client, then evoluted to a zypper client, and now working as a PackageKit client. Sadly, during 10.3 cycle this applet got the feature to select updates individually and other small stuff which turned it into a very complicated piece of code, and started to became a package manager on its own. Later it became the favorite place to plug any kind of notifications, like registration needed, smolt participation, etc, and right now the code is much more complex that it should be (thus taking more maintenance and testing than it should require). This feature has the objective of cleaning up this situation to free resources in this area. With the progress of packagekit and recently, kpackagekit, this should be possible. kpackagekit already implements various of the needed aspects, and therefore it would mean getting rid of in house code for upstream code. Additionally, it would result in a much more consistant user experience as the tools would be similar across distributions. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 14:24:20) Looks like Duncan is in favor of this. Stano? If you guys are comfortable with the change, I am all for it. But remember, priority #1 is dist-upgrade. #5: Duncan Mac-Vicar (dmacvicar) (2009-06-02 18:00:54) I will evaluate this feature later, we don't know the status of KPackageKit, we have the package and Thomas contributed patches, so only the decision to switch or not to switch is important. Feedback from the KDE team about upstream KDE 4.3 would also be useful. #8: Lubos Lunak (llunak) (2010-03-12 11:40:52) Is it written down somewhere what are the requirements for a KUpdateApplet replacement? What is listed here as 'Testcase' looks incomplete to me. I'd personally prefer if KDE stayed away from this strange PackageKit experiment (in my experience most KUpdateApplet problems are in fact PackageKit problems), and in fact there are some plans upstream to have a KDE wrapper API for packaging (basically like PackageKit, but without the overdesigning and sucking). That would also solve the problem of switching to upstream infrastructure, and that's why I'd like to know the openSUSE requirements. The expected timeframe is KDE SC 4.4 or 4.5, i.e. too late for 11.3. #9: Martin Seidler (pistazienfresser) (2010-06-22 22:31:15) Is the proposal not just like the status with Gnome (in 11.2)? If so I would not recomend that (way of) change: I use the PackageKit Software in Gnome now only for notiforcation and not for making updates as I (and seems so - also many other users in the forums) had often problems that seems to be related to that applet (or simply the use of different applets for updating software). #10: Federico Lucifredi (flucifredi) (2010-06-22 22:50:50) (reply to #9) Bugs on the Gnome PK applet should be fixed -- lets make sure they are reported. -- The proposal here, as I understand it, was to bring about coherence with upstream in the KDE space. That is a valid objective, and quality is something that would be addressed as part of any change. No one is rushing. #11: Martin Seidler (pistazienfresser) (2010-06-28 23:29:07) (reply to #10) Sorry if my first comment seems to be so contra. I have only voted neutral and am not sure. If this proposted way would really work it seems to me desirable (if I could understand it at all ;-) ). If it would lead to a stable and easy way to update (without the possibility to add completely new programms) it may be also make sence to give a normal user access to that update tool (again?). But the developers may also look at possible complications or unreported bugs (just seach for "update" and "applet" or something like this in the forums - maybe that indicates more to replacing kupdateapplet than against?): for example (some of the first results of "update" and "applet" - some of 300): http://forums.opensuse.org/get-help-here/applications/441112-updater-applet… http://forums.opensuse.org/get-help-here/applications/440994-kupdater-apple… http://forums.opensuse.org/get-help-here/applications/440391-problem-updati… http://forums.opensuse.org/get-help-here/applications/440082-opensuse-updat… ... #12: Petar Petrov (siminin) (2010-07-02 09:23:55) (reply to #11) I also have problems with kpackagekit. That's why i uninstall packagekit and install kupdateapplet-zypp and the notification works like a charm. That's why i dislike this proposal and vote it down. #15: Duncan Mac-Vicar (dmacvicar) (2011-02-14 10:31:49) (reply to #12) If you have problems, please report concrete bugs. #13: Sascha Peilicke (saschpe) (2010-12-17 09:20:10) Seems like this is done for 11.4 #14: Fahim Murshed (inverbrass) (2011-02-11 19:28:25) Nice #16: Mindaugas Baranauskas (embar-) (2011-02-16 13:48:26) (reply to #14) I have openSUSE 11.4RC1 and the first time I used KpackageKit to install an RPM pakage - it chashed! see https://bugs.kde.org/show_bug.cgi?id=266448 #17: Roger Luedecke (shadowolf7) (2011-06-01 23:07:35) Kpackagekit is not only problematic and inefficient, it is redundant. Remove from 12.1. #18: Jos Poortvliet (jospoortvliet) (2011-06-02 13:42:49) (reply to #17) If we want to have Bretzn and Appstream -> cross-distro app installers, packagekit is crucial. The GUI might be replaced by Bretzn, or augmented - but the underlying tech will have to stay in any case. -- openSUSE Feature: https://features.opensuse.org/305394

1 0

[New: openFATE 313109] improve http://software.opensuse.org/search, group results, search for content
by fate_noreply＠suse.de 18 Apr '12

18 Apr '12

Feature added by: Joerg Steffens (steffens) Feature #313109, revision 1 Title: improve http://software.opensuse.org/search, group results, search for content openSUSE.org: Unconfirmed Priority Requester: Important Requested by: Joerg Steffens (steffens) Partner organization: openSUSE.org Description: openSUSE ist a good distribution and the openSUSE Build Service is a fantastic tool to build packages for it. However, this solutions would be far more effient, if all the available packages can be found easily. The interface through http://software.opensuse.org/search needs improvment. E.g. searching for libreoffice for openSUSE-12.1 results in more than 80 pages (!), because the search function returns not only the package "libreoffice" but also all packages that contain "libreoffice" as a substring of there name. All found packages are displayed with full information, like repository, package namem package version, description, manual download of i586, x86_64, src, 1-click install, link to OBS Improvements: - optional: distinguish between basic and advanced search - in advanced search - by default, only return exact matches - allow regex based searches (or at least wildcards) - most important: group the search results: * package name * version: repository, more info (OBS, 1-Click install, ...) E.g. * libreoffice * 3.4.2.6-4.2.2 openSUSE:12.1/standard * 3.4.4.3-2.1 LibreOffice:Stable/openSUSE_Tumbleweed * ... * libreoffice-base-drivers-mysql * 3.4.2.6-4.2.2 openSUSE:12.1/standard * 3.4.4.3-2.1 LibreOffice:Stable/openSUSE_Tumbleweed * 3.4.4.3-84.1 LibreOffice:Unstable/openSUSE_12.1 * ... * ... because normaly I'm interessted in installing a package and therefore finding the best repository to add (LibreOffice:Stable sounbd more suitable than LibreOffice:Unstable or home:mytest) I also always liked the package search from Debian http://www.debian.org/distrib/packages, where it is easily possible to search for the content of packages. SUSEs approach to this has always been limited and the search from http://packages.opensuse-community.org/ (webpin) is out of order. The "official" site http://search.opensuse.org/packages/ results in an internal server error. Even as this has worked, some month ago, you had to know the full path of the file you are looking for. A package content based search over the full openSUSE reposiory would be a real benifit that makes ot a lot easier to use OBS in all its power. -- openSUSE Feature: https://features.opensuse.org/313109

1 3

[New: openFATE 310986] Software Search to arrive at most desirable options
by fate_noreply＠suse.de 18 Apr '12

18 Apr '12

Feature added by: Carl Fletcher (caf4926) Feature #310986, revision 1 Title: Software Search to arrive at most desirable options openFATE: Unconfirmed Priority Requester: Important Requested by: Carl Fletcher (caf4926) Partner organization: openSUSE.org Description: Currently the Software Search and or Webpin results in a plethora of choices, most of which are less than desirable. Ideally, search results should First offer the most stable and or suitable packages. For example. If a user comes along and searches for 'VLC' They are offered a host of unstable options. Everyone knows that 'VLC' should come from Packman. If we can't refer directly to Packman, it should be possible to link to a multi-media giuide. I'm going to guess this could be difficult. But it must be possible to flag searches by keywords to redirect to the most likely solution, but with an option to continue to search anyway. Test Case: Open here: http://software.opensuse.org/search and search: vlc Business case (Partner benefit): openSUSE.org: Avoid new user use of unstable or unsuitable repos. We should be directing to the most suitable or most likely suitable solution. At the moment it's very random. -- openSUSE Feature: https://features.opensuse.org/310986

1 14

[openFATE 305881] Add a simple way to access the rpmlint report
by fate_noreply＠suse.de 17 Apr '12

17 Apr '12

Feature added by: Vincent Untz (vuntz) Feature #305881, revision 1, last change by Title: Add a simple way to access the rpmlint report Buildservice: Unconfirmed Priority Requester: Important Requested by: Vincent Untz (vuntz) Description: Right now, to see the rpmlint report of a build, you have to get the complete build log, which can be slow (because it's big). Having a faster way to read the rpmlint report could result in some tools to highlight what should be fixed, and therefore in better packages. -- openSUSE Feature: https://features.opensuse.org/305881

1 6

[openFATE 307621] Provide public interface to submit patchinfos
by fate_noreply＠suse.de 17 Apr '12

17 Apr '12

Feature added by: Dirk Mueller (dirkmueller) Feature #307621, revision 1 Title: Provide public interface to submit patchinfos Buildservice: New Priority Requester: Mandatory Requested by: Dirk Mueller (dirkmueller) Partner organization: openSUSE.org Description: For openSUSE 11.2 it should be possible for external community members to submit maintenance updates. It is already possible to submit the changed packages itself, however the patchinfo file can not be submitted by external members. The feature would be to allow to attach the information needed for a patchinfo file (maybe except for a swampid) to be submitted by an external community member. One possible implementation method would be a new submitrequest type in the buildservice API. Business case (Partner benefit): openSUSE.org: Make use of community members for providing updates -- openSUSE Feature: https://features.opensuse.org/307621

1 3

[openFATE 306849] Drop requests comment have to be public/archived
by fate_noreply＠suse.de 17 Apr '12

17 Apr '12

Feature added by: Stephan Binner (Beineri) Feature #306849, revision 1 Title: Drop requests comment have to be public/archived Buildservice: Unconfirmed Priority Requester: Mandatory Requested by: Stephan Binner (beineri) Description: Comments of accepted drop requests should appear in opensuse-commit mails which inform about the package being dropped. -- openSUSE Feature: https://features.opensuse.org/306849

1 4

[New: openFATE 309852] improve spec file editor in buildservice
by fate_noreply＠suse.de 17 Apr '12

17 Apr '12

Feature added by: Michal Seben (mseben) Feature #309852, revision 1 Title: improve spec file editor in buildservice Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Michal Seben (mseben) Description: if you try to edit spec file in buildservice you get clean,not highlighted text, it would be fine if we have spec editor build in (with auto-completion and syntax higlight) maybe we could use codemirror : http://marijn.haverbeke.nl/codemirror/jstest.html (http://marijn.haverbeke.nl/codemirror/jstest.html) ? -- openSUSE Feature: https://features.opensuse.org/309852

1 9

[New: openFATE 311187] Anonymous source package download from web interface using disturl
by fate_noreply＠suse.de 17 Apr '12

17 Apr '12

Feature added by: Ciaran Farrell (babelworx) Feature #311187, revision 1 Title: Anonymous source package download from web interface using disturl Buildservice: Unconfirmed Priority Requester: Important Requested by: Ciaran Farrell (babelworx) Partner organization: openSUSE.org Description: Using the disturl tag of our rpm package it is possible to find out exactly where the corresponding source for the binary rpm is located. For example, using osc: osc co -r <HASH> <project> <package> will download the exact source code for the binary rpm. However, to use osc a novell.com/buildservice account is necessary. Suggested is a corresponding web interface feature where even anonymous users can download the exact corresponding source to a binary rpm. Business case (Partner benefit): openSUSE.org: To make it easy for anyone with a rpm to quickly and easily download the exact corresponding source code -- openSUSE Feature: https://features.opensuse.org/311187

1 2

[New: openFATE 312279] OBS issuetracker integration
by fate_noreply＠suse.de 17 Apr '12

17 Apr '12

Feature added by: Bernhard Wiedemann (bmwiedemann) Feature #312279, revision 1 Title: OBS issuetracker integration Buildservice: Unconfirmed Priority Requester: Important Requested by: Bernhard Wiedemann (bmwiedemann) Partner organization: openSUSE.org Description: build.opensuse.org webui should display hyperlinks to issue-trackers when seeing e.g. bnc#654321 or fate#345678 mentioned in commit messages. This allows for easier review of submit-requests. There are probably other places/clients where such links can be useful. -- openSUSE Feature: https://features.opensuse.org/312279

1 2

[New: openFATE 310390] webui shall show informations about commits of a package
by fate_noreply＠suse.de 17 Apr '12

17 Apr '12

Feature added by: Adrian Schröter (adrianSuSE) Feature #310390, revision 1 Title: webui shall show informations about commits of a package Buildservice: Candidate Priority Requester: Mandatory Projectmanager: Important Requested by: Adrian Schröter (adriansuse) Developer: (Novell) Description: The webui shows the history of all commits. actions to * view old code * go back to old code * show diffs shall be possible -- openSUSE Feature: https://features.opensuse.org/310390

1 1

[openFATE 306232] Quality Classification Of Projects
by fate_noreply＠suse.de 17 Apr '12

17 Apr '12

Feature added by: Adrian Schröter (adrianSuSE) Feature #306232, revision 1, last change by Title: Quality Classification Of Projects Buildservice: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Adrian Schröter (adriansuse) Description: A Project should get a classification, set by the project owner about the general quality. This classification should have an influence to the software search for the end user (by default he wants stable stuff, but he might also looks for latest snapshots). Possible classifications are: * STABLE -- project is considered to be ready to use for End-Users * TESTING -- project should work from point of developer view, but needs verification * DEVELOPMENT -- project is random state, it might work. * BROKEN -- project is known to be not working atm. -- openSUSE Feature: https://features.opensuse.org/306232

1 8

[openFATE 306517] Read access control to obs projects
by fate_noreply＠suse.de 17 Apr '12

17 Apr '12

Feature changed by: Adrian Schröter (adrianSuSE) Feature #306517, revision 17 Title: Read access control to obs projects Buildservice: Done Milestone: 2.3 Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Scott Bahling (sbahling) Partner organization: openSUSE.org Description: A project owner defines which other projects are granted read access to this project. Let's call the projects with read access the 'reader list' of the project. Only other projects on the reader list are allowed to use sources or build results from this project; repositories share the permissions of their respective projects. Individual users act on behalf of projects. Thus they gain read access either by being member of the project or by being mamber of a project on the reader list. This is needed to manually build packages locally. When a project or a user has no read access, the project will not be visible. Any links seem to be broken, pointing to an inexistent object. Any read access control failures must pretend this, because project names already can reveal upcoming product properties. For the same reason, the reader list must only be accessible to project members. If read access is withdrawn from a project, already built results must no longer be accessible to the now unauthorized projects and their members. So semantically, a cached expanded source link or a built binary 'knows' which other projects have been used for its creation; read access is only granted to the intersection of the reader lists of all these projects at the time of the access. Obviously this can be cached, too, until the read access is updated. The read access is discretionary. This means, if a user has gotten hold of a source or a binary while she had access to it, she has the data on her disk and the obs will not provide means to take it back if read access should be withdrawn. For that reason, a 'which users and projects dos this reader list expand to' function must be provided, to make things obvious and to allow for what-if probes before changing the reader list. For reliable testing of build results, it's desirable to have the result of publishing available even for read access restricted projects. This would simplify and harden testing, giving testers a most end user like experience. For the record, it has been discussed to introduce 'real ACLs', allowing to withdraw access from some individuals or projects before granting access to a superset. It also has been proposed to optionally 'include' the acl from another project. And it has been proposed to add user groups in addition to projects. These three proposals at frist glance seem to simplify administration, but they also increase complexity of the read access and make it quickly obscure and non- obvious. This proposal here tries to keep it short and simple. References: http://wiki.opensuse.org/openSUSE:Build_Service_Concept_ACL#Adding_code_for… Business case (Partner benefit): openSUSE.org: Component vendors and system vendors consider it a significant competitive advantage to hide technical details about upcoming products until the product is publicly released. Thus privacy control is crucial for a self serviced operation of a driver build. Discussion: #1: Adrian Schröter (adriansuse) (2010-02-19 10:56:40) Diserable for our 2.0 release. Mandatory for ISV build. #2: Adrian Schröter (adriansuse) (2010-04-19 09:44:40) (reply to #1) k, LF want to do an extra release just for this feature (1.8). This feature is currently implemented by Martin Moring and Jan-Simon Möller from LinuxFoundation. #3: Adrian Schröter (adriansuse) (2010-04-21 17:22:15) EngManager and Developer is actual "Martin Mohring", but fate does not know him. #4: Adrian Schröter (adriansuse) (2010-09-17 14:47:32) OBS 2.1 will just have the control to protect sources, but not entire projects or binaries. OBS 2.2 is planned to focus on complete read permission handling only. #5: Martin Mohring (martinmohring) (2010-09-20 17:27:12) I am known to openFATE as login martinmohring #6: Martin Mohring (martinmohring) (2010-09-20 17:29:29) Am update on the implementation is available on http://en.opensuse.org/openSUSE:Build_Service_Concept_ACL #7: Adrian Schröter (adriansuse) (2011-04-04 13:32:20) Implementation looks to be complete, except for some last fixme's. + #8: Adrian Schröter (adriansuse) (2012-04-17 09:27:59) + the last fixme's are also solved. + The only issue, which would need improving is that existing projects + can not become hidden. -- openSUSE Feature: https://features.opensuse.org/306517

1 0

[New: openFATE 310489] Improved diff webui interface
by fate_noreply＠suse.de 17 Apr '12

17 Apr '12

Feature added by: Adrian Schröter (adrianSuSE) Feature #310489, revision 1 Title: Improved diff webui interface Buildservice: New Priority Requester: Important Requested by: Adrian Schröter (adriansuse) Description: We want to have an improved interface for showing diffs in the webui. The diff can be between different packages or revisions or from a request. The UI should show only which files have changed (can be done via requesting the md5 sums of files in the merge file list) and offer the user to show the differences between each file. We may want to show the diff between specific files by default (eg files which end with .dsc, .spec, .kiwi or .changes). -- openSUSE Feature: https://features.opensuse.org/310489

1 5

[New: openFATE 310109] 3rd party web site integration support for installing/downloading software from OBS.
by fate_noreply＠suse.de 17 Apr '12

17 Apr '12

Feature added by: Adrian Schröter (adrianSuSE) Feature #310109, revision 1 Title: 3rd party web site integration support for installing/downloading software from OBS. Buildservice: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Adrian Schröter (adriansuse) Description: We lack an easy way to add a link on any 3rd party site for downloading and/or installing a package or software stack from any defined repository. There should be a simple html snippet which either loads a java script based popup or opens a small and easy to use html (without javascript) popup. The popup window should offer to select a base distro (and in best case detect it somehow) and the way for installation: * download rpm/deb * add repository * 1-Click installation via YMP * Pattern installation, if a pattern has been defined on OBS. I think we need different implementations of this snippet, because there are different kind of web designs out there. But having one with javascript popup and one without would be a great start already. The html snippet should contain also a link back to OBS and/or back to the Project in OBS. A html snippet should allow to specify: * Used project and either * * List of packages to show or install step by step or * * A pattern to install AI: adrian, create a more detailed plan in wiki Robert, it would be great to have some mockups how this could look alike -- openSUSE Feature: https://features.opensuse.org/310109

1 5

[openFATE 305907] Support Update Repo Generation
by fate_noreply＠suse.de 17 Apr '12

17 Apr '12

Feature added by: Adrian Schröter (adrianSuSE) Feature #305907, revision 1, last change by Title: Support Update Repo Generation Buildservice: Evaluation Priority Requester: Desirable Projectmanager: Desirable Requested by: Adrian Schröter (adriansuse) Description: The Build Service should offer update repos as repository channel. It is unclear right now, how we will carry in the extra update information texts. This should maybe designed together with a new changelog handling. -- openSUSE Feature: https://features.opensuse.org/305907

1 6

[New: openFATE 311785] release handling (in general and for maintenance incidents in special)
by fate_noreply＠suse.de 17 Apr '12

17 Apr '12

Feature added by: Adrian Schröter (adrianSuSE) Feature #311785, revision 1 Title: release handling (in general and for maintenance incidents in special) Buildservice: New Milestone: 2.3 Priority Requester: Mandatory Requested by: Adrian Schröter (adriansuse) Engineering Manager: (Novell) Technical Contact: (Novell) Partner organization: openSUSE.org Description: We have the need to manage releases in OBS. Releases in this context are entire builds, which can be tested at one place and can be moved afterwards to another place (project and/or repository). We have this need for * Maintenance releases * Factory standard -> snapshot releases * anything else ? The release target shall be defined in the repository defintion of the origin repository. For example <project name="myProject"> ... <repository name="standard"> <path.... <releasetarget project="myProject" repository="snapshot" condition="repositoryfinished|buildsuccessful|manual|maintenance" /> ... The conditions define when the release happens: * repositoryfinished: Always, after the "standard" repository finished, the releasetarget gets updated (may be usefull as "blocked" workaround). * buildsuccessful: Release only when no failed/unresolvable/broken build state exists. * manual: release on manual command by the user. * maintenance: release happens on maintenance_release accept event. The accept is also removing the condition attribute. It can be added again, in case an incident needs to get restarted/re-released. * no condition attribute: do not do anything. it is just kept to define the target (maybe this would be the manual case ?) -- openSUSE Feature: https://features.opensuse.org/311785

1 4

[openFATE 300758] Show unneeded packages
by fate_noreply＠suse.de 11 Apr '12

11 Apr '12

Feature changed by: Cristian Morales Vega (RedDwarf) Feature #300758, revision 141 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-11.3: Done Priority Requester: Desirable Projectmanager: Important Requested by: JP Rosevear (jproseve) Product Manager: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org 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. #40: Tim Edwards (tk83) (2010-01-27 15:46:00) I'd also like to see this, Mandriva added it in a couple of releases ago and it's great. It's really missing in Opensuse #41: Eduard Huguet (eduardhc) (2010-03-02 15:55:43) (reply to #40) Agreed. Being a long time user of both Gentoo and Ubuntu, I was really shocked to discover that zypper was lacking this feature. Even more: when talking about Linux with friends I always make mention of this kind of "autoremove unneeded" option as one of the strong points of Linux package managing systems, as I was really taking for granted that any package manager out there had this feature included... Regards. #42: Rémy Marquis (spyhawk) (2010-05-02 17:13:32) Michael Andres started to implement this feature in Libzypp 7.4, see http://lists.opensuse.org/zypp-devel/2010-04/msg00033.html #45: Robin Knapp (rknapp) (2010-07-14 13:00:55) (reply to #42) --clean-deps works indeed, but what about just showing unneeded packages? It's mentioned in http://en.opensuse.org/Product_highlights#Package_management_with_zypper but I haven't found any information about this feature. #46: Moqi Ba (bamoqi) (2011-07-24 01:37:08) This FATE is marked as done but as of 11.4 "zypper rm -u" doesn't work without a package name. It cannot actively find and remove orphaned package which are auto-installed, like "apt-get autoremove" does. #47: Michael Schröder (mlschroe) (2012-02-13 12:34:53) (reply to #46) True. We can add that for 12.2, but the quality of the result really depends on knowing which packages were selected by the user and which packages were dragged in via dependencies. + #49: Cristian Morales Vega (reddwarf) (2012-04-11 16:06:31) (reply to + #47) + That info is available already through the history, isn't? The only problem + I know of is bnc#679213... that I have no idea if was fixed since the + info is not public :-( #48: Joachim Plack (jplack) (2012-02-13 13:58:53) For images generated in a SLEPOS environment, we would like the to reduce the footprint. So we'd like to find out all packages where last use (per read access time stamp) <= install time. This list we would the transfer back to the image creation server so that the next image gets reduce to what we really need. Btw. removedthe big list of rejected openSUSEs besides the first and last to get a better overview again while keeping the history -- openSUSE Feature: https://features.opensuse.org/300758

1 0

[New: openFATE 310266] APT-Cacher for Opensuse RPM's
by fate_noreply＠suse.de 06 Apr '12

06 Apr '12

Feature added by: Matthew Collinsworth (Avanesov79) Feature #310266, revision 1 Title: APT-Cacher for Opensuse RPM's Package Wishlist: Unconfirmed Priority Requester: Desirable Requested by: Matthew Collinsworth (avanesov79) Partner organization: openSUSE.org Description: Example setup: https://help.ubuntu.com/community/Apt-Cacher-Server Apt-Cacher creates a local repo on demand so it is not nesasary to download the entire repo at once. Clients using it do not need to modify thier repo addresses. The concept works as follows: A server with enough storage is setup with APT-Cacher running on it. The client PC's have a single file added to them telling them to use the APT-Cacher server as a proxy for all repo downloads. When a request is made the server checks to see if it has an up-to-date version of the package requested. If it does it feeds it along, if it doesnt it downloads it and sends it to the requesting client. It keeps the downloaded package in case another client needs it. Business case (Partner benefit): openSUSE.org: Apt-Cacher makes it very easy to establish a local repo on demand without needing to download the entire repo-cache at once. It also requires minimum configuration on the client PC and no reconfiguration of the clients repo sources. -- openSUSE Feature: https://features.opensuse.org/310266

1 7

[New: openFATE 312544] Add ntfs to /etc/filesystems
by fate_noreply＠suse.de 04 Apr '12

04 Apr '12

Feature added by: Christian Wansart (Ctwx) Feature #312544, revision 1 Title: Add ntfs to /etc/filesystems openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Christian Wansart (ctwx) Partner organization: openSUSE.org Description: Hi there, since I still have a ntfs partition to easily share files between Windows and Linux, I had problems mounting the ntfs partition through Dolphin. First I had to add "ntfs" to /etc/filesystems to make it work with Dolphin. However, for me, it is no problem to add this line. But I have a few colleagues with now run openSUSE as well, who have no desire to manually change config files. However, they had to, to get their ntfs partition, in their case an external hard drive, running. I'd really prefer if this line could be added to the /etc/filesystems file. Thank you. -- openSUSE Feature: https://features.opensuse.org/312544

1 3

[openFATE 307727] Do not install Apparmore per default
by fate_noreply＠suse.de 03 Apr '12

03 Apr '12

Feature added by: Carsten Hoeger (choeger) Feature #307727, revision 1 Title: Do not install Apparmore per default openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Carsten Hoeger (choeger) Description: Do not install AppArmor per default. -- openSUSE Feature: https://features.opensuse.org/307727

1 10

[New: openFATE 313343] Gnome as Default Desktop - openSUSE 12.2
by fate_noreply＠suse.de 03 Apr '12

03 Apr '12

Feature added by: Simone Dedo (Templare) Feature #313343, revision 1 Title: Gnome as Default Desktop - openSUSE 12.2 openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Simone Dedo (templare) Partner organization: openSUSE.org Description: Guys, Be honest with yourself, KDE can't be at this moment the default DE of openSUSE, its incomplete, and doesn't work well at all (there is still some crashes on KDE 4.8.1). KDE on Samba cant save documents. Do not remember password if u check the option "Remember password". Kmail is not good as Evolution. Not all is integrated. Firefox isnt well integrated with KDE, Thunderbird too and so on. If Novell choosen some years ago to go with GNOME as default there is a reason for that (and they had right). If we wanna play with an OS, KDE is a good choise, but if we wanna work with an OS, GNOME is the best choise. Please again, fallback to GNOME for openSUSE 12.2, is the right choise for have a stable openSUSE. -- openSUSE Feature: https://features.opensuse.org/313343

1 3

[New: openFATE 313380] openSUSE NET installation - package selection - install only crucial software
by fate_noreply＠suse.de 03 Apr '12

03 Apr '12

Feature added by: user user (AkitaNeru) Feature #313380, revision 1 Title: openSUSE NET installation - package selection - install only crucial software openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: user user (akitaneru) Partner organization: openSUSE.org Description: OpenSuse NET installation ISO have great feature in which you can select which packages to download and install. But i'm not Linux experts so I don't know which packages are 100% crucial for Linux operation and which packages are excess baggage. So if you cloud add a checkBox on screen when you select desktop environment ("Desktop selection"). Which will tell installer that I want only crucial packages which are requited to start openSUSE in selected desktop environment. (no codec, no music players, no video players, no web browsers, no samba, no printers, no office, no command prompt tools for system administration, ...) I can in "Installation settings" screen easily add packages which I need on my PC. -- openSUSE Feature: https://features.opensuse.org/313380

1 0