November 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 306667] Include Ramlog application
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Glenn Doig (doiggl) Feature #306667, revision 1 Title: Include Ramlog application openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Glenn Doig (doiggl) Description: See article Improve system performance by moving your log files to RAM http://www.linux.com/feature/141231 (http://www.linux.com/feature/141231) http://tofu3.szm.sk/ramlog/ (http://tofu3.szm.sk/ramlog/) (Some info) The Ramlog project lets you keep your system logs in RAM while your machine is running and copies them to disk when you shut down. If you are running a laptop or mobile device with syslog enabled, Ramlog might help you increase your battery life or the life of the flash drive on your mobile device. As a side effect of using Ramlog, you will be less likely to be caught out by a daemon that suddenly starts sending a message to syslog every 30 seconds and saps your battery keeping the hard disk spinning. Rpm: http://tofu3.szm.sk/ramlog/1.1.0/rpm/ramlog-1.1.0-1.noarch.rpm (http://tofu3.szm.sk/ramlog/1.1.0/rpm/ramlog-1.1.0-1.noarch.rpm) Thankyou -- openSUSE Feature: https://features.opensuse.org/306667

1 3

[openFATE 306324] Improvements to Failsafe mode
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Rajko Matovic (rajko_m) Feature #306324, revision 1, last change by Title: Improvements to Failsafe mode openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Rajko Matovic (rajko_m) Description: Currently when kernel fails to load, user can only give up on installing openSUSE. Failsafe mode can help sometimes, but load of kernel parameters can introduce problems later. Knoppix offers alternatives that may work on particular hardware without going trough process of discovery of proper kernel parameters, and it has help pages available right from the boot screen. Both combined make booting possible with very little to no experience in kernel issues. -- openSUSE Feature: https://features.opensuse.org/306324

1 5

[openFATE 306902] Scripts by the users
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Jan Gerrit Marker (JanGerritJose) Feature #306902, revision 1 Title: Scripts by the users openSUSE-11.3: Unconfirmed Priority Requester: Neutral Requested by: Jan Gerrit Marker (jangerritjose) Description: There some problems which could be solved easily by shell scripts (like deleting plasma-appletsrc if something is wrong with plasma). But nobody knows it and suddenly there are 10 questions about problems with Plasma in 10 forums which all could be fix by deleting plasma-appletsrc. There could be a webinterface where users could upload their scripts. There would be a description of the actions of the script and the problem, they try to fix. Users could use a YaST module to search for a script which fixes the problem, download it and execute it. There could be a voting system about the scripts: solved the problem fast, not so fast, did something wrong and so on. To ensure that the scripts don't destroy the system there could be two categories: "Tested", "Untested". Trustable openSUSE-Members could move the scripts from "Untestes" to "Tested". Or, if there are a lot of good votes for the script, the script would be moved automatically. -- openSUSE Feature: https://features.opensuse.org/306902

1 3

[openFATE 307376] On-the-fly encrypting/decrypting filesystem
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Patrick Weimer (smoovn) Feature #307376, revision 1 Title: On-the-fly encrypting/decrypting filesystem openSUSE-11.2: Unconfirmed Priority Requester: Desirable openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Patrick Weimer (smoovn) Description: I'm searching for a on-the-fly encryption for my /home/ partition. Maybe its a good feature for OpenSuSE itself? -- openSUSE Feature: https://features.opensuse.org/307376

1 5

[openFATE 306666] Complete remove-install-update with zypper
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: James Carter (jimc_uclamath) Feature #306666, revision 1 Title: Complete remove-install-update with zypper openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: James Carter (jimc_uclamath) Description: This is a feature request for zypper-1.0.9-0.1.1 in OpenSuSE 11.1. Obviously the improvements would go into a future SuSE release. In my use case, I have 0.5 FTE to spend on system administration of about 120 researchers' workstations and compute nodes running OpenSuSE. My goals involving zypp in order of frequency of occurrence are: apply security patches; install or remove software according to particular research groups' needs; deploy new machines that have no OS on the disc; and upgrade every 18 months to a new distro version. To accomplish these tasks I need to minimize hand labor in package management. What am I trying to accomplish in package management? Software which is not wanted on a machine should be removed if present, and software which is wanted should be installed if absent, plus dependencies, or upgraded to the latest patch version. I suspect that quite a lot of SuSE users, not just me, would like a package management program which could enforce a locally created pattern, automatically removing, adding and updating packages as needed. Back in SuSE 8.2, rug and zypper/libzypp being in the future, I wrote a perl script to make these goals happen. When zypper first came out I investigated it but found it lacking; the lack of a "dry run" (-D) switch precluded testing. But now with the 64bit x86_64 architecture, and with dependencies involving components and version relations, my script is not flexible enough. I again investigated zypper. With the features now present, specifically the -D (dry run) switch, zypper can now do part of my job if shepherded by a lot of supporting scripting. I would like to list features which would make it useful for the whole job. 1) In rare but important cases we need to blacklist or "hold back" updates. Debian has this feature, and even Microsoft Windows can do it. 2) Zypper should have a "negative removal" mode, that is, rather than listing all the packages you want to remove, you list all the packages you want to keep. Zypper will add all their dependencies, and the non-listed packages (including their exclusive dependencies) will be removed. (My new script uses kludge techniques with rpm, not zypper, to do this calculation, but it's hard and time-consuming, 0.125 second per installed package, to deal with dependencies.) 3) Zypper should have an option to be silent about packages already installed. In other words, you list all the packages you want on the machine, and it installs the missing ones, if any. My new script excludes installed packages from the list of wanted packages before feeding the remainder to zypper, but zypper internally could do this much more neatly. 4) I assume that if I take a back-version machine and trick zypper into orienting on a new distro version, it will recognize that a new version is available for every package and take action accordingly. The distro version (and architecture: changing i586 to x86_64) should be selectable on the command line. 5) The YaST installer downloads a package, then installs it, then repeats. (Or perhaps downloading and installation are smartly overlapped.) Zypper should do the same thing, not requiring disc space for every affected package at the same time. To check that all packages can be downloaded, it can do HEAD requests at the start. There should also be a command line option to not be anally retentive about missing packages: if a transient failure prevents downloading, always retry the package (and those requiring it) later, and if the failure is permanent, install as much as you can, don't die on the spot like zypper presently does. 6) Zypper should install packages in dependency order, so if a failure interrupts the process the machine has no missing dependencies, even if wanted packages are missing. I don't know if zypper already does this. The YaST installer, which I assume is based on libzypp, is seen to install aaa_base kind of in the middle of the set of packages, which leads me to bring up this point. 7) Zypper should have options to remove, install or replace packages itself like it does now, but it should also be able to emit a list or table of affected packages that can be postprocessed before installation or removal. For removal this would be package full names; for installation it would be URLs in the repositories (with an option for plain file names instead of file:/// URLs); for updates both items are needed. It would help in a lot of postprocessing situations if you could optionally ask for the package basenames to be prepended as another field; e.g. if the full name is "zypper-1.0.9-0.1.1" the basename is "zypper". Also helpful in setting up the list of wanted packages would be a separate table of dependency relations, e.g. when the output says "AA BB" it means that package AA is required by package BB. Machine readable format is important; you might make an option to pick tabular output or English texts. In my new script to get dependencies I do "rpm -e --test $pkg" and then parse the English output, which is a crock, takes a lot of time, and is unreliable if you ever "improve" the texts. 8) Wherever a list of thousands of packages or URLs can appear on the command line, zypper should also be able to read these from a file. If either kind of list turns up with zero packages, zypper should shut up and install each of them, same as if one or more packages are on the list. 9) Likely zypper already determines the product, version and architecture from /etc/SuSE-release, but there are so many variants of the first line that it's a crock to parse it. Presently you give "VERSION = 11.1" in the second line (with blanks); I would suggest also giving the PRODUCT and ARCH, and without blanks so in a shell script one can do eval `grep '=' /etc/SuSE-release` rather than dumbly using "tr" to make the blanks go away. 10) Likely it is possible to use the Python binding of libzypp to easily write a wrapper script that easily does all of the above requests. (I prefer Perl; can we have that language binding also?) However, I was not able to find documentation to even get started, i.e. to specify the repositories and a list of packages. So my new script reeks of kludges and fails to use zypper (libzypp) for the most important steps. My final request is for documentation on libzypp that I can use for projects of this kind. Related FATE tickets: * 300758 (../300758) : Show orphan packages (rejected in v11.1). Also 306627 (../306627) , a duplicate with a better use case description. * 302159 (../302159) : Only download packages (rejected in v11.1). Just give me the list of URLs; I'll download them on my home DSL connection, distribute on the home net, and then do rpm -F *.rpm. * 305634 (../305634) : Distro version upgrade from the command line using zypper. Hear, hear! My old script could do this. -- openSUSE Feature: https://features.opensuse.org/306666

1 1

[openFATE 307837] OpenLDAP Modules and Overlays
by fate_noreply＠suse.de 12 Nov '10

12 Nov '10

Feature added by: Dieter Kluenter (dkluenter) Feature #307837, revision 1 Title: OpenLDAP Modules and Overlays Package Wishlist: Unconfirmed Priority Requester: Desirable Requested by: Dieter Kluenter (dkluenter) Description: Up to now, all Overlays of OpenLDAP are statically build in. I would like to request to build Overlays and some backends as Modul. -- openSUSE Feature: https://features.opensuse.org/307837

1 2

[openFATE 307956] Improved tftp yast module
by fate_noreply＠suse.de 09 Nov '10

09 Nov '10

Feature added by: Birger Kollstrand (MrKane) Feature #307956, revision 1 Title: Improved tftp yast module openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Birger Kollstrand (mrkane) Partner organization: openSUSE.org Description: Goal: To facilitate an even smoother setup of an installation server where clients can be installed wia ethernet. Suggested solution: The Yast tftp module or the yast Install server module is added a ppossibility to edit the pxelinux etherboot setup. For the first iteration text editing of the "default" config file in pxelinux.cfg is added. The second iteration will add the new builds loaded into the Installtion servers to the "default" config file in pxelinux.cfg and copy the initrd and the linux file to the correct location. I prefer to have them under separate directories under /srv/tftpboot. Sample configuration files can be obtained from me. Use Case: Facilitate easy setup of a complet installation server with distros delivered by ftp/http and the initial boot process handled through tftp. This removes the need for a separate boot disk, memory stick etc. Business case (Partner benefit): openSUSE.org: It makes it way easier to setup a large environment where a number of machines needs to be installed with a SuSE version. It makes it really easy to test on different versions of openSUSE, SLES etc. especially when combined with autoyast. A complete re-installation is done in a few minutes. -- openSUSE Feature: https://features.opensuse.org/307956

1 1

[New: openFATE 308289] Dedicate More third party support
by fate_noreply＠suse.de 08 Nov '10

08 Nov '10

Feature added by: Gary Pikula (shadoweva09) Feature #308289, revision 1 Title: Dedicate More third party support openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Gary Pikula (shadoweva09) Partner organization: openSUSE.org Description: All of the desktop Linux distributions could definitely benefit from better third party software support. The case right now is that a company may decide to dedicate resource to make their software Linux compatible, but likely will only dedicate enough resources to make it .rpm, .deb, or .tar.gz packages and nothing else because of the small market share. They also don't want their software being hosted in repository servers and keep control over distribution. I know the politics usually go that the should use our package format and our repositories, but they don't and certain reasons come up that make it impossible to do so (like Skype needing to protect their phone bills). Since they didn't use the format the user has, the user has to do all the work getting it to work and they suffer. Use Case: A user is using a distribution that uses rpm install files and needs to install commercial software to connect to their school's application server. The company that makes the software only dedicated enough resources to make the debian package. The user now has to install and learn to use special software to make the client software work. If there was a special way of handling Third party software that businesses were encouraged to use and all desktop Linux distributions supported that way of software management the users would not suffer, and business would not have to choose between which package format to allocate project funds for. Business case (Partner benefit): openSUSE.org: To put an end to the second rate treatment of software that's not in repositories, make the user experience much better for people using third party software, and reduce costs for companies developing software for desktop Linux by eliminating the need to create multiple packages. -- openSUSE Feature: https://features.opensuse.org/308289

1 4

[openFATE 307787] Protection against modifying of system libraries
by fate_noreply＠suse.de 08 Nov '10

08 Nov '10

Feature added by: Mircea Kitsune (MirceaKitsune) Feature #307787, revision 1 Title: Protection against modifying of system libraries openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Mircea Kitsune (mirceakitsune) Description: A few days ago I made a mistake that caused me to brake my KDE and Linux installation. Although the fault was mine, I believe OpenSuse should have a protection against dangerous system changes or at least signal the user clearly when a change to system packages could damage important components. What I did was upgrading Pidgin messenger from version 2.5.1 to 2.6.2, but selecting the 32bit version from the repositories instead of the 64bit one (the installed 2.5.1 was the correct 64bit version). I didn't realize it and Yast replaced KDE and system libraries with 32bit versions, ripping the install apart. OpenSuse did not notify me that I would replace and brake system components, and everything appeared like a normal installation. Although I learned from my mistake and should have better reviewed the list of changes, I believe OpenSuse should have not allowed such a change rather than letting it seem like a normal installation. This is dangerous for new users who may not be aware of such dangers and only learn after braking their first OpenSuse install. Test Case: On a 64bit version of OpenSuse 11.1 KDE4 which has Pidgin 2.5.1-x.x-x86_64 installed: 1 - Open Yast -> Software Management, and add the following repository in Configuration -> Repositories: http://download.opensuse.org/repositories/GNOME:/Factory/openSUSE_11.1/ 2 - Refresh it then return to the search screen and search for Pidgin. Select pidgin from the packet list and in the Versions tab below select "2.6.2-x.x-i586 from gnome-repo" and click Accept. 3 - A conflict window will appear, mentioning you can either take some actions to resolve the conflict, not install pidgin, or ignore some of its dependencies. Under "Following actions will be done" there is a "369 more" list which includes important system libs that would be changed with 32bit versions. 4 - If the user is a Linux beginner and has commonly avoided such conflict windows, he may not give enough attention to this nor realize he has selected the i586 version and choose to replace the libraries. Once installation is done KDE and Linux core components are broken and the OpenSuse installation damaged. This is an example screenshot (I have the correct version of 2.6.2 already installed, consider it's 2.5.1-x86_64 at the top): http://img27.imageshack.us/img27/9106/installg.jpg -- openSUSE Feature: https://features.opensuse.org/307787

1 9

[openFATE 307551] Booting Live OS from a USB drive
by fate_noreply＠suse.de 08 Nov '10

08 Nov '10

Feature added by: Ben Metzner (Bman22) Feature #307551, revision 1 Title: Booting Live OS from a USB drive openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Ben Metzner (bman22) Partner organization: openSUSE.org Description: I think it would be great to allow for a live session to be run via a usb key. Almost every live distro i know supports it as a feature, and even a lot of non-live-specific distro's have the option to run live from a usb key. If this could be incorperated in 11.2, or 11.3, it would be great. Just providing an ISO file to image to a usb drive would be great, seeing as the current images won't boot from a usb key. Use Case: Somebody who wants to be able to easily carry around multiple linux distrobutions, and boot them from a usb drive, or memory card reader in their computer. Business case (Partner benefit): openSUSE.org: I want this specifically so i can image some sd cards with my favorite distro's (OpenSuSE obviously being one of those), and just reboot the computer with a different sd card when i want a different distro, instead of having to carry around multiple cd drives, as well as an external cd player for my netbook. -- openSUSE Feature: https://features.opensuse.org/307551

1 7