June 2011 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 312274] Customise generated filename from tar_scm service
by fate_noreply＠suse.de 08 Jun '11

08 Jun '11

Feature added by: Torgny Nyblom (tnyblom) Feature #312274, revision 1 Title: Customise generated filename from tar_scm service Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Torgny Nyblom (tnyblom) Partner organization: openSUSE.org Description: When the tar_scm source service is generating the filename and the versionprefix is used I would like the possibility to customize the format of the generated timestamp and the separator between the version and the timestamp. /Regards Torgny Business case (Partner benefit): openSUSE.org: Currently my personal reason is that the KDE:Unstable:SC repo is using version on the form 4.6.41_YYYYMMMDDD and to be able to use my own packages and have these coexist nicely I need to generate the same version pattern. -- openSUSE Feature: https://features.opensuse.org/312274

1 5

[New: openFATE 311005] Filter by cell colors
by fate_noreply＠suse.de 07 Jun '11

07 Jun '11

Feature added by: Kohei Yoshida (kohei_yoshida) Feature #311005, revision 1 Title: Filter by cell colors Requested by: Kohei Yoshida (kohei_yoshida) Engineering Manager: (Novell) Developer: (Novell) Partner organization: openSUSE.org Description: In Calc, add support for filtering by cell colors. Relations: - original bugzilla report (novell/bugzilla/id: 657380) https://bugzilla.novell.com/show_bug.cgi?id=657380 -- openSUSE Feature: https://features.opensuse.org/311005

1 5

[New: openFATE 312460] port issetugid() syscall to linux
by fate_noreply＠suse.de 06 Jun '11

06 Jun '11

Feature added by: Ludwig Nussel (lnussel) Feature #312460, revision 1 Title: port issetugid() syscall to linux openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: BSD has a issetugid() syscall that allows programs and libraries to reliably determine whether they were started in a setuid context: http://www.manpagez.com/man/2/issetugid/ This or a similar syscall would be valuable on Linux too, especially in the advent of fscaps where the traditional uid != euid check doesn't work anymore. -- openSUSE Feature: https://features.opensuse.org/312460

1 1

[openFATE 305394] Move KDE software updates notifications to upstream infrastructure
by fate_noreply＠suse.de 02 Jun '11

02 Jun '11

Feature changed by: Jos Poortvliet (jospoortvliet) Feature #305394, revision 47 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 Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Technical Contact: (Novell) 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 312463] Add joystick config as optional for yast2-sound
by fate_noreply＠suse.de 02 Jun '11

02 Jun '11

Feature added by: saulo aldighieri moraes (saul0) Feature #312463, revision 1 Title: Add joystick config as optional for yast2-sound openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: saulo aldighieri moraes (saul0) Partner organization: openSUSE.org Description: yast2-sound is very usable for everybody who have a sound-card but when it is installed it add a joystick config option that I think is not useful for most of the users and nowadays most of the sound card dont have joystick input so I think we can separate yast2-sound from joystick. It will reduce the number of option in the yast control panel too. -- openSUSE Feature: https://features.opensuse.org/312463

1 3

[openFATE 305394] Move KDE software updates notifications to upstream infrastructure
by fate_noreply＠suse.de 01 Jun '11

01 Jun '11

Feature changed by: Roger Luedecke (Shadowolf7) Feature #305394, revision 46 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 Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Technical Contact: (Novell) 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. -- openSUSE Feature: https://features.opensuse.org/305394

1 0