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

[openFATE 306353] add italian ISP on yast DSL providers list
by fate_noreply＠suse.de 20 Nov '09

20 Nov '09

Feature added by: andrea florio (anubisg1) Feature #306353, revision 1, last change by Title: add italian ISP on yast DSL providers list openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: andrea florio (anubisg1) Description: what about to add italian ISP to that list? i can give you all infos needed -- openSUSE Feature: https://features.opensuse.org/306353

1 9

[openFATE 306967] KDE default
by fate_noreply＠suse.de 16 Nov '09

16 Nov '09

Feature added by: Frank Karlitschek (FrankKarlitschek) Feature #306967, revision 1 Title: KDE default openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Frank Karlitschek (frankkarlitschek) Description: I propose to make KDE the default desktop in openSUSE. - It is confusing for new Linux users if they have to decide between KDE and GNOME during the installation. New users don´t know either of them. So it is easier for beginners if there is a default. openSUSE has more KDE users than GNOME users so it is logical to make KDE the default. - Unique Selling Point. It is important for openSUSE to provide something that Ubuntu and Fedora don´t provide. It would be beneficial for openSUSE to be the only big KDE distribution. - This could attract more developers because KDE developers need a nice distribution to develop on. - This would increase the popularity of openSUSE in the KDE user community. The negative impact on the GNOME community is not that bad because Ubuntu is the most popular GNOME distribution. openSUSE should, of course, also ship and support GNOME. So experienced users can choose. But new users should have KDE as default. What do you think? -- openSUSE Feature: https://features.opensuse.org/306967

1 109

[openFATE 306413] Poulsbo (GMA500) graphics support
by fate_noreply＠suse.de 15 Nov '09

15 Nov '09

Feature added by: Justin Haygood (jhaygood) Feature #306413, revision 1, last change by Title: Poulsbo (GMA500) graphics support openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Justin Haygood (jhaygood) Description: openSUSE should support laptops with an Intel GMA500 (Poulsbo) graphics card. Currently, Ubuntu has a monopoly on such machines, such as the Dell Inspiron Mini 12 -- openSUSE Feature: https://features.opensuse.org/306413

1 3

[openFATE 305783] Integrate latest stable KDE4 release
by fate_noreply＠suse.de 05 Nov '09

05 Nov '09

Feature added by: Stephan Binner (Beineri) Feature #305783, revision 1, last change by Title: Integrate latest stable KDE4 release openSUSE-11.2: New Priority Requester: Mandatory Requested by: Stephan Binner (beineri) Partner organization: openSUSE.org Description: Depending on what the openSUSE 11.2 schedule allows, the next release has to contain either the latest KDE 4.2.x or KDE 4.3.x packages including usual nifties (see external link) and integration with the distribution. In any case it should be tested and run with Qt 4.5 and KDE applications should be used in KDE4 versions as far as possible. Relations: - Ideas what to achieve with KDE on 11.2 (url: http://en.opensuse.org/KDE/Ideas/11.2) -- openSUSE Feature: https://features.opensuse.org/305783

1 17

[openFate 305624] Allow downloading all packages before installing
by fate_noreply＠suse.de 30 Oct '09

30 Oct '09

Feature added by: Jiri Srain <jsrain(a)novell.com> Feature #305624, revision 1, last change by Title: Allow downloading all packages before installing openSUSE-11.2: New Requested by: Jiri Srain (jsrain) Interested: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Libzypp should allow to set a policy to first download all packages and afterwards install all packages at once. It should be considered whether to enable this policy under some scenarios (e.g. makes sense for online update, but not for distro installation) References: https://bugzilla.novell.com:443/show_bug.cgi?id=448040 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305624

1 42

[openFATE 306656] Quick hack for anonymous read-only access to build service
by fate_noreply＠suse.de 29 Oct '09

29 Oct '09

Feature added by: Juergen Weigert (jnweiger) Feature #306656, revision 1 Title: Quick hack for anonymous read-only access to build service Hackweek IV: Unconfirmed Priority Requester: Important Requested by: Juergen Weigert (jnweiger) Description: Currently iChains is in front of build.opensuse.org, thus a read-only mode without login is not possible. As a quickfix hack: Let us implement a Guest User, who can login to iChains with one mouseclick. The Guest User shall have no write permissions, but shall have a login button, which allows user to change to their own login later. -- openSUSE Feature: https://features.opensuse.org/306656

1 5

[openFATE 306647] Make openFATE More Readable
by fate_noreply＠suse.de 25 Oct '09

25 Oct '09

Feature added by: Karl Eichwalder (keichwa) Feature #306647, revision 1 Title: Make openFATE More Readable openFATE: Unconfirmed Priority Requester: Important Requested by: Karl Eichwalder (keichwa) Description: Please, offer an alternate style-sheets (CSS) for better readability. For me, many texts are hard to read because the contrast is rather low (light gray on white, a grayish blue on gray, this gray on that gray–all this is often hard to read). Do not take me wrong: the Web UI looks very nice, but for readability I'd rather prefer black on white. BTW, I'm wondering why the on-the-fly spellchecker is not active in the edit box? -- openSUSE Feature: https://features.opensuse.org/306647

1 3

[openFate 305730] Add Package-Wishlist as 'Products' Component
by fate_noreply＠suse.de 21 Oct '09

21 Oct '09

Feature added by: Lars Vogdt (lrupp) Feature #305730, revision 1, last change by Title: Add Package-Wishlist as 'Products' Component openFATE: Unconfirmed Priority Requester: Important Requested by: Lars Vogdt (lrupp) Partner organization: openSUSE.org Description: So current solution for openSUSE users to suggest new packages for inclusion in openSUSE is a bit complicated and diverted in many places: * see the Wislists (http://en.opensuse.org/Wishlist) in the Wiki * see the Bugzilla (http://devzilla.novell.com/education/) of openSUSE-Education * see Novells Bugzilla (https://bugzilla.novell.com/) * see the openSUSE-Forums and Mailinglists... A possible solution with the new openFATE could be to unify the process to request new packages for openSUSE on one single place: openFATE! To make requests of new packages easy, someone should be able to file a request against a "Product" named "New packages" or "Package Wishlist". Perhaps it's possible to create a simple Wizard for this special product in the future, including: * At least two mandatory fields for packagename and upstream URL * and a simple "search for pending requests" after entering the two mandatory fields to avoid duplicates. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305730

1 7

[openFate 305691] Support ext4 as installation option
by fate_noreply＠suse.de 19 Oct '09

19 Oct '09

Feature added by: Stephan Binner (Beineri) Feature #305691, revision 1, last change by Title: Support ext4 as installation option openSUSE-11.2: New Priority Requester: Mandatory Requested by: Stephan Binner (beineri) Partner organization: openSUSE.org Description: Next openSUSE release should at least support to use (versus "default to") ext4 as file system. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305691

1 35

[openFATE 306935] Backport X-Fi support into Factory kernel
by fate_noreply＠suse.de 19 Oct '09

19 Oct '09

Feature added by: Dean Hilkewich (deanjo13) Feature #306935, revision 1 Title: Backport X-Fi support into Factory kernel openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Dean Hilkewich (deanjo13) Description: Could you please backport the x-fi alsa module into the factory kernel. People have been waiting far to long for this support and it would be ashame to not have it tested extensively in the early stages of 11.2 development. -- openSUSE Feature: https://features.opensuse.org/306935

1 8

[openFATE 306753] zypper - bootstrap: install into given directory
by fate_noreply＠suse.de 16 Oct '09

16 Oct '09

Feature added by: Jan Engelhardt (jengelh) Feature #306753, revision 1 Title: zypper - bootstrap: install into given directory openSUSE-11.2: Unconfirmed Priority Requester: Desirable openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Jan Engelhardt (jengelh) Description: Currently, one needs a bit of rpm[1] to initialize a minimal base system[2]. It would be cool if one could just use zypper to calculate all the dependencies. Like: zypper --root /tmp/test install rpm zypper Afterwards, the zypper inside the new chroot can be used to install further packages as desired. [1] http://jengelh.medozas.de/files/bootstrap-11.1-i586.sh [2] perhaps not even functional for a standalone boot, but that's not the point -- openSUSE Feature: https://features.opensuse.org/306753

1 10

[openFate 305702] Finer checks for a syslog reload need in dhcp client scripts
by fate_noreply＠suse.de 12 Oct '09

12 Oct '09

Feature added by: Marius Tomaschewski (mtomaschewski) Feature #305702, revision 1, last change by Title: Finer checks for a syslog reload need in dhcp client scripts openSUSE-11.2: New Priority Requester: Neutral Requested by: Karl Katzke (karlkatzke) Interested: Stefan Behlert (sbehlert) Interested: Stephan Kulow (coolo) Partner organization: openSUSE.org Description: Syslog reloads every time the DHCP lease is renewed, even though the "change hostname via DHCP" option is turned off in the configuration. Finer control requested in bugzilla, bug 466198, by Karl Katzke. Would be a finer control / finer checks (hostname, ip address changes) desirable to implement? Relations: - syslog does not get right hostname when dhcp is used (novell/bugzilla/id: 116466) https://bugzilla.novell.com/show_bug.cgi?id=116466 - DHCP renewal causes syslog-ng reset even if host name has not changed (novell/bugzilla/id: 466198) https://bugzilla.novell.com/show_bug.cgi?id=466198 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305702

1 8

[openFATE 305888] Disable PulseAudio by default
by fate_noreply＠suse.de 06 Oct '09

06 Oct '09

Feature added by: Stephan Kulow (coolo) Feature #305888, revision 1, last change by Title: Disable PulseAudio by default openSUSE-11.2: Unconfirmed Priority Requester: Mandatory Requested by: Alberto Passalacqua (albertop) Description: PulseAudio has been one of the major sources of complaints and of problems for both the 11.0 and 11.1 release, with significant annoyances for openSUSE users, as reported on IRC and on local forums. As a consequence it is worth to consider the possibility to disable it by default on freshly installed systems for openSUSE 11.2. This enhancement request aims to collect the votes of those who agree with this. According to a discussion in IRC with coolo, if there are enough requests, this might be done. So, please, if you want to see PA disabled by default, in favour of a working audio system out of the box for many more users, just comment here. Relations: - Disable PulseAudio by default (novell/bugzilla/id: 478511) https://bugzilla.novell.com/show_bug.cgi?id=478511 Discussion: #1: Criss Peress (pieris) (2009-02-22 12:52:19) +1 #2: Jakub Rusinek (liviopl) (2009-02-22 13:31:25) You should have a look at what Lennart says on pulseaudio-discuss list [1], 'cause this might be important for openSUSE. 1| https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-February/003150… #3: Luigi Bettin (gigi888) (2009-02-22 13:55:58) +1 #4: Alberto Passalacqua (albertop) (2009-02-22 14:23:28) On comment #2: that has nothing to do with this discussion. Please keep it on topic! Fedora, cited in the link as the distribution doing something in the suggested direction, has similar complaints to those we had for openSUSE 11.0 and 11.1. Bye, A. #5: andrea florio (anubisg1) (2009-02-22 16:57:39) +1 for me #6: andrea martin (il_cjargnel) (2009-02-22 23:54:03) +1 for me (no pulse audio of default in 11.2) #7: Takashi Iwai (tiwai) (2009-02-23 01:07:08) Guys, the bugzilla is no place for voting or discussions, and it's no user forum. It's the place to report a bug and fix the bug. Please vote/discuss on ML at first. Then report back the result to bugzilla as the consensus of the whole community. Thanks. #8: Sven Burmeister (rabauke) (2009-02-23 04:28:01) I do not see any discussion here. Enabling pa by default can be regarded as a bug and not doing so as an enhancement people vote on. Bugzilla is about bugs/enhancements (not features) and voting. #9: Alberto Passalacqua (albertop) (2009-02-23 07:22:54) In answer to comment #7: This is an enhancement request, and bugzilla is exactly the place where this kind of discussion, to collect votes for it. Further discussion happened in the IRC anyway, and this bug report was opened as a consequence of it to collect user's feedback in a clean and organized manner, so that the decisionmaker can decide without reading an endless discussion in a mailing-list. As a consequence I reopen it. Regards, A. #10: Alberto Passalacqua (albertop) (2009-02-23 07:26:33) @Takashi Iwai: You might want to take part to the IRC life of openSUSE and discuss with us. Any suggestion/help is welcome! :-) #11: Takashi Iwai (tiwai) (2009-02-23 07:43:54) Could you give the exact voting result here? (And, no I'm not going to join IRC just for this purpose.) The vote must be done in an open way, and needs to take from a wide range of voters (users) without bias. Voting in bugzilla doesn't make sense for this kind of issue because the bugzilla (a specific bug entry) isn't the place where every user takes a look. It's the place where the people with the same problems take a look. Thus, of course, it will result in votes just by haters. Also, the endless discussion in ML is the result you have to respect. If there is no clear sign in the discussions in ML, it means there is no clear way to go, too. The rest is the political decision, and not about technical ones (remember KDE vs GNOME). So, please give more concrete technical issues rather than emotional +1/-1 votes. #12: Michael Skiba (mirrakor) (2009-02-23 10:03:31) > So, please give more concrete technical issues rather than emotional +1/-1 votes. There's nothing emotional about it. > It's the place where the people with the same problems take a look. Thus, of course, it will result in votes just by haters. Which is exactly the point - this isn't an open "opinion poll" it's about messuring how big the disturbances/problems (->bug) with PA really is, and if it affects enough people it's worth thinking about disabling it by default. #13: Alberto Passalacqua (albertop) (2009-02-23 10:07:28) Hi Takashi, the result of the voting, done with the usual procedure to vote bugs and requests, can be read at the top of the page. Currently this request has 27 votes. Each user can give a maximum of five votes. I probably wasn't clear in the initial post. We discussed to disable PA on IRC, and coolo suggested that is can be done if there is a sufficient number of requests. I don't know what "sufficient" means, but I thought it would have been easier to collect the votes in a quantitative manner here, using bugzilla features. I think it is important to notice that I'm not asking to remove PulseAudio, but to simply disable it by default, so that users don't meet the problems it is causing to them. PulseAudio can be already be disabled with one click in YaST, and the same can done to enable it again. My idea is that we should not activate it by default, because for 11.0 and 11.1 releases we had quite a lot of complaints due to it. Users who want it will be able to enable it with a simple click, but the new unexperienced user won't have to fight to make it work to listen to his music, which will result in a better image of the distribution that "works out of the box" and at the same time provides "the latest stack" for those who want/need it. The concrete technical issues are the following (I sum up what reported): - PA audio glitches often. - It gives troubles with Flash and other players, which capture the server, making other applications unable to work correctly. - It crashes, leaving you without controls on the audio system (Connection refused). - It doesn't work properly with some player and sound tool (someone reported issues with audacity, skype (I know it's skype problem but people wants to use it) gives problems too). Anyway, if you prefer, we can post the link on the ML to make it available to a wider public. I simply fear it will become noisy. I already spread it on IRC when I opened the request. P.S. My invitation on IRC was friendly. If you don't like it, there is no problem. But I'm serious when I say that suggestions are welcome. After all we are here to improve things, and not to fight between us :-) Regards, Alberto #14: Daniele Tombolini (kailed) (2009-02-23 11:47:18) +1 at least, under kde is unuseful. #15: Takashi Iwai (tiwai) (2009-02-23 12:11:37) OK, then I reassign this bug to coolo. Please reassign back after the decision is made. My position is neutral about this. I myself don't use PA, and I won't. But I do understand that some (other) people want PA as default, too. #16: alberto rossi (al9000) (2009-02-23 12:13:09) no to pulseaudio by default in opensuse 11.2 #17: Rajko Matovic (rajko_m) (2009-02-23 13:17:47) This is discussion about this enhancement request: http://lists.opensuse.org/opensuse-factory/2009-02/msg00208.html #18: Alberto Passalacqua (albertop) (2009-02-23 13:21:34) FYI, opened a discussion here so the interested people can say their opinion and we can collect more feedback: http://lists.opensuse.org/opensuse-factory/2009-02/msg00208.html A. #19: Vincent Untz (vuntz) (2009-02-23 14:47:36) Stupid question, if people think that the votes on this bug can be taken into account for the decision: how can people vote to keep pulseaudio? IMHO, bugzilla is not the right place for this -- this is not an enhancement request, this is a technical decision. Starting a thread on opensuse-factory was a good thing, though :-) #20: Andras Barna (sartek) (2009-02-23 19:59:13) for me alsa worked perfectly, so why change it.. so +1 #21: Jigish Gohil (cyberorg) (2009-02-23 22:45:22) Can we get kernel people look into the points raised in link posted on comment #2? https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-February/003150… Quoting relevant parts from that post for everyone's benefit here. "Apparently OpenSUSE ships a kernel (2.6.27.7-9-pae) that causes scheduling latencies of > 210ms. That is a lot. That is really really really a lot." "Fedora-kernels that easily give latencies of 5ms or so." "1) For fucks sakes: get your bloody kernels fixed. Enable preempt, set HZ to 1000. Get rid of low-quality drivers that block the CPU. Latencies of 210ms is *REALLY NOT NECESSARY*. 2) If you want to stick with your crap kernel, then either disable g-f entirely or adjust the #defines at the top of src/modules/alsa-sink.c and src/modules/alsa-source.c." So why do our kernel suck so bad? -- openSUSE Feature: https://features.opensuse.org/305888

1 28

[openFATE 306364] Live-CD: Start of Installer Without Desktop
by fate_noreply＠suse.de 01 Oct '09

01 Oct '09

Feature added by: Stephan Binner (Beineri) Feature #306364, revision 1, last change by Title: Live-CD: Start of Installer Without Desktop openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Stephan Binner (beineri) Description: It should be possible to start the Live-CD installer directly from boot menu on low-memory systems without having to load a complete desktop. -- openSUSE Feature: https://features.opensuse.org/306364

1 8

[openFATE 305845] YaST - keyword search for modules
by fate_noreply＠suse.de 30 Sep '09

30 Sep '09

Feature added by: Pavol Rusnak (prusnak) Feature #305845, revision 1, last change by Title: YaST - keyword search for modules openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Pavol Rusnak (prusnak) Description: System Preferences in Mac OS X (YaST equivalent from Apple :)) has a group of keywords associated with each module. It would be nice if YaST had the same. Example: * module: Hardware -> Graphics Card and Monitor * keywords: graphics, monitor, screen, resolution, ... When user wants to change the resolution, he/she starts YaST, type "resolution" in search box and "Graphics Card and Monitor" module will show up. This is not possible now, because YaST only searches in descriptions of modules. -- openSUSE Feature: https://features.opensuse.org/305845

1 5

[openFATE 306305] iFolder for openSUSE 11.2
by fate_noreply＠suse.de 28 Sep '09

28 Sep '09

Feature added by: Michael Löffler (michl19) Feature #306305, revision 1, last change by Title: iFolder for openSUSE 11.2 openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Michael Löffler (michl19) Partner organization: openSUSE.org Description: Getting iFolder in a state where we first can get it into Factory and then add it to openSUSE 11.2. iFolder is a simple and secure storage solution that increases productivity by enabling to back up, access and manage personal files-from anywhere, at any time. Once installed, it simply saves files locally and iFolder automatically updates the files on a network server and delivers them to a different machines in usage. Business case (Partner benefit): openSUSE.org: Different people at different locations can work jointly on the same file. They always can find on the server the most current version of the file as iFolder keeps it up to date. iFolder allows more efficient collaboration -- openSUSE Feature: https://features.opensuse.org/306305

1 6

[openFate 305343] Partitioner: Support RAID10
by fate_noreply＠suse.de 25 Sep '09

25 Sep '09

Feature added by: Arvin Schnell <aschnell(a)novell.com> Feature #305343, revision 1, last change by Title: Partitioner: Support RAID10 openSUSE-11.2: New Priority Requester: Important SLES-12: New Priority Requester: Important Requested by: V K <truckk(a)inbox.lv> Partner organization: openSUSE.org Description: There is interesting raid-10 config on 2 disks witch can be created like that: mdadm --create /dev/md1 --bitmap=internal --metadata=1.0 --level=raid10 --raid-devices=2 --layout=f2 /dev/sda2 /dev/sdb2 such configuration gives about 2x sequential read performance in comparison with plain raid-1 partitioner shows only RAID Type: RAID_UNKNOWN. Discussion: #1: Arvin Schnell <aschnell(a)novell.com> (2008-10-17 04:05:48) I know, same is true for RAID6. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305343

1 8

[openFATE 306658] Migration tool from KDE3 to KDE4
by fate_noreply＠suse.de 15 Sep '09

15 Sep '09

Feature added by: Axel Braun (DocB) Feature #306658, revision 1 Title: Migration tool from KDE3 to KDE4 openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Axel Braun (docb) Description: As KDE4 becomes more stable, many users go (or are forced to go...) to KDE4. To ease this step, esp. in a production environment or within a company, a migration tool is required. For example, I just tried to migrate KMail by copying kmailrc and apps/kmail to the ~/.kde4 path. Mail accounts (POP/Dimap) are copied, but I miss all identities, outbound mail servers and all local mail subfolders. This test is not yet performed for knode, kwallet, PGP, etc...but definitely required -- openSUSE Feature: https://features.opensuse.org/306658

1 16

[openFate 305631] vlan support in initrd
by fate_noreply＠suse.de 15 Sep '09

15 Sep '09

Feature added by: Bernhard Walle <bwalle(a)novell.com> Feature #305631, revision 1, last change by Title: vlan support in initrd openSUSE-11.2: New Requested by: Bernhard Walle (bwalle) Partner organization: openSUSE.org Description: Quoting from Bugzilla 415389 (because external reporters are not able to create a FATE entry): It would be very useful to be able to create vlan network interfaces in initrd via kernel command line parameters. This makes network support in initrd more complete. In our case we need vlan support because all servers have two physical network interfaces. eth0 is connected to the default vlan, which is internet in our case. eth1 is a trunk interface connected to several internal vlans. We need the vlans to seperate traffic from different virtual machines. Only one vlan supports nfs, other vlans are more restricted or private to a customer owning a virtual machine. Because a xen dom0 server doesn't need much diskspace, we boot them from the network. This requires the initrd to login to the nfs server, which requires vlan support. Business case (Partner benefit): openSUSE.org: I don't see any business case here. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305631

1 4

[openFate 305594] Logging support for osc meta and others ...
by fate_noreply＠suse.de 14 Sep '09

14 Sep '09

Feature added by: Pavol Rusnak <prusnak(a)novell.com> Feature #305594, revision 1, last change by Title: Logging support for osc meta and others ... Buildservice: New Priority Requester: Important Requested by: Pavol Rusnak <prusnak(a)novell.com> Partner organization: openSUSE.org Description: * The logging support missing for osc meta and other potentially dangerous ctions. When anyone changes a project conf for example, there's no information who changed what. So the current commit logs support should be extended to all other changes in package/project. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305594

1 2

[openFATE 306764] device mapper raid0/1/5 kernel modules upgread
by fate_noreply＠suse.de 10 Sep '09

10 Sep '09

Feature added by: Marcin Labun (mlabun) Feature #306764, revision 1 Title: device mapper raid0/1/5 kernel modules upgread openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Marcin Labun (mlabun) Description: Please upgrade to the latest device mapper kernel modules for dmraid: dm-stripe, dm-mirror. Please inlcude also RAID 5 module which is experimetal and can be found at: http://people.redhat.com/heinzm/sw/dm/dm-raid45/ This request is connect with https://features.opensuse.org/306763 (upgrade dmraid to RC16). -- openSUSE Feature: https://features.opensuse.org/306764

1 4

[openFATE 306942] Update yast2-sound to recognize x-fi in factory.
by fate_noreply＠suse.de 08 Sep '09

08 Sep '09

Feature added by: Dean Hilkewich (deanjo13) Feature #306942, revision 1 Title: Update yast2-sound to recognize x-fi in factory. openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Dean Hilkewich (deanjo13) Description: Now that Takashi Iwai has graciously backported the x-fi module into the factory kernel can we please get the yast2-sound module updated to include support for the x-fi? -- openSUSE Feature: https://features.opensuse.org/306942

1 3

[openFATE 306763] upgrade dmraid to RC16
by fate_noreply＠suse.de 07 Sep '09

07 Sep '09

Feature added by: Marcin Labun (mlabun) Feature #306763, revision 1 Title: upgrade dmraid to RC16 openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Marcin Labun (mlabun) Description: RC16 version of dmraid (not yet published) will include following features/bug fixes (full description of bugs can be found in RH BZ): 479419 [SEC] OROM/DMRAID metadata inconsistency 479425 Incorrect status displayed when disk is missing [status] 483282 dmraid -r will falsely toggle the OROM back to 'normal' status after a failed rebuild 481735 [SEC] dmraid does not allow to activate RAID arrays in degraded state 481749 [SEC] DMRAID does not receive and process kernel events for active devices 505005 dmraid always creates error mapping for the last device in an isw RAID5 set 505007 dmraid regression on raid45 target kernel status interface 506893 Segmentation fault for RAID5 when starting manual rebuild 473282 [SEC] Include support for compatibility with IMSM 9.0 metadata in dmraid 505011 dmraid doesn't update isw metadata to OK during rebuild -- openSUSE Feature: https://features.opensuse.org/306763

1 3

[openFATE 306307] Include Gwibber in GNOME 11.2
by fate_noreply＠suse.de 07 Sep '09

07 Sep '09

Feature added by: Kevin Dupuy (kdupuy9) Feature #306307, revision 1, last change by Title: Include Gwibber in GNOME 11.2 openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Kevin Dupuy (kdupuy9) Description: With the explosion in use of microblogging in everything from Facebook to Twitter, more and more people are looking for a way to view all their friends and followers messages, as well as get their messages out quickly. I propose openSUSE includes Gwibber in the default install of openSUSE GNOME. Gwibber is a microblogging client written in GTK and supports Twitter, Facebook, Jaiku, Laconi.ca servers, Flickr, and more. More info at https://launchpad.net/gwibber -- openSUSE Feature: https://features.opensuse.org/306307

1 7

[openFate 305731] Remove scrollkeeper
by fate_noreply＠suse.de 07 Sep '09

07 Sep '09

Feature added by: Vincent Untz (vuntz) Feature #305731, revision 1, last change by Title: Remove scrollkeeper openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Vincent Untz (vuntz) Partner organization: openSUSE.org Description: We should remove scrollkeeper from the distribution and only use a rarian-based solution. This implies working upstream on migrating the modules. Also, we could make packages install their help in /usr/share/datatir/gnome-panel/help (eg), instead of /usr/share/gnome/help which is difficult to handle from a package ownership point of view. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305731

1 5

[openFate 305345] Replace cups-autoconfig with hal-cups-utils
by fate_noreply＠suse.de 07 Sep '09

07 Sep '09

Feature added by: Vincent Untz <vuntz(a)novell.com> Feature #305345, revision 1, last change by Title: Replace cups-autoconfig with hal-cups-utils openSUSE-11.2: New Priority Requester: Important Requested by: Vincent Untz <vuntz(a)novell.com> Partner organization: openSUSE.org Description: In openSUSE, we use cups-autoconfig to automatically configure new printers detected by HAL. However, no other distro uses this, and hal-cups-utils seems to be the long-term solution. Switching to hal-cups-utils means easier maintenance for us. hal-cups-utils also ships the hal backend for cups that we have in cups-backends. I've packaged a new cups-backends package (without the hal backend) and a hal-cups-utils package (with the hal backend, patched like what we had in cups-backends) in home:vuntz:factory-playground. So it's all ready for testing. Note: yast2-printer makes it possible to edit /etc/cups-autoconfig.conf. We might want to keep the configuration option of /etc/cups-autoconfig.conf in hal-cups-utils. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305345

1 9

[openFATE 306168] Wake the PC to run the task if it has been suspended.
by fate_noreply＠suse.de 04 Sep '09

04 Sep '09

Feature added by: Stephan Kulow (coolo) Feature #306168, revision 1, last change by Title: Wake the PC to run the task if it has been suspended. openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Scott Couston (zczc2311) Description: Increasingly we offer tasks to be run that are configured in Yast - Online Update- Apparmour reports, notifications from events etc etc. What we don't offer it an open to wake the PC from suspend to run the task if the user so desires it - I think its is not of much value to schedule any task or to set any type of notification if the user has no option to wake the PC from suspend Reproducible: Always Steps to Reproduce: 1. Set online update to run in 30 minutes time. 2. Suspend the PC. 3. We have lost our instructions to initiate any schedule by NOT offering a way or option to wake a PC from sleep. Actual Results: If the PC suspends itself is is told to suspend any scheduled task set during that period will never run. Expected Results: This is a problem as we are setting a task but don't provide a way for the task we have set to run if the PC is suspended at the time - This could easily mean that any scheduled task may never run if it is scheduled inside say.......23:00 - 04:00 Hours Dont like my luck with default priority ;-) But I think I have a valid point to leave default Severity and aim for 11.2 implementation. Relations: - In all Yast Application that we enable to run at a specific time we currently have no way to wake the PC to run the task if it has been suspended. (novell/bugzilla/id: 482678) https://bugzilla.novell.com/show_bug.cgi?id=482678 -- openSUSE Feature: https://features.opensuse.org/306168

1 4

[openFATE 306733] Add KDE3 buildservice repository to community list
by fate_noreply＠suse.de 02 Sep '09

02 Sep '09

Feature added by: Karsten König (remur) Feature #306733, revision 1 Title: Add KDE3 buildservice repository to community list openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Karsten König (remur) Description: As openSUSE 11.2 will drop KDE3 from main repositories we should make adding the KDE3 repository as easy as possible, adding KDE3 to the community repository list would be an easy way to do this and will point out the unsupported state of the repository. Use Case: * Elmar wants to keep using KDE3 as KDE4 still isn't ready for him, he doesn't mind using a seperate inofficial repository though. This will make it easy for him to add the repository at install time and select KDE3 * Karsten hangs around #opensuse-kde and after 11.2 release a lot of people come and ask how to get KDE3 and start bitching about the decission to drop it, he can now point out this easy way to add the repository and help restore order in the channel -- openSUSE Feature: https://features.opensuse.org/306733

1 28

[openFate 305308] Installation into Windows Partition (Wubi-like)
by fate_noreply＠suse.de 27 Aug '09

27 Aug '09

Feature added by: Stephan Binner <stbinner(a)novell.com> Feature #305308, revision 1, last change by Title: Installation into Windows Partition (Wubi-like) openSUSE-11.2: New Priority Requester: Desirable Requested by: Stephan Binner <stbinner(a)novell.com> Partner organization: openSUSE.org Description: Wubi allows the installation of Ubuntu on a MS Windows System without changing the partition setup. Users can test-drive a Linux system without major performance loss like when using a Live-CD, have data persistence beyond reboot and an easy way to deinstall like any other application after trial. References: http://wubi-installer.org , https://wiki.ubuntu.com/WubiGuide , http://en.wikipedia.org/wiki/Wubi_(Ubuntu) Business case (Partner benefit): openSUSE.org: Having a Wubi-alike installer for openSUSE would be a great way to promote openSUSE to Windows users. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305308

1 14

[openFATE 306652] description field silently removes words in < angular brackets >
by fate_noreply＠suse.de 24 Aug '09

24 Aug '09

Feature added by: Juergen Weigert (jnweiger) Feature #306652, revision 1 Title: description field silently removes words in < angular brackets > openFATE: Unconfirmed Priority Requester: Important Requested by: Juergen Weigert (jnweiger) Description: angular brackets < and > should be escaped from the rich text validator, if taped in by the user. currently the validator silently removes them together with the words in them, thus crippling the text. -- openSUSE Feature: https://features.opensuse.org/306652

1 4

[openFATE 306995] make voting widget more prominent in openFATE
by fate_noreply＠suse.de 24 Aug '09

24 Aug '09

Feature added by: Ciaran Farrell (babelworx) Feature #306995, revision 1 Title: make voting widget more prominent in openFATE openFATE: Unconfirmed Priority Requester: Desirable Requested by: Ciaran Farrell (babelworx) Description: When viewing a feature on features.opensuse.org it is hard to see how you can vote the feature up or down. You can see a scorebar, but no indication of how to influence it. After viewing the Help page, I found out that "The voting widget is displayed on the upper right side of a feature. It shows the current score of a feature, and you can see a history of the votes on "toggle statistics". To give a vote, please login, and you will have the three options "down", "neutral" and "up" when hovering over the voting applet." The Help documentation is perfect - but would it not be better if the "vote up and vote down" buttons were: * directly visible without needing to hover over anything * accessible not just from the feature page itself but also when viewing a list of features sorted e.g. by score * from the dashboard -- openSUSE Feature: https://features.opensuse.org/306995

1 4

[openFATE 306909] Implement kio_sftp with libssh
by fate_noreply＠suse.de 21 Aug '09

21 Aug '09

Feature added by: Andreas Schneider (gladiac) Feature #306909, revision 1 Title: Implement kio_sftp with libssh Hackweek IV: Unconfirmed Priority Requester: Important Requested by: Andreas Schneider (gladiac) Description: The current kio_sftp implementation calls the openssh ssh binary for sftp. This is ugly and slow. It is time to replace kio_sftp with libssh's sftp implementation. This is a POSIX like API for IO. Andreas Schneider and Dirk Müller will work on this. Test Case: Whatever ... :) Use Case: Better, faster, cleaner! -- openSUSE Feature: https://features.opensuse.org/306909

1 3

[openFate 305320] Show accessed mirror(s)
by fate_noreply＠suse.de 18 Aug '09

18 Aug '09

Feature added by: Peter Poeml <poeml(a)novell.com> Feature #305320, revision 1, last change by Title: Show accessed mirror(s) openSUSE-11.1: New Priority Requester: Mandatory Requested by: Peter Poeml <poeml(a)novell.com> Partner organization: openSUSE.org Description: This concerns both YaST and zypper. It would help a lot if they would show the mirror which is accessed when downloading a package. (Technically, the download client is following redirects and the actually URL needs to be shown, not just the first URL that was contacted but that redirected to another URL) It is a long-standing problem that this information is lacking and it makes debugging and optimizing much harder than necessary, because this information is only available deeply buried in some logfile. We need this information for two reasons: 1) Debugging - to see which URL was accessed when something goes wrong, like a mirror timing out. For example, Whenever a mirror returns garbage, it takes a lot of additional time to find out which one, because all reports are lacking the critical detail, and it is usually hard to find it out later. 2) Optimizing the load sharing between different mirrors - to distinguish slow mirrors from fast ones. For example, I am very much in need of information about the situation in the US, but even though people in the US run installations for me and are willing to send me logs, I can't get this information. In reply to a question from Stano: > Do you want the information in the log or to be shown in e.g. zypper -vvv ? Shown, in normal output. It is already in some log I believe, I don't know which one exactly anymore though. Thing is, users won't be able to tell us anything useful if they weren't shown the information. And later it is not reproducible. At least in a failure situation the URLs must be shown. That alone wouldn't give us the chance to find out about slow mirrors, but at least it would allow to debug problems. Real life example #1: If a mirror is behind a firewall that lets every 10th connection stall (so the transfer hangs or the connection is reset), it usually takes weeks (!) to find out about it. But it hits virtually every user from mirrors country during the time. We have had this 4 times during the last 18 months. Real life example #2: I got feedback from someone who did a network install of openSUSE 11.0 from download.opensuse.org, located in the US. He had to let it running overnight because it took a long time. Next morning, the install hadn't even completed. YaST was hanging and waiting for somebody to hit retry. Problem is, it took us a lot of work to find out which mirror was at fault. We actually had to repeat the install, I had to follow the log and live watching his machine accessing download.opensuse.org, to see where it was redirected, and where it spent most time (while downloading some package). We found a mirror which was really slow, and I could disable it. I have a suspicion though, that we have more such mirrors, because I have got some similar reports from recently. But how to find out? People only complain about slowness, without the ability to give any useful detail. See http://news.opensuse.org/2008/09/23/upcoming-factory-changes/#comments (http://news.opensuse.org/2008/09/23/upcoming-factory-changes/#comments) for examples of this. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305320

1 18

[openFate 305694] Separate Desktop / Server Kernels
by fate_noreply＠suse.de 18 Aug '09

18 Aug '09

Feature added by: Dean Hilkewich (deanjo13) Feature #305694, revision 1, last change by Title: Separate Desktop / Server Kernels openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Dean Hilkewich (deanjo13) Partner organization: openSUSE.org Description: It seems to me that the current default kernels are somewhat hurting openSUSE's performance perception. Current kernel configs are OK but are not very well suited for desktop usage. In the future I would like to see a kernel package that is optimized for desktop usage. Current timer settings and no preemption really (sometimes drastically) hurts openGL performance and applications such as wine and causes alot of issues such as audio studdering. It would be nice to see a separate desktop performance kernel package with options such as Preemption model set to Preemptable Kenel (low-latency Desktop) and Timer Frequency Set to 1000 Hz, HPET support, Tickless System, disable optimize for size, disable Control Group support and disable Group CPU scheduler. You could also disable items and modules that are extremely rare in a desktop environment such as ATM support, Infiniband etc etc as these are not typically used in a desktop scenario which would be a large majority of openSUSE users. Further performance enhancements would also be done through out the system aimed at desktop use as well such as disabling barriers (even making it a simple checkmark option in the partitioner). Such optimizations for desktop usage can overcome openSUSE's reputation as being slower then the other mainstream distro's. The kernel settings alone can make up to a 30-40% increase in framerates in wine games for example and can cure alot of hiccups in multimedia apps. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305694

1 53

[openFATE 306941] Live Per-process I/O graph similar to iotop
by fate_noreply＠suse.de 18 Aug '09

18 Aug '09

Feature added by: Nikanth K (nikanth) Feature #306941, revision 1 Title: Live Per-process I/O graph similar to iotop Hackweek IV: Unconfirmed Priority Requester: Important Requested by: Nikanth K (nikanth) Description: iotop has a similar interface to top but dislays I/O data. But I/O could be spiky and it is easy to miss I/O events. Watching a real-time graph of it, would be more interesting. Also most of the time I write only C code. So I would use this oppurtunity to keep abreast modern languages like python, Java,... The iotop code which I need to refer is in python, and I would write this application in Java!!! -- openSUSE Feature: https://features.opensuse.org/306941

1 7

[openFATE 306365] iFolder support for Mobile platform
by fate_noreply＠suse.de 18 Aug '09

18 Aug '09

Feature added by: Biswajeet Mahapatra (mbiswajeet) Feature #306365, revision 1, last change by Title: iFolder support for Mobile platform Requested by: Biswajeet Mahapatra (mbiswajeet) Description: iFolder for mobile -- openSUSE Feature: https://features.opensuse.org/306365

1 2

[openFate 305680] access table contents in YaST in more ways than just by push buttons
by fate_noreply＠suse.de 17 Aug '09

17 Aug '09

Feature added by: Martin Schmidkunz (mschmidkunz) Feature #305680, revision 1, last change by Title: access table contents in YaST in more ways than just by push buttons openSUSE-11.2: New Priority Requester: Important Requested by: Martin Schmidkunz (mschmidkunz) Interested: Johannes Meixner (jsmeix) Interested: Katarina Machalkova (kmachalkova) Interested: Lukas Ocilka (locilka) Interested: Martin Vidner (mvidner) Interested: Ricardo Cruz (rpmcruz) Description: There is feedback (e.g. http://mvidner.blogspot.com/2009/01/yast-ui-table-usability.html) that users might get confused with the fact that table actions (performed on the table items) are accesible only as push buttons below the table. What users are used to from other GUI applications and what they miss in YaST UI is: a) context menu activated by right click on table item (e.g. edit/delete this item) b) more function key bindings (e.g. 'Delete' key will do the same what would pushing delete button do) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305680

1 6

[openFATE 306913] zypper lu should show installed version of package
by fate_noreply＠suse.de 14 Aug '09

14 Aug '09

Feature added by: Atri Bhattacharya (badshah400) Feature #306913, revision 1 Title: zypper lu should show installed version of package openSUSE-11.2: Unconfirmed Priority Requester: Mandatory Requested by: Atri Bhattacharya (badshah400) Description: It is very necessary for zypper lu to show the version of the installed packages for which updates/upgrades have been detected. This way, one will be able to see if a package has a major or minor upgrade and accordingly decide whether he wants to update it. Currently it only shows the available version, and this is insufficient information for a user to decide whether he wants the update or not. Use Case: 1) zypper lu -a from terminal 2) Upgrades for package foo detected. Installed version: 1.0.x Available version: 1.0.y User chooses not to install this minor update. 3) Upgrades for package foo2 detected. Installed version: 1.0.x Available version: 1.1.y User decides this is a big upgrade, goes for it. -- openSUSE Feature: https://features.opensuse.org/306913

1 7

[openFATE 306657] Core technologies we wish to see
by fate_noreply＠suse.de 14 Aug '09

14 Aug '09

Feature added by: jimbo bigcreed (Dimble_ThriceFoon) Feature #306657, revision 1 Title: Core technologies we wish to see openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: jimbo bigcreed (dimble_thricefoon) Description: This request revolves around the desire for 11.2 to implement some core technologies due out in Q3 2009 that will ensure the distribution is not obscelesent long before it is replaced by 11.3 in Q3 2010. These core technologies include: 1. Kernel 2.6.31 (due: end august/ start september). By the time 11.2 arrives in mid november the 2.6.31 kernel will already be ten weeks old, and 2.6.30 will be over six months old. 2. Xorg 7.5 / x-server 1.7 (due: mid august) By the time 11.2 arrives in mid november the x-server 1.6 will already be over six months old, and X.org 7.4 itself will be over a year old. The inclusion of X.org 7.5 and kernel 2.6.31 will keep 11.2 fresh and relevant throughout its nine month life, and prevent the perception of staleness among suse enthusiasts in 2010. -- openSUSE Feature: https://features.opensuse.org/306657

1 28

[openFATE 306654] List versions of packages in zypper displays
by fate_noreply＠suse.de 14 Aug '09

14 Aug '09

Feature added by: Luc de Louw (delouw) Feature #306654, revision 1 Title: List versions of packages in zypper displays openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Luc de Louw (delouw) Description: It would be quite useful when having information on package versions being installed/updated etc. -- openSUSE Feature: https://features.opensuse.org/306654

1 6

[openFATE 306644] The browser link in the desktop panel should point to Firefox
by fate_noreply＠suse.de 14 Aug '09

14 Aug '09

Feature added by: Hugo Palma (hpalma) Feature #306644, revision 1 Title: The browser link in the desktop panel should point to Firefox openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Hugo Palma (hpalma) Description: Firefox is the shown as the default browser everywhere except in the desktop panel where the link to the browser points to Konqueror. -- openSUSE Feature: https://features.opensuse.org/306644

1 9

[openFATE 306643] Include Midnight Commander on the LiveCDs
by fate_noreply＠suse.de 14 Aug '09

14 Aug '09

Feature added by: Rastislav Krupansky (ra100) Feature #306643, revision 1 Title: Include Midnight Commander on the LiveCDs openSUSE-11.2: Unconfirmed Priority Requester: Neutral Requested by: Rastislav Krupansky (ra100) Description: According to requests on factory and kde mailing lists it would be useful for many people to include Midnight Commander on the LiveCDs by default. http://lists.opensuse.org/opensuse-factory/2009-07/msg00049.html http://lists.opensuse.org/opensuse-kde/2009-07/msg00004.html -- openSUSE Feature: https://features.opensuse.org/306643

1 9

[openFATE 306629] Install from ISO
by fate_noreply＠suse.de 14 Aug '09

14 Aug '09

Feature added by: jp redpos (jpredpos) Feature #306629, revision 1 Title: Install from ISO openFATE: Unconfirmed Priority Requester: Neutral Requested by: jp redpos (jpredpos) Description: I could be nice to install opensuse from the .iso in other disk or partition. And boot to install with other very small iso, that could burn in a pen-usb. -- openSUSE Feature: https://features.opensuse.org/306629

1 4

[openFATE 306526] Pull needed dependencies when installing from a local file
by fate_noreply＠suse.de 14 Aug '09

14 Aug '09

Feature added by: Piotrek Juzwiak (BenderBendingRodriguez) Feature #306526, revision 1 Title: Pull needed dependencies when installing from a local file openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Piotrek Juzwiak (benderbendingrodriguez) Description: It would be great if it would be possible for YaST? to install any necessary packages when installing something from a local file. For example: VirtualBox rpm package needs pam-devel which would have to be installed by invoking YaST first (not everyone knows what to do when they encounter a message saying that they're missing a dependency). So it would be great for YaST to pull the needed dependency or say that they are not available. This would simplify installation of many packages for new users. -- openSUSE Feature: https://features.opensuse.org/306526

1 10

[openFATE 306450] Recent NetworkManager >= 0.7.1
by fate_noreply＠suse.de 14 Aug '09

14 Aug '09

Feature added by: Carsten Hoeger (choeger) Feature #306450, revision 1, last change by Title: Recent NetworkManager >= 0.7.1 openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Carsten Hoeger (choeger) Description: Recent Networkmanager versions support more mobile broadband devices. -- openSUSE Feature: https://features.opensuse.org/306450

1 7

[openFATE 306230] Auto-Reset the screen settings
by fate_noreply＠suse.de 14 Aug '09

14 Aug '09

Feature added by: Marcel Müller (open_assistant) Feature #306230, revision 1, last change by Title: Auto-Reset the screen settings openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Marcel Müller (open_assistant) Description: The "Bildschirmeinstellungen"(~screen settings, don't know the name in the english version, the little Monitor in the Gnome panel, where you can set the screen solution and the frequenzy) should reset the solution after 30 or 15 seconds automatically, if you don't press save. Like in Windows or SaX2. It would avoid much trouble if you choose the wrong settings. -- openSUSE Feature: https://features.opensuse.org/306230

1 6

[openFATE 305803] improve command_not_found_helper speed
by fate_noreply＠suse.de 14 Aug '09

14 Aug '09

Feature added by: Susanne Oberhauser (froh) Feature #305803, revision 1, last change by Title: improve command_not_found_helper speed openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Susanne Oberhauser (froh) Description: In the discussion on opensuse-factory [opensuse-factory] issues with command-not-found speed (Message-ID: <20081210084607.GA2988@taygeta>), I've suggested a different approach: I'd very much prefer bash to tell me without any delay: Command not found. If this is not a typo, type "man make-it-work" for help. And then the make-it-work man page will tell you right away to run "make-it-work commandname' to locate and install the package providing fancytool. with a little practice you will go one back in history, prefix your last command with 'make-it-work ' and have fun... imho the current solution is solving a problem that doesn't really exist (pretend all software is preinstalled) and creates a new one (lag). Michal Vyskocil pointed out that such magic should at least look in /sbin and /usr/sbin and give a usefull message if the command is found there: command found in /sbin or /usr/sbin. Maybe retry as root, e.g. with 'sudo $command' -- openSUSE Feature: https://features.opensuse.org/305803

1 6

[openFate 305658] Official USB stick images
by fate_noreply＠suse.de 14 Aug '09

14 Aug '09

Feature added by: Stephan Binner <stbinner(a)novell.com> Feature #305658, revision 1, last change by Title: Official USB stick images openSUSE-11.2: New Priority Requester: Desirable Requested by: Stephan Binner (beineri) Description: It would like to see openSUSE releases with official USB images (one with KDE, one with GNOME) next to the Live-CDs. As alternative the Live-CD images could be mastered in a way that they also can boot from USB (afaik they are not able atm) together with a small app/script to install them to USB - other distributions offer that. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305658

1 49

[openFate 305318] Move gconf schemas to /usr
by fate_noreply＠suse.de 14 Aug '09

14 Aug '09

Feature added by: Vincent Untz <vuntz(a)novell.com> Feature #305318, revision 1, last change by Title: Move gconf schemas to /usr openSUSE-11.2: New Priority Requester: Desirable Requested by: Vincent Untz <vuntz(a)novell.com> Partner organization: openSUSE.org Description: We store gconf schemas in /etc/gconf. However, the schemas are not configuration files, but simply data. Therefore, we should move the schemas to /usr. Simply changing a line in /etc/gconf/2/path should make gconf work with the new location. Note that Debian already implements this. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305318

1 7

[openFate 305149] [Feature-request] Yast Expert Partitioner: should not require mounting "/" root partition
by fate_noreply＠suse.de 14 Aug '09

14 Aug '09

Feature added by: Arvin Schnell <aschnell(a)novell.com> Feature #305149, revision 1, last change by Title: [Feature-request] Yast Expert Partitioner: should not require mounting "/" root partition openSUSE-11.2: New Priority Requester: Desirable Requested by: Alexey Eremenko <al4321(a)gmail.com> Partner organization: openSUSE.org Description: Hi All ! Since openSUSE 11.1 will have brand new expert partitioner, I would like to request the ability to use SUSE's partitioner for partition hard disks for other operating systems. Currently it is not possible, because SUSE requires mounting "/" root partition. In some cases I need to install third-party OSes before I install openSUSE, so I want to use SUSE flexible partitioner to partition and format the hard disk, then install the other OSes and only in the end I want to install openSUSE. -Alexey Discussion: #1: Arvin Schnell <aschnell(a)novell.com> (2008-08-04 08:41:18) So in a nutshell you want to use the partitioner as a separate program (started from the DVD) without the other installation features like package managment. Right? #2: Arvin Schnell <aschnell(a)novell.com> (2008-08-05 12:11:02) Not mounting "/" during installation will certainly lead to a failure so I hesitate to remove the check. But we could add a special mode with disabled checks. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305149

1 9

[openFate 305550] Port of YaST Qt Control Center to Qt4
by fate_noreply＠suse.de 14 Aug '09

14 Aug '09

Feature added by: Stephan Binner <stbinner(a)novell.com> Feature #305550, revision 1, last change by Title: Port of YaST Qt Control Center to Qt4 openSUSE-11.2: New Priority Requester: Important Requested by: Stephan Binner <stbinner(a)novell.com> Partner organization: openSUSE.org Description: The YaST Qt Control Center is one of the few remaining parts of the desktop still requiring Qt3. It should be ported to Qt4. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305550

1 23

[openFATE 306778] Better SElinux support
by fate_noreply＠suse.de 13 Aug '09

13 Aug '09

Feature added by: Luc de Louw (delouw) Feature #306778, revision 1 Title: Better SElinux support openSUSE-11.2: Unconfirmed Priority Requester: Desirable openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Luc de Louw (delouw) Description: It would be a pleasure to better SElinux support in OpenSUSE. Today most of the important tools are provided, but AFAIK not default profiles. Since SElinux is quite complicated and not that easy to handle, delivering some default profiles for the most important daemons would be a good starting point. I think SElinux would becomce more and more important since more and more distros are switching to SElinux (such as Ubuntu and Debian).SElinux is in the vanilla kernel since quite some time and is mature enough. As of today the only distributions will a good SElinux support are Fedora, CentOS and RHEL. -- openSUSE Feature: https://features.opensuse.org/306778

1 1

[openFATE 306435] Mounting remote directories during boot using sshfs
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Carlos Robinson (robin_listas) Feature #306435, revision 1, last change by Title: Mounting remote directories during boot using sshfs openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Carlos Robinson (robin_listas) Description: It should be interesting mount remote directories using sshfs during boot process. We can do it now with samba or nfs, but not sshfs. Sshfs has encription and it's fast enough. Actually we can use it by command-line from userspace only. Adding the possibility to include this in fstab file (and a possible module for yast) would be cool. (Written on behalf of non-member Alfredo Amaya) -- openSUSE Feature: https://features.opensuse.org/306435

1 2

[openFATE 306775] Yast Integration with PolicyKit
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Ney walens de Mesquita (nwm) Feature #306775, revision 1 Title: Yast Integration with PolicyKit openSUSE-11.2: Unconfirmed Priority Requester: Desirable openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Ney walens de Mesquita (nwm) Description: Would be very good, if Yast can integrate with PolicyKit permissions and provide ways of a regular non root user to configure modules and set values regarding Policykit permissions. -- openSUSE Feature: https://features.opensuse.org/306775

1 3

[openFATE 306991] SUSE Style for KDE Desktop
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Eduardo Sotomayor (Easgs) Feature #306991, revision 1 Title: SUSE Style for KDE Desktop openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Eduardo Sotomayor (easgs) Description: In KDE 3.5 there was the option to set up the menu with the option "change menu to SUSE style" but it is not available in KDE 4.2.95, are there plans to implement it or it will not be available anymore?, I think that the SUSE style is better than the KDE style. I think this feature is a must in openSUSE because a lot of people including me use this style in their desktop and are use to it, it is more practical than the default KDE Classic or Kickoff styles. -- openSUSE Feature: https://features.opensuse.org/306991

1 6

[openFATE 306980] Reengineer the softwarerepo's / create a rolling distro
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Gunter Schelfhout (xgunterx) Feature #306980, revision 1 Title: Reengineer the softwarerepo's / create a rolling distro openFATE: Unconfirmed Priority Requester: Important Requested by: Gunter Schelfhout (xgunterx) Description: The present reposystem is too complicated for lots of users. There are simply too many of them, with possible conflicts and the priority system for these repo's is too cinfusing. This should be reengineered and looking to Debian and Ubuntu is not that unwise. There should be only a few repo's: - one with all the packages for the present released version (and the other previous version which are still maintained), - one with the updates, - one for all the packages which will be incuded in the next version of OpenSUSE, - one for all the packages which are in the testing fase AND all the packages which are out of testing and will be included in the next version. This mimics indeed the 'stable-testing-unstable' system of Debian and Ubuntu but it has indeed lots of benifits: - it is easy to understand, - a system as this creates 3 subversions between the release of two versions, meaning stable-testing-unstable is a omplete working version on it own, - users can decide EASY what they prefer: a stable environment with security updates, a more or less stable environment which is tracking the feature updates from the developers more and which are to be included in the next release and a testing version which is tracking the updates of the developers on the foot and might break their environment. - more people will choose the testing environment for wanting the bleeding edge packages which will result in more bugreports which will put the actual released version to a higher standard. - from here it is just a small step to create a rolling distro ... -- openSUSE Feature: https://features.opensuse.org/306980

1 3

[openFATE 306977] allow the user select all desktop in desktop selection dialog
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Sergio Gabriel (Dahool) Feature #306977, revision 1 Title: allow the user select all desktop in desktop selection dialog openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Sergio Gabriel (dahool) Description: Replace option buttons in current desktop selection dialogs by checkboxes, so it is easier to install more than one desktop. -- openSUSE Feature: https://features.opensuse.org/306977

1 7

[openFATE 306773] Include Enomalism in openSUSE 11.2-3
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Mariano Iumiento (miumiento) Feature #306773, revision 1 Title: Include Enomalism in openSUSE 11.2-3 openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Mariano Iumiento (miumiento) Description: Please could you look at including Enomalism in the next release? Enomalism (http://www.enomalism.com) is an Open Source based Cloud Computing solution that allows the management of XEN and KVM based virtualization environments, VMware is supposed to be in roadmap, openVZ is still in testing. They are actually completing the development of the solution based on Fedora, CentOS and Red Hat (plus minor Ubuntu environments). I've tried to implement it on openSUSE 11.1 to verify how hard it would be to have it working, but there are various areas unknown to me that do not work well (python: the 2.6 version in openSUSE is too new for the software). Gartner: This is the product of the year for 2009. Gartner has made a Top 10 list of Cloud Computing solutions and 9 are SaaS (Google, Microsoft, etc.). Enomalism is, as Gartner said, the only Open Source solution and is the only one that is a software to create a private cloud rather than a service to access on the web. There is surely much to enhance, but it seems to be the only Open Source solution deserving attention (together with Eucalyptus). Cloud Computing is something that is going to be used a lot, and could also be used in future SLE releases. If it's needed for going ahead, I can try to be a tester, but would anyway need support because I'm not a developer. Hope to see news. Regards. Mariano Iumiento. -- openSUSE Feature: https://features.opensuse.org/306773

1 2

[openFATE 306768] Module in YaST2 for System Cleanup
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: John Shand (jshand2008) Feature #306768, revision 1 Title: Module in YaST2 for System Cleanup openSUSE-11.2: Unconfirmed Priority Requester: Mandatory Requested by: John Shand (jshand2008) Description: 1. This module would in effect, check, verify and remove orphaned rpm software from the computer along with removing all their entries in the software database. On verifying the above, it would warn you of any other dependencies requiring those rpms/file etc. This would be extremely useful as i install and test a lot of software everyday and i'm left with heaps of unused software afterwards. 2. This module would also check for and removes temp files from all user accounts. These sorts of files are performance snuffers in the end. 3. It would be good to have an option in the module to enable periodic scheduling to match the users needs. 4. This may or may not be a security issue, but would prefer it to be used by adminitrators only. -- openSUSE Feature: https://features.opensuse.org/306768

1 6

[openFATE 306749] Online Banking with New Zealand Banks
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: John Shand (jshand2008) Feature #306749, revision 1 Title: Online Banking with New Zealand Banks openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Requested by: John Shand (jshand2008) Description: I am using a financial program called KMyMoney 0.9.3. it is a fantastic program, but i am used to actually doing my online banking with another program i used for real time transactions and update ie. the program would store my login information in an encrpted file and automatically login into my Kiwibank account from the program itself. this would be an awesome feature for any of the financial software available for opensuse. please do your best with this feature as it would make life a heck of a lot easier thanks John -- openSUSE Feature: https://features.opensuse.org/306749

1 7

[openFATE 306592] PV Grub support in opensuse
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Josef Reidinger (jreidinger) Feature #306592, revision 1 Title: PV Grub support in opensuse openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Josef Reidinger (jreidinger) Description: To xen is added new feature that allows using own kernel in XEN guest. More info is here http://blog.xen.org/index.php/2008/08/28/xen-33-feature-pv-grub/ (http://blog.xen.org/index.php/2008/08/28/xen-33-feature-pv-grub/) . Some xen hosting services already contain this functionality http://www.linode.com/wiki/index.php/PV-GRUB (http://www.linode.com/wiki/index.php/PV-GRUB) .Discussion about this feature happen on yast-devel mailing list http://lists.opensuse.org/yast-devel/2009-06/msg00071.html (http://lists.opensuse.org/yast-devel/2009-06/msg00071.html) -- openSUSE Feature: https://features.opensuse.org/306592

1 3

[openFATE 306173] delayed insert for clipboard paste actions
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Ciaran Farrell (babelworx) Feature #306173, revision 1, last change by Title: delayed insert for clipboard paste actions ideas.opensuse.org: Unconfirmed Priority Requester: Neutral Requested by: Ciaran Farrell (babelworx) Description: One thing which has annoyed me since SUSE 9 is the interaction between (etc) KDE and the (x)clipboard. After selecting a text in a browser, etc, one would expect to be able to use the middle mouse button, or possibly ctrl-v to paste the selected text into another application. This works sometimes. However, more often than not, the expected result does not come about - either a completely different text is pasted (e.g. an 'older' clipboard entry) or nothing at all. Pasting something which you don't mean to paste into an application such as IRC, IM or a web form could mean sending information which you never meant to send - particularly if the pasting action automatically triggers submission. Thus, maybe it would be possible (in the absence of clipboard being made work as expected - and yes, I have tried all the options such as sync etc) to have a delayed insert whereby there would be a timeout of, e.g. 3 seconds after pasting. The user would have 3 seconds to frantically hit "STOP!" before the text is automatically sent. -- openSUSE Feature: https://features.opensuse.org/306173

1 3

[openFATE 306945] Window Menu enhancement
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: karthik bherin (karthikbp) Feature #306945, revision 1 Title: Window Menu enhancement openFATE: Unconfirmed Priority Requester: Desirable Requested by: karthik bherin (karthikbp) Description: The Window Menu s, top left corner with application icon, of any window can have 2 more options: 1. Launch another. 2. List the names of all windows of the same app currently open, to switch to. The is based on the research that a user tends to open "new" instances of the same app or "switch" to other windows of the same app. As an example, from a Firefox window I would like a quick access to open new Firefox window or switch to another currently open Firefox window. -- openSUSE Feature: https://features.opensuse.org/306945

1 4

[openFATE 306639] Yast-squid support for helpers
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Raimo Schmidt (raimoschmidt) Feature #306639, revision 1 Title: Yast-squid support for helpers openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Raimo Schmidt (raimoschmidt) Description: It would be nice to make support for external helpers during configuring squid with yast-squid For example I need Squid authorization for LDAP users -- openSUSE Feature: https://features.opensuse.org/306639

1 5

[openFATE 306638] Yast-mail + Dovecot
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Raimo Schmidt (raimoschmidt) Feature #306638, revision 1 Title: Yast-mail + Dovecot openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Raimo Schmidt (raimoschmidt) Description: WE need to add support for Dovecot IMAP Server in Yast2-mail. It will be really helpful -- openSUSE Feature: https://features.opensuse.org/306638

1 3

[openFATE 306328] Yast Help Button Documentation Needs Specific Application/Srvice Overview in most all Yast Services
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Karl Eichwalder (keichwa) Feature #306328, revision 1, last change by Title: Yast Help Button Documentation Needs Specific Application/Srvice Overview in most all Yast Services openSUSE-11.2: New Priority Requester: Desirable Requested by: Scott Couston (zczc2311) Description: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.0.7) Gecko/2009022800 SUSE/3.0.7-1.1.6 Firefox/3.0.7 I will use the help button in Yast>Firewall>Interface to provide the consent of why I fell we need service overview for most each Yast Service. The assumption is that everyone uses a Linux PC to either provide NAT or a point where 1 PC has the only direct WAN interface as well as a second LAN Interface. In some networks, normally only those that are domain based have a dedicated PC to distribute comms and this is the only PC that has 1 network card in the External Zone, for example, and has a second Network Card in the Internal one which allocates either real IP Distribution to the LAN or NAT'ed 192.168.... /24 Black Hole Private IP's For example the contact sensitive help that is presented on the Interface line is * ** nterfaces Here, assign your network devices into firewall zones by selecting the device in the table and clicking Change. Enter special strings, like any, using Custom. You can also enter interfaces not yet configured here. If you need masquerading, the string any is not allowed. Every network device should be assigned to a firewall zone. Network traffic through any unassigned interface is blocked. * ** I think we need a Service Overview on the startup Help Button contact and subsequent link references to that from down wind services of the applications further help messages. Here at the Service Overview Help we need the current text and reference to Service Overview to explain situations where a PC is dedicated to sit between the LAN (Internal Zone) and the WAN (External Zone) and is configured to allocate either Many Public IP's to the LAN or NATed Black Hole IPs to the LAN. I am not sure what is happening outside of my home country Australia as I have not been away for 3 years, however Unless a Business Wants to maintain their own Domain and maintain their own Web Server the above is a mute point. Almost all Modem Hardware shipped automatically for no cost from all their DSL providers will contain Ethernet and WIFI access, with routed comms using NAT, and most all support double-directional SPI Firewalls, NAT, and complete routing capabilities in one box. In the case of a small business or a Network Home user, if asked, I will replace their old DSL Modem to at very least the above services. .AU in Large Homes and Small Business are dumping their software firewalls, particularly those which are Windoze users as they really need an unbelievable amount of comms knowledge to just run their major software Firewalls. We are very fortunate not to be in a disaster of needing an advanced degree in comms to use our suse firewalls - however the point remains about the vehicle responsible for connection of multiple PC to the Net. Just about every small Business owner farms out the WEB Server duties to a purpose facility such as www.dnsexit.com or many similar services and as such never have their Linux PC distributing the comms and web Services. I dont know if we have the ability to present any graphics in YAST help, however I think each and every YaSt Service should have an Application Overview and a graphic diagram if possible when the Help Button is selected. There are a great number of Yast Services that only Businesses with a T-n Internet connection will use PC hardware to supply downwards TCP comms IP's, web Services etc etc etc. Perhaps if we offer help in a System Over View from the Help Button of the first stage of most all Yast Services, and link Help Specific information to Help on further use of a Yast Service, we might find users out there who really do not know what enormous services power they have if they can read each Yast Application's Short but accurate Service Overview. Your thoughts? Reproducible: Always Steps to Reproduce: 1.Enhancement Request in Overview aimed at 11.2 2. 3. Actual Results: Enhancement Request in Overview aimed at 11.2 Expected Results: Enhancement Request in Overview aimed at 11.2 Relations: - Yast Help Button Documentation Needs Specific Application/Srvice Overview in most all Yast Services (novell/bugzilla/id: 491208) https://bugzilla.novell.com/show_bug.cgi?id=491208 -- openSUSE Feature: https://features.opensuse.org/306328

1 3

[openFATE 305784] Wireless light blinks all the time
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Robert Lewis (rll123) Feature #305784, revision 1, last change by Title: Wireless light blinks all the time openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Robert Lewis (rll123) Partner organization: openSUSE.org Description: The LED blinking is very distracting and needs to be controlable. The LED blinks when traffic goes through the wireless card. However you can configure the LED behavior in /sys/class/net/wlanX/device/leds. For example something like echo none > /sys/class/net/wlanX/device/leds/*TX/trigger echo none > /sys/class/net/wlanX/device/leds/*RX/trigger echo none > /sys/class/net/wlanX/device/leds/*assoc/trigger should deactivate the blinking while traffic is received or transmitted. Just play with the LED triggers to get the desired behavior. This is a work around for a few people not afraid to muck with such things but a GUI user interface to turn this on/off will be needed for most people. I think we need YaST options in the wireless network area to tune the LED behavior. > Agreed. A graphical user interface would be very nice for tuning the LED > behavior. I suggest to open a feature request at [2] for that. > >Thanks, > Helmut -- openSUSE Feature: https://features.opensuse.org/305784

1 5

[openFATE 306275] Import Windows Document in suse 11.2 installation
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: andrea florio (anubisg1) Feature #306275, revision 1, last change by Title: Import Windows Document in suse 11.2 installation openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: andrea florio (anubisg1) Description: lots of distros (ubuntu mandriva and so on) allow during installation time to import documents from an existing windows partition. i think should be a greate idea do the same thing with suse. -- openSUSE Feature: https://features.opensuse.org/306275

1 6

[openFATE 306339] YaST module for setting up local OBS
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Dean Hilkewich (deanjo13) Feature #306339, revision 1, last change by Title: YaST module for setting up local OBS Buildservice: Unconfirmed Priority Requester: Important openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Dean Hilkewich (deanjo13) Description: It seems to me that one module that is sorely missing from yast is a local OBS module. It could greatly simplify the process and perhaps enable more people to cut their teeth on how to use it effectively instead of trying to build something on the hosted OBS which restricts what they can build without violating the terms and often involves a long wait to even see if something builds or fails. This whole process in a yast module might encourage people to use OBS. http://en.opensuse.org/Build_Service/Build_Service_Installation_Tutorial/op… -- openSUSE Feature: https://features.opensuse.org/306339

1 7

[openFate 305697] Raid support in sysinfo://
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Dean Hilkewich (deanjo13) Feature #305697, revision 1, last change by Title: Raid support in sysinfo:// openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Dean Hilkewich (deanjo13) Partner organization: openSUSE.org Description: Can we please finally get support for raid devices in the My Computer / Sysinfo screen. This has been asked for repeatedly over the releases and still has not appeared. mdraid / dmraid setups are common, lets get some support for showing them in those screens. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305697

1 7

[openFATE 306920] Dolphin command history
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Albert Thuswaldner (thuswa) Feature #306920, revision 1 Title: Dolphin command history openFATE: Unconfirmed Priority Requester: Neutral Requested by: Albert Thuswaldner (thuswa) Description: Just a quite unfinished idea here, see if I can explain it... Wouldn't it be great with a command history in dolphin? Think something analogues to the history page in a web browser combined with the bash history (if you have used Matlab version 5 or later you probably have an idea what I am sort of getting at: http://matlab.izmiran.ru/help/techdoc/ref/commandhistory.html). Basically an interactive page which lists the previously performed file operations in dolphin, In it's simplest form something like this: Today (2009-06-20) ------------------------ move file | source path | destination change dir | source path | destination Yesterday ---------------------------------- ...... In terms of use cases you could se several * Undo/redo list * Simple way to repeat a command (just click on list entry) * If you make the interaction really clever you could use it to create simple macros , mark the entries in history that you want to include -> save for later * Log of what you have done with your files. * Probably more use cases that I can not think of right now,,, Ok with that said, I will not give you the pleasure to cut this to pieces all by your self, I will be the first to "help" you doing that ;): 1. Probably most would use the command-line for several of the use cases above (I do it myself and I am happy doing that) 2. To some extent this Idea intersects with other concepts, Time machine type functionality for instance. Still I think it is an idea worth investigating, don't you? -- openSUSE Feature: https://features.opensuse.org/306920

1 3

[openFATE 306777] Yast Proxy Module GNOME integration
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Ney walens de Mesquita (nwm) Feature #306777, revision 1 Title: Yast Proxy Module GNOME integration openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Ney walens de Mesquita (nwm) Description: Would be nice if Yast Proxy module can integrate with Gnome Proxy setting. One of the problens about Proxy Module is that set System Proxy and not gconf configuration. This can cause a problem with firefox when the proxy settings has changed by Yast and Gnome relly on System Proxy and no in GCONF. Apparently Firefox by default relly in gconf. -- openSUSE Feature: https://features.opensuse.org/306777

1 4

[openFATE 306955] Shortcut trigger on KDEto menu entry
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Roman Bysh (Romanator) Feature #306955, revision 1 Title: Shortcut trigger on KDEto menu entry openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Roman Bysh (romanator) Description: Ever since we moved from KDE-3.5.x to KDE-4.3, we have lost the ability to use i.e. ALT+CTRL+K as a shortcut. It always reverts to CTRL+ALT+K. KDE-3.5 allowed the correct shortcut trigger. Can we add this shortcut trigger order back in to KDE-4.3? -- openSUSE Feature: https://features.opensuse.org/306955

1 1

[openFATE 306780] Change icons on root (/) folder.
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Umar Ahmed (umar420e) Feature #306780, revision 1 Title: Change icons on root (/) folder. openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Umar Ahmed (umar420e) Description: It is difficult to find the use of the folders located in the root for a new linux user or a user who switched from windows, so, the there should be the icons in the root folder which can show the function of each folder which makes the os more user friendly. -- openSUSE Feature: https://features.opensuse.org/306780

1 3

[openFATE 306912] Enhance F-Spot
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Heribert Riesbeck (ve3fd) Feature #306912, revision 1 Title: Enhance F-Spot openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Heribert Riesbeck (ve3fd) Description: In order to make F-Spot more usable I recommend to (i) add camera profiles and (ii) allow for collections which are visible in the sidebar. In other words select pictures from a variety of events or whatever tags and recatalog them into quick collections. The underlying reasoning for this is, I would like to get away from Lightroom. Would be quite desirable for photographers. -- openSUSE Feature: https://features.opensuse.org/306912

1 1

[openFATE 306897] PHP5.3
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Ralf Becker (RalfBeckerKL) Feature #306897, revision 1 Title: PHP5.3 openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Ralf Becker (ralfbeckerkl) Description: I would love to see php5.3 included in the next openSUSE release (11.2). It' included many useful new features and openSUSE could be one of the first distros to include it. EGroupware (www.egroupware.org) is working with php5.3. Ralf -- openSUSE Feature: https://features.opensuse.org/306897

1 1

[openFATE 306462] Evaluate distributability of MPEG container codecs
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Stanislav Brabec (sbrabec) Feature #306462, revision 1, last change by Title: Evaluate distributability of MPEG container codecs openSUSE-11.2: New Priority Requester: Desirable Requested by: Stanislav Brabec (sbrabec) Description: Due to uncertain legal status of MPEG stream and transport stream format decoders, its implementation is not part of our products. It would be nice to evaluate its legal status and make possible to decode MPEG2/4 videos using free video and audio codecs, for example Dirac video. Decoding a video requires finding of synchronization points (transport stream decoding, for a stream broadcasting) demultiplexing (stream decoding), then decoding video (passing video sub-stream to the video codec) and audio (passing sound sub-stream to the sound codec). It is known, that video codecs for MPEG-2/4 are part of MPEG LA (http://www.mpegla.com/) patent portfolio. It is known, that audio codecs for MPEG-2/4 are part of VIA Licensing (http://www.vialicensing.com/) and Thomson (http://mp3licensing.com/) patent portfolios. Legal status of the stream operations (transport stream synchronization, multiplexing and demultiplexing) is not known. It may be covered by some patents, but it is possible that there are no patents covering the stream container formats. References: https://bugzilla.novell.com/show_bug.cgi?id=483592 -- openSUSE Feature: https://features.opensuse.org/306462

1 2

[openFATE 306461] Evaluate distributability of AC3/A52
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Stanislav Brabec (sbrabec) Feature #306461, revision 1, last change by Title: Evaluate distributability of AC3/A52 openSUSE-11.2: New Priority Requester: Desirable Requested by: Stanislav Brabec (sbrabec) Description: It would be nice to have AC3/A52 codecs enabled in our multimedia applications. Now it's disabled due to its uncertain legal status. The issue need a legal research. Some resources on the internet mention Dolby Laboratories, Inc. as a patent holder. But there is no mention of patents is on their web, no mention whether "AC-3" (which this particular decoder uses to indicate the decoding and downmix methods) is a trademark. Maybe Dolby owns patent to technology, maybe only copyright on implementation. It is also possible, that all relevant patens already expired. A/52 / AC3 is the ATSC's (Advanced Televison Systems Commitee's) audio codec standard for HDTV. Coincidentally, it's also used for DVDs. Also known as ATSC A/52, Digital Audio Compression (AC-3), United States Advanced Television Committee. References: https://bugzilla.novell.com/show_bug.cgi?id=483592 -- openSUSE Feature: https://features.opensuse.org/306461

1 2

[openFATE 306623] Integrate openFATE with Bugzilla
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Andrés G. Aragoneses (knocte) Feature #306623, revision 1 Title: Integrate openFATE with Bugzilla openFATE: Unconfirmed Priority Requester: Important Requested by: Andrés G. Aragoneses (knocte) Description: I really don't understand why we are using openFATE instead of bugzilla for tracking features... But anyway, I think we can live in both worlds. Just make openFATE indeed by a Bugzilla frontend for enhancements and we're ready to go. Of course this requires a serious re-architecture of openFATE codebase, but it would please the community around both projects and it would merge feedback mechanisms. -- openSUSE Feature: https://features.opensuse.org/306623

1 4

[openFATE 306304] support "Obsolete this by another package"
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Stanislav Brabec (sbrabec) Feature #306304, revision 1, last change by Title: support "Obsolete this by another package" openSUSE-11.2: New Priority Requester: Desirable Requested by: Stanislav Brabec (sbrabec) Partner organization: openSUSE.org Description: If third party wants to terminate a temporary branch of a package, which should is obsoleted by the mainline, adding Obsoletes: foo-old-branch into the mainline package is not an option (it's possible only for official packages). Support for an Obsolete tag counterpart initiated by the existing package would fix this situation. Example: Name: gimp-unstable Version: 2.5.23 Provides: gimp = %{version} ObsoleteBy: gimp >= 2.6 It would allow to provide mainline gimp packages without Obsoletes: gimp-unstable < 2.6 and even allow thitd partines to create temporary branches of packages. Business case (Partner benefit): openSUSE.org: Providing a significantly modified packages, that are known to be obsolete after upgrade to the -- openSUSE Feature: https://features.opensuse.org/306304

1 6

[openFATE 306533] automatic mailinglists for projects
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: Ludwig Nussel (lnussel) Feature #306533, revision 1 Title: automatic mailinglists for projects Buildservice: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Description: In order do coordinate between different people in a obs project itwould be nice if the buildservice automatically providedmaillinglists for each project. Something likePROJECTNAME(a)build.opensuse.org orPROJECTNAME+PACKAGE(a)build.opensuse.org. Mails to such addressesshoudl be forwarded to the project/package maintainers. That way theproject and user list would not have to be synced between the buildservice and a separate mailinglist manager.In a further step the build service could allow interested personsthat are not maintainers to sign up as well. -- openSUSE Feature: https://features.opensuse.org/306533

1 4

[openFATE 306503] LiveCD: Save installer settings in case of abort and rerun
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: Jakub Rusinek (liviopl) Feature #306503, revision 1 Title: LiveCD: Save installer settings in case of abort and rerun openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Jakub Rusinek (liviopl) Description: Some people may encounter problems using installer and abort installation and rerun it later. Installer should remember settings to make their lives easier. -- openSUSE Feature: https://features.opensuse.org/306503

1 2

[openFATE 306366] Need ability to add business case during fate creation over web.
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: Joe Harmon (jaharmon) Feature #306366, revision 1, last change by Title: Need ability to add business case during fate creation over web. openFATE: Unconfirmed Priority Requester: Important Requested by: Joe Harmon (jaharmon) Description: When creating a new feature using fate.novell.com you have the ability to create a use case, test case, but not the ability to add a business case. Can we get that option added as well? -- openSUSE Feature: https://features.opensuse.org/306366

1 8

[openFATE 306595] Yast2 package manager: Save package selection on abort/cancel, recover/resume at
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: Vincent Petry (PVince81) Feature #306595, revision 1 Title: Yast2 package manager: Save package selection on abort/cancel, recover/resume at openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Vincent Petry (pvince81) Description: >From bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=506968 In the following cases, I happen to cancel a long yast installation/update:1) When I figure out I forgot to select a package for the big install/update.2) When I want to install a small package, but can't because yast is lockingrpm/zypper.3) When the internet connection is too slow, and I'd like to cancel it for nowand try again later.4) When I figure out the install will take longer than planned, and I want toturn the computer off and resume the install the next day.After each of these possible cases, I wish I could simply resume theinstallation from where it was stopped, or at least recover the packageselection I made, especially if it took me a long time to pick the packages.Steps to Reproduce:1. Open yast2 and "Install software"2. Spend some time select a lot of packages to install3. Click "Ok", and let the install run.4. At some time cancel the installation5. Restart Yast "Install software"Actual Results: Frustraction, because at step 5, the package selection is gone (especially ifyou took a long time to pick them), and even though some of the packages havealready been installed, the rest of the selection (from step 2) must be doneagain.Expected Results: When clicking on "Cancel" at step 4, yast saves the current package selection(or the to-be-installed list) into a temporary file.At step 5, when restarting yast, it tells that an install has been aborted andlets the user choose to recover the package selection from that point.Possible variations:1) When yast starts, don't ask anything, but provide a menu item or button toreload the backed-up package selection.2) When cancelling, the dialog could ask the user if he/she wishes to resumethe installation later. If yes, the package selection is saved, else it is justforgotten. -- openSUSE Feature: https://features.opensuse.org/306595

1 3

[openFATE 306596] Yast2 package manager: Select/taboo packages by feature/provides/hardware
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: Vincent Petry (PVince81) Feature #306596, revision 1 Title: Yast2 package manager: Select/taboo packages by feature/provides/hardware openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Vincent Petry (pvince81) Description: >From bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=506970 I have no bluetooth devices, so it would be convenient to prevent/taboo anybluetooth package to become automatically installed on the system. I have an intel GPU, but it didn't prevent the Xorg packages for radeon andunichrome to get automatically installed (suggested packages?). It would be convenient to have a way to select or taboo packages by feature orhardware availability. It could look like a metapackage or an option that couldbe selected, like: "Bluetooth -> Never install" "Graphics driver - Intel -> Selected" "Graphics driver - Radeon -> Never install" -- openSUSE Feature: https://features.opensuse.org/306596

1 3

[openFATE 306645] Secure home directory permissions by default
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: Jan Engelhardt (jengelh) Feature #306645, revision 1 Title: Secure home directory permissions by default openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Jan Engelhardt (jengelh) Description: Also see https://bugzilla.novell.com/show_bug.cgi?id=518550 . The default for home directories is 0755 (umask 022 in login.defs), and here's the fate entry to change it to 0711 (umask 066). -- openSUSE Feature: https://features.opensuse.org/306645

1 8

[openFATE 306653] Default confirmation in zypper should be set to No
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: Luc de Louw (delouw) Feature #306653, revision 1 Title: Default confirmation in zypper should be set to No openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Luc de Louw (delouw) Description: At the moment when doing zypper remove whatever the default of the confimation is set to YES. This is quite dangerous because dependencies will also be removed. I suggest to set all default confirmation answers to NO to prevent unintended actions when accidentialy pressing the enter key in the wrong terminal or similar Murphy occurences. -- openSUSE Feature: https://features.opensuse.org/306653

1 5

[openFATE 306171] openfate login is not usual novell one
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: Jean-Daniel Dodin (jdd_sysop) Feature #306171, revision 1, last change by Title: openfate login is not usual novell one openFATE: Unconfirmed Priority Requester: Important Requested by: Jean-Daniel Dodin (jdd_sysop) Description: The openfate login is unusual. It's not recognised by Firefox. Usual Novell login don't have fields in the source page, but only a login one that send to the novell page. Here I have to key in login/pass then I go to an other page and have to rekey why? -- openSUSE Feature: https://features.opensuse.org/306171

1 2

[openFATE 305866] osc/obs: load Packages from every Project without Link
by fate_noreply＠suse.de 10 Aug '09

10 Aug '09

Feature added by: Sascha Manns (saigkill) Feature #305866, revision 1, last change by Title: osc/obs: load Packages from every Project without Link Buildservice: Unconfirmed Priority Requester: Neutral Requested by: Sascha Manns (saigkill) Description: If i build Packages with OBS/OSC, i must link Packages from other Project to my own. I wish me, that future Releases from OBS/OSC solve the depencies automaticly, and load the Packages from every Repository. Other Way, is if we give Repositories an Priority Number. So the OSC/OBS works first with the high Priority Repos. -- openSUSE Feature: https://features.opensuse.org/305866

1 8

[openFATE 306195] Add DPI option to SaX2
by fate_noreply＠suse.de 06 Aug '09

06 Aug '09

Feature added by: Vitaliy Tomin (HighwayStar) Feature #306195, revision 1, last change by Title: Add DPI option to SaX2 openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Vitaliy Tomin (highwaystar) Description: DPI are very important thing for good font rendering, it always should be equal horizontal and vertical means. Now SaX have option for set display size in millimeters, but it not usefull. By automatic detection SaX make strange DPI means like 95x101 or 84x91 or something else. This values produce ugly font rendering. I suggest to make an option to set fixed DPI for screen, or easier set of physycal screen size in millimetrs to make an wanted DPI like 96, that mean DPI : 96x96 -- openSUSE Feature: https://features.opensuse.org/306195

1 5

[openFATE 306772] kernel update only with kernel header
by fate_noreply＠suse.de 06 Aug '09

06 Aug '09

Feature added by: Matteo Zuliani (tekkkkkk) Feature #306772, revision 1 Title: kernel update only with kernel header openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Matteo Zuliani (tekkkkkk) Description: hi every time kernel update is without kernel headers. This cause some problems if on computer is present virtual machine or graphic drivers that require partial recompile Sorry for my english -- openSUSE Feature: https://features.opensuse.org/306772

1 2

[openFATE 305553] zypper: dist upgrade could error out if more than one repository with a base product exists
by fate_noreply＠suse.de 30 Jul '09

30 Jul '09

Feature changed by: Ruediger Oertel (oertel) Feature #305553, revision 22 Title: zypper: dist upgrade could error out if more than one repository with a base product exists openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Dirk Mueller (dirkmueller) Description: I've just learned over lunch that calling "zypper dup" is wrong if you have both buildservice repositories and a distribution repository enabled. apparently one has to call it with -r name, where name points to the distribution one wants to upgrade to, and the other repositories (e.g. buildservice addons) must not be dup'ed, but only updated via update -t package. I've verified that this indeed fixes the "reinstalling/downgrading package" issues everyone seems to be complaining about. It would be nice if zypp/zypper could detect this situation and advise the user, or alternatively do the right thing automatically. I'm not sure if channels of distributions (e.g. the factory channel, or a future openSUSE 11.0 channel) can be detected in some way.. if it does, then it could automatically add the -r argument if there is only one distribution channel enabled, and altneratively error out if more than one distribution channel is in the sources list and no -r argument was given. Relations: - make zypper dup error out if more than one repository exists (novell/bugzilla/id: 385972) https://bugzilla.novell.com/show_bug.cgi?id=385972 Discussion: #1: Stephan Kulow (coolo) (2008-05-11 02:20:39) * ** Bug 388956 has been marked as a duplicate of this bug. *** #2: Duncan Mac-Vicar (dmacvicar) (2008-12-10 15:31:24) Hm. If that is so, this feature is really important :O) Just a side question: how does installation handle this (if at all)? Currently they can't, we need to add means of such identification (as well as identification of update repos). yup, sounds good #3: Lukas Ocilka (locilka) (2008-05-12 06:17:43) Installation/Upgrade has the installation repository registered as the fist one, then Add-Ons or other repositories can be added or enabled. Upgrade doesn't handle how the packages are selected to be upgraded, it just calls solver. OK, some packages are dropped by installation by default :) See bug #300540. #4: Stephan Kulow (coolo) (2008-05-12 06:25:06) the main difference: it's pretty unusual to have 13 repos during distribution update with very comparable versions. While it's not to for zypper dup. BTW: another difference: installations sets YAST_IS_RUNNING=instsys, which some packages cause not to produce errors on updates. This might be good for dup, but bad for update #5: Duncan Mac-Vicar (dmacvicar) (2008-12-10 16:56:35) Note, I moved the bugzilla entry to fate, but mls claims the bug is invalid, as it is a perfect use case to do dist upgrade with various repositories. So this feature has to be evaluated with care and gathering opinions from various sources. It may be invalid. #7: Jiri Srain (jsrain) (2008-12-11 07:58:04) (reply to #5) I don't think it is invalid; I happened to downgrade several packages from OSS repo via zypper dup :-( #8: Duncan Mac-Vicar (dmacvicar) (2008-12-11 10:10:32) (reply to #7) The solution of stop-with-error if there is more than one repository is invalid because prevent the valid usecase of dist-upgrading with more than one repo enabled (as mls pointed out). What is valid about the feature, is that multiple repo upgrade can be dangerous, and we may warn the user if there are repos for different products there. #9: Jiri Srain (jsrain) (2008-12-11 10:53:42) (reply to #8) Sorry for not being precise in my comment: of course user must be able to override this error/warning/whatever. #6: Duncan Mac-Vicar (dmacvicar) (2008-12-10 18:34:19) Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if repositories are mixed. #10: Ján Kupec (jkupec) (2009-06-24 09:33:26) Michael, is this still relevant? Is this related to the planned --from option? #11: Michael Schröder (mlschroe) (2009-06-24 11:33:46) (reply to #10) This has nothing to do with --from, it's about doint 'zypper dup' to update the system to the next release while still having old repositories enabled. #12: Ján Kupec (jkupec) (2009-07-07 16:26:43) (reply to #11) So multiple repositories are not a problem in general, but multiple repos for different products are! OK, so now back to the solution: can you tell me or point me to some info abou these CPEs Duncan mentions in c#6? I guess they are part of the product solvable and are available as solv attribute? If so, all that's needed is to check whether there are multiple repos with a different product and write a warning if that's the case, right? #13: Michael Schröder (mlschroe) (2009-07-07 16:34:14) (reply to #12) ma, is there a libzypp interface? #14: Michael Andres (mlandres) (2009-07-13 14:16:11) (reply to #13) Yes. Since you can ask for a products CPEid, or for the CPEids related to a repository (supported or updated products). But I don't know if those CPEids are meanwhile included in the metadata (see bnc #459527). #15: Ján Kupec (jkupec) (2009-07-14 18:17:17) (reply to #14) OK, so this should not be too much work. So to sum it up: * zypper: show a warning in 'dup' if there are multiple base repos with different CPEids enabled. * metadata: check/include the CPEid in product metadata (who should do this?) #16: Ján Kupec (jkupec) (2009-07-27 17:30:09) (reply to #14) Rudi, please look at c#14 and 15 #17: Ján Kupec (jkupec) (2009-07-29 19:04:40) Current status: * TODO: put CPE IDs to content/prodcuts.xml metadata (still nobody assigned to do this!) * TODO: satsolver will need to parse the above (or is this ready already?) * PROBLEM: we need to figure out which repos don't go together for dup. I proposed to compare CPEs of 'base' or 'platform' repos, but we have no 'isBase' flag in product or repo metadata. Simply checking for different CPEs is not enough (think of one base product and one addon - two different CPEs, but 'dup' is OK with them). * PROBLEM: even if we'll have the 'isBase' flag, we'll be stuck in case of two different, but compatible bases, like e.g. SLES and SLED could be used standalone or with SLED as an add-on to SLES in the past. Do we still allow this? Any ideas? + #18: Ruediger Oertel (oertel) (2009-07-30 17:20:05) + adding more data (like the CPE-ids) is not a big issue. the problem for + me is rather how to obtain a CPE-id -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 305168] default to relatime
by fate_noreply＠suse.de 30 Jul '09

30 Jul '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305168, revision 26 Title: default to relatime openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-09-10 10:20:17 reject reason: This is too late for openSUSE 11.1. Postponing. Priority Requester: Mandatory openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: At least for desktops, we should reduce the memory and I/O thrash caused by atime updates, by using relatime. Relations: - bugreport from community (novell/bugzilla/id: 398616) https://bugzilla.novell.com/show_bug.cgi?id=398616 - Offers 'noatime' when 'relatime' is clearly better (novell/bugzilla/id: 461829) https://bugzilla.novell.com/show_bug.cgi?id=461829 + Documentation Impact: + Needs to be documented in release notes Discussion: #1: Robert Davies (robopensuse) (2009-01-16 15:52:09) Bug #461829 is not requesting breaking POSIX semantics by default! relatime should replace noatime option in the mount options part of partioner tool, especially now it has been improved to update atime on file access if it's older than 24 hours. Standards are important, and LRU file caches cannot be relied on if noatime usage is common, or if poor backup software touches atimes, when reading files. #2: Sven Burmeister (rabauke) (2009-01-23 01:09:47) 11.1 is out and 11.2 getting started. Did anyone hear of ubuntu suffering from using relatime by default? If not, it seems likely that there are little to none issues. #3: Stephan Kulow (coolo) (2009-05-08 16:51:21) Matthias, I would think the easiest solution is replacing the current checkbox "use noatime" with "use relatime" and make it default (possibly per product). atime is a major pain for many systems where powersave and co are affected. #4: Matthias Eckermann (mge1512) (2009-05-11 15:52:11) (reply to #3) I am not perfectly happy, as a system crash could invalide the "atime"s with "relatime" switched on; looking for supporting information though, it seems, the broader Linux community is in favour of "relatime" (with remarkable exceptions); thus I propose: * introduce "relatime" as an independend parameter * keep the "noatime" checkbox in YaST * make "relatime" default on SSDs automatically * introduce a generic switch in YaST "defaultrelatime", which can be switched on/off per product * make "relatime" default "on" for the openSUSE product Does that help? #5: Jan Kara (jankara) (2009-05-11 16:33:11) This is a bit separate to how it will all look in Yast but I wanted to point out that in current Linus's tree (going to be 2.6.30) is a patch which changes kernel's default to 'relatime'. So unless we change something, all filesystems on this or newer kernel are going to be mounted as relatime (you have to specify 'strictatime' mount option if you really wish to keep atime). #6: Stephan Kulow (coolo) (2009-05-12 10:36:27) (reply to #5) then we can leave everything as it is actually and the feature is Done once we switch to 2.6.30 #7: Jan Kara (jankara) (2009-05-12 13:08:05) (reply to #6) Yes, the original request will be fulfilled. But I believe it would be good to have a selection in partitioner tool like: "Access time behavior: <relatime|noatime|strictatime>" anyway and make 'relatime' default. Also it is a question how to behave on update - the safest would be to add 'strictatime' to filesystems that don't have any atime setting but realistically it is probably better to ask user whether he agrees to switching to relatime and default to "yes". #9: Stephan Kulow (coolo) (2009-05-12 13:45:51) (reply to #7) completely different feature IMO and way more complex (and definitely over the top of openSUSE 11.2) #10: Duncan Mac-Vicar (dmacvicar) (2009-05-12 14:00:25) (reply to #7) Do we really need this extra options really? Is there a good usecase for it? I don't want to bring something to implementation because it is "good", "cool" or "nice to have". #11: Jan Kara (jankara) (2009-05-12 15:50:33) (reply to #10) User can always edit /etc/fstab by hand so strictly speaking it's not necessary. About the usecase - there really are people who want 'strictatime' for various reasons (well, most often they are just afraid that something can break). From my POV that is enough for substituting that 'noatime' checkbox we have currently with the selection I suggested but I admit I'm not the one who'll have to implement it ;-). Regarding the update - silently changing the behavior of atime seems kind of rough to users to me. At least we should warn them (release notes?) that this is happening and that they can add 'strictatime' to /etc/fstab if they have problems with the change. #12: Andreas Jaeger (a_jaeger) (2009-06-09 15:36:15) (reply to #11) Let's add something to the release notes for those updating - and not do any other changes. #13: Arvin Schnell (aschnell) (2009-07-29 15:14:15) (reply to #12) With 2.6.30 in factory this isn't a feature for yast2-storage anymore. Andreas, if something should be added to the release notes please assigned to approptiate people. + #14: Andreas Jaeger (a_jaeger) (2009-07-30 10:06:20) + Karl, could you add something, please? + Arvin, I agree. -- openSUSE Feature: https://features.opensuse.org/305168

1 0

[openFATE 306983] Create a Single way of Managing NIC Devices
by fate_noreply＠suse.de 30 Jul '09

30 Jul '09

Feature added by: Scott Couston (zcnnnnzc) Feature #306983, revision 1 Title: Create a Single way of Managing NIC Devices openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Scott Couston (zcnnnnzc) Description: In Opensuse 11.1 the decision was made to remove Yast controll of Network Manager. This created 2 semi-dependant ways of managing Network Interface Cards, that in retrospect offered poor or impossible singular control. This decision may have had technical merit however it created a huge deal of complication and bugs as a result. At this time KDE4 NM was not available and KDE3 NM was the only form of NM available to this version of openSuse. In the case where NM is selected over IFUP, other dependant Yast Applications offered no control over the NIC and IP itself. Take the small example of the Yast Firewall. If NM was selected over IFUP, the Yast Firewall offered NO contol over the IP. If NM is selected over IFUP, the NIC(s) as a devices, offered no controll as Yast defines all dependancies over NIC(s) as a device or multiple devices. If NM is selected over IFUP during Installation, there was no facility to input static IP's or effect any controll over NM as Installation only offered the user to choose the alternate NM but not configure it. Poor or No testing of a PC that was on a LAN where NO DHCP Services were offered was obvious. Without DHCP Servies, it was not possible to Install updates as IFUP could not provide nominated DNS Services. IFUP could only set a static IP, but failed to provide DNS Services despie being present in IFUP's configuration. NM also suffered at the fate of DHCP Services. Despite Static Services being present in NM, the presence of DHCP Services overruled static entries in NM as thease were ignored. NM only provided static services so configured, when DHCP Services were Not present. The control over NIC cards became a total IF issue. Any variant from IFUP using DHCP Services and the LAN also providing them, meant we lost control over the NIC(s).* We need to decide IF we need to maintain both IFUP and NM for control over NIC(s) as of 11.1 we offer almost NO control over any variant so configured* The downline application to configure WIFI, VPN, IPV6 etc are all compromised. 2 totally different methods of appling downline services need provision for the rest of further developements. I do not think it is realistic for us to continue to maintain both IFUP and NM as the down line repercusions are so huge and without control over an IP and DNS we might as well stop developement. It is not sufficant to depend on DHCP Services always being present as we then assume a condition that may not be set. This would be akin to stating in the"Installation Requirements" and adding a line stating that OpenSuse requires DHCP Services to be present for the software to "Install and Function Correctly" Either we dump NM or IFUP. Certainly unless Yast can controll NM it must go OR if we want to take the other downline services of VPN, WIFI, IPV6; IFUP must go. Request for Comment neeeds to start, both in the technical requirements of a singular control and the userability of same. The above statments are all suypported by various bugs, mostly opened by the author. Any Commnts please? -- openSUSE Feature: https://features.opensuse.org/306983

1 0

[openFATE 306350] Implement Debian's Kaboom KDE Migration-Tool
by fate_noreply＠suse.de 29 Jul '09

29 Jul '09

Feature added by: Maximilian Maher (maxmaher) Feature #306350, revision 1, last change by Title: Implement Debian's Kaboom KDE Migration-Tool openSUSE-11.2: New Priority Requester: Mandatory Requested by: m m (mmaher) Description: kaboom is tool for migrating your KDE user settings and data files from KDE 3 to KDE 4. Depending on the options you choose, you may: 1. Use you current KDE 3 settings as initial for KDE 4. 2. Use your existing KDE 4 settings and replace current KDE 3 settings. 3. Merge current KDE 4 settings with current KDE 3 settings (experimental). 4. Start KDE with defaults settings and data. http://pkg-kde.alioth.debian.org/kaboom.html -- openSUSE Feature: https://features.opensuse.org/306350

1 7

[openFATE 305899] Package Locking
by fate_noreply＠suse.de 29 Jul '09

29 Jul '09

Feature added by: Will Stephenson (wstephenson) Feature #305899, revision 1, last change by Title: Package Locking Buildservice: Unconfirmed Priority Requester: Important Requested by: Will Stephenson (wstephenson) Description: * Lock a package ** osc co -l checks out and locks * Anyone can unlock a package (to prevent deadlock) but it has to be explicit ** https://build.opensuse.org/project/monitor to show locks and lock owners -- openSUSE Feature: https://features.opensuse.org/305899

1 8

[openFATE 305553] zypper: dist upgrade could error out if more than one repository with a base product exists
by fate_noreply＠suse.de 29 Jul '09

29 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #305553, revision 21 Title: zypper: dist upgrade could error out if more than one repository with a base product exists openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Dirk Mueller (dirkmueller) Description: I've just learned over lunch that calling "zypper dup" is wrong if you have both buildservice repositories and a distribution repository enabled. apparently one has to call it with -r name, where name points to the distribution one wants to upgrade to, and the other repositories (e.g. buildservice addons) must not be dup'ed, but only updated via update -t package. I've verified that this indeed fixes the "reinstalling/downgrading package" issues everyone seems to be complaining about. It would be nice if zypp/zypper could detect this situation and advise the user, or alternatively do the right thing automatically. I'm not sure if channels of distributions (e.g. the factory channel, or a future openSUSE 11.0 channel) can be detected in some way.. if it does, then it could automatically add the -r argument if there is only one distribution channel enabled, and altneratively error out if more than one distribution channel is in the sources list and no -r argument was given. Relations: - make zypper dup error out if more than one repository exists (novell/bugzilla/id: 385972) https://bugzilla.novell.com/show_bug.cgi?id=385972 Discussion: #1: Stephan Kulow (coolo) (2008-05-11 02:20:39) * ** Bug 388956 has been marked as a duplicate of this bug. *** #2: Duncan Mac-Vicar (dmacvicar) (2008-12-10 15:31:24) Hm. If that is so, this feature is really important :O) Just a side question: how does installation handle this (if at all)? Currently they can't, we need to add means of such identification (as well as identification of update repos). yup, sounds good #3: Lukas Ocilka (locilka) (2008-05-12 06:17:43) Installation/Upgrade has the installation repository registered as the fist one, then Add-Ons or other repositories can be added or enabled. Upgrade doesn't handle how the packages are selected to be upgraded, it just calls solver. OK, some packages are dropped by installation by default :) See bug #300540. #4: Stephan Kulow (coolo) (2008-05-12 06:25:06) the main difference: it's pretty unusual to have 13 repos during distribution update with very comparable versions. While it's not to for zypper dup. BTW: another difference: installations sets YAST_IS_RUNNING=instsys, which some packages cause not to produce errors on updates. This might be good for dup, but bad for update #5: Duncan Mac-Vicar (dmacvicar) (2008-12-10 16:56:35) Note, I moved the bugzilla entry to fate, but mls claims the bug is invalid, as it is a perfect use case to do dist upgrade with various repositories. So this feature has to be evaluated with care and gathering opinions from various sources. It may be invalid. #7: Jiri Srain (jsrain) (2008-12-11 07:58:04) (reply to #5) I don't think it is invalid; I happened to downgrade several packages from OSS repo via zypper dup :-( #8: Duncan Mac-Vicar (dmacvicar) (2008-12-11 10:10:32) (reply to #7) The solution of stop-with-error if there is more than one repository is invalid because prevent the valid usecase of dist-upgrading with more than one repo enabled (as mls pointed out). What is valid about the feature, is that multiple repo upgrade can be dangerous, and we may warn the user if there are repos for different products there. #9: Jiri Srain (jsrain) (2008-12-11 10:53:42) (reply to #8) Sorry for not being precise in my comment: of course user must be able to override this error/warning/whatever. #6: Duncan Mac-Vicar (dmacvicar) (2008-12-10 18:34:19) Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if repositories are mixed. #10: Ján Kupec (jkupec) (2009-06-24 09:33:26) Michael, is this still relevant? Is this related to the planned --from option? #11: Michael Schröder (mlschroe) (2009-06-24 11:33:46) (reply to #10) This has nothing to do with --from, it's about doint 'zypper dup' to update the system to the next release while still having old repositories enabled. #12: Ján Kupec (jkupec) (2009-07-07 16:26:43) (reply to #11) So multiple repositories are not a problem in general, but multiple repos for different products are! OK, so now back to the solution: can you tell me or point me to some info abou these CPEs Duncan mentions in c#6? I guess they are part of the product solvable and are available as solv attribute? If so, all that's needed is to check whether there are multiple repos with a different product and write a warning if that's the case, right? #13: Michael Schröder (mlschroe) (2009-07-07 16:34:14) (reply to #12) ma, is there a libzypp interface? #14: Michael Andres (mlandres) (2009-07-13 14:16:11) (reply to #13) Yes. Since you can ask for a products CPEid, or for the CPEids related to a repository (supported or updated products). But I don't know if those CPEids are meanwhile included in the metadata (see bnc #459527). #15: Ján Kupec (jkupec) (2009-07-14 18:17:17) (reply to #14) OK, so this should not be too much work. So to sum it up: * zypper: show a warning in 'dup' if there are multiple base repos with different CPEids enabled. * metadata: check/include the CPEid in product metadata (who should do this?) #16: Ján Kupec (jkupec) (2009-07-27 17:30:09) (reply to #14) Rudi, please look at c#14 and 15 + #17: Ján Kupec (jkupec) (2009-07-29 19:04:40) + Current status: + * TODO: put CPE IDs to content/prodcuts.xml metadata (still nobody + assigned to do this!) + * TODO: satsolver will need to parse the above (or is this ready + already?) + * PROBLEM: we need to figure out which repos don't go together for dup. I + proposed to compare CPEs of 'base' or 'platform' repos, but we have no + 'isBase' flag in product or repo metadata. Simply checking for + different CPEs is not enough (think of one base product and one addon - + two different CPEs, but 'dup' is OK with them). + * PROBLEM: even if we'll have the 'isBase' flag, we'll be stuck in case + of two different, but compatible bases, like e.g. SLES and SLED could + be used standalone or with SLED as an add-on to SLES in the past. Do we + still allow this? + Any ideas? -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 305168] default to relatime
by fate_noreply＠suse.de 29 Jul '09

29 Jul '09

Feature changed by: Arvin Schnell (aschnell) Feature #305168, revision 25 Title: default to relatime openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-09-10 10:20:17 reject reason: This is too late for openSUSE 11.1. Postponing. Priority Requester: Mandatory openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: At least for desktops, we should reduce the memory and I/O thrash caused by atime updates, by using relatime. Relations: - bugreport from community (novell/bugzilla/id: 398616) https://bugzilla.novell.com/show_bug.cgi?id=398616 - Offers 'noatime' when 'relatime' is clearly better (novell/bugzilla/id: 461829) https://bugzilla.novell.com/show_bug.cgi?id=461829 Discussion: #1: Robert Davies (robopensuse) (2009-01-16 15:52:09) Bug #461829 is not requesting breaking POSIX semantics by default! relatime should replace noatime option in the mount options part of partioner tool, especially now it has been improved to update atime on file access if it's older than 24 hours. Standards are important, and LRU file caches cannot be relied on if noatime usage is common, or if poor backup software touches atimes, when reading files. #2: Sven Burmeister (rabauke) (2009-01-23 01:09:47) 11.1 is out and 11.2 getting started. Did anyone hear of ubuntu suffering from using relatime by default? If not, it seems likely that there are little to none issues. #3: Stephan Kulow (coolo) (2009-05-08 16:51:21) Matthias, I would think the easiest solution is replacing the current checkbox "use noatime" with "use relatime" and make it default (possibly per product). atime is a major pain for many systems where powersave and co are affected. #4: Matthias Eckermann (mge1512) (2009-05-11 15:52:11) (reply to #3) I am not perfectly happy, as a system crash could invalide the "atime"s with "relatime" switched on; looking for supporting information though, it seems, the broader Linux community is in favour of "relatime" (with remarkable exceptions); thus I propose: * introduce "relatime" as an independend parameter * keep the "noatime" checkbox in YaST * make "relatime" default on SSDs automatically * introduce a generic switch in YaST "defaultrelatime", which can be switched on/off per product * make "relatime" default "on" for the openSUSE product Does that help? #5: Jan Kara (jankara) (2009-05-11 16:33:11) This is a bit separate to how it will all look in Yast but I wanted to point out that in current Linus's tree (going to be 2.6.30) is a patch which changes kernel's default to 'relatime'. So unless we change something, all filesystems on this or newer kernel are going to be mounted as relatime (you have to specify 'strictatime' mount option if you really wish to keep atime). #6: Stephan Kulow (coolo) (2009-05-12 10:36:27) (reply to #5) then we can leave everything as it is actually and the feature is Done once we switch to 2.6.30 #7: Jan Kara (jankara) (2009-05-12 13:08:05) (reply to #6) Yes, the original request will be fulfilled. But I believe it would be good to have a selection in partitioner tool like: "Access time behavior: <relatime|noatime|strictatime>" anyway and make 'relatime' default. Also it is a question how to behave on update - the safest would be to add 'strictatime' to filesystems that don't have any atime setting but realistically it is probably better to ask user whether he agrees to switching to relatime and default to "yes". #9: Stephan Kulow (coolo) (2009-05-12 13:45:51) (reply to #7) completely different feature IMO and way more complex (and definitely over the top of openSUSE 11.2) #10: Duncan Mac-Vicar (dmacvicar) (2009-05-12 14:00:25) (reply to #7) Do we really need this extra options really? Is there a good usecase for it? I don't want to bring something to implementation because it is "good", "cool" or "nice to have". #11: Jan Kara (jankara) (2009-05-12 15:50:33) (reply to #10) User can always edit /etc/fstab by hand so strictly speaking it's not necessary. About the usecase - there really are people who want 'strictatime' for various reasons (well, most often they are just afraid that something can break). From my POV that is enough for substituting that 'noatime' checkbox we have currently with the selection I suggested but I admit I'm not the one who'll have to implement it ;-). Regarding the update - silently changing the behavior of atime seems kind of rough to users to me. At least we should warn them (release notes?) that this is happening and that they can add 'strictatime' to /etc/fstab if they have problems with the change. #12: Andreas Jaeger (a_jaeger) (2009-06-09 15:36:15) (reply to #11) Let's add something to the release notes for those updating - and not do any other changes. + #13: Arvin Schnell (aschnell) (2009-07-29 15:14:15) (reply to #12) + With 2.6.30 in factory this isn't a feature for yast2-storage anymore. + Andreas, if something should be added to the release notes please + assigned to approptiate people. -- openSUSE Feature: https://features.opensuse.org/305168

1 0

[openFATE 306356] Icons in YaST: Use /usr/share/icons/hicolor/ as a fallback
by fate_noreply＠suse.de 29 Jul '09

29 Jul '09

Feature changed by: Katarina Machalkova (kmachalkova) Feature #306356, revision 9 Title: Icons in YaST: Use /usr/share/icons/hicolor/ as a fallback openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Lukas Ocilka (locilka) Partner organization: openSUSE.org Description: YaST icons are expected to be in /usr/share/YaST2/theme/current/icons/ directory but the list of icons is fixed because the current is a symlink to the currently installed and selected theme-directory which is different for openSUSE or SLES. If another (e.g., 3rd party) YaST module wants to add its own icon, it has to put it into the current directory which will change when using another YaST theme. The proposal is simple: If an icon is not found in the current theme, try to use /usr/share/icons/hicolor/ as a fallback. Business case (Partner benefit): openSUSE.org: 3rd party add-ons with YaST modules, Our own add-ons with YaST modules (SMT, OES)... Discussion: #1: Christoph Thiel (cthiel1) (2009-04-20 17:30:28) Makes a lot of sense to me with regard to appliances and custom YaST themes. #2: Katarina Machalkova (kmachalkova) (2009-07-29 13:00:38) Done in yast2-control-center-qt + #3: Katarina Machalkova (kmachalkova) (2009-07-29 13:09:14) + Done also in yast2-libyui and yast2-qt. Instead of one global icon + search path there can now be several search paths and they're traversed + until the correct icon is found. This is done transparently for UIs on + libyui level (for selection-like widgets). + Note I've kept the global search path in mostly for compatibility + reasons, in order not to break Gtk UI (since I don't speak Gtk and + can't adjust the code myself) but I'd like to drop it eventually. Also + icons in IconButton type of widget currently do not work in Gtk, but + that does not matter, as they're not used anywhere in YaST. + Once the Gtk part is settled, we can set this to 'done' -- openSUSE Feature: https://features.opensuse.org/306356

1 0

[openFATE 306356] Icons in YaST: Use /usr/share/icons/hicolor/ as a fallback
by fate_noreply＠suse.de 29 Jul '09

29 Jul '09

Feature changed by: Katarina Machalkova (kmachalkova) Feature #306356, revision 8 Title: Icons in YaST: Use /usr/share/icons/hicolor/ as a fallback openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Lukas Ocilka (locilka) Partner organization: openSUSE.org Description: YaST icons are expected to be in /usr/share/YaST2/theme/current/icons/ directory but the list of icons is fixed because the current is a symlink to the currently installed and selected theme-directory which is different for openSUSE or SLES. If another (e.g., 3rd party) YaST module wants to add its own icon, it has to put it into the current directory which will change when using another YaST theme. The proposal is simple: If an icon is not found in the current theme, try to use /usr/share/icons/hicolor/ as a fallback. Business case (Partner benefit): openSUSE.org: 3rd party add-ons with YaST modules, Our own add-ons with YaST modules (SMT, OES)... Discussion: #1: Christoph Thiel (cthiel1) (2009-04-20 17:30:28) Makes a lot of sense to me with regard to appliances and custom YaST themes. + #2: Katarina Machalkova (kmachalkova) (2009-07-29 13:00:38) + Done in yast2-control-center-qt -- openSUSE Feature: https://features.opensuse.org/306356

1 0

[openFATE 306844] In-line spell check in katepart
by fate_noreply＠suse.de 29 Jul '09

29 Jul '09

Feature added by: Thijs Heus (thijsdetweede) Feature #306844, revision 1 Title: In-line spell check in katepart openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Thijs Heus (thijsdetweede) Description: http://bugs.kde.org/show_bug.cgi?id=33857 Katepart (i.e., kate, kwrite and most notably kile) finally features inline spellchecking. But since this feature will only arrive in KDE4.4, openSUSE 11.2 won't see it. It seems a shame to let a feature that is so eagerly awaited lie until a year from now. Is it possible to backport it to KDE 4.3.x/openSUSE 11.2? -- openSUSE Feature: https://features.opensuse.org/306844

1 4

[openFATE 306476] Install boot entry configurable in kernel git file
by fate_noreply＠suse.de 29 Jul '09

29 Jul '09

Feature changed by: Stephan Kulow (coolo) Feature #306476, revision 9 Title: Install boot entry configurable in kernel git file openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Important Requested by: Thomas Renninger (trenn) Description: Provide a file in the kernel git which describes an installation boot entry including: - help/description - specific boot parameters - active on which arch The installation image (e.g. DVD) will then provide these specific boot entries to make it easy for: - kernel developers to add critical boot parameters required for specific HW for booting - users by providing a meaningful help at boot loader start up Currently most important settings that are coming to my mind are: - apic=bigsmp (for i386 machines with a lot cores might require that) - disable Kernel Mode Settings -> disable kernel graphics parts which won't work on all HW if set by default soon The idea originally comes from Bernhard Walle. Steffen and myself discussed that already and agreed that it makes sense to do that. On longterm it would be great to get rid of the "Failsafe" Yast boot loader functionality. This would not be necessary anymore then. This currently totally useless and outdated anyway. With the new approach, soon as one successfully booted an entry from the installation image, these boot options will be the default forever (or manually adjusted). Discussion: #1: Stefan Dirsch (sndirsch) (2009-06-22 10:09:05) I think the X' team' would like to get involved here WRT KMS. Also I believe we still want to have a possibility to detect that the user wants to start the Xserver from installation (usually fbdev driver) instead of the apparently broken native X driver. This was boot param 'x11failsafe' in the past. #2: Thomas Renninger (trenn) (2009-06-22 14:27:39) Yeah, in this case we probably need some advise from the X guys which boot params have to be passed, eventually other extra quirks are needed for KMS, no idea. But in general the responsibility and possibilty to generate/modify extra boot entries and with them passing extra kernel boot parameters and a description when to use them should rely in the kernel teams hands and thus the config file should lie in the kernel repo. Coolo, can you set this fate entry a project manager state, so that we can finally work on that at some time, thanks. #3: Stefan Dirsch (sndirsch) (2009-06-22 14:52:39) Probably the modeset option needs to be used for all relevant KMS capable DRM modules, like i915, radeon. Possibily also radeonhd (still to be implemented) and nouveau (in case it's installed, we don't ship it). So something like this: i915.modeset=0, radeon.modeset=0, radeonhd. modeset=0, nouveau.modeset=0. #5: Andreas Jaeger (a_jaeger) (2009-07-10 11:47:39) I'm a bit confused what you want to do here. What advantage will this bring us? #6: Andreas Jaeger (a_jaeger) (2009-07-14 15:13:04) (reply to #5) Just talked with Thomas: The idea is to safe the information about kernel-parameters as part of the kernel package and let the installation get this information from there - instead of hardcoding it in the installation workflow. Also the kernel would provide different options that the developers think make sense. -- openSUSE Feature: https://features.opensuse.org/306476

1 0

[openFATE 305807] Make cleanup in applications and Control Center
by fate_noreply＠suse.de 29 Jul '09

29 Jul '09

Feature added by: Piotrek Juzwiak (BenderBendingRodriguez) Feature #305807, revision 1, last change by Title: Make cleanup in applications and Control Center openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Piotrek Juzwiak (benderbendingrodriguez) Description: What i find every time very irritating is the idea behind Control Center and applications. It should be clearly differed. After a clean install there are too many configuration tools in the applications browser what makes it difficult to browse (despite having an option to search, of course if You know what You are searching for). Not everyone knows how to clean everything up, in my example most configuration tools are in the Control Center what makes A LOT more room for applications in Application Browser what makes it easier to browse for apps. SO: make a clear distinction of what is a configuration tool and what is an application. -- openSUSE Feature: https://features.opensuse.org/305807

1 6

[openFATE 305317] Default to hidden bootloader menu
by fate_noreply＠suse.de 28 Jul '09

28 Jul '09

Feature changed by: Stefan Kunze (KunzeS) Feature #305317, revision 18 Title: Default to hidden bootloader menu openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Desirable Info Provider: Jan Engelhardt (jengelh) Requested by: Jiri Srain (jsrain) Description: As long as there is no other operating system present (SUSE is the only system), it makes sense to default to hidden bootloader menu (and booting directly). References: http://www.gnu.org/software/grub/manual/grub.html#Hidden-menu-interface https://bugzilla.novell.com/show_bug.cgi?id=425717 Discussion: #1: Stephan Kulow (coolo) (2009-04-16 10:34:48) I like that idea. I guess it's a tiny change for bootloader, but has possibly some docu impact. #2: Stanislav Visnovsky (visnov) (2009-05-28 16:45:13) How should it behave with option to keep kernels from updates (libzypp option)? What about failsafe? #3: Jiri Srain (jsrain) (2009-06-01 11:21:11) From the GRUB documentation: When your terminal is dumb or you request GRUB to hide the menu interface explicitly with the command `hiddenmenu' (*note hiddenmenu::), GRUB doesn't show the menu interface (*note Menu interface::) and automatically boots the default entry, unless interrupted by pressing ESC. When you interrupt the timeout and your terminal is dumb, GRUB falls back to the command-line interface (*note Command-line interface::). This sounds to me like this GRUB feature is intended for different purpose, and the use case described here does not make much sense (unlike lowering the time-out to e.g. 1 second). Torsten, what is your view? According to the documentation, GRUB allows to display the boot menu via pushing the Escape button. #7: Christoph Thiel (cthiel1) (2009-07-16 11:27:26) (reply to #3) Torsten, could you please provide your view on this? Fedora and others seem to be doing this for years. #4: T. J. Brumfield (enderandrew) (2009-06-13 03:31:06) This option would only be utilized when no other OS is present, and you can still get back to the menu with Esc. This isn't that much different than needing F8 for the boot menu for Windows. It would speed up boot times. How is that a bad thing? #5: Jan Engelhardt (jengelh) (2009-06-18 23:53:45) Does not Fedora do something similar? #6: Christoph Thiel (cthiel1) (2009-06-28 10:00:44) (reply to #5) I haven't looked at how Fedora handles this. Jan, would you be able to dig into what Fedora does technically? This would be very much appreciated! + #8: Stefan Kunze (kunzes) (2009-07-28 16:03:50) + The only problem I see with this is when the installer does not pick up + another installed OS (happens to Windows once in a while) and defaults + to a hidden Bootloader? + -- openSUSE Feature: https://features.opensuse.org/305317

1 0

[openFATE 306615] My openSUSE
by fate_noreply＠suse.de 28 Jul '09

28 Jul '09

Feature added by: Cornelius Schumacher (cschum) Feature #306615, revision 1 Title: My openSUSE Requested by: Cornelius Schumacher (cschum) Description: Write a portal which integrates all the different openSUSE services and shows a personal view on what's going on in openSUSE. Services to integrate could be the Build Service, openFATE, Bugzilla, openSUSE News, Planet openSUSE, SUSE Studio, Wikis, the software portal, forums, mailing lists, upstream development sites, etc. -- openSUSE Feature: https://features.opensuse.org/306615

1 11

[openFATE 304429] Package cache handling in yast
by fate_noreply＠suse.de 27 Jul '09

27 Jul '09

Feature changed by: Eduardo Sotomayor (Easgs) Feature #304429, revision 16 Title: Package cache handling in yast openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 21:45:10 reject reason: Postponing. Zypper already provides the functionality. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Done Priority Requester: Important Requested by: Ladislav Slezak (lslezak) Description: Add a possibility to edit 'keeppackages' option in *.repo files. The downloaded packages are not kept by default, but it should be configurable by user. The question is how it should be configurable. My suggestions are a check box or an extra menu item in the repositoru manager (repositories. ycp) . References: https://bugzilla.novell.com/show_bug.cgi?id=393709 Test Case: * check if the installed version of yast2-packager is 2.18.0 or later, with following command: $ rpm -q yast2-packager * add a new Software Repository: open YaST2 -> Software -> Software Repositories -> Add * during adding the new Software Repositories flag "Keep Downloaded Packages" * install or update a package: # zypper install <package name> * check if the package rpm file was saved in local cache (default: /var/cache/zypp/packages/) Discussion: #2: Ladislav Slezak (lslezak) (2009-01-08 13:47:14) Implemented in yast SVN trunk (will be in yast2-packager-2.18.0) There is a new check box, similar to 'Enabled' and 'Autorefresh' check boxes. (bnc#402617) #3: Eduardo Sotomayor (easgs) (2009-05-21 01:01:51) Will it work when installing a package with Yast not zypper command? #4: Rémy Marquis (spyhawk) (2009-05-23 08:36:50) (reply to #3) Yes. it is working. As specified above, there is a new checkbox in the UI for enabling cache handling. #5: Vincent Petry (pvince81) (2009-07-11 03:20:54) Will it also resume partially downloaded packages ? + #6: Eduardo Sotomayor (easgs) (2009-07-27 17:49:19) + With the zypper command is possible to only download the requiered rpm + files with all dependencies without affecting the system, this is + usefull to make a distributable CD so you can install the programs even + without an internet connection in another computer, in this way, you + can get all the files without affecting the source PC, it would be good + to add another check box "Download only" to acomplish that via Yast. + So you will have two options + "Keep Downloaded Packages" + "Download only" -- openSUSE Feature: https://features.opensuse.org/304429

1 0

[openFATE 305553] zypper: dist upgrade could error out if more than one repository with a base product exists
by fate_noreply＠suse.de 27 Jul '09

27 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #305553, revision 20 Title: zypper: dist upgrade could error out if more than one repository with a base product exists openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Dirk Mueller (dirkmueller) Description: I've just learned over lunch that calling "zypper dup" is wrong if you have both buildservice repositories and a distribution repository enabled. apparently one has to call it with -r name, where name points to the distribution one wants to upgrade to, and the other repositories (e.g. buildservice addons) must not be dup'ed, but only updated via update -t package. I've verified that this indeed fixes the "reinstalling/downgrading package" issues everyone seems to be complaining about. It would be nice if zypp/zypper could detect this situation and advise the user, or alternatively do the right thing automatically. I'm not sure if channels of distributions (e.g. the factory channel, or a future openSUSE 11.0 channel) can be detected in some way.. if it does, then it could automatically add the -r argument if there is only one distribution channel enabled, and altneratively error out if more than one distribution channel is in the sources list and no -r argument was given. Relations: - make zypper dup error out if more than one repository exists (novell/bugzilla/id: 385972) https://bugzilla.novell.com/show_bug.cgi?id=385972 Discussion: #1: Stephan Kulow (coolo) (2008-05-11 02:20:39) * ** Bug 388956 has been marked as a duplicate of this bug. *** #2: Duncan Mac-Vicar (dmacvicar) (2008-12-10 15:31:24) Hm. If that is so, this feature is really important :O) Just a side question: how does installation handle this (if at all)? Currently they can't, we need to add means of such identification (as well as identification of update repos). yup, sounds good #3: Lukas Ocilka (locilka) (2008-05-12 06:17:43) Installation/Upgrade has the installation repository registered as the fist one, then Add-Ons or other repositories can be added or enabled. Upgrade doesn't handle how the packages are selected to be upgraded, it just calls solver. OK, some packages are dropped by installation by default :) See bug #300540. #4: Stephan Kulow (coolo) (2008-05-12 06:25:06) the main difference: it's pretty unusual to have 13 repos during distribution update with very comparable versions. While it's not to for zypper dup. BTW: another difference: installations sets YAST_IS_RUNNING=instsys, which some packages cause not to produce errors on updates. This might be good for dup, but bad for update #5: Duncan Mac-Vicar (dmacvicar) (2008-12-10 16:56:35) Note, I moved the bugzilla entry to fate, but mls claims the bug is invalid, as it is a perfect use case to do dist upgrade with various repositories. So this feature has to be evaluated with care and gathering opinions from various sources. It may be invalid. #7: Jiri Srain (jsrain) (2008-12-11 07:58:04) (reply to #5) I don't think it is invalid; I happened to downgrade several packages from OSS repo via zypper dup :-( #8: Duncan Mac-Vicar (dmacvicar) (2008-12-11 10:10:32) (reply to #7) The solution of stop-with-error if there is more than one repository is invalid because prevent the valid usecase of dist-upgrading with more than one repo enabled (as mls pointed out). What is valid about the feature, is that multiple repo upgrade can be dangerous, and we may warn the user if there are repos for different products there. #9: Jiri Srain (jsrain) (2008-12-11 10:53:42) (reply to #8) Sorry for not being precise in my comment: of course user must be able to override this error/warning/whatever. #6: Duncan Mac-Vicar (dmacvicar) (2008-12-10 18:34:19) Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if repositories are mixed. #10: Ján Kupec (jkupec) (2009-06-24 09:33:26) Michael, is this still relevant? Is this related to the planned --from option? #11: Michael Schröder (mlschroe) (2009-06-24 11:33:46) (reply to #10) This has nothing to do with --from, it's about doint 'zypper dup' to update the system to the next release while still having old repositories enabled. #12: Ján Kupec (jkupec) (2009-07-07 16:26:43) (reply to #11) So multiple repositories are not a problem in general, but multiple repos for different products are! OK, so now back to the solution: can you tell me or point me to some info abou these CPEs Duncan mentions in c#6? I guess they are part of the product solvable and are available as solv attribute? If so, all that's needed is to check whether there are multiple repos with a different product and write a warning if that's the case, right? #13: Michael Schröder (mlschroe) (2009-07-07 16:34:14) (reply to #12) ma, is there a libzypp interface? #14: Michael Andres (mlandres) (2009-07-13 14:16:11) (reply to #13) Yes. Since you can ask for a products CPEid, or for the CPEids related to a repository (supported or updated products). But I don't know if those CPEids are meanwhile included in the metadata (see bnc #459527). #15: Ján Kupec (jkupec) (2009-07-14 18:17:17) (reply to #14) OK, so this should not be too much work. So to sum it up: * zypper: show a warning in 'dup' if there are multiple base repos with different CPEids enabled. * metadata: check/include the CPEid in product metadata (who should do this?) + #16: Ján Kupec (jkupec) (2009-07-27 17:30:09) (reply to #14) + Rudi, please look at c#14 and 15 -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 305553] zypper: dist upgrade could error out if more than one repository with a base product exists
by fate_noreply＠suse.de 27 Jul '09

27 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #305553, revision 19 Title: zypper: dist upgrade could error out if more than one repository - exists + with a base product exists openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Dirk Mueller (dirkmueller) Description: I've just learned over lunch that calling "zypper dup" is wrong if you have both buildservice repositories and a distribution repository enabled. apparently one has to call it with -r name, where name points to the distribution one wants to upgrade to, and the other repositories (e.g. buildservice addons) must not be dup'ed, but only updated via update -t package. I've verified that this indeed fixes the "reinstalling/downgrading package" issues everyone seems to be complaining about. It would be nice if zypp/zypper could detect this situation and advise the user, or alternatively do the right thing automatically. I'm not sure if channels of distributions (e.g. the factory channel, or a future openSUSE 11.0 channel) can be detected in some way.. if it does, then it could automatically add the -r argument if there is only one distribution channel enabled, and altneratively error out if more than one distribution channel is in the sources list and no -r argument was given. Relations: - make zypper dup error out if more than one repository exists (novell/bugzilla/id: 385972) https://bugzilla.novell.com/show_bug.cgi?id=385972 Discussion: #1: Stephan Kulow (coolo) (2008-05-11 02:20:39) * ** Bug 388956 has been marked as a duplicate of this bug. *** #2: Duncan Mac-Vicar (dmacvicar) (2008-12-10 15:31:24) Hm. If that is so, this feature is really important :O) Just a side question: how does installation handle this (if at all)? Currently they can't, we need to add means of such identification (as well as identification of update repos). yup, sounds good #3: Lukas Ocilka (locilka) (2008-05-12 06:17:43) Installation/Upgrade has the installation repository registered as the fist one, then Add-Ons or other repositories can be added or enabled. Upgrade doesn't handle how the packages are selected to be upgraded, it just calls solver. OK, some packages are dropped by installation by default :) See bug #300540. #4: Stephan Kulow (coolo) (2008-05-12 06:25:06) the main difference: it's pretty unusual to have 13 repos during distribution update with very comparable versions. While it's not to for zypper dup. BTW: another difference: installations sets YAST_IS_RUNNING=instsys, which some packages cause not to produce errors on updates. This might be good for dup, but bad for update #5: Duncan Mac-Vicar (dmacvicar) (2008-12-10 16:56:35) Note, I moved the bugzilla entry to fate, but mls claims the bug is invalid, as it is a perfect use case to do dist upgrade with various repositories. So this feature has to be evaluated with care and gathering opinions from various sources. It may be invalid. #7: Jiri Srain (jsrain) (2008-12-11 07:58:04) (reply to #5) I don't think it is invalid; I happened to downgrade several packages from OSS repo via zypper dup :-( #8: Duncan Mac-Vicar (dmacvicar) (2008-12-11 10:10:32) (reply to #7) The solution of stop-with-error if there is more than one repository is invalid because prevent the valid usecase of dist-upgrading with more than one repo enabled (as mls pointed out). What is valid about the feature, is that multiple repo upgrade can be dangerous, and we may warn the user if there are repos for different products there. #9: Jiri Srain (jsrain) (2008-12-11 10:53:42) (reply to #8) Sorry for not being precise in my comment: of course user must be able to override this error/warning/whatever. #6: Duncan Mac-Vicar (dmacvicar) (2008-12-10 18:34:19) Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if repositories are mixed. #10: Ján Kupec (jkupec) (2009-06-24 09:33:26) Michael, is this still relevant? Is this related to the planned --from option? #11: Michael Schröder (mlschroe) (2009-06-24 11:33:46) (reply to #10) This has nothing to do with --from, it's about doint 'zypper dup' to update the system to the next release while still having old repositories enabled. #12: Ján Kupec (jkupec) (2009-07-07 16:26:43) (reply to #11) So multiple repositories are not a problem in general, but multiple repos for different products are! OK, so now back to the solution: can you tell me or point me to some info abou these CPEs Duncan mentions in c#6? I guess they are part of the product solvable and are available as solv attribute? If so, all that's needed is to check whether there are multiple repos with a different product and write a warning if that's the case, right? #13: Michael Schröder (mlschroe) (2009-07-07 16:34:14) (reply to #12) ma, is there a libzypp interface? #14: Michael Andres (mlandres) (2009-07-13 14:16:11) (reply to #13) Yes. Since you can ask for a products CPEid, or for the CPEids related to a repository (supported or updated products). But I don't know if those CPEids are meanwhile included in the metadata (see bnc #459527). #15: Ján Kupec (jkupec) (2009-07-14 18:17:17) (reply to #14) OK, so this should not be too much work. So to sum it up: * zypper: show a warning in 'dup' if there are multiple base repos with different CPEids enabled. * metadata: check/include the CPEid in product metadata (who should do this?) -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 305403] Bootloader beep configuration
by fate_noreply＠suse.de 27 Jul '09

27 Jul '09

Feature changed by: Jozef Uhliarik (juhliarik) Feature #305403, revision 17 Title: Bootloader beep configuration - Hackweek IV: Candidate + Hackweek IV: Done Priority Requester: Desirable Projectmanager: Desirable - openSUSE-11.2: Candidate + openSUSE-11.2: Done Priority Requester: Desirable Projectmanager: Desirable Requested by: Jiri Srain (jsrain) Description: Allow to configure whether the acoustic signal should be used for installed bootloader. Acoustic signal is valuable for visually impaired people, while it may be disturbing e.g. in libraries. Discussion: #1: Jiri Srain (jsrain) (2008-11-12 15:58:43) Default can be set depending on whether braille display was found or whether text-to-speech in isolinux was used. #2: Stefan Behlert (sbehlert) (2008-11-12 17:15:07) Is this feature meant as 'allow atuomatic setting of'? The beep is afaik already configurable to be 'off'. If not, this would be a bug. #3: Stefan Seyfried (seife) (2008-11-12 18:09:40) Please reject this feature. This is seriously overengineered. The beep now defaults to off int the installed system. If somebody wants to enable it, he can do so with gfxboot --change-config "boot::beep=1" Marco only needs to document that for his customers and everything is fine. Please, no YaST module for that. #4: Jiri Srain (jsrain) (2008-11-13 09:39:44) (reply to #3) It's not about a new module, just about a check box in the bootloader configuration. #5: Jiri Srain (jsrain) (2009-06-01 11:38:11) (reply to #4) Jozo, please, find a reasonable location for the check box. #6: Jozef Uhliarik (juhliarik) (2009-06-25 10:37:14) Steffen how can I obtain info about status of "beep" from gfxboot? I know how to switch on/off option but I need also status. Please let me know. #7: Steffen Winterfeldt (snwint) (2009-06-25 11:40:48) (reply to #6) You can't. If you have an INF file parser, you can run 'gfxboot --show- config' and get the value from there. + #8: Jozef Uhliarik (juhliarik) (2009-07-27 16:54:15) + done in yast2-bootloader 2.18.11 -- openSUSE Feature: https://features.opensuse.org/305403

1 0

[openFATE 302159] zypper: Add option to only download packages (-d)
by fate_noreply＠suse.de 27 Jul '09

27 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #302159, revision 43 Title: zypper: Add option to only download packages (-d) openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-06-19 14:19:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-04 14:32:54 reject reason: Running out of time, postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 22:23:41 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important - openSUSE-11.2: Candidate + openSUSE-11.2: Done Priority Requester: Desirable Projectmanager: Important Requested by: Jiri Srain (jsrain) Description: rug has a '-d' option which causes it only download packages, not to install them. zypper does not have one. to make use of such options (download packages and install them later) zypp must be able to keep the packages downloaded and use them later instead of downloading them again (eg. some kind of persistent cache). References: https://bugzilla.novell.com/show_bug.cgi?id=230704 See also feature #300747 and #305624 Discussion: #2: Ján Kupec (jkupec) (2007-06-05 13:43:33) (reply to #1) First, we must have a clue how to do it :O) #5: Michael Andres (mlandres) (2007-06-18 13:21:51) (reply to #2) We need a persistent package cache, where packages are indexed by MD5, SHA. Commit has to be rewritten to separate download and install code (still offering alternating download/install or download all then install). And we need some cache cleanup policies. But we probabely don't want to do this before we know the refactored zypp runs smoothly, so I would not promise this for 10.3 #8: Federico Lucifredi (flucifredi) (2007-06-18 15:48:59) (reply to #5) As an aside, indexing will cause you probelsm with blind-revisioned packages, depending on how you implement it. #4: Duncan Mac-Vicar (dmacvicar) (2007-06-18 09:19:27) (reply to #3) This means changing the commit, and we can only do that if we are ahead of time with the other changes. #6: Jiri Srain (jsrain) (2007-06-18 14:40:08) Duncan, Michael, thanks! Stano, please, postpone for 11.0. #7: Federico Lucifredi (flucifredi) (2007-06-18 15:46:55) Lets not forget that 70%+ of OpenSUSE users have broadband according to the survey, which means this is a marginal advantage, albeit a nice one (I imagine, users who are charged by the bit, and advanced users doing who-knows-what will take advantage of the ability to retrieve packages from the cache). #13: Jan Engelhardt (jengelh) (2009-03-01 17:02:04) (reply to #7) Broadband is actually a pretty broad term, and so the survey item probably did not have much value. #10: Stanislav Visnovsky (visnov) (2007-11-23 11:26:31) zypper improvements, commit re-factoring. #14: Elmar Stellnberger ATK (estellnb) (2009-03-26 13:04:40) One advantage will be that packages can be inspected by a prog. such as mc in advance to installation or to manually take them apart by rpm2cpio. Sometimes it is necessary to add special rpm-installation options as --excludepath or --excludedocs to install several versions of a single package for downward compatibility. Furthermore in combination with an upcoming --arch switch it may enable to download packages on a server to be installed on another system/machine. f.i. the ati repo can not be browsed via http so that it is necessary to download packages from it via zypper rather than a web browser. #17: Michael Andres (mlandres) (2009-07-21 12:30:27) libzypp-6.11.0 allows to set different download policies in ZYppCommitPolicy (DownloadOnly, DownloadInAdvance, DownloadInHeaps, DownloadAsNeeded). + #18: Ján Kupec (jkupec) (2009-07-27 15:22:59) + Done also in zypper (--download-only/-d added to several commands). To + be in zypper 1.2.3 -- openSUSE Feature: https://features.opensuse.org/302159

1 0

[openFATE 306850] Codestriker
by fate_noreply＠suse.de 27 Jul '09

27 Jul '09

Feature added by: Hemant Mohan (hemantm) Feature #306850, revision 1 Title: Codestriker Package Wishlist: Unconfirmed Priority Requester: Desirable Requested by: Hemant Mohan (hemantm) Description: Codestriker is a code review tool (http://codestriker.sourceforge.net/), which is very useful to the developers. -- openSUSE Feature: https://features.opensuse.org/306850

1 2

[openFATE 305877] Popularity contest
by fate_noreply＠suse.de 25 Jul '09

25 Jul '09

Feature changed by: Carlos Gonçalves (cgoncalves) Feature #305877, revision 20 Title: Popularity contest openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Desirable Requested by: Vladimir Nadvornik (nadvornik) Description: We need a feedback about packages that are preferred by users and actively used. Debian already has a tool named Popularity contest (popcon) * reusing popcon will give us results that are directly comparable with Debian and Ubuntu * packagers team can take care of the package * we need a configuration dialog in YaST that is visible enough * we need a server infrastructure on opensuse.org. (There are certain privacy issues, see Debian FAQ for details) References: http://en.opensuse.org/BrainStorming_Prague#We_don.27t_know_which_packages_… http://popcon.debian.org/FAQ http://popcon.debian.org/ http://popcon.ubuntu.com/ Discussion: #1: Michal Vyskocil (mvyskocil) (2009-02-20 12:56:06) The pupularity-contest executable is a simple Perl script, which should be ported to rpm (replacing of dpkg calls by appropiate rpm alternative should be enough). #2: Pavol Rusnak (prusnak) (2009-03-11 15:53:13) (reply to #1) Replacing of dpkg calls with rpm is a no-go, because of the transactions in RPM. I started to work on a rewrite, will post results soon ... #3: Marek Stopka (m4r3k) (2009-03-13 09:28:08) (reply to #2) And here is a result... :-) http://stick.gk2.sk/blog/2009/03/popcorn-popularity-contest-for-rpm/ #4: Jay Mistry (zmdmw52) (2009-03-15 15:36:25) The software equivalent of Smolts Hardware profiler. Results can be uploaded to a dedicated website (such as is for Smolts- http://www.smolts.org/), so that users can see the relative weight/popularity of various commonly-used applications. + #7: Carlos Gonçalves (cgoncalves) (2009-07-25 19:03:58) (reply to #4) + There is a GSOC project (http://socghop.appspot.com/student_project/show/google/gsoc2009/gentoo/t124…) + which is addressing this (Smolt) feature to Gentoo, though the author + has been coding this aswell to Debian-based distros and more recently + considering RPM distros too. + I've been working with him on the client integration since I'm its + author, and from my side all I can say is that Smolt sooner or later + will be addressing this feature, too, but won't be ready in time for + openSUSE 11.2 since feature/version freeze is next week (July 31). #5: T. J. Brumfield (enderandrew) (2009-06-13 21:16:54) During install, there can be a simple checkbox such as "Share hardware/software details with openSUSE servers for profiling." #6: Stephan Kulow (coolo) (2009-06-24 11:29:15) first we need the package in and someone to maintain the server or contact debian if they host other distros too. -- openSUSE Feature: https://features.opensuse.org/305877

1 0

[openFATE 305584] Do not assume fixed and contiguous device numbers in installation and management tools for storage
by fate_noreply＠suse.de 24 Jul '09

24 Jul '09

Feature changed by: Arvin Schnell (aschnell) Feature #305584, revision 17 Title: Do not assume fixed and contiguous device numbers in installation and management tools for storage openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-03 08:25:13 reject reason: No resources in YaST team for this in 11.2. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Mandatory Projectmanager: Important Requested by: Matthias Eckermann (mge1512) Requested by: Tejun Heo (teheo) Description: Subject: [Research] head up on upcoming extended block devt change From: Tejun Heo <tj(a)kernel.org> Date: Thu, 18 Dec 2008 12:59:21 +0900 Reply-To: research(a)suse.de Hello, all. From soon to be released 2.6.28, the kernel contains extended block devt support, which basically allocates block device numbers dynamically from major number 259 (might expand to other major numbers if ever necessary). This means that device numbers belonging to the same device become non-contiguous and can be on different major numbers. This will remove the 15 partition limit on /dev/sdX's and increase the total number of supported SCSI disks considerably. Also, it's used by md to allow partitioning of /dev/mdX's thus removing the distinction of partitionable and non-partitionable md devices. For example, /dev/sda with 60 partitions can look like as follows. # cat /proc/partitions major minor #blocks name 8 0 156290904 sda 8 1 8001 sda1 8 2 8032 sda2 8 3 8032 sda3 8 4 1 sda4 ... 8 15 8001 sda15 259 0 8001 sda16 259 1 8001 sda17 259 2 8001 sda18 ... 259 43 8001 sda59 259 44 8001 sda60 For detailed overview, please take a look at the following message. http://article.gmane.org/gmane.linux.kernel/701825 As device node creation is completely dynamic these days, installed systems usually can cope fine with this change; however, in installation and management tools, there seem to be many places which assume fixed and contiguous device numbers. To ease hunting down those areas, a debug option is available which forces every block device to be allocated on the dynamic major non-consecutively. With the debug option turned on, the above disk will look like the following. # cat /proc/partitions major minor #blocks name 8 0 156290904 sda 259 262144 8001 sda1 259 786432 8032 sda2 259 131072 8032 sda3 259 655360 1 sda4 259 393216 8001 sda5 259 917504 8001 sda6 259 65536 8001 sda7 ... 259 114688 8001 sda55 259 638976 8001 sda56 259 376832 8001 sda57 259 901120 8001 sda58 259 245760 8001 sda59 259 770048 8001 sda60 So, the installation / management tools need to follow /sys/block/*/device/driver to determine which type of device it is and use /sys/block/*/dev to determine its device number. I'll add a kernel parameter (say, block.force_ext_devt) so that this debug option can be turned on and off during boot so that people who don't work on related subsystems don't have to suffer. I'm not sure how and when to proceed with this yet but I definitely think we'll need plenty of time to sort this out completely. Any ideas on how to proceed on this? Thanks. -- tejun Discussion: #1: Tejun Heo (teheo) (2008-12-22 13:31:11) So... when and how do we proceed with things like this? I wanna enable it in HEAD but SLES11 hasn't branched out from HEAD yet but I don't think we should wait till SLES11 is released. #2: Matthias Eckermann (mge1512) (2008-12-22 10:24:58) (reply to #1) SLE 11 has precedence over anything else we currently do - with respect to focus and time spent on it. Thus we should concentrate on SLE 11 and wait with those changes after release of SLE 11. There are more than enough P1 and P2 issues with the SLE 11 kernel to work on, ... Vojtech? #3: Vojtech Pavlik (vojtech_pavlik) (2008-12-22 12:14:19) I agree, Matthias, and I see no reason why this couldn't wait until SLES11 branches out of HEAD. #4: Tejun Heo (teheo) (2008-12-23 11:52:19) Alright, then. I'll enable it when SLES11 branches out. Thanks. #5: Tejun Heo (teheo) (2009-05-29 16:55:23) Added genhd.mangle_devt parameter and enabled DEBUG_BLOCK_EXT_DEVT for all configs except for vanilla's and ppc/ps3. Ext major and mangled minor can be enabled by specifying "genhd.mangle_devt=1" as kernel parameter. Have fun. :-) #7: Christoph Thiel (cthiel1) (2009-06-03 08:26:09) (reply to #5) Tejun, IIUC the options you put in, don't break anything unless genhd. mangle_devt=1 on kernel cmdline? We won't be able to complete the YaST part of this for 11.2. #8: Tejun Heo (teheo) (2009-06-03 15:35:12) (reply to #7) Yeap, the kernel will behave exactly the same as before if the parameter isn't specified. Also, we can disable DEBUG_BLOCK_EXT_DEVT when we're nearing SL112 release (maybe when we enter beta). For now, I'll leave it there in case someone wants to play with it. Maybe it's wise to schedule dev resource so that SL113 can have it implemented? #9: Arvin Schnell (aschnell) (2009-06-03 10:30:47) (reply to #8) I don't expect major problems from the mangled node numbers in YaST. For the partitioner the main work is to change the maximal number of partitions for disks and handling it everywhere (from lib to UI). + #10: Arvin Schnell (aschnell) (2009-07-24 15:03:55) + During hackweek I have extended libstorage to read both "range" and + "ext_range". A few tests with genhd.mangle_devt=1 showed no problems + and I was able to create 20 partitions on sda using YaST. The range is + likely not handled correctly everywhere but testing should be possible + now. + Changes should be included in openSUSE 11.2 Milestone 5. -- openSUSE Feature: https://features.opensuse.org/305584

1 0

[openFATE 305150] Indicate automounted filesystems in YaST partitioner
by fate_noreply＠suse.de 23 Jul '09

23 Jul '09

Feature changed by: Arvin Schnell (aschnell) Feature #305150, revision 11 Title: Indicate automounted filesystems in YaST partitioner - openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) - reject date: 2009-06-03 08:20:42 - reject reason: No resources for 11.2. + openSUSE-11.2: Done Priority Requester: Mandatory Projectmanager: Important - openSUSE-11.3: Evaluation - Priority - Requester: Mandatory - Projectmanager: Important Requested by: Arvin Schnell (aschnell) Description: Currently the partitioner does not indicate if a filesystem (e.g. NFS) is mounted via some automounting daemon. For these filesystems the "Edit" and "Delete" buttons do not make sense. Using them could even cause trouble. So these filesystems need special handling. Libstorage must be extended to detect and provide the information. The ignore_fstab flag can be used as a starting point for this. Relations: - Yast2 Partitioner shows NFS mounts from automounter (novell/bugzilla/id: 446502) https://bugzilla.novell.com/show_bug.cgi?id=446502 + Discussion: + #2: Arvin Schnell (aschnell) (2009-07-23 09:45:00) + Implemented during hackweek: The ignore_fstab flags is now also set for + non-NFS volumes and displayed in the UI. -- openSUSE Feature: https://features.opensuse.org/305150

1 0

[openFATE 306926] Launchpad for openSUSE
by fate_noreply＠suse.de 22 Jul '09

22 Jul '09

Feature added by: Pavol Rusnak (prusnak) Feature #306926, revision 1 Title: Launchpad for openSUSE Hackweek IV: Unconfirmed Priority Requester: Important Requested by: Pavol Rusnak (prusnak) Description: Ubuntu released source code for their tool Launchpad. Modify it, so it is possible to run under openSUSE. Probably integrate with other openSUSE tools later (OBS, ...) -- openSUSE Feature: https://features.opensuse.org/306926

1 3

[openFATE 305586] Desktop independent global notification framework
by fate_noreply＠suse.de 21 Jul '09

21 Jul '09

Feature changed by: Lubos Lunak (llunak) Feature #305586, revision 25 Title: Desktop independent global notification framework openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Desirable Requested by: Stefan Assmann (assmannst) Partner organization: openSUSE.org Description: Our current desktop environments lack a good, configurable notification framework like Growl on Mac OS X. With D-BUS in place we could develop/integrate a framework that is desktop independent and could serve both KDE and GNOME applications the same way. This provides one step towards integrating both desktops more closely, thus making the user experience smoother. One such notification system is already in development. It's called mumbles (http://www.mumbles-project.org/) and provides lots of features similar to Growl. * It's customizable * Has theming support * Has plugin support * Desktop independent * Can use compiz for smooth display Using such a framework, more than just integrating desktops could be achieved: * Local notifications on hardware events * Remote notifications on login/hardware events * Easy scriptability for custom notifications Steps necessary to implement such a framework in openSUSE/SLE: * Install and configure framework by default * Integrate framework configuration in desktop environment * Make framework interactive so the user can react on events (optional) * Make applications D-Bus/Notification aware, so they send events, already available: Firefox, Thunderbird, Pidgin, several others Business case (Partner benefit): openSUSE.org: Such a framework would be a huge win for the general user experience, as it makes the desktop look more integrated and smooth. It's even a good idea for SLES, so administrators can be easily notified when events occur, without the hassle to set up syslog forwarding+parsing+notifying. Discussion: #2: Guy Lunardi (glunardi) (2008-12-18 08:32:18) I agree this is an important part of the desktop platform. How is this different from the libnotify solution which I believe we use for this purpose today? It is my PM understanding it does most everything you are describing including a CLI (notify-send). Applications such as NetworkManager, PowerManager, Pidgin and Banshee. Reading their FAQ, the reason for not using libnotify is that the author wanted to put more Python dependent software on their system :- ). Is this proposal about switching from libnotify to mumbles? (honestly asking, I have no opinion) #3: Stefan Assmann (assmannst) (2008-12-18 15:46:19) (reply to #2) Honestly I have not much insighted into libnotify myself. Talking to Alex Graf about this, we came up with the idea to teach the libnotify daemon how to forward messages to mumbles. It turns out that libnotify has support for theming, so it should be possible to create a theme that forwards all events to mumbles. Then we would not have to make a decision what we should use and could just switch and see what suits us best. This way we don't lose any functionality. In my opinion mumbles looks a lot smoother than the current libnotify messages. However I guess everything possible with mumbles could be tought to libnotify as well. Frankly said I don't want to make a decision here, what I care for is that the functionality described in this fate will be integrated into our products. #4: Stefan Assmann (assmannst) (2008-12-18 16:15:56) (reply to #3) Update: Talking to the developers I just learned that mumbles will intercept libnotify messages and handle them. There's a plugin for mumbles that does that. #5: Tejun Heo (teheo) (2008-12-22 13:28:54) I think that having the notion of what a "notification" is and how the user can take "action"s to it is quite important. There are multiple classes of notifications - some are ephemeral while others must get acknowledgement from the user. For example, download complete from firefox, new driver or codec installation suggestion and smartd reporting imminent disk failures can and probably should use the same notification mechanism but they need to be handled differently. For ephemeral notifications, I think what libnotify has been doing is fine but for anything else, we at least need a way for the user to ack or take actions accordingly and review and search unacked and acked notifications. I think having such notification mechanism will help us a lot as a distro as it will enable us to suggest things in not-too-intrusive yet friendly way. #6: M. S. (funkym) (2009-01-17 13:05:51) libnotify does all that and ontop is based on a desktop independent freedesktop specification (http://galago-project.org/specs/notification/index.php) for notifications to adopt by any desktop environment. It is written in C which is much more suitable for daemons and provides bindings for D- BUS, Mono, Python and Vala. Interactive notifications are already used widely; take PackageKit as an example. The developer of growl is also interested to improve libnotify as they are closely related and friends with the maintainer. A cross desktop friendly notifications utility in Python is the right thing to make things worse. If you want the bling just create a different theme for libnotify... What libnotify needs though is a bit of coding love to implement stuff like network notifications. Switch to Mumbles -> NO! Contribute to libnotify -> YES! $2c #7: Stefan Assmann (assmannst) (2009-01-19 09:55:39) (reply to #6) It's no longer the question whether to switch from one to the other. Mumbles is able to intercept libnotify messages so we can provide it "on top" and switch. Then it's a question of defaults and what we like this to become. #10: Andreas Jaeger (a_jaeger) (2009-07-09 10:21:44) Ubuntu is working on a notification framework well (https://wiki.ubuntu.com/NotifyOSD). Are those in a state that we can make a decision to go one way or the other? Initially we could add it as optional package and ask for feedback with Milestone 4 - and then decide what to do. #11: Will Stephenson (wstephenson) (2009-07-09 14:34:30) (reply to #10) The discussion about notification APIs is still very active on the XDG list. I recommend not adopting either the Ubuntu proposal or the galago derived fdo Notification spec until a standard has been agreed. 1) The Notification spec is not a standard. Its unilateral assumption of the org.freedesktop.Notification namespace is controversial. A standard spec is still under discussion. 2) The Ubuntu design makes strong and arbitrary restrictions on what can be shown in the notification. The intention of the current discussion is to design a notification API that can be a superset of the Ubuntu proposal and provides the features required by several projects outside Ubuntu. Since a productive discussion is still taking place, making a premature decision would undermine the XDG standards process and cause additional work when a final spec is agreed. - + #12: Lubos Lunak (llunak) (2009-07-21 15:05:15) + This request is confused on several fronts. At least one of our + desktops, KDE, has had such a framework, KNotify, since ages. Mumbles + itself declares itself to be "a plugin driven, modern notification + system for Gnome", so it doesn't look very desktop independent. And it + is enough to read the XDG list to see that libnotify is in fact not a + standard or anything close either. I assume that it will still take + some time to reach any usable consensus on an actual specification for + notifications, so there is probably not much to be done here for 11.2 + besides joining the XDG discussions (unless, of course, this proposal + in fact wanted to be named 'GNOME notification framework'). -- openSUSE Feature: https://features.opensuse.org/305586

1 0

[openFATE 302159] zypper: Add option to only download packages (-d)
by fate_noreply＠suse.de 21 Jul '09

21 Jul '09

Feature changed by: Michael Andres (mlandres) Feature #302159, revision 41 Title: zypper: Add option to only download packages (-d) openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-06-19 14:19:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-04 14:32:54 reject reason: Running out of time, postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 22:23:41 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Candidate Priority Requester: Desirable Projectmanager: Important Requested by: Jiri Srain (jsrain) Description: rug has a '-d' option which causes it only download packages, not to install them. zypper does not have one. to make use of such options (download packages and install them later) zypp must be able to keep the packages downloaded and use them later instead of downloading them again (eg. some kind of persistent cache). References: https://bugzilla.novell.com/show_bug.cgi?id=230704 See also feature #300747 and #305624 Discussion: #2: Ján Kupec (jkupec) (2007-06-05 13:43:33) (reply to #1) First, we must have a clue how to do it :O) #5: Michael Andres (mlandres) (2007-06-18 13:21:51) (reply to #2) We need a persistent package cache, where packages are indexed by MD5, SHA. Commit has to be rewritten to separate download and install code (still offering alternating download/install or download all then install). And we need some cache cleanup policies. But we probabely don't want to do this before we know the refactored zypp runs smoothly, so I would not promise this for 10.3 #8: Federico Lucifredi (flucifredi) (2007-06-18 15:48:59) (reply to #5) As an aside, indexing will cause you probelsm with blind-revisioned packages, depending on how you implement it. #4: Duncan Mac-Vicar (dmacvicar) (2007-06-18 09:19:27) (reply to #3) This means changing the commit, and we can only do that if we are ahead of time with the other changes. #6: Jiri Srain (jsrain) (2007-06-18 14:40:08) Duncan, Michael, thanks! Stano, please, postpone for 11.0. #7: Federico Lucifredi (flucifredi) (2007-06-18 15:46:55) Lets not forget that 70%+ of OpenSUSE users have broadband according to the survey, which means this is a marginal advantage, albeit a nice one (I imagine, users who are charged by the bit, and advanced users doing who-knows-what will take advantage of the ability to retrieve packages from the cache). #13: Jan Engelhardt (jengelh) (2009-03-01 17:02:04) (reply to #7) Broadband is actually a pretty broad term, and so the survey item probably did not have much value. #10: Stanislav Visnovsky (visnov) (2007-11-23 11:26:31) zypper improvements, commit re-factoring. #14: Elmar Stellnberger ATK (estellnb) (2009-03-26 13:04:40) One advantage will be that packages can be inspected by a prog. such as mc in advance to installation or to manually take them apart by rpm2cpio. Sometimes it is necessary to add special rpm-installation options as --excludepath or --excludedocs to install several versions of a single package for downward compatibility. Furthermore in combination with an upcoming --arch switch it may enable to download packages on a server to be installed on another system/machine. f.i. the ati repo can not be browsed via http so that it is necessary to download packages from it via zypper rather than a web browser. + #17: Michael Andres (mlandres) (2009-07-21 12:30:27) + libzypp-6.11.0 allows to set different download policies in + ZYppCommitPolicy (DownloadOnly, DownloadInAdvance, DownloadInHeaps, + DownloadAsNeeded). -- openSUSE Feature: https://features.opensuse.org/302159

1 0

[openFATE 306904] Distributed Shared memory library
by fate_noreply＠suse.de 20 Jul '09

20 Jul '09

Feature added by: Peter Morreale (pmorreale) Feature #306904, revision 1 Title: Distributed Shared memory library Hackweek IV: Unconfirmed Priority Requester: Desirable Requested by: Peter Morreale (pmorreale) Description: The feature is a library to allow applications to reference and maintain shared memory segments with consistent data across a network fabric. This is similar to the old DEC Memory Channel functionality that allowed multiple machines to read and write to specific memory locations on those nodes. A couple of our customers have asked for similar functionality and as a result, I have been working on a initial implemention. For more specific information, please contact me directly. -- openSUSE Feature: https://features.opensuse.org/306904

1 3

[openFATE 120340] Run download and install in parallel
by fate_noreply＠suse.de 20 Jul '09

20 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #120340, revision 94 Title: Run download and install in parallel openSUSE-10.2: Rejected by Klaus Kämpf (kwk) reject date: 2006-08-09 11:36:10 reject reason: Not possible in 10.2 timeframe Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-08-01 10:25:01 reject reason: Out of time. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Jiri Srain (jsrain) reject date: 2008-03-28 13:56:11 reject reason: Out of resources for 11.0. Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 12:06:35 reject reason: This needs to wait. Postponing. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-03 08:43:03 reject reason: No resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Klaus Kämpf (kwk) Requested by: Peter Poeml (poeml) Requested by: Reinhard Max (rmax) Description: Network installation could be improved by running package download and package installation in parallel. References: https://bugzilla.novell.com/show_bug.cgi?id=60844 https://bugzilla.novell.com/show_bug.cgi?id=209799 https://bugzilla.novell.com/show_bug.cgi?id=128050 https://bugzilla.novell.com/show_bug.cgi?id=370457 https://bugzilla.novell.com/show_bug.cgi?id=370054 https://bugzilla.novell.com/show_bug.cgi?id=385711 http://en.opensuse.org/Libzypp/Failover http://metalinker.org/ Fate #300660: Download package groups before install Discussion: #2: Klaus Kämpf (kwk) (2006-08-09 11:36:42) Michael already looked at this. Should be further evaluated for 10.3 #3: Edith Parzefall (emapedl) (2007-07-31 16:56:12) Problem is: what do we do if we lost the network connection when only half the packages are installed? #7: Reinhard Max (rmax) (2008-04-10 11:42:43) (reply to #3) I think this is a general problem for network based installations. Can you elaborate if/why you see this as a special problem when download and installation are running in parallel? #8: Peter Poeml (poeml) (2008-05-19 14:49:53) (reply to #7) For reliable operation of a business critical server, it is a must that packages are downloaded first, before the installation/update is started. Otherwise a network outage can lead to a broken system which is half updated. So if parallel download/install is implemented (for desktop users, maybe...) then please make sure that it is possible to disable it. #9: Reinhard Max (rmax) (2008-05-19 16:01:15) (reply to #8) As we just sorted out on IRC, the current implementation also doesn't allow to complete download before starting installation and the feature proposed here wouldn't make this worse. But as the wish of server admins to have all packages downloaded before starting to install them is very valid, I think we should extend this feature request to contain that requirement as well, and probably rename it to "decouple download and installation". If download and installation are properly decoupled, it should just be a matter of the parameters the algorithm is called with to get one of the following behaviours: * Download and install packages one by one (as it is now) * Keep downloading subsequent packages while installing (as originally proposed here) * Use a fixed-size download cache for flow control between download an installations (in situations where download is faster than installation and disk space is limited) * Download all packages of an update or installation and install them afterwards (as requested by Peter for server admins) #10: Jiri Srain (jsrain) (2008-05-20 10:22:10) (reply to #9) We already do have similar feature: #300660: Download package groups before install #4: Edith Parzefall (emapedl) (2007-07-31 16:57:22) Please reject for 10.3. #5: Duncan Mac-Vicar (dmacvicar) (2008-01-10 16:23:46) This is included in the ZYpp plan for 11.0, however implementation will start after beta. Will keep in evaluation, it depends on other milestones for beta1 #14: Chris Hills (chaz6) (2009-02-16 16:42:06) Is there a feature request to install using both the base and updates repo so that the latest packages available at install-time are used, thus saving bandwidth? #15: Jiri Srain (jsrain) (2009-02-17 08:45:38) (reply to #14) This is how it works for quite some time. Repositories providing patches also provide the packages so that they can be installed directly from the update repositories (provided they contain newer version). #16: Duncan Mac-Vicar (dmacvicar) (2009-06-02 15:18:00) For 11.2 we will focus on flexibility of the download and install order (like installing after everything is downloaded), however parallel stuff should be done after we have this in place. Please reject. #17: Michal Papis (mpapis) (2009-07-04 20:58:23) I think great example here may be Gentoo, there You can chose the way of getting packages, by default download and installation go in paraler, but it is possible to get first sources and then run build/installation. If you are on the default and something breaks, ex. network, Yuo can always resume the last download&installation task. #18: Giuseppe Salinaro (superpeppo89) (2009-07-16 19:37:27) (reply to #17) This idea of gentoo is good... + #19: Ján Kupec (jkupec) (2009-07-20 10:59:31) (reply to #18) + Guys, as Duncan wrote in c#16, we are already developing the "download + all, install all" mode (currently we only have "download one, install + one, ..."), and yes, users will be able to choose one of these. This + particular feature would be an improvement of the current mode: + "download one, install one while downloading others, ...". I hope this + clarifies the current status a bit. -- openSUSE Feature: https://features.opensuse.org/120340

1 0

[openFATE 306914] Emesene
by fate_noreply＠suse.de 19 Jul '09

19 Jul '09

Feature added by: Adrian maravilla (fulapol) Feature #306914, revision 1 Title: Emesene Package Wishlist: Unconfirmed Priority Requester: Neutral Requested by: Adrian maravilla (fulapol) Description: I really like to see the emesene package in repositorys -- openSUSE Feature: https://features.opensuse.org/306914

1 1

[openFATE 305296] Easy Way to Disable Beagle Completely During Installation
by fate_noreply＠suse.de 18 Jul '09

18 Jul '09

Feature changed by: Vincent Untz (vuntz) Feature #305296, revision 105 Title: Easy Way to Disable Beagle Completely During Installation - openSUSE-11.2: Evaluation + openSUSE-11.2: Done Priority Requester: Important Projectmanager: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree #11: Jean-Daniel Dodin (jdd) (2009-02-15 10:12:29) (reply to #1) +1 #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #26: Peter Nixon (peternixon) (2009-03-11 20:39:01) (reply to #3) +1 #29: Pedro Veloso (pedrodh) (2009-04-01 22:18:05) (reply to #26) Totally agree #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) Beagle should be disabled by default. Everyone in the DFW Linux Users Group complained when Suse added it. It causes nothing but trouble for me. #12: Bart Otten (bartotten) (2009-02-16 01:13:58) I agree with the people voting to disable it by default. I think we have to keep focus on the 'consumer' and most of them won't use Kerry/Beagle. ps. KDE4 -and- Beagle is useless. KDE4 uses Strigi and Nepomuk. #13: Sebastian Rösgen (palimpseste) (2009-02-17 12:55:11) Despite all who now have voted for this proposal, I just have to vote against it. At least in the forms discussed here. I use Beagle heavily as do some other people I got convinced to use openSUSE instead of Windows. A good Desktop search was among the arguments to move these people to change their OS (others arguments were Deskbar etc... which btw. does not necessarily need Beagle but gets some interesting advantages IF Beagle is activated). Why not simply ask at startup how to configure some basic system defaults. Among them there could be beagle. So concerning the proposals of Federico Lucifredi, Stephan Kulow and so on, I am definitively of the same mind. Beagle should be installed by default, but it should be easy to switch it "on" or "off" whenever one wants. #14: Eric Springer (erikina) (2009-02-18 01:05:18) (reply to #13) Yes, a search is very useful. Yes, some people find beagle beneficial (as apparently you do). But the vast majority (Currently the vote is at 47:1) of people it doesn't work well with. And that's truly an amazing statistic, as it's super easy to see and use the feature it provides but much harder to see that it's beagle causing so many (resource related) problems. And if that statistic alone isn't enough to convince you it's not a sensible default, then I have absolutely no idea how to. There really should be a resemblance of QA in place, especially for default (and completely optional) packages. #15: Sebastian Rösgen (palimpseste) (2009-02-19 12:04:23) (reply to #14) Ok, I hope that my comment did not sound as gruff or ... brusque, for I, basically, hoped to present a different opinion. What I did not intend was to, evidently, irritate somebody by not completely assenting to his opinion. See: I am working for a university in Germany. We have 45.000 students and a staff of employees of a size appropriate for this amount of students. We rely heavily on the capabilities of a search system (to be honest: in this case not beagle, but somethings similar to beagle). I am one person who posts here but, to stay in your line of argumentation, statistically I represent so many single individuals, that my vote could be multiplied by a "pretty fight factor". Now the problem is that most of these people just use a search feature but do not understand of configure it. But they will notice when it is gone . These users do not vote, they are not involved in community work, they are not programmers, not system architects, not members of an online community. But they use systems like beagle. I know, as I stated in my first post, some people, which I got to switch their OS, from Windows to openSUSE. These people will miss features, too. Especially if you are so eager so simple remove this feature despite the fact that it was part of the distribution for many years. The more I write here, the angrier I get. I mentioned that Lucifredi and Kulow are of another opinion (disable but no remove the software; make it possible to switch it on or off when needed), an opinion I agree with. Is it possible that YOU ignored that part? This is quite normale for the usual open source community. To me it is a relatively illusive concept, the more I deal with it (and I deal with it for now 9 years) the more I learn about the ignorance it contains. Too many people choose rather to ignore those who have to vote (usually called users) and instead see their opinion as the ultimate measure to decide pro and contra. Did it come to your mind that about 80-90% of those who start to create an account for a portal like openFATE, who pay the time to write some comments and skip through all these proposals in this portal, that 80-90% of these people might perhaps be programmers? Geeks and nerds as they are called nowadays. This is no real statistic representing the opinion of those who use a software, it is a statistic of those how develop a software. Make this clear to you. So to get back on a rather rational level: I recognize that you are of another opinion. That most of the people here are. But, and that was important to me, these votes in here are not a real representation of opinions. I prefer openSUSE after all these years espcially because it was bought by Novell. Because they do research in usability, which is the only real way to ask the customers/the users, how to design the software. That is why I said, that an easy startup QA for the normal user is the best to do. Do not be too ignorant. The users know what they want, even if they miss some technical versatily, they will still take note of features that are missing, of bugs in the browser, of missing parts in the system "that they know worked on a different OS" or whatever else. Perhaps they annot name the source of the problem and do not know if it is a real design issue or a real bug. But they will say that the feature is not how they expected it to be. I recently said to a colleague of mine that the times of Mac OS are nearly over. The only real advantage they have is that they can design an OS without paying too much attention to different hardware. They know exactly which hardware their OS will possible have to run on. If Linux with a nice GNOME, KDE, or-whatever-desktop would run out of the box on ANY posible hardware, with all features running without a problem (Audio, Bluetooth, 3D Graphics are still a problem as we know) it would be undeniable that Linux will be the winner. I see progress made well into that direction. I see that Linux is close to this goal, to solve these issues in nears time (most Graphic Cards now easily work, with only a few exceptions). So please do not disappoint me. I have to lead discussions about Linux/Windows and Linux/MacOSX nearly every week. I do not want to have them led in vain. Look at what Mac and Windows do, they have a search system with an index. Make ours betters, faster and less memory hungry instead of removing it. These who switch from Windows/Mac to Linux (for instance to openSUSE) want to find new and more useful features instead of fewer features. I know this post was too long. I am sorry, but it thought it necessary. #16: Eric Springer (erikina) (2009-02-19 14:33:07) (reply to #15) I agree with everything you said, but you must realize I/we aren't arguing against search. We're arguing against beagle. I personally use google desktop search on a daily basis. And it works well. I assume that it does all its work when I'm not physically using the computer (a policy that is ideal for desktop usage). I'm not advocating its inclusion (primarily license reasons and kde integration reasons) but you should see that I'm not against a search or anything like that. Beagle on the other hand, I've tried to give it a fair shot a few times. To see if it has improved (something I will admit Banshee has done). But its *always* problematic. Something that is echoed daily on IRC and the mailing lists. The firefox extension causes huge amounts errors and slow downs. The actual search program maxs out the CPU. IO brings the computer to a crawl when I need to get work done etc. It's just not pretty. So if Beagle works well, I'd love to use it. But it doesn't and shouldn't be included. Put it this way. I would really like to see kernel initialization of graphics devices. However, until it's finished and works properly -- I think we'd both agree that it shouldn't be on our systems. I know it's not a good test for everything, but have you noticed how many other desktop distros have chosen to include beagle? #17: Sebastian Rösgen (palimpseste) (2009-02-19 18:16:48) (reply to #16) Ok, I see your point. Perhaps beagle is indeed not a good solution and I was too narrow minded to realize it. (Though I haven't experienced the CPU problems anymore for about one year, I suppose you are right). Especially since the development of beagle has come to a crawl (the last release: 0.3.9 was released about four weeks ago but it needed nearly half a year to be released and contains only some mere bug fixes). I think, I am going to open a new feature request in openFate. If you (and the other guys) are not against desktop search, but instead against beagle, it could be interesting to discuss why Tracker (http://projects.gnome.org/tracker/index.html) should not become a replacement for beagle. Especially since KDE has now Strigi as a core component. So one can get rid of beagle and use some "quasi native" tools for desktop search (namely "strigi" and "tracker") on Gnome and, respectively, KDE. Anyway, thanks for your reply and the discussion. #18: Sebastian Rösgen (palimpseste) (2009-02-19 18:23:53) (reply to #17) Hm, as it seems I cannot open such a request. Wonderful! So perhaps somebody has read this discussion and might be so kind to at least evaluate the request and "perhaps" might open a new feature request concerning the replacement of beagle by Tracker (which is a Gnome Desktop search, but since KDE has already its own Desktop search this should not be that problematic... I hope) And before somebody asks: no I will not file a feature request via bug tracking system. Those usually take weeks or even months before they are answered/evaluated/discussed etc... #19: Federico Lucifredi (flucifredi) (2009-02-19 16:52:12) (reply to #18) Hello Sebastian - I do not take the thread as being "against desktop search", which is a great feature, or against Beagle, which I personally run. The decision is only to have Beagle not be running by default out of the box, but to have it installed and ready. The first time a search is performed, we ask. Users who want desktop search select to run it, and those who are more "frugal" in terms of CPU do not. I am running a 3 year old laptop, and Beagle is running just fine for me. I suspect that's the case for a lot of people. But it is still a good idea to ask for a choice. #20: Eric Springer (erikina) (2009-02-22 03:03:55) (reply to #17) 100% agree. I think tracker/strigi make wonderful replacements. :) #22: andrea florio (anubisg1) (2009-02-25 00:40:51) (reply to #20) indeed... beagle is to heavy, traker instead, is simply wonderful! #23: Barbara Hudson (barbie_h) (2009-03-04 02:22:21) (reply to #15) I was going to vote in favour of the request, because I've been bitten by beagle bringing machines to a crawl many times, but one thing I've noticed is that, as people move to dual / quad -core machines, it's no longer a big issue. I'm not saying ignore the memory and resource problems - just that even laptops nowadays can run plasma and beagle and still feel responsive. The current system, where it notifies you when it does the initial indexing, is a lot better than the computer slowing to a crawl on a fresh install and people wondering why openSUSE is soooo slow. #21: Stanislav Visnovsky (visnov) (2009-02-24 09:10:56) Coolo, I believe this should be done via patterns. #24: Stephan Kulow (coolo) (2009-03-04 11:52:23) (reply to #21) having a desktop search easy to enable sounds like a good to have feature, so I wouldn't simply remove the package from install. But it doesn't make sense on a KDE4 desktop (and it's not there in 11.1 afaik) and it doesn't have to be running by default for GNOME either. But this is something for the beagle maintainers to decide. #25: Stephan Kulow (coolo) (2009-03-04 11:53:33) (reply to #24) that is: it should be off by default (seeing all the votes). But if it's worth to make it easier to turn it on than it is, I leave to those that know. But the solution to enable it, should be within the desktop. #27: Jan Engelhardt (jengelh) (2009-03-16 18:03:00) Less than "easy way to disable beagle completey during installation" it should even be "disable beagle by default", thank you. #28: Marcel Müller (open_assistant) (2009-03-16 20:32:45) great idea, especially to my slowly pc #30: Gabriel Stein (gabrielstein) (2009-04-03 21:15:44) Totally Agree. I just post on my blog, and I will pay 5 pints of Guinness to the great developer which will do that amazing thing. #31: john andersen (jsamyth) (2009-04-16 20:22:51) I agree Beagle should be an optional item, not installed by default.   There, I've said it.   But an alternative might be to install it and restrict it't indexing BY DEFAULT to the user's home directory, (and perhaps the user's mail spool), and hava a configuration window that allows adding additional directories. That is a feature that might make it more palletable.  But realistically, when this many people arrive at a Future Feature site begging and pleading for a package to dropped from a normal installation you should assume there are some serious flaws with that package.  This site should be about new and improved features we would all like to see, but instead this thread is focused on something that has been rammed down our throats for way too many releases, and which has historically been difficult to remove.   Side issue: Unless you are a Linux Developer there is no point in having it index the entire hard drive.  Your average user has no need of these areas, and experienced users already know where things are, so a generalized indexer that searches the entire disk is a solution looking for a problem. #32: jean-christophe baptiste (phocean) (2009-04-27 11:28:48) Ok for those who want to get an easy way to disable Beagle. But it should be activated by default. I am using Beagle intensively (on Gnome) and I have never got a problem with it. It just rocks and a huge time saver to me. Maybe my hardware is just not obsolete (Core 2 duo laptop)... I think it is the kind of killer app good to show off and that can bring more new users. #33: andrea florio (anubisg1) (2009-05-12 20:04:51) (reply to #32) you are luky then.. beagle on my pc make them very very slower, it should be disabled by default, if you need it, then you insta/activate it #34: Marc collin (collinm) (2009-07-04 15:03:05) Disable it by default, i use kde... and there is alreay a solution for it.... we could also disable mono... #35: Michael Löffler (michl19) (2009-07-07 11:29:54) Vincent, can you do this? As it is our highest rated feature it would be very good to have implemented rather soon then later. Thanks. #36: Vincent Untz (vuntz) (2009-07-07 12:09:24) Well, it depends on what is the decision here: * if it's something that should be done during installation, I have no idea how to implement that. * If it's just disabling beagle by default, I'll need to investigate, but it hopefully only is changing something in a .desktop file. So what's the process on taking a decision here? That being said, just disabling beagle by default might expose a usability issue: if it's disabled, it will not index files. So when the user searches for something for the first time, it will not work and users won't understand it, and will just give up on it. (It might be solvable with a nice message the first time the user does a search, though) #37: Michael Löffler (michl19) (2009-07-07 14:43:12) (reply to #36) Vincent, please see #1. What you describe is exactly what Federico suggested as well. So I'd say disable beagle by default and offer option to run at first search. #38: Karl Eichwalder (keichwa) (2009-07-07 15:08:23) (reply to #37) IIRC, the kde help center works this way and it is rather annoying. Most of the time, the desktop computer idles... I think on the Mac the desktop search (spotlight) is enabled by default. #39: Stephan Kulow (coolo) (2009-07-07 15:16:24) (reply to #38) you're wrong. Most of the time, the desktop computer saves power. #40: Karl Eichwalder (keichwa) (2009-07-07 15:36:52) (reply to #39) Yes, you are right. Once the work is done. On my desktop at work, beagled and beagled-helper do not cause any notable load. It's different on my test machine, though. #41: Dean Hilkewich (deanjo13) (2009-07-07 16:36:55) (reply to #38) When it comes to indexing services spotlight is far ahead of beagle in usability and performance. It is also easily disabled with a system setting if desired. Even on old G4's spotlight doesn't kill performance like beagle does. #42: Segundo Luis Martín Díaz Sotomayor (zchronos) (2009-07-07 17:47: 18) Beagle should be disabled by default. + #49: Vincent Untz (vuntz) (2009-07-18 18:42:21) + Fixed in GNOME:Factory, and submitted to openSUSE:Factory (#14802). -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 306908] Access control in Build Service
by fate_noreply＠suse.de 17 Jul '09

17 Jul '09

Feature added by: Srinidhi B S (srinidhi) Feature #306908, revision 1 Title: Access control in Build Service Hackweek IV: Unconfirmed Priority Requester: Important Requested by: Srinidhi B S (srinidhi) Description: Implement access control in Build Service so that a project maintainer or admin can disallow "read" access to a project / package according to the accessing "user's roles". Currently, "all users" have read access and any user with "maintainer" role inside a project / package can write to the project / package. Extend the existing "permission" set so as to allow more granular ACLs. Not sure if this would really make sense to a public instance of Build Service - like the OpenSUSE Build Service itself - but has real value in a local Build Service instance. Use Case: TeamA and TeamB are involved in the same project (or product, since Build Service has no distinction) in a local instance of Build Service. TeamB is working on a new package, say alpha, inside the same project whose sources have a proprietary nature or fall under some kind of Non-Disclosable agreement. TeamB wants to continue leveraging the power of Build Service for this package as well. As of today, there's no way TeamB can hide the sources of "alpha" from members of TeamA. But with the help of ACLs, TeamB's project maintainer can easily set permission flags on package "alpha" to be accessed only by the members of TeamB. -- openSUSE Feature: https://features.opensuse.org/306908

1 0

[openFate 305692] Better hardware support in SAX
by fate_noreply＠suse.de 17 Jul '09

17 Jul '09

Feature added by: Andrey Karepin (EGDFree) Feature #305692, revision 1, last change by Title: Better hardware support in SAX openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Andrey Karepin (egdfree) Partner organization: openSUSE.org Description: For example: * horizontal scrolling on mouse Logitec G5 out of the box * add to SAX profile keyboard Logitec Wave, with the support of all the extra keys (multemidiynyh and Fn) * add to SAX profile for your monitor Acer P223W (P243W, etc.) and its auto-detect -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305692

1 11

[openFATE 302306] Reorganization of YaST control center
by fate_noreply＠suse.de 17 Jul '09

17 Jul '09

Feature changed by: Michael Löffler (michl19) Feature #302306, revision 65 Title: Reorganization of YaST control center openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-03 17:08:02 reject reason: Postponing, we are running out of time. Priority Requester: Mandatory openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-25 15:09:31 reject reason: Needs more discussion. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.1: Rejected by Federico Lucifredi (flucifredi) reject date: 2008-07-18 18:56:09 reject reason: postponing as per engineering's request. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Rejected by Jiri Srain (jsrain) reject date: 2009-07-17 10:19:44 reject reason: Let's do it early in the 11.2 development cycle to have feedback from Alpha snapshots and be able to adjust. Priority Requester: Mandatory Projectmanager: Important - openSUSE-11.3: New + openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Martin Schmidkunz (mschmidkunz) Description: As many users (even the experienced ones) find the current organization of YaST modules confusing a reorganization is needed. We have conducted a usability study where experienced users sorted the YaST modules. So I would really ask to take advantage of these data. You find the data and some thoughts about a possible re-categorization on: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study The reorganization would affect the sorting and presentation, some labeling issues, the use of a consistent icon set, the use of tool tips and an enhancment of search One possible solution would be to organize it similar to the GNOME configuration center: I already heard that it might be mandatory to present AppArmor as an extra section (which in my opinion would be not advisable from a usability perspective, but if it is mandatory, then we have to add it as an extra section). I also thought that some YaST modules (e.g. keyboard, mouse, DNS, Hostname) are doublicated but it turned out, that this makes sense for SLES. Still I suggest combining the modules "user management" and "group management" into a single module called "User and Group Management". This makes sense because opening "user management" and "group management" opens the same module but only show a different view. Documentation Impact: This would require a lot of changes throughout the manuals. Discussion: #1: Tanja Roth (ta-ro) (2007-05-30 14:33:36) Would a reorganization apply to both KDE and GNOME desktop, then? Whatever a new YaST structure would look like, from a doc perspective it would be important that YaST structure and appearance are in sync for both desktops as we strive to use a "common doc base" for both desktops whereever possible to reduce efforts and costs. As reorganization of YaST would require many changes throughout our manuals, we cannot afford to additionally maintain different "flavors" of YaST chapters for KDE/GNOME. Apart from that, consistent structure and appearance of YaST in both desktops would also be a benefit for users. #2: Stanislav Visnovsky (visnov) (2007-06-12 11:40:45) Sigi, is the card study finished now? Where can we find the results? #3: Martin Schmidkunz (mschmidkunz) (2007-06-12 13:58:58) > Would a reorganization apply to both KDE and GNOME desktop, then? Yes. Exactly for the reasons you named, Tanja :-) By the way, a reorganization of YaST control center already took place in SLES 10 SP1. This solution is similar to what Sigi and I suggested. Perhaps it would be a good idea to take the YaST control center as it is in SLES 10 SP1, improve it a little and implement its design into all our products. What do you think about that? #4: Stanislav Visnovsky (visnov) (2007-06-12 14:00:46) (reply to #3) There was no reorganization for SLE10 SP1. The only change was introduction of slab-based GNOME control center for YaST. The categorization, description and module lists did not change and are shared between KDE and GNOME control centers. #5: Martin Schmidkunz (mschmidkunz) (2007-06-12 18:01:19) I am sorry for a missunderstanding. I meant that we should take the current "GNOME control centre" - like design of the YaST control centre in SLES 10 SP 1 as a base for a redesign of the YaST control centre in our other products. Additionally to that, we should discuss (and perform) a reorganization of modules. #7: Federico Lucifredi (flucifredi) (2007-06-29 17:59:43) (reply to #5) This is worth pursuing, I am no UX expert, but if we can make it easier for users to find things, we should. A reorganization should be well thought-out, so that we break the existing habits *only once*, we should not be reshuffling things too often. #8: Siegfried Olschner (sdolschn) (2007-07-03 12:35:30) The results of the the cardsort study are available at: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study The subjects (N=~30) have been "Experts", so you can transfer the results to a new openSUSE YaST Control Center. The cluster trees with 2 different statistical options show only one difference: - ISDN, Modem, DSL, Network => Hardware - ISDN, Modem, DSL, Network => Network see http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study#Illustrative_M… I'm just writing a sumary. This section is placed at the top of the page. #9: Siegfried Olschner (sdolschn) (2007-07-03 12:39:23) I got only 2-3 NOT-Expert users in the sample. Their results are not presented on the page. But it's clear, they separated out cards like: VLM, iSCSI Initiator, Powertweak, VNC, Sudo, AppArmor, LDAP, etc., etc. #10: Siegfried Olschner (sdolschn) (2007-07-06 10:05:23) Some mockups available at: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study#Sorting_and_pr… #11: Martin Schmidkunz (mschmidkunz) (2007-11-29 13:50:55) Some additional mock ups and thoughs about that topic are available at: http://en.opensuse.org/YaST/Development/New_Control_Center #13: Martin Schmidkunz (mschmidkunz) (2008-02-11 15:24:24) One other suggestion was influenced by the KDE 4 control center: http://en.opensuse.org/YaST/Development/New_Control_Center/YaST_KDEstyle The main concerns with these mock ups are: * information overload * "search" is somehow meaningless if it isn't provided by some kind of thesaurus #15: Berthold Gunreben (azouhr) (2008-04-09 12:52:12) I don't know if this is just too late, but for me the only design that looks like a real step forward from all the designs on http://en.opensuse.org/YaST/Development/New_Control_Center/ is http://en.opensuse.org/YaST/Development/New_Control_Center/YaST_System_Navi… I really like this approach. Please don't just create huge lists of modules, or preselected lists of modules that never can meet the customers needs. #16: Duncan Mac-Vicar (dmacvicar) (2008-04-24 14:56:14) This feature was on impl. But limited resources and refocus on PackageKit froze development. Passing back to Stano. #17: Federico Lucifredi (flucifredi) (2008-06-13 19:49:56) lets figure out a plan and get it done this time :) #20: Martin Schmidkunz (mschmidkunz) (2007-09-29 03:17:48) As there is some negative feedback from the KDE 4 personal settings menu (https://bugzilla.novell.com/show_bug.cgi?id=431432), maybe we should take it into account when talking about a YaST control center redesign. BTW: what is the status on this feature request? #21: Thomas Göttlicher (tgoettlicher) (2008-10-23 17:03:56) (reply to #20) Thanks for this hint. Development on this featrue is postponed. #22: evamaria fuchs (nefuchs) (2009-01-22 17:49:48) Currently we are conducting usability tests, see: http://en.opensuse.org/YaST/Development/New_Control_Center#Usability_Tests #24: Karl Eichwalder (keichwa) (2009-05-08 07:37:16) For what's worth, things got worse in the meantime ;) This feature needs to be split into 2 or 3 subfeatures: * Improve labels (e.g., "/etc/sysconfig Editor" -> "Sysconfig Editor"). * Reorganize groups: Move items from "Other" to Miscellaneous, split Network Services into Network Servers and Network Clients, make the Apparmor entries one entry and move it to Security, make Virtualization entries one entry and move it to System, move Hostnames from Network Services to Network Devices and rename Network Devices to "Network Devices and Hostnames". * Improve the UI. The Gnome CC is rahter pointless because its left navigation (?) is just superfluous (ok, there is now "Common Tasks"...). Because YaST contains more groups and especially entries, we need a way to hide or collapse groups completely. (I do not like the KDE idea just to display a subset of the entries of a group.) BTW, the worst thing about yast's gtk ui is the idea of sorting groups alphabetically. In English, happily "Hardware" comes before "Miscellaneous"... #25: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:24:54) the split between kcontrol and yast is confusing #26: Rémy Marquis (spyhawk) (2009-06-05 02:22:02) (reply to #25) This issue has already been discussed here : http://duncan.mac-vicar.com/blog/archives/452 #27: jimbo bigcreed (dimble_thricefoon) (2009-06-17 16:10:31) (reply to #26) cheers for the info. as long as they provide a non-confusing synthesis of the two related system management functions in a native QT4.5 environment i will be happy. -- openSUSE Feature: https://features.opensuse.org/302306

1 0

[openFATE 302306] Reorganization of YaST control center
by fate_noreply＠suse.de 17 Jul '09

17 Jul '09

Feature changed by: Jiri Srain (jsrain) Feature #302306, revision 63 Title: Reorganization of YaST control center openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-03 17:08:02 reject reason: Postponing, we are running out of time. Priority Requester: Mandatory openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-25 15:09:31 reject reason: Needs more discussion. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.1: Rejected by Federico Lucifredi (flucifredi) reject date: 2008-07-18 18:56:09 reject reason: postponing as per engineering's request. Priority Requester: Mandatory Projectmanager: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Jiri Srain (jsrain) + reject date: 2009-07-17 10:19:44 + reject reason: Let's do it early in the 11.2 development cycle to have + feedback from Alpha snapshots and be able to adjust. Priority Requester: Mandatory Projectmanager: Important + openSUSE-11.3: New + Priority + Requester: Mandatory Requested by: Martin Schmidkunz (mschmidkunz) Description: As many users (even the experienced ones) find the current organization of YaST modules confusing a reorganization is needed. We have conducted a usability study where experienced users sorted the YaST modules. So I would really ask to take advantage of these data. You find the data and some thoughts about a possible re-categorization on: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study The reorganization would affect the sorting and presentation, some labeling issues, the use of a consistent icon set, the use of tool tips and an enhancment of search One possible solution would be to organize it similar to the GNOME configuration center: I already heard that it might be mandatory to present AppArmor as an extra section (which in my opinion would be not advisable from a usability perspective, but if it is mandatory, then we have to add it as an extra section). I also thought that some YaST modules (e.g. keyboard, mouse, DNS, Hostname) are doublicated but it turned out, that this makes sense for SLES. Still I suggest combining the modules "user management" and "group management" into a single module called "User and Group Management". This makes sense because opening "user management" and "group management" opens the same module but only show a different view. Documentation Impact: This would require a lot of changes throughout the manuals. Discussion: #1: Tanja Roth (ta-ro) (2007-05-30 14:33:36) Would a reorganization apply to both KDE and GNOME desktop, then? Whatever a new YaST structure would look like, from a doc perspective it would be important that YaST structure and appearance are in sync for both desktops as we strive to use a "common doc base" for both desktops whereever possible to reduce efforts and costs. As reorganization of YaST would require many changes throughout our manuals, we cannot afford to additionally maintain different "flavors" of YaST chapters for KDE/GNOME. Apart from that, consistent structure and appearance of YaST in both desktops would also be a benefit for users. #2: Stanislav Visnovsky (visnov) (2007-06-12 11:40:45) Sigi, is the card study finished now? Where can we find the results? #3: Martin Schmidkunz (mschmidkunz) (2007-06-12 13:58:58) > Would a reorganization apply to both KDE and GNOME desktop, then? Yes. Exactly for the reasons you named, Tanja :-) By the way, a reorganization of YaST control center already took place in SLES 10 SP1. This solution is similar to what Sigi and I suggested. Perhaps it would be a good idea to take the YaST control center as it is in SLES 10 SP1, improve it a little and implement its design into all our products. What do you think about that? #4: Stanislav Visnovsky (visnov) (2007-06-12 14:00:46) (reply to #3) There was no reorganization for SLE10 SP1. The only change was introduction of slab-based GNOME control center for YaST. The categorization, description and module lists did not change and are shared between KDE and GNOME control centers. #5: Martin Schmidkunz (mschmidkunz) (2007-06-12 18:01:19) I am sorry for a missunderstanding. I meant that we should take the current "GNOME control centre" - like design of the YaST control centre in SLES 10 SP 1 as a base for a redesign of the YaST control centre in our other products. Additionally to that, we should discuss (and perform) a reorganization of modules. #7: Federico Lucifredi (flucifredi) (2007-06-29 17:59:43) (reply to #5) This is worth pursuing, I am no UX expert, but if we can make it easier for users to find things, we should. A reorganization should be well thought-out, so that we break the existing habits *only once*, we should not be reshuffling things too often. #8: Siegfried Olschner (sdolschn) (2007-07-03 12:35:30) The results of the the cardsort study are available at: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study The subjects (N=~30) have been "Experts", so you can transfer the results to a new openSUSE YaST Control Center. The cluster trees with 2 different statistical options show only one difference: - ISDN, Modem, DSL, Network => Hardware - ISDN, Modem, DSL, Network => Network see http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study#Illustrative_M… I'm just writing a sumary. This section is placed at the top of the page. #9: Siegfried Olschner (sdolschn) (2007-07-03 12:39:23) I got only 2-3 NOT-Expert users in the sample. Their results are not presented on the page. But it's clear, they separated out cards like: VLM, iSCSI Initiator, Powertweak, VNC, Sudo, AppArmor, LDAP, etc., etc. #10: Siegfried Olschner (sdolschn) (2007-07-06 10:05:23) Some mockups available at: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study#Sorting_and_pr… #11: Martin Schmidkunz (mschmidkunz) (2007-11-29 13:50:55) Some additional mock ups and thoughs about that topic are available at: http://en.opensuse.org/YaST/Development/New_Control_Center #13: Martin Schmidkunz (mschmidkunz) (2008-02-11 15:24:24) One other suggestion was influenced by the KDE 4 control center: http://en.opensuse.org/YaST/Development/New_Control_Center/YaST_KDEstyle The main concerns with these mock ups are: * information overload * "search" is somehow meaningless if it isn't provided by some kind of thesaurus #15: Berthold Gunreben (azouhr) (2008-04-09 12:52:12) I don't know if this is just too late, but for me the only design that looks like a real step forward from all the designs on http://en.opensuse.org/YaST/Development/New_Control_Center/ is http://en.opensuse.org/YaST/Development/New_Control_Center/YaST_System_Navi… I really like this approach. Please don't just create huge lists of modules, or preselected lists of modules that never can meet the customers needs. #16: Duncan Mac-Vicar (dmacvicar) (2008-04-24 14:56:14) This feature was on impl. But limited resources and refocus on PackageKit froze development. Passing back to Stano. #17: Federico Lucifredi (flucifredi) (2008-06-13 19:49:56) lets figure out a plan and get it done this time :) #20: Martin Schmidkunz (mschmidkunz) (2007-09-29 03:17:48) As there is some negative feedback from the KDE 4 personal settings menu (https://bugzilla.novell.com/show_bug.cgi?id=431432), maybe we should take it into account when talking about a YaST control center redesign. BTW: what is the status on this feature request? #21: Thomas Göttlicher (tgoettlicher) (2008-10-23 17:03:56) (reply to #20) Thanks for this hint. Development on this featrue is postponed. #22: evamaria fuchs (nefuchs) (2009-01-22 17:49:48) Currently we are conducting usability tests, see: http://en.opensuse.org/YaST/Development/New_Control_Center#Usability_Tests #24: Karl Eichwalder (keichwa) (2009-05-08 07:37:16) For what's worth, things got worse in the meantime ;) This feature needs to be split into 2 or 3 subfeatures: - * Improve labels (e.g., "/etc/sysconfig Editor" -> "Sysconfig Editor"). * Reorganize groups: Move items from "Other" to Miscellaneous, split Network Services into Network Servers and Network Clients, make the Apparmor entries one entry and move it to Security, make Virtualization entries one entry and move it to System, move Hostnames from Network Services to Network Devices and rename Network Devices to "Network Devices and Hostnames". * Improve the UI. The Gnome CC is rahter pointless because its left navigation (?) is just superfluous (ok, there is now "Common Tasks"...). Because YaST contains more groups and especially entries, we need a way to hide or collapse groups completely. (I do not like the KDE idea just to display a subset of the entries of a group.) - BTW, the worst thing about yast's gtk ui is the idea of sorting groups alphabetically. In English, happily "Hardware" comes before "Miscellaneous"... #25: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:24:54) the split between kcontrol and yast is confusing #26: Rémy Marquis (spyhawk) (2009-06-05 02:22:02) (reply to #25) This issue has already been discussed here : http://duncan.mac-vicar.com/blog/archives/452 #27: jimbo bigcreed (dimble_thricefoon) (2009-06-17 16:10:31) (reply to #26) cheers for the info. - as long as they provide a non-confusing synthesis of the two related system management functions in a native QT4.5 environment i will be happy. -- openSUSE Feature: https://features.opensuse.org/302306

1 0

[openFATE 120340] Run download and install in parallel
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Giuseppe Salinaro (Superpeppo89) Feature #120340, revision 93 Title: Run download and install in parallel openSUSE-10.2: Rejected by Klaus Kämpf (kwk) reject date: 2006-08-09 11:36:10 reject reason: Not possible in 10.2 timeframe Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-08-01 10:25:01 reject reason: Out of time. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Jiri Srain (jsrain) reject date: 2008-03-28 13:56:11 reject reason: Out of resources for 11.0. Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 12:06:35 reject reason: This needs to wait. Postponing. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-03 08:43:03 reject reason: No resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Klaus Kämpf (kwk) Requested by: Peter Poeml (poeml) Requested by: Reinhard Max (rmax) Description: Network installation could be improved by running package download and package installation in parallel. References: https://bugzilla.novell.com/show_bug.cgi?id=60844 https://bugzilla.novell.com/show_bug.cgi?id=209799 https://bugzilla.novell.com/show_bug.cgi?id=128050 https://bugzilla.novell.com/show_bug.cgi?id=370457 https://bugzilla.novell.com/show_bug.cgi?id=370054 https://bugzilla.novell.com/show_bug.cgi?id=385711 http://en.opensuse.org/Libzypp/Failover http://metalinker.org/ Fate #300660: Download package groups before install Discussion: #2: Klaus Kämpf (kwk) (2006-08-09 11:36:42) Michael already looked at this. Should be further evaluated for 10.3 #3: Edith Parzefall (emapedl) (2007-07-31 16:56:12) Problem is: what do we do if we lost the network connection when only half the packages are installed? #7: Reinhard Max (rmax) (2008-04-10 11:42:43) (reply to #3) I think this is a general problem for network based installations. Can you elaborate if/why you see this as a special problem when download and installation are running in parallel? #8: Peter Poeml (poeml) (2008-05-19 14:49:53) (reply to #7) For reliable operation of a business critical server, it is a must that packages are downloaded first, before the installation/update is started. Otherwise a network outage can lead to a broken system which is half updated. So if parallel download/install is implemented (for desktop users, maybe...) then please make sure that it is possible to disable it. #9: Reinhard Max (rmax) (2008-05-19 16:01:15) (reply to #8) As we just sorted out on IRC, the current implementation also doesn't allow to complete download before starting installation and the feature proposed here wouldn't make this worse. But as the wish of server admins to have all packages downloaded before starting to install them is very valid, I think we should extend this feature request to contain that requirement as well, and probably rename it to "decouple download and installation". If download and installation are properly decoupled, it should just be a matter of the parameters the algorithm is called with to get one of the following behaviours: * Download and install packages one by one (as it is now) * Keep downloading subsequent packages while installing (as originally proposed here) * Use a fixed-size download cache for flow control between download an installations (in situations where download is faster than installation and disk space is limited) * Download all packages of an update or installation and install them afterwards (as requested by Peter for server admins) #10: Jiri Srain (jsrain) (2008-05-20 10:22:10) (reply to #9) We already do have similar feature: #300660: Download package groups before install #4: Edith Parzefall (emapedl) (2007-07-31 16:57:22) Please reject for 10.3. #5: Duncan Mac-Vicar (dmacvicar) (2008-01-10 16:23:46) This is included in the ZYpp plan for 11.0, however implementation will start after beta. Will keep in evaluation, it depends on other milestones for beta1 #14: Chris Hills (chaz6) (2009-02-16 16:42:06) Is there a feature request to install using both the base and updates repo so that the latest packages available at install-time are used, thus saving bandwidth? #15: Jiri Srain (jsrain) (2009-02-17 08:45:38) (reply to #14) This is how it works for quite some time. Repositories providing patches also provide the packages so that they can be installed directly from the update repositories (provided they contain newer version). #16: Duncan Mac-Vicar (dmacvicar) (2009-06-02 15:18:00) For 11.2 we will focus on flexibility of the download and install order (like installing after everything is downloaded), however parallel stuff should be done after we have this in place. Please reject. #17: Michal Papis (mpapis) (2009-07-04 20:58:23) I think great example here may be Gentoo, there You can chose the way of getting packages, by default download and installation go in paraler, but it is possible to get first sources and then run build/installation. If you are on the default and something breaks, ex. network, Yuo can always resume the last download&installation task. + #18: Giuseppe Salinaro (superpeppo89) (2009-07-16 19:37:27) (reply to + #17) + This idea of gentoo is good... -- openSUSE Feature: https://features.opensuse.org/120340

1 0

[openFATE 305546] Support for NTLM authentication (proxy) in YaST and libzypp
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305546, revision 8 Title: Support for NTLM authentication (proxy) in YaST and libzypp - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-07-16 18:02:44 + reject reason: out of context for openSUSE. Priority Requester: Desirable Projectmanager: Desirable Requested by: Katarina Machalkova (kmachalkova) Partner organization: openSUSE.org Description: YaST and libzypp should work in an environment with proxy server requiring NTLM authentication. The feature consists of two parts: 1) YaST proxy module has to provide UI to let user choose NTLM and write configuration file (/root/.curlrc) accordingly 2) libzypp media backend needs to be adapted to read and understand such configuration( that is, accept also --proxy-ntlm option instead of bare --proxy only) References: https://bugzilla.novell.com/show_bug.cgi?id=440296 https://bugzilla.novell.com/show_bug.cgi?id=412137 Business case (Partner benefit): openSUSE.org: Significant for adoption in mixed datacenters where the proxy infrastruture is on MSFT assets. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:57:23) Sadly, there is a realistic business case for this in mixed datacenters. Some odd people like to use NTLM proxies, I will never understand why. this will be a headache to do :-/ -- openSUSE Feature: https://features.opensuse.org/305546

1 0

[openFATE 303873] Reducing pop ups during installation
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Christoph Thiel (cthiel1) Feature #303873, revision 16 Title: Reducing pop ups during installation openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-08 11:01:26 reject reason: This can wait. Postponing. Priority Requester: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-07-16 17:47:05 + reject reason: out of resources for 11.2. Priority Requester: Important Projectmanager: Desirable + openSUSE-11.3: New + Priority + Requester: Important Requested by: Martin Schmidkunz (mschmidkunz) Description: Before installing the system the user is asked to confirm various licenses. Each license is presented via pop up. Depending on the selected packages the user might be forced to accept quite a lot of them. This is quite unusable and we should think about how to reduce these. One idea might be: http://en.opensuse.org/Image:Installation_nopopups.png Not for SLES: Furthermore after accepting all these licenses the user has to confirm the installation in an extra pop up. I do not see the necessity for that pop up as users made the experience with other operating systems who do not ask the user for comfirmation (Apple Mac OS, MS Windows, Ubuntu, Red Hat Enterprise Linux, Fedora) that installation means that something will happen to their hard drive. Discussion: #1: Matthias Eckermann (mge1512) (2008-05-15 12:10:27) I agree with and like: http://en.opensuse.org/Image:Installation_nopopups.png But the extra pop-up for "YES, I really want to wipe my harddisk" must remain, as it is a security and safetiness issue. Marking this part of the idea as "Not for SLES". Federico, what is your opinion here? #2: Michael Löffler (michl19) (2008-05-15 12:27:44) Ciaran can you give the view from a legal perspective? #3: Ciaran Farrell (babelworx) (2008-05-16 11:51:38) I like the setup described in the screenshot and believe that it certainly gives the person installing the opportunity to review every license individually. In fact, I'm going to suggest to Patrick Mc Bride that this could be a default license acceptance method as it is far better than what we currently have available (i.e. all or nothing system). I'll ask Christopher De Nicolo for his opinion (from a german legal perspective). #4: Federico Lucifredi (flucifredi) (2008-05-22 15:47:44) I just went through the 11.0 beta 3 workflow, and I am satisfied with the current state. the mock-up is ok, but consider this: while it is true that you get prompted 5 times to approve licenses, if there is something that users are trained to do, in all platforms, is precisely click accept :-) I would say we can proceed with it, but I don't consider it a major issue, and not a usability problem. by the way, the 11.0 install workflow rocks :-) -- openSUSE Feature: https://features.opensuse.org/303873

1 0

[openFATE 302573] Make auto-selected-packages popup configurable
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Christoph Thiel (cthiel1) Feature #302573, revision 10 Title: Make auto-selected-packages popup configurable openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-03-27 15:37:25 reject reason: Postponing to be considered for future YaST swmgmt UI changes. Priority Requester: Desirable openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-07 12:53:40 reject reason: More important tasks to solve. Priority Requester: Desirable - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-07-16 17:41:00 + reject reason: out of resources for 11.2. Priority Requester: Desirable Projectmanager: Desirable + openSUSE-11.3: New + Priority + Requester: Desirable Requested by: Lukas Ocilka (locilka) Description: YaST Packager has a special popup after the the list of selected packages is accepted. This popup says something like: These packages were automatically added to the list of packages: * package A * package B Some think that it is a bug and such popup should not appear at all (and packages should be added without asking), some think that it is a nice feature. Having it configurable, e.g., [x] Do not show this dialog again should be good enough for both. Note: this touches both installation and running system, so if decision is made in the installation, it should be copied to the installed system as well. References: Bug 298565 - package selector shouldn't ask about installing more packages (https://bugzilla.novell.com/show_bug.cgi?id=298565) -- openSUSE Feature: https://features.opensuse.org/302573

1 0

[openFATE 305551] Document YaST RELAX NG Schema
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305551, revision 8 Title: Document YaST RELAX NG Schema - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-07-16 16:26:24 + reject reason: out of resources for 11.2. Priority Requester: Desirable Projectmanager: Important Requested by: Thomas Schraitle (thomas-schraitle) Partner organization: openSUSE.org Description: According to bnc#455994 (comment #17) Lukas Ocilka suggested to create a FATE entry for this purpose. Background: The YaST DTD for /etc/YaST2/firstboot.xml and the like is outdated and lead to invalid XML files. The DTD is/was rewritten as a RELAX NG Schema but elements, attributes, and attribute values are not documented yet. Business case (Partner benefit): openSUSE.org: * Documented RNG schema supports XML editors in showing tool tips during the writing of a XML file. * WIth the help of XSLT a summary can be created automatically. > reduces costs Discussion: #1: Lukas Ocilka (locilka) (2009-01-16 16:32:28) The XML format of a control file is currently documented at http://forgeftp.novell.com/yast/doc/SL11.1/tdg/inst_in_general_chap.html (generated from manually written docbook file) nevertheless this means that it has to be done at two places at once: the RELAX NG schema and its documentation itself. Having the documentation source insite the RELAX NG schema would halp to keep the documentation in sync. -- openSUSE Feature: https://features.opensuse.org/305551

1 0

[openFATE 305551] Document YaST RELAX NG Schema
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305551, revision 9 Title: Document YaST RELAX NG Schema openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 16:26:24 reject reason: out of resources for 11.2. Priority Requester: Desirable Projectmanager: Important + openSUSE-11.3: New + Priority + Requester: Desirable Requested by: Thomas Schraitle (thomas-schraitle) Partner organization: openSUSE.org Description: According to bnc#455994 (comment #17) Lukas Ocilka suggested to create a FATE entry for this purpose. Background: The YaST DTD for /etc/YaST2/firstboot.xml and the like is outdated and lead to invalid XML files. The DTD is/was rewritten as a RELAX NG Schema but elements, attributes, and attribute values are not documented yet. Business case (Partner benefit): openSUSE.org: * Documented RNG schema supports XML editors in showing tool tips during the writing of a XML file. * WIth the help of XSLT a summary can be created automatically. > reduces costs Discussion: #1: Lukas Ocilka (locilka) (2009-01-16 16:32:28) The XML format of a control file is currently documented at http://forgeftp.novell.com/yast/doc/SL11.1/tdg/inst_in_general_chap.html (generated from manually written docbook file) nevertheless this means that it has to be done at two places at once: the RELAX NG schema and its documentation itself. Having the documentation source insite the RELAX NG schema would halp to keep the documentation in sync. -- openSUSE Feature: https://features.opensuse.org/305551

1 0

[openFATE 305158] Make summary of partitioning changes more readable
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305158, revision 6 Title: Make summary of partitioning changes more readable - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-07-16 16:23:32 + reject reason: no resources for 11.2 Priority Requester: Important Projectmanager: Desirable Requested by: Martin Schmidkunz (mschmidkunz) Description: Before applying the changes made by the partitioner the user is presented by a colorful pop up (http://en.opensuse.org/Image:Part_current_popup.png). The idea is to replace this pop up by a nice, clearly structured full screen summary (http://en.opensuse.org/Image:Summary_partitioner.png). The summary lines ("partition X will be formatted", "fstab options changed for partition Y") come from libstorage and the interface is pretty generic so far. In other words, it has no support for grouping the lines (putting hard disk related msgs together, similarly with LVMs, RAIDs etc.) According to developers it would require significant changes to libstorage. -- openSUSE Feature: https://features.opensuse.org/305158

1 0

[openFATE 305147] Wizard mode for Network Card configuration (in YaST)
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Marcus Meissner (msmeissn) Feature #305147, revision 12 Title: Wizard mode for Network Card configuration (in YaST) openSUSE-11.2: Evaluation Priority Requester: Neutral Requested by: Michal Zugec (mzugec) Description: (based on "Internet/Intranet with external Router" in suse-beta-e) It seems some users don't know how to setup the SuSEfirewall correctly. Especially, they don't know if they should setup a network card as internal or external device. If a network card is found, YaST should ask for its usage (local network or directly connected to the internet?) - every user should know. With this information the firewall setup can be done in a useful way. See bugzilla https://bugzilla.novell.com/show_bug.cgi?id=67415 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:34:01) sounds reasonable. But how many multihomed systems do we find where the user "does not know" ? Besides, the security team's policy seems to be "lock everything, ask questions later", so I am not sure they are willing to mollify the firewall rules (for instance, open up Avahi by default, or other default daemons) on a "local" interface. Asking Marcus for insight. I am not sure on this one. #2: T. J. Brumfield (enderandrew) (2009-06-13 02:33:51) I'd contend that openSUSE and SLES/SLED should be treated differently here. With SLES/SLED, I'd err more on the side of caution and security, where as with openSUSE, I'd err more on the side of making the system user friendly. + #3: Marcus Meissner (msmeissn) (2009-07-16 14:35:43) + What we have investigated, or better Ludwig has investigated, is a + Desktop Applet that can switch Firewall zones. See + http://lizards.opensuse.org/2009/07/10/1453/ + (Since most user machines these days are laptops, who vary between + zones.) + Perhaps this is more what is wanted? -- openSUSE Feature: https://features.opensuse.org/305147

1 0

[openFATE 306356] Icons in YaST: Use /usr/share/icons/hicolor/ as a fallback
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Jiri Srain (jsrain) Feature #306356, revision 7 Title: Icons in YaST: Use /usr/share/icons/hicolor/ as a fallback - openSUSE-11.2: Evaluation + openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Lukas Ocilka (locilka) Partner organization: openSUSE.org Description: YaST icons are expected to be in /usr/share/YaST2/theme/current/icons/ directory but the list of icons is fixed because the current is a symlink to the currently installed and selected theme-directory which is different for openSUSE or SLES. If another (e.g., 3rd party) YaST module wants to add its own icon, it has to put it into the current directory which will change when using another YaST theme. The proposal is simple: If an icon is not found in the current theme, try to use /usr/share/icons/hicolor/ as a fallback. Business case (Partner benefit): openSUSE.org: 3rd party add-ons with YaST modules, Our own add-ons with YaST modules (SMT, OES)... Discussion: #1: Christoph Thiel (cthiel1) (2009-04-20 17:30:28) Makes a lot of sense to me with regard to appliances and custom YaST themes. -- openSUSE Feature: https://features.opensuse.org/306356

1 0

[openFATE 303859] simple network configuration in 1st stage
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Jiri Srain (jsrain) Feature #303859, revision 28 Title: simple network configuration in 1st stage openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-09 10:04:08 reject reason: Postponing, out of resources. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Jiří Suchomel (jsuchome) Description: The feature of "Automatic Configuration" has a nice effect of not asking users for accepting all the default settings. However, there's (at least) one setting that is default but still not widely accepted (I think so - at least I change it always): it's the firewall that is automatically running. Wouldn't it be good to have some simple client, only opened from installation proposal upon user's request (so not by default) where could be this option configured? Even better would be "Network" part in Installation summary, with the only setting "Firewall on", which would be a link which value changes on click. References: https://bugzilla.novell.com/show_bug.cgi?id=379149 https://bugzilla.novell.com/show_bug.cgi?id=303859 Discussion: #1: Matthias Eckermann (mge1512) (2008-06-09 23:49:49) An automatically running firewall is great - for the average user. And this even applies in enterprise. I strongly recomment to reject this feature for ALL products: SLES, SLED and openSUSE, but leave it to Federico. Guy, Federico, Michl, Marcus? #2: Jiří Suchomel (jsuchome) (2008-06-10 07:49:31) (reply to #1) Well, I'm not asking for not starting firewall by default. I agree it is good to have it automatically on. But we miss an option to change this during the installation workflow. #3: Michal Svec (msvec) (2008-06-10 11:24:41) (reply to #2) Right, the proposal was to have a simple way, ideally a hyperlink, to disable the firewall, either completely or just for some services (ssh) somewhere accessible during the installation workflow. We should certainly keep the current default of running firewall automatically. #4: Lukas Ocilka (locilka) (2008-06-10 14:51:08) (reply to #3) It's quite easy to add another firewall_proposal client to the fist stage but that one could only provide enable/disable functionality (the default value is set in control file already). On the other hand, opening a firewall for some services couldn't be done as these services are known after packages with service- definitions are installed (firewall services defined by packages). Using other words: In the installed system. This feature is more about specific configuration dialogs providing functionality to Open Firewall for XYZ Service - I think only configuration of users is affected now (samba-client, SLP broadcast reply, ...?). #5: Jiří Suchomel (jsuchome) (2008-06-10 15:03:08) (reply to #4) No, it isn't. This feature is about possibility to either shut down the firewall or open ports for defined (not arbitrary) services (e.g. ssh). No samba, no SLP. It is called simple network configuration in 1st stage. #6: Lukas Ocilka (locilka) (2008-06-10 16:42:14) (reply to #5) Yes I know what is it called, but as I've already written, in first stage, firewall can be only enabled or disabled. No additional servics could be open as they are unknown in that stage. I'm just talking about the limits of the proposed firewall/network client in first stage. The rest is left on particular modules to open ports/services as required by a specific service used in second stage. Services are defined in packages, their ports, names, description. Even SSH has its own definition in openssh package: /etc/sysconfig/SuSEfirewall2.d/services/sshd . This package needen't be installed at all. #7: Jiří Suchomel (jsuchome) (2008-06-11 08:07:35) (reply to #6) And again, I am not requesting any configuration of services in this stage. Basically I want the same thing we have in current network proposal (at the beginning of currently-usually-unused 2nd stage) , where you can shut firewall down and/or open ssh port. If sshd is the problem (but in the time of installation proposal, we know if it is going to be installed or not, so it may be hidden if sshd is not selected for installation) it doesn't have to be there, and it may consist of simple firewall off/on hyperlink. So yes, it is true that firewall_proposal client ...could only provide enable/disable functionality , but this is actually the point of this feature. I should probably also make clear that I'm not requesting any additonal step in the sequence, only the option to be selected from installation summary, just like Installation from Images is enabled (disable) one. #8: Guy Lunardi (glunardi) (2008-06-12 17:34:47) (reply to #7) Could this be served by providing an hyperlink which would open the current network module presented during the normal installation? Like I had made my initial priority, I am pretty neutral on this. I think power users would appreciate the feature but most of our 1-time installation users would not care. I am fine having it if the investment is very small. #11: Jiří Suchomel (jsuchome) (2008-06-13 07:48:43) (reply to #8) Hyperlink yes, but for enabling/disabling, not for full firewall configuration. This is not really possible in 1st stage, see Lukas' comments 4 and 6. #9: Federico Lucifredi (flucifredi) (2008-06-12 18:11:07) Guys, I am not following... why do we want the enable/disable choice in 1st stage? Looks just fine to me as is. Please clarify what's the advantage of allowing the choice earlier. #10: Jiří Suchomel (jsuchome) (2008-06-13 07:47:11) (reply to #9) In previous versions, we had the network configuration proposed which user had to accept, but now the networking is (by default) configured automatically (and this is without debates fine for most users). The old screen with the network configuration had an option disable firewall with one click and this is the thing which I miss now (yes, it is possible to use the old way also in 11.0, but it brings bunch of other configuration options that are correctly done automatically). So, earlier actually means during installation . Of course this is possible to configure after the installation, but just like many other users, I'd like to have the system configured after the system is installed. #12: Federico Lucifredi (flucifredi) (2008-06-13 17:02:08) (reply to #10) okay - I understand. Yes, this is handy, as it saves the need to go through all the config when all one wants to do is remove the fw. _if_ there is a way to include in the early workflow, lets do it. Of course, that may not be the case on "keeping it simple" grounds. #13: Stanislav Visnovsky (visnov) (2008-06-19 13:21:59) (reply to #12) I agree, if we are able to find a reasonable place, would be nice to have. + #15: Jiri Srain (jsrain) (2009-07-16 12:26:49) + Bubli, please, add very simple Firewall configuration to the first + stage (only enabling/disabling firewall itself and opening/closing the + SSH port). -- openSUSE Feature: https://features.opensuse.org/303859

1 0

[openFATE 302411] Always mount root-fs under /dev/root
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Jiri Srain (jsrain) Feature #302411, revision 27 Title: Always mount root-fs under /dev/root openSUSE-10.3: Rejected by Ihno Krumreich (ihno) reject date: 2007-09-26 11:51:40 reject reason: Not decited yet. So rejected. Priority Requester: Mandatory openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-02-13 12:44:18 reject reason: We have a clear consense that we won't change anything for 11.0 that risks bootloader development (but rather concentrate on consolidating it) and as Jack outlined, it is a risk. Priority Requester: Mandatory openSUSE-11.2: Evaluation Priority Requester: Mandatory Projectmanager: Important Requested by: Hannes Reinecke (hreinecke) Description: The root filesystem should always be mounted at /dev/root, which in turn is a symlink to the actual device node. This way we don't have to edit /etc/fstab if the root device is named differently (ie for automatic booting from degraded mirrors etc). And it would help with having always a consistent /etc/fstab, as /dev/root will be always present. Documentation Impact: + Discussion: #1: Ihno Krumreich (ihno) (2007-07-27 11:52:12) Effort/risk in YaST / bootloader? #2: Stephan Kulow (coolo) (2007-11-19 22:44:38) (reply to #1) who do you ask? #3: Joachim Plack (jplack) (2008-01-14 13:58:33) In principle having a symbolic link for a root device does not make a problem. But _changing_ the symlink might make the current bootloader configuration inconsistent. E.g. Having root=/dev/root in the bootloader config and pointing to /dev/md0 (mirror) hints to duplicate the boot code to two disks, changing the symlink to point to a single disk changed the semantics of the config. So the risk is that by changing the symlink and doing a kernel update one might invalidate the boot configuration resulting in a possible unbootable system. #4: Matthias Eckermann (mge1512) (2008-06-06 09:15:25) (reply to #3) I understand the risk, but the feature itself sounds useful enough. Part of bootloader discussion. Not mandatory for now. #5: Stanislav Visnovsky (visnov) (2008-07-07 13:57:06) (reply to #4) Jiri, please, take a look. #7: Jiri Srain (jsrain) (2009-06-01 13:57:08) For GRUB configuration itself, the root= kernel parameter can be omited completly for standard installations (since initrd handles mounting root itself). I hope that just modifying the partitioner to write fstab should be sufficient in basic cased. However, since YaST needs to know which real device /dev/root is, it needs to exist during installation and be set properly (according to the target system). Probably just creating the symlink manually during installation after mounting the disk and writing fstab is sufficient? #8: Stephan Kulow (coolo) (2009-07-16 11:58:50) yast already handles /dev/root (checked with arvin) and the bootloader and /etc/fstab should not be touched. Just the initrd needs mount differently. #9: Arvin Schnell (aschnell) (2009-07-16 12:10:50) (reply to #8) YaST needs modification when /etc/fstab should contain /dev/root as the device for root-fs (as the description says). After all YaST writes /etc/fstab during installation. + #10: Jiri Srain (jsrain) (2009-07-16 12:22:05) (reply to #9) + Arvin, please, remember to ensure that the symlink itself also exists + even during installation/upgrade. -- openSUSE Feature: https://features.opensuse.org/302411

1 0

[openFATE 302411] Always mount root-fs under /dev/root
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Arvin Schnell (aschnell) Feature #302411, revision 26 Title: Always mount root-fs under /dev/root openSUSE-10.3: Rejected by Ihno Krumreich (ihno) reject date: 2007-09-26 11:51:40 reject reason: Not decited yet. So rejected. Priority Requester: Mandatory openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-02-13 12:44:18 reject reason: We have a clear consense that we won't change anything for 11.0 that risks bootloader development (but rather concentrate on consolidating it) and as Jack outlined, it is a risk. Priority Requester: Mandatory openSUSE-11.2: Evaluation Priority Requester: Mandatory Projectmanager: Important Requested by: Hannes Reinecke (hreinecke) Description: The root filesystem should always be mounted at /dev/root, which in turn is a symlink to the actual device node. This way we don't have to edit /etc/fstab if the root device is named differently (ie for automatic booting from degraded mirrors etc). And it would help with having always a consistent /etc/fstab, as /dev/root will be always present. Documentation Impact: + Discussion: #1: Ihno Krumreich (ihno) (2007-07-27 11:52:12) Effort/risk in YaST / bootloader? #2: Stephan Kulow (coolo) (2007-11-19 22:44:38) (reply to #1) who do you ask? #3: Joachim Plack (jplack) (2008-01-14 13:58:33) In principle having a symbolic link for a root device does not make a problem. But _changing_ the symlink might make the current bootloader configuration inconsistent. E.g. Having root=/dev/root in the bootloader config and pointing to /dev/md0 (mirror) hints to duplicate the boot code to two disks, changing the symlink to point to a single disk changed the semantics of the config. So the risk is that by changing the symlink and doing a kernel update one might invalidate the boot configuration resulting in a possible unbootable system. #4: Matthias Eckermann (mge1512) (2008-06-06 09:15:25) (reply to #3) I understand the risk, but the feature itself sounds useful enough. Part of bootloader discussion. Not mandatory for now. #5: Stanislav Visnovsky (visnov) (2008-07-07 13:57:06) (reply to #4) Jiri, please, take a look. #7: Jiri Srain (jsrain) (2009-06-01 13:57:08) For GRUB configuration itself, the root= kernel parameter can be omited completly for standard installations (since initrd handles mounting root itself). I hope that just modifying the partitioner to write fstab should be sufficient in basic cased. However, since YaST needs to know which real device /dev/root is, it needs to exist during installation and be set properly (according to the target system). Probably just creating the symlink manually during installation after mounting the disk and writing fstab is sufficient? #8: Stephan Kulow (coolo) (2009-07-16 11:58:50) yast already handles /dev/root (checked with arvin) and the bootloader and /etc/fstab should not be touched. Just the initrd needs mount differently. + #9: Arvin Schnell (aschnell) (2009-07-16 12:10:50) (reply to #8) + YaST needs modification when /etc/fstab should contain /dev/root as the + device for root-fs (as the description says). After all YaST writes + /etc/fstab during installation. -- openSUSE Feature: https://features.opensuse.org/302411

1 0

[openFATE 302411] Always mount root-fs under /dev/root
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Stephan Kulow (coolo) Feature #302411, revision 25 Title: Always mount root-fs under /dev/root openSUSE-10.3: Rejected by Ihno Krumreich (ihno) reject date: 2007-09-26 11:51:40 reject reason: Not decited yet. So rejected. Priority Requester: Mandatory openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-02-13 12:44:18 reject reason: We have a clear consense that we won't change anything for 11.0 that risks bootloader development (but rather concentrate on consolidating it) and as Jack outlined, it is a risk. Priority Requester: Mandatory openSUSE-11.2: Evaluation Priority Requester: Mandatory Projectmanager: Important Requested by: Hannes Reinecke (hreinecke) Description: The root filesystem should always be mounted at /dev/root, which in turn is a symlink to the actual device node. This way we don't have to edit /etc/fstab if the root device is named differently (ie for automatic booting from degraded mirrors etc). And it would help with having always a consistent /etc/fstab, as /dev/root will be always present. Documentation Impact: + Discussion: #1: Ihno Krumreich (ihno) (2007-07-27 11:52:12) Effort/risk in YaST / bootloader? #2: Stephan Kulow (coolo) (2007-11-19 22:44:38) (reply to #1) who do you ask? #3: Joachim Plack (jplack) (2008-01-14 13:58:33) In principle having a symbolic link for a root device does not make a problem. But _changing_ the symlink might make the current bootloader configuration inconsistent. E.g. Having root=/dev/root in the bootloader config and pointing to /dev/md0 (mirror) hints to duplicate the boot code to two disks, changing the symlink to point to a single disk changed the semantics of the config. So the risk is that by changing the symlink and doing a kernel update one might invalidate the boot configuration resulting in a possible unbootable system. #4: Matthias Eckermann (mge1512) (2008-06-06 09:15:25) (reply to #3) I understand the risk, but the feature itself sounds useful enough. Part of bootloader discussion. Not mandatory for now. #5: Stanislav Visnovsky (visnov) (2008-07-07 13:57:06) (reply to #4) Jiri, please, take a look. #7: Jiri Srain (jsrain) (2009-06-01 13:57:08) For GRUB configuration itself, the root= kernel parameter can be omited completly for standard installations (since initrd handles mounting root itself). I hope that just modifying the partitioner to write fstab should be sufficient in basic cased. However, since YaST needs to know which real device /dev/root is, it needs to exist during installation and be set properly (according to the target system). Probably just creating the symlink manually during installation after mounting the disk and writing fstab is sufficient? + #8: Stephan Kulow (coolo) (2009-07-16 11:58:50) + yast already handles /dev/root (checked with arvin) and the bootloader + and /etc/fstab should not be touched. Just the initrd needs mount + differently. -- openSUSE Feature: https://features.opensuse.org/302411

1 0

[openFATE 306315] Improve PK/zypper/YaST Big Lock
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Christoph Thiel (cthiel1) Feature #306315, revision 3 Title: Improve PK/zypper/YaST Big Lock - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-07-16 11:45:36 + reject reason: no resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important + Projectmanager: Important Requested by: Federico Lucifredi (flucifredi) + Partner organization: openSUSE.org Description: Currently, execution of any action by one of the package management tools blocks all others, in a "big lock" fashion". This is entirely acceptable when I am doing something with YaST, or running the PK applet, but it is very fastidious when it is due to background activity. Running zypper and seeing that lock message when nothing is being run by the user is very annoying (and is really the same for Yum on RHEL - but it still sucks :-) Can we improve the way PK refreshing causes everything else to lock up? I must say I expect upstream to be doing something about this... Business case (Partner benefit): - The lock interferes with Administrator activity at random moments, and - is very aggravating. It would be a competitive detail over RHEL, as - well as a customer satisfaction item. + openSUSE.org: The lock interferes with Administrator activity at random + moments, and is very aggravating. It would be a competitive detail over + RHEL, as well as a customer satisfaction item. Discussion: #1: Federico Lucifredi (flucifredi) (2009-03-30 21:13:47) I am somewhat reluctant to give this an M, as I do not know if something can actually be done to improve this. It would certainly warrant an M if a good solution can be devised, as this is really annoying on both SLES and RHEL, and it would make us look good in the comparison. -- openSUSE Feature: https://features.opensuse.org/306315

1 0

[openFATE 305503] zypper: allow update by issues/bugs/advisories
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305503, revision 28 Title: zypper: allow update by issues/bugs/advisories openSUSE-11.2: Candidate Priority Requester: Desirable Projectmanager: Mandatory Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Description: YUM security plugin allows to filter updates showing only ones that mention certain issues. Example: yum update --security yum update --bz 410101 yum update --cve CVE-2007-5707 --advisory RHSA-2007:1082-5 As our patches contains this metadata, we could add similar functionality to zypper. Scope The scope is only for zypper. Other front ends would require some GUI concept first. Open Issues: libzypp's PoolQuery would need support for subattributes (updateinfo. xml references are stored as subarrays) User experience * Adds command line options like the ones described above. Dependencies * libzypp Contingency Plan * Feature is new, so in a bad scenario it can simple be deactivated. Relations: - updateinfo XML scheme (url: http://git.opensuse.org/?p=projects/zypp/libzypp.git;a=blob_plain;f=zypp/pa…) - Tips and tricks: yum-security (url: http://www.redhatmagazine.com/2008/01/16/tips-and-tricks-yum-security/) Documentation Impact: New command line options would need to be documented. Test Case: The testing of this feature can be done creating a repository (for example using enhancerepo) containing patches that reference issues, like described in http://en.opensuse.org/Maintenance/Code11/Howto , and then performing updates passing to zypper command line the issues, confirming that only those issues are shown. Use Case: Sysadmin is only interested in particular updates to solve security issues or specific bug numbers or advisories. Business case (Partner benefit): openSUSE.org: Sysadmins do not update ther systems without a strict process and maximum care. Therefore it is very important to allow them to update the system to fix a single issue. It would save them the time to look that themselves package per package. Discussion: #1: Marcus Meissner (msmeissn) (2008-12-03 14:51:14) Random notes: - CVE-XXXX-YYYY RPM provides after fixing issues? - OVAL relation? #2: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:02:46) (reply to #1) About CVE provides. Right now the CVE information is in the patch (since 11.0). I don't have anything against having it as Fix(CVE-XXX-XXX) provides, but I am not sure if having them in both makes sense. Specially in the case that one issue needs more than one package, you will need to install all packages fixing the issue, and if you have 2 repos with 2 same packages providing the issue, they will conflict. #3: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:08:13) (reply to #1) I don't have knowledge how OVAL works, may be you can provide some very concrete example scenarios for the feature described above. What I can say is that the reason why the repository/product compatibility and update information in SLE11/openSUSE 11.1 is supported using CPE ( that is, product can contain a CPE id, and repos can tell to which CPE they are compatible and which CPE they update with fixes ) was to enhance our ability to do semantic queries like relate upstream security issues and installed products. OVAL uses CPE as the platform descriptor AFAIK. #4: Dirk Mueller (dirkmueller) (2008-12-04 14:58:01) adding rpm provides was also my first idea, but that has a side effect: often enough, CVE numbers are not yet known when the package is built and ends up in QA, and editing rpm provides essentially needs a rebuild, which invalidates QA. so preferably we need a way to update the rpm provides without doing a rebuild (bad) or we need a way to add it to the meta information (which is currently generated via patchinfo and where it is also too late). an idealistic approach would be to make sure that we can update this meta information after patchinfo checkin (entering the data into swamp and autobuild fetches that information when the update is released and adds it to the meta info). #5: Federico Lucifredi (flucifredi) (2009-01-07 15:52:34) This has quite a bit of customer value. BTW, there may be a duplicate out there #6: Michael Andres (mlandres) (2009-07-01 18:33:01) libzypp-6.9.2 supports PoolQuery of subattributes. So one can e.g search for patches with updateReferenceId "CVE-2007-5707', or of updateReferenceType 'bugzilla",... (I'll provide some sample code) @Jano: I'll provide some code example, that tells how to access and iterate the matching updateReferences. So you could start working on zypper. #7: Ján Kupec (jkupec) (2009-07-03 15:10:56) Thanx! I have a question about the reference types. What types do we support? in updateinfo.rnc (see references) i only see bugzilla and cve Do we want separate options for all supported types, like yum has? #9: Ján Kupec (jkupec) (2009-07-03 15:57:19) (reply to #7) Also, i noticed in 11.1 updates repository, that many bugs have a CVE, but it's only in the description, not in the 'reference' metadata. Only bugzilla is in 'reference'. Do we want to address this? #10: Marcus Meissner (msmeissn) (2009-07-03 15:59:21) (reply to #9) we are not emitting it yet. this also needs to be done :/ #8: Ján Kupec (jkupec) (2009-07-03 15:20:18) Suggestion how the commands could look like: $ zypper fix --search [string] $ zypper fix --bugzilla <#> $ zypper fix --cve <#> #11: Klaus Kämpf (kwk) (2009-07-04 12:11:44) (reply to #8) Please re-think about introducing another term ( fix ), we already have * update * upgrade * patch #12: Ján Kupec (jkupec) (2009-07-07 10:11:04) (reply to #11) What i try to achieve is to have a way to install the patches fixing the issues and a way to list them (issue number & patch name & (patch) description), search in them. The other alternatives i considered were: $ zypper patch [--bugzilla #] [--cve #] $ zypper list-patches --issues [string] The first command looks nice, but i don't know what to use to list/search the issues - the list-patches command does not seem right to me - looks more like it deserved a new command. $ zypper install [--bugzilla #] [--cve #] $ zypper search --issues [string] In this case, like in the 'list-patches --issues' case, the search command would either need to radically change its output, or user would need to call 'zypper patch-info the_found_patch' to get the patch description. Any other ideas? Why is having a new command a bad thing (esp. compared to having new options in the existing commands)? BTW: (We don't have 'upgrade' :O) #13: Martin Vidner (mvidner) (2009-07-07 14:33:03) (reply to #12) Why reinvent the wheel? Can we just copy yum's interface as described in the referenced yum-security article? * http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/ (http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/) * http://linux.die.net/man/8/yum-security (http://linux.die.net/man/8/yum-security) #14: Ján Kupec (jkupec) (2009-07-07 14:57:27) (reply to #13) 'zypper update' does not work with patches. 'zypper patch' looks to me like better candidate for new --bz or --cve options. yum does not make difference between these two. The yum plugin also adds a new command (list-sec), which was Klaus' objection. #15: Klaus Kämpf (kwk) (2009-07-07 15:51:26) (reply to #14) Well, my objection is the new term 'fix' besides 'update' and 'patch' and will confuse people. It should be an option to "list" or "list-patches" imho #16: Ján Kupec (jkupec) (2009-07-07 16:16:12) (reply to #15) OK, so far the following looks like a candidate (taken yum into account as well): # to install a fix $ zypper patch [--bz #] [--cve #] [--any-other #] # to list available needed fixes (issue-number, patchname-version, category, description) # all $ zypper list-patches --issues # matching a substring ("CVE", number, or any) $ zypper list-patches --issues foo # only CVEs/bugzillas $ zypper list-patches [--cve] [--bz] #17: Ján Kupec (jkupec) (2009-07-15 09:24:34) Done in zypper. You can fetch zypper 1.2.2 from home:jkupec:Factory to try and let me know what you think. New options in lp and patch commands: $ zypper help lp -b, --bugzilla[=#] List needed patches for Bugzilla issues. --cve[=#] List needed patches for CVE issues. --issues[=string] Look for issues matching the specified string. -a, --all List all patches, not only the needed ones. $ zypper help patch patch [options] -b, --bugzilla # Install patch fixing the specified bugzilla issue. --cve # Install patch fixing the specified CVE issue. --bz works, too. Can this feature be closed, or we'll close it after the repo metadata have the CVE references? #18: Ján Kupec (jkupec) (2009-07-15 09:30:38) One more thing that crossed my mind when looking at the yum article http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/ They seem to be able to associate issue numbers with spcecific packages. I'm not sure if this is because they just avoid issuing updates with plenty of packages in single <update> tags, like we often do? + #19: Christoph Thiel (cthiel1) (2009-07-16 11:33:39) (reply to #18) + Rudi, is autobuild planning to adding additional information to the + metadata? -- openSUSE Feature: https://features.opensuse.org/305503

1 0

[openFATE 305394] Move KDE software updates notifications to upstream infrastructure
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305394, revision 24 Title: Move KDE software updates notifications to upstream infrastructure - openSUSE-11.2: Evaluation + 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: New + Priority + Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) 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. -- openSUSE Feature: https://features.opensuse.org/305394

1 0

[openFATE 305313] creating nonexistent directories with Autoyast
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #305313, revision 13 Title: creating nonexistent directories with Autoyast - openSUSE-11.2: Evaluation + openSUSE-11.2: Done Priority Requester: Important Projectmanager: Important Requested by: Uwe Gansert (ug) Description: from bug #429491 It should be possible to create directories just like files with its permissions and ownership. Today it is impossible (using just "files") to put for example /root/.ssh/authorized_keys. To anticipate possible comments, the "file_script" is not IMHO the right way to deal with the problem since it is invoked after writing the file to a filesystem. Yet it may be considered a workaround as of today. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 14:19:55) up for Engineering's comment. Is workaround adequate ? #2: Milisav Radmanic (radmanic) (2009-04-16 14:06:01) The workaround is effective but technically not adequate. We should support creating directories like we do it for files. The request is off the mailinglist and makes sense. #3: Stanislav Visnovsky (visnov) (2009-05-28 16:41:02) Isn't it better to have support for untarring root.tar.gz to the filesystem like kiwi does? #4: Uwe Gansert (ug) (2009-06-04 15:37:40) (reply to #3) the idea of untaring a tgz is actually not that bad but in this case I'd prefer to keep it simple. A tgz needs to be stored in base64 format inside of the XML and it's not obvious what's in it by looking at the XML file. Changing something in that is a bit complex too, compared to simply use a text editor and change the XML file. People who need to add so many files/dirs that it's too much for the "files" section can do that with a tgz+scripts combination already. For smaller changes (which is enough for many customers from my experience) the clearly represented "files" section is better I think because you can see immediately what happens just by looking at the XML file. -- openSUSE Feature: https://features.opensuse.org/305313

1 0

[openFATE 305317] Default to hidden bootloader menu
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305317, revision 17 Title: Default to hidden bootloader menu openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Desirable Info Provider: Jan Engelhardt (jengelh) Requested by: Jiri Srain (jsrain) Description: As long as there is no other operating system present (SUSE is the only system), it makes sense to default to hidden bootloader menu (and booting directly). References: http://www.gnu.org/software/grub/manual/grub.html#Hidden-menu-interface https://bugzilla.novell.com/show_bug.cgi?id=425717 Discussion: #1: Stephan Kulow (coolo) (2009-04-16 10:34:48) I like that idea. I guess it's a tiny change for bootloader, but has possibly some docu impact. #2: Stanislav Visnovsky (visnov) (2009-05-28 16:45:13) How should it behave with option to keep kernels from updates (libzypp option)? What about failsafe? #3: Jiri Srain (jsrain) (2009-06-01 11:21:11) From the GRUB documentation: When your terminal is dumb or you request GRUB to hide the menu interface explicitly with the command `hiddenmenu' (*note hiddenmenu::), GRUB doesn't show the menu interface (*note Menu interface::) and automatically boots the default entry, unless interrupted by pressing ESC. When you interrupt the timeout and your terminal is dumb, GRUB falls back to the command-line interface (*note Command-line interface::). This sounds to me like this GRUB feature is intended for different purpose, and the use case described here does not make much sense (unlike lowering the time-out to e.g. 1 second). Torsten, what is your view? According to the documentation, GRUB allows to display the boot menu via pushing the Escape button. + #7: Christoph Thiel (cthiel1) (2009-07-16 11:27:26) (reply to #3) + Torsten, could you please provide your view on this? + Fedora and others seem to be doing this for years. #4: T. J. Brumfield (enderandrew) (2009-06-13 03:31:06) This option would only be utilized when no other OS is present, and you can still get back to the menu with Esc. This isn't that much different than needing F8 for the boot menu for Windows. It would speed up boot times. How is that a bad thing? #5: Jan Engelhardt (jengelh) (2009-06-18 23:53:45) Does not Fedora do something similar? #6: Christoph Thiel (cthiel1) (2009-06-28 10:00:44) (reply to #5) I haven't looked at how Fedora handles this. Jan, would you be able to dig into what Fedora does technically? This would be very much appreciated! -- openSUSE Feature: https://features.opensuse.org/305317

1 0

[openFATE 303535] Use libnetapi to join Active Directory
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Christoph Thiel (cthiel1) Feature #303535, revision 24 Title: Use libnetapi to join Active Directory openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-07 14:56:26 reject reason: Postponing. Priority Requester: Mandatory Projectmanager: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-07-16 11:15:21 + reject reason: no resoureces for 11.2 Priority Requester: Mandatory Projectmanager: Important Requested by: Ralf Haferkamp (rhafer) Description: Starting with 3.2.0 Samba will contain libnetapi, which is a C API providing features required to join an Active Directory Domain. The "Windows Domain Membership" YaST Module should switch to use this API instead of calling the "net" command. This should make the Module much easier to maintain Discussion: #9: Jiri Srain (jsrain) (2008-07-07 13:53:26) Stano, please, postpone. Minimal gain, it would requre to write a new C++ agent, and use code which has not been used before for this purpose. Let's stay with proven method and experiment with a new one for 11.2. #11: Matthias Eckermann (mge1512) (2008-07-14 20:37:06) Ralf and Samba-Team: is this reject acceptable for you - or will this have negative impact on AD integration? #12: Ralf Haferkamp (rhafer) (2008-07-28 11:51:48) (reply to #11) Jim, could you please answer Matthias' question I am not sure if libnetapi does provide anything that we need in SLED10, which is not provided by the "net" command. #13: James McDonough (jmcdough) (2008-07-29 07:22:45) (reply to #12) It is not advisable, but it is acceptable for now. Initially, it will simply mean that we are more exposed to the net command format changes, or any of the possible problems caused by running and interpreting output from external commands. Longer term, it should be done, as any new function will be implemented first through libnetapi, and not necessarily exposed through the net command. -- openSUSE Feature: https://features.opensuse.org/303535

1 0

[openFATE 120373] Unified Button Labels
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Christoph Thiel (cthiel1) Feature #120373, revision 53 Title: Unified Button Labels openSUSE-10.3: Rejected by Stephan Kulow (coolo) reject date: 2007-07-30 10:43:50 reject reason: not enough resources to do it right Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2009-03-30 09:27:47 reject reason: Did not happen completely in time. Priority Requester: Mandatory Projectmanager: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-07-16 11:08:56 + reject reason: out of resources for 11.2. Priority Requester: Desirable + openSUSE-11.3: New + Priority + Requester: Desirable Requested by: Klaus Kämpf (kwk) Description: Unify button labels YaST currently uses several different button labels for basically the same action, i.e. 'Ok', 'Accept', and 'Finish'. Decision: Only a single label per action should be used. Labels should be generally "OK" and "Cancel" for standard modules and "Back", "Next", "Cancel" and "Finish" for wizards. Documentation Impact: check YaST descriptions in manuals and update screen shots Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2006-06-27 11:36:42) I'm moving this from "future" to 10.3. 10.2 will share much with SP1, so we cannot make this kind of change there. Adding Coolo and Edith for usability and YaST, respectively. #2: Tanja Roth (ta-ro) (2007-06-11 16:37:21) This would also have documentation impact - we would have to check the YaST parts of the manuals and to redo a lot of screen shots, I guess. #3: Jiri Srain (jsrain) (2007-07-26 14:27:21) I don't think that we can solve this issue now, this must start being solved at the beginning of release cycle. Please, move to 11.0. #4: Stephan Kulow (coolo) (2007-11-20 11:48:19) the release cycle of 11.0 just started. Please kill Reject and Accept soonish. If I may add here: please do not overuse Ok and Cancel, but rather use explicit actions where appliying. "Do not delete 11 files? Ok/Cancel" is no-go, Delete/Cancel helps the user much more. #5: Jiri Srain (jsrain) (2008-03-10 13:36:56) (reply to #4) I don't think that such cases can be handled a different way than on the per-case basis as bugreports. #6: Jiri Srain (jsrain) (2008-03-10 13:39:16) This is the list of files which contain the Accept or Reject words (probably not complete and probably some of the files are superfluous due to non-perfect regext). Please, get rid of as many as possible of them. ./add-on/src/add-on_proposal.ycp ./add-on/src/inst_language_add-on.ycp ./apparmor/src/include/subdomain/reporting_archived_dialogs.ycp ./apparmor/src/include/subdomain/reporting_utils.ycp ./dhcp-server/src/dns-server-wizard.ycp ./fingerprint-reader/src/users_plugin_fingerprint_reader.ycp ./firewall/src/dialogs.ycp ./firewall/src/subdialogs.ycp ./ftp-server/src/complex.ycp ./ftp-server/src/dialogs.ycp ./inetd/src/dialogs.ycp ./installation/src/clients/inst_network_setup.ycp ./installation/src/clients/inst_proposal.ycp ./kdump/src/dialogs.ycp ./kerberos-client/src/dialogs.ycp ./ldap-client/src/LdapPopup.ycp ./ldap-client/src/ui.ycp ./live-installer/src/inst_live_simple_proposal.ycp ./ncurses-pkg/src/pkg_layout.ycp ./network/src/lan/complex.ycp ./nis-client/src/ui.ycp ./ntp-client/src/dialogs.ycp ./packager/doc/display_driver_popup.ycp ./packager/src/clients/inst_packages.ycp ./packager/src/clients/inst_productsources.ycp ./printer/src/common/dialogs.ycp ./registration/src/modules/Register.ycp ./restore/src/ui.ycp ./runlevel/src/runlevel_proposal.ycp ./samba-server/src/ldap-widget.ycp ./sound/sound/src/complex.ycp ./squid/src/complex.ycp ./storage/storage/src/inst_custom_part.ycp ./storage/storage/src/inst_prepdisk.ycp ./storage/storage/src/modules/StorageControllers.ycp ./system-update/src/system-update.ycp ./tune/hwinfo/src/newid.ycp ./tune/hwinfo/src/system_settings_dialogs.ycp ./update/src/clients/system_update.ycp ./update/src/clients/update.ycp ./update/src/include/rootpart.ycp ./users/src/dialogs.ycp ./users/src/users_plugin_ldap_all.ycp ./users/src/users_plugin_ldap_passwordpolicy.ycp ./users/src/users_plugin_ldap_shadowaccount.ycp ./users/src/users_plugin_quota.ycp ./yast2/library/modules/Label.ycp ./yast2/library/wizard/src/Wizard.ycp ./ycp-ui-bindings/examples/Wizard2.ycp #7: Martin Schmidkunz (mschmidkunz) (2008-03-10 17:18:59) Cool! When we are already touching the navigation buttons maybe we can also try to work out feature #303446 "Button order, positioning, labeling in YaST". Button order should be according to the selected desktop. If another desktop then KDE or GNOME is selected either KDE or GNOME button order should be used. The help button should be aligned left and the navigation buttons should be aligned right. Having too much space between the navigation buttons as we have no doesn't support grouping of buttons, which makes navigation difficult for the user. Labeling should be as stated in this feature. #8: Ladislav Slezak (lslezak) (2008-03-17 16:51:45) Fixed in yast2-sound-2.16.4, yast2-tune-2.16.0 and in yast2-packager- 2.16.27 #9: Arvin Schnell (aschnell) (2008-03-18 17:25:40) Is the decision documented in some style-guide? #10: Martin Schmidkunz (mschmidkunz) (2008-03-19 12:10:05) It is documented in http://en.opensuse.org/Image:Ysg.pdf However this is just a first draft which needs to be approved (FATE: 303041) #11: Jiří Suchomel (jsuchome) (2008-03-26 10:55:07) Done in yast2-ldap-client, yast2-fingerprint-reader, yast2-kerberos- client, yast2-nis-client, yast2-users #12: Jozef Uhliarik (juhliarik) (2008-03-27 10:18:07) Fixed in yast2-kdump-2.16.10, yast2-ftp-server-2.16.10 and in yast2- dhcp-server-2.16.7 #13: Arvin Schnell (aschnell) (2008-03-27 16:40:31) Done for storage. #14: J. Daniel Schmidt (jdsn) (2008-04-01 11:51:50) In case of registration the word "Reject" is used in context of a certificate. The user is asked to "Trust" or "Reject" the certificate. Changing it to "Trust" and "No" or to change the question and switch to "Yes"/"No" is not quite intuitive I think. So I'd keep the word "Reject" for registration. Btw: It will appear never in openSUSE but only during manual installation of a SLE product with registering agains a registration proxy aka. SMT. #15: Katarina Machalkova (kmachalkova) (2008-04-04 10:43:39) And what about installation proposals and installation clients? Are we suppose to substitute word "Accept" by something else there, too? If so, what is the suitable word in such case? Clearly not "Finish" (as it may let user think that it will finish the whole installation), is "OK" the right one then? #16: Martin Schmidkunz (mschmidkunz) (2008-04-04 11:21:54) What about using "Next"? #17: Jiri Srain (jsrain) (2008-04-04 10:51:20) (reply to #16) Next sounds to me like another step in a workflow should follow, which is not this case. I personally prefer simple "OK". #18: Lukas Ocilka (locilka) (2008-04-04 12:25:58) (reply to #17) I personally still prefer "Accept" as it was in the previous YaST Style Guide TM. But "OK" might work too. "Next" is definitely _not_ the right way to go. We have to distinguish between the main workflow and the step-workflows. #19: Martin Schmidkunz (mschmidkunz) (2008-04-04 12:33:28) (reply to #18) Why is it necessary to distinguish between main workflow and steps workflow? To the user it is just one installation process. Just out of curiosity: why is accepting the proposal not considered just another step in the installation workflow? basic settings => accepting proposal => perform installation #20: Lukas Ocilka (locilka) (2008-04-04 12:52:04) (reply to #19) For accepting the installation proposal, I'd even rather use [Install] than anything else. [Accept] has been used there because it's so important decision that in needs emphasizing. #21: Jiri Srain (jsrain) (2008-04-04 11:55:21) (reply to #19) Katarina's question was about the button e.g. in the partitioning dialog, not about the installation proposal as whole (if I understood it correctly). #22: Martin Schmidkunz (mschmidkunz) (2008-04-04 14:19:14) (reply to #21) Sorry for the misunderstanding and thanks for the correction! I suggest to use Cancel/OK as the only two buttons. Reason: the dialogs are side-steps from main installation workflow. I think now I got Lukas' comment about main worklfow and steps- workflow. :-) #23: Katarina Machalkova (kmachalkova) (2008-04-04 17:23:36) (reply to #21) Right, the partitioning dialog (or networking, gfx card, whatever) that is launched from installation proposal. For example, in yast2-network, we use (in the very same dialog) "Finish" on running system, but "Accept" in installation. My q. was whether to substitute the installation client's "Accept" button with something more suitable. #24: Lukas Ocilka (locilka) (2008-04-11 18:23:12) Changing Accept buttons to Install or Update (FATE #120373) >> yast2- installation-2.16.34 #25: Lukas Ocilka (locilka) (2008-04-11 18:45:41) Done in yast2-update-2.16.6 This is definitely going to break something as I can't check every change made... #26: Jiri Srain (jsrain) (2008-04-14 11:40:57) Most of the Accept/Reject buttons are gone now. Let's solve the remaining ones as bugs. #31: Michael Löffler (michl19) (2009-06-09 15:39:44) (reply to #26) Jiri, how much work needs to be done to clean it up by 100%? #27: Martin Schmidkunz (mschmidkunz) (2009-03-18 16:23:14) It is true that the Accept and Reject button labels are removed from the YaST modules. However the button labels are far from being unified. The biggest mess ist the crude mixture of "Cancel" and "Abort" labels and the second issue is the presentation of "Back" buttons which have the same functionality as "Cancel" but are shown in one screen configuration dialogs. The attempt to solve these issues via bugzilla (https://bugzilla.novell.com/show_bug.cgi?id=478089) revealed that this issue seems to aquire some ressources. One main reason for button labeling trouble seems to be that wizard.ycp is used in many places where the dialog is not a wizard, but where it is an overview. To get a professional, consistent GUI and in order to reduce translation efforts and development of new YaST modules one possible solution might be the development of two different templates: * * wizard.ycp for wizards and installation and * * overview.ycp for edit/singe configuration/overview dialogs Some possible layouts can be viewed at: * http://en.opensuse.org/Image:Wizard_dialog.png * http://en.opensuse.org/Image:Overview_dialog.png Buttons could use something like the button box widget developed sh or the button label widget developed by mzugec. As mentioned in the bug, it will take some effort and ressources but I think, that the outcomes will be worth it! #30: Martin Schmidkunz (mschmidkunz) (2009-04-01 15:39:33) The status of button labels in YaST (based on openSUSE 11.1/SLE 11) can be found at: http://en.opensuse.org/Media:Unified_buttons_yast.pdf Some basic numbers: * * 10 different button combinations for overview dialogs * * 5 different button combinations for wizard dialogs * * 3 different button combinations for progress dialogs Suggestions for a unification: * Use Cancel/OK for overview dialogs * Use Cancel/OK and Back/Cancel/Next (Back/Cancel/Finish) for wizards * Cancel for progress dialogs Necessary work for unified buttons in overview dialogs * Cancel/OK is already used in 28 of 78 overview dialogs * 50 overview dialogs which need adjustments (4 x relabeling 2 buttons, 9 x relabeling 1 button, 12 x hide 1 button, 25 x hide 1 Button and relabeling 2 buttons) Necessary work for unified buttons in wizard dialogs * Cancel/OK and Back/Cancel/Next are already used in 23 of 44 overview dialogs * 21 wizard dialogs which need adjustments (20 x relabeling 1 button, 1 x add “Cancel” button) Necessary work for unified buttons in progress dialogs * Cancel is already used in 3 of 46 progress dialogs * All progress dialogs can be easily adjusted by hiding “Back” and “Next” buttons and relabel “Abort” into “Cancel” in progress.ycp Final conclusions/questions * Unified button labels in wizards and progress dialogs can be achieved by just adjusting wizard.ycp and progress.ycp libraries * Overview dialogs need some manual adjustments as they base on wizards. ycp as well * Can adjustments be done by copying code from existing dialogs with OK/Cancel buttons (e.g. Date and Time)? * Does it make sense to invest into an overview.ycp dialog? -- openSUSE Feature: https://features.opensuse.org/120373

1 0

[openFATE 306898] Automated Video-Encoding
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature added by: Juergen Weigert (jnweiger) Feature #306898, revision 1 Title: Automated Video-Encoding Hackweek IV: Unconfirmed Priority Requester: Important Requested by: Juergen Weigert (jnweiger) Description: kdeNlive features a batch mode, Its project files are plain XML. We need an application service, that would * take a raw cut DV video file from dvgrab * take number of seconds to trim from begin and end of the DV file * optionally take an additional audio track * configure audio channels mono to stereo, mixdown of additional track * take the text for a title screen * take number of seconds the title screen should be shown (prepended or overlayed) * take a logo graphics (or offer a default openSUSE logo) to be overlayed at the top righthand corner * write out a kdenlive project file, * run kdenlive in batch mode, showing a progress indicator. This could be a simple shell script or a cool web application available on tube.opensuse.org Test Case: The DV video files from LinuxTag still need encoding, so there is plenty material for testing. Use Case: saves us time in post production of our recordings from internal talks and external conferences. Makes the works reproducable, shortens turnaround time. More video coverage gives openSUSE better visibility and transparency. -- openSUSE Feature: https://features.opensuse.org/306898

1 0

[openFATE 305403] Bootloader beep configuration
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Jozef Uhliarik (juhliarik) Feature #305403, revision 16 Title: Bootloader beep configuration + Hackweek IV: Candidate + Priority + Requester: Desirable + Projectmanager: Desirable openSUSE-11.2: Candidate Priority Requester: Desirable Projectmanager: Desirable Requested by: Jiri Srain (jsrain) Description: Allow to configure whether the acoustic signal should be used for installed bootloader. Acoustic signal is valuable for visually impaired people, while it may be disturbing e.g. in libraries. Discussion: #1: Jiri Srain (jsrain) (2008-11-12 15:58:43) Default can be set depending on whether braille display was found or whether text-to-speech in isolinux was used. #2: Stefan Behlert (sbehlert) (2008-11-12 17:15:07) Is this feature meant as 'allow atuomatic setting of'? The beep is afaik already configurable to be 'off'. If not, this would be a bug. #3: Stefan Seyfried (seife) (2008-11-12 18:09:40) Please reject this feature. This is seriously overengineered. The beep now defaults to off int the installed system. If somebody wants to enable it, he can do so with gfxboot --change-config "boot::beep=1" Marco only needs to document that for his customers and everything is fine. Please, no YaST module for that. #4: Jiri Srain (jsrain) (2008-11-13 09:39:44) (reply to #3) It's not about a new module, just about a check box in the bootloader configuration. #5: Jiri Srain (jsrain) (2009-06-01 11:38:11) (reply to #4) Jozo, please, find a reasonable location for the check box. #6: Jozef Uhliarik (juhliarik) (2009-06-25 10:37:14) Steffen how can I obtain info about status of "beep" from gfxboot? I know how to switch on/off option but I need also status. Please let me know. #7: Steffen Winterfeldt (snwint) (2009-06-25 11:40:48) (reply to #6) You can't. If you have an INF file parser, you can run 'gfxboot --show- config' and get the value from there. -- openSUSE Feature: https://features.opensuse.org/305403

1 0

[openFATE 304500] Make storage failures non-fatal
by fate_noreply＠suse.de 15 Jul '09

15 Jul '09

Feature changed by: Greg Riedesel (Gracal) Feature #304500, revision 26 Title: Make storage failures non-fatal openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-29 13:04:58 reject reason: Postponing. Out of resources. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-03 08:34:12 reject reason: No resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Arvin Schnell (aschnell) Description: Currently all storage failures (during step "Prepare Harddisk") are fatal. E.g. if a partition cannot be mounted the installation is aborted. Some failures do not really harm, e.g. if mounting of a Windows partition fails that is not used for the installation. For other failures an really experienced user might fix the problem manually on the console. So for all failures the user should be asked whether the installation should continue. References: https://bugzilla.novell.com/show_bug.cgi?id=382765#c1 https://bugzilla.novell.com/show_bug.cgi?id=397156 https://bugzilla.novell.com/show_bug.cgi?id=402812 https://bugzilla.novell.com/show_bug.cgi?id=438660 https://bugzilla.novell.com/show_bug.cgi?id=520902 Relations: - Installation aborts after error message that NTFS partition can't be mounted (novell/bugzilla/id: 309074) https://bugzilla.novell.com/show_bug.cgi?id=309074 Discussion: #2: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:33:20) Please reject for SLE11/11.1. All resources allocated with mandatory features already. + #6: Greg Riedesel (gracal) (2009-07-15 21:49:09) + When installng openSUSE on a latop with a hybernated Windows parition, + the current behavior will hard-stop the install. In some instances, if + there was a prior openSUSE install, the boot files may have already + been scrubbed when the mount-failure occurs that hard-stops the + install. In this case, the laptop will become unbootable. The only way + around it is to complete the openSUSE install, and explicitly remove + the Windows parititions from fstab as part of the disk-parititioning + dialog. That way the Windows partitions are not mounted during + installation and won't throw an error. -- openSUSE Feature: https://features.opensuse.org/304500

1 0

[openFATE 304879] OOo: Update of KDE integration to KDE4
by fate_noreply＠suse.de 15 Jul '09

15 Jul '09

Feature changed by: Jan Holesovsky (kendysan) Feature #304879, revision 89 Title: OOo: Update of KDE integration to KDE4 openSUSE-11.1: Rejected by JP Rosevear (jproseve) reject date: 2008-08-15 11:47:35 reject reason: As per PM recommendation. Priority Requester: Mandatory Projectmanager: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Candidate Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Stephan Binner (beineri) Description: The current OOo KDE integration (file dialogs, addressbook, interface/icon theme,...) is based on KDE3. As openSUSE 11.1/SLED 11 will likely not include KDE3 anymore it has to be upgraded to KDE4. Use Case: I will find this is really usefull. Discussion: #1: Stephan Kulow (coolo) (2008-06-13 09:54:23) There are far too many mandatory OOo features. Please reevaluate - it's unlikely that we won't ship KDE3 apps in SLED11 #2: Dirk Mueller (dirkmueller) (2008-06-13 13:25:48) (reply to #1) we will ship KDE3 libs, yes. that doesn't mean that we desire to have KDE3 app dependencies ;) #7: Rajesh Ganesan (ganesanrajesh) (2009-01-07 03:20:08) Well, an excellent idea and most expected too. But (http://kde.openoffice.org/) seems struck at March 2006 itself. Any plans(or chance) of revival? #8: Armin Moradi (amoradi) (2009-01-19 19:30:45) Excellent idea, again, this brings up the consistency issue with the rest of KDE4. #9: Ruurd Pels (rfpels) (2009-03-06 22:40:10) Seems to me now that we have 4.2 in FACTORY for 11.1 we can create and release an integration package there so we will be ready by the time SLES11 goes gold. #14: Michael Löffler (michl19) (2009-07-14 12:13:49) (reply to #9) Jan, can you comment on #9. As this feature is one of the highest rated ones we should start implementation better sooner than later. #15: Jan Holesovsky (kendysan) (2009-07-14 15:15:21) (reply to #14) We now have a proof of concept KDE4 integration in ooo-build, it will be a part of OOo 3.1.1. So far the theming and the file dialog were ported; also the Oxygen icons for OOo were provided - everything as a community effort. For more information please see the comments 11, 12, 13. #16: Michael Löffler (michl19) (2009-07-15 13:55:55) (reply to #15) Jan, so it looks like we can change the status of this feature into implementation, right? #17: Jan Holesovsky (kendysan) (2009-07-15 14:10:00) (reply to #16) I suppose so, so I changed the state to implementation. Let's evaluate the quality of this later in the beta phase, and reject for SP1 if the quality is poor - as I say, it is still purely community effort. #10: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:26:13) this would be nice for 11.2 #11: Karsten König (remur) (2009-06-15 15:23:55) Good news everybody! http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2009-06.html#2… (Just for tracking, most openfate users propably have seen this by now on planetsuse) #12: jimbo bigcreed (dimble_thricefoon) (2009-06-16 18:41:27) (reply to #11) dot.kde http://www.kdedevelopers.org/node/3983 KDE4 integration done by the kubuntu boys #13: Stephan Binner (beineri) (2009-07-01 20:17:03) (reply to #12) An early OpenOffice_org-kde4 package exists in Factory so this should be change to Candidate. -- openSUSE Feature: https://features.opensuse.org/304879

1 0

[openFATE 304879] OOo: Update of KDE integration to KDE4
by fate_noreply＠suse.de 15 Jul '09

15 Jul '09

Feature changed by: Jan Holesovsky (kendysan) Feature #304879, revision 88 Title: OOo: Update of KDE integration to KDE4 openSUSE-11.1: Rejected by JP Rosevear (jproseve) reject date: 2008-08-15 11:47:35 reject reason: As per PM recommendation. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Stephan Binner (beineri) Description: The current OOo KDE integration (file dialogs, addressbook, interface/icon theme,...) is based on KDE3. As openSUSE 11.1/SLED 11 will likely not include KDE3 anymore it has to be upgraded to KDE4. Use Case: I will find this is really usefull. Discussion: #1: Stephan Kulow (coolo) (2008-06-13 09:54:23) There are far too many mandatory OOo features. Please reevaluate - it's unlikely that we won't ship KDE3 apps in SLED11 #2: Dirk Mueller (dirkmueller) (2008-06-13 13:25:48) (reply to #1) we will ship KDE3 libs, yes. that doesn't mean that we desire to have KDE3 app dependencies ;) #7: Rajesh Ganesan (ganesanrajesh) (2009-01-07 03:20:08) Well, an excellent idea and most expected too. But (http://kde.openoffice.org/) seems struck at March 2006 itself. Any plans(or chance) of revival? #8: Armin Moradi (amoradi) (2009-01-19 19:30:45) Excellent idea, again, this brings up the consistency issue with the rest of KDE4. #9: Ruurd Pels (rfpels) (2009-03-06 22:40:10) Seems to me now that we have 4.2 in FACTORY for 11.1 we can create and release an integration package there so we will be ready by the time SLES11 goes gold. #14: Michael Löffler (michl19) (2009-07-14 12:13:49) (reply to #9) Jan, can you comment on #9. As this feature is one of the highest rated ones we should start implementation better sooner than later. #15: Jan Holesovsky (kendysan) (2009-07-14 15:15:21) (reply to #14) We now have a proof of concept KDE4 integration in ooo-build, it will be a part of OOo 3.1.1. So far the theming and the file dialog were ported; also the Oxygen icons for OOo were provided - everything as a community effort. For more information please see the comments 11, 12, 13. #16: Michael Löffler (michl19) (2009-07-15 13:55:55) (reply to #15) Jan, so it looks like we can change the status of this feature into implementation, right? + #17: Jan Holesovsky (kendysan) (2009-07-15 14:10:00) (reply to #16) + I suppose so, so I changed the state to implementation. Let's evaluate + the quality of this later in the beta phase, and reject for SP1 if the + quality is poor - as I say, it is still purely community effort. #10: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:26:13) this would be nice for 11.2 #11: Karsten König (remur) (2009-06-15 15:23:55) Good news everybody! http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2009-06.html#2… (Just for tracking, most openfate users propably have seen this by now on planetsuse) #12: jimbo bigcreed (dimble_thricefoon) (2009-06-16 18:41:27) (reply to #11) dot.kde http://www.kdedevelopers.org/node/3983 KDE4 integration done by the kubuntu boys #13: Stephan Binner (beineri) (2009-07-01 20:17:03) (reply to #12) An early OpenOffice_org-kde4 package exists in Factory so this should be change to Candidate. -- openSUSE Feature: https://features.opensuse.org/304879

1 0

[openFATE 304879] OOo: Update of KDE integration to KDE4
by fate_noreply＠suse.de 15 Jul '09

15 Jul '09

Feature changed by: Michael Löffler (michl19) Feature #304879, revision 87 Title: OOo: Update of KDE integration to KDE4 openSUSE-11.1: Rejected by JP Rosevear (jproseve) reject date: 2008-08-15 11:47:35 reject reason: As per PM recommendation. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Stephan Binner (beineri) Description: The current OOo KDE integration (file dialogs, addressbook, interface/icon theme,...) is based on KDE3. As openSUSE 11.1/SLED 11 will likely not include KDE3 anymore it has to be upgraded to KDE4. Use Case: I will find this is really usefull. Discussion: #1: Stephan Kulow (coolo) (2008-06-13 09:54:23) There are far too many mandatory OOo features. Please reevaluate - it's unlikely that we won't ship KDE3 apps in SLED11 #2: Dirk Mueller (dirkmueller) (2008-06-13 13:25:48) (reply to #1) we will ship KDE3 libs, yes. that doesn't mean that we desire to have KDE3 app dependencies ;) #7: Rajesh Ganesan (ganesanrajesh) (2009-01-07 03:20:08) Well, an excellent idea and most expected too. But (http://kde.openoffice.org/) seems struck at March 2006 itself. Any plans(or chance) of revival? #8: Armin Moradi (amoradi) (2009-01-19 19:30:45) Excellent idea, again, this brings up the consistency issue with the rest of KDE4. #9: Ruurd Pels (rfpels) (2009-03-06 22:40:10) Seems to me now that we have 4.2 in FACTORY for 11.1 we can create and release an integration package there so we will be ready by the time SLES11 goes gold. #14: Michael Löffler (michl19) (2009-07-14 12:13:49) (reply to #9) Jan, can you comment on #9. As this feature is one of the highest rated ones we should start implementation better sooner than later. #15: Jan Holesovsky (kendysan) (2009-07-14 15:15:21) (reply to #14) We now have a proof of concept KDE4 integration in ooo-build, it will be a part of OOo 3.1.1. So far the theming and the file dialog were ported; also the Oxygen icons for OOo were provided - everything as a community effort. For more information please see the comments 11, 12, 13. + #16: Michael Löffler (michl19) (2009-07-15 13:55:55) (reply to #15) + Jan, so it looks like we can change the status of this feature into + implementation, right? #10: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:26:13) this would be nice for 11.2 #11: Karsten König (remur) (2009-06-15 15:23:55) Good news everybody! http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2009-06.html#2… (Just for tracking, most openfate users propably have seen this by now on planetsuse) #12: jimbo bigcreed (dimble_thricefoon) (2009-06-16 18:41:27) (reply to #11) dot.kde http://www.kdedevelopers.org/node/3983 KDE4 integration done by the kubuntu boys #13: Stephan Binner (beineri) (2009-07-01 20:17:03) (reply to #12) An early OpenOffice_org-kde4 package exists in Factory so this should be change to Candidate. -- openSUSE Feature: https://features.opensuse.org/304879

1 0

[openFATE 305503] zypper: allow update by issues/bugs/advisories
by fate_noreply＠suse.de 15 Jul '09

15 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #305503, revision 27 Title: zypper: allow update by issues/bugs/advisories openSUSE-11.2: Candidate Priority Requester: Desirable Projectmanager: Mandatory Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Description: YUM security plugin allows to filter updates showing only ones that mention certain issues. Example: yum update --security yum update --bz 410101 yum update --cve CVE-2007-5707 --advisory RHSA-2007:1082-5 As our patches contains this metadata, we could add similar functionality to zypper. Scope The scope is only for zypper. Other front ends would require some GUI concept first. Open Issues: libzypp's PoolQuery would need support for subattributes (updateinfo. xml references are stored as subarrays) User experience * Adds command line options like the ones described above. Dependencies * libzypp Contingency Plan * Feature is new, so in a bad scenario it can simple be deactivated. Relations: - updateinfo XML scheme (url: http://git.opensuse.org/?p=projects/zypp/libzypp.git;a=blob_plain;f=zypp/pa…) - Tips and tricks: yum-security (url: http://www.redhatmagazine.com/2008/01/16/tips-and-tricks-yum-security/) Documentation Impact: New command line options would need to be documented. Test Case: The testing of this feature can be done creating a repository (for example using enhancerepo) containing patches that reference issues, like described in http://en.opensuse.org/Maintenance/Code11/Howto , and then performing updates passing to zypper command line the issues, confirming that only those issues are shown. Use Case: Sysadmin is only interested in particular updates to solve security issues or specific bug numbers or advisories. Business case (Partner benefit): openSUSE.org: Sysadmins do not update ther systems without a strict process and maximum care. Therefore it is very important to allow them to update the system to fix a single issue. It would save them the time to look that themselves package per package. Discussion: #1: Marcus Meissner (msmeissn) (2008-12-03 14:51:14) Random notes: - CVE-XXXX-YYYY RPM provides after fixing issues? - OVAL relation? #2: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:02:46) (reply to #1) About CVE provides. Right now the CVE information is in the patch (since 11.0). I don't have anything against having it as Fix(CVE-XXX-XXX) provides, but I am not sure if having them in both makes sense. Specially in the case that one issue needs more than one package, you will need to install all packages fixing the issue, and if you have 2 repos with 2 same packages providing the issue, they will conflict. #3: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:08:13) (reply to #1) I don't have knowledge how OVAL works, may be you can provide some very concrete example scenarios for the feature described above. What I can say is that the reason why the repository/product compatibility and update information in SLE11/openSUSE 11.1 is supported using CPE ( that is, product can contain a CPE id, and repos can tell to which CPE they are compatible and which CPE they update with fixes ) was to enhance our ability to do semantic queries like relate upstream security issues and installed products. OVAL uses CPE as the platform descriptor AFAIK. #4: Dirk Mueller (dirkmueller) (2008-12-04 14:58:01) adding rpm provides was also my first idea, but that has a side effect: often enough, CVE numbers are not yet known when the package is built and ends up in QA, and editing rpm provides essentially needs a rebuild, which invalidates QA. so preferably we need a way to update the rpm provides without doing a rebuild (bad) or we need a way to add it to the meta information (which is currently generated via patchinfo and where it is also too late). an idealistic approach would be to make sure that we can update this meta information after patchinfo checkin (entering the data into swamp and autobuild fetches that information when the update is released and adds it to the meta info). #5: Federico Lucifredi (flucifredi) (2009-01-07 15:52:34) This has quite a bit of customer value. BTW, there may be a duplicate out there #6: Michael Andres (mlandres) (2009-07-01 18:33:01) libzypp-6.9.2 supports PoolQuery of subattributes. So one can e.g search for patches with updateReferenceId "CVE-2007-5707', or of updateReferenceType 'bugzilla",... (I'll provide some sample code) @Jano: I'll provide some code example, that tells how to access and iterate the matching updateReferences. So you could start working on zypper. #7: Ján Kupec (jkupec) (2009-07-03 15:10:56) Thanx! I have a question about the reference types. What types do we support? in updateinfo.rnc (see references) i only see bugzilla and cve Do we want separate options for all supported types, like yum has? #9: Ján Kupec (jkupec) (2009-07-03 15:57:19) (reply to #7) Also, i noticed in 11.1 updates repository, that many bugs have a CVE, but it's only in the description, not in the 'reference' metadata. Only bugzilla is in 'reference'. Do we want to address this? #10: Marcus Meissner (msmeissn) (2009-07-03 15:59:21) (reply to #9) we are not emitting it yet. this also needs to be done :/ #8: Ján Kupec (jkupec) (2009-07-03 15:20:18) Suggestion how the commands could look like: $ zypper fix --search [string] $ zypper fix --bugzilla <#> $ zypper fix --cve <#> #11: Klaus Kämpf (kwk) (2009-07-04 12:11:44) (reply to #8) Please re-think about introducing another term ( fix ), we already have * update * upgrade * patch #12: Ján Kupec (jkupec) (2009-07-07 10:11:04) (reply to #11) What i try to achieve is to have a way to install the patches fixing the issues and a way to list them (issue number & patch name & (patch) description), search in them. The other alternatives i considered were: $ zypper patch [--bugzilla #] [--cve #] $ zypper list-patches --issues [string] The first command looks nice, but i don't know what to use to list/search the issues - the list-patches command does not seem right to me - looks more like it deserved a new command. $ zypper install [--bugzilla #] [--cve #] $ zypper search --issues [string] In this case, like in the 'list-patches --issues' case, the search command would either need to radically change its output, or user would need to call 'zypper patch-info the_found_patch' to get the patch description. Any other ideas? Why is having a new command a bad thing (esp. compared to having new options in the existing commands)? BTW: (We don't have 'upgrade' :O) #13: Martin Vidner (mvidner) (2009-07-07 14:33:03) (reply to #12) Why reinvent the wheel? Can we just copy yum's interface as described in the referenced yum-security article? * http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/ (http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/) * http://linux.die.net/man/8/yum-security (http://linux.die.net/man/8/yum-security) #14: Ján Kupec (jkupec) (2009-07-07 14:57:27) (reply to #13) 'zypper update' does not work with patches. 'zypper patch' looks to me like better candidate for new --bz or --cve options. yum does not make difference between these two. The yum plugin also adds a new command (list-sec), which was Klaus' objection. #15: Klaus Kämpf (kwk) (2009-07-07 15:51:26) (reply to #14) Well, my objection is the new term 'fix' besides 'update' and 'patch' and will confuse people. It should be an option to "list" or "list-patches" imho #16: Ján Kupec (jkupec) (2009-07-07 16:16:12) (reply to #15) OK, so far the following looks like a candidate (taken yum into account as well): # to install a fix $ zypper patch [--bz #] [--cve #] [--any-other #] # to list available needed fixes (issue-number, patchname-version, category, description) # all $ zypper list-patches --issues # matching a substring ("CVE", number, or any) $ zypper list-patches --issues foo # only CVEs/bugzillas $ zypper list-patches [--cve] [--bz] #17: Ján Kupec (jkupec) (2009-07-15 09:24:34) Done in zypper. You can fetch zypper 1.2.2 from home:jkupec:Factory to try and let me know what you think. New options in lp and patch commands: $ zypper help lp -b, --bugzilla[=#] List needed patches for Bugzilla issues. --cve[=#] List needed patches for CVE issues. --issues[=string] Look for issues matching the specified string. -a, --all List all patches, not only the needed ones. $ zypper help patch patch [options] -b, --bugzilla # Install patch fixing the specified bugzilla issue. --cve # Install patch fixing the specified CVE issue. --bz works, too. Can this feature be closed, or we'll close it after the repo metadata have the CVE references? + #18: Ján Kupec (jkupec) (2009-07-15 09:30:38) + One more thing that crossed my mind when looking at the yum article + http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/ + They seem to be able to associate issue numbers with spcecific + packages. I'm not sure if this is because they just avoid issuing + updates with plenty of packages in single <update> tags, like we often + do? -- openSUSE Feature: https://features.opensuse.org/305503

1 0

[openFATE 305503] zypper: allow update by issues/bugs/advisories
by fate_noreply＠suse.de 15 Jul '09

15 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #305503, revision 26 Title: zypper: allow update by issues/bugs/advisories openSUSE-11.2: Candidate Priority Requester: Desirable Projectmanager: Mandatory Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Description: YUM security plugin allows to filter updates showing only ones that mention certain issues. Example: yum update --security yum update --bz 410101 yum update --cve CVE-2007-5707 --advisory RHSA-2007:1082-5 As our patches contains this metadata, we could add similar functionality to zypper. Scope The scope is only for zypper. Other front ends would require some GUI concept first. Open Issues: libzypp's PoolQuery would need support for subattributes (updateinfo. xml references are stored as subarrays) User experience * Adds command line options like the ones described above. Dependencies * libzypp Contingency Plan * Feature is new, so in a bad scenario it can simple be deactivated. Relations: - updateinfo XML scheme (url: http://git.opensuse.org/?p=projects/zypp/libzypp.git;a=blob_plain;f=zypp/pa…) - Tips and tricks: yum-security (url: http://www.redhatmagazine.com/2008/01/16/tips-and-tricks-yum-security/) Documentation Impact: New command line options would need to be documented. Test Case: The testing of this feature can be done creating a repository (for example using enhancerepo) containing patches that reference issues, like described in http://en.opensuse.org/Maintenance/Code11/Howto , and then performing updates passing to zypper command line the issues, confirming that only those issues are shown. Use Case: Sysadmin is only interested in particular updates to solve security issues or specific bug numbers or advisories. Business case (Partner benefit): openSUSE.org: Sysadmins do not update ther systems without a strict process and maximum care. Therefore it is very important to allow them to update the system to fix a single issue. It would save them the time to look that themselves package per package. Discussion: #1: Marcus Meissner (msmeissn) (2008-12-03 14:51:14) Random notes: - CVE-XXXX-YYYY RPM provides after fixing issues? - OVAL relation? #2: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:02:46) (reply to #1) About CVE provides. Right now the CVE information is in the patch (since 11.0). I don't have anything against having it as Fix(CVE-XXX-XXX) provides, but I am not sure if having them in both makes sense. Specially in the case that one issue needs more than one package, you will need to install all packages fixing the issue, and if you have 2 repos with 2 same packages providing the issue, they will conflict. #3: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:08:13) (reply to #1) I don't have knowledge how OVAL works, may be you can provide some very concrete example scenarios for the feature described above. What I can say is that the reason why the repository/product compatibility and update information in SLE11/openSUSE 11.1 is supported using CPE ( that is, product can contain a CPE id, and repos can tell to which CPE they are compatible and which CPE they update with fixes ) was to enhance our ability to do semantic queries like relate upstream security issues and installed products. OVAL uses CPE as the platform descriptor AFAIK. #4: Dirk Mueller (dirkmueller) (2008-12-04 14:58:01) adding rpm provides was also my first idea, but that has a side effect: often enough, CVE numbers are not yet known when the package is built and ends up in QA, and editing rpm provides essentially needs a rebuild, which invalidates QA. so preferably we need a way to update the rpm provides without doing a rebuild (bad) or we need a way to add it to the meta information (which is currently generated via patchinfo and where it is also too late). an idealistic approach would be to make sure that we can update this meta information after patchinfo checkin (entering the data into swamp and autobuild fetches that information when the update is released and adds it to the meta info). #5: Federico Lucifredi (flucifredi) (2009-01-07 15:52:34) This has quite a bit of customer value. BTW, there may be a duplicate out there #6: Michael Andres (mlandres) (2009-07-01 18:33:01) libzypp-6.9.2 supports PoolQuery of subattributes. So one can e.g search for patches with updateReferenceId "CVE-2007-5707', or of updateReferenceType 'bugzilla",... (I'll provide some sample code) @Jano: I'll provide some code example, that tells how to access and iterate the matching updateReferences. So you could start working on zypper. #7: Ján Kupec (jkupec) (2009-07-03 15:10:56) Thanx! I have a question about the reference types. What types do we support? in updateinfo.rnc (see references) i only see bugzilla and cve Do we want separate options for all supported types, like yum has? #9: Ján Kupec (jkupec) (2009-07-03 15:57:19) (reply to #7) Also, i noticed in 11.1 updates repository, that many bugs have a CVE, but it's only in the description, not in the 'reference' metadata. Only bugzilla is in 'reference'. Do we want to address this? #10: Marcus Meissner (msmeissn) (2009-07-03 15:59:21) (reply to #9) we are not emitting it yet. this also needs to be done :/ #8: Ján Kupec (jkupec) (2009-07-03 15:20:18) Suggestion how the commands could look like: $ zypper fix --search [string] $ zypper fix --bugzilla <#> $ zypper fix --cve <#> #11: Klaus Kämpf (kwk) (2009-07-04 12:11:44) (reply to #8) Please re-think about introducing another term ( fix ), we already have * update * upgrade * patch #12: Ján Kupec (jkupec) (2009-07-07 10:11:04) (reply to #11) What i try to achieve is to have a way to install the patches fixing the issues and a way to list them (issue number & patch name & (patch) description), search in them. The other alternatives i considered were: $ zypper patch [--bugzilla #] [--cve #] $ zypper list-patches --issues [string] The first command looks nice, but i don't know what to use to list/search the issues - the list-patches command does not seem right to me - looks more like it deserved a new command. $ zypper install [--bugzilla #] [--cve #] $ zypper search --issues [string] In this case, like in the 'list-patches --issues' case, the search command would either need to radically change its output, or user would need to call 'zypper patch-info the_found_patch' to get the patch description. Any other ideas? Why is having a new command a bad thing (esp. compared to having new options in the existing commands)? BTW: (We don't have 'upgrade' :O) #13: Martin Vidner (mvidner) (2009-07-07 14:33:03) (reply to #12) Why reinvent the wheel? Can we just copy yum's interface as described in the referenced yum-security article? * http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/ (http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/) * http://linux.die.net/man/8/yum-security (http://linux.die.net/man/8/yum-security) #14: Ján Kupec (jkupec) (2009-07-07 14:57:27) (reply to #13) 'zypper update' does not work with patches. 'zypper patch' looks to me like better candidate for new --bz or --cve options. yum does not make difference between these two. The yum plugin also adds a new command (list-sec), which was Klaus' objection. #15: Klaus Kämpf (kwk) (2009-07-07 15:51:26) (reply to #14) Well, my objection is the new term 'fix' besides 'update' and 'patch' and will confuse people. It should be an option to "list" or "list-patches" imho #16: Ján Kupec (jkupec) (2009-07-07 16:16:12) (reply to #15) OK, so far the following looks like a candidate (taken yum into account as well): # to install a fix $ zypper patch [--bz #] [--cve #] [--any-other #] # to list available needed fixes (issue-number, patchname-version, category, description) # all $ zypper list-patches --issues # matching a substring ("CVE", number, or any) $ zypper list-patches --issues foo # only CVEs/bugzillas $ zypper list-patches [--cve] [--bz] + #17: Ján Kupec (jkupec) (2009-07-15 09:24:34) + Done in zypper. You can fetch zypper 1.2.2 from home:jkupec:Factory to + try and let me know what you think. New options in lp and patch + commands: + $ zypper help lp + -b, --bugzilla[=#] List needed patches for Bugzilla issues. + --cve[=#] List needed patches for CVE issues. + --issues[=string] Look for issues matching the specified + string. + -a, --all List all patches, not only the needed ones. + $ zypper help patch + patch [options] + -b, --bugzilla # Install patch fixing the specified bugzilla + issue. + --cve # Install patch fixing the specified CVE issue. + --bz works, too. + Can this feature be closed, or we'll close it after the repo metadata + have the CVE references? -- openSUSE Feature: https://features.opensuse.org/305503

1 0

[openFATE 303532] Reduce size of updates for openSUSE Factory
by fate_noreply＠suse.de 14 Jul '09

14 Jul '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #303532, revision 27 Title: Reduce size of updates for openSUSE Factory Buildservice: Evaluation Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-06-06 09:06:29 reject reason: not really attached to a specific openSUSE version Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Adrian Schröter (adriansuse) reject date: 2008-11-06 16:10:03 reject reason: This is a build service feature, but no distribution feature. Priority Requester: Important Projectmanager: Important Requested by: Michael Löffler (michl19) Description: Each update currently is around 2GB which is already much for broadband bandwith. For user with less bandwith it's by and large impossible to use Factory. Goal is to reduce size of updates and stay with frequent updates to offer latest software to the user. As we want more people using Factory it's usage needs to be conveniant. Discussion: #1: Stephan Kulow (coolo) (2008-03-27 16:48:43) According to discussions with Rudi and mls, the delta setup on dist need to be changed to also contain the rpm header and the deltas need to be indexed in a way that zypp will see them. So we can still use drpmsync for internal distribution and put the deltas only in instsource for mirrors. #2: Duncan Mac-Vicar (dmacvicar) (2008-04-22 13:28:56) This will happen automatically once the remaining parts of libzypp deltarpm handling are finished. We only need to agree on the format. I will propose something today. #3: Duncan Mac-Vicar (dmacvicar) (2008-05-26 17:09:31) ZYpp side is done. The only thing that needs to be done is to generate the deltarpm metadata in factory. I will post link to documentation and examples shortly. + #7: Andreas Jaeger (a_jaeger) (2009-07-14 21:36:57) (reply to #3) + What is the status of the Build Service side for this? #4: Gerald Pfeifer (geraldpfeifer) (2009-01-03 14:54:00) Opening this up for openSUSE.org. #5: Stephan Kulow (coolo) (2009-01-16 08:24:42) ok, we discussed this a bit further. We plan to throw away builds that are equal to the previous build and publish deltas generated by the build clients if they are not equal. If a build is equal is to be defined, for now it's a shell script that checks various properties - and works acceptable for now. I rebuild a good portion of 11.1 without further changes and get 7345 binary rpms (including all subpackages). 5666 are considered equal by my current script (based on work by Michael Matz). And many of other packages are possible to fix, so they are equal too. So this gives for uneffected rebuilds a huge reduction of updates. The kernels and kmps are currently seen as !equal after an uneffected rebuild as they put the %release (rebuild counter) in many places. Not sure how much the script should work around such cases. But even for those the download size would reduce: kernel-default.i586 (with base and extra): 25.7MB to download deltas of it: 6.7MB (I think the kernel puts a lot of "rebuild on" info in the code) #6: Piotrek Juzwiak (benderbendingrodriguez) (2009-06-17 17:29:42) As an addition to that it would be great if the older package would stay until the second rebuild so that if something breaks we could go back to the previous version and report that something's wrong with the new one. -- openSUSE Feature: https://features.opensuse.org/303532

1 0

[openFATE 305553] zypper: dist upgrade could error out if more than one repository exists
by fate_noreply＠suse.de 14 Jul '09

14 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #305553, revision 18 Title: zypper: dist upgrade could error out if more than one repository exists - openSUSE-11.2: Evaluation + openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Dirk Mueller (dirkmueller) Description: I've just learned over lunch that calling "zypper dup" is wrong if you have both buildservice repositories and a distribution repository enabled. apparently one has to call it with -r name, where name points to the distribution one wants to upgrade to, and the other repositories (e.g. buildservice addons) must not be dup'ed, but only updated via update -t package. I've verified that this indeed fixes the "reinstalling/downgrading package" issues everyone seems to be complaining about. It would be nice if zypp/zypper could detect this situation and advise the user, or alternatively do the right thing automatically. I'm not sure if channels of distributions (e.g. the factory channel, or a future openSUSE 11.0 channel) can be detected in some way.. if it does, then it could automatically add the -r argument if there is only one distribution channel enabled, and altneratively error out if more than one distribution channel is in the sources list and no -r argument was given. Relations: - make zypper dup error out if more than one repository exists (novell/bugzilla/id: 385972) https://bugzilla.novell.com/show_bug.cgi?id=385972 Discussion: #1: Stephan Kulow (coolo) (2008-05-11 02:20:39) * ** Bug 388956 has been marked as a duplicate of this bug. *** #2: Duncan Mac-Vicar (dmacvicar) (2008-12-10 15:31:24) Hm. If that is so, this feature is really important :O) Just a side question: how does installation handle this (if at all)? Currently they can't, we need to add means of such identification (as well as identification of update repos). yup, sounds good #3: Lukas Ocilka (locilka) (2008-05-12 06:17:43) Installation/Upgrade has the installation repository registered as the fist one, then Add-Ons or other repositories can be added or enabled. Upgrade doesn't handle how the packages are selected to be upgraded, it just calls solver. OK, some packages are dropped by installation by default :) See bug #300540. #4: Stephan Kulow (coolo) (2008-05-12 06:25:06) the main difference: it's pretty unusual to have 13 repos during distribution update with very comparable versions. While it's not to for zypper dup. BTW: another difference: installations sets YAST_IS_RUNNING=instsys, which some packages cause not to produce errors on updates. This might be good for dup, but bad for update #5: Duncan Mac-Vicar (dmacvicar) (2008-12-10 16:56:35) Note, I moved the bugzilla entry to fate, but mls claims the bug is invalid, as it is a perfect use case to do dist upgrade with various repositories. So this feature has to be evaluated with care and gathering opinions from various sources. It may be invalid. #7: Jiri Srain (jsrain) (2008-12-11 07:58:04) (reply to #5) I don't think it is invalid; I happened to downgrade several packages from OSS repo via zypper dup :-( #8: Duncan Mac-Vicar (dmacvicar) (2008-12-11 10:10:32) (reply to #7) The solution of stop-with-error if there is more than one repository is invalid because prevent the valid usecase of dist-upgrading with more than one repo enabled (as mls pointed out). What is valid about the feature, is that multiple repo upgrade can be dangerous, and we may warn the user if there are repos for different products there. #9: Jiri Srain (jsrain) (2008-12-11 10:53:42) (reply to #8) Sorry for not being precise in my comment: of course user must be able to override this error/warning/whatever. #6: Duncan Mac-Vicar (dmacvicar) (2008-12-10 18:34:19) Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if repositories are mixed. #10: Ján Kupec (jkupec) (2009-06-24 09:33:26) Michael, is this still relevant? Is this related to the planned --from option? #11: Michael Schröder (mlschroe) (2009-06-24 11:33:46) (reply to #10) This has nothing to do with --from, it's about doint 'zypper dup' to update the system to the next release while still having old repositories enabled. #12: Ján Kupec (jkupec) (2009-07-07 16:26:43) (reply to #11) So multiple repositories are not a problem in general, but multiple repos for different products are! OK, so now back to the solution: can you tell me or point me to some info abou these CPEs Duncan mentions in c#6? I guess they are part of the product solvable and are available as solv attribute? If so, all that's needed is to check whether there are multiple repos with a different product and write a warning if that's the case, right? #13: Michael Schröder (mlschroe) (2009-07-07 16:34:14) (reply to #12) ma, is there a libzypp interface? #14: Michael Andres (mlandres) (2009-07-13 14:16:11) (reply to #13) Yes. Since you can ask for a products CPEid, or for the CPEids related to a repository (supported or updated products). But I don't know if those CPEids are meanwhile included in the metadata (see bnc #459527). + #15: Ján Kupec (jkupec) (2009-07-14 18:17:17) (reply to #14) + OK, so this should not be too much work. So to sum it up: + * zypper: show a warning in 'dup' if there are multiple base repos with + different CPEids enabled. + * metadata: check/include the CPEid in product metadata (who should do + this?) -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 306771] Visual Basic Programming in Linux
by fate_noreply＠suse.de 14 Jul '09

14 Jul '09

Feature added by: John Shand (jshand2008) Feature #306771, revision 1 Title: Visual Basic Programming in Linux openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: John Shand (jshand2008) Description: I am also a well seasoned Visual Basic Programmer in need of an openSUSE clone so i can keep writing database software. i would appreciate any feedback on this -- openSUSE Feature: https://features.opensuse.org/306771

1 4

[openFATE 306769] Permanent File Shreeder on a Ext3/Ext4 file system
by fate_noreply＠suse.de 14 Jul '09

14 Jul '09

Feature added by: John Shand (jshand2008) Feature #306769, revision 1 Title: Permanent File Shreeder on a Ext3/Ext4 file system openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: John Shand (jshand2008) Description: If you work on a business machine like i do and you later decide to sell it, you wouldn't want all your business secrets going out the door with computer. So a cd boot up tool would be handy if you wish to totally clean your hard drive from that information before selling it. -- openSUSE Feature: https://features.opensuse.org/306769

1 2

[openFATE 306407] Do not make lang packages mandatory
by fate_noreply＠suse.de 14 Jul '09

14 Jul '09

Feature changed by: Stephan Kulow (coolo) Feature #306407, revision 9 Title: Do not make lang packages mandatory openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Mandatory Requested by: Vincent Untz (vuntz) Description: Right now, packages which have a split lang package have "Requires: % {name]-lang". I think that in most cases, this requires is wrong and it should really be a Recommends. FWIW, one thing that is blocking to implement this for GNOME is that the english help files automatically end up in the lang package, while they shouldn't: https://bugzilla.novell.com/show_bug.cgi?id=449847 Discussion: #1: Stephan Binner (beineri) (2009-05-07 08:59:25) The -lang and bundle packages contain also en/C data files and/or manuals. Or you sure that every application checks correctly for their absence? #2: Vincent Untz (vuntz) (2009-05-07 13:09:28) (reply to #1) Stephan: that's more or less the bug I linked to :-) We certainly need to be careful and check for this kind of stuff. #3: Andreas Jaeger (a_jaeger) (2009-07-09 14:32:59) Coolo, could you comment on this and evaluate it, please? #4: Stephan Kulow (coolo) (2009-07-09 14:35:49) (reply to #3) meanwhile I'm convinced myself that using Requires is wrong - as we're cheating anyway in only giving it e.g. german or spanish language. #5: Stephan Kulow (coolo) (2009-07-09 14:36:29) (reply to #4) the question though is: who will do this. We should do it consistently I guess. #6: Ludwig Nussel (lnussel) (2009-07-09 15:04:33) (reply to #5) Consistency can be enforced later. Officially allowing/encouraging Recommends would be quite helpful already so packages can be changed if they need to be touched anyways. + #7: Stephan Kulow (coolo) (2009-07-14 15:52:46) (reply to #6) + I'm actually not aware of any policy that forbids recommends. It's just + current practice. -- openSUSE Feature: https://features.opensuse.org/306407

1 0

[openFATE 305641] Bring Puppet to fully supportable status
by fate_noreply＠suse.de 14 Jul '09

14 Jul '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305641, revision 20 Title: Bring Puppet to fully supportable status - openSUSE-11.2: Candidate + openSUSE-11.2: Done Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: Dedicate a developer for the duration of the 11.2 cycle to shaking out Puppet on openSUSE, contribute patches upstream correcting integration with our base system, and analyzing what future integration areas (particularly with YaST, but not limited) appear promising. The objective is to walk through the Puppet documentation (http://reductivelabs.com/trac/puppet/wiki/DocumentationStart), Turnbull's book (ISBN 159059978), and test out that things work as they should, patching and sending upstream when they do not. Finally, contribute a small "Puppet on SUSE" document to the community detailing any platform- specific factors (you will see there are a number for other distors already). Additional notes: The plan is to _INSTALL_ the Puppet infrastructure by default. No default-running is planned - I thought it was important to clarify this. Addtionally, Facter needs to be packaged and supportable alongside Puppet. Cft should be packaged, but not default installed, and not the target of this focused infrastructure work in this cycle (i.e. Best effort). Relations: - Feature for 11 GA tech Preview (feature/id: 303687) Business case (Partner benefit): openSUSE.org: The ultimate intent is to integrate a policy management framework into the platform and have it available as default infrastructure. This has a number of consequencies: for one, the ability of third parties, both internal and external, to leverage the policy language for platform management. Secondly, I want to support the Puppet objective of being a pervasive policy language for *NIX, which may or may not be achievable. This combines with the set of enabling management technologies we want to have on the platform as blocks to build on: integrated libraries (libzypp, libstorage, ..), management instrumentation (SFCB, management profiles exposing the libraries wherever possible), Stateless YaST interface (to enable access to configuration facilities), and support instrumentation (the Novell Support Link, formerly known as Aurora and Onstar). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-08 16:25:48) . #2: Federico Lucifredi (flucifredi) (2009-01-26 18:49:40) As per for phone conversation, this requirement is not only about technology ("Policy framework"), but also about the political decision of what solution to adopt - in which context the technology is not an Engineering decision, but a Business one. I am chosing Puppet on the theory that we will do our bit to help the rise of a cross-*NIX management tool by making it available and supported. If the interest in Puppet contines at this pace, and other things go the right way, we will consider further investment. For now, we just make Puppet (and Facter with it) L3 supported. If the market keeps moving in this direction, then good, we will integrate beyond the "managing by configuration file" scheme, and look at what YaST integration we can do. If it does not, we just keep the L3 package and move3 on. Think of it as Perl - it is on Every *NIX, and if you use it is good if not, it does not hurt. #3: Pavol Rusnak (prusnak) (2009-02-10 15:45:06) I think anicka did some experiments with puppet. #4: Duncan Mac-Vicar (dmacvicar) (2009-04-15 09:35:35) Progress note: integration of the community authored zypper plugin for puppet is integrated (and working) and will be submitted to stable. #5: Duncan Mac-Vicar (dmacvicar) (2009-06-02 11:24:28) We added a patch to support zypper for puppet package ensure policies, which is submitted. Marking as in implementation. Could in theory be marked as done if we had any criteria. -- openSUSE Feature: https://features.opensuse.org/305641

1 0

[openFATE 304879] OOo: Update of KDE integration to KDE4
by fate_noreply＠suse.de 14 Jul '09

14 Jul '09

Feature changed by: Jan Holesovsky (kendysan) Feature #304879, revision 86 Title: OOo: Update of KDE integration to KDE4 openSUSE-11.1: Rejected by JP Rosevear (jproseve) reject date: 2008-08-15 11:47:35 reject reason: As per PM recommendation. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Stephan Binner (beineri) Description: The current OOo KDE integration (file dialogs, addressbook, interface/icon theme,...) is based on KDE3. As openSUSE 11.1/SLED 11 will likely not include KDE3 anymore it has to be upgraded to KDE4. Use Case: I will find this is really usefull. Discussion: #1: Stephan Kulow (coolo) (2008-06-13 09:54:23) There are far too many mandatory OOo features. Please reevaluate - it's unlikely that we won't ship KDE3 apps in SLED11 #2: Dirk Mueller (dirkmueller) (2008-06-13 13:25:48) (reply to #1) we will ship KDE3 libs, yes. that doesn't mean that we desire to have KDE3 app dependencies ;) #7: Rajesh Ganesan (ganesanrajesh) (2009-01-07 03:20:08) Well, an excellent idea and most expected too. But (http://kde.openoffice.org/) seems struck at March 2006 itself. Any plans(or chance) of revival? #8: Armin Moradi (amoradi) (2009-01-19 19:30:45) Excellent idea, again, this brings up the consistency issue with the rest of KDE4. #9: Ruurd Pels (rfpels) (2009-03-06 22:40:10) Seems to me now that we have 4.2 in FACTORY for 11.1 we can create and release an integration package there so we will be ready by the time SLES11 goes gold. #14: Michael Löffler (michl19) (2009-07-14 12:13:49) (reply to #9) Jan, can you comment on #9. As this feature is one of the highest rated ones we should start implementation better sooner than later. + #15: Jan Holesovsky (kendysan) (2009-07-14 15:15:21) (reply to #14) + We now have a proof of concept KDE4 integration in ooo-build, it will + be a part of OOo 3.1.1. So far the theming and the file dialog were + ported; also the Oxygen icons for OOo were provided - everything as a + community effort. For more information please see the comments 11, 12, + 13. #10: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:26:13) this would be nice for 11.2 #11: Karsten König (remur) (2009-06-15 15:23:55) Good news everybody! http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2009-06.html#2… (Just for tracking, most openfate users propably have seen this by now on planetsuse) #12: jimbo bigcreed (dimble_thricefoon) (2009-06-16 18:41:27) (reply to #11) dot.kde http://www.kdedevelopers.org/node/3983 KDE4 integration done by the kubuntu boys #13: Stephan Binner (beineri) (2009-07-01 20:17:03) (reply to #12) An early OpenOffice_org-kde4 package exists in Factory so this should be change to Candidate. -- openSUSE Feature: https://features.opensuse.org/304879

1 0

[openFATE 306476] Install boot entry configurable in kernel git file
by fate_noreply＠suse.de 14 Jul '09

14 Jul '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #306476, revision 7 Title: Install boot entry configurable in kernel git file - openSUSE-11.2: Unconfirmed + openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Thomas Renninger (trenn) Description: Provide a file in the kernel git which describes an installation boot entry including: - help/description - specific boot parameters - active on which arch The installation image (e.g. DVD) will then provide these specific boot entries to make it easy for: - kernel developers to add critical boot parameters required for specific HW for booting - users by providing a meaningful help at boot loader start up Currently most important settings that are coming to my mind are: - apic=bigsmp (for i386 machines with a lot cores might require that) - disable Kernel Mode Settings -> disable kernel graphics parts which won't work on all HW if set by default soon The idea originally comes from Bernhard Walle. Steffen and myself discussed that already and agreed that it makes sense to do that. On longterm it would be great to get rid of the "Failsafe" Yast boot loader functionality. This would not be necessary anymore then. This currently totally useless and outdated anyway. With the new approach, soon as one successfully booted an entry from the installation image, these boot options will be the default forever (or manually adjusted). Discussion: #1: Stefan Dirsch (sndirsch) (2009-06-22 10:09:05) I think the X' team' would like to get involved here WRT KMS. Also I believe we still want to have a possibility to detect that the user wants to start the Xserver from installation (usually fbdev driver) instead of the apparently broken native X driver. This was boot param 'x11failsafe' in the past. #2: Thomas Renninger (trenn) (2009-06-22 14:27:39) Yeah, in this case we probably need some advise from the X guys which boot params have to be passed, eventually other extra quirks are needed for KMS, no idea. But in general the responsibility and possibilty to generate/modify extra boot entries and with them passing extra kernel boot parameters and a description when to use them should rely in the kernel teams hands and thus the config file should lie in the kernel repo. Coolo, can you set this fate entry a project manager state, so that we can finally work on that at some time, thanks. #3: Stefan Dirsch (sndirsch) (2009-06-22 14:52:39) Probably the modeset option needs to be used for all relevant KMS capable DRM modules, like i915, radeon. Possibily also radeonhd (still to be implemented) and nouveau (in case it's installed, we don't ship it). So something like this: i915.modeset=0, radeon.modeset=0, radeonhd. modeset=0, nouveau.modeset=0. #5: Andreas Jaeger (a_jaeger) (2009-07-10 11:47:39) I'm a bit confused what you want to do here. What advantage will this bring us? + #6: Andreas Jaeger (a_jaeger) (2009-07-14 15:13:04) (reply to #5) + Just talked with Thomas: The idea is to safe the information about + kernel-parameters as part of the kernel package and let the + installation get this information from there - instead of hardcoding it + in the installation workflow. Also the kernel would provide different + options that the developers think make sense. -- openSUSE Feature: https://features.opensuse.org/306476

1 0

[openFATE 304879] OOo: Update of KDE integration to KDE4
by fate_noreply＠suse.de 14 Jul '09

14 Jul '09

Feature changed by: Michael Löffler (michl19) Feature #304879, revision 85 Title: OOo: Update of KDE integration to KDE4 openSUSE-11.1: Rejected by JP Rosevear (jproseve) reject date: 2008-08-15 11:47:35 reject reason: As per PM recommendation. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Stephan Binner (beineri) Description: The current OOo KDE integration (file dialogs, addressbook, interface/icon theme,...) is based on KDE3. As openSUSE 11.1/SLED 11 will likely not include KDE3 anymore it has to be upgraded to KDE4. Use Case: I will find this is really usefull. Discussion: #1: Stephan Kulow (coolo) (2008-06-13 09:54:23) There are far too many mandatory OOo features. Please reevaluate - it's unlikely that we won't ship KDE3 apps in SLED11 #2: Dirk Mueller (dirkmueller) (2008-06-13 13:25:48) (reply to #1) we will ship KDE3 libs, yes. that doesn't mean that we desire to have KDE3 app dependencies ;) #7: Rajesh Ganesan (ganesanrajesh) (2009-01-07 03:20:08) Well, an excellent idea and most expected too. But (http://kde.openoffice.org/) seems struck at March 2006 itself. Any plans(or chance) of revival? #8: Armin Moradi (amoradi) (2009-01-19 19:30:45) Excellent idea, again, this brings up the consistency issue with the rest of KDE4. #9: Ruurd Pels (rfpels) (2009-03-06 22:40:10) Seems to me now that we have 4.2 in FACTORY for 11.1 we can create and release an integration package there so we will be ready by the time SLES11 goes gold. + #14: Michael Löffler (michl19) (2009-07-14 12:13:49) (reply to #9) + Jan, can you comment on #9. As this feature is one of the highest rated + ones we should start implementation better sooner than later. #10: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:26:13) this would be nice for 11.2 #11: Karsten König (remur) (2009-06-15 15:23:55) Good news everybody! http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2009-06.html#2… (Just for tracking, most openfate users propably have seen this by now on planetsuse) #12: jimbo bigcreed (dimble_thricefoon) (2009-06-16 18:41:27) (reply to #11) dot.kde http://www.kdedevelopers.org/node/3983 KDE4 integration done by the kubuntu boys #13: Stephan Binner (beineri) (2009-07-01 20:17:03) (reply to #12) An early OpenOffice_org-kde4 package exists in Factory so this should be change to Candidate. -- openSUSE Feature: https://features.opensuse.org/304879

1 0

[openFATE 306776] Yast Integration with PolicyKit
by fate_noreply＠suse.de 14 Jul '09

14 Jul '09

Feature added by: Ney walens de Mesquita (nwm) Feature #306776, revision 1 Title: Yast Integration with PolicyKit openSUSE-11.2: Unconfirmed Priority Requester: Desirable openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Ney walens de Mesquita (nwm) Description: Would be very good, if Yast can integrate with PolicyKit permissions and provide ways of a regular non root user to configure modules and set values regarding Policykit permissions. -- openSUSE Feature: https://features.opensuse.org/306776

1 2

[openFATE 305553] zypper: dist upgrade could error out if more than one repository exists
by fate_noreply＠suse.de 13 Jul '09

13 Jul '09

Feature changed by: Michael Andres (mlandres) Feature #305553, revision 17 Title: zypper: dist upgrade could error out if more than one repository exists openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Dirk Mueller (dirkmueller) Description: I've just learned over lunch that calling "zypper dup" is wrong if you have both buildservice repositories and a distribution repository enabled. apparently one has to call it with -r name, where name points to the distribution one wants to upgrade to, and the other repositories (e.g. buildservice addons) must not be dup'ed, but only updated via update -t package. I've verified that this indeed fixes the "reinstalling/downgrading package" issues everyone seems to be complaining about. It would be nice if zypp/zypper could detect this situation and advise the user, or alternatively do the right thing automatically. I'm not sure if channels of distributions (e.g. the factory channel, or a future openSUSE 11.0 channel) can be detected in some way.. if it does, then it could automatically add the -r argument if there is only one distribution channel enabled, and altneratively error out if more than one distribution channel is in the sources list and no -r argument was given. Relations: - make zypper dup error out if more than one repository exists (novell/bugzilla/id: 385972) https://bugzilla.novell.com/show_bug.cgi?id=385972 Discussion: #1: Stephan Kulow (coolo) (2008-05-11 02:20:39) * ** Bug 388956 has been marked as a duplicate of this bug. *** #2: Duncan Mac-Vicar (dmacvicar) (2008-12-10 15:31:24) Hm. If that is so, this feature is really important :O) Just a side question: how does installation handle this (if at all)? Currently they can't, we need to add means of such identification (as well as identification of update repos). yup, sounds good #3: Lukas Ocilka (locilka) (2008-05-12 06:17:43) Installation/Upgrade has the installation repository registered as the fist one, then Add-Ons or other repositories can be added or enabled. Upgrade doesn't handle how the packages are selected to be upgraded, it just calls solver. OK, some packages are dropped by installation by default :) See bug #300540. #4: Stephan Kulow (coolo) (2008-05-12 06:25:06) the main difference: it's pretty unusual to have 13 repos during distribution update with very comparable versions. While it's not to for zypper dup. BTW: another difference: installations sets YAST_IS_RUNNING=instsys, which some packages cause not to produce errors on updates. This might be good for dup, but bad for update #5: Duncan Mac-Vicar (dmacvicar) (2008-12-10 16:56:35) Note, I moved the bugzilla entry to fate, but mls claims the bug is invalid, as it is a perfect use case to do dist upgrade with various repositories. So this feature has to be evaluated with care and gathering opinions from various sources. It may be invalid. #7: Jiri Srain (jsrain) (2008-12-11 07:58:04) (reply to #5) I don't think it is invalid; I happened to downgrade several packages from OSS repo via zypper dup :-( #8: Duncan Mac-Vicar (dmacvicar) (2008-12-11 10:10:32) (reply to #7) The solution of stop-with-error if there is more than one repository is invalid because prevent the valid usecase of dist-upgrading with more than one repo enabled (as mls pointed out). What is valid about the feature, is that multiple repo upgrade can be dangerous, and we may warn the user if there are repos for different products there. #9: Jiri Srain (jsrain) (2008-12-11 10:53:42) (reply to #8) Sorry for not being precise in my comment: of course user must be able to override this error/warning/whatever. #6: Duncan Mac-Vicar (dmacvicar) (2008-12-10 18:34:19) Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if repositories are mixed. #10: Ján Kupec (jkupec) (2009-06-24 09:33:26) Michael, is this still relevant? Is this related to the planned --from option? #11: Michael Schröder (mlschroe) (2009-06-24 11:33:46) (reply to #10) This has nothing to do with --from, it's about doint 'zypper dup' to update the system to the next release while still having old repositories enabled. #12: Ján Kupec (jkupec) (2009-07-07 16:26:43) (reply to #11) So multiple repositories are not a problem in general, but multiple repos for different products are! OK, so now back to the solution: can you tell me or point me to some info abou these CPEs Duncan mentions in c#6? I guess they are part of the product solvable and are available as solv attribute? If so, all that's needed is to check whether there are multiple repos with a different product and write a warning if that's the case, right? #13: Michael Schröder (mlschroe) (2009-07-07 16:34:14) (reply to #12) ma, is there a libzypp interface? + #14: Michael Andres (mlandres) (2009-07-13 14:16:11) (reply to #13) + Yes. Since you can ask for a products CPEid, or for the CPEids related + to a repository (supported or updated products). But I don't know if + those CPEids are meanwhile included in the metadata (see bnc #459527). -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 306786] Manage KVM via VirtualBox Frontend
by fate_noreply＠suse.de 13 Jul '09

13 Jul '09

Feature added by: Matthias Eckermann (mge1512) Feature #306786, revision 1 Title: Manage KVM via VirtualBox Frontend Hackweek IV: Unconfirmed Priority Requester: Important Requested by: Matthias Eckermann (mge1512) Description: While a VirtualBox backend for lib-virt has already been developed, see: http://libvirt.org/drvvbox.html (http://libvirt.org/drvvbox.html) , it is not yet implemented to manage other HVs (than the vbox internal HV) using the VirtualBox frontend. It is proposed to make the VirtualBox frontend use libvirt as a backend, to manage other HVs (KVM,Xen). -- openSUSE Feature: https://features.opensuse.org/306786

1 0

[openFATE 306327] Add DB2 Express-C
by fate_noreply＠suse.de 12 Jul '09

12 Jul '09

Feature changed by: Luc de Louw (delouw) Feature #306327, revision 10 Title: Add DB2 Express-C openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Robert Schweikert (rjschwei) Description: IBM is interested to providing an easy mechanism for users to install DB2 Express C, the free version of DB2. It would be nice if we could add DB2 Express C to the openSUSE non-oss repository. Relations: Discussion: #3: Glenn Doig (doiggl) (2009-04-24 06:16:56) http://www-01.ibm.com/software/data/db2/express/ http://www-01.ibm.com/software/data/db2/express/download.html #4: Pascal Bleser (pbleser) (2009-05-20 22:00:05) Why not, let's go for it. If IBM wants to see openSUSE as a vehicle to drive the adoption of their products, even if not opensource, and as long as it doesn't affect the license/EULA/redistribution of the distribution itself, I don't see any reason not to support that initiative. IBM can choose to either have it in the non-OSS repository, or host it in a repository of their own, with openSUSE builds. What is involved on our side of things ? #5: Robert Schweikert (rjschwei) (2009-05-28 09:21:00) - IBM has a distribution agreement that needs to be signed. In addition I think when somone installs DB2-Express C from the non-oss repo we should pop up a box telling them about the agreement if they intend to distribute DB2 Express with a product. No registration required for private use. #6: Robert Schweikert (rjschwei) (2009-05-28 09:22:04) Added attachment Distribution agreement (IBM_DB2_and_WAS_CE_Distribution_Form_and_Agreement_4_17_2009.pdf) + #7: Luc de Louw (delouw) (2009-07-12 14:45:45) + It is a good idea to add DB2-Express. How about also to add Oracle XE + (the equivalent to DB2-Express) so users have more choice. + Should I add a feature request for Oracle XE? -- openSUSE Feature: https://features.opensuse.org/306327

1 0

[openFATE 303736] yast and libzypp should respect the disk space reserved for root
by fate_noreply＠suse.de 12 Jul '09

12 Jul '09

Feature changed by: Luc de Louw (delouw) Feature #303736, revision 10 Title: yast and libzypp should respect the disk space reserved for root openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-08 12:18:47 reject reason: Postponing. This is nice to have. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Desirable Requested by: Ladislav Slezak (lslezak) Description: If e.g. root partition has 70MB free user space and 500MB free space reserved for root user yast reports 570MB total free space. But installation of a package which is greater than 70MB fails: installing package kdelibs3-devel-doc-3.5.5-45 needs 335MB on the / filesystem Yast should display the non-root free space (70MB in this case). It seems that it is valid only for ext2/ext3 filesystems (XFS and ReiserFS seem to not support root space). Default reserved space for ext2/ext3 is 5%. References: https://bugzilla.novell.com/show_bug.cgi?id=237309 + Discussion: + #1: Luc de Louw (delouw) (2009-07-12 14:43:12) + The problem is that the default reserved space is way to much for + todays diskspace available. IMHO this issue should be addressed + upstream, the default space should be much less than 5% or even a fixed + amount of space e.g. 100MB. + The reserved space for root is tought for emergencies and not for + installing new packages, at least not with that size. + At the end of the day it is not a good idea to support that feature. -- openSUSE Feature: https://features.opensuse.org/303736

1 0

[openFATE 304429] Package cache handling in yast
by fate_noreply＠suse.de 11 Jul '09

11 Jul '09

Feature changed by: Vincent Petry (PVince81) Feature #304429, revision 15 Title: Package cache handling in yast openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 21:45:10 reject reason: Postponing. Zypper already provides the functionality. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Done Priority Requester: Important Requested by: Ladislav Slezak (lslezak) Description: Add a possibility to edit 'keeppackages' option in *.repo files. The downloaded packages are not kept by default, but it should be configurable by user. The question is how it should be configurable. My suggestions are a check box or an extra menu item in the repositoru manager (repositories. ycp) . References: https://bugzilla.novell.com/show_bug.cgi?id=393709 Test Case: * check if the installed version of yast2-packager is 2.18.0 or later, with following command: $ rpm -q yast2-packager * add a new Software Repository: open YaST2 -> Software -> Software Repositories -> Add * during adding the new Software Repositories flag "Keep Downloaded Packages" * install or update a package: # zypper install <package name> * check if the package rpm file was saved in local cache (default: /var/cache/zypp/packages/) Discussion: #2: Ladislav Slezak (lslezak) (2009-01-08 13:47:14) Implemented in yast SVN trunk (will be in yast2-packager-2.18.0) There is a new check box, similar to 'Enabled' and 'Autorefresh' check boxes. (bnc#402617) #3: Eduardo Sotomayor (easgs) (2009-05-21 01:01:51) Will it work when installing a package with Yast not zypper command? #4: Rémy Marquis (spyhawk) (2009-05-23 08:36:50) (reply to #3) Yes. it is working. As specified above, there is a new checkbox in the UI for enabling cache handling. + #5: Vincent Petry (pvince81) (2009-07-11 03:20:54) + Will it also resume partially downloaded packages ? -- openSUSE Feature: https://features.opensuse.org/304429

1 0

[openFATE 306621] Possibility to skip filesystem check at startup
by fate_noreply＠suse.de 10 Jul '09

10 Jul '09

Feature added by: Dominik Grafenhofer (dgrafenhofer) Feature #306621, revision 1 Title: Possibility to skip filesystem check at startup openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Dominik Grafenhofer (dgrafenhofer) Description: Periodic filesystem checks at startup are important, but take a lot of time. For desktop users it is sometimes importent to startup their computer really fast (e.g. when giving a presentation). It is a nuissance, that these filesystem checks cannot be easily skipped (and postponed for the next startup) like under Ubuntu. Analogous to Ubuntu Linux I therefore propose to have a mechanism in place to stop a (periodic) filesystem check at startup when the escape key is pressed during the check. -- openSUSE Feature: https://features.opensuse.org/306621

1 25

[openFATE 306758] Online Banking with New Zealand Banks
by fate_noreply＠suse.de 10 Jul '09

10 Jul '09

Feature added by: John Shand (jshand2008) Feature #306758, revision 1 Title: Online Banking with New Zealand Banks openSUSE-11.2: Unconfirmed Priority Requester: Mandatory Requested by: John Shand (jshand2008) Description: I am using a financial program called KMyMoney 0.9.3. it is a fantastic program, but i am used to actually doing my online banking with another program i used for real time transactions and update ie. the program would store my login information in an encrpted file and automatically login into my Kiwibank account from the program itself. this would be an awesome feature for any of the financial software available for opensuse. please do your best with this feature as it would make life a heck of a lot easier. thanks for your help john -- openSUSE Feature: https://features.opensuse.org/306758

1 1

[openFATE 306580] provide trademark-neutral branding packages
by fate_noreply＠suse.de 10 Jul '09

10 Jul '09

Feature added by: Juergen Weigert (jnweiger) Feature #306580, revision 1 Title: provide trademark-neutral branding packages openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Juergen Weigert (jnweiger) Description: Wit 11.2 we plan to provide e.g. * MozillaFirefox-branding-opensuse.rpm and * MozillaFirefox-branding-upstream.rpm for the user to easily substitute our branding with an original upstream branding. This implements opensuse trademark guidelines for modified distributions, but in case of Firefox, we should also provide a * MozillaFirefox-branding-template-neutral.rpm or similar to also implement Mozilla trademark guidelines. -- openSUSE Feature: https://features.opensuse.org/306580

1 6

[openFATE 306352] mod_proxy_ajp: support for "subscribe" method
by fate_noreply＠suse.de 10 Jul '09

10 Jul '09

Feature added by: Emmanuel Rouët (erouet) Feature #306352, revision 1, last change by Title: mod_proxy_ajp: support for "subscribe" method openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Emmanuel Rouët (erouet) Description: With mod_jk, the "unknown" methods were handled as attributes and still forwarded. In AJP, "unknown" methods are not allowed to be compressed & will not be forwarded and the connection is broken. Shouldn't AJP provide feature parity ? Currently, the list of methods supported by AJP does not include "subscribe": http://httpd.apache.org/docs/2.2/mod/mod_proxy_ajp.html#overviewprotocol However, Apache.org states "Later version of ajp13, will transport additional methods, even if they are not in this list." -- openSUSE Feature: https://features.opensuse.org/306352

1 1

[openFATE 306393] BrowsePoll support in yast2-printer
by fate_noreply＠suse.de 10 Jul '09

10 Jul '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #306393, revision 3 Title: BrowsePoll support in yast2-printer - openSUSE-11.2: Unconfirmed + openSUSE-11.2: Rejected by Andreas Jaeger (a_jaeger) + reject date: 2009-07-10 11:41:21 + reject reason: A complete redesign is too much work for this feature. Priority Requester: Neutral Requested by: Johannes Meixner (jsmeix) Description: yast2-printer "Print via Network": request for BrowsePoll support Usually there is no need for BrowsePoll support in yast2-printer because currently it is designed to make a setup according to the "Intrinsic design of CUPS for printing in the network", see http://en.opensuse.org/SDB:CUPS_in_a_Nutshell (http://en.opensuse.org/SDB:CUPS_in_a_Nutshell) But there is a valid use case for BrowsePoll: See https://bugzilla.novell.com/show_bug.cgi?id=433047#c10 (https://bugzilla.novell.com/show_bug.cgi?id=433047#c10) I know a use-case for BrowsePoll: When in a bigger company there are several CUPS servers for various departments each server may allow access for all client hosts in the whole company but it would usually send browsing information only to the client hosts of the particular department to which a particular server belongs. When a user in department A likes to see additionally the queues on the server for department B he would use BrowsePoll to poll the queues from the server for department B. Adding BrowsePoll support requires a re-design of the whole "Print via Network" dialog. I like to have it evaluated if it is worth the effort ("business case" and so on). + Discussion: + #1: Andreas Jaeger (a_jaeger) (2009-07-10 11:42:58) + Let's not redesign the UI for this at them moment. My only requirement + is the default YaST policy: YaST should not overwrite user + configuration changes, so if a user adds BrowsePoll and later runs + YaST, the contents is still the same. -- openSUSE Feature: https://features.opensuse.org/306393

1 0

[openFATE 304500] Make storage failures non-fatal
by fate_noreply＠suse.de 10 Jul '09

10 Jul '09

Feature changed by: Arvin Schnell (aschnell) Feature #304500, revision 24 Title: Make storage failures non-fatal openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-29 13:04:58 reject reason: Postponing. Out of resources. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-03 08:34:12 reject reason: No resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Arvin Schnell (aschnell) Description: Currently all storage failures (during step "Prepare Harddisk") are fatal. E.g. if a partition cannot be mounted the installation is aborted. Some failures do not really harm, e.g. if mounting of a Windows partition fails that is not used for the installation. For other failures an really experienced user might fix the problem manually on the console. So for all failures the user should be asked whether the installation should continue. References: https://bugzilla.novell.com/show_bug.cgi?id=382765#c1 https://bugzilla.novell.com/show_bug.cgi?id=397156 https://bugzilla.novell.com/show_bug.cgi?id=402812 https://bugzilla.novell.com/show_bug.cgi?id=438660 + https://bugzilla.novell.com/show_bug.cgi?id=520902 Relations: - Installation aborts after error message that NTFS partition can't be mounted (novell/bugzilla/id: 309074) https://bugzilla.novell.com/show_bug.cgi?id=309074 Discussion: #2: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:33:20) Please reject for SLE11/11.1. All resources allocated with mandatory features already. -- openSUSE Feature: https://features.opensuse.org/304500

1 0

[openFATE 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 09 Jul '09

09 Jul '09

Feature changed by: andrea florio (anubisg1) Feature #305634, revision 124 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Candidate Priority Requester: Mandatory Projectmanager: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Relations: - Fedora Upgrade Instructions (feature/id: http://fedoraproject.org/wiki/YumUpgradeFaq) - Debian Upgrade How-to (url: http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.ht…) - Wiki page for implementation (url: http://en.opensuse.org/Upgrade/11.2) Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) Yes, the PAM maintainers would like to know more details, too. #19: Robert Davies (robopensuse) (2009-02-02 13:45:04) (reply to #18) There were a number of different forum poster's hitting it, just after 11.1 released (I think due to zypper dup not YaST upgrade and therefore unreported to BugZilla). It is not something I had, because I did fresh installs. Interestingly though I have used Debian less, I have done several dist-upgrade's, simply because it is expected to work well. So it is a mistake to focus on specific tech issues alone. This problem is also about expectations and user perceptions. Announcing "support" for dist upgrade and appealing for test, so work rounds can be found, for release notes at time matters to. #21: Cristian Rodríguez (elvigia) (2009-02-02 15:29:32) (reply to #19) as you failed to elaborate on the problem, I will.. Some people end with broken /etc/pam.d/login they have the following line session required pam_resmgr.so but that module is gone, and rpm upgrade does not remove that line (probably because that file has been modified) #24: JP Rosevear (jproseve) (2009-02-02 10:15:19) (reply to #21) Isn't that simply a packaging problem? #25: Klaus Kämpf (kwk) (2009-02-02 19:42:45) (reply to #24) In this case, it looks like a packaging problem, indeed. However, we had more complicated upgrade tasks in the past, like dropping devs.rpm and running udev instead. See Removing devs.rpm (http://en.opensuse.org/Software_Management/Upgrade/Devs_Rpm) for a discussion of the problem. #30: Peter Poeml (poeml) (2009-03-10 15:31:10) (reply to #25) Interesting discussion about that particular issue, but simple to solve. What works is keeping devs.rpm, and/or simply rpm -e --justdb it. (It's enough to do so later.) The more complicated issues in the past where a case where the kernel changed its major version, and some networking applications could not start with the (still running) old kernel. Didn't prevent an online upgrade over the network though, and applications could keep running. When skipping several openSUSE versions, and differences have accumulated, in can happen that an upgrade in one step is not possible. It's not possible to upgrade from 9.0 to 10.1 without first updating to 9.1, due to the kernel. These issues are quickly found by experimentation though. Other than that, the most hurting issue during remote upgrades is the difficulty to ensure persistent device naming for NICs, because that is reimplemented / changed with each openSUSE version, the upgrade procedure is not well documented, and funny surprises are the rule, and it often simply doesn't work. Other small hurdles are the increasing modularization of kernel, which can lead to lack of support for chipsets and storage in the initrd, package split-offs (mingetty) that lead to lack of essential components after the upgrade. It pays to make sure that all packages are installed which are in the "minimal" patter of that openSUSE version. And the required but disappeared PAM module locked us out once also... A word to all the non-believers who think that upgrades don't work: I have upgraded dozens of systems remotely during the last decade. All my productive systems are repeatedly upgraded that way since day one. Unfortunately, the tools we have didn't help with this. Apart from using rpm, I started doing this with yum a few years ago (if it works, metadata is available, falling back to rpm if needed). Last year I documented some steps: http://poeml.de/~poeml/10.1-11.0-update/update-11.0.howto. With today's conveniency of virtualization at hand, I actually did an upgrade by experiment with a VM first, to minimize the risk, and documented all the steps. Since I had to upgrade several 10.1 machines, this seemed like a good idea to reduce the risk and save brain energy. The notes from it are a good outcome, too. #26: Klaus Kämpf (kwk) (2009-02-02 19:43:24) (reply to #21) Whats the bug number for this problem ? #20: Robert Davies (robopensuse) (2009-02-02 14:48:34) On Scope, here are the Release Notes for Lenny - http://www.uk.debian.org/releases/testing/amd64/release-notes/ 4.1.4 - Prepare a safe environment for the upgrade - text mode or via ssh login, Article on how to go from Etch to Lenny - http://www.debianadmin.com/howto-upgrade-from-debian-etch-40-to-lenny-50.ht… #27: Federico Lucifredi (flucifredi) (2009-02-04 15:32:01) (reply to #20) this is very helpful, we should look at the bumps that Debian hits while doing this. On a separate note, just tried to "yum upgrade" frlom RHEL 5.2 to RHEL 5.3, and it went without a hitch. There may be something to be gathered from Fedora as well here. #22: Manuel Trujillo (toomany) (2009-02-02 15:44:44) I think this is a really helpful characteristic, because a lot of people like me, use openSUSE as server, and is a true hell to upgrade servers in any datacenter, at kilometers off distance. I hope this feature will be a reallity in the next 11.2. #23: Duncan Mac-Vicar (dmacvicar) (2009-02-02 15:46:27) (reply to #22) Please, if you just want to express your favorites, use the voting feature. Comments is for discussion around solving the problem itself. #28: Javier Llorente (javierllorente) (2009-03-10 14:08:21) Just a few comments... A few weeks ago, I upgraded one server from 11.0 to 11.1 via ssh using zypper dup. zypper and its related libraries have to be upgraded first in order to avoid problems, especially if the upgrade process is interrupted. Another issue besides the order of the upgrade, would be restarting daemons and dealing with new .conf. Maybe we could check if it has been edited, if not, then automerge it. Some stuff could malfunction due to old config files. We could also have a manual merge option. Another thing... wouldn't it be better to download all the packages at once and install them afterwards instead of downloading/installing package by package? On a side note, I want to say that my upgrade went smoothly (rcpbind wasn't installed but I consider that a small issue). zypper has been improved a lot. It would be great if zypper dup was officially supported as another upgrade method. #29: Peter Poeml (poeml) (2009-03-10 14:35:19) (reply to #28) Regarding config merge on update, I have played with two things. First, the yum plugin called yum-merge-conf, which allows for interactive merging of config files during the upgrade. Works and gets the job done, and could be done in zypper as well, however from my own experience I have to say that it protracts the update more than I sometimes like, and I typically want to do this job in a separate step (after the packages are updated). not protract the update for merging all files. So I rather use another approach, which is a script called rpmresolve (https://build.opensuse.org/package/view_file?file=rpmresolve&package=server… 3Apoeml), which works in a similar way, based on presence of rpmsave/rpmnew files. It opens vim in diff mode, lets you merge and asks you which version you want to keep. Works well for me since years, it just might require refinement of some things of the implementation in a more generic way (e.g. calling $EDITOR with different option than - d). + #31: andrea florio (anubisg1) (2009-07-10 00:11:07) + i think that we miss something like that: + https://help.ubuntu.com/community/JauntyUpgrades + it's so easy to upgrade an ubuntu version that also my 5 years old + student was able to do it.. -- openSUSE Feature: https://features.opensuse.org/305634

1 0