April 2012 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 310695] boot with gag or similar by default
by fate_noreply＠suse.de 28 Oct '13

28 Oct '13

Feature added by: pier andre (pier_andreit) Feature #310695, revision 1 Title: boot with gag or similar by default openFATE: Unconfirmed Priority Requester: Desirable Requested by: pier andre (pier_andreit) Description: dear developers, I'm a user, simple user, not advanced or power, only simple, one of the problem of a user like me is the bootloader, as simple wannabe better users usually do I have a double or triple boot pc, the first is windows becouse my fear to have a pc which cannot use some software, the second is suse linux with stable repository becouse I would like to learn and work with it and the third is suse linux factory updated becouse my curiosity to try new software is big but the fear to have a system crapped exist. Sometimes happen that I have to reinstall some operative system or I would like to try another distribution, this turn me in a dark tunnel about bootloader, where to install it, which install, does windows and suse restart again? in the past happened the mess :-). Why don't adopt by default a software like this or similar or the idea? GAG, the Graphical Boot Manager (http://gag.sourceforge.net/) it could be improved and installed in a its own separate little partition, it will eliminate the doubt and the choice on where and which bootloader to install, installing the grub or lilo or other in the partition where the new installation is performed and gag in his own dedicated partition. thanks of any attention Pier -- openSUSE Feature: https://features.opensuse.org/310695

1 4

[openFATE 306960] support update of systems with encrypted physical volumes
by fate_noreply＠suse.de 28 Oct '13

28 Oct '13

Feature added by: Arvin Schnell (aschnell) Feature #306960, revision 1 Title: support update of systems with encrypted physical volumes openSUSE-11.3: New Priority Requester: Mandatory Requested by: Arvin Schnell (aschnell) Description: Since openSUSE 11.2 can install systems with encrypted physical volumes (see fate #305633) openSUSE 11.3 must be able to update such systems. -- openSUSE Feature: https://features.opensuse.org/306960

1 14

[openFATE 307745] Let the admin ("root") download and install untrusted third-party RPMs from known URLs guided via YaST
by fate_noreply＠suse.de 24 Oct '13

24 Oct '13

Feature added by: Johannes Meixner (jsmeix) Feature #307745, revision 1 Title: Let the admin ("root") download and install untrusted third-party RPMs from known URLs guided via YaST openSUSE-11.3: New Priority Requester: Neutral Requested by: Johannes Meixner (jsmeix) Description: I would like to have it evaluated whether or not it is allowed to implement a dialog in YaST which lets the system admin (i.e. "root") download and install untrusted third-party RPMs from known URLs. In any case "root" can download and install any software manually. This reques is about to provide a guided and restricted way for some particular cases. My current use-case are the printer driver packages which are available via OpenPrinting at the Linux Foundation: http://www.openprinting.org/driver_list.cgi where LSB compliant driver RPM packages are available. >From my point of view those packages are on the one hand untrusted third-party RPMs but on the other hand their download location is "well known" which makes those packages "well known third-party packages". I assume that from a strict security point of view any kind of third party software is "strictly forbidden" but I like to propose a more useful way here: The system adminj (i.e. "root") can in any case download and install whatever software he likes. This man invalidate e.g. whatever support contract but it is up to the admin to know what he does. Currently we have no idea at all which third-party printer drivers an admin may download an install on his own. When he has a printer for which there is no driver provided by us, the admin may download whatever driver software from any totally unknown location and install it with any unknown consequences. (E.g. some time ago there was a printer driver from a printer manufacturer where its installation script set setuid root bits on various user application programs to mak it "just work".) Currently we even do not tell the admin about the well known printer driver locations at OpenPrinting. >From my point of view it would be a big improvement when I could implement a dialog in the YaST printer module which shows a very explicite text that this is about untrusted unsupported third-party software. This text would require explicite confirmation by the admin. Then it downloads RPMs only from hardcoded URLs from OpenPrinting and inspects the downloaded RPM whether it overwrites already installed files on the system and if not, it installs it without running any RPM scripts because normal printer drivers do not need to run RPM scripts during installation. If the above conditions are not fulfilled it shows a very explicite warning text and does not install anything. In contrast to now where we leave the admin totally on its own how to get a driver for a printer for which we do not provide a driver, the above described guided and restricted way to download and install drivers via YaST would help both the admin and us because in many cases we could make sure this way that we know at least which third-party driver the admin has installed. Please do not confuse this request with the different request how a third-party (e.g. OpenPrinting or a printer manufacturer) could provide software packages in a way which is in full compliance to our package installation and management tools (i.e. via a repository which provides also updates and so on). This request is meant for third-party RPMs "as is" where the vendor/provider simply does not want (because of whatever reason which is beyond our control) to provide his RPMs in compliance to our package installation and management tools. -- openSUSE Feature: https://features.opensuse.org/307745

1 9

[New: openFATE 311338] YaST debconf Module
by fate_noreply＠suse.de 13 Oct '13

13 Oct '13

Feature added by: Lars Vogdt (lrupp) Feature #311338, revision 1 Title: YaST debconf Module openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Lars Vogdt (lrupp) Partner organization: openSUSE.org Description: Currently, people installing RPM packages have no opportunity to configure the installed applications afterwards with openSUSE Tools - if there's no specialized YaST module. This is a disadvantage comparing to Debians debconf system, allowing packagers (and therefor endusers) asking the user certain configuration questions after installation. Goals * A first part will be a GUI reading currently availble debconf templates and displaying them as expected. Please have a look at the debconf specifications for this. * If this proof of concept works, there's a need for support of such templates in RPM. We need a general policy describing how RPM packagers can include such template files in their packages. This would give openSUSE the great benefit of helping Debian people to migrate to openSUSE - and (more important) allows packagers to allow users customizing their installation without writing special YaST modules. Scope Remember that debconf doesn't cover all configuration aspects of any application. It should be enough to ask some general informations so that an application is ready for usage afterwards. A fine granulary configuration should been done by hand - or the according YaST module. Related technologies Tools that interact : * libzypp * mod_ui (YaST) * rpm Typical use case In the end, a user should be able to install a package like MySQL - and configure main parts of his new application using the YaST debconf module. Also think about packages for applications using a database, such as web based applications like horde, moodle and so on - currently, the user has to create the needed database manually. The YaST debconf module could ask for the location of the database server, the database name, the username, ... - and use this informations to set everything up so a user can login to his application right afterwards. Business case (Partner benefit): openSUSE.org: debconf is a software utility for performing system-wide configuration tasks on Unix-like operating systems. It is developed for the Debian GNU/Linux distribution, and is closely integrated with Debian's package management system, dpkg. When packages are being installed, debconf asks the user questions which determine the contents of the system-wide configuration files associated with that package. After package installation, it is possible to go back and change the configuration of a package by using the dpkg-reconfigure program, or another program such as Synaptic. The design of debconf allows for front-ends for answering configuration questions to be added in a modular way, and there exist several, such as one for dialog, other for readline, one for editor, one for KDE, one for GNOME [1], a Python front-end API, etc. There are two differnent goals for openSUSE: * Add some kind of "debconf" support to RPM * Create a YaST Module as front-end -- openSUSE Feature: https://features.opensuse.org/311338

1 3

[New: openFATE 310455] list packages that trigger build
by fate_noreply＠suse.de 08 Oct '13

08 Oct '13

Feature added by: William Brenneman (eocrates) Feature #310455, revision 1 Title: list packages that trigger build Buildservice: Unconfirmed Priority Requester: Desirable Requested by: William Brenneman (eocrates) Description: I have packages that use the openSUSE_Factory repo, and periodically a required package will be updated in the repository that triggers my packages to be rebuilt. Suggection: list what package (and version # => version #) in Commit History of my package that triggered my package to rebuild. -- openSUSE Feature: https://features.opensuse.org/310455

1 10

[New: openFATE 312816] Continuous YaST Testing in Jenkins
by fate_noreply＠suse.de 04 Oct '13

04 Oct '13

Feature added by: Lukas Ocilka (locilka) Feature #312816, revision 1 Title: Continuous YaST Testing in Jenkins Hackweek VII: Unconfirmed Priority Requester: Important Requested by: Lukas Ocilka (locilka) Partner organization: openSUSE.org Description: Continuous testing in Jenkins is widely used by several projects, such as: libzypp, slms, studio... to find issues ASAP, but YaST still lacks this possibility. Jenkins URL: http://river.suse.de/ More info on the subject can be found at this thread: http://lists.opensuse.org/yast-devel/2011-06/msg00096.html -- openSUSE Feature: https://features.opensuse.org/312816

1 1

[New: openFATE 309679] YaSTroid
by fate_noreply＠suse.de 04 Oct '13

04 Oct '13

Feature added by: Jared Allen (jpallen) Feature #309679, revision 1 Title: YaSTroid Requested by: Jared Allen (jpallen) Description: YaSTroid - An Android phone application to manage your SLES server using the WebYaST back-end. -- openSUSE Feature: https://features.opensuse.org/309679

1 14

[New: openFATE 309768] Blobec: Git with GPG on FTP
by fate_noreply＠suse.de 04 Oct '13

04 Oct '13

Feature added by: Martin Vidner (mvidner) Feature #309768, revision 1 Title: Blobec: Git with GPG on FTP Requested by: Martin Vidner (mvidner) Description: Blobec is a tool to store my private information (diary, calendar) on the Net to increase its availability and redundance. * To preserve privacy it needs to be encrypted → GPG. * I want it to be versioned, with easy merging of diverged copies → Git. * The publishing part works with what my current ISP provides → FTP (with SSL). I am implementing it in Ruby, with cURL. -- openSUSE Feature: https://features.opensuse.org/309768

1 4

[New: openFATE 312825] Objects in YCP (YaST)
by fate_noreply＠suse.de 04 Oct '13

04 Oct '13

Feature added by: Martin Vidner (mvidner) Feature #312825, revision 1 Title: Objects in YCP (YaST) Hackweek VII: Unconfirmed Priority Requester: Important Requested by: Martin Vidner (mvidner) Partner organization: openSUSE.org Description: As I am thinking about refactoring the network code, not having objects in YCP is a pain. The twist is, I don't want to add YCP objects but use Ruby objects. (We can already use Perl objects, yast2-storage does it, but it's limited.) Here's sample code to show how it could look, modeled after http://www.ruby-doc.org/stdlib-1.8.7/libdoc/uri/rdoc/classes/URI.html { import "Assert"; // Yes, you can! (also in SP2) // http://svn.opensuse.org/viewvc/yast/trunk/yast2/library/modules/Assert.ycp?… // Original Ruby code: // require 'uri' import $[ "what": "uri", "language": "ruby", "namespaces": ["URI", "URI::HTTP"] ]; /* The above complicated syntax enables - loading modules from elsewhere than /usr/share/YaST2/modules - loading YCP namespaces (Ruby modules (classes)) named otherwise than the file they are in, without needing to annotate them with TYPEINFO (like perl-bindings/pluglib-bindings do) */ // uri = URI.parse("http://www.ruby-lang.org/") any uri = URI::parse("http://www.ruby-lang.org/"); // [1] // assert_equal "http", uri.scheme Assert::Equal("http", uri->scheme()); // newuri = URI::HTTP.build( {:host => 'www.example.com', :path => '/foo/bar'}) any newuri = URI::HTTP::build($[ `host: "www.example.com", `path: "/foo/bar"]); // assert_equal "http://www.example.com/foo/bar", newuri.request_uri Assert::Equal ("http://www.example.com/foo/bar", newuri->request_uri()); } Formally, whereas now YCP has NAMESPACE :: IDENTIFIER ( PARAMS ) which calls a function (a module/class method in Ruby, a class method in Perl), we add EXPRESSION -> IDENTIFIER ( PARAMS ) which calls a method (an instance method in Ruby. [1] "any" is a lie, the type is actually a distinct one, called YCPExternal in C++. We could use "extern" which is currently an unused reserved word in YCP. But URIs are not my target. I am aiming for { any eth = SUSE::Ifcfg::new("eth0"); any br = SUSE::Ifcfg::Bridge::new("br0"); br->startmode(`auto); br->add(eth); /* br->add will also set: eth->bootproto(`none); eth->startmode(br->startmode()); */ any tap = SUSE::Ifcfg::Tap::new("tap0")->tunnel_set_owner("tux"); br->add(tap); foreach(any i, [br, tap, eth], { i->save(); }); } if (you->are_interested()) { you->please()->tell(martin); } -- openSUSE Feature: https://features.opensuse.org/312825

1 3

[New: openFATE 308958] Reduce size of the Minimal Install
by fate_noreply＠suse.de 22 Sep '13

22 Sep '13

Feature added by: Jan Engelhardt (jengelh) Feature #308958, revision 1 Title: Reduce size of the Minimal Install openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Jan Engelhardt (jengelh) Partner organization: openSUSE.org Description: IMHO, the text-mode minimal install without X and anything still comes with "too many" packages. I use the minimal selection whenever I need to set up a new, clean, system, as installing onto a Minimal is faster than cherry-picking every single package for deletion from a Medium or Maximum selection. This includes, but is not limited to: * documentation to magic things happening in the background: PolicyKit-doc, readline-doc * other documentation that I've probably read already; bash-doc, perl-doc * archaic systems: yp-tools ypbind yast2-nis-client * packages serving no purpose: perl-Business-ISBN (heck, not even yast needs that), perl-GD * things that make my command line slow: command-not-found scout * it so happens that eventually I can throw out the entire python stack, and the remaining Xorg libs * printing, sound, bootsplash I have here a dump file between the initial minimal install and a tailored system - some things have been removed that I would leave on the minimal install list however (e.g. yast2-sudo). So the raw contents of the diff file is [mh, FATE has no attachments - see https://bugzilla.novell.com/show_bug.cgi?id=577791 ] Business case (Partner benefit): openSUSE.org: Everytime a new system is bootstrapped, I have to (="want to") remove these first because they will never be needed -- if they will, I can reinstall them later, or pick a larger "non-minimal" text mode from yast. -- openSUSE Feature: https://features.opensuse.org/308958

1 3

[New: openFATE 313142] YaST support only SSSD for LDAP based authentication
by fate_noreply＠suse.de 05 Sep '13

05 Sep '13

Feature added by: Ralf Haferkamp (rhafer) Feature #313142, revision 1 Title: YaST support only SSSD for LDAP based authentication openSUSE Distribution: Unconfirmed Priority Requester: Mandatory Requested by: Ralf Haferkamp (rhafer) Partner organization: openSUSE.org Description: We should remove support for nss_ldap and pam_ldap configuration from the YaST ldap-client module (note: this is not a request to remove nss_ldap and pam_ldap from the distribution) and only support SSSD for LDAP based users authentication. The nss_ldap and pam_ldap packages should still be part of future distribution to still allow manual setup. When updating an nss-/pam_ldap based system from an older release it should stay with nss-/pam_ldap. Upon first startup of yast2-ldap-client it might offer a migration to sssd. Business case (Partner benefit): openSUSE.org: Focussing on a single implementation for LDAP authentication allows us to provide a cleaner UI and should reduce the complexity of the YaST ldap-client module considerably. Making it easier to use and maintain. -- openSUSE Feature: https://features.opensuse.org/313142

1 9

[openFATE 306974] Additional columns in software management
by fate_noreply＠suse.de 03 Sep '13

03 Sep '13

Feature added by: Todd R (TheBlackCat) Feature #306974, revision 1 Title: Additional columns in software management openSUSE-11.2: Unconfirmed Priority Requester: Desirable openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Todd R (theblackcat) Description: It would be nice if there were a few additional columns in the software management interface. One specific column I am interested in would be an architecture column, to show you the architecture of an installed package or the architecture the package would have if you were to install it. The other column would show the repository of the package, either the repository of an installed package or the repository the package would be downloaded from if you were to install it. -- openSUSE Feature: https://features.opensuse.org/306974

1 6

[New: openFATE 310410] Evaluate switching to libjpeg-turbo
by fate_noreply＠suse.de 26 Aug '13

26 Aug '13

Feature added by: Vincent Untz (vuntz) Feature #310410, revision 1 Title: Evaluate switching to libjpeg-turbo openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Vincent Untz (vuntz) Description: Quoting http://fedoraproject.org/wiki/Features/libjpeg-turbo: ==== libjpeg-turbo is fork of the original libjpeg project. It contains numerous performance related enhancements and is at least twice faster in JPEG compression/decompression than original libjpeg on platforms with MMX/SSE instruction set. It has same API/ABI like original libjpeg and also runs on non-SSE platforms where is around 25% faster. http://sourceforge.net/projects/libjpeg-turbo ==== We should evaluate this library and see if we can replace libjpeg with it for improved performance. -- openSUSE Feature: https://features.opensuse.org/310410

1 8

[New: openFATE 313400] store gpg key in fs instead of rpmdb
by fate_noreply＠suse.de 19 Aug '13

19 Aug '13

Feature added by: Ludwig Nussel (lnussel) Feature #313400, revision 1 Title: store gpg key in fs instead of rpmdb openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: currently gpg keys used by rpm for signature verification apppar to be installed in the rpmdb as some kind of pseudo package (rpm -qa 'gpg-pubkey*'). This makes them rather clumsy to manage. It would be better to have gpg keys as regular files in the file system. In fact rpm supports that since a while via the %_keyringpath option. It's set to %{_dbpath}/pubkeys/ by default. If any keys are found in that directory the keys in the rpmdb are no longer used. Therefore I propose to: - change the openSUSE-build-key package to drop it's files into %_keyringpath - patch libzypp to prefer %_keyringpath too - add a %post snippet to rpm or openSUSE-build-key to export extra keys in rpmdb to %_keyringpath and remove them from rpmdb afterwards - make %_keyringpath an array so we can have distro provided keys in /usr and admin/locally configured keys in /etc -- openSUSE Feature: https://features.opensuse.org/313400

1 7

[openFATE 306598] Sync Tomboy/Tasque with Evernote
by fate_noreply＠suse.de 13 Aug '13

13 Aug '13

Feature added by: Joe Brockmeier (jbrockmeier) Feature #306598, revision 1 Title: Sync Tomboy/Tasque with Evernote Requested by: Joe Brockmeier (jbrockmeier) Description: Evernote is a pretty cool service, but it doesn't have a Linux client. I'd like to be able to sync my Tomboy notes with Evernote and retrieve them from another machine. Same with Tasque -- I'd like to be able to save a to-do list to Evernote from tasque so I could use a mobile Evernote client to look up my to-dos. -- openSUSE Feature: https://features.opensuse.org/306598

1 4

[openFATE 306588] improve on software search
by fate_noreply＠suse.de 13 Aug '13

13 Aug '13

Feature added by: Juergen Weigert (jnweiger) Feature #306588, revision 1 Title: improve on software search Requested by: Juergen Weigert (jnweiger) Description: software.o.o/search is always a case insensitive substring search. I'd like to hack into the system and add - optional case sensitivity,- exact package name search- regexp search This is an opportunity to learn ruby on rails for me. Any takers, who want to coach me, especially with Rails welcome. -- openSUSE Feature: https://features.opensuse.org/306588

1 6

[openFate 305705] Types of installation
by fate_noreply＠suse.de 13 Aug '13

13 Aug '13

Feature added by: Agustin Chavarria (dj_ubun_1) Feature #305705, revision 1, last change by Title: Types of installation openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Agustin Chavarria (dj_ubun_1) Partner organization: openSUSE.org Description: would be good, that at the time of installation opensuse, ask what you want to install, like a template, without having to go to edit to add software. An example for that will be: Multimedia install Full install server install developer install -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305705

1 12

[New: openFATE 309614] Activator application for SUSE Studio created appliances
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: Christian Hueller (chuller) Feature #309614, revision 1 Title: Activator application for SUSE Studio created appliances Requested by: Christian Hueller (chuller) Partner organization: openSUSE.org Description: Basically the idea is simple: Create an application (GUI would be nice) that can 'activate' a previously SUSE Studio built appliance. 'Activate' stands here for things like o register appliance with Novell or ISV o create users and set passwords o do other security relevant things like creating keys or add own proprietary material After the activation it would be awesome to also integrate some deployment functionality to burn isos directly to CD after activation or copy disk images to a usb stick How it might work: Basically the appliance filesystem needs to be accessed in order to modify the appliance accordingly. This could be done through either loop mounting the image or by booting it inside some hypervisor. Loop mounting requires root access, so booting might be the better solution, we only need to take care the kiwi firstboot processes do net get triggered in this activation boot. Possible features: o interaction with studio itself using its API (no manual download of the appliance e.g.) Use Case: The use case is pretty clear as this would cover the gap between the simple creation of an appliance and the frist booting of it on your hardware: The user downloads a SLES11 appliance with the 'activator', then sets the root password and enters the SLES11 registration key. Now the update repositories get added to the appliance and the password is changed without being accessible on the online server. Business case (Partner benefit): openSUSE.org: This would be a great usability improvement to the whole stusio experienc -- openSUSE Feature: https://features.opensuse.org/309614

1 2

[New: openFATE 313426] Allow vendor changes in suse studio
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: Paolo Zavarise (bicchiere) Feature #313426, revision 1 Title: Allow vendor changes in suse studio SUSE Studio: Unconfirmed Priority Requester: Desirable Requested by: Paolo Zavarise (bicchiere) Partner organization: openSUSE.org Description: If you create a kde appliance based on opensuse 12.1 and then you add the kde 4.8 repository, you will find kde 4.7 in the appliance, because the suse studio system lack the option "allow vendor changes" that you can find in zypper.conf. Actually, you need to select kde 4.8 files manually. I think that an option "allow vendor changes" should be a good idea in the suse studio build system. -- openSUSE Feature: https://features.opensuse.org/313426

1 1

[New: openFATE 313197] Allow VMDK and OVF builds with *no* guest additions / VM tools
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: M. Edward Ed Borasky (znmeb) Feature #313197, revision 1 Title: Allow VMDK and OVF builds with *no* guest additions / VM tools SUSE Studio: Unconfirmed Priority Requester: Mandatory Requested by: M. Edward Ed Borasky (znmeb) Partner organization: openSUSE.org Description: I build desktop appliances in OVF and VMDK format and run them in either VirtualBox, VMware Player or VMware Workstation. During the build process, SUSE Studio forces installation of the VMware library libvmtools0 if I select either OVF or VMDK, and it generates a conflict if I try to ban that library. When a user runs a desktop appliance, they have to *remove* any installed VMware or VirtualBox guest additions / tools and install the *matching* toools provided by their desktop virtualizer. If they don't, the appliance won't function correctly. So SUSE Studio should allow the appliance maker to remove any guest tool / addition libraries in the creation process. -- openSUSE Feature: https://features.opensuse.org/313197

1 1

[New: openFATE 313162] Update VMware version in VMX files
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: M. Edward Ed Borasky (znmeb) Feature #313162, revision 1 Title: Update VMware version in VMX files SUSE Studio: Unconfirmed Priority Requester: Important Requested by: M. Edward Ed Borasky (znmeb) Partner organization: openSUSE.org Description: The current version of SUSE Studio creates VMware virtual machines that are many versions behind where VMware is. I believe they're currently being generated as version 4, while VMware has versions 5, 6, 6.5, 7 and 8. I would say generate them at version 7 - VMware Workstation 8 just came out a few months ago and I don't know how many people have upgraded that far yet. But just about everyone who's *active* on VMware should be at least on 7. Test Case: Create a virtual machine in SUSE Studio. Download it and open it in VMware Workstation. You'll get a dialog asking if you want to upgrade it. Use Case: The current version of VMware machines won't play with the "Unity" option. Business case (Partner benefit): openSUSE.org: Mostly it's because of Unity in VMware Player. Player doesn't have the upgrade option, and I don't want my users to have to buy Workstation to use Unity. -- openSUSE Feature: https://features.opensuse.org/313162

1 1

[New: openFATE 313112] Enterprise and Network Standard Desktops and Authority
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: Scott Couston (zczc2311) Feature #313112, revision 1 Title: Enterprise and Network Standard Desktops and Authority Requested by: Scott Couston (zczc2311) Partner organization: openSUSE.org Description:  This feature request has a huge SLES/SLED Commercial Application as well as an OpenSuse application. Preamble- The larger a Network gets the more costly it becomes to effectively administer it and cost of help desk staff fixing up accidental changes to users desktop. A user having access to the root user and password is a disturbing failure by Enterprise Technicians. The following is a little more detailed than a concept however, there are technical issues yet to overcome outside of this document. Effectively installing updates and new applications and maintaining company policy on desktop access and presentation, keeps a small cast of hundreds of staff roaming an enterprise and large numbers of help-desk permanently and often on roster 24/7. Trying to maintain company standards is a nightmare for Help Desk and Security Managers bad dreams. Currently we have no simple yet effective way to do this; however we have all the tools and donât need to buy any commercial software. No Net Admin nor Help Desk personnel can ever be expected to maintain hundreds of users desktops and their configuration so long as users have both the 'poke it and see' or has this innate type of curiosity to âLets change this and see what happensâ This feature request proposes a method of achieving Network-Wide Desktop Configuration, standardisation, standardisation of user authority on a workstation and implementing network wide changes with a minimum of fuss. It does require that ALL outstanding BUGS of NFS be fixed and verified as working every time, everyday, without fault. I am NOT proposing we just lock up all workstations, far far from that. The request does not impede in any way the freedom each user needs to retain preferences. Situation - We can learn a lot about the horrendously difficult task that Microsoft gives their Netadmin's and Help Desk personnel to standardise desktop configuration and functionality, Network wide. M.S calls this 'profiles' or 'wandering profiles' or 'mobile' or 'dynamic profiles'. To this end I am going to explain the essentially working properties on how Microsoft achieves this. This will not be a complete technical discussion, however I can propose a much better and less troublesome technical answer to this situation by only looking at the basis of an M.S Network Profile. The reason we can achieve a more advanced proposition is a tribute to a more advanced O/S in our Linux and the way we manage network drives. Current M.S On an MS NTFS server a permanent system directory exists that holds shell (profile) information that every MS desktop can use one the profile file exists. Every workstation that has ever been installed with ANY version of windows comes with a specific environment variable set that basically says after login to server, check for system profile and if present use this as the desktop standard. If not found or the profile file is incomplete with errors in it, then ignore and load normal workstation configurations. There are more complex parts to this, but essentially this is all that happens. An M.S Windows complete guide devotes a whole chapter, some 80 Pages, on how this is achieved and it is laborious and unnecessarily complex. The user can have the right to change their desktop presentation, but menu items can be greyed out to control access to change important aspects of say, I.E that need to have company wide settings that a user cannot change. Users have the system rights to change their workstation appearance. The other 2 two files held on the servers file system are Policy Profile (group or otherwise) and Authority Profile. This one file can be changed by a netadmin and copied to the system profile file, this ensures all users take up workstation standardisation and forced user authority network wide My Feature Request for Suse Linux. - âStandard Network Desktopâ In concept, after using ONE PC Server to create a standard desktop look and feel, all users inherit this mater configuration. Firstly we need a new Application in Yast>Miscellaneous>New Application> that has the dual ability to either create the Standard Network Desktop OR to use the Standard Network Desktop. The former should be used on a Network File Server. I suggest this new application in yast is in a wizard format. If CREATE is used the current configuration of the desktop is copied to every %userername directory which holds the same copy of all hidden files configuration and directory structure. The next step in CREATE is to start an NFS Server which only creates the export of the newly created directory as Read Only. The next step is to set some environment variables on $Set Standard_Network_Configuration =(the created name of the new directory $Set Standard_Network_Group Configuration = %username Group(users) $Set Standard_Network_Authority=%username second group membership If USE Standard Network Configuration is used in Yast>Miscellaneous>New Application, the exported Network configuration directory is mounted as all users /home directory as RO. Next the same three environment variables are set. $Set Standard_Network_Configuration =(the created name of the new directory $Set Standard_Network_Group Configuration = %username Group(users) $Set Standard_Network_Authority=%username second group membership The wizard is finalised and then the workstation is rebooted. When the workstation loads the mounted /home directory that is exported on the CREATE File Server, become the users /home directories hidden configuration files which ensures the exact copy that was first established. If a change in the default workstation is required, the changes are made once on the desktop that the File Server uses. Then the create wizard is then re-executed copying the new configuration files to the system wide /home directory on the file server with all its .configuration directories and files and the directory is re-exported. As soon as any PC that has had the USE function acted upon it; is rebooted the new appearance from the newly created desktop configuration is again remounted as the users /home directory which takes up all the new .hidden files configuration. Up until now this is a very simple concept and very easy to implement. Now comes the hard part. This is where we need to observe the set environment variables on the workstation and server. I donât have all the technical answers here, however I can propose a method of handling these new problems The Network Standard environment variable is intended to specify that the user can/cannot write to their % username exported directory on the Server's own hard disk as well as can/cannot write files and documents and create new directories; example /home/documents and directories that are not hidden. This variable also ensures that directories and file are owned by the correct username, group etc. The Group environment variable is intended to specify a group standard that can contradict or reverse or alter ANY of these environment variables and to what extent. The groups are defined by adding or removing membership to groups other than 'users', in the user account, The Authority environment variable is intended to specify the location of the users encrypted Login account details and where they are stored. Again the Authority name is taken from specific user login group membership. This is about where I finish the concept of yet to be defined use of the environment variables to overcome the situation where every users login account needs to be both observed, and its location. The environment variables are also intended to allow a user to write changes to their desktop -- openSUSE Feature: https://features.opensuse.org/313112

1 21

[New: openFATE 312942] Clone 32bit image to 64 bits
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: Richard Bos (rbos) Feature #312942, revision 1 Title: Clone 32bit image to 64 bits SUSE Studio: Unconfirmed Priority Requester: Desirable Requested by: Richard Bos (rbos) Partner organization: openSUSE.org Description: Although it is possible to clone an appliance, it does not seem possible to clone or perhaps better brance a 32bit appliance and alter the artchitecture to 64 bit. Right the same appliance has to made and configured for the 64 bit architecture. Business case (Partner benefit): openSUSE.org: Sometimes an appliance is available is 32bit version, but a 64bit is desired so it can run natively on a 64bit system. -- openSUSE Feature: https://features.opensuse.org/312942

1 1

[New: openFATE 312642] Timeframe for building
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: Kim Leyendecker (openLHAG) Feature #312642, revision 1 Title: Timeframe for building SUSE Studio: Unconfirmed Priority Requester: Important Requested by: Kim Leyendecker (openlhag) Partner organization: openSUSE.org Description: IÂ´m currently maintain openSUSE remastered 11.1. ItÂ´s build for keeping an openSUSE 11.1 image up to date using the evergreen repos. IÂ´m doing Service Packs in a fix schedule. Upgrading the packages and rebuild the system is kinda pain for me. So, a feature which you can use to give Studio a time schedule for updating the appliance would be nice. *How it works?* Well, the best way would be to choose a GUI where the following is included: Automatic build all: * 6 weeks * every month * every week * 6 months * (type in your desired timeframe) New build if: * an package get updated in the repository * just do it on time, donÂ´t care about packages Which number should be counted higher: * the major number * the minor number * the release number Using Hermes, the maintainer would get the latest build information in a changelog: Appliance name: xxx Based on: openSUSE /SUSE Linux Enterprise Current version: mm.ii.rr new packages: Firefox 3.6.19 -> Firefox 5.0.1 Thunderbird 3.1.0 -> Thunderbird 5.0 Linux 2.6.32 -> Linux 3.0rc7 ... comments: -- Use Case: doing releases on time, like I do. Business case (Partner benefit): openSUSE.org: Because so we can automatically create releases on a time based model. This becomes important when we want to ship Service Packs. -- openSUSE Feature: https://features.opensuse.org/312642

1 2

[New: openFATE 312082] Updating SUSE images on Studio
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: Shashank Sondhi (dreamtrip) Feature #312082, revision 1 Title: Updating SUSE images on Studio SUSE Studio: Unconfirmed Priority Requester: Mandatory Requested by: Shashank Sondhi (dreamtrip) Partner organization: openSUSE.org Description: So as to ensure that SUSE studio images do not face trouble regarding upgrades it would be great if the images could be updated if the option is selected for the image or version. -- openSUSE Feature: https://features.opensuse.org/312082

1 3

[New: openFATE 311013] Adding Beta and RC status
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: Kim Leyendecker (openLHAG) Feature #311013, revision 1 Title: Adding Beta and RC status SUSE Studio: Unconfirmed Priority Requester: Neutral Requested by: Kim Leyendecker (openlhag) Partner organization: openSUSE.org Description: A nice feature in SUSE Studio is to add a Beta or RC status on your own appliance. If you build a Server and you know it's unstable but you want to publish it to get feedback, you can add a status, so that it's on the iso Image too. Business case (Partner benefit): openSUSE.org: Because the user can see how far the developing status is. -- openSUSE Feature: https://features.opensuse.org/311013

1 1

[New: openFATE 310898] integrate BuildService and SUSE Studio better
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: Jos Poortvliet (jospoortvliet) Feature #310898, revision 1 Title: integrate BuildService and SUSE Studio better Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Jos Poortvliet (jospoortvliet) Partner organization: openSUSE.org Description: SUSE Studio and BuildService have very limited integration right now, still making them separate worlds. Howver there is a lot of room for doing better. Which could bring users from the one to the other - there seems rather little overlap between the two userbases, and SUSE Studio could thus profit from the OBS users AND bring new users to OBS/openSUSE. An example of integration would be to have a one-click-make-an-appliance-of-this-package. Or in SUSE Studio - offer the user to build a package in OBS out of a tarball he/she uploads. Business case (Partner benefit): openSUSE.org: We want this because it can bring new users to OBS/openSUSE/SUSE Studio. And it offers additional value for both STUDIO and OBS users as well. -- openSUSE Feature: https://features.opensuse.org/310898

1 3

[New: openFATE 309958] SUSE Studio: add build format "LTSP Image"
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: Alex Savin (alexqwesa) Feature #309958, revision 1 Title: SUSE Studio: add build format "LTSP Image" Requested by: Alex Savin (alexqwesa) Description: SUSE Studio: add build format "LTSP Image" so, if SUSE Studio is frontend for kiwi, and kiwi can create LTSP Images - why SUSE Studio can't do it? also: it can generate rpm package(and repo) for simplest installation Images -- openSUSE Feature: https://features.opensuse.org/309958

1 2

[New: openFATE 309733] Graphical client for SUSE Studio
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: Cornelius Schumacher (cschum) Feature #309733, revision 1 Title: Graphical client for SUSE Studio Requested by: Cornelius Schumacher (cschum) Description: SUSE Studio is great as web app for creating appliances in the browser, but there are a couple of tasks which can only be performed locally. To facilitate that I'm going to write a graphical client for SUSE Studio focusing on the tasks which can not be done in the web interface, such as managing downloads, running and deploying appliances locally, natively connecting to testdrive, etc. The client will use the SUSE Studio API to talk to the server. Implementation will be done in C++ using the KDE development platform. There are probably many more ideas what the client could do. Add your ideas here, if you like. If somebody wants to join the fun and participate in hacking let me know. You are more than welcome :-) -- openSUSE Feature: https://features.opensuse.org/309733

1 4

[New: openFATE 309314] Add Factory Snapshots to SUSE Studio
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: James Mason (bear454) Feature #309314, revision 1 Title: Add Factory Snapshots to SUSE Studio openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: James Mason (bear454) Description: SUSE Studio has base images of the current openSUSE release to use as a basis for construction custom versions or specialized appliances. It would benefit the products of those appliances to have early access to Factory snapshots (Milestones, Release Candidates) in order to be able to have updates ready at the time of release. This would also allow beta testers the opportunity to create more robust test cases based on specific configuration choices, potentially resulting in more rapid, fine grained testing of the snapshots. -- openSUSE Feature: https://features.opensuse.org/309314

1 2

[openFATE 306606] GUI client for SUSE Studio
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: Cornelius Schumacher (cschum) Feature #306606, revision 1 Title: GUI client for SUSE Studio Requested by: Cornelius Schumacher (cschum) Description: SUSE Studio is a fantastic web app, but sometimes it would still be more convenient to have a native client, for example when dealing with lots of overlay files, or to manage writing downloaded appliances to physical media or running and controlling them in a virtual machine. The Studio API makes it possible to write a native client. -- openSUSE Feature: https://features.opensuse.org/306606

1 7

[openFate 305633] Support installation with encrypted root file system
by fate_noreply＠suse.de 10 Aug '13

10 Aug '13

Feature added by: Andreas Jaeger <aj(a)novell.com> Feature #305633, revision 1, last change by Title: Support installation with encrypted root file system openSUSE-11.2: Unconfirmed Requested by: Stephan Kleine (bitshuffler) Partner organization: openSUSE.org Description: One thing openSUSE is really missing, compared with other popular distributions, is the ability to install into an encrypted root file system so _everything_ is encrypted. While the manual installation / setup like described at http://en.opensuse.org/Encrypted_Root_File_System_with_SUSE_HOWTO works, it is still cumbersome and error-prone to setup - especially on systems with small hard disks like e.g. laptops. IMHO this subject gets more and more important not only for laptops but also for normal workstations with respect to the global decline of privacy protection. Since all the necessary software is in place and Yast already has the option (including the GUI) to encrypt /home this shouldn't be that hard to do and would be a great feature for 11.1 (especially if you keep in mind that this will be the base for the next SLE version and corporations love security functionality provided out of the box as an option). Important points are: 1. it should work with LVMs as well 2. it should be possible to automatically generate a key on startup to encrypt the swap partition (given, this would disable suspend) 3. one should be able to use the same password for several partitions so one has to enter it just one time instead of once for every partition. Related reports: * Bug #397411 - Hibernation won't work with encrypted swap * Bug #399298 - encrypt swap partions by default on every boot using a random key * Bug #166067 - sysinfo:/ does not list encrypted /home partition Relations: - Easy to use Full Disk Encryption (feature/id: 304470) - Support installation with encrypted root file system (novell/bugzilla/id: 415479) https://bugzilla.novell.com/show_bug.cgi?id=415479 Discussion: #1: Arvin Schnell (aschnell) (2008-08-08 11:39:11) Full disk encryption is already under discussion in fate #304470. Sorry, but it's not public. #2: Stephan Kleine (bitshuffler) (2008-12-17 09:49:10) Reopened because the whole installer was rewritten but still no one cared to add this. I'm sorry, but this feature request is about adding root file system encryption to openSUSE. When, or if at all, you add it to SLE, I couldn't care less about it, but I surely don't want to wait till SLE 12 ;) Also I understand that you don't want to track and update 2 different locations but, since that feature is asked for quite often, IMHO there should be a location for openSUSE users to express their need (as in vote) for it and to CC themself to get notified on updates / when it finally is implemented. Making the fate entry public at https://features.opensuse.org/ would be nice to have as well (since it isn't actual rocket science and suse is one of the last distributions to add this feature there shouldn't be a reason to track this behind closed doors) but I can happily live without it as long as you leave this request open so people can vote for it & cc themself. Thanks a lot. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305633

1 53

[New: openFATE 312466] Separate user and kernel log messages
by fate_noreply＠suse.de 09 Aug '13

09 Aug '13

Feature added by: Andreas Jaeger (a_jaeger) Feature #312466, revision 1 Title: Separate user and kernel log messages openSUSE Distribution: New Priority Requester: Important Requested by: Andreas Jaeger (a_jaeger) Product Manager: (Novell) Technical Contact: (Novell) Technical Contact: (Novell) Technical Contact: (Novell) Partner organization: openSUSE.org Description: SUSE used blogd to separate kernel and user log messages during boot. With systemd now everything is written to the kernel ring buffer. We should separate those again. Relations: - syslog (novell/bugzilla/id: 696963) https://bugzilla.novell.com/show_bug.cgi?id=696963 -- openSUSE Feature: https://features.opensuse.org/312466

1 17

[New: openFATE 310899] Bring back boot option 'repair installed system'
by fate_noreply＠suse.de 08 Aug '13

08 Aug '13

Feature added by: Juergen Weigert (jnweiger) Feature #310899, revision 1 Title: Bring back boot option 'repair installed system' openSUSE-11.4: New Priority Requester: Mandatory Requested by: Juergen Weigert (jnweiger) Product Manager: (Novell) Project Manager: (Novell) Partner organization: openSUSE.org Description: yast2-repair was dropped due to fate#308679, bnc#541793. I suggest we take the effort and recreate similar functionality in a maintainable way. Even if incomplete, this would be a good signal moving forward. Business case (Partner benefit): openSUSE.org: The repair feature was an unique selling point for openSUSE and SUSE based products. It gave users a feeling of reliability and confidence. It is absent in 11.3 -- openSUSE Feature: https://features.opensuse.org/310899

1 15

[openFATE 307422] New application, glc
by fate_noreply＠suse.de 08 Aug '13

08 Aug '13

Feature added by: Zombie Ryushu (zombie_ryushu) Feature #307422, revision 1 Title: New application, glc Buildservice: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Zombie Ryushu (zombie_ryushu) Partner organization: openSUSE.org Description: I wish for the video campturing package glc to be added to the Build Service. GLC captures OpenGL output from OpenGL applications. http://nullkey.ath.cx/projects/glc/wiki/HowtoInstall Business case (Partner benefit): openSUSE.org: recordMyDesktop will capture non-accellerated applications, but not Accellerated ones. -- openSUSE Feature: https://features.opensuse.org/307422

1 2

[openFATE 307408] Package request: Amaya
by fate_noreply＠suse.de 08 Aug '13

08 Aug '13

Feature added by: Peter Gumbrell (gumb) Feature #307408, revision 1 Title: Package request: Amaya Package Wishlist: Unconfirmed Priority Requester: Desirable Requested by: Peter Gumbrell (gumb) Description: Copied from old wishlist: Amaya (http://www.w3.org/Amaya/) : W3C's own all-in-one web editor / browser. Maintained for over 12 years. Features support for HTML, XHTML, XML, MathML, CSS, SVG and other emerging web technologies. Updated regularly and fully cross-platform. Provided under the W3C Software License (http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231) (open source). Wanted by: Website developers, especially standards-compliant ones. Amaya is a very capable web design tool. It helps users to create perfect, standards-compliant code, featuring collaboration tools and all regular formatting with both WYSIWYG and source views, and it also doubles up as a web browser. The only current alternative that provides this sort of functionality is Kompozer, but that's still in an alpha/beta state and is prone to modifying your HTML formatting and producing imperfect results, being aimed more at the WYSIWYG user. The packages provided by the Amaya project often fail to work and nothing happens when I try to run the program on openSUSE 11.1. Any chance somebody could look at this and provide it via the Build Service, or consider its inclusion in future releases? -- openSUSE Feature: https://features.opensuse.org/307408

1 2

[openFATE 306988] Pythonxy
by fate_noreply＠suse.de 08 Aug '13

08 Aug '13

Feature added by: Claude Gouedard (cgoued) Feature #306988, revision 1 Title: Pythonxy Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Claude Gouedard (cgoued) Description: Tring to build a General Linux Package from an already existing one for Ubuntu, somehow conterpart of Windows Pythonxy Distribution at www_pythonxy_com. -- openSUSE Feature: https://features.opensuse.org/306988

1 3

[openFATE 307372] iChain Interface for Blogging Software
by fate_noreply＠suse.de 08 Aug '13

08 Aug '13

Feature added by: Sascha Manns (saigkill) Feature #307372, revision 1 Title: iChain Interface for Blogging Software Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Sascha Manns (saigkill) Description: ATM i must me login via iChain to post in lizards. But i would like to have an option to use my Bilbo Blogger with iChain. -- openSUSE Feature: https://features.opensuse.org/307372

1 7

[openFATE 306725] DVB Streaming Application
by fate_noreply＠suse.de 08 Aug '13

08 Aug '13

Feature added by: Romolo Manfredini (romoloman) Feature #306725, revision 1 Title: DVB Streaming Application Package Wishlist: Unconfirmed Priority Requester: Desirable Requested by: Romolo Manfredini (romoloman) Description: There area already several application to stream DVB signals on a network but none of those actually provided by opensuse are as lightweight as getstream getstream can stream single channels from a whole trasponder using http, multicast, unicast and using a modified version of live555 also in RTSP. Is actually under test support for CA support either for DVB-S and DVB-T Getstream is hosted at: http://silicon-verl.de/home/flo/projects/streaming/ -- openSUSE Feature: https://features.opensuse.org/306725

1 1

[openFATE 306717] Channel scan utility for DVBT
by fate_noreply＠suse.de 08 Aug '13

08 Aug '13

Feature added by: Romolo Manfredini (romoloman) Feature #306717, revision 1 Title: Channel scan utility for DVBT Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Romolo Manfredini (romoloman) Description: The scan utility or dvbscan utility are useful for DVB-S channels but limited for DVB-T Digital terrestrial TV in europe is evolving fast with MUX appearing day after day, the scan utility provided suppose that you already know DVB-T frequencies of your city and relays on files in /usr/share/dvb/dvb-t/ for frequency scanning. There is a nice utility called w_scan: http://wirbel.htpc-forum.de/w_scan/index2.html which performs a raw scan of all frequencies supported by the DVB adapter looking for valid digital mux. This utility generates as output various formats that can be used directly by DVB programs or as initial tuning data for (dvb)scan utility. This utility supports DVB-S/S2/T/C adapters and related frequencies. -- openSUSE Feature: https://features.opensuse.org/306717

1 1

[openFATE 306626] Security/Pentesting/Tools
by fate_noreply＠suse.de 08 Aug '13

08 Aug '13

Feature added by: Gabriel Nigro (gnigro) Feature #306626, revision 1 Title: Security/Pentesting/Tools openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Gabriel Nigro (gnigro) Description: Hello, I would like to see one group of tools seemed to Backtrack4 in order educational in OS 11.2.Could is it possible ? Thanks a lot. Use Case: http://backtrack.offensive-security.com/index.php?title=Tools -- openSUSE Feature: https://features.opensuse.org/306626

1 3

[New: openFATE 310454] Warn when disabling publish when dependent repositories exist
by fate_noreply＠suse.de 08 Aug '13

08 Aug '13

Feature added by: Will Stephenson (wstephenson) Feature #310454, revision 1 Title: Warn when disabling publish when dependent repositories exist Buildservice: Unconfirmed Priority Requester: Important Requested by: Will Stephenson (wstephenson) Description: eg disabling publish in KDE:Distro:Factory should warn that the dependent repositories in KDE:Unstable:Playground that build using the results of KDE:Distro:Factory will continue to publish. This can lead to subtle runtime incompatibilities when users install packages built vs a newer version of kdelibs than they have installed, or unresolvable packages in the published dependent repos at best. -- openSUSE Feature: https://features.opensuse.org/310454

1 3

[New: openFATE 310301] Add 'one click add' to repositories index-page
by fate_noreply＠suse.de 08 Aug '13

08 Aug '13

Feature added by: Bart Otten (BartOtten) Feature #310301, revision 1 Title: Add 'one click add' to repositories index-page Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Bart Otten (bartotten) Partner organization: openSUSE.org Description: A link in the OBS indexpages to add an repository to zypper/yast or Recognise the .repo filetype in Yast so the meta-file handler can add the repo Use Case: - browse the OBS-repos - view folder http://download.opensuse.org/repositories/home:/georg298/openSUSE_11.3/ - click at home:georg298.repo (http://download.opensuse.org/repositories/home:/georg298/openSUSE_11.3/home…) - One click installer/ One click repo-add starts and shows some info - Click finish (with option to start packagemanagement) Business case (Partner benefit): openSUSE.org: At this moment users have to set up all information manual which could be so much easier. We have the One click install, but what if I just want to add the whole repo and there is no One click install-button? -- openSUSE Feature: https://features.opensuse.org/310301

1 1

[New: openFATE 310030] detect user specs for software downloads
by fate_noreply＠suse.de 08 Aug '13

08 Aug '13

Feature added by: Kristan Wifler (k_wifler) Feature #310030, revision 1 Title: detect user specs for software downloads Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Kristan Wifler (k_wifler) Description: You can read info from the web browser in order to determine the most likely file the user wants for his/her computer system, Operating system, etc. This is for software.opensuse.org download of openSUSE mostly. I have seen several sites that do this, it makes it more convenient for default settings. -- openSUSE Feature: https://features.opensuse.org/310030

1 1

[New: openFATE 309738] include dependency kind in _builddepinfo
by fate_noreply＠suse.de 08 Aug '13

08 Aug '13

Feature added by: Ludwig Nussel (lnussel) Feature #309738, revision 1 Title: include dependency kind in _builddepinfo Buildservice: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Description: _builddepinfo of a repo lists the recursively expanded dependencies of a package. For analyzing dependency graphs it would be helpful to include information about whether a dependency is explicitly listed in the .spec file or got added due to dependency resolution. -- openSUSE Feature: https://features.opensuse.org/309738

1 1

[New: openFATE 308618] smart online package search
by fate_noreply＠suse.de 08 Aug '13

08 Aug '13

Feature added by: Elmar Stellnberger (estellnb) Feature #308618, revision 1 Title: smart online package search Buildservice: Unconfirmed Priority Requester: Important Requested by: Elmar Stellnberger (estellnb) Description: A smart online package search as it can be found at debtags.alioth.debian.org (http://debtags.alioth.debian.org/ssearch.html) would be highly desirable for openSUSE, too. If I do f.i. enter 'web browser' at the YaST package module it will not find konqueror, arora, epiphany, lynx, pinfo, p3m and many others though these packages are available; i.e. at first the package tagging needs to be improved. Then we need to improve the software search at packages.opensuse-community.org (http://packages.opensuse-community.org) . It currently seems to search for package names only though optionally searching for keywords, summary, description, provides, filenames and requires fields across all known repos would be highly desirable. I do also wonder why my own buildservice packages can not be found there. A factory search in the same place would be handy too although we do not have third party repositories for factory (mere buildservice search). For openSUSE 11.3 I would wish the community search to be available from RC1 on; for os 11.2 I had to wait even weeks after the final release. A comprehensive package search utility is one of the features a good distro should comprise. -- openSUSE Feature: https://features.opensuse.org/308618

1 3

[New: openFATE 309717] make osc to remember http authentication header
by fate_noreply＠suse.de 08 Aug '13

08 Aug '13

Feature added by: JF Ding (jfding) Feature #309717, revision 1 Title: make osc to remember http authentication header Buildservice: Unconfirmed Priority Requester: Desirable Requested by: JF Ding (jfding) Description: In current implementation, osc use 'urllib2' to access api server for http transactions. The problem is, osc need to send out a pair of request for each access: 1st request without authentication header, and the response will be a 401 with Basic authentication challenge. 2nd request with dynamically generated authorization header (Authorization: Basic <base64 encoded string>\r\n) But we can make osc to remember the header at the first authentication challenge of each osc running. Then the http request number and network loading can be lowered a lot. Python's urllib2 module is flexible enough to add this feature. I have implemented it in my personal gitorious branch: http://gitorious.org/~jfding/opensuse/jfdings-osc/commit/62d705c29999856ec6… (http://gitorious.org/~jfding/opensuse/jfdings-osc/commit/62d705c29999856ec6…) Any advice? Thanks. -- openSUSE Feature: https://features.opensuse.org/309717

1 2

[New: openFATE 309611] Add a "ignore" file
by fate_noreply＠suse.de 08 Aug '13

08 Aug '13

Feature added by: Johannes Obermayr (jobermayr) Feature #309611, revision 1 Title: Add a "ignore" file Buildservice: Unconfirmed Priority Requester: Important Requested by: Johannes Obermayr (jobermayr) Partner organization: openSUSE.org Description: Each time the build hosts become initialized new for providing a fresh build system. After that the defined "BuildRequires:" become copied together with all dependencies from another host and installed on the build system. Finally the build system is initialized and the actual build process can start. There are often packages installed which are not really needed for the build process but for a working system. They become installed because of a "Requires:" tag in the actual depended package (especially -branding-{upstream,opensuse}, .noarch [data] or very far depend packages). With a "ignore" file you can say to OBS that e.g. package xy-data is not needed and should not / must not be installed. It is an addition to the "Ignore:"s defined in buildconfig. Business case (Partner benefit): openSUSE.org: 1. Reduce data transfer to the build hosts 2. Improve speed of initialization the build hosts 3. It could be a workaround for bug #510360 -- openSUSE Feature: https://features.opensuse.org/309611

1 1

[New: openFATE 308617] provide FreeBSD, Solaris and OSX build targets
by fate_noreply＠suse.de 08 Aug '13

08 Aug '13

Feature added by: Elmar Stellnberger (estellnb) Feature #308617, revision 1 Title: provide FreeBSD, Solaris and OSX build targets Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Elmar Stellnberger (estellnb) Description: The provision of build targets for the most important Unix derivates like FreeBSD, Solaris and OSX would greatly enhance the capabilities of the build service. While rebuilding packages for different distributions and Linux versions is often a rather cosmetic issue this could really leverage the future use of the build service and constitute a major advancement. The build service infrastructure could then also be sold to proffesional closed source application developers. This should not be undoable since there are also plans for a Windows build target. However the support of the program environment will be much better met on a Unix based system. -- openSUSE Feature: https://features.opensuse.org/308617

1 8

[New: openFATE 308569] exclude certain subpackages from publishing
by fate_noreply＠suse.de 08 Aug '13

08 Aug '13

Feature added by: Wolfgang Rosenauer (wrosenauer) Feature #308569, revision 1 Title: exclude certain subpackages from publishing Buildservice: Unconfirmed Priority Requester: Important Requested by: Wolfgang Rosenauer (wrosenauer) Description: I would like to exclude certain subpackages from being published to repositories. In this example it's a package having data which is not needed but for special purposes and it's quite big (around 100MB RPM size) so it's probably a good idea not to distribute and publish it. -- openSUSE Feature: https://features.opensuse.org/308569

1 3