November 2015 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 310712] Constantly usable Factory
by fate_noreply＠suse.de 18 Nov '15

18 Nov '15

Feature added by: Christoph Obexer (cobexer) Feature #310712, revision 1 Title: Constantly usable Factory openSUSE-11.4: Unconfirmed Priority Requester: Mandatory Requested by: Christoph Obexer (cobexer) Partner organization: openSUSE.org Description: I recently read about the Debain CUT project, ( http://cut.debian.net/ (http://cut.debian.net/) , http://kitenet.net/~joey/code/debian/cut/ (http://kitenet.net/~joey/code/debian/cut/) ) looking at the current situation with openSuSE Factory i see that it is dangerous to use, unstable alpha or beta packages come into Factory all the time, while other packages become out of date. The result is a system that is pretty much unusable. Only allowing stable packages to enter Factory would make that a lot better, and if one finds bugs chances are that those bugs aren't already fixed in a newer svn/git snapshot, but are real bugs. This would save a lot of time for testers and developers in dealing with "invalid", or "temporary" bugs. I think that a robust, "stable" Factory would lead to more people using it full time and thus a better quality of the next openSuSE version. I see that this would have negative aspects as well, but i think most devel projects have unstable/testing repositories set up already and those could still contain the snapshots of upcoming versions, testers of those specific projects could use tose repositories then. Doing a release of openSuSE would be easier then too, simply snapshot Factory, and declare it as openSuSE $VERSION. The transition from the current state to a "constantly usable Factory" would be smooth too. And it's also in line with the openSuSE vision, stable rather than bleeding edge. Business case (Partner benefit): openSUSE.org: More users using Factory -> better stability of Factory -> better stability of openSuSE $VERSION -> openSuSE back where it should be - the Linux for professionals. -- openSUSE Feature: https://features.opensuse.org/310712

1 4

[New: openFATE 319862] Provide public Factory:snapshot access or proper Factory:standard build process
by fate_noreply＠suse.de 18 Nov '15

18 Nov '15

Feature added by: Sergey Kondakov (X0F) Feature #319862, revision 1 Title: Provide public Factory:snapshot access or proper Factory:standard build process Buildservice: Unconfirmed Priority Requester: Mandatory Requested by: Sergey Kondakov (x0f) Partner organization: openSUSE.org Description: All OBS repositories are built against Factory:snapshot but it's inaccessible to users, we are forced to use Factory:standard, so any non-Factory package from any repo may fail at any time. There is no non-malicious reason for it and real solution would be ensuring real rolling build process on OBS. But until then, let the people safely use repoes of their choosing ! Details at https://bugzilla.suse.com/show_bug.cgi?id=954697 Moreover, the incompatibility seems artificial and intentional: http://lists.opensuse.org/opensuse-factory/2015-11/msg00374.html I'm not even sure if what is accessible to users is even "standard" or some other non-Factory:snapshot snapshot. It's a mess. -- openSUSE Feature: https://features.opensuse.org/319862

1 1

[openFATE 307735] "Publish on Build Success" mode
by fate_noreply＠suse.de 18 Nov '15

18 Nov '15

Feature changed by: Jimmy Berry (boombatower) Feature #307735, revision 11 Title: "Publish on Build Success" mode Buildservice: Evaluation by engineering manager Priority Requester: Important Projectmanager: Desirable Requested by: Stephan Binner (beineri) Partner organization: openSUSE.org 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. #5: grant k (grantksupport) (2014-06-11 02:44:10) Adrian pointed me here from my own post, https://github.com/openSUSE/open-build-service/issues/702 +1 on this capability to keep critical repos available. + #6: Jimmy Berry (boombatower) (2015-11-18 06:52:50) + Or even one step further. No packages are in flux (ie building). That + can definitely happen with large repositories like KDE updates and such + as I used a lot in the past. Not so much with Tumbleweed. + Perhaps a pre-publish step that checks that package dependendies can be + satisfied which would allow individual packages to require exact + versions if they need them and not when they don't. A bit more granular + control and should still solve the wait until no errors in the original + request. -- openSUSE Feature: https://features.opensuse.org/307735

1 0

[openFATE 313811] Configurable multi-spec file package build mode
by fate_noreply＠suse.de 13 Nov '15

13 Nov '15

Feature changed by: Adrian Schröter (adrianSuSE) Feature #313811, revision 7 Title: Configurable multi-spec file package build mode Buildservice: Evaluation by engineering manager - Milestone: 2.7 + Milestone: 3.0 Priority Requester: Mandatory Projectmanager: Important Requested by: Dr. Werner Fink (wernerfink) Partner organization: openSUSE.org Description: We want to have a functionality to enable multiple spec file builds from one source without the need to create _link's. This should be configurable project wide and per package. Additionally it would be nice to offer an option to build all of them in same build root sequential or even in parallel (Would obsolete texlive-specs-? meta packages). Discussion: #1: Adrian Schröter (adriansuse) (2012-09-07 10:16:43) This can also be used for product building, so we can turn productconverter into a source service. -- openSUSE Feature: https://features.opensuse.org/313811

1 0

[New: openFATE 319702] split unison package in text and GUI part
by fate_noreply＠suse.de 02 Nov '15

02 Nov '15

Feature added by: Oliver Kurz (okurz) Feature #319702, revision 1 Title: split unison package in text and GUI part Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Oliver Kurz (okurz) Partner organization: openSUSE.org Description: split package "unison" into "unison" text only with less dependencies, and "unison-gtk" with GUI and more dependencies. Compare to https://packages.debian.org/search?keywords=unison Reasoning: unison is a file synchronisation tool suitable for non-interactive use, e.g. on servers, NAS, etc. The existing package is pulling in many dependencies, e.g. libgtk, which itself is pulling in more dependencies leading to an additional install of 340 MB (or more). -- openSUSE Feature: https://features.opensuse.org/319702

1 0