April 2012 - openSUSE Features - openSUSE Mailing Lists

[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