February 2018 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 308619] Provide Kwallet integration for Firefox
by fate_noreply＠suse.de 25 Feb '18

25 Feb '18

Feature added by: Jimmy Berry (boombatower) Feature #308619, revision 1 Title: Provide Kwallet integration for Firefox openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Jimmy Berry (boombatower) Description: I have wanted such a feature for sometime and recently discoved https://addons.mozilla.org/en-US/firefox/addon/49357 via identi.ca talk. Since openSUSE 11.2 includes KDE integration for Firefox, I think this would be a great thing to either add/finish/polish or just defaultly include as part of integration. -- openSUSE Feature: https://features.opensuse.org/308619

1 3

[New: openFATE 324890] Allow 'multibuild' to be disabled per project
by fate_noreply＠suse.de 22 Feb '18

22 Feb '18

Feature added by: Ludwig Nussel (lnussel) Feature #324890, revision 1 Title: Allow 'multibuild' to be disabled per project Buildservice: New Priority Requester: Mandatory Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: Following up on https://github.com/openSUSE/open-build-service/issues/3227 filed by Dominique Multibuilds are an interesting concept and I do like it a lot - but it causes a problem for the products using rings. I'll use a package of mine as a practical example (I did not convert it to multibuild yet, knowing of this problem. * libproxy - and libproxy-plugins libproxy lives in ring1 (basic library dependencies) and libproxy-plugins lives in ring2 (full KDE and GNOME extensions on top of libproxy, which uses a plugin model) now, with multibuild, I could not have libproxy builtin ring1 and libproxy:plugins in ring2 - they would only go together. My proposal would be a way to specify ring0/1/2 that multibuild is NOT to be considered (which would easily make for libproxy:plugins not to be built for ring1); but this then still lacks a good idea to ensure libproxy:plugins can be built in ring2 (preferably it would link to ring1/libproxy - we could then add some extra information into the _link to tell it what @BUILD_FLAVOR@ to use for this package -- openSUSE Feature: https://features.opensuse.org/324890

1 1

[New: openFATE 310922] central system user registry
by fate_noreply＠suse.de 12 Feb '18

12 Feb '18

Feature added by: Ludwig Nussel (lnussel) Feature #310922, revision 1 Title: central system user registry openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: Once upon a time all systems users were defined in aaa_base via the default /etc/passwd file. When the uid space below uid 100 got too small a new dynamic range between 100 and 499 was introduced. So nowadays packages dynamically create a user in %pre which gets a random uid in this range. Disadvantage: uids are different on every system. Usually this is not a problem but for programs that export files over the network it is. TV recordings made by VDR for example. useradd has a --preferred-uid option for such cases. It's possible to specify a uid and useradd tries to use it. If it's already taken another one is chosen. Thefore I'd propose to leverage that feature: - introduce a central uid registry for system users, e.g a file in aaa_base - lower SYSTEM_UID_MAX (/etc/login.defs) to e.g. 349 and assign "preferred uids" in the rage 350-499. - change useradd calls in packages to a macro that transparently decides whether a preferred uid needs to be used. Use Case: - two systems running vdr, one for recording, the other one for playback on a TV want to share recordings via nfs. -- openSUSE Feature: https://features.opensuse.org/310922

1 15

[New: openFATE 324968] clean old packages only after the whole repository has been re-built.
by fate_noreply＠suse.de 01 Feb '18

01 Feb '18

Feature added by: Ludwig Nussel (lnussel) Feature #324968, revision 1 Title: clean old packages only after the whole repository has been re-built. Buildservice: New Priority Requester: Desirable Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: following up on https://bugzilla.suse.com/show_bug.cgi?id=482392 When a shared library package changes the soname, the resulting old binary rpms are immediately cleaned up after the new build finishes. This breaks bootstrapping if it hits eg rpm. Proposed solution would be to keep around old packages until the whole project is rebuilt -- openSUSE Feature: https://features.opensuse.org/324968

1 0

[New: openFATE 324966] add mail header to specify role of the notification
by fate_noreply＠suse.de 01 Feb '18

01 Feb '18

Feature added by: Ludwig Nussel (lnussel) Feature #324966, revision 1 Title: add mail header to specify role of the notification Buildservice: New Priority Requester: Desirable Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: following up on https://github.com/openSUSE/open-build-service/issues/4162 when I recieve a email because someone commented on a SR and that email is sent to all members of the opensuse-reviewteam i'd like something in the headers to be different from when I get a email about a comment on a SR that I created / need to review as a maintainer / already commented on. Generally I'd like to pay alot of attention to the second type of comments, where as the first type I like to filter somewhere in my inbox so I can look at them if needed. Example B, currently I see everytime abichecker comments on a maintenance incident, in my case it would be better if I could filter it so I can discard those comments if I didn't create or am not directly involved in the maintenance incident like what happened before I was getting those emails. -- openSUSE Feature: https://features.opensuse.org/324966

1 0

[New: openFATE 324962] allow to lock requests
by fate_noreply＠suse.de 01 Feb '18

01 Feb '18

Feature added by: Ludwig Nussel (lnussel) Feature #324962, revision 1 Title: allow to lock requests Buildservice: New Priority Requester: Desirable Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: in order to avoid developers messing up the state of an almost ready staging project, it would be good to have some kind of lock command so the state of certain requests cannot be modified by anyone except for a specific user/group anymore. Needed especially for * delete requests, as they are handled in a very special way * superseding requests. if a developer supersedes another request, release enginering can't do anything about it anymore Is also of particulare interest for SLE with strict deadlines, more elaborate human reviews that take time and yast auto submits by a CI. -- openSUSE Feature: https://features.opensuse.org/324962

1 0

[New: openFATE 324961] enhance freezelink command
by fate_noreply＠suse.de 01 Feb '18

01 Feb '18

Feature added by: Ludwig Nussel (lnussel) Feature #324961, revision 1 Title: enhance freezelink command Buildservice: New Priority Requester: Desirable Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: In order for the staging tool to avoid handling the frozen link itself, obs needs to provide more api calls * update all entries to current version * update or add only specific entries * create links only with a limited set of packages -- openSUSE Feature: https://features.opensuse.org/324961

1 0