February 2009 - openSUSE Features - openSUSE Mailing Lists

[openFate 305144] [Feature-request] Yast as a Linux learning tool
by fate_noreply＠suse.de 30 Jan '18

30 Jan '18

Feature added by: Arvin Schnell <aschnell(a)novell.com> Feature #305144, revision 1, last change by Title: [Feature-request] Yast as a Linux learning tool openSUSE-11.1: New Priority Requester: Desirable Requested by: Alexey Eremenko <al4321(a)gmail.com> Partner organization: openSUSE.org Description: Hi All ! I Have very good new idea: converting Yast into a Linux learning tool. This is very simple to achieve: Yast must show the commands it executes and files it modifies, in a nice GUI dialog. It will allow all kinds of Linux users understand how things really work. Enable learn new things or remind how old-but-forgotten things work for seasoned people. Great, isn't it ? P.S. Jay Vollmer recommends, that among the commands that Yast shows as it executing, it should also recommend "man pages" for the relevant underlying commands. -- -Alexey Eromenko "Technologov", 29.jul.2008. Discussion: #1: Alexey Eremenko <al4321(a)gmail.com> (2008-07-29 12:09:11) Rajko M. wrote: If one wants to see what is gong on in background, than look at logs in realtime. There is console (Konsole) and command tail. Run as root: tail -f /var/log/YaST2/y2log and then start YaST and play with. -- -Alexey Eromenko "Technologov", 29.jul.2008. #2: Jerry Houston <jerry.houston(a)comcast.net> (2008-07-29 15:41:34) Sounds like a great way for new users to learn more about what's under the hood. Or, what's under the bonnet, for the Brits. #3: Cyril Hrubis <chrubis(a)novell.com> (2008-07-31 07:11:21) Moving to maintainers to decide. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305144

1 19

[openFate 305737] remove warning of missing swap from expert partitioner
by fate_noreply＠suse.de 12 Sep '17

12 Sep '17

Feature added by: Arvin Schnell (aschnell) Feature #305737, revision 1, last change by Title: remove warning of missing swap from expert partitioner openSUSE-11.2: New Priority Requester: Desirable Requested by: Arvin Schnell (aschnell) Partner organization: openSUSE.org Description: There are requests to remove the warning about a missing swap device from the expert partitioner for systems with only SSDs. I want to go one step further and remove the warning altogether since RAM has increased so much in the past. Relations: - proposal for SSD (novell/bugzilla/id: 467874) https://bugzilla.novell.com/show_bug.cgi?id=467874 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305737

1 5

[openFATE 305929] Startup in X even when the xorg.conf fails
by fate_noreply＠suse.de 10 Sep '17

10 Sep '17

Feature added by: Joop Boonen (worldcitizen) Feature #305929, revision 1, last change by Title: Startup in X even when the xorg.conf fails openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Joop Boonen (worldcitizen) Description: As there are more and more new users within openSuSE with less knowledge. I was thinking it's an option to boot in Vesa when the original xorg.conf fails. Than the user is still able to fix the problem via a GUI i.e. YaST and SAX. -- openSUSE Feature: https://features.opensuse.org/305929

1 15

[openFate 305640] Replace gnomesu by something more modern
by fate_noreply＠suse.de 21 Jul '17

21 Jul '17

Feature added by: Vincent Untz <vuntz(a)novell.com> Feature #305640, revision 1, last change by Title: Replace gnomesu by something more modern openSUSE-11.2: New Priority Requester: Important Requested by: Vincent Untz (vuntz) Partner organization: openSUSE.org Description: gnomesu is kind of obsolete and unmaintained. In the world of PolicyKit, we could use the new PolicyKit-aware gksu, or the adminkit stuff done by Rodrigo. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305640

1 15

[openFate 305688] system wide spellchecker (hunspell)
by fate_noreply＠suse.de 28 Jun '17

28 Jun '17

Feature added by: Kálmán Kéménczy (kkemenczy) Feature #305688, revision 1, last change by Title: system wide spellchecker (hunspell) openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Kálmán Kéménczy (kkemenczy) Partner organization: openSUSE.org Description: Why Hunspell? MySpell is not developed for quite a long time either in Mozilla and in OpenOffice.org. Hunspell is a fork of MySpell, it has great improvements is several ways, and fully backward compatible with MySpell. Main features: * Extended support for language peculiarities; Unicode character encoding, compounding and complex morphology. * Improved suggestion using n-gram similarity, rule and dictionary based pronounciation data. * Morphological analysis, stemming and generation. * Hunspell is based on MySpell and works also with MySpell dictionaries. * GPL/LGPL/MPL tri-license http://en.wikipedia.org/wiki/Hunspell http://hunspell.sourceforge.net/ Fedora project: http://fedoraproject.org/wiki/Releases/FeatureDictionary Ubuntu project: https://wiki.ubuntu.com/ConsolidateSpellingLibs I also find a reference in the wishlist: http://en.opensuse.org/Wishlist_Various Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=354554 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305688

1 15

[openFate 305548] YaST-Qt: More informative "Installation Summary"
by fate_noreply＠suse.de 22 Jun '17

22 Jun '17

Feature added by: Stephan Binner <stbinner(a)novell.com> Feature #305548, revision 1, last change by Title: YaST-Qt: More informative "Installation Summary" openSUSE-11.2: New Priority Requester: Desirable Requested by: Stephan Binner <stbinner(a)novell.com> Partner organization: openSUSE.org Description: The YaST Qt package manager should provide as much information in the "Installation Summary" view as zypper, esp the overall download size to expect and how much disk space will be freed/used after performing the operation. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305548

1 22

[openFate 305305] 1-click uninstall
by fate_noreply＠suse.de 25 May '17

25 May '17

Feature added by: Michael Loeffler <michl(a)novell.com> Feature #305305, revision 1, last change by Title: 1-click uninstall openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Michael Loeffler <michl(a)novell.com> Partner organization: openSUSE.org Description: An easy way to remove Software! For example: you installed an application with "1-click install" (which will install all the packages that you need), there should be an easy way (also with 1 click) to remove what you have installed with that 1-click operation... in another words: an "1-click Uninstall" to remove installed software (dependencies and packages included). -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305305

1 35

[openFate 305664] Server CD
by fate_noreply＠suse.de 25 May '17

25 May '17

Feature added by: Martin Schlander (cb400f) Feature #305664, revision 1, last change by Title: Server CD openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Martin Schlander (cb400f) Description: Providing an official openSUSE server cd - with some often used server software - and perhaps a lightweight window manager like icewm or similar - would be a great thing for a number of reasons. - openSUSE is generally considered a desktop centric distribution, providing a server cd would do a heck of a lot to highligt the excellent (home-)server qualities of openSUSE. - The few people that realize that the openSUSE DVD/netinstall actually offers text mode/server installation, are often discouraged by needing to download a full DVD, or do troublesome and slow http/ftp installation. - Server users are generally more technical people, it would be beneficial to attract more of these to the openSUSE project. - More people using openSUSE on home servers would likely have spill-over effects on SLES sales. - An openSUSE server cd, would be an excellent response to Ubuntu server edition and Microsoft Home Server. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305664

1 32

[openFate 305582] Off-Line one click install (MSI for Linux)
by fate_noreply＠suse.de 25 May '17

25 May '17

Feature added by: Duncan Mac-Vicar <dmacvicar(a)novell.com> Feature #305582, revision 1, last change by Title: Off-Line one click install (MSI for Linux) openSUSE-11.2: New Priority Requester: Important Requested by: Duncan Mac-Vicar <dmacvicar(a)novell.com> Partner organization: openSUSE.org Description: Idea from community member Raul Romero. Same concept as MSI packages for Windows but exploiting the One Click Install concept of openSUSE (and therefore inheriting the simplicity, code and security. Basically a compressed file which includes a repository inside, plus one click install information, and a script to trigger the oneclickinstall handler with the data as payload in the script. Therefore is a collection of rpms that can be installed detailed description is here http://en.opensuse.org/OSI There is already a prototype working. Example script: http://dl.getdropbox.com/u/363315/MozillaFirefox.osi This requires some extra features in one click install and other pieces * ability to force OneClick to add the repo (the one inside the compressed file) Additionally I see other features: * ability to suggest an update repo for the installed bundle * support from build service to generate bundles * easy way to generate them locally Out of scope but interesting: * Ablity to trigger a YaST workflow (its own control.xml?) Business case (Partner benefit): openSUSE.org: This solves the business case of distributing service packs, applications, codecs bundles by just downloading a big file, 100% offline, supporting dependencies and repo signatures. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305582

1 40

[openFate 305556] rpm -q --whatrecommends foobar
by fate_noreply＠suse.de 29 Nov '16

29 Nov '16

Feature added by: Stephan Binner <stbinner(a)novell.com> Feature #305556, revision 1, last change by Title: rpm -q --whatrecommends foobar openSUSE-11.2: New Priority Requester: Desirable Requested by: Stephan Binner <stbinner(a)novell.com> Partner organization: openSUSE.org Description: For debugging purporses why a package is installed it would be nice to have a "--whatrecommends" query option for rpm and not only "--whatrequires". -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305556

1 12

[openFATE 305838] Integrate ReviewBoard in Buildservice
by fate_noreply＠suse.de 12 Feb '16

12 Feb '16

Feature added by: Klaas Freitag (kfreitag) Feature #305838, revision 1, last change by Title: Integrate ReviewBoard in Buildservice Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Klaas Freitag (kfreitag) Description: ReviewBoard is a code change review system. It should be considered to integrate it to the openSUSE Buildservice infrastructure to ease collaboration. It might be an option that submit requests to packages can be handled in the review board. -- openSUSE Feature: https://features.opensuse.org/305838

1 4

[openFATE 305914] PAC support for 'system wide proxy configuration'
by fate_noreply＠suse.de 05 Dec '15

05 Dec '15

Feature added by: Dominique Leuenberger (dimstar) Feature #305914, revision 1, last change by Title: PAC support for 'system wide proxy configuration' openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Dominique Leuenberger (dimstar) Description: The distribution now contains libproxy and we should try to make as much use of it as possible. A big advantage is the ability to parse PAC (Proxy AutoConfiguration) without the need for this in every application. Simply linking against libproxy with it's very simple API (3 API calls, 2 without parameters) is enugh to have the advantage of no longer needing to 'guess' what proxy to use. What is now: - You can set in yast / proxy a general proxy to be used (http://foo.proxy.com:1234) This is bascially put into http_proxy envvar. In gnome you can set user proxy configuration as: - Use System Proxy (as configured in yast) - Use proxy configuration (static, same options as in yast) - Use automatic proxy configuration script Yast lacks the option to specify a PAC script on system wide level. This is only possible in the user sessions configuration. This made sense as most applications don't know how to handle pac files anyway. But with libroxy, this hurdle can be taken away from every single application and can thus be offered. I'm glad to elaborate on questions; I'm sure there are some :-) -- openSUSE Feature: https://features.opensuse.org/305914

1 17

[openFate 305356] 802.1x authentication on wired network using YaST via wpa_supplicant
by fate_noreply＠suse.de 22 Apr '15

22 Apr '15

Feature added by: Marius Tomaschewski <mt(a)novell.com> Feature #305356, revision 1, last change by Title: 802.1x authentication on wired network using YaST via wpa_supplicant openSUSE-11.2: New Priority Requester: Desirable Requested by: Marius Tomaschewski <mt(a)novell.com> Partner organization: openSUSE.org Description: Some networks using 802.1x authentication on metallic Ethernet and I think it would be cool have a possibility, handle this connection type using YaST. The major problem to support this is that the wpa_supplicant is in /usr/sbin; it seems also to be difficult to move it to /sbin because of all the libs the wpa_supplicant is using. What would be required, is to extent the "supported_on_localfs" function to check this and start the interface in remotefs flow when 802.1x is enabled. That is, using remotefs on 802.1x authenticated interfaces would be not possible -- same as with NetworkManager. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305356

1 9

[openFATE 305913] support package installation by supplements in YCP
by fate_noreply＠suse.de 28 Jan '15

28 Jan '15

Feature added by: Arvin Schnell (aschnell) Feature #305913, revision 1, last change by Title: support package installation by supplements in YCP openSUSE-11.2: New Priority Requester: Important Requested by: Arvin Schnell (aschnell) Description: Allow installation of package by supplements in YCP. Currently yast2-storage has a list of packages required for certain filesystems. This list could be removed since filesystem packages include a supplements . Relations: - mail on yast-devel (url: http://lists.opensuse.org/yast-devel/2009-02/msg00033.html) -- openSUSE Feature: https://features.opensuse.org/305913

1 11

[openFate 305099] please have yast do a fsck before attempting to mount existing filesystems
by fate_noreply＠suse.de 28 Jan '15

28 Jan '15

Feature added by: Arvin Schnell <aschnell(a)novell.com> Feature #305099, revision 1, last change by Title: please have yast do a fsck before attempting to mount existing filesystems openSUSE-11.2: New Priority Requester: Important Requested by: Per Jessen <per.jessen(a)enidan.com> Partner organization: openSUSE.org Description: I was doing a new install, but wanted to keep my /home filesystem (JFS). No problem, except that the filesystem wasn't clean and needed an fsck. As far as I can tell, yast didn't do this, so mounting of the /home filesystem failed, which caused the entirely installation process to abend and start over. Discussion: #1: Stefan Hundhammer <sh(a)novell.com> (2008-02-21 06:26:43) I'd really hate to have my 100+ GB ext3 partitions fscked. That takes forever. #2: Per Jessen <per.jessen(a)enidan.com> (2008-02-21 07:15:33) Even when they're clean? It's done on every bootup anyway. See /etc/init.d/boot.localfs #3: Jozef Uhliarik <juhliarik(a)novell.com> (2008-02-21 08:21:41) What is your opinion Thomas? #4: Thomas Fehr <fehr(a)novell.com> (2008-02-21 08:24:13) That would need an feature request, not a bug report. #6: Stephan Kulow <coolo(a)novell.com> (2008-02-21 12:04:27) I think it's not too uncommon that people reinstall their system _because_ the old one had a problem, so dirty file systems may not be too uncommon. #7: Thomas Fehr <fehr(a)novell.com> (2008-02-25 03:00:03) What the customer described happens on JFS, this is an unsupported filesystem exactly for the reason that it behaves quite fundamentally different to most other filesystems. Filesystems like ext3 or reiser simply do their log reply when they are dirty and all is fine. So if you want such things to be added, please specify it as a feature request. Since there needs to be an interactive user interface to the filesystem check program this is in no way a simple change. Or would you prefer for example do a rebuild of reiserfs internal tree as default without asking the user first? Problem is that the questions the filesystem check tools ask the user are quite special and of course totally different for different filesystem types. #8: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2008-07-17 08:13:00) I happen to suffer from this bug too once. I think the bug is not that the installation cleans the disk, but at least say that is not clean instead of crashing (in my case it was an installation where yast thought the disk was mounted but it was not) #9: Arvin Schnell <aschnell(a)novell.com> (2008-07-17 08:22:23) No time for 11.1. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305099

1 9

[openFate 305249] Remove agfa-fonts from openSUSE 11.1
by fate_noreply＠suse.de 22 Jul '14

22 Jul '14

Feature added by: Michael Loeffler <michl(a)novell.com> Feature #305249, revision 1, last change by Title: Remove agfa-fonts from openSUSE 11.1 openSUSE-11.1: Evaluation Priority Requester: Important Requested by: Michael Loeffler <michl(a)novell.com> Partner organization: openSUSE.org Description: As Liberation fonts looking really good meanwhile I propose to replace the proprietary agfa-fonts with the open source fonts for openSUSE 11.1 and future versions. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305249

1 17

[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

[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

[openFATE 305874] Enable peer to peer downloading of patches/software
by fate_noreply＠suse.de 08 Aug '13

08 Aug '13

Feature added by: Johan Kotze (gogga) Feature #305874, revision 1, last change by Title: Enable peer to peer downloading of patches/software Buildservice: Unconfirmed Priority Requester: Important openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Johan Kotze (gogga) Description: It would be great if we could somehow include a peer to peer functionality for the download of patches/packages. This would greatly reduce the number of mirrors required and would increase the performance for many users in countries with limited international bandwidt. I was thinking that we host a torrent tracker on opensuse.org and build a torrent client into zypper/libzypp and allow the user to allocate a portion of disk space for downloaded packages. Most modern systems have ample disk space and should be able to spare around 4GB for downloaded packages. This is also in line with the spirit of community where we help each other out. If it works well, it could also be used to distribute patched internally inside an organization when they deploy SLE. -- openSUSE Feature: https://features.opensuse.org/305874

1 6

[openFate 305716] [openSUSE 11.1] Disk partitioning under installation (Disk)
by fate_noreply＠suse.de 05 Mar '13

05 Mar '13

Feature added by: Matthias Eckermann (mge1512) Feature #305716, revision 1, last change by Title: [openSUSE 11.1] Disk partitioning under installation (Disk) openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Sebastian Furdal (resus) Partner organization: openSUSE.org Description: We all know, that openSUSE as a default wants use on its own entire disk. This is VERRY BAD setting. On this website exist a pool: http://suse.ehelp.pl/modules/xoopspoll/pollresults.php?poll_id=24 POLISH: Czy os11 powinien miec przy instalacji mozliwosc wyboru, na ktorej partycji zainstalować system? ENGLISH: Should os11 installation program have make a choice on what partition install the system? 94% users sad YES (tak) Try my proposal... "See the attachments" Relations: - [openSUSE 11.1] Disk partitioning under installation (Disk) (novell/bugzilla/id: 383886) https://bugzilla.novell.com/show_bug.cgi?id=383886 Discussion: #1: Sebastian Furdal (resus) (2008-04-25 12:36:23) Created an attachment (id=210574) Disk (GIMP) #2: Sebastian Furdal (resus) (2008-04-25 12:37:01) Created an attachment (id=210575) Button "create" #3: Arvin Schnell (aschnell) (2008-04-28 03:44:40) Something for PM to decide. #4: Stephan Kulow (coolo) (2008-04-28 04:10:30) Actually this fits the feedback I got during fosdem - the _HUGE_ majority of (power) users has to change the proposal. But the "Create" and "Edit" buttons are already more prominently as they were in previous releases. This was on the behalf of this feedback. #5: Sebastian Furdal (resus) (2008-04-28 07:47:26) Created an attachment (id=210885) Version 2 #6: Matthias Eckermann (mge1512) (2008-04-29 04:06:15) I do not completly understand the request, I fear:-( Is it (1) about leaving space for windows or other OSes? (2) or about _how_ the Linux partitioning should look like? (3) or about both? I personally have a rather "sophisticated" partitioning (people say: "crazy"), thus I am planning to propose a LVM based partitioning as one(!) option (and default for our Enterprise Server product) with roughly(!) this layout. /dev/sda1 /boot /dev/sda2 /swap /dev/sda3 # system VG / /usr /opt /var /dev/sda4 # data VG /tmp /home /srv This more or less resembles the defaults of Unix/BSD systems. As said: it is the "extended" variant of what I can imagine for systems, where Linux is allowed to control the whole harddisk. For systems with shared windows partitions the layout should be different. And suggestions? Comments? Ideas? Proposals? Thanks in advance - so long - MgE #8: Sebastian Furdal (resus) (2008-05-01 02:19:50) (1)(1)does the idea of „automatic partitioning” is to make monopoly in one OS on one computer? [sarcasm] (2)(2)Yes, its only a proposal, more details I can make in some free time. (3)(3)Yap (4)(4)but openSUSE is mostly installed by less advanced users, who mostly do not know anything about Servers (5)(5)Most people on the world have a Windows and they install GNU/Linux with curiosity, and GNU/Linux should not propose to delete their favorite system and all precious data that where collected for years. This is something that makes openSUSE behind almost all major GNU/Linux distributions. And even I do not use Windows, but GNU/Linux (doesn't matter if its not openSUSE/SUSE) but I want check this distro [...] (6)(6)Propose: 1. After detecting disks and partitions Yast2 should propose mount points for all existed partitions. 2. When it finds completely free partition (doesn't matter with what file system - sometimes users prepare before installation free partition under different OS for a new system) OR/AND unallocated space with more size than installation required it should mark it with a green color – that on this partition/space You can install openSUSE with options /boot, /swap, /, /usr, ... etc. 3. When it doesn't find good partition then it should ask “Create automatic disk partitioning?”. a) YES - Automatically create partition setup for home users (example only with “/” and “/home” and ”/boot” - boot is very important for grub, because for example when a user delete under windows Linux partition grub is still in the MBR but it cant find config files - “OH MY GOD, LOOK LINUX DESTROYED MY SYSTEM – I WILL NEVER USE LINIX AGAIN” and most people do not know anything about windows installation “fixmbr”) - ALL DATA WILL BE LOST [red color] - Automatically create partition setup for server - ALL DATA WILL BE LOST [red color] b) NO - Edit partition setup (all proposed mount points in step 1. should remain even without “/” but whit red warning “To install openSUSE You have to create partition with minimal size $MINIMAL_INSTALLATION_SIZE GB”). #9: Matthias Eckermann (mge1512) (2008-05-06 20:56:51) Hello and thanks for the answers. Please see my comments below.? (In reply to comment #8 from Sebastian Furdal) > > (1) about leaving space for windows or other OSes? > (1)(1)does the idea of „automatic partitioning” is to make monopoly in one > OS on one computer? [sarcasm] I agree: I have at least 3 openSUSE/SLES systems on my systems, and every fresh installation tries to kill my "vg_data". This is just annoying and will be fixed. > > (2) or about _how_ the Linux partitioning should look like? > (2)(2)Yes, its only a proposal, more details I can make in some free time. I also have some ideas there, ... > (4)(4)but openSUSE is mostly installed by less advanced users, > who mostly do not know anything about Servers Well, that does not necessarily be true according to other requests I see:-) But I agree that the "less advanced users" have to be covered in the most save way. > [...] This is something that makes openSUSE behind almost all major > GNU/Linux distributions. [...] Well, you might simply avoid those type of comments, please, as it weakens your very valid points above and below ( because people might become angry ). > (6)(6)Propose: > [...] Instead of your proposal let me post a proposal I wrote roughly 2 years ago here in bugzilla (closed bug); in meta-programming-language (and covering also datacenter use e.g. of SLES product): if( SAN-storage-found ) { expert-partitioning(); } else if( num-of-harddisks > 1 ) { expert-partitioning(); } else if( only-one-windows-partition_on( first_harddisk ) ) { # case 2 below partitioning-with-shrink( first_harddisk ) | expert-partitioning(); } else if( some-partitions-but-free-space_on( first_harddisk ) ){ # case 3 below partitioning-without-shrink-or-delete_on (first_harddisk ) | expert-partitioning(); } else if( some-partitions-but-no-free-space_on( first_harddisk ) ) { expert-partitioning(); } else if( multiple-existing-OSes-found ){ expert-partitioning(); } else { # empty harddisk, case 1 below default-partitioning(); } I would like to see that a little bit less complex, but I hope it could be a good start; I also hope we can agree that there are only three relatively "safe" & easy cases: 1. one empty harddisk 2. one harddisk full with another OS (most probably windows) 3. (at least) one (bigger) empty primary partition on first harddisk Everything else needs "knowledge" by the person in front of the computer, i.e. an "expert partitioner" YaST module to support this person, HTH - MgE #10: Matthias Eckermann (mge1512) (2008-05-26 06:19:13) What do you think? #11: Sebastian Furdal (resus) (2008-07-20 03:40:24) I think advanced partitioning should be rewritten, sometimes it is to complicated ... Your proposal is good but openSUSE should automatically propose simple and automatic solutions ... such as: - propose partitions where oS could be installed - propose automatic mount points - propose some profiles of partitioning etc. What You think? #12: Andreas Jaeger (a_jaeger) (2008-10-24 05:24:05) Information was provided. #13: Matthias Eckermann (mge1512) (2009-01-21 11:57:03) Moved to openFATE from bugzilla. Let's proceed for openSUSE 11.2 based on what we have in openSUSE 11.1. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305716

1 12

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

21 Jan '13

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

1 8

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

19 Oct '12

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

1 25

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

04 Sep '12

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

1 21

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

27 Aug '12

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

1 94

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

17 Apr '12

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

1 6

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

17 Apr '12

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

1 6

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

05 Oct '11

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

1 8

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

23 May '11

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

1 3

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

14 Apr '11

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

1 4

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

14 Apr '11

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

1 10

[openFATE 305919] Hunspell as a system wide spellchecker
by fate_noreply＠suse.de 13 Apr '11

13 Apr '11

Feature added by: Stephan Kulow (coolo) Feature #305919, revision 1, last change by Title: Hunspell as a system wide spellchecker openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Kálmán Kéménczy (kkemenczy) Description: Why Hunspell? MySpell is not developed for quite a long time either in Mozilla and in OpenOffice.org. Hunspell is a fork of MySpell, it has great improvements is several ways, and fully backward compatible with MySpell. Main features: * Extended support for language peculiarities; Unicode character ncoding, compounding and complex morphology. * Improved suggestion using n-gram similarity, rule and dictionary ased pronounciation data. * Morphological analysis, stemming and generation. * Hunspell is based on MySpell and works also with MySpell dictionaries. * GPL/LGPL/MPL tri-license http://en.wikipedia.org/wiki/Hunspell http://hunspell.sourceforge.net/ Fedora project: http://fedoraproject.org/wiki/Releases/FeatureDictionary I also find a reference in the wishlist: http://en.opensuse.org/Wishlist_Various Relations: - Hunspell as a system wide spellchecker (novell/bugzilla/id: 354554) https://bugzilla.novell.com/show_bug.cgi?id=354554 Discussion: #1: Stephan Kulow (coolo) (2008-01-18 06:18:21) For reference: http://lists.opensuse.org/opensuse-factory/2008-01/msg00156.html #2: Petr Mladek (pmladek) (2008-01-18 07:20:54) * ** Bug 301458 has been marked as a duplicate of this bug. *** #3: Petr Mladek (pmladek) (2008-01-18 07:24:25) I'll do my best to do it for openSUSE-11.0. I am still busy with some other things. Or Michael, do you have time to look at it? #4: Kálmán Kéménczy (kkemenczy) (2008-01-27 12:17:56) patch for gtkspell (2.0.11): http://www.abisource.com/~dom/gtkspell-2.0.11-enchant.patch using this patch makes obsolate the gtkspell-gcc-err-fix.diff patch for gnome-spell 1.0.7: based on https://bugzilla.redhat.com/show_bug.cgi?id=426347 attached #5: Petr Mladek (pmladek) (2008-01-28 05:44:13) Adding gtkspell maintainer to CC. #6: Kálmán Kéménczy (kkemenczy) (2008-01-28 05:52:56) Created an attachment (id=191980) gnome spell check patch #7: Kálmán Kéménczy (kkemenczy) (2008-02-04 02:24:22) now available in Build Service (without dictionaries) http://download.opensuse.org/repositories/home:/kkemenczy/openSUSE_Factory/ #8: Ladislav Michnovič (lmich) (2008-02-04 02:49:51) Proposed patch for gtkspell has been added. #9: Kálmán Kéménczy (kkemenczy) (2008-02-04 12:38:37) dictionaries http://download.opensuse.org/repositories/home:/kkemenczy/openSUSE_Factory/… #10: Martin Schlander (cb400f) (2008-02-05 01:30:16) For Danish (da_DK) there's a dictionary being developed that's optimized for hunspell at http://www.stavekontrolden.dk http://www.stavekontrolden.dk/main/sspinputfiles/da_DK.dic http://www.stavekontrolden.dk/main/sspinputfiles/da_DK.aff I believe it's already a better option for hunspell than the dictionary from http://da.speling.org which is currently packaged. If not already it will become so soon as it's developed a lot more actively. Furthermore it's available under these licenses: GPL version 2 LGPL version 2.1 MPL version 1.1 Don't hesitate to ask if there are further questions. #11: Kálmán Kéménczy (kkemenczy) (2008-02-05 07:25:42) da_DK dictionary updated what is the next step? Someone had to decide to add it to the factory for further test. #12: Petr Mladek (pmladek) (2008-02-05 09:57:30) Lado. is there any chance that you could create the hunspell package for STABLE/FACTORY? I am still busy with some other stuff. #13: Ladislav Michnovič (lmich) (2008-02-06 02:49:05) O.K. I'll do it. It won't be in Alpha 2 because it is already under mastering process. It should appear in Alpha 3. #14: Ladislav Michnovič (lmich) (2008-02-19 06:14:25) Package is in Factory. #15: Kálmán Kéménczy (kkemenczy) (2008-02-21 03:48:22) imho several tasks left: * I am not sure that gnome-spell is Enchant-enable or not. ttps://bugzilla.novell.com/attachment.cgi?id=191980 * Sonnet's enchant backend backport to kdelibs / kspell ttp://bugs.kde.org/show_bug.cgi?id=154560 more info: https://www.redhat.com/archives/fedora-devel-list/2007-December/msg01493.ht… * Removing hunspell from Enchant ttps://bugzilla.redhat.com/show_bug.cgi?id=426402 * vim patch for hunspell: ttps://bugzilla.redhat.com/show_bug.cgi?id=219777 Should I create seperate bugs or we should keep them together here? #16: Ladislav Michnovič (lmich) (2008-02-21 04:13:53) (In reply to comment #15 from kalman kemenczy) > imho several tasks left: > > * I am not sure that gnome-spell is Enchant-enable or not. > https://bugzilla.novell.com/attachment.cgi?id=191980 > > * Sonnet's enchant backend backport to kdelibs / kspell > http://bugs.kde.org/show_bug.cgi?id=154560 > more info: > https://www.redhat.com/archives/fedora-devel-list/2007-December/msg01493.ht… > > * Removing hunspell from Enchant > https://bugzilla.redhat.com/show_bug.cgi?id=426402 > > * vim patch for hunspell: > https://bugzilla.redhat.com/show_bug.cgi?id=219777 > > Should I create seperate bugs or we should keep them together here? Adding kde-maintainers and gnome-maintainers to CC. Reassigning to vim maintainer. #17: Bjoern Jacke (bjacke) (2008-03-23 12:43:01) * ** Bug 237828 has been marked as a duplicate of this bug. *** #18: Bjoern Jacke (bjacke) (2008-05-01 15:57:47) - any news from vim maintainer on this? - enchant still needs rework or update - gnome-spell still needs enchant support added #19: Ladislav Michnovič (lmich) (2008-05-05 04:40:12) Adding JP. What do you think about this? See comment #15 and #18. #20: Matthias Koenig (makoenig) (2008-05-05 06:42:03) There are some problems with the vim patch. Currently we have /bin/vim-normal as default vim and /usr/bin/vim-enhanced. As the patch links against libhunspell which lives in /usr/lib{,64} we cannot link /bin/vim-normal against this. This would require either moving libhunspell to /lib{,64} which is not want we want (libhunspell itself also links against /usr/lib{,64}/libstdc++), or building /bin/vim-normal without syntax features at all (as the spell features seem to be tightly coupled to the general syntax features), which I also don't want. The best solution would be to provide a /bin/vim-tiny with minimal features and moving /bin/vim-normal to /usr/bin/vim-normal. But this will not happen for 11.0, as it will need yet another vim package restructuring. But, despite of this, yes, I think using hunspell is a good idea, as the vim dictionaries are derived from the OO ones and would otherwise waste a lot of space by duplicated data. Also worth mentioning, that this patch has been sent a year ago to upstream. While the idea has been appreciated, the patch has been rejected as is, AFAIK there has not been any work to improve this: http://www.mail-archive.com/vim-dev@vim.org/msg03252.html #21: Kálmán Kéménczy (kkemenczy) (2008-05-09 22:54:06) Created an attachment (id=214116) Gnome spell enchant patch here is the latest and greatest patch wirtten by Szilveszter Farkas from Ubuntu community, however this is created for gnome-spell 1.0.7, maybe it could use for 1.0.8. #22: Kálmán Kéménczy (kkemenczy) (2008-05-09 22:57:46) Rodrigo, could you check this patch to gnome-spell, please? https://bugzilla.novell.com/attachment.cgi?id=214116 Hopefully you are the maintainer for this packge. Many thanks, kalman #23: Stanislav Brabec (sbrabec) (2008-05-21 04:21:49) Patch applied (autogenerated files removed from it). #24: Jan Engelhardt (jengelh) (2009-01-11 18:53:30) There's a ton of spelling tools, why could not it have used one of the previously packaged ones, aka aspell or ispell? #25: Kálmán Kéménczy (kkemenczy) (2009-01-12 01:19:59) Jan, Hunspell already packaged in openSUSE. To answer your why's please read comment#1 #26: Jan Engelhardt (jengelh) (2009-01-12 03:06:41) >Hunspell already packaged in openSUSE But was not in 10.3. Hence the question. >comment#1 First comment says "Myspell". I asked about aspell/ispell. #27: Kálmán Kéménczy (kkemenczy) (2009-01-12 03:41:41) I think there are some reasons why choose Mozilla and OpenOffice.org and why Fedora decided as well, and slowly Ubuntu will go this way. In my comment#1 you should find the awesome summary: http://fedoraproject.org/wiki/Releases/FeatureDictionary Hunspell is not a question, the question is when? -- openSUSE Feature: https://features.opensuse.org/305919

1 3

[openFate 305587] Yast template for theming
by fate_noreply＠suse.de 01 Apr '11

01 Apr '11

Feature added by: Jakub Steiner <jimmac(a)novell.com> Feature #305587, revision 1, last change by Title: Yast template for theming openSUSE-11.2: New Priority Requester: Important Requested by: Jim McEldowney <jimmac(a)erie.net> Partner organization: openSUSE.org Description: To be able to skin the Yast installer properly, I would welcome the existence of a YCP template to include all of the widgets included in the actual installer. Business case (Partner benefit): openSUSE.org: Without such a testbed it's extremely hard and error prone to create new styling. In some cases it's impossible to see the implications of a style change until after it has been submitted to build and new distribution snapshot released. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305587

1 6

[openFATE 305876] Packages usage statistics
by fate_noreply＠suse.de 31 Mar '11

31 Mar '11

Feature added by: Michal Vyskocil (mvyskocil) Feature #305876, revision 1, last change by Title: Packages usage statistics openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Michal Vyskocil (mvyskocil) Description: Moved from Brainstorming_Prague (http://en.opensuse.org/BrainStorming_Prague#We_don.27t_know_which_packages_…) Problem: We don't know which packages users really use/have installed We cannot focus our interest on really important packages for our end-users, because we don't know which are important. Those popularity statistics could help us in many ways - for example bug priority of popular package should be higher, or we can decide move the package from/to Factory, ... Debian has a http://popcon.debian.org/ and popularity-contest package, so we should reuse an existing code. The pupularity-contest executable is a simple Perl script, which should be ported to rpm (replacing of dpkg calls by rpm alternative should be enough). Those package usage statistics could be integrated into Software Portal and to YaST comparing relative results for individual packages between openSUSE and Debian can give us a valuable information about the community structure (how many users use development tools etc.) -- openSUSE Feature: https://features.opensuse.org/305876

1 4

[openFate 305723] Allow to set the owner of a partition
by fate_noreply＠suse.de 16 Mar '11

16 Mar '11

Feature added by: Rajko Matovic (rajko_m) Feature #305723, revision 1, last change by Title: Allow to set the owner of a partition openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Rajko Matovic (rajko_m) Partner organization: openSUSE.org Description: If a user buys a new external harddrive and partitions it via YaST he will not be able to write on it, since the filesystem is owned by root. A normal user would need to know about how to use konsole and which command to use in order to change the owner. It would be a lot easier, if the user could change the owner within the partitioning module. Of course this should not be possible for system-partitions such as / and /usr etc, yet /windows and /media, as well as /home/xyz/ should be fine. The problem is not trivial as it is not enough to change fstab. See: See: http://ntfs-3g.org/support.html#unprivileged -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305723

1 5

[openFate 305075] Allow to set the owner of a partition
by fate_noreply＠suse.de 16 Mar '11

16 Mar '11

Feature added by: Arvin Schnell (aschnell(a)novell.com) Feature #305075, revision 1 Title: Allow to set the owner of a partition openSUSE-11.1: New Priority Requester: Desirable Requested by: Sven Burmeister (sven.burmeister(a)gmx.net) Partner organization: openSUSE.org Description: If a user buys a new external harddrive and partitions it via YaST he will not be able to write on it, since the filesystem is owned by root. A normal user would need to know about how to use konsole and which command to use in order to change the owner. It would be a lot easier, if the user could change the owner within the partitioning module. Of course this should not be possible for system-partitions such as / and /usr etc, yet /windows and /media, as well as /home/xyz/ should be fine. Discussion: #1: Arvin Schnell(aschnell(a)novell.com) (2008-07-15 08:32:00) Do you want to set gui and uid in /etc/fstab? #2: Sven Burmeister(sven.burmeister(a)gmx.net) (2008-07-15 08:56:26) I'm not sure which is the best approach. Either the user could do something that replaces "chown user:group ." on the new partition or some predefined gui/uid to select from, because the normal user has no idea about those and the numbers that go with them. The goal is that a user that knows the root password can not only partition a new harddrive via GUI but also make it accessible (rw) to users without having to know anything about fstab-syntax and options. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305075

1 17

[openFate 305672] openFATE - Show References
by fate_noreply＠suse.de 17 Feb '11

17 Feb '11

Feature added by: Klaas Freitag (kfreitag) Feature #305672, revision 1, last change by Title: openFATE - Show References Requested by: Klaas Freitag (kfreitag) Description: openFATE should comfortably display and handle external references like: * related bug numbers * other features (dupes, related) * wiki pages into the opensuse wiki * sourcecode, ie. svn path People should be able to edit references as well. Wiki page and sourcecode references are new and must be added. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305672

1 7

[openFate 305768] Use open source firmware for b43
by fate_noreply＠suse.de 03 Feb '11

03 Feb '11

Feature added by: Helmut Schaa (hschaa) Feature #305768, revision 1, last change by Title: Use open source firmware for b43 openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Helmut Schaa (hschaa) Partner organization: openSUSE.org Description: Currently openSUSE does not ship the firmware for broadcom devices due to legal issues. Only a script /usr/sbin/install_bcm43xx_firmware is provided which is not easy to find for new users. However an open source firmware for these devices are available now at [1] and would allow to be shipped with openSUSE. Of course this firmware needs some testing but it would be quite nice to not depend anymore on the proprietary firmware. [1] http://www.ing.unibs.it/openfwwf/ -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305768

1 4

[openFATE 305923] osc revert or merge
by fate_noreply＠suse.de 18 Dec '10

18 Dec '10

Feature added by: Will Stephenson (wstephenson) Feature #305923, revision 1, last change by Title: osc revert or merge Buildservice: Unconfirmed Priority Requester: Important Requested by: Will Stephenson (wstephenson) Description: The only way to revert packages currently is very inconvenient. Some more svn semantics like osc merge to enable reverts would help. -- openSUSE Feature: https://features.opensuse.org/305923

1 2

[openFate 305695] Binary Upload of prebuild packges
by fate_noreply＠suse.de 17 Dec '10

17 Dec '10

Feature added by: Martin Mohring (MartinMohring) Feature #305695, revision 1, last change by Title: Binary Upload of prebuild packges Buildservice: Unconfirmed Priority Requester: Important Requested by: Martin Mohring (martinmohring) Partner organization: openSUSE.org Description: Ths allow also developers without direct access to the OBS backend to create distributions that consist of only binary packages or that are initially created from binary packages, there should be a combination of backend and osc be capable to upload binary files to :full directory of a project. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305695

1 1

[openFate 305081] openSUSE Testfeature
by fate_noreply＠suse.de 11 Dec '10

11 Dec '10

Feature added by: Christopher Hofmann (cwh(a)novell.com) Feature #305081, revision 1 Title: openSUSE Testfeature openSUSE-11.1: New Priority Requester: Neutral Requested by: Christopher Hofmann (cwh(a)novell.com) Partner organization: openSUSE.org Description: Feel free to play aroud with this feature. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305081

1 34

[openFate 305725] Use gettext for gconf schemas translations
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Vincent Untz (vuntz) Feature #305725, revision 1, last change by Title: Use gettext for gconf schemas translations openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Vincent Untz (vuntz) Partner organization: openSUSE.org Description: The translations of all the descriptions of gconf keys in schemas are already in the gettext files of the application. Removing them from the schemas would make the packages smaller and would possibly improve gconf performance in normal usage (ie, outside of gconf-editor, where the descriptions are used). Martin Pitt and I talked about this, and Martin has implemented it for Ubuntu: https://bugs.launchpad.net/bugs/123025 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305725

1 5

[openFATE 305851] Include kiwi-ltsp in Factory
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Stephan Kulow (coolo) Feature #305851, revision 1, last change by Title: Include kiwi-ltsp in Factory openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Jigish Gohil (cyberorg) Description: I've been maintaining KIWI-LTSP: LTSP5 implementation on openSUSE using KIWI in server:ltsp Build Service repository, now it is at the stable and production ready state. This is request to include the packages(not all of them) in openSUSE Factory, and possibly 11.3 later. Relations: - Include kiwi-ltsp in Factory (novell/bugzilla/id: 474360) https://bugzilla.novell.com/show_bug.cgi?id=474360 Discussion: #1: Jigish Gohil (cyberorg) (2009-02-10 08:42:08) Should this have gone on https://features.opensuse.org/ ? #2: andrea florio (anubisg1) (2009-02-10 09:16:58) +1 for me... kiwi-ltsp is great and works fine! #3: Shrenik Bhura (sbhura) (2009-02-11 05:20:31) The inclusion will largely serve as an impetus for further development of this great project. With increased exposure, the motivation to deliver a quality project shall also increase. #4: Ken Yap (ken_yap) (2009-02-11 06:31:44) Yes, please include it in OpenSUSE, it will make OpenSUSE more attractive to people who want to build thin client clusters. #5: Stephan Kulow (coolo) (2009-02-11 06:53:23) why not Factory:Contrib? And I agree with #1 Having it in Factory means currently that someone from novell needs to review them and that's why we created contrib where everyone capable can maintain packages that go with a specific openSUSE release. And for having it on the DVD it's a bit too special use case, so it would be online repo only anyway. #6: Jigish Gohil (cyberorg) (2009-02-11 07:00:00) Not on the DVD, but Factory and OSS online repo. Instead of Contrib isn't current location - server:ltsp more appropriate? Idea is to include it officially in the distribution. I am sure we can make a same kind of arrangement we have in place for compiz to maintain this as well. -- openSUSE Feature: https://features.opensuse.org/305851

1 8

[openFate 305690] Replace System-V init with upstart init
by fate_noreply＠suse.de 27 Oct '10

27 Oct '10

Feature added by: Vitaliy Tomin (HighwayStar) Feature #305690, revision 1, last change by Title: Replace System-V init with upstart init openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Vitaliy Tomin (highwaystar) Partner organization: openSUSE.org Description: Upstart - an event-based init daemon. It can provide more flexible init system for more faster and effective boot and communication with the init daemon over D-Bus. upstart home page http://upstart.ubuntu.com/ -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305690

1 56

[openFate 305312] OpenSUSE <= 11.1 Alpha 2 don't install on SD card
by fate_noreply＠suse.de 06 Oct '10

06 Oct '10

Feature added by: Arvin Schnell <aschnell(a)novell.com> Feature #305312, revision 1, last change by Title: OpenSUSE <= 11.1 Alpha 2 don't install on SD card openSUSE-11.2: New Priority Requester: Important Requested by: Harald Welte <haraldwelte(a)viatech.com> Partner organization: openSUSE.org Description: [Please note that I'm working for the CPU+Chipset maker VIA and this is an actually important feature for the 'netbook' class of devices in the coming months] Recently, BIOS vendors have been starting to implement a 'boot from SD card' feature, much like they have added 'boot from USB memory stick' some years ago. The only SD-card host controller that I've seen this implemented for is SDHCI compliant host controllers. While this is a nice feature to support, for most systems it is just a gimmick and not something neccessarry. However, there are hand-held devices such as netbooks in the pipeline which do not have any other mass storage device. No hard disk and no IDE-attached flash disk or the like. They just have one (more likely two or more) SD card slots and you install and store not only your data but the entire operating system on that SD card. Furthermore, there are products like Samsung moviNAND which are basically a SDcard in a BGA package that can be soldered onto a PCB. So from a protocol and software point of view it is a SD card, but it is mechanically soldered onto the board. Such device have gained some popularity in ARM-based designs, but we'll likely see them in the x86 world, too. To make this happen, The distribution installation initrd needs to 1. include and auto-load the sdhc.ko and sdhci_pci.ko kernel modules 2. create the /dev/mmcblk* device nodes as per udev/hotplug events The actual distribution installation program needs to 1. recognize /dev/mmcblk* as block devices that can be used as target device 2. use a grub-install or similar program that can discover the bios drive number to /dev/mmcblk* device name mapping I have outlined the full details at http://wiki.gpl-devices.org/wiki/Installing_Linux_on_booting_SD_card -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305312

1 18

[openFate 305706] Facebook chat/Pidgin Integration
by fate_noreply＠suse.de 07 Sep '10

07 Sep '10

Feature added by: Kevin Dupuy (kdupuy9) Feature #305706, revision 1, last change by Title: Facebook chat/Pidgin Integration openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Kevin Dupuy (kdupuy9) Partner organization: openSUSE.org Description: Facebook is currently the most popular social networking site, and it's chat functionality is being used as an IM client for many people. With pidgin-facebookchat (http://code.google.com/p/pidgin-facebookchat/) , Pidgin seamlessly integrates Facebook friends and chats as it would any other IM service. The plugin is already there, and licensed under the GPLv3 (see website above). -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305706

1 7

[openFate 305267] Installation using Orca (screen reader) to Improve Accessibility
by fate_noreply＠suse.de 10 Aug '10

10 Aug '10

Feature added by: Lukas Ocilka <locilka(a)novell.com> Feature #305267, revision 1, last change by Title: Installation using Orca (screen reader) to Improve Accessibility openSUSE-11.2: New Priority Requester: Desirable Requested by: Darragh Ó Héiligh <d(a)digitaldarragh.com> Partner organization: openSUSE.org Description: Original title: Accessibility for installation could be automated with better results. Users can currently press F9 at the boot screen to hear the boot options spoken. THis is a fantastic new feature and is one that OpenSuSE is the first to add. For this you should be very proud. However, I would ask that you further build upon this success by recognising that accessibility at the boot menu has been enabled and automatically start the Orca screen reader with also setting gnome accessibility to enabled. One further consideration should be taken into account. To enable Orca to access the installation screen, Orca must be run as root. However, if Orca is run as root, the rest of the desktop is not accessible due to permissioning issues. Therefore, the installation should be run automatically if the f9 key si pressed. Note, a similar feature excluding the accessible boot menu has also been added to Ubuntu 8.04. Note that they also have a key press (F5) to automatically enable assistive technologies for installation on their live CD. References: See bnc #417874 (https://bugzilla.novell.com/show_bug.cgi?id=417874) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305267

1 5

[openFate 305589] Checkbox "include user home projects in search"
by fate_noreply＠suse.de 30 Jul '10

30 Jul '10

Feature added by: Pavol Rusnak <prusnak(a)novell.com> Feature #305589, revision 1, last change by Title: Checkbox "include user home projects in search" Buildservice: New Priority Requester: Desirable Requested by: Pavol Rusnak <prusnak(a)novell.com> Partner organization: openSUSE.org Description: Here's one idea to start with: on the search page, have a checkbox labeled "Include user home projects in search" which defaults to OFF. Then at least you have one level of separation (between "official" and home projects) that is clear to both developers and users. And developers will be motivated to move their generally useful packages into an "official" project by the fact that the default checkbox is OFF. http://lists.opensuse.org/opensuse-buildservice/2008-12/msg00088.html -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305589

1 4

[openFATE 305905] Package and Project Marking
by fate_noreply＠suse.de 02 Jun '10

02 Jun '10

Feature added by: Will Stephenson (wstephenson) Feature #305905, revision 1, last change by Title: Package and Project Marking Buildservice: Unconfirmed Priority Requester: Important Requested by: Will Stephenson (wstephenson) Description: * Add the ability to have a 'status update' on packages AND projects * * status updates are not package changelogs; logs refer to changes to the contents of the package, status updates relate to ongoing work on the packages * * 1:N relationship, status updates are timestamped. Like facebook or $microblogging service. * show current status on checkout or list * Add a command to read all the status updates on a package. Examples: 1) Jack is updating Commodore:Amiga:Workbench:Factory to 23.2 and disables publish on the whole project before the actual release date with the status message '20090224 - disabled publish pending 23.2 release' 2) Jill is triaging breakages in Commodore:Amiga:Workbench:Factory and marks packages without checking them out before assigning work to team members Denise and Paula, with "osc mark -m 'broken by input.device changes' Commodore:Amiga:Workbench:Factory Preferences" 3) Paula is fixing a breakage in Commodore:Amiga:Workbench:Factory Preferences and locks (see #305899) the package with status update using "osc co -l -m '20090225 - fixing build failure due to input.device changes' Commodore:Amiga:Workbench:Factory Preferences" -- openSUSE Feature: https://features.opensuse.org/305905

1 3

[openFate 305104] Provide possibility to configure WEP/WPA/WPA2/... at installation
by fate_noreply＠suse.de 09 Mar '10

09 Mar '10

Feature added by: Lukas Ocilka <locilka(a)novell.com> Feature #305104, revision 1, last change by Title: Provide possibility to configure WEP/WPA/WPA2/... at installation openSUSE-11.1: New Priority Requester: Desirable Requested by: Jim Creech <jacreech(a)suddenlink.net> Partner organization: openSUSE.org Description: It is possible to configure a network in the first stage installation but it is only possible to select DHCP or Static + configure proxy. It is impossible to configure a secure wireless connection. See also: Bug 293609 (https://bugzilla.novell.com/show_bug.cgi?id=293609) - No provision for entering WEP at installation -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305104

1 9

[openFate 305724] Allow to take over old users by home directory
by fate_noreply＠suse.de 02 Mar '10

02 Mar '10

Feature added by: Jiří Suchomel (jsuchome) Feature #305724, revision 1, last change by Title: Allow to take over old users by home directory openSUSE-11.2: New Priority Requester: Neutral Requested by: Jiří Suchomel (jsuchome) Partner organization: openSUSE.org Description: (from bug reporter:) I have a seperate /home partition and whenever I reinstall/upgrade I just set up the same user as before and he gets assigned the same uid (1000) so nothing gets broken. But I guess with more users and corresponding home directories this aproach begs for wrong permissions, so I suggest the following: In case /home isn't empty it could take all directories available and list them as users to specify their data (Name, login, passwort etc as usual) and then assign corresponding uid. References: https://bugzilla.novell.com/show_bug.cgi?id=464238 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305724

1 7

[openFate 305689] Allow creation of meta-repositories
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Magnus Boman (MBoman) Feature #305689, revision 1, last change by Title: Allow creation of meta-repositories Buildservice: Unconfirmed Priority Requester: Important Requested by: Magnus Boman (mboman) Partner organization: openSUSE.org Description: It'd be extremely useful if it was possible to create meta-repositories in OBS. The way it would work, is that anyone could create a project in OBS, and from there, include several other projects to combine them in one meta-repository. It is kind of possible today if one use _links or _aggregate, but that either forces the entire repo to be built in the users own project, or requires a lot of disk space. A meta-repository would basically only create symlinks to the other projects (would not require any extra disk space, nor OBS resources for re-compiling everything in a "new" project) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305689

1 6

[openFate 305693] Versioning for project data
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Martin Mohring (MartinMohring) Feature #305693, revision 1, last change by Title: Versioning for project data Buildservice: Unconfirmed Priority Requester: Mandatory Requested by: Martin Mohring (martinmohring) Partner organization: openSUSE.org Description: Currently, we have versioning of the source files with OBS.Since at least projconf correlates to the sources, it should be versioned to make versioning more of a feature to restore old versions reproducable. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305693

1 3

[openFate 305625] Emphasize my packages in a project maintained by me.
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Pavol Rusnak <prusnak(a)novell.com> Feature #305625, revision 1, last change by Title: Emphasize my packages in a project maintained by me. Buildservice: New Requested by: Pavol Rusnak (prusnak) Partner organization: openSUSE.org Description: When I'm a maintainer of a project and also set as an explicit maintainer of a package inside this project, I'm unable to list of these packages. "My Projects" shows only affected projects and packages outside of these projects. I suggest to show emphasize such packages in Project view (package list) for example by adding icon, or showing the package name in bold. This is especially needed for Contrib repository. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305625

1 3

[openFate 305592] Warn on creating of the package that already exists in BuildService
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Pavol Rusnak <prusnak(a)novell.com> Feature #305592, revision 1, last change by Title: Warn on creating of the package that already exists in BuildService Buildservice: New Priority Requester: Important Requested by: Pavol Rusnak <prusnak(a)novell.com> Partner organization: openSUSE.org Description: http://lists.opensuse.org/opensuse-buildservice/2008-12/msg00056.html * warn on creating of the package that already exists in BuildService (webclient and osc) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305592

1 3

[openFate 305590] Virtual packages and virtual joint projects
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Pavol Rusnak <prusnak(a)novell.com> Feature #305590, revision 1, last change by Title: Virtual packages and virtual joint projects Buildservice: New Priority Requester: Desirable Requested by: Pavol Rusnak <prusnak(a)novell.com> Partner organization: openSUSE.org Description: http://lists.opensuse.org/opensuse-buildservice/2008-12/msg00094.html Virtual packages and virtual joint project would be a special type of projects, that are part of a standard binary repository, but they have no source present in the project. It may have several typical use cases: Virtual dependency packages --------------------------- When a project intents to update a library to a newer version, virtual dependency packages and projects may determine packages that will have broken/changed dependencies after installing of a new library. How it should look. Either package or a project should have a new attribute: "Rebuild parent project packages" Possible values: "ignore": Rebuild only packages in this project and nothing else (just the current behavior) "rebuild broken": Rebuild parent project packages, that cannot be used with newer version any more (it typically happens for package, that require exact version it is built against, or packages that don't follow shared library packaging conventions) "smart rebuild": Rebuild packages that require package or symbol that are no more part of the output of the new package. "all dependencies": Behave just like a single repository and rebuild everything which uses the new in the build. Examples of use for particular values: "rebuild broken": Building some modules require the same version of the base package it was build with. When trying to update base package in a project, it will rebuild all such modules. "smart rebuild": Testing package poppler update: New poppler has a new soname and it requires to rebuild all packages that are linked with poppler. However it is possible to install these packages (and use shared library from the parent project), testing of the new library requires to rebuild these package with the new library). "all dependencies": Testing new core package (bison, gcc). All packages, that have this package in BuildRequires on build system will be rebuilt. Virtual package may become non-virtual. If you need to patch one of the packages to be able to rebuild it in the new repository, you have to link it physically to the joint repository. In this moment, package becomes equal to the normal link package, disabled by default. Virtual/non-virtual joint project --------------------------------- Just now, one can include two different projects, that have a disjunctive packages. Virtual joint project would determine packages that will build differently (or break) in one or another parent repository and rebuild them as a separate repository. Virtual joint project could be a separate project that contains rebuilds of packages in the intersection of both project. Virtual joint project may become non-virtual. If you need to patch one of the packages to be able to rebuild it with both projects included, you have to add it physically to the joint repository. In this moment, the joint project feature would be equal to the normal repository with "Rebuild parent project packages" set. Example: Suppose you have a testing repository of new poppler (different soname) and a multimedia:photo with a new version of GIMP (requires poppler). You can easily include both multimedia:photo and poppler test repositories, but you cannot test new gimp with a new poppler. Creating of virtual joint project will automatically detect these packages and rebuild them. There could be again the tag "Rebuild parent projects packages" with the same values as above. Benefits: Virtual packages: Now they are often substituted by links. Several years later, nobody knows, why such link was created and the link may rot there forever. Virtual joint project: It will allow to test result of a dangerous package check-in without actually doing it. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305590

1 3

[openFate 305595] Show dependencies between packages in repo
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Pavol Rusnak <prusnak(a)novell.com> Feature #305595, revision 1, last change by Title: Show dependencies between packages in repo Buildservice: New Priority Requester: Important Requested by: Pavol Rusnak <prusnak(a)novell.com> Partner organization: openSUSE.org Description: * Show dependencies (Requires, BuildRequires) between packages in repository OBS should provide lists of required packages (runtime and build dependencies) - BuildRequires could be extracted from spec files - it is important to show also reverse dependencies (eg. which packages depend on the package I'm maintaining) - Requires are much harder (will probably need also symbol resolution), but not so desperately needed as BuildRequires -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305595

1 4

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

05 Nov '09

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

1 17

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

30 Oct '09

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

1 42

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

21 Oct '09

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

1 7

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

19 Oct '09

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

1 35

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

12 Oct '09

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

1 8

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

06 Oct '09

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

1 28

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

30 Sep '09

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

1 5

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

25 Sep '09

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

1 8

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

15 Sep '09

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

1 4

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

14 Sep '09

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

1 2

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

07 Sep '09

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

1 5

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

07 Sep '09

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

1 9

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

27 Aug '09

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

1 14

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

18 Aug '09

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

1 18

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

18 Aug '09

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

1 53

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

17 Aug '09

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

1 6

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

14 Aug '09

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

1 6

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

14 Aug '09

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

1 49

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

14 Aug '09

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

1 7

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

14 Aug '09

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

1 9

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

14 Aug '09

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

1 23

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

12 Aug '09

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

1 5

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

12 Aug '09

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

1 7

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

10 Aug '09

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

1 8

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

29 Jul '09

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

1 8

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

29 Jul '09

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

1 6

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

17 Jul '09

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

1 11

[openFate 305727] rpmbuild build should warn about possibly by mistake %excluded files
by fate_noreply＠suse.de 29 Jun '09

29 Jun '09

Feature added by: Stephan Binner (Beineri) Feature #305727, revision 1, last change by Title: rpmbuild build should warn about possibly by mistake %excluded files openSUSE-11.2: New Priority Requester: Desirable Requested by: Stephan Binner (beineri) Partner organization: openSUSE.org Description: If one works with %exclude macros in %files sections, esp with several sub-packages and wildcards in the %exclude statements, then it can easily happen that files installed to the RPM_BUILD_ROOT do not get packaged into a package at all. This case happens currently completely silent. rpmbuild should warn when an installed file gets only referenced by an %exclude statement but nowhere else. An option might be to make this warning a build error and to have a policy to allow installed files to be excluded from packages by well visible "rm $RPM_BUILD_ROOT/foo" calls within the .spec only. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305727

1 3

[openFate 305721] Desktop should survive a dbus restart
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature added by: Vincent Untz (vuntz) Feature #305721, revision 1, last change by Title: Desktop should survive a dbus restart openSUSE-11.2: New Priority Requester: Important Requested by: Vincent Untz (vuntz) Partner organization: openSUSE.org Description: Many applications have issues when dbus is restarted. It seems people want this to be possible, see for example https://bugzilla.novell.com/show_bug.cgi?id=439616 This is more than just a bug, and covers many packages, so I'm opening this feature to track this. On the GNOME side, the mandatory part are probably gdm and gnome-session, in order to not have the current sessions closed. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305721

1 2

[openFate 305683] Add web browser for SUSE Installation
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature added by: Vincent Steenhoute (civ75) Feature #305683, revision 1, last change by Title: Add web browser for SUSE Installation openSUSE-11.2: New Priority Requester: Desirable Requested by: Vincent Steenhoute (civ75) Interested: Vincent Untz (vuntz) Partner organization: openSUSE.org Description: While installing SUSE with the classic installation CD/DVD, add a web browser. Somes peoples don't use LiveCD and prefer Install DVD, giving them possibility to browse internet while all the package are installed would be a must. I guess Webkit will fit nicely with the QT UI of our installation. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305683

1 14

[openFate 305146] Use old system network configuration when updating instead of demanding a new one
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature added by: Lukas Ocilka <locilka(a)novell.com> Feature #305146, revision 1, last change by Title: Use old system network configuration when updating instead of demanding a new one openSUSE-11.2: New Priority Requester: Desirable Requested by: Pacho Ramos <pacho(a)condmat1.ciencias.uniovi.es> Partner organization: openSUSE.org Description: Currently, when I try to update from opensuse 10.3 to 11.0 with DVD and I want to add network repositories, I have to configure again my network for opensuse installer even when it is already configured on my opensuse-10.3 I think that would be much better try to use network configuration from old installation and only ask user if a problem occurs Business case (Partner benefit): openSUSE.org: System update from media: Start installation / Update, select network-based repositories to be used, you will be asked to configure the network. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305146

1 5

[openFATE 305846] Add the us_int (us international with euro sign keyboard)
by fate_noreply＠suse.de 09 Jun '09

09 Jun '09

Feature added by: Joop Boonen (worldcitizen) Feature #305846, revision 1, last change by Title: Add the us_int (us international with euro sign keyboard) openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Joop Boonen (worldcitizen) Description: Add the us_int (us international with euro sign on "5" key keyboard) in the choices in the installation process (when the keyboard can be chosen). This way it'll be easier to choose this lay-out. -- openSUSE Feature: https://features.opensuse.org/305846

1 9

[openFate 305735] Correctly detect keyboard model on laptops
by fate_noreply＠suse.de 08 Jun '09

08 Jun '09

Feature added by: Vincent Untz (vuntz) Feature #305735, revision 1, last change by Title: Correctly detect keyboard model on laptops openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Vincent Untz (vuntz) Partner organization: openSUSE.org Description: The default configuration of X always gives you a keyboard using the microsoftpro model. However, on laptops, it'd be better to actually use the model of this laptop -- it's certainly possible to have a script to detect this. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305735

1 5

[openFate 305681] yast2 remote and vnc server
by fate_noreply＠suse.de 05 Jun '09

05 Jun '09

Feature added by: andrea florio (anubisg1) Feature #305681, revision 1, last change by Title: yast2 remote and vnc server openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: andrea florio (anubisg1) Partner organization: openSUSE.org Description: the remote yast module should start a vnc (and/or rdp) server too.. right now it simply open firewall ports, that means it is un-usefull like that... because it not allow you to control remotly the pc -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305681

1 4

[openFATE 305808] 1-click install without permanent subscription to repo
by fate_noreply＠suse.de 03 Jun '09

03 Jun '09

Feature added by: Johan Kotze (gogga) Feature #305808, revision 1, last change by Title: 1-click install without permanent subscription to repo openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Johan Kotze (gogga) Description: I would like to have the option of using 1-click install, but not be permanently subscribed to the repositories. Example. I am interested in qcad. It is in the education repository and it is the only package in that repository that I am interested in. I use 1-click install, but now my system is updated to be permanently subscribed to the education repo. This adds to the startup time of zypper and all other package management tools. This could be quite easily implemented by just disabling the repo once the install has finished or just remembering which repo's were added during the 1-click install and just remove them again. -- openSUSE Feature: https://features.opensuse.org/305808

1 6

[openFate 305272] Definition in the Yast2 samba server module for "workgroup" host
by fate_noreply＠suse.de 28 May '09

28 May '09

Feature added by: Lukas Ocilka <locilka(a)novell.com> Feature #305272, revision 1, last change by Title: Definition in the Yast2 samba server module for "workgroup" host openSUSE-11.2: New Priority Requester: Desirable Requested by: Andreas van dem Helge <andrew(a)joako.net> Partner organization: openSUSE.org Description: Add a definition in the samba server module for "workgroup" host. I.E. in a SOHO it isn't always necessary to setup a true "domain" server, however if there were a set of options for things like "LMB" aka "local master browser" and a quick set of clicks to join a "Workgrp" as a client. this tutorial highlights the amount of script editing that could be avoided if the samba server were more "workgroup" friendly http://www.swerdna.net.au/linhowtolanprimer.html#samba (http://www.swerdna.net.au/linhowtolanprimer.html#samba) References: Originally reported as BNC #420766 (https://bugzilla.novell.com/show_bug.cgi?id=420766) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305272

1 3

[openFATE 305772] Move to hal-cups-utils instead of cups-autoconfig
by fate_noreply＠suse.de 16 Apr '09

16 Apr '09

Feature added by: Vincent Untz (vuntz) Feature #305772, revision 1, last change by Title: Move to hal-cups-utils instead of cups-autoconfig openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Vincent Untz (vuntz) Partner organization: openSUSE.org Description: We're the only one using cups-autoconfig and everybody else is using hal-cups-utils, so it's probably working a bit better. And switching to it means lower maintenance on our side. Packages are ready for testing in home:vuntz:factory-playground -- openSUSE Feature: https://features.opensuse.org/305772

1 3

[openFate 305696] Add YaST Functionalities under GNOME "Common Tasks" Header
by fate_noreply＠suse.de 02 Apr '09

02 Apr '09

Feature added by: Kevin Dupuy (kdupuy9) Feature #305696, revision 1, last change by Title: Add YaST Functionalities under GNOME "Common Tasks" Header openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Kevin Dupuy (kdupuy9) Partner organization: openSUSE.org Description: Currently, the GNOME Control Center features a "Common Tasks" banner on the sidebar of the window. An an improvement, some common YaST tasks could be added under this banner (currently, only "Set Preferred Applications" is listed). Some possible functionality: * Add User Account * Add/remove software repositories * Open administrator settings* (opens YaST) *Because there is no other method of opening YaST besides actually knowing that one needs to open YaST (e.g., new user). -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305696

1 7

[openFATE 305928] CSV Export of the FATE Data
by fate_noreply＠suse.de 31 Mar '09

31 Mar '09

Feature added by: Sascha Manns (saigkill) Feature #305928, revision 1, last change by Title: CSV Export of the FATE Data openFATE: Unconfirmed Priority Requester: Neutral Requested by: Sascha Manns (saigkill) Description: In the Weekly News, we collect datas and spreadsheets and statistics. For bugzilla exists an Function for exporting in CSV. I wish me in common Versions of openFATE an Feature similar to the bugzilla. So we can easier collect Datas and publish it in the Weekly News.... -- openSUSE Feature: https://features.opensuse.org/305928

1 7

[openFATE 305878] extend lv and fs when installing packages
by fate_noreply＠suse.de 30 Mar '09

30 Mar '09

Feature added by: Dinar Valeev (Eri_zaq) Feature #305878, revision 1, last change by Title: extend lv and fs when installing packages openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Dinar Valeev (eri_zaq) Description: When system using lvm, and VG have free extents package manager should monitor that. And if FS is full and free extents is available we need to extend LV and FS before installing packages. This feature is very important for Enterprise. This feature is available in AIX. -- openSUSE Feature: https://features.opensuse.org/305878

1 1

[openFATE 305841] Be able to add proxy setting, choose network card and set wifi setting via Fx.
by fate_noreply＠suse.de 30 Mar '09

30 Mar '09

Feature added by: Joop Boonen (worldcitizen) Feature #305841, revision 1, last change by Title: Be able to add proxy setting, choose network card and set wifi setting via Fx. openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Joop Boonen (worldcitizen) Description: Be able to add proxy setting, choose network card and set wifi setting via one of the F(1..12) keys in the install screen. I think it'll be easier for less experienced users to install openSuSE via ftp/http when they are behind a proxy and firewall, want to user a certain network card and/or want to install via wifi. -- openSUSE Feature: https://features.opensuse.org/305841

1 2

[openFate 305170] openFATE test
by fate_noreply＠suse.de 05 Mar '09

05 Mar '09

Feature added by: Michael Loeffler <michl(a)novell.com> Feature #305170, revision 1, last change by Title: openFATE test openSUSE-11.1: Evaluation Priority Requester: Mandatory Requested by: Michael Loeffler <michl(a)novell.com> Partner organization: openSUSE.org Description: test Business case (Partner benefit): openSUSE.org: sdf -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305170

1 5

[openFATE 305715] Package event framework
by fate_noreply＠suse.de 28 Feb '09

28 Feb '09

Feature changed by: Casper Clemence (maninalift) Feature #305715, revision 12 Title: Package event framework openSUSE-11.2: New Priority Requester: Desirable Requested by: Andreas Gruenbacher (agruen) Description: The installation, upgrade, or removal of several packages triggers actions such as running ldconfig, rebuilding the initrd, or similar. Those actions are not specific to the package at hand, but either global with a system-wide effect (such as running ldconfig), or they affect a group of packages (such as all kernel (sub-)packages of a specific version, including all KMPs affecting it). Those actions need to be run eventually (with order restrictions relative to other package installs, upgrades, or removals), but running them again and again for each package is wasteful. (Example: with the kernel packages split into kernel-$flavor-base, kernel-$flavor, and kernel-$flavor-extra in CODE11, we currently run mkinitrd out of the %post script of each package. We don't know which of those packages will be installed, and when generating the initrd is supposed to succeed. This both wastes time, and we also cannot tell transient from permanent failures.) In former days, SuSEconfig was used for some of those tasks, but it turned into a major nightmare (perhaps due to its design). It would be nice if we could come up with a framework in which packages can trigger events and define which actions they need to be run, and rpm will then perform those actions in an appropriate order, avoiding repeating the same action unnecessarily. (The dependencies between actions and package installs/upgrades/removals are somewhat complex, but I think they are manageable.) Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 18:09:34) This is desirable only as it happens within RPM's framework (or if the additions are "candy" that does not affect the actual result). This includes upstreaming. I do not want to comment besides the RPM requirement until Engineering determines how (and if) to proceed. There are too many factors involved. Stano, Needinfo me back when you guys have a settled position or decide to postpone this one given the other priorities. #2: Klaus Kämpf (kwk) (2009-01-29 12:45:22) Actually, there is probably litte engineering can do or decide here imho. It very much depends on PMs long-term strategy for RPM. There are currently two options * One is to stay with rpm 4.x and keep the status quo. * The other is to move up to rpm5 and try to influence its development. Upstream implementation of the feature request can only happen within rpm5. Adopting rpm5 for the distribution has several prerequisites: * Investment into rpm5 development. * Getting more distributions to adopt rpm5. * Influencing Linux Standards Base to accept rpm5. Given recent comments from RedHat/Fedora, widespread rpm5 adoption looks rather unlikely. #3: Michael Schröder (mlschroe) (2009-01-29 12:50:19) (reply to #2) That sounds like rpm-4 doesn't get new features at all, which is simply not true. Actually I think it's probably easier to get new features into rpm-4, because it's very hard to convince Jeff of something he doesn't like, whereas Panu is more open. #4: Klaus Kämpf (kwk) (2009-01-29 13:22:30) (reply to #3) Now thats good to know. But this probably still needs a significant investment (and a fair bit of persuasion) into rpm4, I guess. + #5: Casper Clemence (maninalift) (2009-02-28 15:05:35) + I don't know about the issue of how the installer works but from a user + perspective the handling of multiple kernel flavours could certainly be + better. At the moment a symbolic link is automatically created at + /boot/vmlinuz pointing, rather arbitrarily IMO, to the most recently + updated kernel. Also the grub menu is messed with in an inept sort of a + way. + If instead symbolic links were created for each kernel flavour there + would be no need to change the grub menu except when new flavours were + installed or others removed, thus preserving all of the users other + boot settings. -- openSUSE Feature: https://features.opensuse.org/305715

1 0

[openFATE 302921] Testing openSUSE Feature Tracking
by fate_noreply＠suse.de 26 Feb '09

26 Feb '09

Feature changed by: Andrey Karepin (EGDFree) Feature #302921, revision 33 Title: Testing openSUSE Feature Tracking openSUSE-10.3: Done Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Description: Just a test - should go to opensuse-features(a)opensuse.org yes we can!!!!!! Discussion: #1: Hendrik Vogelsang (hennevogel) (2007-10-30 13:00:36) blah blah blah #2: Hendrik Vogelsang (hennevogel) (2007-10-30 13:02:35) (reply to #1) blubb lubb lbuib #13: Hendrik Vogelsang (hennevogel) (2007-10-30 13:57:04) (reply to #1) dsdsdwsd #14: Hendrik Vogelsang (hennevogel) (2007-10-30 13:59:12) (reply to #13) wsdsdsds #15: Hendrik Vogelsang (hennevogel) (2007-10-30 14:01:10) (reply to #13) dsdsds #16: Hendrik Vogelsang (hennevogel) (2007-10-30 14:11:35) (reply to #13) ddsddds #3: Hendrik Vogelsang (hennevogel) (2007-10-30 13:12:39) this is working #4: Hendrik Vogelsang (hennevogel) (2007-10-30 13:16:03) (reply to #3) or bnot #10: Hendrik Vogelsang (hennevogel) (2007-10-30 13:48:53) (reply to #3) dwsdsdsd #5: Hendrik Vogelsang (hennevogel) (2007-10-30 13:27:44) swsasaas #6: Hendrik Vogelsang (hennevogel) (2007-10-30 13:33:36) sqsqasas #7: Hendrik Vogelsang (hennevogel) (2007-10-30 13:36:11) wdwdswd #8: Hendrik Vogelsang (hennevogel) (2007-10-30 13:38:00) dwsdsds #9: Hendrik Vogelsang (hennevogel) (2007-10-30 13:46:33) wswdds #11: Michael Loeffler (sprudel24) (2007-10-30 13:49:14) wjnd sd s�dlkj sid #12: Hendrik Vogelsang (hennevogel) (2007-10-30 13:52:27) (reply to #11) sasasas #17: Hendrik Vogelsang (hennevogel) (2007-10-30 14:48:56) (reply to #12) xdsdsds #18: Gerald Pfeifer (geraldpfeifer) (2007-11-02 21:51:25) Moving from openSUSE 10.3 to openSUSE 11.0. #19: Juergen Weigert (jnweiger) (2008-07-29 21:53:03) ping-pong. #20: Thomas Schmidt (digitaltomm) (2009-01-05 15:54:14) test... updated keeper #21: Jan Engelhardt (jengelh) (2009-02-02 13:45:36) My comment is supposed not to be saved! #22: Andrey Karepin (egdfree) (2009-02-24 16:41:58) https://bugzilla.novell.com/show_bug.cgi?id=478760 + #23: Andrey Karepin (egdfree) (2009-02-26 17:25:35) + if you paste the text in the box to search through the context menu + (right mouse button), the text "Text Search or ID" is not removed + automatically -- openSUSE Feature: https://features.opensuse.org/302921

1 0

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

24 Feb '09

Feature changed by: andrea florio (anubisg1) Feature #305296, revision 44 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree #11: Jean-Daniel Dodin (jdd) (2009-02-15 10:12:29) (reply to #1) +1 #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) Beagle should be disabled by default. Everyone in the DFW Linux Users Group complained when Suse added it. It causes nothing but trouble for me. #12: Bart Otten (bartotten) (2009-02-16 01:13:58) I agree with the people voting to disable it by default. I think we have to keep focus on the 'consumer' and most of them won't use Kerry/Beagle. ps. KDE4 -and- Beagle is useless. KDE4 uses Strigi and Nepomuk. #13: Sebastian Rösgen (palimpseste) (2009-02-17 12:55:11) Despite all who now have voted for this proposal, I just have to vote against it. At least in the forms discussed here. I use Beagle heavily as do some other people I got convinced to use openSUSE instead of Windows. A good Desktop search was among the arguments to move these people to change their OS (others arguments were Deskbar etc... which btw. does not necessarily need Beagle but gets some interesting advantages IF Beagle is activated). Why not simply ask at startup how to configure some basic system defaults. Among them there could be beagle. So concerning the proposals of Federico Lucifredi, Stephan Kulow and so on, I am definitively of the same mind. Beagle should be installed by default, but it should be easy to switch it "on" or "off" whenever one wants. #14: Eric Springer (erikina) (2009-02-18 01:05:18) (reply to #13) Yes, a search is very useful. Yes, some people find beagle beneficial (as apparently you do). But the vast majority (Currently the vote is at 47:1) of people it doesn't work well with. And that's truly an amazing statistic, as it's super easy to see and use the feature it provides but much harder to see that it's beagle causing so many (resource related) problems. And if that statistic alone isn't enough to convince you it's not a sensible default, then I have absolutely no idea how to. There really should be a resemblance of QA in place, especially for default (and completely optional) packages. #15: Sebastian Rösgen (palimpseste) (2009-02-19 12:04:23) (reply to #14) Ok, I hope that my comment did not sound as gruff or ... brusque, for I, basically, hoped to present a different opinion. What I did not intend was to, evidently, irritate somebody by not completely assenting to his opinion. See: I am working for a university in Germany. We have 45.000 students and a staff of employees of a size appropriate for this amount of students. We rely heavily on the capabilities of a search system (to be honest: in this case not beagle, but somethings similar to beagle). I am one person who posts here but, to stay in your line of argumentation, statistically I represent so many single individuals, that my vote could be multiplied by a "pretty fight factor". Now the problem is that most of these people just use a search feature but do not understand of configure it. But they will notice when it is gone . These users do not vote, they are not involved in community work, they are not programmers, not system architects, not members of an online community. But they use systems like beagle. I know, as I stated in my first post, some people, which I got to switch their OS, from Windows to openSUSE. These people will miss features, too. Especially if you are so eager so simple remove this feature despite the fact that it was part of the distribution for many years. The more I write here, the angrier I get. I mentioned that Lucifredi and Kulow are of another opinion (disable but no remove the software; make it possible to switch it on or off when needed), an opinion I agree with. Is it possible that YOU ignored that part? This is quite normale for the usual open source community. To me it is a relatively illusive concept, the more I deal with it (and I deal with it for now 9 years) the more I learn about the ignorance it contains. Too many people choose rather to ignore those who have to vote (usually called users) and instead see their opinion as the ultimate measure to decide pro and contra. Did it come to your mind that about 80-90% of those who start to create an account for a portal like openFATE, who pay the time to write some comments and skip through all these proposals in this portal, that 80-90% of these people might perhaps be programmers? Geeks and nerds as they are called nowadays. This is no real statistic representing the opinion of those who use a software, it is a statistic of those how develop a software. Make this clear to you. So to get back on a rather rational level: I recognize that you are of another opinion. That most of the people here are. But, and that was important to me, these votes in here are not a real representation of opinions. I prefer openSUSE after all these years espcially because it was bought by Novell. Because they do research in usability, which is the only real way to ask the customers/the users, how to design the software. That is why I said, that an easy startup QA for the normal user is the best to do. Do not be too ignorant. The users know what they want, even if they miss some technical versatily, they will still take note of features that are missing, of bugs in the browser, of missing parts in the system "that they know worked on a different OS" or whatever else. Perhaps they annot name the source of the problem and do not know if it is a real design issue or a real bug. But they will say that the feature is not how they expected it to be. I recently said to a colleague of mine that the times of Mac OS are nearly over. The only real advantage they have is that they can design an OS without paying too much attention to different hardware. They know exactly which hardware their OS will possible have to run on. If Linux with a nice GNOME, KDE, or-whatever-desktop would run out of the box on ANY posible hardware, with all features running without a problem (Audio, Bluetooth, 3D Graphics are still a problem as we know) it would be undeniable that Linux will be the winner. I see progress made well into that direction. I see that Linux is close to this goal, to solve these issues in nears time (most Graphic Cards now easily work, with only a few exceptions). So please do not disappoint me. I have to lead discussions about Linux/Windows and Linux/MacOSX nearly every week. I do not want to have them led in vain. Look at what Mac and Windows do, they have a search system with an index. Make ours betters, faster and less memory hungry instead of removing it. These who switch from Windows/Mac to Linux (for instance to openSUSE) want to find new and more useful features instead of fewer features. I know this post was too long. I am sorry, but it thought it necessary. #16: Eric Springer (erikina) (2009-02-19 14:33:07) (reply to #15) I agree with everything you said, but you must realize I/we aren't arguing against search. We're arguing against beagle. I personally use google desktop search on a daily basis. And it works well. I assume that it does all its work when I'm not physically using the computer (a policy that is ideal for desktop usage). I'm not advocating its inclusion (primarily license reasons and kde integration reasons) but you should see that I'm not against a search or anything like that. Beagle on the other hand, I've tried to give it a fair shot a few times. To see if it has improved (something I will admit Banshee has done). But its *always* problematic. Something that is echoed daily on IRC and the mailing lists. The firefox extension causes huge amounts errors and slow downs. The actual search program maxs out the CPU. IO brings the computer to a crawl when I need to get work done etc. It's just not pretty. So if Beagle works well, I'd love to use it. But it doesn't and shouldn't be included. Put it this way. I would really like to see kernel initialization of graphics devices. However, until it's finished and works properly -- I think we'd both agree that it shouldn't be on our systems. I know it's not a good test for everything, but have you noticed how many other desktop distros have chosen to include beagle? #17: Sebastian Rösgen (palimpseste) (2009-02-19 18:16:48) (reply to #16) Ok, I see your point. Perhaps beagle is indeed not a good solution and I was too narrow minded to realize it. (Though I haven't experienced the CPU problems anymore for about one year, I suppose you are right). Especially since the development of beagle has come to a crawl (the last release: 0.3.9 was released about four weeks ago but it needed nearly half a year to be released and contains only some mere bug fixes). I think, I am going to open a new feature request in openFate. If you (and the other guys) are not against desktop search, but instead against beagle, it could be interesting to discuss why Tracker (http://projects.gnome.org/tracker/index.html) should not become a replacement for beagle. Especially since KDE has now Strigi as a core component. So one can get rid of beagle and use some "quasi native" tools for desktop search (namely "strigi" and "tracker") on Gnome and, respectively, KDE. Anyway, thanks for your reply and the discussion. #18: Sebastian Rösgen (palimpseste) (2009-02-19 18:23:53) (reply to #17) Hm, as it seems I cannot open such a request. Wonderful! So perhaps somebody has read this discussion and might be so kind to at least evaluate the request and "perhaps" might open a new feature request concerning the replacement of beagle by Tracker (which is a Gnome Desktop search, but since KDE has already its own Desktop search this should not be that problematic... I hope) And before somebody asks: no I will not file a feature request via bug tracking system. Those usually take weeks or even months before they are answered/evaluated/discussed etc... #19: Federico Lucifredi (flucifredi) (2009-02-19 16:52:12) (reply to #18) Hello Sebastian - I do not take the thread as being "against desktop search", which is a great feature, or against Beagle, which I personally run. The decision is only to have Beagle not be running by default out of the box, but to have it installed and ready. The first time a search is performed, we ask. Users who want desktop search select to run it, and those who are more "frugal" in terms of CPU do not. I am running a 3 year old laptop, and Beagle is running just fine for me. I suspect that's the case for a lot of people. But it is still a good idea to ask for a choice. #20: Eric Springer (erikina) (2009-02-22 03:03:55) (reply to #17) 100% agree. I think tracker/strigi make wonderful replacements. :) + #22: andrea florio (anubisg1) (2009-02-25 00:40:51) (reply to #20) + indeed... beagle is to heavy, traker instead, is simply wonderful! #21: Stanislav Visnovsky (visnov) (2009-02-24 09:10:56) Coolo, I believe this should be done via patterns. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 302921] Testing openSUSE Feature Tracking
by fate_noreply＠suse.de 24 Feb '09

24 Feb '09

Feature changed by: Thomas Schmidt (digitaltomm) Feature #302921, revision 32 Title: Testing openSUSE Feature Tracking openSUSE-10.3: Done Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Description: Just a test - should go to opensuse-features(a)opensuse.org - yes we can!!!!! + yes we can!!!!!! Discussion: #1: Hendrik Vogelsang (hennevogel) (2007-10-30 13:00:36) blah blah blah #2: Hendrik Vogelsang (hennevogel) (2007-10-30 13:02:35) (reply to #1) blubb lubb lbuib #13: Hendrik Vogelsang (hennevogel) (2007-10-30 13:57:04) (reply to #1) dsdsdwsd #14: Hendrik Vogelsang (hennevogel) (2007-10-30 13:59:12) (reply to #13) wsdsdsds #15: Hendrik Vogelsang (hennevogel) (2007-10-30 14:01:10) (reply to #13) dsdsds #16: Hendrik Vogelsang (hennevogel) (2007-10-30 14:11:35) (reply to #13) ddsddds #3: Hendrik Vogelsang (hennevogel) (2007-10-30 13:12:39) this is working #4: Hendrik Vogelsang (hennevogel) (2007-10-30 13:16:03) (reply to #3) or bnot #10: Hendrik Vogelsang (hennevogel) (2007-10-30 13:48:53) (reply to #3) dwsdsdsd #5: Hendrik Vogelsang (hennevogel) (2007-10-30 13:27:44) swsasaas #6: Hendrik Vogelsang (hennevogel) (2007-10-30 13:33:36) sqsqasas #7: Hendrik Vogelsang (hennevogel) (2007-10-30 13:36:11) wdwdswd #8: Hendrik Vogelsang (hennevogel) (2007-10-30 13:38:00) dwsdsds #9: Hendrik Vogelsang (hennevogel) (2007-10-30 13:46:33) wswdds #11: Michael Loeffler (sprudel24) (2007-10-30 13:49:14) wjnd sd s�dlkj sid #12: Hendrik Vogelsang (hennevogel) (2007-10-30 13:52:27) (reply to #11) sasasas #17: Hendrik Vogelsang (hennevogel) (2007-10-30 14:48:56) (reply to #12) xdsdsds #18: Gerald Pfeifer (geraldpfeifer) (2007-11-02 21:51:25) Moving from openSUSE 10.3 to openSUSE 11.0. #19: Juergen Weigert (jnweiger) (2008-07-29 21:53:03) ping-pong. #20: Thomas Schmidt (digitaltomm) (2009-01-05 15:54:14) test... updated keeper #21: Jan Engelhardt (jengelh) (2009-02-02 13:45:36) My comment is supposed not to be saved! #22: Andrey Karepin (egdfree) (2009-02-24 16:41:58) https://bugzilla.novell.com/show_bug.cgi?id=478760 -- openSUSE Feature: https://features.opensuse.org/302921

1 0

[openFATE 302921] Testing openSUSE Feature Tracking
by fate_noreply＠suse.de 24 Feb '09

24 Feb '09

Feature changed by: Thomas Schmidt (digitaltomm) Feature #302921, revision 31 Title: Testing openSUSE Feature Tracking openSUSE-10.3: Done Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Description: Just a test - should go to opensuse-features(a)opensuse.org - yes we can!!!! + yes we can!!!!! Discussion: #1: Hendrik Vogelsang (hennevogel) (2007-10-30 13:00:36) blah blah blah #2: Hendrik Vogelsang (hennevogel) (2007-10-30 13:02:35) (reply to #1) blubb lubb lbuib #13: Hendrik Vogelsang (hennevogel) (2007-10-30 13:57:04) (reply to #1) dsdsdwsd #14: Hendrik Vogelsang (hennevogel) (2007-10-30 13:59:12) (reply to #13) wsdsdsds #15: Hendrik Vogelsang (hennevogel) (2007-10-30 14:01:10) (reply to #13) dsdsds #16: Hendrik Vogelsang (hennevogel) (2007-10-30 14:11:35) (reply to #13) ddsddds #3: Hendrik Vogelsang (hennevogel) (2007-10-30 13:12:39) this is working #4: Hendrik Vogelsang (hennevogel) (2007-10-30 13:16:03) (reply to #3) or bnot #10: Hendrik Vogelsang (hennevogel) (2007-10-30 13:48:53) (reply to #3) dwsdsdsd #5: Hendrik Vogelsang (hennevogel) (2007-10-30 13:27:44) swsasaas #6: Hendrik Vogelsang (hennevogel) (2007-10-30 13:33:36) sqsqasas #7: Hendrik Vogelsang (hennevogel) (2007-10-30 13:36:11) wdwdswd #8: Hendrik Vogelsang (hennevogel) (2007-10-30 13:38:00) dwsdsds #9: Hendrik Vogelsang (hennevogel) (2007-10-30 13:46:33) wswdds #11: Michael Loeffler (sprudel24) (2007-10-30 13:49:14) wjnd sd s�dlkj sid #12: Hendrik Vogelsang (hennevogel) (2007-10-30 13:52:27) (reply to #11) sasasas #17: Hendrik Vogelsang (hennevogel) (2007-10-30 14:48:56) (reply to #12) xdsdsds #18: Gerald Pfeifer (geraldpfeifer) (2007-11-02 21:51:25) Moving from openSUSE 10.3 to openSUSE 11.0. #19: Juergen Weigert (jnweiger) (2008-07-29 21:53:03) ping-pong. #20: Thomas Schmidt (digitaltomm) (2009-01-05 15:54:14) test... updated keeper #21: Jan Engelhardt (jengelh) (2009-02-02 13:45:36) My comment is supposed not to be saved! #22: Andrey Karepin (egdfree) (2009-02-24 16:41:58) https://bugzilla.novell.com/show_bug.cgi?id=478760 -- openSUSE Feature: https://features.opensuse.org/302921

1 0

[openFATE 302921] Testing openSUSE Feature Tracking
by fate_noreply＠suse.de 24 Feb '09

24 Feb '09

Feature changed by: Thomas Schmidt (digitaltomm) Feature #302921, revision 30 Title: Testing openSUSE Feature Tracking openSUSE-10.3: Done Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Description: Just a test - should go to opensuse-features(a)opensuse.org - yes we can!!! + yes we can!!!! Discussion: #1: Hendrik Vogelsang (hennevogel) (2007-10-30 13:00:36) blah blah blah #2: Hendrik Vogelsang (hennevogel) (2007-10-30 13:02:35) (reply to #1) blubb lubb lbuib #13: Hendrik Vogelsang (hennevogel) (2007-10-30 13:57:04) (reply to #1) dsdsdwsd #14: Hendrik Vogelsang (hennevogel) (2007-10-30 13:59:12) (reply to #13) wsdsdsds #15: Hendrik Vogelsang (hennevogel) (2007-10-30 14:01:10) (reply to #13) dsdsds #16: Hendrik Vogelsang (hennevogel) (2007-10-30 14:11:35) (reply to #13) ddsddds #3: Hendrik Vogelsang (hennevogel) (2007-10-30 13:12:39) this is working #4: Hendrik Vogelsang (hennevogel) (2007-10-30 13:16:03) (reply to #3) or bnot #10: Hendrik Vogelsang (hennevogel) (2007-10-30 13:48:53) (reply to #3) dwsdsdsd #5: Hendrik Vogelsang (hennevogel) (2007-10-30 13:27:44) swsasaas #6: Hendrik Vogelsang (hennevogel) (2007-10-30 13:33:36) sqsqasas #7: Hendrik Vogelsang (hennevogel) (2007-10-30 13:36:11) wdwdswd #8: Hendrik Vogelsang (hennevogel) (2007-10-30 13:38:00) dwsdsds #9: Hendrik Vogelsang (hennevogel) (2007-10-30 13:46:33) wswdds #11: Michael Loeffler (sprudel24) (2007-10-30 13:49:14) wjnd sd s�dlkj sid #12: Hendrik Vogelsang (hennevogel) (2007-10-30 13:52:27) (reply to #11) sasasas #17: Hendrik Vogelsang (hennevogel) (2007-10-30 14:48:56) (reply to #12) xdsdsds #18: Gerald Pfeifer (geraldpfeifer) (2007-11-02 21:51:25) Moving from openSUSE 10.3 to openSUSE 11.0. #19: Juergen Weigert (jnweiger) (2008-07-29 21:53:03) ping-pong. #20: Thomas Schmidt (digitaltomm) (2009-01-05 15:54:14) test... updated keeper #21: Jan Engelhardt (jengelh) (2009-02-02 13:45:36) My comment is supposed not to be saved! #22: Andrey Karepin (egdfree) (2009-02-24 16:41:58) https://bugzilla.novell.com/show_bug.cgi?id=478760 -- openSUSE Feature: https://features.opensuse.org/302921

1 0

[openFATE 302921] Testing openSUSE Feature Tracking
by fate_noreply＠suse.de 24 Feb '09

24 Feb '09

Feature changed by: Thomas Schmidt (digitaltomm) Feature #302921, revision 29 Title: Testing openSUSE Feature Tracking openSUSE-10.3: Done Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Description: Just a test - should go to opensuse-features(a)opensuse.org - yes we can!! + yes we can!!! Discussion: #1: Hendrik Vogelsang (hennevogel) (2007-10-30 13:00:36) blah blah blah #2: Hendrik Vogelsang (hennevogel) (2007-10-30 13:02:35) (reply to #1) blubb lubb lbuib #13: Hendrik Vogelsang (hennevogel) (2007-10-30 13:57:04) (reply to #1) dsdsdwsd #14: Hendrik Vogelsang (hennevogel) (2007-10-30 13:59:12) (reply to #13) wsdsdsds #15: Hendrik Vogelsang (hennevogel) (2007-10-30 14:01:10) (reply to #13) dsdsds #16: Hendrik Vogelsang (hennevogel) (2007-10-30 14:11:35) (reply to #13) ddsddds #3: Hendrik Vogelsang (hennevogel) (2007-10-30 13:12:39) this is working #4: Hendrik Vogelsang (hennevogel) (2007-10-30 13:16:03) (reply to #3) or bnot #10: Hendrik Vogelsang (hennevogel) (2007-10-30 13:48:53) (reply to #3) dwsdsdsd #5: Hendrik Vogelsang (hennevogel) (2007-10-30 13:27:44) swsasaas #6: Hendrik Vogelsang (hennevogel) (2007-10-30 13:33:36) sqsqasas #7: Hendrik Vogelsang (hennevogel) (2007-10-30 13:36:11) wdwdswd #8: Hendrik Vogelsang (hennevogel) (2007-10-30 13:38:00) dwsdsds #9: Hendrik Vogelsang (hennevogel) (2007-10-30 13:46:33) wswdds #11: Michael Loeffler (sprudel24) (2007-10-30 13:49:14) wjnd sd s�dlkj sid #12: Hendrik Vogelsang (hennevogel) (2007-10-30 13:52:27) (reply to #11) sasasas #17: Hendrik Vogelsang (hennevogel) (2007-10-30 14:48:56) (reply to #12) xdsdsds #18: Gerald Pfeifer (geraldpfeifer) (2007-11-02 21:51:25) Moving from openSUSE 10.3 to openSUSE 11.0. #19: Juergen Weigert (jnweiger) (2008-07-29 21:53:03) ping-pong. #20: Thomas Schmidt (digitaltomm) (2009-01-05 15:54:14) test... updated keeper #21: Jan Engelhardt (jengelh) (2009-02-02 13:45:36) My comment is supposed not to be saved! #22: Andrey Karepin (egdfree) (2009-02-24 16:41:58) https://bugzilla.novell.com/show_bug.cgi?id=478760 -- openSUSE Feature: https://features.opensuse.org/302921

1 0

[openFATE 302921] Testing openSUSE Feature Tracking
by fate_noreply＠suse.de 24 Feb '09

24 Feb '09

Feature changed by: Thomas Schmidt (digitaltomm) Feature #302921, revision 28 Title: Testing openSUSE Feature Tracking openSUSE-10.3: Done Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Description: Just a test - should go to opensuse-features(a)opensuse.org - yes we can! + yes we can!! Discussion: #1: Hendrik Vogelsang (hennevogel) (2007-10-30 13:00:36) blah blah blah #2: Hendrik Vogelsang (hennevogel) (2007-10-30 13:02:35) (reply to #1) blubb lubb lbuib #13: Hendrik Vogelsang (hennevogel) (2007-10-30 13:57:04) (reply to #1) dsdsdwsd #14: Hendrik Vogelsang (hennevogel) (2007-10-30 13:59:12) (reply to #13) wsdsdsds #15: Hendrik Vogelsang (hennevogel) (2007-10-30 14:01:10) (reply to #13) dsdsds #16: Hendrik Vogelsang (hennevogel) (2007-10-30 14:11:35) (reply to #13) ddsddds #3: Hendrik Vogelsang (hennevogel) (2007-10-30 13:12:39) this is working #4: Hendrik Vogelsang (hennevogel) (2007-10-30 13:16:03) (reply to #3) or bnot #10: Hendrik Vogelsang (hennevogel) (2007-10-30 13:48:53) (reply to #3) dwsdsdsd #5: Hendrik Vogelsang (hennevogel) (2007-10-30 13:27:44) swsasaas #6: Hendrik Vogelsang (hennevogel) (2007-10-30 13:33:36) sqsqasas #7: Hendrik Vogelsang (hennevogel) (2007-10-30 13:36:11) wdwdswd #8: Hendrik Vogelsang (hennevogel) (2007-10-30 13:38:00) dwsdsds #9: Hendrik Vogelsang (hennevogel) (2007-10-30 13:46:33) wswdds #11: Michael Loeffler (sprudel24) (2007-10-30 13:49:14) wjnd sd s�dlkj sid #12: Hendrik Vogelsang (hennevogel) (2007-10-30 13:52:27) (reply to #11) sasasas #17: Hendrik Vogelsang (hennevogel) (2007-10-30 14:48:56) (reply to #12) xdsdsds #18: Gerald Pfeifer (geraldpfeifer) (2007-11-02 21:51:25) Moving from openSUSE 10.3 to openSUSE 11.0. #19: Juergen Weigert (jnweiger) (2008-07-29 21:53:03) ping-pong. #20: Thomas Schmidt (digitaltomm) (2009-01-05 15:54:14) test... updated keeper #21: Jan Engelhardt (jengelh) (2009-02-02 13:45:36) My comment is supposed not to be saved! #22: Andrey Karepin (egdfree) (2009-02-24 16:41:58) https://bugzilla.novell.com/show_bug.cgi?id=478760 -- openSUSE Feature: https://features.opensuse.org/302921

1 0

[openFATE 302921] Testing openSUSE Feature Tracking
by fate_noreply＠suse.de 24 Feb '09

24 Feb '09

Feature changed by: Thomas Schmidt (digitaltomm) Feature #302921, revision 27 Title: Testing openSUSE Feature Tracking openSUSE-10.3: Done Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Description: Just a test - should go to opensuse-features(a)opensuse.org - yes we can + yes we can! Discussion: #1: Hendrik Vogelsang (hennevogel) (2007-10-30 13:00:36) blah blah blah #2: Hendrik Vogelsang (hennevogel) (2007-10-30 13:02:35) (reply to #1) blubb lubb lbuib #13: Hendrik Vogelsang (hennevogel) (2007-10-30 13:57:04) (reply to #1) dsdsdwsd #14: Hendrik Vogelsang (hennevogel) (2007-10-30 13:59:12) (reply to #13) wsdsdsds #15: Hendrik Vogelsang (hennevogel) (2007-10-30 14:01:10) (reply to #13) dsdsds #16: Hendrik Vogelsang (hennevogel) (2007-10-30 14:11:35) (reply to #13) ddsddds #3: Hendrik Vogelsang (hennevogel) (2007-10-30 13:12:39) this is working #4: Hendrik Vogelsang (hennevogel) (2007-10-30 13:16:03) (reply to #3) or bnot #10: Hendrik Vogelsang (hennevogel) (2007-10-30 13:48:53) (reply to #3) dwsdsdsd #5: Hendrik Vogelsang (hennevogel) (2007-10-30 13:27:44) swsasaas #6: Hendrik Vogelsang (hennevogel) (2007-10-30 13:33:36) sqsqasas #7: Hendrik Vogelsang (hennevogel) (2007-10-30 13:36:11) wdwdswd #8: Hendrik Vogelsang (hennevogel) (2007-10-30 13:38:00) dwsdsds #9: Hendrik Vogelsang (hennevogel) (2007-10-30 13:46:33) wswdds #11: Michael Loeffler (sprudel24) (2007-10-30 13:49:14) wjnd sd s�dlkj sid #12: Hendrik Vogelsang (hennevogel) (2007-10-30 13:52:27) (reply to #11) sasasas #17: Hendrik Vogelsang (hennevogel) (2007-10-30 14:48:56) (reply to #12) xdsdsds #18: Gerald Pfeifer (geraldpfeifer) (2007-11-02 21:51:25) Moving from openSUSE 10.3 to openSUSE 11.0. #19: Juergen Weigert (jnweiger) (2008-07-29 21:53:03) ping-pong. #20: Thomas Schmidt (digitaltomm) (2009-01-05 15:54:14) test... updated keeper #21: Jan Engelhardt (jengelh) (2009-02-02 13:45:36) My comment is supposed not to be saved! #22: Andrey Karepin (egdfree) (2009-02-24 16:41:58) https://bugzilla.novell.com/show_bug.cgi?id=478760 -- openSUSE Feature: https://features.opensuse.org/302921

1 0

[openFATE 302921] Testing openSUSE Feature Tracking
by fate_noreply＠suse.de 24 Feb '09

24 Feb '09

Feature changed by: Andrey Karepin (EGDFree) Feature #302921, revision 26 Title: Testing openSUSE Feature Tracking openSUSE-10.3: Done Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Description: Just a test - should go to opensuse-features(a)opensuse.org yes we can Discussion: #1: Hendrik Vogelsang (hennevogel) (2007-10-30 13:00:36) blah blah blah #2: Hendrik Vogelsang (hennevogel) (2007-10-30 13:02:35) (reply to #1) blubb lubb lbuib #13: Hendrik Vogelsang (hennevogel) (2007-10-30 13:57:04) (reply to #1) dsdsdwsd #14: Hendrik Vogelsang (hennevogel) (2007-10-30 13:59:12) (reply to #13) wsdsdsds #15: Hendrik Vogelsang (hennevogel) (2007-10-30 14:01:10) (reply to #13) dsdsds #16: Hendrik Vogelsang (hennevogel) (2007-10-30 14:11:35) (reply to #13) ddsddds #3: Hendrik Vogelsang (hennevogel) (2007-10-30 13:12:39) this is working #4: Hendrik Vogelsang (hennevogel) (2007-10-30 13:16:03) (reply to #3) or bnot #10: Hendrik Vogelsang (hennevogel) (2007-10-30 13:48:53) (reply to #3) dwsdsdsd #5: Hendrik Vogelsang (hennevogel) (2007-10-30 13:27:44) swsasaas #6: Hendrik Vogelsang (hennevogel) (2007-10-30 13:33:36) sqsqasas #7: Hendrik Vogelsang (hennevogel) (2007-10-30 13:36:11) wdwdswd #8: Hendrik Vogelsang (hennevogel) (2007-10-30 13:38:00) dwsdsds #9: Hendrik Vogelsang (hennevogel) (2007-10-30 13:46:33) wswdds #11: Michael Loeffler (sprudel24) (2007-10-30 13:49:14) wjnd sd s�dlkj sid #12: Hendrik Vogelsang (hennevogel) (2007-10-30 13:52:27) (reply to #11) sasasas #17: Hendrik Vogelsang (hennevogel) (2007-10-30 14:48:56) (reply to #12) xdsdsds #18: Gerald Pfeifer (geraldpfeifer) (2007-11-02 21:51:25) Moving from openSUSE 10.3 to openSUSE 11.0. #19: Juergen Weigert (jnweiger) (2008-07-29 21:53:03) ping-pong. #20: Thomas Schmidt (digitaltomm) (2009-01-05 15:54:14) test... updated keeper #21: Jan Engelhardt (jengelh) (2009-02-02 13:45:36) My comment is supposed not to be saved! + #22: Andrey Karepin (egdfree) (2009-02-24 16:41:58) + https://bugzilla.novell.com/show_bug.cgi?id=478760 -- openSUSE Feature: https://features.opensuse.org/302921

1 0

[openFATE 302921] Testing openSUSE Feature Tracking
by fate_noreply＠suse.de 24 Feb '09

24 Feb '09

Feature changed by: Thomas Schmidt (digitaltomm) Feature #302921, revision 25 Title: Testing openSUSE Feature Tracking openSUSE-10.3: Done Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Description: Just a test - should go to opensuse-features(a)opensuse.org + yes we can Discussion: #1: Hendrik Vogelsang (hennevogel) (2007-10-30 13:00:36) blah blah blah #2: Hendrik Vogelsang (hennevogel) (2007-10-30 13:02:35) (reply to #1) blubb lubb lbuib #13: Hendrik Vogelsang (hennevogel) (2007-10-30 13:57:04) (reply to #1) dsdsdwsd #14: Hendrik Vogelsang (hennevogel) (2007-10-30 13:59:12) (reply to #13) wsdsdsds #15: Hendrik Vogelsang (hennevogel) (2007-10-30 14:01:10) (reply to #13) dsdsds #16: Hendrik Vogelsang (hennevogel) (2007-10-30 14:11:35) (reply to #13) ddsddds #3: Hendrik Vogelsang (hennevogel) (2007-10-30 13:12:39) this is working #4: Hendrik Vogelsang (hennevogel) (2007-10-30 13:16:03) (reply to #3) or bnot #10: Hendrik Vogelsang (hennevogel) (2007-10-30 13:48:53) (reply to #3) dwsdsdsd #5: Hendrik Vogelsang (hennevogel) (2007-10-30 13:27:44) swsasaas #6: Hendrik Vogelsang (hennevogel) (2007-10-30 13:33:36) sqsqasas #7: Hendrik Vogelsang (hennevogel) (2007-10-30 13:36:11) wdwdswd #8: Hendrik Vogelsang (hennevogel) (2007-10-30 13:38:00) dwsdsds #9: Hendrik Vogelsang (hennevogel) (2007-10-30 13:46:33) wswdds #11: Michael Loeffler (sprudel24) (2007-10-30 13:49:14) wjnd sd s�dlkj sid #12: Hendrik Vogelsang (hennevogel) (2007-10-30 13:52:27) (reply to #11) sasasas #17: Hendrik Vogelsang (hennevogel) (2007-10-30 14:48:56) (reply to #12) xdsdsds #18: Gerald Pfeifer (geraldpfeifer) (2007-11-02 21:51:25) Moving from openSUSE 10.3 to openSUSE 11.0. #19: Juergen Weigert (jnweiger) (2008-07-29 21:53:03) ping-pong. #20: Thomas Schmidt (digitaltomm) (2009-01-05 15:54:14) test... updated keeper #21: Jan Engelhardt (jengelh) (2009-02-02 13:45:36) My comment is supposed not to be saved! -- openSUSE Feature: https://features.opensuse.org/302921

1 0

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

24 Feb '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #305296, revision 43 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree #11: Jean-Daniel Dodin (jdd) (2009-02-15 10:12:29) (reply to #1) +1 #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) Beagle should be disabled by default. Everyone in the DFW Linux Users Group complained when Suse added it. It causes nothing but trouble for me. #12: Bart Otten (bartotten) (2009-02-16 01:13:58) I agree with the people voting to disable it by default. I think we have to keep focus on the 'consumer' and most of them won't use Kerry/Beagle. ps. KDE4 -and- Beagle is useless. KDE4 uses Strigi and Nepomuk. #13: Sebastian Rösgen (palimpseste) (2009-02-17 12:55:11) Despite all who now have voted for this proposal, I just have to vote against it. At least in the forms discussed here. I use Beagle heavily as do some other people I got convinced to use openSUSE instead of Windows. A good Desktop search was among the arguments to move these people to change their OS (others arguments were Deskbar etc... which btw. does not necessarily need Beagle but gets some interesting advantages IF Beagle is activated). Why not simply ask at startup how to configure some basic system defaults. Among them there could be beagle. So concerning the proposals of Federico Lucifredi, Stephan Kulow and so on, I am definitively of the same mind. Beagle should be installed by default, but it should be easy to switch it "on" or "off" whenever one wants. #14: Eric Springer (erikina) (2009-02-18 01:05:18) (reply to #13) Yes, a search is very useful. Yes, some people find beagle beneficial (as apparently you do). But the vast majority (Currently the vote is at 47:1) of people it doesn't work well with. And that's truly an amazing statistic, as it's super easy to see and use the feature it provides but much harder to see that it's beagle causing so many (resource related) problems. And if that statistic alone isn't enough to convince you it's not a sensible default, then I have absolutely no idea how to. There really should be a resemblance of QA in place, especially for default (and completely optional) packages. #15: Sebastian Rösgen (palimpseste) (2009-02-19 12:04:23) (reply to #14) Ok, I hope that my comment did not sound as gruff or ... brusque, for I, basically, hoped to present a different opinion. What I did not intend was to, evidently, irritate somebody by not completely assenting to his opinion. See: I am working for a university in Germany. We have 45.000 students and a staff of employees of a size appropriate for this amount of students. We rely heavily on the capabilities of a search system (to be honest: in this case not beagle, but somethings similar to beagle). I am one person who posts here but, to stay in your line of argumentation, statistically I represent so many single individuals, that my vote could be multiplied by a "pretty fight factor". Now the problem is that most of these people just use a search feature but do not understand of configure it. But they will notice when it is gone . These users do not vote, they are not involved in community work, they are not programmers, not system architects, not members of an online community. But they use systems like beagle. I know, as I stated in my first post, some people, which I got to switch their OS, from Windows to openSUSE. These people will miss features, too. Especially if you are so eager so simple remove this feature despite the fact that it was part of the distribution for many years. The more I write here, the angrier I get. I mentioned that Lucifredi and Kulow are of another opinion (disable but no remove the software; make it possible to switch it on or off when needed), an opinion I agree with. Is it possible that YOU ignored that part? This is quite normale for the usual open source community. To me it is a relatively illusive concept, the more I deal with it (and I deal with it for now 9 years) the more I learn about the ignorance it contains. Too many people choose rather to ignore those who have to vote (usually called users) and instead see their opinion as the ultimate measure to decide pro and contra. Did it come to your mind that about 80-90% of those who start to create an account for a portal like openFATE, who pay the time to write some comments and skip through all these proposals in this portal, that 80-90% of these people might perhaps be programmers? Geeks and nerds as they are called nowadays. This is no real statistic representing the opinion of those who use a software, it is a statistic of those how develop a software. Make this clear to you. So to get back on a rather rational level: I recognize that you are of another opinion. That most of the people here are. But, and that was important to me, these votes in here are not a real representation of opinions. I prefer openSUSE after all these years espcially because it was bought by Novell. Because they do research in usability, which is the only real way to ask the customers/the users, how to design the software. That is why I said, that an easy startup QA for the normal user is the best to do. Do not be too ignorant. The users know what they want, even if they miss some technical versatily, they will still take note of features that are missing, of bugs in the browser, of missing parts in the system "that they know worked on a different OS" or whatever else. Perhaps they annot name the source of the problem and do not know if it is a real design issue or a real bug. But they will say that the feature is not how they expected it to be. I recently said to a colleague of mine that the times of Mac OS are nearly over. The only real advantage they have is that they can design an OS without paying too much attention to different hardware. They know exactly which hardware their OS will possible have to run on. If Linux with a nice GNOME, KDE, or-whatever-desktop would run out of the box on ANY posible hardware, with all features running without a problem (Audio, Bluetooth, 3D Graphics are still a problem as we know) it would be undeniable that Linux will be the winner. I see progress made well into that direction. I see that Linux is close to this goal, to solve these issues in nears time (most Graphic Cards now easily work, with only a few exceptions). So please do not disappoint me. I have to lead discussions about Linux/Windows and Linux/MacOSX nearly every week. I do not want to have them led in vain. Look at what Mac and Windows do, they have a search system with an index. Make ours betters, faster and less memory hungry instead of removing it. These who switch from Windows/Mac to Linux (for instance to openSUSE) want to find new and more useful features instead of fewer features. I know this post was too long. I am sorry, but it thought it necessary. #16: Eric Springer (erikina) (2009-02-19 14:33:07) (reply to #15) I agree with everything you said, but you must realize I/we aren't arguing against search. We're arguing against beagle. I personally use google desktop search on a daily basis. And it works well. I assume that it does all its work when I'm not physically using the computer (a policy that is ideal for desktop usage). I'm not advocating its inclusion (primarily license reasons and kde integration reasons) but you should see that I'm not against a search or anything like that. Beagle on the other hand, I've tried to give it a fair shot a few times. To see if it has improved (something I will admit Banshee has done). But its *always* problematic. Something that is echoed daily on IRC and the mailing lists. The firefox extension causes huge amounts errors and slow downs. The actual search program maxs out the CPU. IO brings the computer to a crawl when I need to get work done etc. It's just not pretty. So if Beagle works well, I'd love to use it. But it doesn't and shouldn't be included. Put it this way. I would really like to see kernel initialization of graphics devices. However, until it's finished and works properly -- I think we'd both agree that it shouldn't be on our systems. I know it's not a good test for everything, but have you noticed how many other desktop distros have chosen to include beagle? #17: Sebastian Rösgen (palimpseste) (2009-02-19 18:16:48) (reply to #16) Ok, I see your point. Perhaps beagle is indeed not a good solution and I was too narrow minded to realize it. (Though I haven't experienced the CPU problems anymore for about one year, I suppose you are right). Especially since the development of beagle has come to a crawl (the last release: 0.3.9 was released about four weeks ago but it needed nearly half a year to be released and contains only some mere bug fixes). I think, I am going to open a new feature request in openFate. If you (and the other guys) are not against desktop search, but instead against beagle, it could be interesting to discuss why Tracker (http://projects.gnome.org/tracker/index.html) should not become a replacement for beagle. Especially since KDE has now Strigi as a core component. So one can get rid of beagle and use some "quasi native" tools for desktop search (namely "strigi" and "tracker") on Gnome and, respectively, KDE. Anyway, thanks for your reply and the discussion. #18: Sebastian Rösgen (palimpseste) (2009-02-19 18:23:53) (reply to #17) Hm, as it seems I cannot open such a request. Wonderful! So perhaps somebody has read this discussion and might be so kind to at least evaluate the request and "perhaps" might open a new feature request concerning the replacement of beagle by Tracker (which is a Gnome Desktop search, but since KDE has already its own Desktop search this should not be that problematic... I hope) And before somebody asks: no I will not file a feature request via bug tracking system. Those usually take weeks or even months before they are answered/evaluated/discussed etc... #19: Federico Lucifredi (flucifredi) (2009-02-19 16:52:12) (reply to #18) Hello Sebastian - I do not take the thread as being "against desktop search", which is a great feature, or against Beagle, which I personally run. The decision is only to have Beagle not be running by default out of the box, but to have it installed and ready. The first time a search is performed, we ask. Users who want desktop search select to run it, and those who are more "frugal" in terms of CPU do not. I am running a 3 year old laptop, and Beagle is running just fine for me. I suspect that's the case for a lot of people. But it is still a good idea to ask for a choice. #20: Eric Springer (erikina) (2009-02-22 03:03:55) (reply to #17) 100% agree. I think tracker/strigi make wonderful replacements. :) + #21: Stanislav Visnovsky (visnov) (2009-02-24 09:10:56) + Coolo, I believe this should be done via patterns. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 305848] Offer 1 Sole Default Facility to Process System Email
by fate_noreply＠suse.de 23 Feb '09

23 Feb '09

Feature added by: Scott Couston (zczc2311) Feature #305848, revision 1, last change by Title: Offer 1 Sole Default Facility to Process System Email openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Scott Couston (zczc2311) Description: Currently during installation we offer a user the ability to receive system email. What we don't show everyone that we need to configure an email Client to draining /var/mail/xxxxxx Consider that we have 10 PC on a LAN or a remote user providing system support. We really have no facility to process default system mail. I propose that we add a new network Service to YaST to define an 1. SMTP Server/IP 2. A Valid From Address 3. A Valid To Address 4. Optional password verification to SMTP Server 5. TLS/SSL Transfer via POP3 By configuring a default mail client system wide a sole user address within another part of the LAN will get all the system mail AND/OR a remote Administrator who job is to view system mail warnings etc. Yes I know we could use IMAP, but why not keep it very simple and use an SMTP Server we all know how to use and we all know how to set-up an email client wherever it may be. This would provide system wide continuity for all system mail and we can start offering more that the current security/Apparmour items into the future. I understand that adding anything to YaST is pushing it - But I think this really is a quick, easy and user friendly way of accomplishing the above. Once Established we can omit the option for a user to receive system mail OR if so selected fill in the initial info into the YaST Module above whilst drawing the attention to the user to complete YaST System Mail after installation. Your Thoughts? -- openSUSE Feature: https://features.opensuse.org/305848

1 1

[openFATE 305882] Create Custom Locale in YaST
by fate_noreply＠suse.de 23 Feb '09

23 Feb '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #305882, revision 2 Title: Create Custom Locale in YaST + openSUSE-11.2: New + Priority + Requester: Desirable Requested by: Stanislav Visnovsky (visnov) Description: In Gnome there is no easy way (GUI) to set date and time format independent of desktop language. I agree with the use of the locale framework in the Gnome desktop because locale should affect all apps, not just desktop ones, and I hope that KDE follows suit. However, regardless of what Gnome or KDE decides, a tool in YaST to create a custom locale (for apps using locale) and to at the same time set KDE desktop preferences or something similar would be benificial within YaST. In Suse 10.1 Gnome desktop and SLED 10 Gnome desktop it is very cumbersome to choose a default en_CA locale, US English keyboard, en_UK desktop language (since UK English spelling is closer to Canadian spelling), a Weekday Month Day, Year long format an ISO-8601 short date format (i.e. YYYY-MM-DD), and a 24hr time format. On other operating systems and in the KDE desktop it is easy to specify these regional settings (although the KDE settings only apply to KDE apps as far as I know). If there is already an easy way to set date format settings then please help me find it. Relations: - Create Custom Locale in YaST (novell/bugzilla/id: 188844) https://bugzilla.novell.com/show_bug.cgi?id=188844 Discussion: #3: Guy Lunardi (glunardi) (2008-12-09 15:36:53) Stano, I am cleaning up my bugs and finally got to this one. I think this could be useful indeed. A way to setup system-wide locale settings that would apply across the desktop environment and any other applications. This probably needs to be moved to Fate. Could we look into it for openSUSE 11.2 and SP1? -- openSUSE Feature: https://features.opensuse.org/305882

1 0

[openFATE 304911] Import all GPG keys at once before downloading the metadata from new repositories
by fate_noreply＠suse.de 23 Feb '09

23 Feb '09

Feature changed by: Dmitry Mittov (Michael_Knight) Feature #304911, revision 17 Title: Import all GPG keys at once before downloading the metadata from new repositories openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-09 07:54:32 reject reason: Cannot be done in time. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Ladislav Slezak (lslezak) Description: If e.g. 10 different repositories are added yast asks to import the GPG key for each repository so the user cannot leave the computer while the metadata are downloaded. References: https://bugzilla.novell.com/show_bug.cgi?id=399253 Discussion: #2: Federico Lucifredi (flucifredi) (2008-07-08 19:41:45) (reply to #1) cute. It is a nice idea indeed. + #3: Dmitry Mittov (michael_knight) (2009-02-23 11:03:50) + It is not a good idea to add gpg keys for all repos all over the world. + What do you want to do with new repos on BuildService? They can be + created after release of new Suse version. All repos signed with SuSE + Package Signing Key are guaranteed. When you add other repos you should + confirm you trust them. + But special option for 'zypper ar'. Something like '--trust-key' will + solve you problem. -- openSUSE Feature: https://features.opensuse.org/304911

1 0

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

22 Feb '09

Feature changed by: Eric Springer (Erikina) Feature #305296, revision 42 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree #11: Jean-Daniel Dodin (jdd) (2009-02-15 10:12:29) (reply to #1) +1 #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) Beagle should be disabled by default. Everyone in the DFW Linux Users Group complained when Suse added it. It causes nothing but trouble for me. #12: Bart Otten (bartotten) (2009-02-16 01:13:58) I agree with the people voting to disable it by default. I think we have to keep focus on the 'consumer' and most of them won't use Kerry/Beagle. ps. KDE4 -and- Beagle is useless. KDE4 uses Strigi and Nepomuk. #13: Sebastian Rösgen (palimpseste) (2009-02-17 12:55:11) Despite all who now have voted for this proposal, I just have to vote against it. At least in the forms discussed here. I use Beagle heavily as do some other people I got convinced to use openSUSE instead of Windows. A good Desktop search was among the arguments to move these people to change their OS (others arguments were Deskbar etc... which btw. does not necessarily need Beagle but gets some interesting advantages IF Beagle is activated). Why not simply ask at startup how to configure some basic system defaults. Among them there could be beagle. So concerning the proposals of Federico Lucifredi, Stephan Kulow and so on, I am definitively of the same mind. Beagle should be installed by default, but it should be easy to switch it "on" or "off" whenever one wants. #14: Eric Springer (erikina) (2009-02-18 01:05:18) (reply to #13) Yes, a search is very useful. Yes, some people find beagle beneficial (as apparently you do). But the vast majority (Currently the vote is at 47:1) of people it doesn't work well with. And that's truly an amazing statistic, as it's super easy to see and use the feature it provides but much harder to see that it's beagle causing so many (resource related) problems. And if that statistic alone isn't enough to convince you it's not a sensible default, then I have absolutely no idea how to. There really should be a resemblance of QA in place, especially for default (and completely optional) packages. #15: Sebastian Rösgen (palimpseste) (2009-02-19 12:04:23) (reply to #14) Ok, I hope that my comment did not sound as gruff or ... brusque, for I, basically, hoped to present a different opinion. What I did not intend was to, evidently, irritate somebody by not completely assenting to his opinion. See: I am working for a university in Germany. We have 45.000 students and a staff of employees of a size appropriate for this amount of students. We rely heavily on the capabilities of a search system (to be honest: in this case not beagle, but somethings similar to beagle). I am one person who posts here but, to stay in your line of argumentation, statistically I represent so many single individuals, that my vote could be multiplied by a "pretty fight factor". Now the problem is that most of these people just use a search feature but do not understand of configure it. But they will notice when it is gone . These users do not vote, they are not involved in community work, they are not programmers, not system architects, not members of an online community. But they use systems like beagle. I know, as I stated in my first post, some people, which I got to switch their OS, from Windows to openSUSE. These people will miss features, too. Especially if you are so eager so simple remove this feature despite the fact that it was part of the distribution for many years. The more I write here, the angrier I get. I mentioned that Lucifredi and Kulow are of another opinion (disable but no remove the software; make it possible to switch it on or off when needed), an opinion I agree with. Is it possible that YOU ignored that part? This is quite normale for the usual open source community. To me it is a relatively illusive concept, the more I deal with it (and I deal with it for now 9 years) the more I learn about the ignorance it contains. Too many people choose rather to ignore those who have to vote (usually called users) and instead see their opinion as the ultimate measure to decide pro and contra. Did it come to your mind that about 80-90% of those who start to create an account for a portal like openFATE, who pay the time to write some comments and skip through all these proposals in this portal, that 80-90% of these people might perhaps be programmers? Geeks and nerds as they are called nowadays. This is no real statistic representing the opinion of those who use a software, it is a statistic of those how develop a software. Make this clear to you. So to get back on a rather rational level: I recognize that you are of another opinion. That most of the people here are. But, and that was important to me, these votes in here are not a real representation of opinions. I prefer openSUSE after all these years espcially because it was bought by Novell. Because they do research in usability, which is the only real way to ask the customers/the users, how to design the software. That is why I said, that an easy startup QA for the normal user is the best to do. Do not be too ignorant. The users know what they want, even if they miss some technical versatily, they will still take note of features that are missing, of bugs in the browser, of missing parts in the system "that they know worked on a different OS" or whatever else. Perhaps they annot name the source of the problem and do not know if it is a real design issue or a real bug. But they will say that the feature is not how they expected it to be. I recently said to a colleague of mine that the times of Mac OS are nearly over. The only real advantage they have is that they can design an OS without paying too much attention to different hardware. They know exactly which hardware their OS will possible have to run on. If Linux with a nice GNOME, KDE, or-whatever-desktop would run out of the box on ANY posible hardware, with all features running without a problem (Audio, Bluetooth, 3D Graphics are still a problem as we know) it would be undeniable that Linux will be the winner. I see progress made well into that direction. I see that Linux is close to this goal, to solve these issues in nears time (most Graphic Cards now easily work, with only a few exceptions). So please do not disappoint me. I have to lead discussions about Linux/Windows and Linux/MacOSX nearly every week. I do not want to have them led in vain. Look at what Mac and Windows do, they have a search system with an index. Make ours betters, faster and less memory hungry instead of removing it. These who switch from Windows/Mac to Linux (for instance to openSUSE) want to find new and more useful features instead of fewer features. I know this post was too long. I am sorry, but it thought it necessary. #16: Eric Springer (erikina) (2009-02-19 14:33:07) (reply to #15) I agree with everything you said, but you must realize I/we aren't arguing against search. We're arguing against beagle. I personally use google desktop search on a daily basis. And it works well. I assume that it does all its work when I'm not physically using the computer (a policy that is ideal for desktop usage). I'm not advocating its inclusion (primarily license reasons and kde integration reasons) but you should see that I'm not against a search or anything like that. Beagle on the other hand, I've tried to give it a fair shot a few times. To see if it has improved (something I will admit Banshee has done). But its *always* problematic. Something that is echoed daily on IRC and the mailing lists. The firefox extension causes huge amounts errors and slow downs. The actual search program maxs out the CPU. IO brings the computer to a crawl when I need to get work done etc. It's just not pretty. So if Beagle works well, I'd love to use it. But it doesn't and shouldn't be included. Put it this way. I would really like to see kernel initialization of graphics devices. However, until it's finished and works properly -- I think we'd both agree that it shouldn't be on our systems. I know it's not a good test for everything, but have you noticed how many other desktop distros have chosen to include beagle? #17: Sebastian Rösgen (palimpseste) (2009-02-19 18:16:48) (reply to #16) Ok, I see your point. Perhaps beagle is indeed not a good solution and I was too narrow minded to realize it. (Though I haven't experienced the CPU problems anymore for about one year, I suppose you are right). Especially since the development of beagle has come to a crawl (the last release: 0.3.9 was released about four weeks ago but it needed nearly half a year to be released and contains only some mere bug fixes). I think, I am going to open a new feature request in openFate. If you (and the other guys) are not against desktop search, but instead against beagle, it could be interesting to discuss why Tracker (http://projects.gnome.org/tracker/index.html) should not become a replacement for beagle. Especially since KDE has now Strigi as a core component. So one can get rid of beagle and use some "quasi native" tools for desktop search (namely "strigi" and "tracker") on Gnome and, respectively, KDE. Anyway, thanks for your reply and the discussion. #18: Sebastian Rösgen (palimpseste) (2009-02-19 18:23:53) (reply to #17) Hm, as it seems I cannot open such a request. Wonderful! So perhaps somebody has read this discussion and might be so kind to at least evaluate the request and "perhaps" might open a new feature request concerning the replacement of beagle by Tracker (which is a Gnome Desktop search, but since KDE has already its own Desktop search this should not be that problematic... I hope) And before somebody asks: no I will not file a feature request via bug tracking system. Those usually take weeks or even months before they are answered/evaluated/discussed etc... #19: Federico Lucifredi (flucifredi) (2009-02-19 16:52:12) (reply to #18) Hello Sebastian - I do not take the thread as being "against desktop search", which is a great feature, or against Beagle, which I personally run. The decision is only to have Beagle not be running by default out of the box, but to have it installed and ready. The first time a search is performed, we ask. Users who want desktop search select to run it, and those who are more "frugal" in terms of CPU do not. I am running a 3 year old laptop, and Beagle is running just fine for me. I suspect that's the case for a lot of people. But it is still a good idea to ask for a choice. + #20: Eric Springer (erikina) (2009-02-22 03:03:55) (reply to #17) + 100% agree. I think tracker/strigi make wonderful replacements. :) -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 305336] Ship man page for every executable
by fate_noreply＠suse.de 21 Feb '09

21 Feb '09

Feature changed by: Jan Engelhardt (jengelh) Feature #305336, revision 26 Title: Ship man page for every executable openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Matthias Eckermann (mge1512) Description: 1. Even graphical applications need docs outside the application itself. The need to run the application, to know what does it does, is not good. 2. You need a standard documentation format; where standard = expected for people needing that documentation. Who are, often, not knowing the distro well (so the format can't be distro-specific). And the format must be the same for all binaries/packages. One can't rely on the fact it will always be easy and intuitive to find that some application is part KDE (for example) and one can get the documentation in konqueror when typing 'help:/application'. 3. To view the documentation must be as easy as possible and with as minimal resources as possible. This is why online documentation is not so good (you need a running Internet net connection), documentation in a web browser as well (you need X and graphical desktop). HTML is questionable as it (as a format) allows so many extensions that it is needed to expect that such documentation will not be readable in text browsers after some time. 4. Many parts are shared between openSUSE and the enterprise products. And, in the enterprise world, we need to be much more standard conforming. Including the documentation. A UNIX admin will use the 'man' command for getting info about the binary. 'info' system is here as well, for many years. But 'man' is still more usual. Imagine a server room with hundreds/thousands of servers of several UN*X clones - 'man' works everywhere, and Linux is expected to be "on par" also with respect to those capabilities. These four points stay behind the idea of man pages needed and provided for everything. Relations: - How to Create Manpages with DocBook (url: http://en.opensuse.org/Manual_Pages/How_to_Create_Manpages_with_DocBook) - At http://en.opensuse.org/Manual_Pages/Missing a list of all packages with missing man pages can be found (url: http://en.opensuse.org/Manual_Pages/Missing) Use Case: User / Administrator should find a dedicated man page for every executable in openSUSE and SUSE Linux Enterprise systems. Discussion: #2: Stefan Behlert (sbehlert) (2008-10-22 15:00:11) I agree with the intention, but shouldn't it be rather 'documentation for each executable'? Newer stuff uses mostly info-pages, afaiks #3: Matthias Eckermann (mge1512) (2008-11-10 14:31:15) (reply to #2) It is valid to have a pointer to the info pages in the man-pages, sure. But man-pages are the UNIX proposed way of doing documentation. #9: Thomas Schraitle (thomas-schraitle) (2009-02-20 09:54:09) IMHO DocBook would be very suitable for this task as nobody has to learn the awkward syntax of groff/troff/... For example, I've submitted a DocBook file to the scout author and he generates the manpage with the DocBook stylesheets automatically. If you think, a manpage is not enough, each DocBook file can be easily transformed into (X)HTML, PDF, or almost any other output formats. IHMO it saves time if you want to support more formats than just manpage. The whole process is documented here: http://en.opensuse.org/Manual_Pages/How_to_Create_Manpages_with_DocBook + #10: Jan Engelhardt (jengelh) (2009-02-21 20:31:14) (reply to #9) + Manpages are very suitable for this task as nobody has to learn the + awkward DocBook syntax. + If done right, manpages are just another markup language and there are + just a few elements one needs to know. (You can even count them in your + hands: .TH, .SH, .SS, .PP, .TP, .nf/.fi, \fB, \fI, \fP, and sometimes . + IP. They almost map to HTML's title, h1, h2, p, (no direct eqv), pre, + b, i, /b|/i, and ol|ul, respectively.) -- openSUSE Feature: https://features.opensuse.org/305336

1 0

[openFATE 305877] Popularity contest
by fate_noreply＠suse.de 20 Feb '09

20 Feb '09

Feature changed by: Michal Vyskocil (mvyskocil) Feature #305877, revision 3 Title: Popularity contest openSUSE-11.2: New Priority Requester: Important Requested by: Vladimir Nadvornik (nadvornik) Description: We need a feedback about packages that are preferred by users and actively used. Debian already has a tool named Popularity contest (popcon) * reusing popcon will give us results that are directly comparable with Debian and Ubuntu * packagers team can take care of the package * we need a configuration dialog in YaST that is visible enough * we need a server infrastructure on opensuse.org. (There are certain privacy issues, see Debian FAQ for details) References: http://en.opensuse.org/BrainStorming_Prague#We_don.27t_know_which_packages_… http://popcon.debian.org/FAQ http://popcon.debian.org/ http://popcon.ubuntu.com/ + Discussion: + #1: Michal Vyskocil (mvyskocil) (2009-02-20 12:56:06) + The pupularity-contest executable is a simple Perl script, which should + be ported to rpm (replacing of dpkg calls by appropiate rpm alternative + should be enough). -- openSUSE Feature: https://features.opensuse.org/305877

1 0

[openFATE 305869] improve partioning UI during installation
by fate_noreply＠suse.de 20 Feb '09

20 Feb '09

Feature changed by: Martin Schmidkunz (mschmidkunz) Feature #305869, revision 3 Title: improve partioning UI during installation - openFATE: New - Priority - Requester: Important openSUSE-11.2: New Priority Requester: Important Requested by: Martin Schmidkunz (mschmidkunz) Description: The partitioning dialog during installation is perceived as confusing (see Bug #461819) . The reasons for confusion are * button labeling * workflow A redesign could provide some improvement. A first idea could be: http://en.opensuse.org/Image:Partitioner_proposal_installation.png References: https://bugzilla.novell.com/show_bug.cgi?id=461819 http://en.opensuse.org/Image:Partitioner_proposal_installation.png -- openSUSE Feature: https://features.opensuse.org/305869

1 0

[openFATE 305336] Ship man page for every executable
by fate_noreply＠suse.de 20 Feb '09

20 Feb '09

Feature changed by: Thomas Schraitle (thomas-schraitle) Feature #305336, revision 24 Title: Ship man page for every executable openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Matthias Eckermann (mge1512) Description: 1. Even graphical applications need docs outside the application itself. The need to run the application, to know what does it does, is not good. 2. You need a standard documentation format; where standard = expected for people needing that documentation. Who are, often, not knowing the distro well (so the format can't be distro-specific). And the format must be the same for all binaries/packages. One can't rely on the fact it will always be easy and intuitive to find that some application is part KDE (for example) and one can get the documentation in konqueror when typing 'help:/application'. 3. To view the documentation must be as easy as possible and with as minimal resources as possible. This is why online documentation is not so good (you need a running Internet net connection), documentation in a web browser as well (you need X and graphical desktop). HTML is questionable as it (as a format) allows so many extensions that it is needed to expect that such documentation will not be readable in text browsers after some time. 4. Many parts are shared between openSUSE and the enterprise products. And, in the enterprise world, we need to be much more standard conforming. Including the documentation. A UNIX admin will use the 'man' command for getting info about the binary. 'info' system is here as well, for many years. But 'man' is still more usual. Imagine a server room with hundreds/thousands of servers of several UN*X clones - 'man' works everywhere, and Linux is expected to be "on par" also with respect to those capabilities. These four points stay behind the idea of man pages needed and provided for everything. Relations: + - How to Create Manpages with DocBook (url: http://en.opensuse.org/Manual_Pages/How_to_Create_Manpages_with_DocBook) - At http://en.opensuse.org/Manual_Pages/Missing a list of all packages with missing man pages can be found (url: http://en.opensuse.org/Manual_Pages/Missing) Use Case: User / Administrator should find a dedicated man page for every executable in openSUSE and SUSE Linux Enterprise systems. Discussion: #2: Stefan Behlert (sbehlert) (2008-10-22 15:00:11) I agree with the intention, but shouldn't it be rather 'documentation for each executable'? Newer stuff uses mostly info-pages, afaiks #3: Matthias Eckermann (mge1512) (2008-11-10 14:31:15) (reply to #2) It is valid to have a pointer to the info pages in the man-pages, sure. But man-pages are the UNIX proposed way of doing documentation. #9: Thomas Schraitle (thomas-schraitle) (2009-02-20 09:54:09) IMHO DocBook would be very suitable for this task as nobody has to learn the awkward syntax of groff/troff/... For example, I've submitted a DocBook file to the scout author and he generates the manpage with the DocBook stylesheets automatically. If you think, a manpage is not enough, each DocBook file can be easily transformed into (X)HTML, PDF, or almost any other output formats. IHMO it saves time if you want to support more formats than just manpage. The whole process is documented here: http://en.opensuse.org/Manual_Pages/How_to_Create_Manpages_with_DocBook -- openSUSE Feature: https://features.opensuse.org/305336

1 0

[openFATE 305336] Ship man page for every executable
by fate_noreply＠suse.de 20 Feb '09

20 Feb '09

Feature changed by: Thomas Schraitle (thomas-schraitle) Feature #305336, revision 23 Title: Ship man page for every executable openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Matthias Eckermann (mge1512) Description: 1. Even graphical applications need docs outside the application itself. The need to run the application, to know what does it does, is not good. 2. You need a standard documentation format; where standard = expected for people needing that documentation. Who are, often, not knowing the distro well (so the format can't be distro-specific). And the format must be the same for all binaries/packages. One can't rely on the fact it will always be easy and intuitive to find that some application is part KDE (for example) and one can get the documentation in konqueror when typing 'help:/application'. 3. To view the documentation must be as easy as possible and with as minimal resources as possible. This is why online documentation is not so good (you need a running Internet net connection), documentation in a web browser as well (you need X and graphical desktop). HTML is questionable as it (as a format) allows so many extensions that it is needed to expect that such documentation will not be readable in text browsers after some time. 4. Many parts are shared between openSUSE and the enterprise products. And, in the enterprise world, we need to be much more standard conforming. Including the documentation. A UNIX admin will use the 'man' command for getting info about the binary. 'info' system is here as well, for many years. But 'man' is still more usual. Imagine a server room with hundreds/thousands of servers of several UN*X clones - 'man' works everywhere, and Linux is expected to be "on par" also with respect to those capabilities. These four points stay behind the idea of man pages needed and provided for everything. Relations: - At http://en.opensuse.org/Manual_Pages/Missing a list of all packages with missing man pages can be found (url: http://en.opensuse.org/Manual_Pages/Missing) Use Case: User / Administrator should find a dedicated man page for every executable in openSUSE and SUSE Linux Enterprise systems. Discussion: #2: Stefan Behlert (sbehlert) (2008-10-22 15:00:11) I agree with the intention, but shouldn't it be rather 'documentation for each executable'? Newer stuff uses mostly info-pages, afaiks #3: Matthias Eckermann (mge1512) (2008-11-10 14:31:15) (reply to #2) It is valid to have a pointer to the info pages in the man-pages, sure. But man-pages are the UNIX proposed way of doing documentation. + #9: Thomas Schraitle (thomas-schraitle) (2009-02-20 09:54:09) + IMHO DocBook would be very suitable for this task as nobody has to + learn the awkward syntax of groff/troff/... For example, I've submitted + a DocBook file to the scout author and he generates the manpage with + the DocBook stylesheets automatically. + If you think, a manpage is not enough, each DocBook file can be easily + transformed into (X)HTML, PDF, or almost any other output formats. IHMO + it saves time if you want to support more formats than just manpage. + The whole process is documented here: http://en.opensuse.org/Manual_Pages/How_to_Create_Manpages_with_DocBook -- openSUSE Feature: https://features.opensuse.org/305336

1 0

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

19 Feb '09

Feature changed by: Federico Lucifredi (flucifredi) Feature #305296, revision 41 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree #11: Jean-Daniel Dodin (jdd) (2009-02-15 10:12:29) (reply to #1) +1 #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) Beagle should be disabled by default. Everyone in the DFW Linux Users Group complained when Suse added it. It causes nothing but trouble for me. #12: Bart Otten (bartotten) (2009-02-16 01:13:58) I agree with the people voting to disable it by default. I think we have to keep focus on the 'consumer' and most of them won't use Kerry/Beagle. ps. KDE4 -and- Beagle is useless. KDE4 uses Strigi and Nepomuk. #13: Sebastian Rösgen (palimpseste) (2009-02-17 12:55:11) Despite all who now have voted for this proposal, I just have to vote against it. At least in the forms discussed here. I use Beagle heavily as do some other people I got convinced to use openSUSE instead of Windows. A good Desktop search was among the arguments to move these people to change their OS (others arguments were Deskbar etc... which btw. does not necessarily need Beagle but gets some interesting advantages IF Beagle is activated). Why not simply ask at startup how to configure some basic system defaults. Among them there could be beagle. So concerning the proposals of Federico Lucifredi, Stephan Kulow and so on, I am definitively of the same mind. Beagle should be installed by default, but it should be easy to switch it "on" or "off" whenever one wants. #14: Eric Springer (erikina) (2009-02-18 01:05:18) (reply to #13) Yes, a search is very useful. Yes, some people find beagle beneficial (as apparently you do). But the vast majority (Currently the vote is at 47:1) of people it doesn't work well with. And that's truly an amazing statistic, as it's super easy to see and use the feature it provides but much harder to see that it's beagle causing so many (resource related) problems. And if that statistic alone isn't enough to convince you it's not a sensible default, then I have absolutely no idea how to. There really should be a resemblance of QA in place, especially for default (and completely optional) packages. #15: Sebastian Rösgen (palimpseste) (2009-02-19 12:04:23) (reply to #14) Ok, I hope that my comment did not sound as gruff or ... brusque, for I, basically, hoped to present a different opinion. What I did not intend was to, evidently, irritate somebody by not completely assenting to his opinion. See: I am working for a university in Germany. We have 45.000 students and a staff of employees of a size appropriate for this amount of students. We rely heavily on the capabilities of a search system (to be honest: in this case not beagle, but somethings similar to beagle). I am one person who posts here but, to stay in your line of argumentation, statistically I represent so many single individuals, that my vote could be multiplied by a "pretty fight factor". Now the problem is that most of these people just use a search feature but do not understand of configure it. But they will notice when it is gone . These users do not vote, they are not involved in community work, they are not programmers, not system architects, not members of an online community. But they use systems like beagle. I know, as I stated in my first post, some people, which I got to switch their OS, from Windows to openSUSE. These people will miss features, too. Especially if you are so eager so simple remove this feature despite the fact that it was part of the distribution for many years. The more I write here, the angrier I get. I mentioned that Lucifredi and Kulow are of another opinion (disable but no remove the software; make it possible to switch it on or off when needed), an opinion I agree with. Is it possible that YOU ignored that part? This is quite normale for the usual open source community. To me it is a relatively illusive concept, the more I deal with it (and I deal with it for now 9 years) the more I learn about the ignorance it contains. Too many people choose rather to ignore those who have to vote (usually called users) and instead see their opinion as the ultimate measure to decide pro and contra. Did it come to your mind that about 80-90% of those who start to create an account for a portal like openFATE, who pay the time to write some comments and skip through all these proposals in this portal, that 80-90% of these people might perhaps be programmers? Geeks and nerds as they are called nowadays. This is no real statistic representing the opinion of those who use a software, it is a statistic of those how develop a software. Make this clear to you. So to get back on a rather rational level: I recognize that you are of another opinion. That most of the people here are. But, and that was important to me, these votes in here are not a real representation of opinions. I prefer openSUSE after all these years espcially because it was bought by Novell. Because they do research in usability, which is the only real way to ask the customers/the users, how to design the software. That is why I said, that an easy startup QA for the normal user is the best to do. Do not be too ignorant. The users know what they want, even if they miss some technical versatily, they will still take note of features that are missing, of bugs in the browser, of missing parts in the system "that they know worked on a different OS" or whatever else. Perhaps they annot name the source of the problem and do not know if it is a real design issue or a real bug. But they will say that the feature is not how they expected it to be. I recently said to a colleague of mine that the times of Mac OS are nearly over. The only real advantage they have is that they can design an OS without paying too much attention to different hardware. They know exactly which hardware their OS will possible have to run on. If Linux with a nice GNOME, KDE, or-whatever-desktop would run out of the box on ANY posible hardware, with all features running without a problem (Audio, Bluetooth, 3D Graphics are still a problem as we know) it would be undeniable that Linux will be the winner. I see progress made well into that direction. I see that Linux is close to this goal, to solve these issues in nears time (most Graphic Cards now easily work, with only a few exceptions). So please do not disappoint me. I have to lead discussions about Linux/Windows and Linux/MacOSX nearly every week. I do not want to have them led in vain. Look at what Mac and Windows do, they have a search system with an index. Make ours betters, faster and less memory hungry instead of removing it. These who switch from Windows/Mac to Linux (for instance to openSUSE) want to find new and more useful features instead of fewer features. I know this post was too long. I am sorry, but it thought it necessary. #16: Eric Springer (erikina) (2009-02-19 14:33:07) (reply to #15) I agree with everything you said, but you must realize I/we aren't arguing against search. We're arguing against beagle. I personally use google desktop search on a daily basis. And it works well. I assume that it does all its work when I'm not physically using the computer (a policy that is ideal for desktop usage). I'm not advocating its inclusion (primarily license reasons and kde integration reasons) but you should see that I'm not against a search or anything like that. Beagle on the other hand, I've tried to give it a fair shot a few times. To see if it has improved (something I will admit Banshee has done). But its *always* problematic. Something that is echoed daily on IRC and the mailing lists. The firefox extension causes huge amounts errors and slow downs. The actual search program maxs out the CPU. IO brings the computer to a crawl when I need to get work done etc. It's just not pretty. So if Beagle works well, I'd love to use it. But it doesn't and shouldn't be included. Put it this way. I would really like to see kernel initialization of graphics devices. However, until it's finished and works properly -- I think we'd both agree that it shouldn't be on our systems. I know it's not a good test for everything, but have you noticed how many other desktop distros have chosen to include beagle? #17: Sebastian Rösgen (palimpseste) (2009-02-19 18:16:48) (reply to #16) Ok, I see your point. Perhaps beagle is indeed not a good solution and I was too narrow minded to realize it. (Though I haven't experienced the CPU problems anymore for about one year, I suppose you are right). Especially since the development of beagle has come to a crawl (the last release: 0.3.9 was released about four weeks ago but it needed nearly half a year to be released and contains only some mere bug fixes). I think, I am going to open a new feature request in openFate. If you (and the other guys) are not against desktop search, but instead against beagle, it could be interesting to discuss why Tracker (http://projects.gnome.org/tracker/index.html) should not become a replacement for beagle. Especially since KDE has now Strigi as a core component. So one can get rid of beagle and use some "quasi native" tools for desktop search (namely "strigi" and "tracker") on Gnome and, respectively, KDE. Anyway, thanks for your reply and the discussion. #18: Sebastian Rösgen (palimpseste) (2009-02-19 18:23:53) (reply to #17) Hm, as it seems I cannot open such a request. Wonderful! So perhaps somebody has read this discussion and might be so kind to at least evaluate the request and "perhaps" might open a new feature request concerning the replacement of beagle by Tracker (which is a Gnome Desktop search, but since KDE has already its own Desktop search this should not be that problematic... I hope) And before somebody asks: no I will not file a feature request via bug tracking system. Those usually take weeks or even months before they are answered/evaluated/discussed etc... + #19: Federico Lucifredi (flucifredi) (2009-02-19 16:52:12) (reply to + #18) + Hello Sebastian - I do not take the thread as being "against desktop search", + which is a great feature, or against Beagle, which I personally run. + The decision is only to have Beagle not be running by default out of + the box, but to have it installed and ready. The first time a search is + performed, we ask. Users who want desktop search select to run it, and + those who are more "frugal" in terms of CPU do not. + I am running a 3 year old laptop, and Beagle is running just fine for + me. I suspect that's the case for a lot of people. But it is still a + good idea to ask for a choice. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

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

19 Feb '09

Feature changed by: Sebastian Rösgen (palimpseste) Feature #305296, revision 40 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree #11: Jean-Daniel Dodin (jdd) (2009-02-15 10:12:29) (reply to #1) +1 #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) Beagle should be disabled by default. Everyone in the DFW Linux Users Group complained when Suse added it. It causes nothing but trouble for me. #12: Bart Otten (bartotten) (2009-02-16 01:13:58) I agree with the people voting to disable it by default. I think we have to keep focus on the 'consumer' and most of them won't use Kerry/Beagle. ps. KDE4 -and- Beagle is useless. KDE4 uses Strigi and Nepomuk. #13: Sebastian Rösgen (palimpseste) (2009-02-17 12:55:11) Despite all who now have voted for this proposal, I just have to vote against it. At least in the forms discussed here. I use Beagle heavily as do some other people I got convinced to use openSUSE instead of Windows. A good Desktop search was among the arguments to move these people to change their OS (others arguments were Deskbar etc... which btw. does not necessarily need Beagle but gets some interesting advantages IF Beagle is activated). Why not simply ask at startup how to configure some basic system defaults. Among them there could be beagle. So concerning the proposals of Federico Lucifredi, Stephan Kulow and so on, I am definitively of the same mind. Beagle should be installed by default, but it should be easy to switch it "on" or "off" whenever one wants. #14: Eric Springer (erikina) (2009-02-18 01:05:18) (reply to #13) Yes, a search is very useful. Yes, some people find beagle beneficial (as apparently you do). But the vast majority (Currently the vote is at 47:1) of people it doesn't work well with. And that's truly an amazing statistic, as it's super easy to see and use the feature it provides but much harder to see that it's beagle causing so many (resource related) problems. And if that statistic alone isn't enough to convince you it's not a sensible default, then I have absolutely no idea how to. There really should be a resemblance of QA in place, especially for default (and completely optional) packages. #15: Sebastian Rösgen (palimpseste) (2009-02-19 12:04:23) (reply to #14) Ok, I hope that my comment did not sound as gruff or ... brusque, for I, basically, hoped to present a different opinion. What I did not intend was to, evidently, irritate somebody by not completely assenting to his opinion. See: I am working for a university in Germany. We have 45.000 students and a staff of employees of a size appropriate for this amount of students. We rely heavily on the capabilities of a search system (to be honest: in this case not beagle, but somethings similar to beagle). I am one person who posts here but, to stay in your line of argumentation, statistically I represent so many single individuals, that my vote could be multiplied by a "pretty fight factor". Now the problem is that most of these people just use a search feature but do not understand of configure it. But they will notice when it is gone . These users do not vote, they are not involved in community work, they are not programmers, not system architects, not members of an online community. But they use systems like beagle. I know, as I stated in my first post, some people, which I got to switch their OS, from Windows to openSUSE. These people will miss features, too. Especially if you are so eager so simple remove this feature despite the fact that it was part of the distribution for many years. The more I write here, the angrier I get. I mentioned that Lucifredi and Kulow are of another opinion (disable but no remove the software; make it possible to switch it on or off when needed), an opinion I agree with. Is it possible that YOU ignored that part? This is quite normale for the usual open source community. To me it is a relatively illusive concept, the more I deal with it (and I deal with it for now 9 years) the more I learn about the ignorance it contains. Too many people choose rather to ignore those who have to vote (usually called users) and instead see their opinion as the ultimate measure to decide pro and contra. Did it come to your mind that about 80-90% of those who start to create an account for a portal like openFATE, who pay the time to write some comments and skip through all these proposals in this portal, that 80-90% of these people might perhaps be programmers? Geeks and nerds as they are called nowadays. This is no real statistic representing the opinion of those who use a software, it is a statistic of those how develop a software. Make this clear to you. So to get back on a rather rational level: I recognize that you are of another opinion. That most of the people here are. But, and that was important to me, these votes in here are not a real representation of opinions. I prefer openSUSE after all these years espcially because it was bought by Novell. Because they do research in usability, which is the only real way to ask the customers/the users, how to design the software. That is why I said, that an easy startup QA for the normal user is the best to do. Do not be too ignorant. The users know what they want, even if they miss some technical versatily, they will still take note of features that are missing, of bugs in the browser, of missing parts in the system "that they know worked on a different OS" or whatever else. Perhaps they annot name the source of the problem and do not know if it is a real design issue or a real bug. But they will say that the feature is not how they expected it to be. I recently said to a colleague of mine that the times of Mac OS are nearly over. The only real advantage they have is that they can design an OS without paying too much attention to different hardware. They know exactly which hardware their OS will possible have to run on. If Linux with a nice GNOME, KDE, or-whatever-desktop would run out of the box on ANY posible hardware, with all features running without a problem (Audio, Bluetooth, 3D Graphics are still a problem as we know) it would be undeniable that Linux will be the winner. I see progress made well into that direction. I see that Linux is close to this goal, to solve these issues in nears time (most Graphic Cards now easily work, with only a few exceptions). So please do not disappoint me. I have to lead discussions about Linux/Windows and Linux/MacOSX nearly every week. I do not want to have them led in vain. Look at what Mac and Windows do, they have a search system with an index. Make ours betters, faster and less memory hungry instead of removing it. These who switch from Windows/Mac to Linux (for instance to openSUSE) want to find new and more useful features instead of fewer features. I know this post was too long. I am sorry, but it thought it necessary. #16: Eric Springer (erikina) (2009-02-19 14:33:07) (reply to #15) I agree with everything you said, but you must realize I/we aren't arguing against search. We're arguing against beagle. I personally use google desktop search on a daily basis. And it works well. I assume that it does all its work when I'm not physically using the computer (a policy that is ideal for desktop usage). I'm not advocating its inclusion (primarily license reasons and kde integration reasons) but you should see that I'm not against a search or anything like that. Beagle on the other hand, I've tried to give it a fair shot a few times. To see if it has improved (something I will admit Banshee has done). But its *always* problematic. Something that is echoed daily on IRC and the mailing lists. The firefox extension causes huge amounts errors and slow downs. The actual search program maxs out the CPU. IO brings the computer to a crawl when I need to get work done etc. It's just not pretty. So if Beagle works well, I'd love to use it. But it doesn't and shouldn't be included. Put it this way. I would really like to see kernel initialization of graphics devices. However, until it's finished and works properly -- I think we'd both agree that it shouldn't be on our systems. I know it's not a good test for everything, but have you noticed how many other desktop distros have chosen to include beagle? #17: Sebastian Rösgen (palimpseste) (2009-02-19 18:16:48) (reply to #16) Ok, I see your point. Perhaps beagle is indeed not a good solution and I was too narrow minded to realize it. (Though I haven't experienced the CPU problems anymore for about one year, I suppose you are right). Especially since the development of beagle has come to a crawl (the last release: 0.3.9 was released about four weeks ago but it needed nearly half a year to be released and contains only some mere bug fixes). I think, I am going to open a new feature request in openFate. If you (and the other guys) are not against desktop search, but instead against beagle, it could be interesting to discuss why Tracker (http://projects.gnome.org/tracker/index.html) should not become a replacement for beagle. Especially since KDE has now Strigi as a core component. So one can get rid of beagle and use some "quasi native" tools for desktop search (namely "strigi" and "tracker") on Gnome and, respectively, KDE. Anyway, thanks for your reply and the discussion. + #18: Sebastian Rösgen (palimpseste) (2009-02-19 18:23:53) (reply to + #17) + Hm, as it seems I cannot open such a request. Wonderful! So perhaps + somebody has read this discussion and might be so kind to at least + evaluate the request and "perhaps" might open a new feature request + concerning the replacement of beagle by Tracker (which is a Gnome + Desktop search, but since KDE has already its own Desktop search this + should not be that problematic... I hope) + And before somebody asks: no I will not file a feature request via bug + tracking system. Those usually take weeks or even months before they + are answered/evaluated/discussed etc... -- openSUSE Feature: https://features.opensuse.org/305296

1 0

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

19 Feb '09

Feature changed by: Sebastian Rösgen (palimpseste) Feature #305296, revision 39 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree #11: Jean-Daniel Dodin (jdd) (2009-02-15 10:12:29) (reply to #1) +1 #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) Beagle should be disabled by default. Everyone in the DFW Linux Users Group complained when Suse added it. It causes nothing but trouble for me. #12: Bart Otten (bartotten) (2009-02-16 01:13:58) I agree with the people voting to disable it by default. I think we have to keep focus on the 'consumer' and most of them won't use Kerry/Beagle. ps. KDE4 -and- Beagle is useless. KDE4 uses Strigi and Nepomuk. #13: Sebastian Rösgen (palimpseste) (2009-02-17 12:55:11) Despite all who now have voted for this proposal, I just have to vote against it. At least in the forms discussed here. I use Beagle heavily as do some other people I got convinced to use openSUSE instead of Windows. A good Desktop search was among the arguments to move these people to change their OS (others arguments were Deskbar etc... which btw. does not necessarily need Beagle but gets some interesting advantages IF Beagle is activated). Why not simply ask at startup how to configure some basic system defaults. Among them there could be beagle. So concerning the proposals of Federico Lucifredi, Stephan Kulow and so on, I am definitively of the same mind. Beagle should be installed by default, but it should be easy to switch it "on" or "off" whenever one wants. #14: Eric Springer (erikina) (2009-02-18 01:05:18) (reply to #13) Yes, a search is very useful. Yes, some people find beagle beneficial (as apparently you do). But the vast majority (Currently the vote is at 47:1) of people it doesn't work well with. And that's truly an amazing statistic, as it's super easy to see and use the feature it provides but much harder to see that it's beagle causing so many (resource related) problems. And if that statistic alone isn't enough to convince you it's not a sensible default, then I have absolutely no idea how to. There really should be a resemblance of QA in place, especially for default (and completely optional) packages. #15: Sebastian Rösgen (palimpseste) (2009-02-19 12:04:23) (reply to #14) Ok, I hope that my comment did not sound as gruff or ... brusque, for I, basically, hoped to present a different opinion. What I did not intend was to, evidently, irritate somebody by not completely assenting to his opinion. See: I am working for a university in Germany. We have 45.000 students and a staff of employees of a size appropriate for this amount of students. We rely heavily on the capabilities of a search system (to be honest: in this case not beagle, but somethings similar to beagle). I am one person who posts here but, to stay in your line of argumentation, statistically I represent so many single individuals, that my vote could be multiplied by a "pretty fight factor". Now the problem is that most of these people just use a search feature but do not understand of configure it. But they will notice when it is gone . These users do not vote, they are not involved in community work, they are not programmers, not system architects, not members of an online community. But they use systems like beagle. I know, as I stated in my first post, some people, which I got to switch their OS, from Windows to openSUSE. These people will miss features, too. Especially if you are so eager so simple remove this feature despite the fact that it was part of the distribution for many years. The more I write here, the angrier I get. I mentioned that Lucifredi and Kulow are of another opinion (disable but no remove the software; make it possible to switch it on or off when needed), an opinion I agree with. Is it possible that YOU ignored that part? This is quite normale for the usual open source community. To me it is a relatively illusive concept, the more I deal with it (and I deal with it for now 9 years) the more I learn about the ignorance it contains. Too many people choose rather to ignore those who have to vote (usually called users) and instead see their opinion as the ultimate measure to decide pro and contra. Did it come to your mind that about 80-90% of those who start to create an account for a portal like openFATE, who pay the time to write some comments and skip through all these proposals in this portal, that 80-90% of these people might perhaps be programmers? Geeks and nerds as they are called nowadays. This is no real statistic representing the opinion of those who use a software, it is a statistic of those how develop a software. Make this clear to you. So to get back on a rather rational level: I recognize that you are of another opinion. That most of the people here are. But, and that was important to me, these votes in here are not a real representation of opinions. I prefer openSUSE after all these years espcially because it was bought by Novell. Because they do research in usability, which is the only real way to ask the customers/the users, how to design the software. That is why I said, that an easy startup QA for the normal user is the best to do. Do not be too ignorant. The users know what they want, even if they miss some technical versatily, they will still take note of features that are missing, of bugs in the browser, of missing parts in the system "that they know worked on a different OS" or whatever else. Perhaps they annot name the source of the problem and do not know if it is a real design issue or a real bug. But they will say that the feature is not how they expected it to be. I recently said to a colleague of mine that the times of Mac OS are nearly over. The only real advantage they have is that they can design an OS without paying too much attention to different hardware. They know exactly which hardware their OS will possible have to run on. If Linux with a nice GNOME, KDE, or-whatever-desktop would run out of the box on ANY posible hardware, with all features running without a problem (Audio, Bluetooth, 3D Graphics are still a problem as we know) it would be undeniable that Linux will be the winner. I see progress made well into that direction. I see that Linux is close to this goal, to solve these issues in nears time (most Graphic Cards now easily work, with only a few exceptions). So please do not disappoint me. I have to lead discussions about Linux/Windows and Linux/MacOSX nearly every week. I do not want to have them led in vain. Look at what Mac and Windows do, they have a search system with an index. Make ours betters, faster and less memory hungry instead of removing it. These who switch from Windows/Mac to Linux (for instance to openSUSE) want to find new and more useful features instead of fewer features. I know this post was too long. I am sorry, but it thought it necessary. #16: Eric Springer (erikina) (2009-02-19 14:33:07) (reply to #15) I agree with everything you said, but you must realize I/we aren't arguing against search. We're arguing against beagle. I personally use google desktop search on a daily basis. And it works well. I assume that it does all its work when I'm not physically using the computer (a policy that is ideal for desktop usage). I'm not advocating its inclusion (primarily license reasons and kde integration reasons) but you should see that I'm not against a search or anything like that. Beagle on the other hand, I've tried to give it a fair shot a few times. To see if it has improved (something I will admit Banshee has done). But its *always* problematic. Something that is echoed daily on IRC and the mailing lists. The firefox extension causes huge amounts errors and slow downs. The actual search program maxs out the CPU. IO brings the computer to a crawl when I need to get work done etc. It's just not pretty. So if Beagle works well, I'd love to use it. But it doesn't and shouldn't be included. Put it this way. I would really like to see kernel initialization of graphics devices. However, until it's finished and works properly -- I think we'd both agree that it shouldn't be on our systems. I know it's not a good test for everything, but have you noticed how many other desktop distros have chosen to include beagle? + #17: Sebastian Rösgen (palimpseste) (2009-02-19 18:16:48) (reply to + #16) + Ok, I see your point. Perhaps beagle is indeed not a good solution and I + was too narrow minded to realize it. (Though I haven't experienced the + CPU problems anymore for about one year, I suppose you are right). + Especially since the development of beagle has come to a crawl (the + last release: 0.3.9 was released about four weeks ago but it needed + nearly half a year to be released and contains only some mere bug + fixes). + I think, I am going to open a new feature request in openFate. If you + (and the other guys) are not against desktop search, but instead + against beagle, it could be interesting to discuss why Tracker + (http://projects.gnome.org/tracker/index.html) should not become a + replacement for beagle. Especially since KDE has now Strigi as a core + component. So one can get rid of beagle and use some "quasi native" + tools for desktop search (namely "strigi" and "tracker") on Gnome and, + respectively, KDE. + Anyway, thanks for your reply and the discussion. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 305598] Improve access to non-preinstalled apps
by fate_noreply＠suse.de 19 Feb '09

19 Feb '09

Feature changed by: Richard Doll (richard_doll) Feature #305598, revision 10 Title: Improve access to non-preinstalled apps openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Richard Doll (richard_doll) Partner organization: openSUSE.org Description: Currently, we include many apps in the distribution which are by default not installed although accessible for installation via Yast (eg. VPN) Users should have an easy way to find out which apps are available on the system and simply need to be installed. This could be an extension to the application browser (eg. "Search catalog for non-installed applications") or other means to make users aware. Business case (Partner benefit): openSUSE.org: We include numerous "un-advertized" applications in the distribution - it seems self-evident that we should make users aware of what is available to them. Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2009-01-02 12:20:33) This is a bit similar to the issue with YaST, where we made the decision to always install all modules to provide the overview of our capabilities. I am obviously not suggesting this route here, but some of the alternative solutions to the YaST issue may be applicable here. #2: Gerald Pfeifer (geraldpfeifer) (2009-01-02 12:21:26) Guy, Michl, something for our desktop / UI teams to look into? #3: Michael Loeffler (sprudel24) (2009-01-09 18:34:08) Hmm, doesn't the Software Management module in YaST provide exactly this? #4: Richard Doll (richard_doll) (2009-02-17 10:29:18) (reply to #3) I don't think so. You have to go actively into Yast and search there. My request is to bring this closer to the user - possibly a simple search bar in the application browser. So...a simple example might be (based on recent real user experience): - User needs a VPN app - User goes into Application Browser, types in VPN in the Filter - No VPN tool is available, no suggestions or next steps are offered. - User abandons search and concludes there is no VPN app installed on the system An ambitious - and more Linux savy - user might start searching elsewhere or try command line (or open Yast). The scenario I recommend is: - User types in "VPN" in the application browser filter - System returns an answer: "You don't currently have a VPN client linked to the application browser, but there is a VPN client on your system. Click here - BUTTON - to add a shortcut for this application in your application browser. - User accepts and from now on has the - already available - VPN client at his/her fingertips. There might be something in openSUSE - I only use SLED - that could address this #5: Martin Schmidkunz (mschmidkunz) (2009-02-19 16:04:13) What about using (and therefore promoting :-)) the one-click- installation-icon used by software installation via openSUSE.org? I played a little bit around with that idea: http://en.opensuse.org/Image:Application_browser_1click.png Of course we should check the readability of this idea :-) #6: Richard Doll (richard_doll) (2009-02-19 10:17:39) (reply to #5) This looks very good to me. It took me while to notice the wrench on the screenshot, but once I saw it it made absolute sense. Nice thing is we wouldn't have to reinvent the wheel and it would make search even more powerful. Only addition I would make is may be a color code or something that makes it even more obvious what is installed and what is "installable" - otherwise excellent. #7: Martin Schmidkunz (mschmidkunz) (2009-02-19 16:37:24) Yes, you are rigth: using a distinctive color makes it really more obvious :-) See: http://en.opensuse.org/Image:Application_browser_1click_color.png + #8: Richard Doll (richard_doll) (2009-02-19 11:46:39) (reply to #7) + Light gray doesn't qualify as a color...in fact it's very purpose is to + lowlight, not highlight... ;-) + Is it feasible to add this with SP1 to SLED? -- openSUSE Feature: https://features.opensuse.org/305598

1 0

[openFATE 305598] Improve access to non-preinstalled apps
by fate_noreply＠suse.de 19 Feb '09

19 Feb '09

Feature changed by: Martin Schmidkunz (mschmidkunz) Feature #305598, revision 9 Title: Improve access to non-preinstalled apps openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Richard Doll (richard_doll) Partner organization: openSUSE.org Description: Currently, we include many apps in the distribution which are by default not installed although accessible for installation via Yast (eg. VPN) Users should have an easy way to find out which apps are available on the system and simply need to be installed. This could be an extension to the application browser (eg. "Search catalog for non-installed applications") or other means to make users aware. Business case (Partner benefit): openSUSE.org: We include numerous "un-advertized" applications in the distribution - it seems self-evident that we should make users aware of what is available to them. Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2009-01-02 12:20:33) This is a bit similar to the issue with YaST, where we made the decision to always install all modules to provide the overview of our capabilities. I am obviously not suggesting this route here, but some of the alternative solutions to the YaST issue may be applicable here. #2: Gerald Pfeifer (geraldpfeifer) (2009-01-02 12:21:26) Guy, Michl, something for our desktop / UI teams to look into? #3: Michael Loeffler (sprudel24) (2009-01-09 18:34:08) Hmm, doesn't the Software Management module in YaST provide exactly this? #4: Richard Doll (richard_doll) (2009-02-17 10:29:18) (reply to #3) I don't think so. You have to go actively into Yast and search there. My request is to bring this closer to the user - possibly a simple search bar in the application browser. So...a simple example might be (based on recent real user experience): - User needs a VPN app - User goes into Application Browser, types in VPN in the Filter - No VPN tool is available, no suggestions or next steps are offered. - User abandons search and concludes there is no VPN app installed on the system An ambitious - and more Linux savy - user might start searching elsewhere or try command line (or open Yast). The scenario I recommend is: - User types in "VPN" in the application browser filter - System returns an answer: "You don't currently have a VPN client linked to the application browser, but there is a VPN client on your system. Click here - BUTTON - to add a shortcut for this application in your application browser. - User accepts and from now on has the - already available - VPN client at his/her fingertips. There might be something in openSUSE - I only use SLED - that could address this #5: Martin Schmidkunz (mschmidkunz) (2009-02-19 16:04:13) What about using (and therefore promoting :-)) the one-click- installation-icon used by software installation via openSUSE.org? I played a little bit around with that idea: http://en.opensuse.org/Image:Application_browser_1click.png Of course we should check the readability of this idea :-) #6: Richard Doll (richard_doll) (2009-02-19 10:17:39) (reply to #5) This looks very good to me. It took me while to notice the wrench on the screenshot, but once I saw it it made absolute sense. Nice thing is we wouldn't have to reinvent the wheel and it would make search even more powerful. Only addition I would make is may be a color code or something that makes it even more obvious what is installed and what is "installable" - otherwise excellent. + #7: Martin Schmidkunz (mschmidkunz) (2009-02-19 16:37:24) + Yes, you are rigth: using a distinctive color makes it really more + obvious :-) See: + http://en.opensuse.org/Image:Application_browser_1click_color.png -- openSUSE Feature: https://features.opensuse.org/305598

1 0

[openFATE 305598] Improve access to non-preinstalled apps
by fate_noreply＠suse.de 19 Feb '09

19 Feb '09

Feature changed by: Richard Doll (richard_doll) Feature #305598, revision 8 Title: Improve access to non-preinstalled apps openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Richard Doll (richard_doll) Partner organization: openSUSE.org Description: Currently, we include many apps in the distribution which are by default not installed although accessible for installation via Yast (eg. VPN) Users should have an easy way to find out which apps are available on the system and simply need to be installed. This could be an extension to the application browser (eg. "Search catalog for non-installed applications") or other means to make users aware. Business case (Partner benefit): openSUSE.org: We include numerous "un-advertized" applications in the distribution - it seems self-evident that we should make users aware of what is available to them. Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2009-01-02 12:20:33) This is a bit similar to the issue with YaST, where we made the decision to always install all modules to provide the overview of our capabilities. I am obviously not suggesting this route here, but some of the alternative solutions to the YaST issue may be applicable here. #2: Gerald Pfeifer (geraldpfeifer) (2009-01-02 12:21:26) Guy, Michl, something for our desktop / UI teams to look into? #3: Michael Loeffler (sprudel24) (2009-01-09 18:34:08) Hmm, doesn't the Software Management module in YaST provide exactly this? #4: Richard Doll (richard_doll) (2009-02-17 10:29:18) (reply to #3) I don't think so. You have to go actively into Yast and search there. My request is to bring this closer to the user - possibly a simple search bar in the application browser. So...a simple example might be (based on recent real user experience): - User needs a VPN app - User goes into Application Browser, types in VPN in the Filter - No VPN tool is available, no suggestions or next steps are offered. - User abandons search and concludes there is no VPN app installed on the system An ambitious - and more Linux savy - user might start searching elsewhere or try command line (or open Yast). The scenario I recommend is: - User types in "VPN" in the application browser filter - System returns an answer: "You don't currently have a VPN client linked to the application browser, but there is a VPN client on your system. Click here - BUTTON - to add a shortcut for this application in your application browser. - User accepts and from now on has the - already available - VPN client at his/her fingertips. There might be something in openSUSE - I only use SLED - that could address this #5: Martin Schmidkunz (mschmidkunz) (2009-02-19 16:04:13) What about using (and therefore promoting :-)) the one-click- installation-icon used by software installation via openSUSE.org? I played a little bit around with that idea: http://en.opensuse.org/Image:Application_browser_1click.png Of course we should check the readability of this idea :-) + #6: Richard Doll (richard_doll) (2009-02-19 10:17:39) (reply to #5) + This looks very good to me. It took me while to notice the wrench on + the screenshot, but once I saw it it made absolute sense. + Nice thing is we wouldn't have to reinvent the wheel and it would make + search even more powerful. + Only addition I would make is may be a color code or something that + makes it even more obvious what is installed and what is "installable" + - otherwise excellent. -- openSUSE Feature: https://features.opensuse.org/305598

1 0

[openFATE 305598] Improve access to non-preinstalled apps
by fate_noreply＠suse.de 19 Feb '09

19 Feb '09

Feature changed by: Martin Schmidkunz (mschmidkunz) Feature #305598, revision 7 Title: Improve access to non-preinstalled apps openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Richard Doll (richard_doll) Partner organization: openSUSE.org Description: Currently, we include many apps in the distribution which are by default not installed although accessible for installation via Yast (eg. VPN) Users should have an easy way to find out which apps are available on the system and simply need to be installed. This could be an extension to the application browser (eg. "Search catalog for non-installed applications") or other means to make users aware. Business case (Partner benefit): openSUSE.org: We include numerous "un-advertized" applications in the distribution - it seems self-evident that we should make users aware of what is available to them. Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2009-01-02 12:20:33) This is a bit similar to the issue with YaST, where we made the decision to always install all modules to provide the overview of our capabilities. I am obviously not suggesting this route here, but some of the alternative solutions to the YaST issue may be applicable here. #2: Gerald Pfeifer (geraldpfeifer) (2009-01-02 12:21:26) Guy, Michl, something for our desktop / UI teams to look into? #3: Michael Loeffler (sprudel24) (2009-01-09 18:34:08) Hmm, doesn't the Software Management module in YaST provide exactly this? #4: Richard Doll (richard_doll) (2009-02-17 10:29:18) (reply to #3) I don't think so. You have to go actively into Yast and search there. My request is to bring this closer to the user - possibly a simple search bar in the application browser. So...a simple example might be (based on recent real user experience): - User needs a VPN app - User goes into Application Browser, types in VPN in the Filter - No VPN tool is available, no suggestions or next steps are offered. - User abandons search and concludes there is no VPN app installed on the system An ambitious - and more Linux savy - user might start searching elsewhere or try command line (or open Yast). The scenario I recommend is: - User types in "VPN" in the application browser filter - System returns an answer: "You don't currently have a VPN client linked to the application browser, but there is a VPN client on your system. Click here - BUTTON - to add a shortcut for this application in your application browser. - User accepts and from now on has the - already available - VPN client at his/her fingertips. There might be something in openSUSE - I only use SLED - that could address this + #5: Martin Schmidkunz (mschmidkunz) (2009-02-19 16:04:13) + What about using (and therefore promoting :-)) the one-click- + installation-icon used by software installation via openSUSE.org? I + played a little bit around with that idea: + http://en.opensuse.org/Image:Application_browser_1click.png Of course + we should check the readability of this idea :-) -- openSUSE Feature: https://features.opensuse.org/305598

1 0

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

19 Feb '09

Feature changed by: Eric Springer (Erikina) Feature #305296, revision 37 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree #11: Jean-Daniel Dodin (jdd) (2009-02-15 10:12:29) (reply to #1) +1 #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) Beagle should be disabled by default. Everyone in the DFW Linux Users Group complained when Suse added it. It causes nothing but trouble for me. #12: Bart Otten (bartotten) (2009-02-16 01:13:58) I agree with the people voting to disable it by default. I think we have to keep focus on the 'consumer' and most of them won't use Kerry/Beagle. ps. KDE4 -and- Beagle is useless. KDE4 uses Strigi and Nepomuk. #13: Sebastian Rösgen (palimpseste) (2009-02-17 12:55:11) Despite all who now have voted for this proposal, I just have to vote against it. At least in the forms discussed here. I use Beagle heavily as do some other people I got convinced to use openSUSE instead of Windows. A good Desktop search was among the arguments to move these people to change their OS (others arguments were Deskbar etc... which btw. does not necessarily need Beagle but gets some interesting advantages IF Beagle is activated). Why not simply ask at startup how to configure some basic system defaults. Among them there could be beagle. So concerning the proposals of Federico Lucifredi, Stephan Kulow and so on, I am definitively of the same mind. Beagle should be installed by default, but it should be easy to switch it "on" or "off" whenever one wants. #14: Eric Springer (erikina) (2009-02-18 01:05:18) (reply to #13) Yes, a search is very useful. Yes, some people find beagle beneficial (as apparently you do). But the vast majority (Currently the vote is at 47:1) of people it doesn't work well with. And that's truly an amazing statistic, as it's super easy to see and use the feature it provides but much harder to see that it's beagle causing so many (resource related) problems. And if that statistic alone isn't enough to convince you it's not a sensible default, then I have absolutely no idea how to. There really should be a resemblance of QA in place, especially for default (and completely optional) packages. #15: Sebastian Rösgen (palimpseste) (2009-02-19 12:04:23) (reply to #14) Ok, I hope that my comment did not sound as gruff or ... brusque, for I, basically, hoped to present a different opinion. What I did not intend was to, evidently, irritate somebody by not completely assenting to his opinion. See: I am working for a university in Germany. We have 45.000 students and a staff of employees of a size appropriate for this amount of students. We rely heavily on the capabilities of a search system (to be honest: in this case not beagle, but somethings similar to beagle). I am one person who posts here but, to stay in your line of argumentation, statistically I represent so many single individuals, that my vote could be multiplied by a "pretty fight factor". Now the problem is that most of these people just use a search feature but do not understand of configure it. But they will notice when it is gone . These users do not vote, they are not involved in community work, they are not programmers, not system architects, not members of an online community. But they use systems like beagle. I know, as I stated in my first post, some people, which I got to switch their OS, from Windows to openSUSE. These people will miss features, too. Especially if you are so eager so simple remove this feature despite the fact that it was part of the distribution for many years. The more I write here, the angrier I get. I mentioned that Lucifredi and Kulow are of another opinion (disable but no remove the software; make it possible to switch it on or off when needed), an opinion I agree with. Is it possible that YOU ignored that part? This is quite normale for the usual open source community. To me it is a relatively illusive concept, the more I deal with it (and I deal with it for now 9 years) the more I learn about the ignorance it contains. Too many people choose rather to ignore those who have to vote (usually called users) and instead see their opinion as the ultimate measure to decide pro and contra. Did it come to your mind that about 80-90% of those who start to create an account for a portal like openFATE, who pay the time to write some comments and skip through all these proposals in this portal, that 80-90% of these people might perhaps be programmers? Geeks and nerds as they are called nowadays. This is no real statistic representing the opinion of those who use a software, it is a statistic of those how develop a software. Make this clear to you. So to get back on a rather rational level: I recognize that you are of another opinion. That most of the people here are. But, and that was important to me, these votes in here are not a real representation of opinions. I prefer openSUSE after all these years espcially because it was bought by Novell. Because they do research in usability, which is the only real way to ask the customers/the users, how to design the software. That is why I said, that an easy startup QA for the normal user is the best to do. Do not be too ignorant. The users know what they want, even if they miss some technical versatily, they will still take note of features that are missing, of bugs in the browser, of missing parts in the system "that they know worked on a different OS" or whatever else. Perhaps they annot name the source of the problem and do not know if it is a real design issue or a real bug. But they will say that the feature is not how they expected it to be. I recently said to a colleague of mine that the times of Mac OS are nearly over. The only real advantage they have is that they can design an OS without paying too much attention to different hardware. They know exactly which hardware their OS will possible have to run on. If Linux with a nice GNOME, KDE, or-whatever-desktop would run out of the box on ANY posible hardware, with all features running without a problem (Audio, Bluetooth, 3D Graphics are still a problem as we know) it would be undeniable that Linux will be the winner. I see progress made well into that direction. I see that Linux is close to this goal, to solve these issues in nears time (most Graphic Cards now easily work, with only a few exceptions). So please do not disappoint me. I have to lead discussions about Linux/Windows and Linux/MacOSX nearly every week. I do not want to have them led in vain. Look at what Mac and Windows do, they have a search system with an index. Make ours betters, faster and less memory hungry instead of removing it. These who switch from Windows/Mac to Linux (for instance to openSUSE) want to find new and more useful features instead of fewer features. I know this post was too long. I am sorry, but it thought it necessary. + #16: Eric Springer (erikina) (2009-02-19 14:33:07) (reply to #15) + I agree with everything you said, but you must realize I/we aren't + arguing against search. We're arguing against beagle. + I personally use google desktop search on a daily basis. And it works + well. I assume that it does all its work when I'm not physically using + the computer (a policy that is ideal for desktop usage). I'm not + advocating its inclusion (primarily license reasons and kde integration + reasons) but you should see that I'm not against a search or anything + like that. + Beagle on the other hand, I've tried to give it a fair shot a few + times. To see if it has improved (something I will admit Banshee has + done). But its *always* problematic. Something that is echoed daily on + IRC and the mailing lists. The firefox extension causes huge amounts + errors and slow downs. The actual search program maxs out the CPU. IO + brings the computer to a crawl when I need to get work done etc. It's + just not pretty. + So if Beagle works well, I'd love to use it. But it doesn't and + shouldn't be included. Put it this way. I would really like to see + kernel initialization of graphics devices. However, until it's finished + and works properly -- I think we'd both agree that it shouldn't be on + our systems. I know it's not a good test for everything, but have you + noticed how many other desktop distros have chosen to include beagle? -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 305656] Make hyperlinks from source project names on 'My Projects' page
by fate_noreply＠suse.de 19 Feb '09

19 Feb '09

Feature changed by: Pavol Rusnak (prusnak) Feature #305656, revision 5 Title: Make hyperlinks from source project names on 'My Projects' page Buildservice: New Priority Requester: Desirable Requested by: Petr Uzel (puzel) Description: When I go to 'My Projects' page in OBS, there is a table with requests concerning me at the bottom of the page. For each request, the table contains source project name. I often need to go directly to that project to check the package. This would be much easier, if the project name were hyperlink to the OBS project. Discussion: #1: Marek Stopka (m4r3k) (2009-02-18 18:07:01) Also package name can go directly to package in source project... I would like that too. Nice idea. #2: Sascha Manns (saigkill) (2009-02-18 18:34:49) That sounds good. I'm vote up +1 + #3: Pavol Rusnak (prusnak) (2009-02-19 12:45:44) + I already reported it two months ago in bugzilla: + http://bugzilla.novell.com/show_bug.cgi?id=461306 -- openSUSE Feature: https://features.opensuse.org/305656

1 0

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

19 Feb '09

Feature changed by: Sebastian Rösgen (palimpseste) Feature #305296, revision 36 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree #11: Jean-Daniel Dodin (jdd) (2009-02-15 10:12:29) (reply to #1) +1 #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) Beagle should be disabled by default. Everyone in the DFW Linux Users Group complained when Suse added it. It causes nothing but trouble for me. #12: Bart Otten (bartotten) (2009-02-16 01:13:58) I agree with the people voting to disable it by default. I think we have to keep focus on the 'consumer' and most of them won't use Kerry/Beagle. ps. KDE4 -and- Beagle is useless. KDE4 uses Strigi and Nepomuk. #13: Sebastian Rösgen (palimpseste) (2009-02-17 12:55:11) Despite all who now have voted for this proposal, I just have to vote against it. At least in the forms discussed here. I use Beagle heavily as do some other people I got convinced to use openSUSE instead of Windows. A good Desktop search was among the arguments to move these people to change their OS (others arguments were Deskbar etc... which btw. does not necessarily need Beagle but gets some interesting advantages IF Beagle is activated). Why not simply ask at startup how to configure some basic system defaults. Among them there could be beagle. So concerning the proposals of Federico Lucifredi, Stephan Kulow and so on, I am definitively of the same mind. Beagle should be installed by default, but it should be easy to switch it "on" or "off" whenever one wants. #14: Eric Springer (erikina) (2009-02-18 01:05:18) (reply to #13) Yes, a search is very useful. Yes, some people find beagle beneficial (as apparently you do). But the vast majority (Currently the vote is at 47:1) of people it doesn't work well with. And that's truly an amazing statistic, as it's super easy to see and use the feature it provides but much harder to see that it's beagle causing so many (resource related) problems. And if that statistic alone isn't enough to convince you it's not a sensible default, then I have absolutely no idea how to. There really should be a resemblance of QA in place, especially for default (and completely optional) packages. + #15: Sebastian Rösgen (palimpseste) (2009-02-19 12:04:23) (reply to + #14) + Ok, I hope that my comment did not sound as gruff or ... brusque, for I, + basically, hoped to present a different opinion. What I did not intend + was to, evidently, irritate somebody by not completely assenting to his + opinion. + See: I am working for a university in Germany. We have 45.000 students + and a staff of employees of a size appropriate for this amount of + students. We rely heavily on the capabilities of a search system (to be + honest: in this case not beagle, but somethings similar to beagle). I + am one person who posts here but, to stay in your line of + argumentation, statistically I represent so many single individuals, + that my vote could be multiplied by a "pretty fight factor". Now the + problem is that most of these people just use a search feature but do + not understand of configure it. But they will notice when it is gone . + These users do not vote, they are not involved in community work, they + are not programmers, not system architects, not members of an online + community. But they use systems like beagle. I know, as I stated in my + first post, some people, which I got to switch their OS, from Windows + to openSUSE. These people will miss features, too. Especially if you + are so eager so simple remove this feature despite the fact that it was + part of the distribution for many years. + The more I write here, the angrier I get. I mentioned that Lucifredi + and Kulow are of another opinion (disable but no remove the software; + make it possible to switch it on or off when needed), an opinion I + agree with. Is it possible that YOU ignored that part? This is quite + normale for the usual open source community. To me it is a relatively + illusive concept, the more I deal with it (and I deal with it for now 9 + years) the more I learn about the ignorance it contains. Too many + people choose rather to ignore those who have to vote (usually called + users) and instead see their opinion as the ultimate measure to decide + pro and contra. Did it come to your mind that about 80-90% of those who + start to create an account for a portal like openFATE, who pay the time + to write some comments and skip through all these proposals in this + portal, that 80-90% of these people might perhaps be programmers? Geeks + and nerds as they are called nowadays. This is no real statistic + representing the opinion of those who use a software, it is a statistic + of those how develop a software. Make this clear to you. + So to get back on a rather rational level: I recognize that you are of + another opinion. That most of the people here are. But, and that was + important to me, these votes in here are not a real representation of + opinions. I prefer openSUSE after all these years espcially because it + was bought by Novell. Because they do research in usability, which is + the only real way to ask the customers/the users, how to design the + software. That is why I said, that an easy startup QA for the normal + user is the best to do. Do not be too ignorant. The users know what + they want, even if they miss some technical versatily, they will still + take note of features that are missing, of bugs in the browser, of + missing parts in the system "that they know worked on a different OS" + or whatever else. Perhaps they annot name the source of the problem and + do not know if it is a real design issue or a real bug. But they will + say that the feature is not how they expected it to be. + I recently said to a colleague of mine that the times of Mac OS are + nearly over. The only real advantage they have is that they can design + an OS without paying too much attention to different hardware. They + know exactly which hardware their OS will possible have to run on. If + Linux with a nice GNOME, KDE, or-whatever-desktop would run out of the + box on ANY posible hardware, with all features running without a + problem (Audio, Bluetooth, 3D Graphics are still a problem as we know) + it would be undeniable that Linux will be the winner. I see progress + made well into that direction. I see that Linux is close to this goal, + to solve these issues in nears time (most Graphic Cards now easily + work, with only a few exceptions). So please do not disappoint me. I + have to lead discussions about Linux/Windows and Linux/MacOSX nearly + every week. I do not want to have them led in vain. Look at what Mac + and Windows do, they have a search system with an index. Make ours + betters, faster and less memory hungry instead of removing it. These + who switch from Windows/Mac to Linux (for instance to openSUSE) want to + find new and more useful features instead of fewer features. + I know this post was too long. I am sorry, but it thought it + necessary. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 305656] Make hyperlinks from source project names on 'My Projects' page
by fate_noreply＠suse.de 18 Feb '09

18 Feb '09

Feature changed by: Sascha Manns (saigkill) Feature #305656, revision 4 Title: Make hyperlinks from source project names on 'My Projects' page Buildservice: New Priority Requester: Desirable Requested by: Petr Uzel (puzel) Description: When I go to 'My Projects' page in OBS, there is a table with requests concerning me at the bottom of the page. For each request, the table contains source project name. I often need to go directly to that project to check the package. This would be much easier, if the project name were hyperlink to the OBS project. Discussion: #1: Marek Stopka (m4r3k) (2009-02-18 18:07:01) Also package name can go directly to package in source project... I would like that too. Nice idea. + #2: Sascha Manns (saigkill) (2009-02-18 18:34:49) + That sounds good. I'm vote up +1 -- openSUSE Feature: https://features.opensuse.org/305656

1 0

[openFATE 305656] Make hyperlinks from source project names on 'My Projects' page
by fate_noreply＠suse.de 18 Feb '09

18 Feb '09

Feature changed by: Marek Stopka (m4r3k) Feature #305656, revision 3 Title: Make hyperlinks from source project names on 'My Projects' page Buildservice: New Priority Requester: Desirable Requested by: Petr Uzel (puzel) Description: When I go to 'My Projects' page in OBS, there is a table with requests concerning me at the bottom of the page. For each request, the table contains source project name. I often need to go directly to that project to check the package. This would be much easier, if the project name were hyperlink to the OBS project. + Discussion: + #1: Marek Stopka (m4r3k) (2009-02-18 18:07:01) + Also package name can go directly to package in source project... I + would like that too. Nice idea. -- openSUSE Feature: https://features.opensuse.org/305656

1 0

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

18 Feb '09

Feature changed by: Eric Springer (Erikina) Feature #305296, revision 34 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree #11: Jean-Daniel Dodin (jdd) (2009-02-15 10:12:29) (reply to #1) +1 #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) Beagle should be disabled by default. Everyone in the DFW Linux Users Group complained when Suse added it. It causes nothing but trouble for me. #12: Bart Otten (bartotten) (2009-02-16 01:13:58) I agree with the people voting to disable it by default. I think we have to keep focus on the 'consumer' and most of them won't use Kerry/Beagle. ps. KDE4 -and- Beagle is useless. KDE4 uses Strigi and Nepomuk. #13: Sebastian Rösgen (palimpseste) (2009-02-17 12:55:11) Despite all who now have voted for this proposal, I just have to vote against it. At least in the forms discussed here. I use Beagle heavily as do some other people I got convinced to use openSUSE instead of Windows. A good Desktop search was among the arguments to move these people to change their OS (others arguments were Deskbar etc... which btw. does not necessarily need Beagle but gets some interesting advantages IF Beagle is activated). Why not simply ask at startup how to configure some basic system defaults. Among them there could be beagle. So concerning the proposals of Federico Lucifredi, Stephan Kulow and so on, I am definitively of the same mind. Beagle should be installed by default, but it should be easy to switch it "on" or "off" whenever one wants. + #14: Eric Springer (erikina) (2009-02-18 01:05:18) (reply to #13) + Yes, a search is very useful. Yes, some people find beagle beneficial + (as apparently you do). But the vast majority (Currently the vote is at + 47:1) of people it doesn't work well with. And that's truly an amazing + statistic, as it's super easy to see and use the feature it provides + but much harder to see that it's beagle causing so many (resource + related) problems. + And if that statistic alone isn't enough to convince you it's not a + sensible default, then I have absolutely no idea how to. There really + should be a resemblance of QA in place, especially for default (and + completely optional) packages. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 305598] Improve access to non-preinstalled apps
by fate_noreply＠suse.de 17 Feb '09

17 Feb '09

Feature changed by: Richard Doll (richard_doll) Feature #305598, revision 6 Title: Improve access to non-preinstalled apps openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Richard Doll (richard_doll) Partner organization: openSUSE.org Description: Currently, we include many apps in the distribution which are by default not installed although accessible for installation via Yast (eg. VPN) Users should have an easy way to find out which apps are available on the system and simply need to be installed. This could be an extension to the application browser (eg. "Search catalog for non-installed applications") or other means to make users aware. Business case (Partner benefit): openSUSE.org: We include numerous "un-advertized" applications in the distribution - it seems self-evident that we should make users aware of what is available to them. Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2009-01-02 12:20:33) This is a bit similar to the issue with YaST, where we made the decision to always install all modules to provide the overview of our capabilities. I am obviously not suggesting this route here, but some of the alternative solutions to the YaST issue may be applicable here. #2: Gerald Pfeifer (geraldpfeifer) (2009-01-02 12:21:26) Guy, Michl, something for our desktop / UI teams to look into? #3: Michael Loeffler (sprudel24) (2009-01-09 18:34:08) Hmm, doesn't the Software Management module in YaST provide exactly this? + #4: Richard Doll (richard_doll) (2009-02-17 10:29:18) (reply to #3) + I don't think so. You have to go actively into Yast and search there. + My request is to bring this closer to the user - possibly a simple + search bar in the application browser. + So...a simple example might be (based on recent real user experience): + - User needs a VPN app - User goes into Application Browser, types in + VPN in the Filter - No VPN tool is available, no suggestions or next + steps are offered. - User abandons search and concludes there is no VPN + app installed on the system + An ambitious - and more Linux savy - user might start searching + elsewhere or try command line (or open Yast). + The scenario I recommend is: - User types in "VPN" in the application + browser filter - System returns an answer: "You don't currently have a + VPN client linked to the application browser, but there is a VPN client + on your system. Click here - BUTTON - to add a shortcut for this + application in your application browser. - User accepts and from now on + has the - already available - VPN client at his/her fingertips. + There might be something in openSUSE - I only use SLED - that could + address this -- openSUSE Feature: https://features.opensuse.org/305598

1 0

[openFATE 305561] Install Debuginfo Package by build-id
by fate_noreply＠suse.de 17 Feb '09

17 Feb '09

Feature changed by: Andreas Gruenbacher (agruen) Feature #305561, revision 7 Title: Install Debuginfo Package by build-id openSUSE-11.2: Candidate Priority Requester: Mandatory Projectmanager: Important Requested by: Jan Blunck (janblunck) Developer: Jan Blunck (jblunck) Description: Since SLE11 we embed build-ids into all binaries. This build-id can be used to match the corresponding debuginfo to a binary file, a running process or a core file. To make it easy for user to install the correct debuginfo, he should be able to run the following command to get the correct debuginfo package installed: zypper install debuginfo-build-id- eb49eeaf82eff32cfbf44d94f9aa8e3cdcf0e461 Discussion: #1: Stephan Kulow (coolo) (2009-02-17 11:17:46) Not sure why agruen is set as engmgr, this is simply some rpm hackery. Put a debuginfo.prov script in place, that checks the file list given and give it all /usr/lib/debug/.build-id files. And it will transform /usr/lib/debug/.build- id/00/d9cff1044033b4781ab47388b422b07cb72708.debug into debuginfo (d9cff1044033b4781ab47388b422b07cb72708). After that you can use zypper install -C "debuginfo (d9cff1044033b4781ab47388b422b07cb72708)" and you get kdepim4-debuginfo installed (11.1-x86_64 example). This is an effort of half an hour without testing. + #2: Andreas Gruenbacher (agruen) (2009-02-17 16:15:18) (reply to #1) + This should work, and the debug info repository metadata should still + remain reasonably small. -- openSUSE Feature: https://features.opensuse.org/305561

1 0

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

17 Feb '09

Feature changed by: Sebastian Rösgen (palimpseste) Feature #305296, revision 32 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree #11: Jean-Daniel Dodin (jdd) (2009-02-15 10:12:29) (reply to #1) +1 #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) Beagle should be disabled by default. Everyone in the DFW Linux Users Group complained when Suse added it. It causes nothing but trouble for me. #12: Bart Otten (bartotten) (2009-02-16 01:13:58) I agree with the people voting to disable it by default. I think we have to keep focus on the 'consumer' and most of them won't use Kerry/Beagle. ps. KDE4 -and- Beagle is useless. KDE4 uses Strigi and Nepomuk. + #13: Sebastian Rösgen (palimpseste) (2009-02-17 12:55:11) + Despite all who now have voted for this proposal, I just have to vote + against it. At least in the forms discussed here. I use Beagle heavily + as do some other people I got convinced to use openSUSE instead of + Windows. A good Desktop search was among the arguments to move these + people to change their OS (others arguments were Deskbar etc... which + btw. does not necessarily need Beagle but gets some interesting + advantages IF Beagle is activated). Why not simply ask at startup how + to configure some basic system defaults. Among them there could be + beagle. So concerning the proposals of Federico Lucifredi, Stephan + Kulow and so on, I am definitively of the same mind. Beagle should be + installed by default, but it should be easy to switch it "on" or "off" + whenever one wants. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 301207] Support encrypted partitions in mediamanager
by fate_noreply＠suse.de 17 Feb '09

17 Feb '09

Feature changed by: Stephan Kulow (coolo) Feature #301207, revision 37 Title: Support encrypted partitions in mediamanager openSUSE-10.2: Rejected by Stephan Kulow (coolo) reject date: 2006-10-25 12:10:25 reject reason: no time left Priority Requester: Important Projectmanager: Important openSUSE-10.3: Rejected by Jared Allen (jpallen) reject date: 2007-08-13 19:01:49 reject reason: Didn't make it. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Dirk Mueller (dirkmueller) reject date: 2008-04-11 16:44:11 reject reason: out of time due to KDE4 switch Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by JP Rosevear (jproseve) reject date: 2008-07-16 15:48:12 reject reason: The common encrypted partition cases are handled already and there is a lack of time before feature freeze. Priority Requester: Important Projectmanager: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Stephan Kulow (coolo) + reject date: 2009-02-17 11:38:03 + reject reason: there are more important features missing in KDE4. Priority Requester: Important Requested by: Stephan Kulow (coolo) Description: KDE's mediamanager currently only supports volumes from HAL, which excludes encrypted partitions only listed in fstab. This needs integrated support including new strings to indicate it's encrypted. Discussion: #1: Stephan Kulow (coolo) (2007-11-16 11:40:04) encrypted partitions become more and more popular, so we should get forward here. We support encryption for removable media now thanks to Daniel's work, but partitions are still out from media:/ #2: Dirk Mueller (dirkmueller) (2008-03-25 11:28:48) there is a improved solution for KDE3 thanks to Tom Patzig. This needs forward port to KDE4 however for 11.0, which will be a non-trivial amount of work. I would say it is 2-3 weeks to get it done properly, including learning solid. #3: Dirk Mueller (dirkmueller) (2008-04-11 16:43:37) the time is not available, beta1 is imminent and there are too many other things to fix. #4: Guy Lunardi (glunardi) (2008-06-03 22:34:50) (reply to #3) Should this be re-prioritize for openSUSE 11.1? Sounds like an important feature. #7: Dirk Mueller (dirkmueller) (2008-06-13 15:06:01) (reply to #4) I'm not sure.. the typical use case of encrypted non-hotpluggable media is to have an encrypted home partition, and you have to mount that on boot, otherwise you can't login. I don't know what the use case or the customer value for this feature is. #9: Daniel Gollub (dgollub) (2008-06-13 15:42:54) (reply to #7) This is already implemented: # cryptconfig make-ehd luks image per user in /home/ + pam_mount #10: Dirk Mueller (dirkmueller) (2008-06-13 15:58:52) (reply to #9) yep, I guess this feature is however about other custom mounts, that shouldn't be mounted via pam_mount (??) #5: JP Rosevear (jproseve) (2008-06-13 08:18:02) Dirk, whats the upstream status of this now? #6: Dirk Mueller (dirkmueller) (2008-06-13 15:01:56) KDE4 (upstream and openSUSE) supports encryted hotpluggable media (usb sticks etc) just fine, but this particular feature, the manually to /etc/fstab added feature is not there afaik. #8: Dirk Mueller (dirkmueller) (2008-06-13 15:09:54) (reply to #6) I'll have to check if my understanding is correct, hence still needinfo #11: Dirk Mueller (dirkmueller) (2008-06-23 10:44:56) (reply to #8) support for fstab-only is not upstream #12: Andreas Jaeger (a_jaeger) (2008-07-07 13:03:21) (reply to #11) OK, so let's evaluate what needs to be done for this - and whether we should move it to 11.2. -- openSUSE Feature: https://features.opensuse.org/301207

1 0

[openFATE 305561] Install Debuginfo Package by build-id
by fate_noreply＠suse.de 17 Feb '09

17 Feb '09

Feature changed by: Stephan Kulow (coolo) Feature #305561, revision 4 Title: Install Debuginfo Package by build-id - openSUSE-11.2: Evaluation + openSUSE-11.2: Candidate Priority Requester: Mandatory + Projectmanager: Important Requested by: Jan Blunck (janblunck) + Developer: Jan Blunck (jblunck) Description: Since SLE11 we embed build-ids into all binaries. This build-id can be used to match the corresponding debuginfo to a binary file, a running process or a core file. To make it easy for user to install the correct debuginfo, he should be able to run the following command to get the correct debuginfo package installed: zypper install debuginfo-build-id- eb49eeaf82eff32cfbf44d94f9aa8e3cdcf0e461 + Discussion: + #1: Stephan Kulow (coolo) (2009-02-17 11:17:46) + Not sure why agruen is set as engmgr, this is simply some rpm hackery. + Put a debuginfo.prov script in place, that checks the file list given + and give it all /usr/lib/debug/.build-id files. + And it will transform /usr/lib/debug/.build- + id/00/d9cff1044033b4781ab47388b422b07cb72708.debug into debuginfo + (d9cff1044033b4781ab47388b422b07cb72708). + After that you can use zypper install -C "debuginfo + (d9cff1044033b4781ab47388b422b07cb72708)" and you get kdepim4-debuginfo + installed (11.1-x86_64 example). + This is an effort of half an hour without testing. -- openSUSE Feature: https://features.opensuse.org/305561

1 0

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

17 Feb '09

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

1 0

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

16 Feb '09

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

1 0

[openFATE 305268] Refactor bootloader UI
by fate_noreply＠suse.de 16 Feb '09

16 Feb '09

Feature changed by: Jiri Srain (jsrain) Feature #305268, revision 5 Title: Refactor bootloader UI - openSUSE-11.2: Evaluation + openSUSE-11.2: Candidate Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Jiri Srain (jsrain) Description: In order to simplify maintenance, allow to fix some bugs and also use more flexibility of YaST UI, the user interface of the bootloader module should be rewritten to YCP instead of using generator with limited possibilities. Discussion: #2: Federico Lucifredi (flucifredi) (2009-01-26 20:45:53) prioritizing cleanup task as per plan. #3: Stanislav Visnovsky (visnov) (2009-02-02 13:11:26) Jiri, please, document the planned changes and provide a link for the feature. -- openSUSE Feature: https://features.opensuse.org/305268

1 0

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

16 Feb '09

Feature changed by: Bart Otten (BartOtten) Feature #305296, revision 31 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree #11: Jean-Daniel Dodin (jdd) (2009-02-15 10:12:29) (reply to #1) +1 #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) Beagle should be disabled by default. Everyone in the DFW Linux Users Group complained when Suse added it. It causes nothing but trouble for me. + #12: Bart Otten (bartotten) (2009-02-16 01:13:58) + I agree with the people voting to disable it by default. I think we + have to keep focus on the 'consumer' and most of them won't use + Kerry/Beagle. + ps. KDE4 -and- Beagle is useless. KDE4 uses Strigi and Nepomuk. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 305326] 5 Second Boot
by fate_noreply＠suse.de 15 Feb '09

15 Feb '09

Feature changed by: Jean-Daniel Dodin (jdd) Feature #305326, revision 11 Title: 5 Second Boot openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-02-09 15:47:52 reject reason: Sorry to be harsh, but this feature can't be implemented as asked for. Priority Requester: Mandatory Requested by: Jared Allen (jpallen) Partner organization: openSUSE.org Description: The amount of time required to boot up needs to be reduced drastically. I suggest we consider the work being done in this article: http://lwn.net/Articles/299483/ as our baseline and strive to make similar adjustments. Business case (Partner benefit): openSUSE.org: As we continue to get more involved in the Thin Client and UMPC markets, boot time becomes increasingly important. Intel's Moblin project is touting boot time as one of the significant features/advantages of their Moblin project. There are signs that other distros are following suit. We have at least one Thin Client partner that is requesting significant improvements in boot time in order to remain competitive. In fact, SLETC would have been included on more thin client hardware shipments to-date had we a faster boot time. Discussion: #1: Jared Allen (jpallen) (2008-10-06 17:03:30) I spoken with both AJ and Michael Meeks regarding this requirement. AJ suggested that include Coolo in the discussion since it will most definitely affect the distribution as a whole. #2: Stephan Kulow (coolo) (2009-01-20 15:18:14) similiar adjustments? Do you mean the "We had to do a lot of damage to X," part or the "use xfce" part? There is a limit on what you can do in a generic system and many of the low hanging fruits is already done. If you talk about getting a thin client to boot fast, then making transparent use of suspend & resume is the way to go IMO. Booting off cold hardware is problematic if you want more than xfce. There are about 100MB data to read for a pretty standard KDE session (and I assume GNOME is similiar) - on a pretty fragmented file system you get ~8MB/s netto - so just reading your files takes already 12s. Making preload dynamic on the blocks actually used is something that was discussed long, long ago, but the kernel still doesn't provide the infrastructure - so this is one of the TODOs, but possibly Intel got that ball rolling. Kernel drivers being quicker with probing would be another TODO, also listed in the article. Another urgent TODO is defragmentation because readahead helps only a little if the next update will scatter the files around your 1TB hard drive. + #3: Jean-Daniel Dodin (jdd) (2009-02-15 10:28:27) + may be this is plain stupid, forgive me if it is. The install time was + dramatically reduced by the use of "images" of installs. Could it not + be possible to build "images" of the installed system - that is to have + all the necessary files on boot able to read at once. It's not exactly + the same as suspend to disk, of like a suspend to disk with only the + system. + Most computers never change hardware and a new grub entry could be + added: boot with new hardware -- openSUSE Feature: https://features.opensuse.org/305326

1 0

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

15 Feb '09

Feature changed by: Jean-Daniel Dodin (jdd) Feature #305296, revision 30 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree + #11: Jean-Daniel Dodin (jdd) (2009-02-15 10:12:29) (reply to #1) + +1 #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) Beagle should be disabled by default. Everyone in the DFW Linux Users Group complained when Suse added it. It causes nothing but trouble for me. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

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

11 Feb '09

Feature changed by: Johnny Stovall (oouc) Feature #305296, revision 28 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. + #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) + Beagle should be disabled by default. Everyone in the DFW Linux Users + Group complained when Suse added it. It causes nothing but trouble for + me. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

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

11 Feb '09

Feature changed by: Manuel Bejarano (mbejaranoc) Feature #305296, revision 26 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. + #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) + 100% agree #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

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

10 Feb '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #302159, revision 28 Title: zypper: Add option to only download packages (-d) openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-06-19 14:19:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-04 14:32:54 reject reason: Running out of time, postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 22:23:41 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Jiri Srain (jsrain) Description: rug has a '-d' option which causes it only download packages, not to install them. zypper does not have one. to make use of such options (download packages and install them later) zypp must be able to keep the packages downloaded and use them later instead of downloading them again (eg. some kind of persistent cache). References: https://bugzilla.novell.com/show_bug.cgi?id=230704 See also feature #300747 Discussion: #2: Ján Kupec (jkupec) (2007-06-05 13:43:33) (reply to #1) First, we must have a clue how to do it :O) #5: Michael Andres (mlandres) (2007-06-18 13:21:51) (reply to #2) We need a persistent package cache, where packages are indexed by MD5, SHA. Commit has to be rewritten to separate download and install code (still offering alternating download/install or download all then install). And we need some cache cleanup policies. But we probabely don't want to do this before we know the refactored zypp runs smoothly, so I would not promise this for 10.3 #8: Federico Lucifredi (flucifredi) (2007-06-18 15:48:59) (reply to #5) As an aside, indexing will cause you probelsm with blind-revisioned packages, depending on how you implement it. #4: Duncan Mac-Vicar (dmacvicar) (2007-06-18 09:19:27) (reply to #3) This means changing the commit, and we can only do that if we are ahead of time with the other changes. #6: Jiri Srain (jsrain) (2007-06-18 14:40:08) Duncan, Michael, thanks! Stano, please, postpone for 11.0. #7: Federico Lucifredi (flucifredi) (2007-06-18 15:46:55) Lets not forget that 70%+ of OpenSUSE users have broadband according to the survey, which means this is a marginal advantage, albeit a nice one (I imagine, users who are charged by the bit, and advanced users doing who-knows-what will take advantage of the ability to retrieve packages from the cache). - #9: Stanislav Visnovsky (visnov) (2007-11-23 11:26:19) (reply to #7) - The feedback on the mailing list clearly shows users are asking for - this a lot. #10: Stanislav Visnovsky (visnov) (2007-11-23 11:26:31) zypper improvements, commit re-factoring. -- openSUSE Feature: https://features.opensuse.org/302159

1 0

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

10 Feb '09

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

1 0

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

10 Feb '09

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

1 0

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

10 Feb '09

Feature changed by: Stephan Kulow (coolo) Feature #305296, revision 24 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. + #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) + I wholehearty agree. Having specific applications in the installer is + definitely something that we shouldn't do. Have it disabled by default + and make it easy to enable. #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

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

10 Feb '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #305634, revision 66 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. + Relations: + - Wiki page for implementation (url: + http://en.opensuse.org/Upgrade/11.2) Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) Yes, the PAM maintainers would like to know more details, too. #19: Robert Davies (robopensuse) (2009-02-02 13:45:04) (reply to #18) There were a number of different forum poster's hitting it, just after 11.1 released (I think due to zypper dup not YaST upgrade and therefore unreported to BugZilla). It is not something I had, because I did fresh installs. Interestingly though I have used Debian less, I have done several dist-upgrade's, simply because it is expected to work well. So it is a mistake to focus on specific tech issues alone. This problem is also about expectations and user perceptions. Announcing "support" for dist upgrade and appealing for test, so work rounds can be found, for release notes at time matters to. #21: Cristian Rodríguez (elvigia) (2009-02-02 15:29:32) (reply to #19) as you failed to elaborate on the problem, I will.. Some people end with broken /etc/pam.d/login they have the following line session required pam_resmgr.so but that module is gone, and rpm upgrade does not remove that line (probably because that file has been modified) #24: JP Rosevear (jproseve) (2009-02-02 10:15:19) (reply to #21) Isn't that simply a packaging problem? #25: Klaus Kämpf (kwk) (2009-02-02 19:42:45) (reply to #24) In this case, it looks like a packaging problem, indeed. However, we had more complicated upgrade tasks in the past, like dropping devs.rpm and running udev instead. See Removing devs.rpm (http://en.opensuse.org/Software_Management/Upgrade/Devs_Rpm) for a discussion of the problem. #26: Klaus Kämpf (kwk) (2009-02-02 19:43:24) (reply to #21) Whats the bug number for this problem ? #20: Robert Davies (robopensuse) (2009-02-02 14:48:34) On Scope, here are the Release Notes for Lenny - http://www.uk.debian.org/releases/testing/amd64/release-notes/ 4.1.4 - Prepare a safe environment for the upgrade - text mode or via ssh login, Article on how to go from Etch to Lenny - http://www.debianadmin.com/howto-upgrade-from-debian-etch-40-to-lenny-50.ht… #27: Federico Lucifredi (flucifredi) (2009-02-04 15:32:01) (reply to #20) this is very helpful, we should look at the bumps that Debian hits while doing this. On a separate note, just tried to "yum upgrade" frlom RHEL 5.2 to RHEL 5.3, and it went without a hitch. There may be something to be gathered from Fedora as well here. #22: Manuel Trujillo (toomany) (2009-02-02 15:44:44) I think this is a really helpful characteristic, because a lot of people like me, use openSUSE as server, and is a true hell to upgrade servers in any datacenter, at kilometers off distance. I hope this feature will be a reallity in the next 11.2. #23: Duncan Mac-Vicar (dmacvicar) (2009-02-02 15:46:27) (reply to #22) Please, if you just want to express your favorites, use the voting feature. Comments is for discussion around solving the problem itself. -- openSUSE Feature: https://features.opensuse.org/305634

1 0

[openFATE 305701] allow more customization in "Automatic Configuration" installation mode
by fate_noreply＠suse.de 09 Feb '09

09 Feb '09

Feature changed by: Stephan Kulow (coolo) Feature #305701, revision 3 Title: allow more customization in "Automatic Configuration" installation mode - openSUSE-11.2: Evaluation + openSUSE-11.2: Duplicate of #303859 Priority Requester: Important Requested by: Stefan Assmann (assmannst) Description: In openSUSE 11.1 there's this feature called "Use Automatic Configuration" which saves you a lot of time during second stage of the installation. However it makes some decisions which you might want to make yourself. This could be further improved, explanation following. In the first stage we have the global overview called "Installation Settings" where you can ultimately revise your settings. In case of an "automatic configuration" this panel should also allow to customize: * basic network settings * firewall At the moment the behavior is that network will be configured somehow YaST thinks it should be right in the second stage and the firewall will always be turned on, allowing no ssh login after installation. That gives the good idea of "Automatic Configuration" a bad after- taste. Having this customizable during first stage is a good step further down the road of an easy, well integrated installation process -- openSUSE Feature: https://features.opensuse.org/305701

1 0

[openFATE 305326] 5 Second Boot
by fate_noreply＠suse.de 09 Feb '09

09 Feb '09

Feature changed by: Stephan Kulow (coolo) Feature #305326, revision 8 Title: 5 Second Boot - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Stephan Kulow (coolo) + reject date: 2009-02-09 15:47:52 + reject reason: Sorry to be harsh, but this feature can't be implemented + as asked for. Priority Requester: Mandatory Requested by: Jared Allen (jpallen) Partner organization: openSUSE.org Description: The amount of time required to boot up needs to be reduced drastically. I suggest we consider the work being done in this article: http://lwn.net/Articles/299483/ as our baseline and strive to make similar adjustments. Business case (Partner benefit): openSUSE.org: As we continue to get more involved in the Thin Client and UMPC markets, boot time becomes increasingly important. Intel's Moblin project is touting boot time as one of the significant features/advantages of their Moblin project. There are signs that other distros are following suit. We have at least one Thin Client partner that is requesting significant improvements in boot time in order to remain competitive. In fact, SLETC would have been included on more thin client hardware shipments to-date had we a faster boot time. Discussion: #1: Jared Allen (jpallen) (2008-10-06 17:03:30) I spoken with both AJ and Michael Meeks regarding this requirement. AJ suggested that include Coolo in the discussion since it will most definitely affect the distribution as a whole. #2: Stephan Kulow (coolo) (2009-01-20 15:18:14) similiar adjustments? Do you mean the "We had to do a lot of damage to X," part or the "use xfce" part? There is a limit on what you can do in a generic system and many of the low hanging fruits is already done. If you talk about getting a thin client to boot fast, then making transparent use of suspend & resume is the way to go IMO. Booting off cold hardware is problematic if you want more than xfce. There are about 100MB data to read for a pretty standard KDE session (and I assume GNOME is similiar) - on a pretty fragmented file system you get ~8MB/s netto - so just reading your files takes already 12s. Making preload dynamic on the blocks actually used is something that was discussed long, long ago, but the kernel still doesn't provide the infrastructure - so this is one of the TODOs, but possibly Intel got that ball rolling. Kernel drivers being quicker with probing would be another TODO, also listed in the article. Another urgent TODO is defragmentation because readahead helps only a little if the next update will scatter the files around your 1TB hard drive. -- openSUSE Feature: https://features.opensuse.org/305326

1 0

[openFATE 305622] Add support for lzop compression to GNU tar
by fate_noreply＠suse.de 09 Feb '09

09 Feb '09

Feature changed by: Stephan Kulow (coolo) Feature #305622, revision 13 Title: Add support for lzop compression to GNU tar openSUSE-11.2: Evaluation Priority Requester: Mandatory + Projectmanager: Neutral Requested by: Matthias Eckermann (mge1512) Description: (iaW) update to tar 1.21 Use Case: 'tar' is one of the most important archiving tools for Linux and Unix- like systems in general. Our version should be capable of interacting with all other versions including the respective compression algorithms and tools. Discussion: #1: Jan Engelhardt (jengelh) (2009-01-19 09:32:51) tar --use=lzop -cf foo.tar.lzop #2: roland kletzing (rkletzin) (2009-01-20 21:44:53) shouldn`t we first have lzop package being part of the distro/factory, before make standard tools using it? (also see https://bugzilla.novell.com/show_bug.cgi?id=461228) it`s on the wishlist for a long time now, glad to see that we have openFate now (since adding to the wishlist was as good as talking to a wall) -- openSUSE Feature: https://features.opensuse.org/305622

1 0

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

05 Feb '09

Feature changed by: Andri Andreas Priyanto (turtlix) Feature #305296, revision 21 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. + #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) + I haven't use beagle since I install openSUSE, and maybe wouldn't or + never But I don't know other user. + I always remove beagle from my gnome-session-properties. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

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

04 Feb '09

Feature changed by: Federico Lucifredi (flucifredi) Feature #305634, revision 63 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) Yes, the PAM maintainers would like to know more details, too. #19: Robert Davies (robopensuse) (2009-02-02 13:45:04) (reply to #18) There were a number of different forum poster's hitting it, just after 11.1 released (I think due to zypper dup not YaST upgrade and therefore unreported to BugZilla). It is not something I had, because I did fresh installs. Interestingly though I have used Debian less, I have done several dist-upgrade's, simply because it is expected to work well. So it is a mistake to focus on specific tech issues alone. This problem is also about expectations and user perceptions. Announcing "support" for dist upgrade and appealing for test, so work rounds can be found, for release notes at time matters to. #21: Cristian Rodríguez (elvigia) (2009-02-02 15:29:32) (reply to #19) as you failed to elaborate on the problem, I will.. Some people end with broken /etc/pam.d/login they have the following line session required pam_resmgr.so but that module is gone, and rpm upgrade does not remove that line (probably because that file has been modified) #24: JP Rosevear (jproseve) (2009-02-02 10:15:19) (reply to #21) Isn't that simply a packaging problem? #25: Klaus Kämpf (kwk) (2009-02-02 19:42:45) (reply to #24) In this case, it looks like a packaging problem, indeed. However, we had more complicated upgrade tasks in the past, like dropping devs.rpm and running udev instead. See Removing devs.rpm (http://en.opensuse.org/Software_Management/Upgrade/Devs_Rpm) for a discussion of the problem. #26: Klaus Kämpf (kwk) (2009-02-02 19:43:24) (reply to #21) Whats the bug number for this problem ? #20: Robert Davies (robopensuse) (2009-02-02 14:48:34) On Scope, here are the Release Notes for Lenny - http://www.uk.debian.org/releases/testing/amd64/release-notes/ 4.1.4 - Prepare a safe environment for the upgrade - text mode or via ssh login, Article on how to go from Etch to Lenny - http://www.debianadmin.com/howto-upgrade-from-debian-etch-40-to-lenny-50.ht… + #27: Federico Lucifredi (flucifredi) (2009-02-04 15:32:01) (reply to + #20) + this is very helpful, we should look at the bumps that Debian hits while + doing this. + On a separate note, just tried to "yum upgrade" frlom RHEL 5.2 to RHEL + 5.3, and it went without a hitch. There may be something to be gathered + from Fedora as well here. #22: Manuel Trujillo (toomany) (2009-02-02 15:44:44) I think this is a really helpful characteristic, because a lot of people like me, use openSUSE as server, and is a true hell to upgrade servers in any datacenter, at kilometers off distance. I hope this feature will be a reallity in the next 11.2. #23: Duncan Mac-Vicar (dmacvicar) (2009-02-02 15:46:27) (reply to #22) Please, if you just want to express your favorites, use the voting feature. Comments is for discussion around solving the problem itself. -- openSUSE Feature: https://features.opensuse.org/305634

1 0

[openFATE 100386] Support a verbose logging mode in yast
by fate_noreply＠suse.de 04 Feb '09

04 Feb '09

Feature changed by: Martin Vidner (mvidner) Feature #100386, revision 33 Title: Support a verbose logging mode in yast openSUSE-10.2: Rejected by Andreas Jaeger (a_jaeger) reject date: 2006-09-30 20:43:33 reject reason: for 10.3. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-08-01 10:24:26 reject reason: Postponing, needs more research. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Federico Lucifredi (flucifredi) reject date: 2008-06-28 19:27:16 reject reason: fixing my typo. Mandatories in the past don't work (yet). Priority Requester: Important Projectmanager: Important openSUSE-11.1: Done Priority Requester: Important Projectmanager: Important SL-10.0: Rejected by Andreas Jaeger (a_jaeger) reject date: 2005-12-02 14:56:13 reject reason: not done. Priority Requester: Desirable Requested by: Andreas Jaeger (a_jaeger) Description: Create a verbose logging mode in yast, where any action yast performs is logged. Any file yast touches should be logged (to /var/log/YaST2/y2log AND clean up the structure of that log file, to make it easier to read and interpret) and all changes on the systems configuration. The goal is to make it really transparent what yast does. Documentation Impact: Admin guide needs to contain information about the new log file. Please add it to the Log file section in the troubleshooting chapter Discussion: #1: Edith Parzefall (emapedl) (2006-09-28 17:17:54) Can't be done for 10.2. Back to TPMs. #2: Edith Parzefall (emapedl) (2007-07-31 16:17:45) Sorry, couldn't be done for 10.3. We need a concept for this. Even within the team different developers have different needs. Improving the logging to give all developers the best possible debugging information will be difficult, but it's definitely something we should attempt in the near future. #3: Stanislav Visnovsky (visnov) (2007-11-08 10:48:48) Can we get some traction here finally? #4: Stanislav Visnovsky (visnov) (2007-11-28 10:16:38) Reopening, the YaST transparency is often cited as a problem for users. #6: Federico Lucifredi (flucifredi) (2008-06-28 17:13:54) I think this has enough user benefit and is trivial enough, we should just get it done. #12: Stanislav Visnovsky (visnov) (2008-09-10 11:03:50) I've added y2useritem and y2usernote builtins into yast2-core. This might be helpful for this feature. + #14: Martin Vidner (mvidner) (2009-02-04 16:17:39) + I have added the two functions to yast2-perl-bindings-2.18.0 (for oS + 11.2). -- openSUSE Feature: https://features.opensuse.org/100386

1 0

[openFATE 305336] Ship man page for every executable
by fate_noreply＠suse.de 04 Feb '09

04 Feb '09

Feature changed by: Matthias Eckermann (mge1512) Feature #305336, revision 22 - Title: [NONCODE] Ship man page for every executable + Title: Ship man page for every executable openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Matthias Eckermann (mge1512) Description: 1. Even graphical applications need docs outside the application itself. The need to run the application, to know what does it does, is not good. 2. You need a standard documentation format; where standard = expected for people needing that documentation. Who are, often, not knowing the distro well (so the format can't be distro-specific). And the format must be the same for all binaries/packages. One can't rely on the fact it will always be easy and intuitive to find that some application is part KDE (for example) and one can get the documentation in konqueror when typing 'help:/application'. 3. To view the documentation must be as easy as possible and with as minimal resources as possible. This is why online documentation is not so good (you need a running Internet net connection), documentation in a web browser as well (you need X and graphical desktop). HTML is questionable as it (as a format) allows so many extensions that it is needed to expect that such documentation will not be readable in text browsers after some time. 4. Many parts are shared between openSUSE and the enterprise products. And, in the enterprise world, we need to be much more standard conforming. Including the documentation. A UNIX admin will use the 'man' command for getting info about the binary. 'info' system is here as well, for many years. But 'man' is still more usual. Imagine a server room with hundreds/thousands of servers of several UN*X clones - 'man' works everywhere, and Linux is expected to be "on par" also with respect to those capabilities. These four points stay behind the idea of man pages needed and provided for everything. Relations: - At http://en.opensuse.org/Manual_Pages/Missing a list of all packages with missing man pages can be found (url: http://en.opensuse.org/Manual_Pages/Missing) Use Case: User / Administrator should find a dedicated man page for every executable in openSUSE and SUSE Linux Enterprise systems. Discussion: #2: Stefan Behlert (sbehlert) (2008-10-22 15:00:11) I agree with the intention, but shouldn't it be rather 'documentation for each executable'? Newer stuff uses mostly info-pages, afaiks #3: Matthias Eckermann (mge1512) (2008-11-10 14:31:15) (reply to #2) It is valid to have a pointer to the info pages in the man-pages, sure. But man-pages are the UNIX proposed way of doing documentation. -- openSUSE Feature: https://features.opensuse.org/305336

1 0

[openFATE 303809] Partitioner: allow cloning of disk layouts - was: easier creation of RAID 1
by fate_noreply＠suse.de 04 Feb '09

04 Feb '09

Feature changed by: Arvin Schnell (aschnell) Feature #303809, revision 18 Title: Partitioner: allow cloning of disk layouts - was: easier creation of RAID 1 openSUSE-11.1: Rejected by Matthias Eckermann (mge1512) reject date: 2008-07-30 16:50:50 reject reason: Moving to SLE 11 SP 1 / openSUSE 11.2 Priority Requester: Important Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Matthias Eckermann (mge1512) Description: Proposal is to offer an option in YaST to clone a disk layout for RAID use and probably jump into the RAID-creation-mode directly Below the original request from C. Boltz / openSUSE community: ----------------------------------------------------------------------------------------------------- It would be good to have an easier way to setup a raid 1 (mirroring). Currently you have to: * create partitions on first disk * create partitions on the second disk (usually using the same layout). * put the corresponding partitions (sda1+sdb1, sda2+sdb2, ...) into a raid array. The easier way would be * [x] I want to create a raid 1 * define the partitioning once for both disks YaST should then partition both disks as requested and create the raid volumes This would save the user/admin some time. However, the traditional method should still be available in case someone wants to have a different layout for some partitions for whatever reason. Relations: - Partitioner: allow cloning of disk layouts - was: easier creation of RAID 1 (novell/bugzilla/id: 387373) https://bugzilla.novell.com/show_bug.cgi?id=387373 Discussion: #2: Matthias Eckermann (mge1512) (2008-05-06 20:10:22) Thanks for the proposal. I am happy that there are more people out there sharing my problems:-) Yet, looking at the current "model" we have in mind for partitioner enhancements, I wonder, if we could probably make that more "generic" by adding something like a "clone disk partitioning scheme" button: You would partition hd0 first and then say: please clone this to hd1, hd2, ... and be able to adjust settings on hd1, ... later. Would that fit? so long - MgE #3: Christian Boltz (cboltz) (2008-05-08 05:07:14) Cloning the disk layout sounds like a good idea and would help. To make it more useful for RAID creation, add "clone to md*", maybe combined with a selection dialog to choose the disks to use. #4: Matthias Eckermann (mge1512) (2008-05-08 05:26:16) Well, you know, we indeed are planning to have such a dialog for creation of raids in the future, ...:-) I changed the "title" according to our discussion, and will 1transfer the request into our internal Feature tracking system soon. Thanks! so long - MgE #6: Martin Schmidkunz (mschmidkunz) (2008-05-15 11:37:58) AFAIK it is currently possible to create one partition after the other. So it does not make sense for me to have a "Clone this partition for future use" at the end. Instead I thought of: http://en.opensuse.org/Image:Idea_303809_1.png When the user presses "Add" in the "partitioning" tab he can choose whether to create one new partition or to use the whole partition scheme from another physical harddisk. Does that make sense? #7: Matthias Eckermann (mge1512) (2008-05-15 12:05:53) (reply to #6) Well, no:-( We are not asking for _partition_ cloning, but _disk_ cloning, i.e. if you have several harddisks, and you want to copy the partitioning from sda to sdb or the like. #8: Martin Schmidkunz (mschmidkunz) (2008-05-16 10:01:41) As discussed live with mge we agree on my proposal. #9: Arvin Schnell (aschnell) (2008-05-16 10:33:01) (reply to #8) That approach has some problems: 1) Hiding "Cloning" behind "Add Partition" is incomprehensible. Cloning affect the whole disk, adding a partition not really. 2) The step to select the partition type is omitted if only one type of partition can be selected. 3) The complete workflow of adding a partition is omitted when no partitions can be created. We (mge, mschmidkunz and aschnell) now agreed upon adding an entry to the "expert" menubutton in the partition overview. + #16: Arvin Schnell (aschnell) (2009-02-04 11:08:08) + Summarising the request: + Add a entry "Close disk layout" to the "Expert" button in the disk + view. This opens a dialog showing all disks that are suitable for being + a clone (constraints: new disks must have equal or larger size). + Several disks can be selected. + On the selected disks: Delete everything (including RAIDs and LVMs + somehow using that disk), create new partition table (if different from + existing) and create partitions with same start and sizes (in cylinders + as libstorage calculates internally) and partition IDs. Other + parameters, e.g. filesystem, are not copied. -- openSUSE Feature: https://features.opensuse.org/303809

1 0

[openFATE 305336] [NONCODE] Ship man page for every executable
by fate_noreply＠suse.de 03 Feb '09

03 Feb '09

Feature changed by: Matthias Eckermann (mge1512) Feature #305336, revision 19 Title: [NONCODE] Ship man page for every executable openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Matthias Eckermann (mge1512) Description: - User / Administrator should find a dedicated man page for every - executable in openSUSE and SUSE Linux Enterprise systems. + 1. Even graphical applications need docs outside the application + itself. The need to run the application, to know what does it does, is + not good. + 2. You need a standard documentation format; where standard = expected + for people needing that documentation. Who are, often, not knowing the + distro well (so the format can't be distro-specific). And the format + must be the same for all binaries/packages. One can't rely on the fact + it will always be easy and intuitive to find that some application is + part KDE (for example) and one can get the documentation in konqueror + when typing 'help:/application'. + 3. To view the documentation must be as easy as possible and with as + minimal resources as possible. This is why online documentation is not + so good (you need a running Internet net connection), documentation in + a web browser as well (you need X and graphical desktop). HTML is + questionable as it (as a format) allows so many extensions that it is + needed to expect that such documentation will not be readable in text + browsers after some time. + 4. Many parts are shared between openSUSE and the enterprise products. + And, in the enterprise world, we need to be much more standard + conforming. Including the documentation. A UNIX admin will use the + 'man' command for getting info about the binary. 'info' system is here + as well, for many years. But 'man' is still more usual. Imagine a + server room with hundreds/thousands of servers of several UN*X clones - + 'man' works everywhere, and Linux is expected to be "on par" also with + respect to those capabilities. + These four points stay behind the idea of man pages needed and provided + for everything. Relations: - At http://en.opensuse.org/Manual_Pages/Missing a list of all packages with missing man pages can be found (url: http://en.opensuse.org/Manual_Pages/Missing) Use Case: User / Administrator should find a dedicated man page for every executable in openSUSE and SUSE Linux Enterprise systems. Discussion: #2: Stefan Behlert (sbehlert) (2008-10-22 15:00:11) I agree with the intention, but shouldn't it be rather 'documentation for each executable'? Newer stuff uses mostly info-pages, afaiks #3: Matthias Eckermann (mge1512) (2008-11-10 14:31:15) (reply to #2) It is valid to have a pointer to the info pages in the man-pages, sure. But man-pages are the UNIX proposed way of doing documentation. -- openSUSE Feature: https://features.opensuse.org/305336

1 0

[openFATE 305336] [NONCODE] Ship man page for every executable
by fate_noreply＠suse.de 03 Feb '09

03 Feb '09

Feature changed by: Matthias Eckermann (mge1512) Feature #305336, revision 18 Title: [NONCODE] Ship man page for every executable openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Matthias Eckermann (mge1512) Description: User / Administrator should find a dedicated man page for every - executable in openSUSE and SUSE Linux Enterprise systems. This should - be implemented starting with openSUSE 11.2. At - http://en.opensuse.org/Manual_Pages/Missing a list of all packages with - missing man pages can be found. + executable in openSUSE and SUSE Linux Enterprise systems. + Relations: + - At http://en.opensuse.org/Manual_Pages/Missing a list of all packages + with missing man pages can be found (url: + http://en.opensuse.org/Manual_Pages/Missing) + Use Case: + User / Administrator should find a dedicated man page for every + executable in openSUSE and SUSE Linux Enterprise systems. Discussion: #2: Stefan Behlert (sbehlert) (2008-10-22 15:00:11) I agree with the intention, but shouldn't it be rather 'documentation for each executable'? Newer stuff uses mostly info-pages, afaiks #3: Matthias Eckermann (mge1512) (2008-11-10 14:31:15) (reply to #2) It is valid to have a pointer to the info pages in the man-pages, sure. But man-pages are the UNIX proposed way of doing documentation. -- openSUSE Feature: https://features.opensuse.org/305336

1 0

[openFATE 302923] handle redirection to mirrors robustly
by fate_noreply＠suse.de 03 Feb '09

03 Feb '09

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #302923, revision 22 Title: handle redirection to mirrors robustly openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-11-28 15:42:20 reject reason: Out of scope for 11.0 Priority Requester: Neutral openSUSE-11.1: Rejected by Matthias Eckermann (mge1512) reject date: 2008-07-22 23:04:50 reject reason: Postponing, will not be ready. Priority Requester: Neutral openSUSE-11.2: Evaluation Priority Requester: Neutral Requested by: Ján Kupec (jkupec) Description: The proposal is to try other mirrors from a mirror list (from the redirector?) if an error occurs on some of the mirrors while providing a file from http/ftp repository. See the references for more details. References: https://bugzilla.novell.com/show_bug.cgi?id=337410 http://lists.opensuse.org/opensuse-buildservice/2007-10/msg00170.html http://en.opensuse.org/Libzypp/Failover http://code.google.com/soc/2008/suse/appinfo.html?csaid=6F1844AB23B67E06 Discussion: #1: Stephan Kulow (coolo) (2007-11-20 11:15:49) I would be strictly against having an own mirror list. The decision was to go with the redirector (or NCC for SLE) and be done with mirrors. If that does not work, then we have to do this whole thing again, not adding untested work arounds to the product. #2: Stephan Kulow (coolo) (2007-11-20 11:16:55) so I would reject this. But it's basically "Eval by Klaas" now #3: Klaas Freitag (kfreitag) (2007-12-03 09:49:44) I agree with Coolos and Peters statements, I would also reject. #4: Klaas Freitag (kfreitag) (2008-06-12 10:06:42) I have to revert my statement that I made before in comment #3, this problem is more serious than realised in the first look. First, it should be noted that we do not control mirrors nor we do have the chance to really influence them. That means that if a mirrors decides to not longer mirror or to switch off or whatever, we have to live with it. However if a customer is sticky to a mirror that is not longer available he would not get any packages from it and thus installation or update fails. The worst thing about that is that this seems to happen regularly but we do not realise that because we're not involved. A solution would be to have a list of possible mirrors that is used by the software installation stack to find a working mirror. Peter knows much more here. But I am not sure at the moment if not Yast/zypper already has this functionality in 11.0? #5: Peter Poeml (poeml) (2008-10-01 11:58:38) YaST/zypper in 11.1 will have preliminary support for this. The essential part of http://en.opensuse.org/Libzypp/Failover has been implemented during a GSoC project this year. See http://lists.opensuse.org/zypp-devel/2008-09/msg00142.html for the status. There is a number of things left to do, like * making it the default * better debuggability - show what it does * better progress report * testing * integration into the install system so it is available during installation Further features from the proposal (mirror preference, simultaneous downloads) are not tackled yet. #6: Federico Lucifredi (flucifredi) (2009-01-07 16:29:58) I would like to see robust redirection, if possible. The details about a list, probably should not be in the feature description. #7: Todd R (theblackcat) (2009-01-22 22:20:45) Would this also be able to handle changes in the Buildservice, like renaming or moving of a certain Buildservice repository? #8: Peter Poeml (poeml) (2009-01-23 11:56:48) (reply to #7) No, that is outside the scope. Changing repositories when the system is upgraded to a next major version is also outside the scope. Maybe that can be covered by http://en.opensuse.org/Standards/Repository_Index_Service, if I am not mistaking it. + #9: Duncan Mac-Vicar (dmacvicar) (2009-02-03 16:28:54) + Today playing with aria (I am trying to switch the default in factory) + I found out an interesting switch: + --server-stat-of=file --server-stat-if=file + The first one ouputs the mirror statistics of the servers used, and the + second one uses its as input: + cat stats host=download.opensuse.org, protocol=http, dl_speed=0, + last_updated=1233674714, status=OK host=widehat.opensuse.org, + protocol=http, dl_speed=8525008, last_updated=1233674714, status=OK + It may make sense to make the MediaAria backend to store this in + var/cache/zypp and use it as input for next time too. -- openSUSE Feature: https://features.opensuse.org/302923

1 0

[openFATE 305336] [NONCODE] Ship man page for every executable
by fate_noreply＠suse.de 03 Feb '09

03 Feb '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305336, revision 16 Title: [NONCODE] Ship man page for every executable openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Matthias Eckermann (mge1512) Partner organization: openSUSE.org Description: User / Administrator should find a dedicated man page for every executable in openSUSE and SUSE Linux Enterprise systems. This should - be implemented starting with openSUSE 11.2. + be implemented starting with openSUSE 11.2. At + http://en.opensuse.org/Manual_Pages/Missing a list of all packages with + missing man pages can be found. Discussion: #2: Stefan Behlert (sbehlert) (2008-10-22 15:00:11) I agree with the intention, but shouldn't it be rather 'documentation for each executable'? Newer stuff uses mostly info-pages, afaiks #3: Matthias Eckermann (mge1512) (2008-11-10 14:31:15) (reply to #2) It is valid to have a pointer to the info pages in the man-pages, sure. But man-pages are the UNIX proposed way of doing documentation. -- openSUSE Feature: https://features.opensuse.org/305336

1 0

[openFATE 305336] [NONCODE] Ship man page for every executable
by fate_noreply＠suse.de 03 Feb '09

03 Feb '09

Feature changed by: Matthias Eckermann (mge1512) Feature #305336, revision 15 Title: [NONCODE] Ship man page for every executable openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Matthias Eckermann (mge1512) Partner organization: openSUSE.org Description: User / Administrator should find a dedicated man page for every - executable in SLE 11 SP 1. This should be implemented starting with - openSUSE 11.2. + executable in openSUSE and SUSE Linux Enterprise systems. This should + be implemented starting with openSUSE 11.2. - Business case (Partner benefit): - openSUSE.org: UNIX "parity". Discussion: #2: Stefan Behlert (sbehlert) (2008-10-22 15:00:11) I agree with the intention, but shouldn't it be rather 'documentation for each executable'? Newer stuff uses mostly info-pages, afaiks #3: Matthias Eckermann (mge1512) (2008-11-10 14:31:15) (reply to #2) It is valid to have a pointer to the info pages in the man-pages, sure. But man-pages are the UNIX proposed way of doing documentation. -- openSUSE Feature: https://features.opensuse.org/305336

1 0

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

02 Feb '09

Feature changed by: Klaus Kämpf (kwk) Feature #305634, revision 60 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) Yes, the PAM maintainers would like to know more details, too. #19: Robert Davies (robopensuse) (2009-02-02 13:45:04) (reply to #18) There were a number of different forum poster's hitting it, just after 11.1 released (I think due to zypper dup not YaST upgrade and therefore unreported to BugZilla). It is not something I had, because I did fresh installs. Interestingly though I have used Debian less, I have done several dist-upgrade's, simply because it is expected to work well. So it is a mistake to focus on specific tech issues alone. This problem is also about expectations and user perceptions. Announcing "support" for dist upgrade and appealing for test, so work rounds can be found, for release notes at time matters to. #21: Cristian Rodríguez (elvigia) (2009-02-02 15:29:32) (reply to #19) as you failed to elaborate on the problem, I will.. Some people end with broken /etc/pam.d/login they have the following line session required pam_resmgr.so but that module is gone, and rpm upgrade does not remove that line (probably because that file has been modified) #24: JP Rosevear (jproseve) (2009-02-02 10:15:19) (reply to #21) Isn't that simply a packaging problem? #25: Klaus Kämpf (kwk) (2009-02-02 19:42:45) (reply to #24) In this case, it looks like a packaging problem, indeed. However, we had more complicated upgrade tasks in the past, like dropping devs.rpm and running udev instead. See Removing devs.rpm (http://en.opensuse.org/Software_Management/Upgrade/Devs_Rpm) for a discussion of the problem. + #26: Klaus Kämpf (kwk) (2009-02-02 19:43:24) (reply to #21) + Whats the bug number for this problem ? #20: Robert Davies (robopensuse) (2009-02-02 14:48:34) On Scope, here are the Release Notes for Lenny - http://www.uk.debian.org/releases/testing/amd64/release-notes/ 4.1.4 - Prepare a safe environment for the upgrade - text mode or via ssh login, Article on how to go from Etch to Lenny - http://www.debianadmin.com/howto-upgrade-from-debian-etch-40-to-lenny-50.ht… #22: Manuel Trujillo (toomany) (2009-02-02 15:44:44) I think this is a really helpful characteristic, because a lot of people like me, use openSUSE as server, and is a true hell to upgrade servers in any datacenter, at kilometers off distance. I hope this feature will be a reallity in the next 11.2. #23: Duncan Mac-Vicar (dmacvicar) (2009-02-02 15:46:27) (reply to #22) Please, if you just want to express your favorites, use the voting feature. Comments is for discussion around solving the problem itself. -- openSUSE Feature: https://features.opensuse.org/305634

1 0

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

02 Feb '09

Feature changed by: Klaus Kämpf (kwk) Feature #305634, revision 59 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) Yes, the PAM maintainers would like to know more details, too. #19: Robert Davies (robopensuse) (2009-02-02 13:45:04) (reply to #18) There were a number of different forum poster's hitting it, just after 11.1 released (I think due to zypper dup not YaST upgrade and therefore unreported to BugZilla). It is not something I had, because I did fresh installs. Interestingly though I have used Debian less, I have done several dist-upgrade's, simply because it is expected to work well. So it is a mistake to focus on specific tech issues alone. This problem is also about expectations and user perceptions. Announcing "support" for dist upgrade and appealing for test, so work rounds can be found, for release notes at time matters to. #21: Cristian Rodríguez (elvigia) (2009-02-02 15:29:32) (reply to #19) as you failed to elaborate on the problem, I will.. Some people end with broken /etc/pam.d/login they have the following line session required pam_resmgr.so but that module is gone, and rpm upgrade does not remove that line (probably because that file has been modified) #24: JP Rosevear (jproseve) (2009-02-02 10:15:19) (reply to #21) Isn't that simply a packaging problem? + #25: Klaus Kämpf (kwk) (2009-02-02 19:42:45) (reply to #24) + In this case, it looks like a packaging problem, indeed. + However, we had more complicated upgrade tasks in the past, like + dropping devs.rpm and running udev instead. + See Removing devs.rpm + (http://en.opensuse.org/Software_Management/Upgrade/Devs_Rpm) for a + discussion of the problem. #20: Robert Davies (robopensuse) (2009-02-02 14:48:34) On Scope, here are the Release Notes for Lenny - http://www.uk.debian.org/releases/testing/amd64/release-notes/ 4.1.4 - Prepare a safe environment for the upgrade - text mode or via ssh login, Article on how to go from Etch to Lenny - http://www.debianadmin.com/howto-upgrade-from-debian-etch-40-to-lenny-50.ht… #22: Manuel Trujillo (toomany) (2009-02-02 15:44:44) I think this is a really helpful characteristic, because a lot of people like me, use openSUSE as server, and is a true hell to upgrade servers in any datacenter, at kilometers off distance. I hope this feature will be a reallity in the next 11.2. #23: Duncan Mac-Vicar (dmacvicar) (2009-02-02 15:46:27) (reply to #22) Please, if you just want to express your favorites, use the voting feature. Comments is for discussion around solving the problem itself. -- openSUSE Feature: https://features.opensuse.org/305634

1 0

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

02 Feb '09

Feature changed by: JP Rosevear (jproseve) Feature #305634, revision 58 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) Yes, the PAM maintainers would like to know more details, too. #19: Robert Davies (robopensuse) (2009-02-02 13:45:04) (reply to #18) There were a number of different forum poster's hitting it, just after 11.1 released (I think due to zypper dup not YaST upgrade and therefore unreported to BugZilla). It is not something I had, because I did fresh installs. Interestingly though I have used Debian less, I have done several dist-upgrade's, simply because it is expected to work well. So it is a mistake to focus on specific tech issues alone. This problem is also about expectations and user perceptions. Announcing "support" for dist upgrade and appealing for test, so work rounds can be found, for release notes at time matters to. #21: Cristian Rodríguez (elvigia) (2009-02-02 15:29:32) (reply to #19) as you failed to elaborate on the problem, I will.. Some people end with broken /etc/pam.d/login they have the following line session required pam_resmgr.so but that module is gone, and rpm upgrade does not remove that line (probably because that file has been modified) + #24: JP Rosevear (jproseve) (2009-02-02 10:15:19) (reply to #21) + Isn't that simply a packaging problem? #20: Robert Davies (robopensuse) (2009-02-02 14:48:34) On Scope, here are the Release Notes for Lenny - http://www.uk.debian.org/releases/testing/amd64/release-notes/ 4.1.4 - Prepare a safe environment for the upgrade - text mode or via ssh login, Article on how to go from Etch to Lenny - http://www.debianadmin.com/howto-upgrade-from-debian-etch-40-to-lenny-50.ht… #22: Manuel Trujillo (toomany) (2009-02-02 15:44:44) I think this is a really helpful characteristic, because a lot of people like me, use openSUSE as server, and is a true hell to upgrade servers in any datacenter, at kilometers off distance. I hope this feature will be a reallity in the next 11.2. #23: Duncan Mac-Vicar (dmacvicar) (2009-02-02 15:46:27) (reply to #22) Please, if you just want to express your favorites, use the voting feature. Comments is for discussion around solving the problem itself. -- openSUSE Feature: https://features.opensuse.org/305634

1 0

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

02 Feb '09

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #305634, revision 56 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) Yes, the PAM maintainers would like to know more details, too. #19: Robert Davies (robopensuse) (2009-02-02 13:45:04) (reply to #18) There were a number of different forum poster's hitting it, just after 11.1 released (I think due to zypper dup not YaST upgrade and therefore unreported to BugZilla). It is not something I had, because I did fresh installs. Interestingly though I have used Debian less, I have done several dist-upgrade's, simply because it is expected to work well. So it is a mistake to focus on specific tech issues alone. This problem is also about expectations and user perceptions. Announcing "support" for dist upgrade and appealing for test, so work rounds can be found, for release notes at time matters to. #21: Cristian Rodríguez (elvigia) (2009-02-02 15:29:32) (reply to #19) as you failed to elaborate on the problem, I will.. Some people end with broken /etc/pam.d/login they have the following line session required pam_resmgr.so but that module is gone, and rpm upgrade does not remove that line (probably because that file has been modified) #20: Robert Davies (robopensuse) (2009-02-02 14:48:34) On Scope, here are the Release Notes for Lenny - http://www.uk.debian.org/releases/testing/amd64/release-notes/ 4.1.4 - Prepare a safe environment for the upgrade - text mode or via ssh login, Article on how to go from Etch to Lenny - http://www.debianadmin.com/howto-upgrade-from-debian-etch-40-to-lenny-50.ht… #22: Manuel Trujillo (toomany) (2009-02-02 15:44:44) I think this is a really helpful characteristic, because a lot of people like me, use openSUSE as server, and is a true hell to upgrade servers in any datacenter, at kilometers off distance. I hope this feature will be a reallity in the next 11.2. + #23: Duncan Mac-Vicar (dmacvicar) (2009-02-02 15:46:27) (reply to #22) + Please, if you just want to express your favorites, use the voting + feature. Comments is for discussion around solving the problem itself. -- openSUSE Feature: https://features.opensuse.org/305634

1 0

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

02 Feb '09

Feature changed by: Manuel Trujillo (toomany) Feature #305634, revision 55 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) Yes, the PAM maintainers would like to know more details, too. #19: Robert Davies (robopensuse) (2009-02-02 13:45:04) (reply to #18) There were a number of different forum poster's hitting it, just after 11.1 released (I think due to zypper dup not YaST upgrade and therefore unreported to BugZilla). It is not something I had, because I did fresh installs. Interestingly though I have used Debian less, I have done several dist-upgrade's, simply because it is expected to work well. So it is a mistake to focus on specific tech issues alone. This problem is also about expectations and user perceptions. Announcing "support" for dist upgrade and appealing for test, so work rounds can be found, for release notes at time matters to. #21: Cristian Rodríguez (elvigia) (2009-02-02 15:29:32) (reply to #19) as you failed to elaborate on the problem, I will.. Some people end with broken /etc/pam.d/login they have the following line session required pam_resmgr.so but that module is gone, and rpm upgrade does not remove that line (probably because that file has been modified) #20: Robert Davies (robopensuse) (2009-02-02 14:48:34) On Scope, here are the Release Notes for Lenny - http://www.uk.debian.org/releases/testing/amd64/release-notes/ 4.1.4 - Prepare a safe environment for the upgrade - text mode or via ssh login, Article on how to go from Etch to Lenny - http://www.debianadmin.com/howto-upgrade-from-debian-etch-40-to-lenny-50.ht… + #22: Manuel Trujillo (toomany) (2009-02-02 15:44:44) + I think this is a really helpful characteristic, because a lot of + people like me, use openSUSE as server, and is a true hell to upgrade + servers in any datacenter, at kilometers off distance. I hope this + feature will be a reallity in the next 11.2. -- openSUSE Feature: https://features.opensuse.org/305634

1 0

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

02 Feb '09

Feature changed by: Cristian Rodríguez (elvigia) Feature #305634, revision 54 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) Yes, the PAM maintainers would like to know more details, too. #19: Robert Davies (robopensuse) (2009-02-02 13:45:04) (reply to #18) There were a number of different forum poster's hitting it, just after 11.1 released (I think due to zypper dup not YaST upgrade and therefore unreported to BugZilla). It is not something I had, because I did fresh installs. Interestingly though I have used Debian less, I have done several dist-upgrade's, simply because it is expected to work well. So it is a mistake to focus on specific tech issues alone. This problem is also about expectations and user perceptions. Announcing "support" for dist upgrade and appealing for test, so work rounds can be found, for release notes at time matters to. + #21: Cristian Rodríguez (elvigia) (2009-02-02 15:29:32) (reply to #19) + as you failed to elaborate on the problem, I will.. Some people end + with broken /etc/pam.d/login they have the following line + session required pam_resmgr.so but that module is gone, and rpm + upgrade does not remove that line (probably because that file has been + modified) #20: Robert Davies (robopensuse) (2009-02-02 14:48:34) On Scope, here are the Release Notes for Lenny - http://www.uk.debian.org/releases/testing/amd64/release-notes/ 4.1.4 - Prepare a safe environment for the upgrade - text mode or via ssh login, Article on how to go from Etch to Lenny - http://www.debianadmin.com/howto-upgrade-from-debian-etch-40-to-lenny-50.ht… -- openSUSE Feature: https://features.opensuse.org/305634

1 0

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

02 Feb '09

Feature changed by: Robert Davies (robopensuse) Feature #305634, revision 53 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) Yes, the PAM maintainers would like to know more details, too. #19: Robert Davies (robopensuse) (2009-02-02 13:45:04) (reply to #18) There were a number of different forum poster's hitting it, just after 11.1 released (I think due to zypper dup not YaST upgrade and therefore unreported to BugZilla). It is not something I had, because I did fresh installs. Interestingly though I have used Debian less, I have done several dist-upgrade's, simply because it is expected to work well. So it is a mistake to focus on specific tech issues alone. This problem is also about expectations and user perceptions. Announcing "support" for dist upgrade and appealing for test, so work rounds can be found, for release notes at time matters to. + #20: Robert Davies (robopensuse) (2009-02-02 14:48:34) + On Scope, here are the Release Notes for Lenny - + http://www.uk.debian.org/releases/testing/amd64/release-notes/ 4.1.4 - + Prepare a safe environment for the upgrade - text mode or via ssh + login, Article on how to go from Etch to Lenny - http://www.debianadmin.com/howto-upgrade-from-debian-etch-40-to-lenny-50.ht… -- openSUSE Feature: https://features.opensuse.org/305634

1 0

[openFATE 302921] Testing openSUSE Feature Tracking
by fate_noreply＠suse.de 02 Feb '09

02 Feb '09

Feature changed by: Jan Engelhardt (jengelh) Feature #302921, revision 24 Title: Testing openSUSE Feature Tracking openSUSE-10.3: Done Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Partner organization: openSUSE.org Description: Just a test - should go to opensuse-features(a)opensuse.org Discussion: #1: Hendrik Vogelsang (hennevogel) (2007-10-30 13:00:36) blah blah blah #2: Hendrik Vogelsang (hennevogel) (2007-10-30 13:02:35) (reply to #1) blubb lubb lbuib #13: Hendrik Vogelsang (hennevogel) (2007-10-30 13:57:04) (reply to #1) dsdsdwsd #14: Hendrik Vogelsang (hennevogel) (2007-10-30 13:59:12) (reply to #13) wsdsdsds #15: Hendrik Vogelsang (hennevogel) (2007-10-30 14:01:10) (reply to #13) dsdsds #16: Hendrik Vogelsang (hennevogel) (2007-10-30 14:11:35) (reply to #13) ddsddds #3: Hendrik Vogelsang (hennevogel) (2007-10-30 13:12:39) this is working #4: Hendrik Vogelsang (hennevogel) (2007-10-30 13:16:03) (reply to #3) or bnot #10: Hendrik Vogelsang (hennevogel) (2007-10-30 13:48:53) (reply to #3) dwsdsdsd #5: Hendrik Vogelsang (hennevogel) (2007-10-30 13:27:44) swsasaas #6: Hendrik Vogelsang (hennevogel) (2007-10-30 13:33:36) sqsqasas #7: Hendrik Vogelsang (hennevogel) (2007-10-30 13:36:11) wdwdswd #8: Hendrik Vogelsang (hennevogel) (2007-10-30 13:38:00) dwsdsds #9: Hendrik Vogelsang (hennevogel) (2007-10-30 13:46:33) wswdds #11: Michael Loeffler (sprudel24) (2007-10-30 13:49:14) wjnd sd s�dlkj sid #12: Hendrik Vogelsang (hennevogel) (2007-10-30 13:52:27) (reply to #11) sasasas #17: Hendrik Vogelsang (hennevogel) (2007-10-30 14:48:56) (reply to #12) xdsdsds #18: Gerald Pfeifer (geraldpfeifer) (2007-11-02 21:51:25) Moving from openSUSE 10.3 to openSUSE 11.0. #19: Juergen Weigert (jnweiger) (2008-07-29 21:53:03) ping-pong. #20: Thomas Schmidt (digitaltomm) (2009-01-05 15:54:14) test... updated keeper + #21: Jan Engelhardt (jengelh) (2009-02-02 13:45:36) + My comment is supposed not to be saved! -- openSUSE Feature: https://features.opensuse.org/302921

1 0

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

02 Feb '09

Feature changed by: Robert Davies (robopensuse) Feature #305634, revision 52 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) Yes, the PAM maintainers would like to know more details, too. + #19: Robert Davies (robopensuse) (2009-02-02 13:45:04) (reply to #18) + There were a number of different forum poster's hitting it, just after + 11.1 released (I think due to zypper dup not YaST upgrade and therefore + unreported to BugZilla). It is not something I had, because I did fresh + installs. Interestingly though I have used Debian less, I have done + several dist-upgrade's, simply because it is expected to work well. So + it is a mistake to focus on specific tech issues alone. This problem is + also about expectations and user perceptions. Announcing "support" for + dist upgrade and appealing for test, so work rounds can be found, for + release notes at time matters to. -- openSUSE Feature: https://features.opensuse.org/305634

1 0

[openFATE 303678] New yast module - LIRC configuration
by fate_noreply＠suse.de 02 Feb '09

02 Feb '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #303678, revision 19 Title: New yast module - LIRC configuration openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-06-24 15:31:30 reject reason: More urgent stuff to cover. Priority Requester: Desirable - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Stanislav Visnovsky <visnov(a)novell.com> + reject date: 2009-02-02 13:29:45 + reject reason: Out of scope. Postponing. Priority Requester: Desirable + openSUSE-11.3: New + Priority + Requester: Desirable Requested by: Ladislav Slezak (lslezak) Partner organization: openSUSE.org Description: Create a new Yast module for configuring IR receivers and remote controls. * irrecord support * ir-kbd-i2c, ir-kbd-gpio support as in tv module already * reading users' config to find out what buttons were defined (only if /home partition left from last installation) * support for lirc's options in /etc/sysconfig See bug https://bugzilla.novell.com/show_bug.cgi?id=381641 -- openSUSE Feature: https://features.opensuse.org/303678

1 0

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

02 Feb '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #305394, revision 12 Title: Move KDE software updates notifications to upstream infrastructure openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Important Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: As kpackagekit matures, it may be the case that for 11.2 it is mature enough for replacing kupdateapplet. It already implements various aspects of kupdateapplet: * notifications (knotify) using a kded service (which takes care of refreshing too) * single update selection (kpackagekit gui) * uses a upstream client library for communication with PackageKit, which are better than our PackageKit communication code. Scope kpackagekit is meant here only to replace kupdateapplet. There is not relation with YaST here. Open Issues: * tray notification: may require implementing a plasma tray icon * SUSE specific code (smolt, registration, hardware search) * Requires some research how to introduce those extensions in kpackagekit, or move SUSE specific parts out, like another kded service. User experience Should stay the same Dependencies * PackageKit * libpackagekit-qt Contingency Plan In the case kpackagekit is not yet mature enough, the same resources invested now in kupdateapplet can be invested in improving kpackagekit. Otherwise, we can stay with kupdateapplet as a fallback. Relations: - kpackagekit author interview (url: http://polishlinux.org/kde/kpackagekit-interview/) - kpackagekit screenshot (url: http://www.packagekit.org/img/kpk-update.png) Test Case: * new patches should be notified by knotify * user should be able to see update availability * user should be able to see detailed update information, as well as selecting individual updates * user should get informed if the update repositories configuration has a problem * user should be informed of (available) drivers for plugged hardware Business case (Partner benefit): openSUSE.org: Right now software notifications are done using the kupdateapplet, which comes from the opensuse-updater code,(renamed in a non sucessful attept to upstream it). This applet come from a summer of code project, originally done as a zmd client, then evoluted to a zypper client, and now working as a PackageKit client. Sadly, during 10.3 cycle this applet got the feature to select updates individually and other small stuff which turned it into a very complicated piece of code, and started to became a package manager on its own. Later it became the favorite place to plug any kind of notifications, like registration needed, smolt participation, etc, and right now the code is much more complex that it should be (thus taking more maintenance and testing than it should require). This feature has the objective of cleaning up this situation to free resources in this area. With the progress of packagekit and recently, kpackagekit, this should be possible. kpackagekit already implements various of the needed aspects, and therefore it would mean getting rid of in house code for upstream code. Additionally, it would result in a much more consistant user experience as the tools would be similar across distributions. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 14:24:20) Looks like Duncan is in favor of this. Stano? If you guys are comfortable with the change, I am all for it. But remember, priority #1 is dist-upgrade. -- openSUSE Feature: https://features.opensuse.org/305394

1 0

[openFATE 302119] Load package selector and libzypp only when needed
by fate_noreply＠suse.de 02 Feb '09

02 Feb '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #302119, revision 32 Title: Load package selector and libzypp only when needed openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-08-01 16:40:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-04-28 13:42:30 reject reason: Did not make it, postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-09-12 14:13:58 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Stanislav Visnovsky <visnov(a)novell.com> + reject date: 2009-02-02 13:15:32 + reject reason: Out of scope. Priority Requester: Desirable + openSUSE-11.3: New + Priority + Requester: Desirable Requested by: Stefan Hundhammer (sh-sh-sh) Partner organization: openSUSE.org Description: The YaST2 UI should load the code for the package selector and libzypp only when needed. Not all applications / YaST2 modules need package selection code, yet for all of them the respective code from the YaST2 UI and libzypp is loaded. Discussion: #1: Stefan Hundhammer (sh-sh-sh) (2007-04-13 18:13:44) In the YaST2 Qt the package management related code is now moved to a separate plugin that is loaded upon demand only if the calling YCP application actually requests a PackageSelector widget. This reduces the memory footprint from 20 MB VmRSS minimum (HelloWorld. ycp) to 18 MB minimum (PackageSelector-empty.ycp). #3: Katarina Machalkova (kmachalkova) (2007-04-16 14:41:35) Stano, do we want this for curses UI as well? If yes, than it's not 'done' ... #4: Stanislav Visnovsky (visnov) (2007-04-16 14:47:02) (reply to #3) Agreed. Reopening for ncurses and possibly gtk+. #5: Jiri Srain (jsrain) (2007-06-13 13:54:26) JP, both Qt and NCurses are done, but GTK is still missing. #6: Stefan Hundhammer (sh-sh-sh) (2007-06-13 15:08:58) Looks like yast2-pkg-bindings are also loaded unconditionally. It shouldn't be too hard to do that with "lazy initialization" like UI built-ins: Postpone loading the Y2Component until it's really needed. #7: Stanislav Visnovsky (visnov) (2007-06-19 15:01:54) (reply to #6) Jiri, if Pkg bindings problem is not addressed, it does not make sense to fix Gtk UI. #8: Jiri Srain (jsrain) (2007-07-18 13:59:50) (reply to #7) Sorry for missing this. Martin, please, solve this for the Pkg bindings. #11: Martin Vidner (mvidner) (2008-04-10 15:23:51) yast2-perl-bindings-2.16.6 no longer links to libzypp, which means libzypp will not be loaded at the very start of yast (perl still will be loaded, but that is relatively cheap). That helps in some cases, but mostly it only delays loading of libzypp, which occurs as soon as Pkg (or Package) is imported. Now I need to make Pkg lazy. #12: Martin Vidner (mvidner) (2008-04-21 15:32:09) I have it almost working, but got stopped by bug 381917 (https://bugzilla.novell.com/show_bug.cgi?id=381917) : problems with destructors of static objects #13: JP Rosevear (jproseve) (2008-07-21 13:59:18) (reply to #12) Martin, what's the status here? Will we need to do anything explicit in packagekit to get this functionality? #14: Stanislav Visnovsky (visnov) (2008-09-08 16:44:06) (reply to #13) There is nothing regarding packagekit for this feature. -- openSUSE Feature: https://features.opensuse.org/302119

1 0

[openFATE 100048] MySQL Configuration
by fate_noreply＠suse.de 02 Feb '09

02 Feb '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #100048, revision 27 Title: MySQL Configuration openSUSE-10.3: Rejected by Andreas Jaeger <aj(a)novell.com> reject date: 2007-07-16 19:10:56 reject reason: Too late for 10.3. Priority Requester: Desirable openSUSE-11.0: Rejected by Duncan Mac-Vicar <dmacvicar(a)novell.com> reject date: 2008-03-18 12:42:12 reject reason: We don't have the resources to finish this module. I will move it to http://en.opensuse.org/Summer_of_Code_2008#YaST_ideas Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-06-26 16:11:49 reject reason: Out of resources. Priority Requester: Desirable - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Stanislav Visnovsky <visnov(a)novell.com> + reject date: 2009-02-02 13:14:30 + reject reason: Out of scope. Priority Requester: Desirable Requested by: Lukas Ocilka (locilka) Partner organization: openSUSE.org Description: MySQL is used very often on servers. There should be management tool for databases, and database-users and for some mysql-variables (key_buffer, write_buffer and more). Discussion: #1: Lukas Ocilka (locilka) (2005-11-29 15:46:59) Novell to Offer MySQL Network * http://www.mysql.com/news-and-events/press-release/release_2005_28.html * Novell offers affordable database software and support services through 'MySQL Network' subscriptions #2: Gerald Pfeifer (geraldpfeifer) (2006-01-03 14:03:13) Holger, can you please qualify this from a PM perspective? (Not for CODE10, of course, but CODE11 or SL10.2/10.3, for example.) #5: Duncan Mac-Vicar (dmacvicar) (2008-03-18 12:41:18) We don't have the resources to finish this module. I will move it to http://en.opensuse.org/Summer_of_Code_2008#YaST_ideas -- openSUSE Feature: https://features.opensuse.org/100048

1 0

[openFATE 305268] Refactor bootloader UI
by fate_noreply＠suse.de 02 Feb '09

02 Feb '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #305268, revision 4 Title: Refactor bootloader UI openSUSE-11.2: Evaluation Priority Requester: Mandatory + Projectmanager: Mandatory Requested by: Jiri Srain (jsrain) + Partner organization: openSUSE.org Description: In order to simplify maintenance, allow to fix some bugs and also use more flexibility of YaST UI, the user interface of the bootloader module should be rewritten to YCP instead of using generator with limited possibilities. Discussion: #2: Federico Lucifredi (flucifredi) (2009-01-26 20:45:53) prioritizing cleanup task as per plan. + #3: Stanislav Visnovsky (visnov) (2009-02-02 13:11:26) + Jiri, please, document the planned changes and provide a link for the + feature. -- openSUSE Feature: https://features.opensuse.org/305268

1 0

[openFATE 305622] Add support for lzop compression to GNU tar
by fate_noreply＠suse.de 02 Feb '09

02 Feb '09

Feature changed by: Matthias Eckermann (mge1512) Feature #305622, revision 11 Title: Add support for lzop compression to GNU tar openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Matthias Eckermann (mge1512) Partner organization: openSUSE.org Description: (iaW) update to tar 1.21 + Use Case: + 'tar' is one of the most important archiving tools for Linux and Unix- + like systems in general. Our version should be capable of interacting + with all other versions including the respective compression algorithms + and tools. Discussion: #1: Jan Engelhardt (jengelh) (2009-01-19 09:32:51) tar --use=lzop -cf foo.tar.lzop #2: roland kletzing (rkletzin) (2009-01-20 21:44:53) shouldn`t we first have lzop package being part of the distro/factory, before make standard tools using it? (also see https://bugzilla.novell.com/show_bug.cgi?id=461228) it`s on the wishlist for a long time now, glad to see that we have openFate now (since adding to the wishlist was as good as talking to a wall) -- openSUSE Feature: https://features.opensuse.org/305622

1 0

[openFATE 302963] Rating support for FATE
by fate_noreply＠suse.de 02 Feb '09

02 Feb '09

Feature changed by: Michael Loeffler (sprudel24) Feature #302963, revision 19 Title: Rating support for FATE openFATE: Evaluation Priority Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: FATE is becoming a huge database of useless information. Most of this come to the fact that there is only syntantic checking but not social checking. Usecase: Searching and navigating produces lot of: * Duplicate features * Incomplete features (no use cases, examples) * Vague features (a.k.a "#xxxxx YaST should be improved" ) * copy and paste features Features should support rating in the slashdot way (Insightful, Interesting, Informative, Troll, Funny) and rating from 1 to 5. The rating could be used so the same people using FATE could score down low- quality features than only make the process of information flow more difficult. Score threshold could be set by people so only high quality, well specified features are shown. It is important that searching could be done using this ratings. It should be possible to generate rankings over this ratings. Current status FATE does not offer anything to filter low quality features User Experience Query dialog would gain an option for searching. Feature editor would gain a rating dialog where different people would express their rating. Search would be over an average or agregation of this scores. Scores should be saved per rater. Contingency Plan No contingency plan at the software level. At the process level, add comments to every feature lacking business case, detailed description, real benefits, and more important, scope. Documentation Impact: Only needs to be mentioned in the handbook. Test Case: * rate a feature in one or two dimensions (score and category) * search for features >= or <= certain rating Business case (Partner benefit): openSUSE.org: Threshold for feature processing should save thousands of dollars in wasted time doing ping pong, needinfos for features with incomplete information. Even engineering could be optimized when features with no real business case dissapear by social tagging. Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2008-04-02 01:26:51) Sounds like an interesting idea for openSUSE. I am looking forward towards considering this for some Phase 2 or so once openFATE (or whatever the name is going to be) is up and running. #3: Stephan Binner (beineri) (2009-01-17 16:03:07) (reply to #1) openFATE is now up and running. Can this request be made public to openSUSE.org partner? #2: Gerald Pfeifer (geraldpfeifer) (2008-11-14 18:05:55) Michl, for the openFATE work. (For SLE, I expect the PMs to take on much of this.) #4: Francis Giannaros (apokryphos) (2009-01-28 16:04:18) This would be great to see. For reference, see https://blueprints.launchpad.net/ubuntu with some good ideas. Also a tag cloud like the build service has might be nice. #5: Andre Duffeck (aduffeck) (2009-01-28 16:14:23) (reply to #4) We will release a new openFATE version by the end of the week with both voting and tagging support (including a cloud ;)) #7: Francis Giannaros (apokryphos) (2009-01-30 20:29:40) (reply to #5) Awesome! #6: Thomas Schmidt (digitaltomm) (2009-01-30 15:12:39) Rating features is available now in openfate with the three options -0 +. Searching for features with or above a certain score is not yet there. Do we need to integrate the voting and search by rating stuff in the FATE client or is this just a community feature? #8: Stephan Binner (beineri) (2009-01-31 11:46:14) (reply to #6) Can you please add a voting column to the browse/query result list and allow sorting by it? Atm you seem to be only able to view the top 5 voted requests (on the dashboard). + #10: Michael Loeffler (sprudel24) (2009-02-02 11:35:31) (reply to #8) + Yes, it would be useful to see the score already while brosing through + the features. + #9: Michael Loeffler (sprudel24) (2009-02-02 11:34:32) (reply to #6) + Voting is not necessary for the internal client. Internal features + should be more driven by use case and business case. For openFate the + public opinion is more important to know. But the voting score of + external features should be displayed internally. -- openSUSE Feature: https://features.opensuse.org/302963

1 0

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

02 Feb '09

Feature changed by: Thorsten Kukuk (kukuk) Feature #305634, revision 51 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? + #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) + Yes, the PAM maintainers would like to know more details, too. -- openSUSE Feature: https://features.opensuse.org/305634

1 0

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

02 Feb '09

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #305634, revision 50 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory + Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. + #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) + Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). + #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) + Exactly, but if we don't know what specific problems are we hitting + during distupgrade the feature has no real work and specific problems + can be tracked as bugs. + FATE is not a place for "make this better" without concrete + requirements or "make an unfalible distupgrade". + If requester, prjmgr, or pm expects anything to be done in the area, we + need at least: + * A list of problems we hit during dist upgrade (I am aware of one + specific, which is download-install sequence if network goes down) + * The scope. As you mention, asking to close every application (or + service) is not much to ask. Therefore the scope has to be set, because + if the scope is "distupgrade and glbc upgrade while oracle process + hospital monitoring equipment transactions" then this is a very + expensive feature. + #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) + btw, can you describe in technical detail the pam upgrade problem so we + can document it? -- openSUSE Feature: https://features.opensuse.org/305634

1 0

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

01 Feb '09

Feature changed by: Thomas Beimel (RheydterGekko) Feature #305296, revision 16 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Partner organization: openSUSE.org Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) + #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) + Yes this would be an perfect option during installation. Especially + because I prefer to have a new installation that consumes as less + resources as possible. I do not need indexing service and I think many + others as well. -- openSUSE Feature: https://features.opensuse.org/305296

1 0