February 2010 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 309013] Transmission Init Script
by fate_noreply＠suse.de 16 Feb '10

16 Feb '10

Feature added by: Amir Ali (lordemsworth) Feature #309013, revision 1 Title: Transmission Init Script Package Wishlist: Unconfirmed Priority Requester: Desirable Requested by: Amir Ali (lordemsworth) Description: Ubuntu and Fedora both have an init script for Transmission-daemon. Is it possible to package an init script in version 1.83/1.84? Why do we want this? More and more users are building headless servers. Other distributions are offering the same functionality. -- openSUSE Feature: https://features.opensuse.org/309013

1 0

[New: openFATE 309011] Perl DVB-T module for recording & EPG
by fate_noreply＠suse.de 15 Feb '10

15 Feb '10

Feature added by: Steve Price (sdprice1) Feature #309011, revision 1 Title: Perl DVB-T module for recording & EPG Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Steve Price (sdprice1) Partner organization: openSUSE.org Description: Perl module distributed on CPAN: Linux-DVB-DVBT (http://search.cpan.org/~SDPRICE/Linux-DVB-DVBT) Linux::DVB::DVBT is a package that provides an object interface to any installed Freeview tuner cards fitted to a Linux PC. The package supports initial set up (i.e. frequency scanning), searching for the latest electronic program guide (EPG), and selectign a channel for recording the video to disk. Now also supports multiplex recording (i.e. recording multiple channels at the same time using a single tuner device). Where broadcast, logical channel numbers are automatically used. Allows a very simple "mythtv-like" Linux PVR system to be created, written in Perl. Example scripts have been provided in the package which illustrate the expected use of the package (and are useable programs in themeselves) dvbt-devices Shows information about fited DVB-T tuners dvbt-scan Run this by providing the frequency file (usually stored in /usr/share/dvb/dvb-t). If run as root, this will set up the configuration files for all users. For example: $ dvbt-scan /usr/share/dvb/dvb-t/uk-Oxford NOTE: Frequency files are provided by the 'dvb' rpm package available for most distros dvbt-epg When run, this grabs the latest EPG information and updates a MySql database: $ dvbt-epg dvbt-record Specify the channel, the duration, and the output filename to record a channel: $ dvbt-record "bbc1" spooks.ts 1:00 Note that the duration can be specified as an integer (number of minutes), or in HH:MM format (for hours and minutes) dvbt-ffrec Similar to dvbt-record, but pipes the transport stream into ffmpeg and uses that to transcode the data directly into an MPEG file (without saving the transport stream file). Specify the channel, the duration, and the output filename to record a channel: $ dvbt-ffrec "bbc1" spooks.mpeg 1:00 Note that the duration can be specified as an integer (number of minutes), or in HH:MM format (for hours and minutes) dvbt-chans Use to display the current list of tuned channels. Shows them in logical channel number order. Use Case: The simplest use case is where a list of cron jobs (using dvbt-record or dvbt-ffrecord) are created by hand to record programs as required. A better alternative is to use the EPG data to automatically create cron jobs for series recording etc. The recorded videos combined with a UPnP media server (e.g. fuppes, mediatomb) provide PVR capability. Business case (Partner benefit): openSUSE.org: This fills the gap where a user wants to have a simple/easy means of creating a PVR on his Linux machine without the difficulty of installing MythTV, or getting another PVR-type system build and installed. By providing simple building blocks, a user can tailor the system to his own requirements. -- openSUSE Feature: https://features.opensuse.org/309011

1 0

[New: openFATE 309003] perl-Wx
by fate_noreply＠suse.de 15 Feb '10

15 Feb '10

Feature added by: Jon Buckingham (jonbuckingham) Feature #309003, revision 1 Title: perl-Wx openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Jon Buckingham (jonbuckingham) Description: It would be really nice to have perl-Wx available for opensuse (11.2 also!) Thanks -- openSUSE Feature: https://features.opensuse.org/309003

1 2

[New: openFATE 308966] Change default passwd hash algorithm to sha512
by fate_noreply＠suse.de 14 Feb '10

14 Feb '10

Feature added by: Stephan Kleine (bitshuffler) Feature #308966, revision 1 Title: Change default passwd hash algorithm to sha512 openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Stephan Kleine (bitshuffler) Partner organization: openSUSE.org Description: Change the default hashing algorithm that gets used by passwd and friends to something more secure than md5 in /etc/default/passwd (preferable sha512). Also please do this ASAP since we are early enough in the development cycle so any unexpected side effects get discovered and fixed before release. Business case (Partner benefit): openSUSE.org: The reason behind this change is that nowadays md5 simply isn't secure anymore. -- openSUSE Feature: https://features.opensuse.org/308966

1 2

[New: openFATE 308367] Rename YaST2 to YaST
by fate_noreply＠suse.de 14 Feb '10

14 Feb '10

Feature added by: Lars Müller (lmuelle) Feature #308367, revision 1 Title: Rename YaST2 to YaST openSUSE-11.3: New Priority Requester: Desirable Requested by: Lars Müller (lmuelle) Partner organization: openSUSE.org Description: YaST1 is gone for a long time but we still use everywhere YaST2. I'm not suggesting to drop the yast2 cmd. My intention is to only use the word "YaST" in the documentation (in the app and printed) and in the screenshots. See also http://bugzilla.novell.com/show_bug.cgi?id=555659 Business case (Partner benefit): openSUSE.org: Make the wording easier. Make IT Work As One. ;) -- openSUSE Feature: https://features.opensuse.org/308367

1 2

[New: openFATE 308973] Tool to do on-line "ext3" filesystem extension
by fate_noreply＠suse.de 14 Feb '10

14 Feb '10

Feature added by: Dennis Olsson (DOL2009) Feature #308973, revision 1 Title: Tool to do on-line "ext3" filesystem extension openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Dennis Olsson (dol2009) Partner organization: openSUSE.org Description: Currently it is not possible to do on-line extension of mounted " ext3 " file systems, while the necessary userland tool "ext2online" is missing, although the kernel (seems to) support(s) it. Have always wonder, why this tool was never added to "openSUSE/SLEx"... Business case (Partner benefit): openSUSE.org: Especially when using file systems under LVM control, the benefit of being able to do on-line extension of a mounted file system increases the usefulness of e.g. server, while not being forced to take the applications down during the file system extension. -- openSUSE Feature: https://features.opensuse.org/308973

1 1

[openFATE 307391] yast2-control-center-qt4 move back to qt "appereance"
by fate_noreply＠suse.de 14 Feb '10

14 Feb '10

Feature added by: andrea florio (anubisg1) Feature #307391, revision 1 Title: yast2-control-center-qt4 move back to qt "appereance" openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: andrea florio (anubisg1) Description: Finally yast developers are moving control-center to qt4, but installing the version provided in kde:kde4:factory:desktop i saw that really bad looking, It actually lookss the gnome version written in qt4, with that i mean that it appears like a single long list of yast modules. That list is too long and confuse the user, in the same way, selecting groups on right side, produce nothing useful because the modules available on that groups are still hidden (only the first one is on the bottom of the page). i think developers should maintain qt3 layout where you see only modules available on that group and possibly in 2 or more columns -- openSUSE Feature: https://features.opensuse.org/307391

1 9

[openFATE 302306] Reorganization of YaST control center
by fate_noreply＠suse.de 13 Feb '10

13 Feb '10

Feature changed by: Ladislav Horvath (6205) Feature #302306, revision 76 Title: Reorganization of YaST control center openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-03 17:08:02 reject reason: Postponing, we are running out of time. Priority Requester: Mandatory openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-25 15:09:31 reject reason: Needs more discussion. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.1: Rejected by Federico Lucifredi (flucifredi) reject date: 2008-07-18 18:56:09 reject reason: postponing as per engineering's request. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Rejected by Jiri Srain (jsrain) reject date: 2009-07-17 10:19:44 reject reason: Let's do it early in the 11.2 development cycle to have feedback from Alpha snapshots and be able to adjust. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Mandatory Projectmanager: Important Requested by: Martin Schmidkunz (mschmidkunz) Description: As many users (even the experienced ones) find the current organization of YaST modules confusing a reorganization is needed. We have conducted a usability study where experienced users sorted the YaST modules. So I would really ask to take advantage of these data. You find the data and some thoughts about a possible re-categorization on: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study The reorganization would affect the sorting and presentation, some labeling issues, the use of a consistent icon set, the use of tool tips and an enhancment of search One possible solution would be to organize it similar to the GNOME configuration center: I already heard that it might be mandatory to present AppArmor as an extra section (which in my opinion would be not advisable from a usability perspective, but if it is mandatory, then we have to add it as an extra section). I also thought that some YaST modules (e.g. keyboard, mouse, DNS, Hostname) are doublicated but it turned out, that this makes sense for SLES. Still I suggest combining the modules "user management" and "group management" into a single module called "User and Group Management". This makes sense because opening "user management" and "group management" opens the same module but only show a different view. Documentation Impact: This would require a lot of changes throughout the manuals. Discussion: #1: Tanja Roth (ta-ro) (2007-05-30 14:33:36) Would a reorganization apply to both KDE and GNOME desktop, then? Whatever a new YaST structure would look like, from a doc perspective it would be important that YaST structure and appearance are in sync for both desktops as we strive to use a "common doc base" for both desktops whereever possible to reduce efforts and costs. As reorganization of YaST would require many changes throughout our manuals, we cannot afford to additionally maintain different "flavors" of YaST chapters for KDE/GNOME. Apart from that, consistent structure and appearance of YaST in both desktops would also be a benefit for users. #2: Stanislav Visnovsky (visnov) (2007-06-12 11:40:45) Sigi, is the card study finished now? Where can we find the results? #3: Martin Schmidkunz (mschmidkunz) (2007-06-12 13:58:58) > Would a reorganization apply to both KDE and GNOME desktop, then? Yes. Exactly for the reasons you named, Tanja :-) By the way, a reorganization of YaST control center already took place in SLES 10 SP1. This solution is similar to what Sigi and I suggested. Perhaps it would be a good idea to take the YaST control center as it is in SLES 10 SP1, improve it a little and implement its design into all our products. What do you think about that? #4: Stanislav Visnovsky (visnov) (2007-06-12 14:00:46) (reply to #3) There was no reorganization for SLE10 SP1. The only change was introduction of slab-based GNOME control center for YaST. The categorization, description and module lists did not change and are shared between KDE and GNOME control centers. #5: Martin Schmidkunz (mschmidkunz) (2007-06-12 18:01:19) I am sorry for a missunderstanding. I meant that we should take the current "GNOME control centre" - like design of the YaST control centre in SLES 10 SP 1 as a base for a redesign of the YaST control centre in our other products. Additionally to that, we should discuss (and perform) a reorganization of modules. #7: Federico Lucifredi (flucifredi) (2007-06-29 17:59:43) (reply to #5) This is worth pursuing, I am no UX expert, but if we can make it easier for users to find things, we should. A reorganization should be well thought-out, so that we break the existing habits *only once*, we should not be reshuffling things too often. #8: Siegfried Olschner (sdolschn) (2007-07-03 12:35:30) The results of the the cardsort study are available at: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study The subjects (N=~30) have been "Experts", so you can transfer the results to a new openSUSE YaST Control Center. The cluster trees with 2 different statistical options show only one difference: - ISDN, Modem, DSL, Network => Hardware - ISDN, Modem, DSL, Network => Network see http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study#Illustrative_M… I'm just writing a sumary. This section is placed at the top of the page. #9: Siegfried Olschner (sdolschn) (2007-07-03 12:39:23) I got only 2-3 NOT-Expert users in the sample. Their results are not presented on the page. But it's clear, they separated out cards like: VLM, iSCSI Initiator, Powertweak, VNC, Sudo, AppArmor, LDAP, etc., etc. #10: Siegfried Olschner (sdolschn) (2007-07-06 10:05:23) Some mockups available at: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study#Sorting_and_pr… #11: Martin Schmidkunz (mschmidkunz) (2007-11-29 13:50:55) Some additional mock ups and thoughs about that topic are available at: http://en.opensuse.org/YaST/Development/New_Control_Center #13: Martin Schmidkunz (mschmidkunz) (2008-02-11 15:24:24) One other suggestion was influenced by the KDE 4 control center: http://en.opensuse.org/YaST/Development/New_Control_Center/YaST_KDEstyle The main concerns with these mock ups are: * information overload * "search" is somehow meaningless if it isn't provided by some kind of thesaurus #15: Berthold Gunreben (azouhr) (2008-04-09 12:52:12) I don't know if this is just too late, but for me the only design that looks like a real step forward from all the designs on http://en.opensuse.org/YaST/Development/New_Control_Center/ is http://en.opensuse.org/YaST/Development/New_Control_Center/YaST_System_Navi… I really like this approach. Please don't just create huge lists of modules, or preselected lists of modules that never can meet the customers needs. #16: Duncan Mac-Vicar (dmacvicar) (2008-04-24 14:56:14) This feature was on impl. But limited resources and refocus on PackageKit froze development. Passing back to Stano. #17: Federico Lucifredi (flucifredi) (2008-06-13 19:49:56) lets figure out a plan and get it done this time :) #20: Martin Schmidkunz (mschmidkunz) (2007-09-29 03:17:48) As there is some negative feedback from the KDE 4 personal settings menu (https://bugzilla.novell.com/show_bug.cgi?id=431432) maybe we should take it into account when talking about a YaST control center redesign. BTW: what is the status on this feature request? #21: Thomas Göttlicher (tgoettlicher) (2008-10-23 17:03:56) (reply to #20) Thanks for this hint. Development on this featrue is postponed. #22: evamaria fuchs (nefuchs) (2009-01-22 17:49:48) Currently we are conducting usability tests, see: http://en.opensuse.org/YaST/Development/New_Control_Center#Usability_Tests #24: Karl Eichwalder (keichwa) (2009-05-08 07:37:16) For what's worth, things got worse in the meantime ;) This feature needs to be split into 2 or 3 subfeatures: * Improve labels (e.g., "/etc/sysconfig Editor" -> "Sysconfig Editor"). * Reorganize groups: Move items from "Other" to Miscellaneous, split Network Services into Network Servers and Network Clients, make the Apparmor entries one entry and move it to Security, make Virtualization entries one entry and move it to System, move Hostnames from Network Services to Network Devices and rename Network Devices to "Network Devices and Hostnames". * Improve the UI. The Gnome CC is rahter pointless because its left navigation (?) is just superfluous (ok, there is now "Common Tasks"...). Because YaST contains more groups and especially entries, we need a way to hide or collapse groups completely. (I do not like the KDE idea just to display a subset of the entries of a group.) BTW, the worst thing about yast's gtk ui is the idea of sorting groups alphabetically. In English, happily "Hardware" comes before "Miscellaneous"... #28: Bart Otten (bartotten) (2009-11-08 14:19:50) (reply to #24) +1 The AppArmor-group is annoying me for a long time. When it came into openSUSE I allready filed a bugreport (FATE was not openFATE yet). I think there are still some lessons in the card sort study. #25: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:24:54) the split between kcontrol and yast is confusing #26: Rémy Marquis (spyhawk) (2009-06-05 02:22:02) (reply to #25) This issue has already been discussed here : http://duncan.mac-vicar.com/blog/archives/452 #27: jimbo bigcreed (dimble_thricefoon) (2009-06-17 16:10:31) (reply to #26) cheers for the info. as long as they provide a non-confusing synthesis of the two related system management functions in a native QT4.5 environment i will be happy. #29: Atri Bhattacharya (badshah400) (2009-11-25 00:55:36) In my opinion, it would be nice to split up YaST's Control Centre into two tabs 1) Basic tasks: This tab should show a limited number of tasks (not modules) used frequently by a typical desktop user. The list might include things like: Set up a printer, Set up a TV card, Check for update, Install/uninstall software, Change system-wide network proxy, Configure date and Time, Add/remove user, manage network settings, view release notes, etc. Tasks might also be grouped into categories like hardware, etc. 2) Advanced view: This is a separate tab that shows all the modules categorised into groups. This is equivalent to the present control- centre view. By not presenting at first view a large number of icons with complicated names and advanced functionality (e.g. Kerberos client, AppArmor, Remote administration-VNC, etc.) the control-centre will prevent a typical desktop user from being overwhelmed, which happens with the present view. The task based list will also help in the sense that one generally thinks in terms of tasks when he/she starts up YaST to configure something. The advanced-view is also present (could use a check-box that says show advanced view by default in YaST for experienced people) for all other modules that might be necessary for specialised usage (like the kerberos client). The present YaST Control Centre is overwhelming for a typical desktop user. Reorganising it so that it shows a task-based list at first view will help regular users appreciate the power of YaST and also importantly its simplicity. It is imperative that we concentrate on the average Joe desktop user in streamlining the interface while keeping in mind its versatility and strengths for the experienced user as well. I believe a reorganisation of YaST's interface along these lines will achieve that. #30: Karl Eichwalder (keichwa) (2009-11-25 09:09:31) (reply to #29) The idea is quite good, but I'd avoid tabs. I'd add two additional additional groups ("Favorites" and "Basics") and list them at the top of the left pane. "Favorites" are meant to be populated by the user, just add two or three entries to make look it nice. "Basics" should contain 8 or 10 entries such as "Install/Remove Software", "Network Config", "Update Config", etc. As a third group you could add "Recent Modules"... After these two are three groups add a separator. #31: Atri Bhattacharya (badshah400) (2009-11-25 17:59:07) (reply to #30) >The idea is quite good, but I'd avoid tabs. Why? Tabs might help separate the gui into two distinct views: basic and advanced. Isn't that useful? However the Favourites and Basics groups you have mentioned also sound very interesting. My point in the above post was to have a view that lists tasks instead of modules, this in my opinion is important for useability. If the basics group as mentioned in your comment has tasks that would be great, the point being when we fire up YaST we are thinking "gotto change the proxy" or "have to add another user" or "have to set up my printer" as against when we are launching application-browser in Gnome for example where one is thinking "OK, let me start this image-editor". A task-based YaST would really help in my opinion, whether they are organised in a tab-based view or as groups as you mention (I actually like the group view more, but there should also be an advanced view which should be useful for the experienced users). #32: Karl Eichwalder (keichwa) (2009-11-26 08:23:43) (reply to #31) > Tabs might help separate the gui into two distinct views: basic and advanced. Maybe, it's useful. I think vertical space is precious. Screens are wide and wider, but often not that high. Really small screens are back with the NetBooks. And then, there is the ncurses YaST UI. I think most things are already task based up to some degree. There is not just one single module called "software management", but there are also other entry point to software managing such as managing repositories or doing online update. The same is valid for networking stuff. But it would be nice to add a search interface. The gtk incarnation comes with a filter option what is a start. + #33: Ladislav Horvath (6205) (2010-02-13 22:54:16) + YaST should IMO drop unnecessary module for which are there already + good GTK/QT alternatives and keep only andvanced modules for network or + servers or some specific HW -- openSUSE Feature: https://features.opensuse.org/302306

1 0

[openFATE 308814] Default repositories to not-autorefresh
by fate_noreply＠suse.de 12 Feb '10

12 Feb '10

Feature changed by: Stanley Miller (stan_qaz) Feature #308814, revision 3 Title: Default repositories to not-autorefresh openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Jimmy Berry (boombatower) Partner organization: openSUSE.org Description: Due to the extra load time required to refresh repositories on auto- fresh when opening the software manager or any other access to it, I go through all my repositories and disable auto-refresh. It would seem most users would be happier with a quicker load time, since keeping the repositories up-to-date should be done via automatic updates are manual refreshing. As an alternative, perhaps have a auto- refresh after x-days or somethign by default, but everytime it loads is a bit much and having to manually go through change them all is rather annoying. I am open to suggestions, but I feel this can be improved. Business case (Partner benefit): openSUSE.org: Make software management more responsive to users and faster to load, giving a better user experience. + Discussion: + #1: Stanley Miller (stan_qaz) (2010-02-12 20:35:32) + It would be good to figure out a way that you could start the program + managment module without the long delay you currently get but turning + off the refresh isn't something I'd be in favor of since I want the + option to select the latest version of anything available. The current + timeout is something like 10 minutes that make it a real pain to come + in and out several times when installing/updating stuff. + Coming up with a way to keep the repositories automatically updated, + possibly daily, would be good enough for me. Anything that could be + done to speed the refresh process would also be an improvement. -- openSUSE Feature: https://features.opensuse.org/308814

1 0

[openFATE 306990] pkgconfig automatic provides / requires
by fate_noreply＠suse.de 12 Feb '10

12 Feb '10

Feature added by: Andrew Jorgensen (ajorgensen) Feature #306990, revision 1 Title: pkgconfig automatic provides / requires openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Andrew Jorgensen (ajorgensen) Description: Integrate macros for automatically determining RPM provides / requires based on pkgconfig for -devel packages. This would consequently automatically determine the dependency chains between -devel packages that use pkgconfig. It would also allow packagers to use the pkgconfig(pkg) string instead of the specific -devel package name. This would make packaging easier both for cross-distro spec files and because when configure complains that a pkgconfig package is missing the packager can immediately add the BuildRequires rather than searching to determine which package contains that .pc file. Fedora and Mandriva both already have this feature. -- openSUSE Feature: https://features.opensuse.org/306990

1 5