April 2011 - openSUSE Features - openSUSE Mailing Lists

[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

[New: openFATE 308270] add link to download all files(sources, patches, spec, etc...) as one file
by fate_noreply＠suse.de 23 May '11

23 May '11

Feature added by: Alex Savin (alexqwesa) Feature #308270, revision 1 Title: add link to download all files(sources, patches, spec, etc...) as one file Buildservice: Unconfirmed Priority Requester: Important Requested by: Alex Savin (alexqwesa) Description: if you want build some package local - you need download sources, patches, spec, and all other files, but some packages use very many files. Add link to download all files(what needed to build package) as one file. -- openSUSE Feature: https://features.opensuse.org/308270

1 5

[New: openFATE 308469] Automatically generated list of various private/open repositories
by fate_noreply＠suse.de 23 May '11

23 May '11

Feature added by: Lee Matheson (oldcpu) Feature #308469, revision 1 Title: Automatically generated list of various private/open repositories Buildservice: Unconfirmed Priority Requester: Important Requested by: Lee Matheson (oldcpu) Description: The new build service promises to make available many new packages for openSUSE community members. It also means proliferation of many packaged rpms to varying standards, with risk of dependency problems and breakage in users openSUSE systems, who add unsupported private repositories without understanding the risk. A way forward is needed to help both the private packagers and the community in using any newly available packages where appropriate, and not using them where not appropriate for use. A way forward start (but not the final answer) would be an automatically (on a regular basis) generated list posted on a web page/site, that would list all build service repositories, with a comment/descriptive field that the build service packager is required to fill in. A recommend field could be an indication as to their planned future support for any package (ie "one of package" for private use, or "temporary package for TBD time frame", or "planned for long term support", or "packaged for private testing" ... ) etc ... With this automatically generated/re-generated list in place, openSUSE users could go to the list to help them assess if they should download and install an rpm from a repository, or indeed if they should add the repository to their software package manager's repository list. -- openSUSE Feature: https://features.opensuse.org/308469

1 5

[New: openFATE 310940] Mumble into Distribution
by fate_noreply＠suse.de 20 May '11

20 May '11

Feature added by: Karl-Thomas Schmidt (genau-danben-denken) Feature #310940, revision 1 Title: Mumble into Distribution openSUSE-11.4: Unconfirmed Priority Requester: Desirable Requested by: Karl-Thomas Schmidt (genau-danben-denken) Partner organization: openSUSE.org Description: Mumble, a groupchat system, should go into next Release. It could improve the support. A testchannel "openSUSE" is alreday set up at "openMafia.org". Working repos exist at buildservice. -- openSUSE Feature: https://features.opensuse.org/310940

1 5

[New: openFATE 310897] drop support for /etc/cryptotab
by fate_noreply＠suse.de 17 May '11

17 May '11

Feature added by: Ludwig Nussel (lnussel) Feature #310897, revision 1 Title: drop support for /etc/cryptotab openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: Until 10.2 yast used /etc/cryptotab (note the 'o') to configure loop mounted crypto containers. 10.3 introduced support for /etc/crypttab which is based on dm-crypt. Entries in /etc/cryptotab still worked but were set up using dm-crypt instead. Now, three years later this is still the case. It's time to drop support for the old /etc/cryptotab and use /etc/crypttab only instead. -- openSUSE Feature: https://features.opensuse.org/310897

1 6

[New: openFATE 311177] RE-Evaluate the Kernels Cache Buffers and all Associated Caching Processes
by fate_noreply＠suse.de 15 May '11

15 May '11

Feature added by: Scott Couston (zczc2311) Feature #311177, revision 1 Title: RE-Evaluate the Kernels Cache Buffers and all Associated Caching Processes openSUSE.org: Unconfirmed Priority Requester: Desirable Requested by: Scott Couston (zczc2311) Partner organization: openSUSE.org Description: I am going to try to suggest the unthinkable - so please bear with me. Over a 3 year period I have watched the utilisation of physical RAM on two X64 PC's. One has 8GIG of RAM the other 4GIG of RAM. I'll just copy and paste the information to make it easier. ************************************************* Total memory (RAM): 7.8 GiB Free memory: 4.5 GiB (+ 2.8 GiB Caches) Free swap: 42.6 GiB ************************************************* Total memory (RAM): 4.9 GiB Free memory: 1.6 GiB (+ 2.3 GiB Caches) Free swap: 66.5 GiB ************************************************** Firstly, I am not going to ever suggest that any change be made to ANY caching algorithms or other O/S dependencyâs, that require the utilisation of VM. Virtual RAM comes into play with its own costs of slowing everything down. The notion of needed more Disk I/O's to stop a hungry application from issuing an 'Insufficient Memory" warning is out of the question I believe. Yes the additional Disk I/O's do allow any application to run, but they are done at the expense of competing with Disk I/O's for file retrieving and storage of application executables code and in essence slow everything down! VM is never a desirable situation and competing for Disk I/O slows everything down - Its not rocket science. What I do see over time in the 4GIG of Physical RAM is better utilised in caching algorithms, but none the less leave an enormous pool of Physical RAM available, even under the highest application load. What I see over time in the 8GIG of Physical RAM is a huge pool of available RAM that sits there and never gets utilised. The 8GIG example may as well only have 4GIG as the presence of a higher value of Physical RAM go to waste as it is never used. This pool of available physical RAM is totally wasted, I believe, and offers no performance enhancing characteristics as the abundant pool remains untouched by any caching buffers and their dynamic allocation does not exist. Rather than reinventing the wheel I have the following suggestion which may very well kill this request completely or make it far more difficult to re-invent the wheel. I have had a very long period of exposure to Netwareâs File Servers' dynamic allocation of Physical RAM and its complexities have been well honed over may years. If we can just use the dynamic allocation of caching, turbo FAT, and TTS services we are almost 90% of the way there. I do agree that the Linux TTS Services are already very strong and possible need no attention. The dynamic changes to the utilisation of ALL the Physical RAM on any Linux O/S Kernel could well do to look at how we dynamically respond when there is abundant Physical RAM present.. Your comments are very very very most welcome as I am starkly aware that suggesting this feature is so very very huge and a difficult task at an Annalists point of view let alone the programmers point of acceptance for changes in huge amounts of code. However I am prepared to run it up the flag poll and see who salutes...:-) Lastly I hope my CR stay fast so as to not ruin the layout.. . -- openSUSE Feature: https://features.opensuse.org/311177

1 14

[openFATE 306979] Increase Installing/Update speed (concurrency)
by fate_noreply＠suse.de 15 May '11

15 May '11

Feature added by: Jörn Knie-von Allmen (Phisiker) Feature #306979, revision 1 Title: Increase Installing/Update speed (concurrency) openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Jörn Knie-von Allmen (phisiker) Description: Solution: Download and Installing in separate processes/threads. So, while installing, the download of the next package can be done (or even partially done). Waiting for terminating the intallprocess of the previous package before to download the next package makes no sense. (Every time when upgrading, this ist annoying). -- openSUSE Feature: https://features.opensuse.org/306979

1 3

[openFATE 307620] Parenta Control
by fate_noreply＠suse.de 11 May '11

11 May '11

Feature added by: J Thimm (thimm) Feature #307620, revision 1 Title: Parenta Control openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Package Wishlist: Unconfirmed Priority Requester: Mandatory Requested by: J Thimm (thimm) Description: I would love to see a parental control feature (with GUI) that allows families -- to use the OS by kids. Parental Control features: - easy configurable and usable This should be compulsory -- because how do you want to educate the youngsters to use the interne? Currently parents cannot "easily" administer such features -- one has to be a professional to get this to work!! I would rather let my kids use Windows because of this -- since there are a number of program do do this job! Am I wrong? Thanks -- openSUSE Feature: https://features.opensuse.org/307620

1 4

[New: openFATE 309579] Dependency tree in zypper summary
by fate_noreply＠suse.de 11 May '11

11 May '11

Feature added by: Ján Kupec (jkupec) Feature #309579, revision 1 Title: Dependency tree in zypper summary Requested by: Ján Kupec (jkupec) Partner organization: openSUSE.org Description: Visualize dependencies of packages (from the installation summary or given on command line) using colored (by type of dependency - recommends, requires, etc) ASCII tree/graph. The feature can be enabled in the info command (zypper info --dep-tree package) and in the installation summary prompt (in which case it would show the graph from the requested packages via all the to-be-installed ones, ending with the installed ones). This feature is meant to be kept simple, and leave more complex analysis to other tools (FATE 309572). Business case (Partner benefit): openSUSE.org: Visualization of package dependencies in a tree makes it easier for packagers to spot incorrect/unneeded dependencies and manage systems, save space, or analyze dependency problems for administrators and users. -- openSUSE Feature: https://features.opensuse.org/309579

1 2

[openFATE 306116] Better lock handling in zypper
by fate_noreply＠suse.de 06 May '11

06 May '11

Feature added by: Marek Stopka (m4r3k) Feature #306116, revision 1, last change by Title: Better lock handling in zypper openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Marek Stopka (m4r3k) Description: Currently only two states in locking of packages are available (keep package as is/do not care about package) but I think it would be much more better to have a possibility lock only some parameters of package... For example you have a 64bit machine, but you want keep some package always in i586 version, but you still wanna version updates in this case there should be a possibility to lock only this parameter. Of course there is a lot of options what else can be locked, for example version of package, meaning that you can't change package version, but release number can change... -- openSUSE Feature: https://features.opensuse.org/306116

1 12