July 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305945] get rid of "symsets" in kernel package dependencies
by fate_noreply＠suse.de 01 Mar '10

01 Mar '10

Feature added by: Michal Marek (michal-m) Feature #305945, revision 1, last change by Title: get rid of "symsets" in kernel package dependencies openSUSE-11.2: New Priority Requester: Important Requested by: Michal Marek (michal-m) Description: Currently, the kernel rpm packages group the exported kernel and module symbols in find-provides and provide these "symsets". It has been done this way to reduce the amount of data the solver has to process. It has a number of problems though: * Moving modules around or adding symbols changes the symset checksums, so the rpm build needs symsets of the previous kernel(s) to provide both old and new checksums * changing or removing one unused or unimportant symbol means that each kmp that uses any other symbol from the same symset needs to be rebuilt Now that we have a much better solver, it's time to get rid of this and provide just the individual symbols. I created a test project in the build service: home:michal-m:kill-symsets. which rebuilds all 11.1 kmps against a normal kernel and against a kernel with symsets turned off (this kernel is built in home:michal-m:kill-symsets:changes). The size difference is rather low, total size of all the rpms on i586 and x86_64 increased by about 1.3M, installed size decreased by 2.6M (because of the removed /boot/symsets* files). Size of yum metadata increased by 1.4M. What needs to be done is to make sure that the solver can really handle this fine (-> Michael). I'm waiting for the test repos to appear on download.o.o. -- openSUSE Feature: https://features.opensuse.org/305945

1 17

[openFATE 306781] osc sr should warn if changes are not commited
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Thorsten Kukuk (kukuk) Feature #306781, revision 1 Title: osc sr should warn if changes are not commited Buildservice: New Priority Requester: Important Requested by: Thorsten Kukuk (kukuk) Description: osc submitrequest should warn and wait for confirmation, if the local changes were not submitted to buildserver yet. This would help to avoid the problem, that old packages without changes got submitted to the project. -- openSUSE Feature: https://features.opensuse.org/306781

1 4

[openFATE 306685] devel projects used for a project
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Hendrik Vogelsang (hennevogel) Feature #306685, revision 1 Title: devel projects used for a project Buildservice: Unconfirmed Priority Requester: Important Requested by: Hendrik Vogelsang (hennevogel) Description: To know about the devel projects used for a project one has currently to query all package _meta files. For large projects this is a lot of data. Can we do this serverside somehow? Like write it into the _meta file of the project or something. -- openSUSE Feature: https://features.opensuse.org/306685

1 6

[openFATE 306343] 'Pkgstars' to reward contributors
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Will Stephenson (wstephenson) Feature #306343, revision 1, last change by Title: 'Pkgstars' to reward contributors Buildservice: Unconfirmed Priority Requester: Important Requested by: Will Stephenson (wstephenson) Description: In KDE we use 'dashstars' to reward those who fix build breakages. When a broken build module is fixed, the person responsible for the commit that fixed the build is awarded a 'dashstar', and an IRC bot advertises this in the developer channel with a message such as "JohnDoe fixed kdelibs (64 dashstars)" so the community sees their contribution. In addition, contributors can query their dashstar totals. A similar system for eg package build fixes or package version updates that is visible on the user's opensuse homepage and advertised in community channels (or a weekly summary mail to -project) would be a fun way to reward contributions. -- openSUSE Feature: https://features.opensuse.org/306343

1 2

[openFATE 305930] Don't increase version number if not strictly needed
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Joop Boonen (worldcitizen) Feature #305930, revision 1, last change by Title: Don't increase version number if not strictly needed Buildservice: Unconfirmed Priority Requester: Important Requested by: Joop Boonen (worldcitizen) Description: As I use KDE42 and other newer packages I often do a factory update. I see that the footprint is very big. Because a package gets always rebuild when for instance a dependent library get rebuild. Even if the package is 100% the same it'll gets the same version number. If possible I would like to have binary identical packages yo keep the same version number this reduces bandwidth usage for users/mirrors and it can give people a false feeling that Linux is buggy "as so many packages need to be updated". -- openSUSE Feature: https://features.opensuse.org/305930

1 4

[openFate 305689] Allow creation of meta-repositories
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Magnus Boman (MBoman) Feature #305689, revision 1, last change by Title: Allow creation of meta-repositories Buildservice: Unconfirmed Priority Requester: Important Requested by: Magnus Boman (mboman) Partner organization: openSUSE.org Description: It'd be extremely useful if it was possible to create meta-repositories in OBS. The way it would work, is that anyone could create a project in OBS, and from there, include several other projects to combine them in one meta-repository. It is kind of possible today if one use _links or _aggregate, but that either forces the entire repo to be built in the users own project, or requires a lot of disk space. A meta-repository would basically only create symlinks to the other projects (would not require any extra disk space, nor OBS resources for re-compiling everything in a "new" project) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305689

1 6

[openFate 305693] Versioning for project data
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Martin Mohring (MartinMohring) Feature #305693, revision 1, last change by Title: Versioning for project data Buildservice: Unconfirmed Priority Requester: Mandatory Requested by: Martin Mohring (martinmohring) Partner organization: openSUSE.org Description: Currently, we have versioning of the source files with OBS.Since at least projconf correlates to the sources, it should be versioned to make versioning more of a feature to restore old versions reproducable. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305693

1 3

[openFate 305625] Emphasize my packages in a project maintained by me.
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Pavol Rusnak <prusnak(a)novell.com> Feature #305625, revision 1, last change by Title: Emphasize my packages in a project maintained by me. Buildservice: New Requested by: Pavol Rusnak (prusnak) Partner organization: openSUSE.org Description: When I'm a maintainer of a project and also set as an explicit maintainer of a package inside this project, I'm unable to list of these packages. "My Projects" shows only affected projects and packages outside of these projects. I suggest to show emphasize such packages in Project view (package list) for example by adding icon, or showing the package name in bold. This is especially needed for Contrib repository. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305625

1 3

[openFate 305592] Warn on creating of the package that already exists in BuildService
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Pavol Rusnak <prusnak(a)novell.com> Feature #305592, revision 1, last change by Title: Warn on creating of the package that already exists in BuildService Buildservice: New Priority Requester: Important Requested by: Pavol Rusnak <prusnak(a)novell.com> Partner organization: openSUSE.org Description: http://lists.opensuse.org/opensuse-buildservice/2008-12/msg00056.html * warn on creating of the package that already exists in BuildService (webclient and osc) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305592

1 3

[openFate 305590] Virtual packages and virtual joint projects
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Pavol Rusnak <prusnak(a)novell.com> Feature #305590, revision 1, last change by Title: Virtual packages and virtual joint projects Buildservice: New Priority Requester: Desirable Requested by: Pavol Rusnak <prusnak(a)novell.com> Partner organization: openSUSE.org Description: http://lists.opensuse.org/opensuse-buildservice/2008-12/msg00094.html Virtual packages and virtual joint project would be a special type of projects, that are part of a standard binary repository, but they have no source present in the project. It may have several typical use cases: Virtual dependency packages --------------------------- When a project intents to update a library to a newer version, virtual dependency packages and projects may determine packages that will have broken/changed dependencies after installing of a new library. How it should look. Either package or a project should have a new attribute: "Rebuild parent project packages" Possible values: "ignore": Rebuild only packages in this project and nothing else (just the current behavior) "rebuild broken": Rebuild parent project packages, that cannot be used with newer version any more (it typically happens for package, that require exact version it is built against, or packages that don't follow shared library packaging conventions) "smart rebuild": Rebuild packages that require package or symbol that are no more part of the output of the new package. "all dependencies": Behave just like a single repository and rebuild everything which uses the new in the build. Examples of use for particular values: "rebuild broken": Building some modules require the same version of the base package it was build with. When trying to update base package in a project, it will rebuild all such modules. "smart rebuild": Testing package poppler update: New poppler has a new soname and it requires to rebuild all packages that are linked with poppler. However it is possible to install these packages (and use shared library from the parent project), testing of the new library requires to rebuild these package with the new library). "all dependencies": Testing new core package (bison, gcc). All packages, that have this package in BuildRequires on build system will be rebuilt. Virtual package may become non-virtual. If you need to patch one of the packages to be able to rebuild it in the new repository, you have to link it physically to the joint repository. In this moment, package becomes equal to the normal link package, disabled by default. Virtual/non-virtual joint project --------------------------------- Just now, one can include two different projects, that have a disjunctive packages. Virtual joint project would determine packages that will build differently (or break) in one or another parent repository and rebuild them as a separate repository. Virtual joint project could be a separate project that contains rebuilds of packages in the intersection of both project. Virtual joint project may become non-virtual. If you need to patch one of the packages to be able to rebuild it with both projects included, you have to add it physically to the joint repository. In this moment, the joint project feature would be equal to the normal repository with "Rebuild parent project packages" set. Example: Suppose you have a testing repository of new poppler (different soname) and a multimedia:photo with a new version of GIMP (requires poppler). You can easily include both multimedia:photo and poppler test repositories, but you cannot test new gimp with a new poppler. Creating of virtual joint project will automatically detect these packages and rebuild them. There could be again the tag "Rebuild parent projects packages" with the same values as above. Benefits: Virtual packages: Now they are often substituted by links. Several years later, nobody knows, why such link was created and the link may rot there forever. Virtual joint project: It will allow to test result of a dangerous package check-in without actually doing it. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305590

1 3

[openFate 305595] Show dependencies between packages in repo
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Pavol Rusnak <prusnak(a)novell.com> Feature #305595, revision 1, last change by Title: Show dependencies between packages in repo Buildservice: New Priority Requester: Important Requested by: Pavol Rusnak <prusnak(a)novell.com> Partner organization: openSUSE.org Description: * Show dependencies (Requires, BuildRequires) between packages in repository OBS should provide lists of required packages (runtime and build dependencies) - BuildRequires could be extracted from spec files - it is important to show also reverse dependencies (eg. which packages depend on the package I'm maintaining) - Requires are much harder (will probably need also symbol resolution), but not so desperately needed as BuildRequires -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305595

1 4

[openFATE 305937] Delete Request Mechanism
by fate_noreply＠suse.de 19 Feb '10

19 Feb '10

Feature added by: Adrian Schröter (adrianSuSE) Feature #305937, revision 1, last change by Title: Delete Request Mechanism Buildservice: Evaluation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Adrian Schröter (adriansuse) Description: As part of our PDB migration, we need a mechanism to request a package removal in a project, where no write access exists. Klaas, can you make a proposal how a package (and project ?) removal can look alike ? -- openSUSE Feature: https://features.opensuse.org/305937

1 3

[openFATE 306990] pkgconfig automatic provides / requires
by fate_noreply＠suse.de 12 Feb '10

12 Feb '10

Feature added by: Andrew Jorgensen (ajorgensen) Feature #306990, revision 1 Title: pkgconfig automatic provides / requires openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Andrew Jorgensen (ajorgensen) Description: Integrate macros for automatically determining RPM provides / requires based on pkgconfig for -devel packages. This would consequently automatically determine the dependency chains between -devel packages that use pkgconfig. It would also allow packagers to use the pkgconfig(pkg) string instead of the specific -devel package name. This would make packaging easier both for cross-distro spec files and because when configure complains that a pkgconfig package is missing the packager can immediately add the BuildRequires rather than searching to determine which package contains that .pc file. Fedora and Mandriva both already have this feature. -- openSUSE Feature: https://features.opensuse.org/306990

1 5

[openFATE 306956] Set up feature for wireless card on desktop
by fate_noreply＠suse.de 11 Feb '10

11 Feb '10

Feature added by: Roman Bysh (Romanator) Feature #306956, revision 1 Title: Set up feature for wireless card on desktop openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Roman Bysh (romanator) Description: It would be nice to add a set up feature for the wirless card on the desktop after the installation has finished. -- openSUSE Feature: https://features.opensuse.org/306956

1 4

[openFATE 306940] NX/NeatX remotable desktop sessions
by fate_noreply＠suse.de 11 Feb '10

11 Feb '10

Feature added by: Tin Blaskovic (canobix) Feature #306940, revision 1 Title: NX/NeatX remotable desktop sessions openSUSE-11.2: Unconfirmed Priority Requester: Desirable openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Tin Blaskovic (canobix) Description: Since the NX server (http://www.nomachine.com) libraries are GPL-ed, there is now a Google project Neatx (http://code.google.com/p/neatx/) that provides a free clean and stable NX server implementation. Together with FreeNX client libraries and a standalone client (http://svn.berlios.de/svnroot/repos/freenx/trunk/freenx-client/nxcl/) , all the components are now available for adding out-of-the-box support for a remotely usable personal Linux desktop. Right now it can be achieved by manually loging into a failsafe X session and starting an NX session to a local server. That session can then be detached and resumed remotely, exhibiting the characteristics (including the speed) comparable to, if not better, than an MS windows terminal (remote desktop) session. It would be handy if creating a "remotable" session that works as described above would be automated and could be chosen from the login screen, so in addition to "KDE", "GNOME", "Failsafe" and other session types, there would be a "KDE remotable","GNOME remotable" or similar types of sessions. Since many of business users still primarily work at their desktops, this would enable them to more easily work remotely, as well as bring Linux desktop features on par with that from the Windows world. -- openSUSE Feature: https://features.opensuse.org/306940

1 3

[openFATE 306933] Integrate Social Desktop into our Desktop
by fate_noreply＠suse.de 10 Feb '10

10 Feb '10

Feature added by: Michael Löffler (michl19) Feature #306933, revision 1 Title: Integrate Social Desktop into our Desktop openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Michael Löffler (michl19) Description: Social interaction between people becomes more important than ever. Communicating over the Internet via mails, forums and internet platforms is just normal. Just think of Facebook, Flickr, BitTorrent... One of the strongest assets of the free software community is its worldwide community of contributors and users who believe in free software and who work hard to bring the software and solutions to the mainstream. Core idea of the Social Desktop is to connect to your peers in the community, making sharing and exchanging knowledge easier to integrate into applications and the desktop itself. The concept behind the Social Desktop is to bring the power of online communities and group collaboration to desktop applications and the desktop shell itself. This feature is about the integration of such a social desktop into our desktop. If integrated it should be simply to use its functionalities but everybody needs to have free choice to use it or not. The targetgroup of the new community / social network is not only developers but also the end users who are not familiar with technical stuff and can with an integrated social desktop get easily in contact with people in the same area or people with same interests or software issues. Creation of some kind of facebook for openSUSE may stimulate the openSUSE adoption and bind existing users to the distribution. This could be beneficial for the marketshare of openSUSE. Another aspect is that this kind of communities can transform users into contributors. References: http://www.open-collaboration-services.org/ http://www.opendesktop.org -- openSUSE Feature: https://features.opensuse.org/306933

1 4

[openFATE 306006] btrfs in openSUSE
by fate_noreply＠suse.de 21 Jan '10

21 Jan '10

Feature added by: Marek Stopka (m4r3k) Feature #306006, revision 1, last change by Title: btrfs in openSUSE openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Marek Stopka (m4r3k) Description: I think it is time to make btrfs as a part of upcoming openSUSE 11.2, probably with BIG warning but still there should be possibility to use btrfs and even better with some kind of integration in YaST disk module... Fedora is going for btrfs with next release either. -- openSUSE Feature: https://features.opensuse.org/306006

1 12

[openFATE 306529] Deactivate build if home:user:branch:foo is inactive for 1 or 2 weeks
by fate_noreply＠suse.de 21 Jan '10

21 Jan '10

Feature added by: Jan-Simon Möller (dl9pf) Feature #306529, revision 1 Title: Deactivate build if home:user:branch:foo is inactive for 1 or 2 weeks Buildservice: Unconfirmed Priority Requester: Important Requested by: Jan-Simon Möller (dl9pf) Description: It would save quite some cpu-cycles if branches which are not in active use - e.g. no change in 1 or 2 weeks - would just get the build disabled. Thus the wave during each factory checkin wouldn't be that high. Or even delete branches if they're inactive for 1 or 2 weeks and only the pristine _link is there. This could be extended to disable the build for factory repos in user's home-dir if there're no checkin's for some time. I don't want to prevent ppl from tracking factory in their home: , but a plain _link is just pointless and build should be disabled automagically after some time. -- openSUSE Feature: https://features.opensuse.org/306529

1 3

[openFATE 306426] Add Package Wishlist
by fate_noreply＠suse.de 21 Jan '10

21 Jan '10

Feature added by: Klaas Freitag (kfreitag) Feature #306426, revision 1, last change by Title: Add Package Wishlist Buildservice: Unconfirmed Priority Requester: Important Requested by: Klaas Freitag (kfreitag) Description: In the Buildservice, the package wishlist should be accessible. That would make it easy to pick packages and build it if bored. -- openSUSE Feature: https://features.opensuse.org/306426

1 5

[openFATE 306589] Improve help for CA Management
by fate_noreply＠suse.de 15 Jan '10

15 Jan '10

Feature added by: Michael Calmer (mcalmer) Feature #306589, revision 1 Title: Improve help for CA Management openSUSE-11.2: New Priority Requester: Desirable Requested by: Michael Calmer (mcalmer) Description: This Module should offer a Hyperlink to far more text - possible online. Relations: - CA Management Module has Virtually No Help (novell/bugzilla/id: 515863) https://bugzilla.novell.com/show_bug.cgi?id=515863 -- openSUSE Feature: https://features.opensuse.org/306589

1 2

[openFATE 306590] Yast Common Server Certificate should support modify, delete, export
by fate_noreply＠suse.de 15 Jan '10

15 Jan '10

Feature added by: Michael Calmer (mcalmer) Feature #306590, revision 1 Title: Yast Common Server Certificate should support modify, delete, export openSUSE-11.2: New Priority Requester: Desirable Requested by: Michael Calmer (mcalmer) Description: More features for Common Server Certificate requested: * Ability to Modify/change the certificate * Ability to Delete * Ability to Export Relations: - Yast Common Server Certificate (novell/bugzilla/id: 510798) https://bugzilla.novell.com/show_bug.cgi?id=510798 -- openSUSE Feature: https://features.opensuse.org/306590

1 3

[openFATE 306007] Ship more vanilla
by fate_noreply＠suse.de 12 Dec '09

12 Dec '09

Feature added by: Klaas Freitag (kfreitag) Feature #306007, revision 1, last change by Title: Ship more vanilla openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Klaas Freitag (kfreitag) Description: Upstream projects such as KDE 4 often are developed with very high care for usability, design and eye candy, staffed with high skilled specialists and/or artists. openSUSE modifications against the vanilla versions sometimes do not really improve the upstream version. Moreover, these kind of modifications often kind of rebrand the projects, for example by replacing the KDE startmenu button by an openSUSE branded one. The openSUSE distribution as a community project should maintain the brand of the upstream projects and not hide them from the distributions users. Also patching vanilla behaviors where not technically needed or fixing problems should be handled very carefully and only happen in good dialog with upstream. -- openSUSE Feature: https://features.opensuse.org/306007

1 11

[openFATE 307065] Terminate DVD image creation and only provide LiveCDs and Net Installs
by fate_noreply＠suse.de 10 Dec '09

10 Dec '09

Feature added by: Stephen Kellat (skellat) Feature #307065, revision 1 Title: Terminate DVD image creation and only provide LiveCDs and Net Installs openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Stephen Kellat (skellat) Description: The discussion in openFATE #306967 relates to making KDE the default desktop environment for openSUSE. The question of choice arises there. A work-around to this would be to cease creating DVD images for installation and instead focus on LiveCDs and Net Install discs. Parity across desktop environments would be possible in having separate GNOME and KDE LiveCDs while also promoting Xfce into its own LiveCD instead of its obscurity on the DVD. As for Net Install discs, those are intended for experienced users so the rationale being exhibited in #306967 for catering to the needs of new users would not necessarily apply. Net Install discs could keep an expanded desktop environment choice list. Test Case: User desires GNOME experience in openSUSE and downloads the GNOME LiveCD. The kicker at http://software.opensuse.org would make the choice available to the user. Other users desire a KDE experience, an Xfce experience, or an LXDE experience would also be potentially directed by the kicker. ISO naming conventions would have to be adjusted to take into account the variety of LiveCDs possible. Use Case: Building LiveCDs decreases the amount of bandwidth to be consumed by potential users who would otherwise secure the DVD ISO. SUSEStudio could be tied in so that project leaders who were so minded could offer refreshed respins on their own outside the normal distribution cycle. -- openSUSE Feature: https://features.opensuse.org/307065

1 8

[openFATE 306976] Incluir Firefox en qt4 en forma predeterminada
by fate_noreply＠suse.de 03 Dec '09

03 Dec '09

Feature added by: Luis Bodino (luigi_bodino) Feature #306976, revision 1 Title: Incluir Firefox en qt4 en forma predeterminada openSUSE-11.2: Unconfirmed Priority Requester: Desirable openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Luis Bodino (luigi_bodino) Description: Propongo que se use la versión qt de firefox para una mejor integración con kde -- openSUSE Feature: https://features.opensuse.org/306976

1 9

[openFATE 306512] Web Services for Management (WS-Man) has official port numbers now
by fate_noreply＠suse.de 20 Nov '09

20 Nov '09

Feature added by: Klaus Kämpf (kwk) Feature #306512, revision 1 Title: Web Services for Management (WS-Man) has official port numbers now openSUSE-11.2: New Priority Requester: Desirable Requested by: Klaus Kämpf (kwk) Partner organization: openSUSE.org Description: >From the openwsman-devel list From: A_Venkatachalam(a)Dell.com To: openwsman-devel(a)lists.sourceforge.net Cc: Vivek_Rajendran(a)Dell.com, Girish_Prakash(a)Dell.com, Chandrasekhar_P(a)Dell.com Subject: [Openwsman-devel] Ports for OpenWSMAN Hi Currently OpenWSMAN 2.1 uses 8888 and 8889 as the default HTTPS and HTTP ports respectively. But as per IANA the registered ports for WSMAN are 5985(HTTP) and 5986(HTTPS) http://www.iana.org/assignments/port-numbers wsman 5985/tcp WBEM WS-Management HTTP wsman 5985/udp WBEM WS-Management HTTP wsmans 5986/tcp WBEM WS-Management HTTP over TLS/SSL wsmans 5986/udp WBEM WS-Management HTTP over TLS/SSL We need to update “openwsman.conf” to make use of these ports by default. Already MS Winrm2.0 is making use of these ports. Thanks, Arun Venkatachalam Dell R & D Centre, Bangalore. Extn - 78973 Business case (Partner benefit): openSUSE.org: Be standards compliant, especially in mixed Windows/Linux enivronments. Discussion: #1: Klaus Kämpf (kwk) (2009-06-15 11:51:12) Changing ports in a SP upgrade might be harmful. Being standards-compatible might outweight the downsides. Needs PM decision ;-) #2: Klaus Kämpf (kwk) (2009-06-15 11:51:56) If we decide to change ports, yast-firewall and documentation might need to be adapted. -- openSUSE Feature: https://features.opensuse.org/306512

1 13