May 2010 - openSUSE Features - openSUSE Mailing Lists

[openFATE 308814] Default repositories to not-autorefresh
by fate_noreply＠suse.de 21 May '10

21 May '10

Feature changed by: Jimmy Berry (boombatower) Feature #308814, revision 5 Title: Default repositories to not-autorefresh openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Jimmy Berry (boombatower) Partner organization: openSUSE.org Description: Due to the extra load time required to refresh repositories on auto- fresh when opening the software manager or any other access to it, I go through all my repositories and disable auto-refresh. It would seem most users would be happier with a quicker load time, since keeping the repositories up-to-date should be done via automatic updates are manual refreshing. As an alternative, perhaps have a auto- refresh after x-days or somethign by default, but everytime it loads is a bit much and having to manually go through change them all is rather annoying. I am open to suggestions, but I feel this can be improved. Business case (Partner benefit): openSUSE.org: Make software management more responsive to users and faster to load, giving a better user experience. Discussion: #1: Stanley Miller (stan_qaz) (2010-02-12 20:35:32) It would be good to figure out a way that you could start the program managment module without the long delay you currently get but turning off the refresh isn't something I'd be in favor of since I want the option to select the latest version of anything available. The current timeout is something like 10 minutes that make it a real pain to come in and out several times when installing/updating stuff. Coming up with a way to keep the repositories automatically updated, possibly daily, would be good enough for me. Anything that could be done to speed the refresh process would also be an improvement. #2: Georg Müller (georgmueller) (2010-02-16 16:35:59) I would disable auto-refresh for static repositories. Once released, oss, non-oss, debug and source do not change anymore. For other repositories, I prefer auto-refresh. If I want to disable auto-refresh, I can do this after adding. + #3: Jimmy Berry (boombatower) (2010-05-21 09:12:32) + The key with the auto-refresh is that even when disabled...the system + updater applet will still refresh them. It seems that the auto-refresh + just triggers it as well when you open the Yast->Software Management + tool which is rather annoying since no one wants to sit there and watch + it update them. + You can also do the zypper refresh and zypper up|dup from command line + to force, but for speed and usability of UI it would be nice to default + to disabled. -- openSUSE Feature: https://features.opensuse.org/308814

1 0

[New: openFATE 308894] Integrate Factory source checkin test in OBS
by fate_noreply＠suse.de 20 May '10

20 May '10

Feature added by: Adrian Schröter (adrianSuSE) Feature #308894, revision 1 Title: Integrate Factory source checkin test in OBS Buildservice: Evaluation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Adrian Schröter (adriansuse) Description: All automatic checks, which validate openSUSE:Factory must get opensourced and should run before a user can create a submit request. This request goes first to Lars for packaging the checks, secondly we need to define a way how to integrate it. -- openSUSE Feature: https://features.opensuse.org/308894

1 1

[openFATE 307506] Improve Factory check-in workflow
by fate_noreply＠suse.de 20 May '10

20 May '10

Feature added by: Adrian Schröter (adrianSuSE) Feature #307506, revision 1 Title: Improve Factory check-in workflow Buildservice: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Stephan Kulow (coolo) Description: We have currently the problem that we do not want to do permanent checkins into Factory project to allow depending packages finish building. But on the other hand, we want to do the review at any point of time and push the new sources into the project at once. We had a discussion about this and this was the results: * Create a concept for requests states, reflecting the currently internal states happen during checkin. Reflecting legal and review states. (AI: Rudi) * Add a functionality to add comments to requests without changing the state. (AI: Klaas/Adrian create xml concept) * Offer a clean server side repository cloning functionality (AI: mls) * osc shall call precheckin.sh on checkin and build (AI: adrian) * internal check_if_valid_source_dir checks must become public (AI: adrian/ro/lrupp) -- openSUSE Feature: https://features.opensuse.org/307506

1 5

[New: openFATE 309572] GUI for reviewing and analysing solver testcases
by fate_noreply＠suse.de 20 May '10

20 May '10

Feature added by: Harald Mueller-Ney (xgonzo) Feature #309572, revision 1 Title: GUI for reviewing and analysing solver testcases Requested by: Harald Mueller-Ney (xgonzo) Description: Given the growing number of community and home repositories in build service, dependencies issues or update issues are more common. YaST and zypper are able to provide solver-testcase which are really good for debugging. While the sheer amound of data as well the complexity of the provide information makes it really hard to decode a solver test case to find the real issue even for experienced users. A GUI tool could provide good support in general and especially by providing "one click" analysis for the most common issues. -- openSUSE Feature: https://features.opensuse.org/309572

1 1

[New: openFATE 309576] Better maintenance of src.rpm changes
by fate_noreply＠suse.de 20 May '10

20 May '10

Feature added by: Michal Vyskocil (mvyskocil) Feature #309576, revision 1 Title: Better maintenance of src.rpm changes Requested by: Michal Vyskocil (mvyskocil) Description: During a SUSE development, we are often using upstream source rpms. The most notable example is jpackage.org - a source of almost every of our Java package. But importing of jpackage.org src.rpm we create a fork of this package and it is not possible to maintain our and future upstream changes. Everything needs to be done manually, which is horribly slow and also error prone apporach. There is a better solution based on patch queues - SUSE changes are considered as a set of patches on top of the upstream sources. This method has many advantages - like sharing of our changes with upstream is piece of cake, updating to the new upstream version is simple - just pop all patches and try to recreate them to newest version. upg is the tool try to smoothly intergrate three different systems into one - osc, git and stg to make this concept easy to use. It manages patches using stg, it is well integrated into BuildService using osc and comes with a few interesting concepts, which will make work with patches more reasonable: * scratches - patches created by simple script - they are never "popped", simply recreated again, so they never failed * heuristics - sometimes patches fails only because PatchXY: number is changed in new upstream version, so upg would be able to fix that * changes - it's a pain for each versioning system, but upg deal with it and try to have them in a good state What is done: upg already exists in very raw version with a basic concept implemented, tested and working (netbeans 6.8 update has been done using this tool). What needs to be done: A public release, implemented configuration system, more heuristics and add more tests than now - yes and also some documentation will be necessary -- openSUSE Feature: https://features.opensuse.org/309576

1 0

[openFATE 307735] "Publish on Build Success" mode
by fate_noreply＠suse.de 20 May '10

20 May '10

Feature changed by: Adrian Schröter (adrianSuSE) Feature #307735, revision 6 Title: "Publish on Build Success" mode Buildservice: Evaluation Priority Requester: Important Projectmanager: Desirable Requested by: Stephan Binner (beineri) Description: It would be good to have a publishing mode which runs only if all packages of a project have built successful (no fail, no expansion errors, no broken) to prevent syncing out of a likely broken/non- installable state. This would be especially useful for automatic upgraded snapshots with a whole chain of interdepending packages. Discussion: #1: Adrian Schröter (adriansuse) (2010-01-22 16:20:31) Should be a "publish only if no fail/broken/expansion errors exist) #2: Adrian Schröter (adriansuse) (2010-02-20 12:11:31) My suggestion is to make it possible via <publish> <enable condition="noerror"> </disable> </publish> setting. #3: Jan Engelhardt (jengelh) (2010-02-20 20:05:40) At the same time, could we have a tunable that publishes packages "every once in a while" (like, X hours), otherwise I am getting no sync for days with large projects. + #4: Adrian Schröter (adriansuse) (2010-05-20 09:09:38) + That feature still needs discussion, moving to 2.5. -- openSUSE Feature: https://features.opensuse.org/307735

1 0

[New: openFATE 309571] Provide standalone tool or yast module to investigate repositories/install sour
by fate_noreply＠suse.de 19 May '10

19 May '10

Feature added by: Harald Mueller-Ney (xgonzo) Feature #309571, revision 1 Title: Provide standalone tool or yast module to investigate repositories/install sour Requested by: Harald Mueller-Ney (xgonzo) Description: The number of respositories is growing more and more. It would very helpful to have an tool enabling review of repositories /install sources not add to the system yet. Ideally such a tool would be helpful to verify if a set of repositories is self contained, meaning satsolver finds a solution if each packages is selected on its own. If dependencies are missing they would be displayed like a yast solver conflict. Use Case: Supporting other not so experienced community members on solver conflicts without need to have the exact same repository setup. -- openSUSE Feature: https://features.opensuse.org/309571

1 0

[New: openFATE 309569] Spice VDI
by fate_noreply＠suse.de 19 May '10

19 May '10

Feature added by: James Fehlig (jfehlig) Feature #309569, revision 1 Title: Spice VDI Requested by: James Fehlig (jfehlig) Partner organization: openSUSE.org Description: Spice is an open remote computing solution, providing client access to remote machine display and devices (e.g., keyboard, mouse, audio). It currently works with an older version of qemu but there has been work to integrate spice in upstream qemu and related projects such as libvirt. Surveying upstream status and getting the various packages working on a current SuSE distro would be an interesting Hackweek project. Business case (Partner benefit): openSUSE.org: Provide users adequate, remote access to virtual machine display and devices. -- openSUSE Feature: https://features.opensuse.org/309569

1 0

[openFATE 307742] Allow adding remote src.rpm via webclient instead of uploading files one by one
by fate_noreply＠suse.de 19 May '10

19 May '10

Feature added by: Pavol Rusnak (prusnak) Feature #307742, revision 1 Title: Allow adding remote src.rpm via webclient instead of uploading files one by one Buildservice: Unconfirmed Priority Requester: Important Requested by: Pavol Rusnak (prusnak) Description: Usecase: When one wants to build chromium in OBS. He has to download src.rpm from http://spot.fedorapeople.org/chromium/F12/chromium-4.0.208.0-0.1.20090910sv… which is 450MB, unpack it and upload via osc. It would be much easier if adding remote file via webclient accepted also src.rpm files. -- openSUSE Feature: https://features.opensuse.org/307742

1 3

[New: openFATE 308755] Auto review and mass approve request call
by fate_noreply＠suse.de 19 May '10

19 May '10

Feature added by: Adrian Schröter (adrianSuSE) Feature #308755, revision 1 Title: Auto review and mass approve request call Buildservice: New Priority Requester: Important Requested by: Adrian Schröter (adriansuse) Description: There should be an api call which approves all requests in new state. This would not affect all requests which are in "review" state. There must be a way to define default reviewers for a project as well. This means that there is always a source reviewer (autobuild team) and a legal reviewer (legal team) by default for openSUSE:Factory for example. This could be implemented via a project attribute. -- openSUSE Feature: https://features.opensuse.org/308755

1 6