February 2009 - openSUSE Features - openSUSE Mailing Lists

[openFate 305472] Support transaction triggers for rpms
by fate_noreply＠suse.de 21 Jan '13

21 Jan '13

Feature added by: Vincent Untz <vuntz(a)novell.com> Feature #305472, revision 1, last change by Title: Support transaction triggers for rpms openSUSE-11.2: New Priority Requester: Important Requested by: Vincent Untz <vuntz(a)novell.com> Partner organization: openSUSE.org Description: It's important to be able to run once after all packages have been installed a command (instead of running the command after each of x packages getting installed, which would make the process much slower). That's basically a post-transaction trigger. For background, see https://bugzilla.novell.com/show_bug.cgi?id=365649 and especially comment #14 from Stanislav. (note that this is work that should be done in upstream rpm, not as patches) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305472

1 8

[openFate 305112] Add webcam configuration module for yast
by fate_noreply＠suse.de 19 Oct '12

19 Oct '12

Feature added by: Michael Loeffler <michl(a)novell.com> Feature #305112, revision 1, last change by Title: Add webcam configuration module for yast openSUSE-11.1: New Priority Requester: Desirable Requested by: Michael Loeffler <michl(a)novell.com> Partner organization: openSUSE.org Description: Webcam is configured automatically. But for users having trouble with configuration a webcam configuration module would be useful. See also bug #359729 Business case (Partner benefit): openSUSE.org: Users in trouble with webcam configuration need a webcam configuration possibility in YaST. As the usage of webcams is rising, eg. through instant messanger this feature request adresses more and more users -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305112

1 25

[openFate 305148] Automatic Compiling of Kernel Modules
by fate_noreply＠suse.de 04 Sep '12

04 Sep '12

Feature added by: Andreas Jaeger <aj(a)novell.com> Feature #305148, revision 1, last change by Title: Automatic Compiling of Kernel Modules openSUSE-11.2: New Priority Requester: Important Requested by: Andreas Jaeger <aj(a)novell.com> Partner organization: openSUSE.org Description: The Standard Linux-Kernel provides a lot of hardware drivers/kernel modules. Nevertheless there are still devices not supported by the kernel. If a user compiles a kernel module by himself, he has to redo this step after each kernel update (if he is aware at all, that this step is needed). My idea was to install kernel-source, kernel-syms, gcc and make with each standard installation and to define a standard directory for the source code of kernel modules, e.g /usr/src/updates. When a Kernel Update is done, the system looks on boot in /usr/src/updates for directories and does there a 'make' and 'make install'. (build a kmp-package ?) If this could become a standard for other distributions (LSB) as well and corresponding init scripts would exist, third party kernel modules could be installed automagically after extracting code to /usr/src/update, so there would be some kind of standard for installing external kernel modules. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305148

1 21

[openFate 305493] Look at plymouth for splash during boot
by fate_noreply＠suse.de 27 Aug '12

27 Aug '12

Feature added by: Vincent Untz <vuntz(a)novell.com> Feature #305493, revision 1, last change by Title: Look at plymouth for splash during boot openSUSE-11.2: New Priority Requester: Important Requested by: Vincent Untz <vuntz(a)novell.com> Partner organization: openSUSE.org Description: I wanted to open a fate feature about this when I first heard of plymouth, but reading http://fedoramagazine.wordpress.com/2008/10/21/interview-fedora-10s-better-… really makes me think we should go this way. Ray's comment starting with "Every flicker and mode change in the boot process takes away from the whole experience." is especially interesting. Is it okay to track the "don't show grub by default" here? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305493

1 94

[openFATE 305881] Add a simple way to access the rpmlint report
by fate_noreply＠suse.de 17 Apr '12

17 Apr '12

Feature added by: Vincent Untz (vuntz) Feature #305881, revision 1, last change by Title: Add a simple way to access the rpmlint report Buildservice: Unconfirmed Priority Requester: Important Requested by: Vincent Untz (vuntz) Description: Right now, to see the rpmlint report of a build, you have to get the complete build log, which can be slow (because it's big). Having a faster way to read the rpmlint report could result in some tools to highlight what should be fixed, and therefore in better packages. -- openSUSE Feature: https://features.opensuse.org/305881

1 6

[openFATE 305907] Support Update Repo Generation
by fate_noreply＠suse.de 17 Apr '12

17 Apr '12

Feature added by: Adrian Schröter (adrianSuSE) Feature #305907, revision 1, last change by Title: Support Update Repo Generation Buildservice: Evaluation Priority Requester: Desirable Projectmanager: Desirable Requested by: Adrian Schröter (adriansuse) Description: The Build Service should offer update repos as repository channel. It is unclear right now, how we will carry in the extra update information texts. This should maybe designed together with a new changelog handling. -- openSUSE Feature: https://features.opensuse.org/305907

1 6

[openFATE 305859] Make installation history accessible from Yast GUI
by fate_noreply＠suse.de 05 Oct '11

05 Oct '11

Feature added by: Atri Bhattacharya (badshah400) Feature #305859, revision 1, last change by Title: Make installation history accessible from Yast GUI openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Atri Bhattacharya (badshah400) Description: As there is now (since openSUSE 11.1) a way to access the history of installed packages and their dependencies, it would be very useful if this history could be accessed from the Yast GUI. In the present implementation, zypper saves the history in a file (/var/log/zypp/history) which is very obscure. The history thus shown from yast should be able to show official-updates and non-official upgrades in different categories. Use Case: 1. Install new software, software not working (or not liked), look-up history start yast, look-up history, uninstall software and installed dependencies. 2. Online update, something goes wrong (upgraded software not working or something), look-up history to see recent updates and revert (all from yast). -- openSUSE Feature: https://features.opensuse.org/305859

1 8

[openFate 305593] Send notifications on link, branch and aggregate, show them in interface
by fate_noreply＠suse.de 23 May '11

23 May '11

Feature added by: Pavol Rusnak <prusnak(a)novell.com> Feature #305593, revision 1, last change by Title: Send notifications on link, branch and aggregate, show them in interface Buildservice: New Priority Requester: Desirable Requested by: Pavol Rusnak <prusnak(a)novell.com> Partner organization: openSUSE.org Description: * send notification emails on link, branch and aggregate and/or show how many packages are linked to current package - that should reduce number of deletions which break other people's packages -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305593

1 3

[openFATE 305849] Provide the Ability to Natively Load More Than One Protocol Stack
by fate_noreply＠suse.de 14 Apr '11

14 Apr '11

Feature added by: Scott Couston (zczc2311) Feature #305849, revision 1, last change by Title: Provide the Ability to Natively Load More Than One Protocol Stack openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Scott Couston (zczc2311) Description: Currently we natively support only an IP protocol stack, however I would hazard a guess that SLES has the ability to load IPX as well even as we have moved away from IPX. The Other Misgiving is that natively we cannot support more than an IP Protocol Stack and the lack of very good open/proprietary 3270 type Terminal Emulation shipped by default. I would be much happier if opensuse OR SLED could cope with another Protocol Stack - In Australia there is an enormous market we currently offer no solution to in only providing an IP Protocol Stack. In my home Country Australia All Federal Government- Health-Social Security- etc./All Banking Sectors/Most all Military Sectors/All State and Federal Law enforcement/Others (Thats a big Market Place) need to support a 3270 type Terminal Emulator and directly address SNA or X.25 or STLC comms. To compete we must at least be equal in the market place! The other mass market world wide particularly in the US are PC's that all Travel Agents use to make their bookings. World Wide They would use either Saber or Apollo or Galileo or Amadeus or Abacus - that about covers the whole World now. The issue all user face with M.S is that they most likely have a dedicated comms server as M.S cannot even load the required Protocol Stack. Depending on which Global System is used they mostly stick to their preferred stack and this could vary from ALC/STLC/X.25/IP/IPX/MATIP/etc..... Enough said - I think we all understand how we can better appeal to other huge markets if we invest in the functional ability to load more than just IPV4/6. I think we need to look far and wide at ALL Industry comms and we CAN do what MS cannot - We could easily bundle off a very very good 3270 type emulator and support SNA AND IP directly without the possible need for a comms servers packet stacking and promiscuous translation to IP. So we have 2 huge untaped Markets we cannot help right now and these are Australian - .GOV/.MIL and internal Banks and credit unions Global - The travel Industry is their varying, but constant use of say STLC/MATIP If we need to pull apart IP coms in the future for IPV6 this would be golden to support more than an IP Protocol only. __________________ -- openSUSE Feature: https://features.opensuse.org/305849

1 4

[openFATE 305842] Provide RPM Update Server to Update All openSUSE/SLED Workstations
by fate_noreply＠suse.de 14 Apr '11

14 Apr '11

Feature added by: Scott Couston (zczc2311) Feature #305842, revision 1, last change by Title: Provide RPM Update Server to Update All openSUSE/SLED Workstations openFATE: Unconfirmed Priority Requester: Important Requested by: Scott Couston (zczc2311) Description: *Please be Patient - This is my First FATE request* Definitions in this Submission Workstation == Any openSUSE/SLED installation that functions without direct server support Installation Server == Any designated PC that holds a repository for the complete RPM's contained at time of software Release. Update Server == Any designated PC that holds a repository(s) that contain online update RPM's The 'Server' would be accessible by normal NFS... et al Services currently available. Current Situation The Installation of a PC with openSUSE/SLED requires a huge number of Online Updates a situation that may never change whilst development continues. The Installation of openSUSE has the ability to perform many NFS Installations at one time whilst being able to create 1 repository server for the entire Installation RPM's for future addition of features and groups not included in the base installation. Feature Request Along the same notion of an NFS Installation I propose that we an Installation Server or Other to be an Update Server which downloads ALL RPM updates as they become available. Each Workstation then selects Online Updates from the Update Server per chosen update check cycle period. In this way each workstation needs only to connect with the Update Server rather than each workstation downloading its required updates. This has the potential to cut update traffic by the number of workstations installed on a LAN and this weighed against the traffic of downloading ALL updates and the traffic on ALL Online update Server Repositories and Mirrors external to the LAN. The concept is notedly simple however this has a huge technical repercussion and link to FATE #120340. This concept is open for addition to FATE #120340 or it can stand alone at the discretion of Novell.DE Whilst this concept is created by the author the technical impact/problems will require much input from Novell.De and Suse.DE and the author. -- openSUSE Feature: https://features.opensuse.org/305842

1 10