September 2012 - openSUSE Features - openSUSE Mailing Lists

[openFATE 312568] YaST: add support for systemd service in runlevel editor
by fate_noreply＠suse.de 25 Sep '12

25 Sep '12

Feature changed by: Andreas Jaeger (a_jaeger) Feature #312568, revision 6 Title: YaST: add support for systemd service in runlevel editor - openSUSE Distribution: New + openSUSE Distribution: Evaluation by project manager Priority Requester: Important Requested by: Frederic Crozat (fcrozat) Partner organization: openSUSE.org Description: Yast runlevel editor should be able to detect if systemd is running and allow to enable/disable systemd service (which can shadow some sysvinit services). Relations: - systemd adaptation of YaST (novell/bugzilla/id: https://bugzilla.novell.com/show_bug.cgi?id=664548) https://bugzilla.novell.com/show_bug.cgi?id=https://bugzilla.novell.com/sho… Discussion: #2: Frederic Crozat (fcrozat) (2012-01-06 11:27:40) YaST support (probably adding a service) should talk to systemd using D- Bus API (like it is already done in systemd gtk gui), so it won't have to handle merge of configuration and so on. -- openSUSE Feature: https://features.opensuse.org/312568

1 0

[openFATE 305336] Ship man page for every executable
by fate_noreply＠suse.de 22 Sep '12

22 Sep '12

Feature changed by: Christopher Yeleighton (yecril71pl) Feature #305336, revision 68 Title: Ship man page for every executable openSUSE-11.2: Rejected by Andreas Jaeger (a_jaeger) reject date: 2009-08-11 15:41:47 reject reason: This is a task that should be done in cooperation with the upstream projects. Priority Requester: Mandatory openSUSE-11.4: Rejected by Matthias Eckermann (mge1512) reject date: 2011-03-26 09:25:38 reject reason: closing here, opening new Priority Requester: Important Requested by: Matthias Eckermann (mge1512) Partner organization: openSUSE.org 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. + #47: Christopher Yeleighton (yecril71pl) (2012-09-22 15:12:11) (reply + to #3) + openSUSE is based on GNU. GNU is not UNIX, so I fail to see how this is + relevant. #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.) #11: Praveen Kunjapur (stilo_vingyou) (2009-04-09 21:38:39) Knowledge is power. #13: Thorsten Kukuk (kukuk) (2009-08-17 22:17:33) We have a huge amount of orphaned packages, there is no chance to do any additional work on this feature. #21: Juergen Weigert (jnweiger) (2009-09-07 17:36:35) No. I cannot even estimate what the docimpact might be. Someone please collect a list of executables, and describe what kind of work is expected on them. Then we can make estimates. From the above comments #13 to #18 I cannot extract useful information. #22: Thorsten Kukuk (kukuk) (2009-09-10 09:53:11) It is still not clear to me what PM is expecting. For adding all the manual pages to every single RPM we don't have the resources, meanwhile the strategy and resource situation changed dramatically. And touching all RPMs would mean, that an online update is nearly impossible, customers have to download nearly every installed RPM. Else I can only repeat my comment #15 #34: Thomas Schraitle (thomas-schraitle) (2009-09-10 14:29:21) I don't think some issues in this entry are really covered yet -- apart from any future decision: 1) Writing manpages for all executables is illusionary. This task has to be and can only be handled by the corresponding upstream projects. Maybe you can convince the project maintainers to improve their documentation in this regard or support them with trainees or the like. But it's a longterm goal, not something done between two months. 2) Firefox is an executable. Does it need a manpage? I would say no, it has other documentation. What qualifies an executable to get a manpage? Where do you draw the line? 3) Writing a manpage is one thing, maintaining it is another. As experience shows, sometimes you have significant changes between one version and the other. Which should be covered in the manpage, of course. Again, this can not be done inhouse, it is a task which can only be written by the upstream projects accordingly. 4) As already written in comment #21, no list is/was collected. 5) As outlined, IHMO documentation departement is the wrong addressee. #35: Matthias Eckermann (mge1512) (2009-09-10 14:53:27) (reply to #34) >I don't think some issues in this entry are really covered yet -- apart from any future decision: Be sure that this has been discussed already in depth, e.g. by the PM Team within SUSE/Novell. > Writing manpages for all executables is illusionary. This task has to be and > can only be handled by the corresponding upstream projects. Man pages do exist for most binaries in the open source community, many also independendly of the respective projects. The Debian community has done a great job here, and it could be useful to join the forces of openSUSE community with Debian here. ... > Maybe you can convince the project maintainers to improve their documentation in > this regard or support them with trainees or the like. But it's a longterm goal, > not something done between two months. That's why the feature already exists for one year, ... > Firefox is an executable. Does it need a manpage? I would say no, > it has other documentation. What qualifies an executable to get > a manpage? Where do you draw the line? In the Enterprise world every binary needs a man page. Including Firefox and all Gnome and KDE applications. One reason for that: no administrator wants to have binaries around, where (s)he cannot say, what it is used for. This might also be a matter of "compliance". I agree however that this is different for openSUSE and the community. > Writing a manpage is one thing, maintaining it is another. > As experience shows, sometimes you have significant changes between > one version and the other. Which should be covered in the manpage, of course. > Again, this can not be done inhouse, it is a task which can only be written > by the upstream projects accordingly. Agreed. > As already written in comment #21, no list is/was collected. This is wrong. In the package "man-pages-supplement" a script exists, to list all binaries without a man-page already. Thus the analysis itself is not difficult. The doing is the challenge. Indeed. #37: Pavol Rusnak (prusnak) (2009-09-10 14:54:24) (reply to #34) 2. EVERY executable, the title of the feature says it all. Even if the manpage only contains "Firefox is a web browser" it is better than nothing. 4. Wrong, list is attached as external reference - http://en.opensuse.org/Manual_Pages/Missing (I collected it in February 2009, so it is a little bit outdated). 5. I don't think this could be done in one departement, because this is huge amount of work. We could start adopting already written manpages from Debian, but still a longterm issue. #38: Thomas Schraitle (thomas-schraitle) (2009-09-10 15:32:43) (reply to #37) > 4. Wrong, list is attached as external reference - http://en.opensuse.org/Manual_Pages/Missing (I collected it in February 2009, so it is a little bit outdated). Thanks Pavol, for the reminder. The list is one part and we know what's missing. That's good. However, what we don't know is the effort/amount of work to make it. It can be a very short one, or something that is really complicated and you need special knowledge. Maybe some could be autogenerated. -- openSUSE Feature: https://features.opensuse.org/305336

1 0

[New: openFATE 312892] Update boost to 1.47.0
by fate_noreply＠suse.de 21 Sep '12

21 Sep '12

Feature added by: Adam Mizerski (etamPL) Feature #312892, revision 1 Title: Update boost to 1.47.0 Package Wishlist: Unconfirmed Priority Requester: Desirable Requested by: Adam Mizerski (etampl) Partner organization: openSUSE.org Description: Boost 1.47.0 is out and it contains (apart from updates and fixes) new libraries (especially I'm interested in Geometry). http://www.boost.org/users/history/version_1_47_0.html -- openSUSE Feature: https://features.opensuse.org/312892

1 6

[New: openFATE 313539] Get rid of SuSEconfig.icu
by fate_noreply＠suse.de 20 Sep '12

20 Sep '12

Feature added by: Andreas Jaeger (a_jaeger) Feature #313539, revision 1 Title: Get rid of SuSEconfig.icu openSUSE Distribution: Evaluation by project manager Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Partner organization: openSUSE.org Description: There is no point to run that code after installation of every package (and it's not run when you use zypper or 3rd party tools anyways). That code should be only run as a part of post-install of the packages. -- openSUSE Feature: https://features.opensuse.org/313539

1 3

[openFATE 100011] Remove SuSEconfig
by fate_noreply＠suse.de 20 Sep '12

20 Sep '12

Feature changed by: Thorsten Kukuk (kukuk) Feature #100011, revision 23 Title: Remove SuSEconfig openSUSE-10.2: Rejected by Andreas Jaeger (a_jaeger) reject date: 2006-08-25 14:59:37 reject reason: We cannot remove all of it. We're currently looking at individual scripts and improve those. Priority Requester: Desirable openSUSE-10.3: Rejected by Andreas Jaeger (a_jaeger) reject date: 2006-09-20 17:15:47 reject reason: we cannot remove it completely for now. Thorsten filled requests for single scripts. Priority Requester: Desirable openSUSE Distribution: Evaluation by project manager Priority Requester: Mandatory SL-10.1: Rejected by Andreas Jaeger (a_jaeger) reject date: 2006-01-05 17:35:29 reject reason: not done for 10.1 Priority Requester: Neutral Requested by: Andreas Jaeger (a_jaeger) Partner organization: openSUSE.org Description: Let's remove all SuSEconfig scripts since only YaST calls SuSEconfig but other tools like rpm and zypper do not call it. If scripts are needed, they need to be invoked as part of the postinstall. Relations: - Forbid new SuSEconfig scripts in autobuild (feature/id: 300890) - Remove SuSEconfig dependency of syslog-ng (feature/id: 300891) - Get rid of SuSEconfig.news (feature/id: 300892) - Get rid of SuSEconfig.zmessages (feature/id: 300893) - Get rid of SuSEconfig.sortpasswd (feature/id: 300894) - Get rid of SuSEconfig.libxml2 (feature/id: 300946) - Get rid of SuSEconfig.pango (feature/id: 300947) - Get rid of SuSEconfig.scrollkeeper (feature/id: 300948) - Get rid of SuSEconfig.sgml-skel (feature/id: 300949) - Get rid of SuSEconfig.xpdf (feature/id: 300950) - Get rid of SuSEconfig.postfix (feature/id: 309055) - Get rid of SuSEconfig.gtk2 (feature/id: 309370) - Get rid of SuSEconfig.groff (feature/id: 311297) - Get rid of SuSEconfig.ispell (feature/id: 311298) - Get rid of SuSEconfig.words (feature/id: 311299) - Get rid of SuSEconfig.texlive (feature/id: 313535) - Get rid of SuSEconfig.fonts (feature/id: 313536) - Get rid of SuSEconfig.glib2 (feature/id: 313537) - Get rid of SuSEconfig.permissions (feature/id: 313538) - Get rid of SuSEconfig.icu (feature/id: 313539) - Get rid of SuSEconfig.mailman (feature/id: 313540) - Get rid of SuSEconfig.ghostscript-cjk (feature/id: 313541) - Get rid of SuSEconfig.isdn (feature/id: 313543) - Get rid of SuSEconfig.cjk-latex (feature/id: 313544) - Get rid of SuSEconfig.prelink (feature/id: 313545) - Get rid of SuSEconfig.scim (feature/id: 313546) - Get rid of SuSEconfig.scpm (feature/id: 313547) - Get rid of SuSEconfig.sendmail (feature/id: 313548) - Get rid of SuSEconfig.xjdic (feature/id: 313549) Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2005-12-02 00:35:48) Andreas, do you want to set some more concrete targets? + #2: Thorsten Kukuk (kukuk) (2012-09-20 15:26:24) + aaa_base and filesystem without SuSEconfig are submitted to Factory. + YaST2 developer will adjust YaST2. -- openSUSE Feature: https://features.opensuse.org/100011

1 0

[openFATE 306927] GLOM
by fate_noreply＠suse.de 18 Sep '12

18 Sep '12

Feature added by: Marcus Wild (Affrostralian) Feature #306927, revision 1 Title: GLOM Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Marcus Wild (affrostralian) Description: Database Frontend - easy to use GUI What you need, without the nonsense! With Glom you can design database systems - the database and the user interface. * Glom has high-level features such as relationships, lookups, related fields, related records, calculated fields, drop-down choices, searching, reports, users and groups. * Glom keeps things simple. It has Numeric, Text, Date, Time, Boolean, and Image field types. * Glom systems require almost no programming, but you may use Python for calculated fields or buttons. * Each Glom system can be translated for multiple languages and countries. -- openSUSE Feature: https://features.opensuse.org/306927

1 1

[New: openFATE 313434] yast simplification
by fate_noreply＠suse.de 13 Sep '12

13 Sep '12

Feature added by: Alexandre Bonhomme (abonhomm) Feature #313434, revision 1 Title: yast simplification openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Alexandre Bonhomme (abonhomm) Partner organization: openSUSE.org Description: Make yast more user friendly : sort aller features (incl. Kde config tool with only one structure and place : merge apper zypper and yast). Se drakeconf as an inspiration source. -- openSUSE Feature: https://features.opensuse.org/313434

1 1

[New: openFATE 313151] opensuse 12.2: kde update conflicts - there needs to be only one!
by fate_noreply＠suse.de 13 Sep '12

13 Sep '12

Feature added by: Jedi Beeftrix (Jedibeeftrix) Feature #313151, revision 1 Title: opensuse 12.2: kde update conflicts - there needs to be only one! openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Jedi Beeftrix (jedibeeftrix) Partner organization: openSUSE.org Description: not a technical person so only a limited ability to explain this, but here goes: back in the day we used YAST, it found updates and installed them, all was good in the world. then we needed desktop notifiers to inform the user that new updates were available, and all was good in the world. then we decided that the notifier ought to be able to install updates, and two parallel systems were born, and was conflict brought into the world. then we had kpackagekit which promised to return the user to the blessed lands of all, but the dream was not realised. then apper arrived promising to correct the flaws of kpackagekit, but still we get conflicts were one service is blocked by the (invisible) operation of the other. ---------------------------- We need a simpler system: http://lists.opensuse.org/opensuse-kde/2012-01/msg00144.html for 12.2, can we make apper call YAST to install updates, or YAST use packagekit as the 'backend', but not have two parallel systems of updates that invariably tie themselves in knots? kind regards JBT -- openSUSE Feature: https://features.opensuse.org/313151

1 8

[New: openFATE 313307] Create SUSE OS Tablet Product
by fate_noreply＠suse.de 13 Sep '12

13 Sep '12

Feature added by: Scott Couston (zczc2311) Feature #313307, revision 1 Title: Create SUSE OS Tablet Product openFATE: Unconfirmed Priority Requester: Mandatory Requested by: Scott Couston (zczc2311) Partner organization: openSUSE.org Description: With IT trends moving so quickly, Sales for IPAD-II and IPAD-III already outsell ALL PC based Hardware across the world and a the new phrase of "Post PC era" is now a common place reality. As of the 8th of March 2010, the IPAD-III is due for release in .AU in two weeks and current interest/sales figures are extraordinary. .AU always gets the first release of new hardware to test the market before release in .US/UK etc. Testing the .AU Market place first and foremost has been the same for Microsoft/Apple and countless O/S as the market is small enough and has a large number of hi tech users, isues a fixed before world release - Nothing new about that its been happening for 25 years - The IPAD-II will remain for sale. Apple has no current reason to terminate the IPAD-II as functionally the IPAD-III offers much the same functionality but with massively increased GPU/CPU processing ability and extraordinary screen rez which is well above a standard HD TV.The camera has increased number of Pixels and talk to text ability like we have never seen before - Its uncannily accurate in speak to text interface - Speak to text has now come of age. We need to do two things for our very survival as Tablet sales/users are now far greater than any PC group, Hardware and O/S irrelevant. First create the Product Suse Linux for Tablets as an O/S! Secondly start immediately to create SUSE Linux O/S for Tablets no matter who manufactures them. Not merely application, but a whole O/S and apps - otherwise and based on sales per unit; the PC as we know it wont exist only tablets and IBM Z/Series Business case (Partner benefit): openSUSE.org: ......for our very survival and because we can do this relatively easily -- openSUSE Feature: https://features.opensuse.org/313307

1 1

[openFATE 305474] provide reliable suspend-on-lid-close
by fate_noreply＠suse.de 10 Sep '12

10 Sep '12

Feature changed by: Michal Marek (michal-m) Feature #305474, revision 16 Title: provide reliable suspend-on-lid-close openSUSE-11.2: Rejected by Andreas Jaeger (a_jaeger) reject date: 2010-11-15 10:50:03 reject reason: Not done in time for openSUSE 11.2 Priority Requester: Desirable Projectmanager: Desirable - openSUSE-11.4: New + openSUSE-11.4: Rejected by Michal Marek (michal-m) + reject reason: Please file bugs in bugzilla Priority Requester: Desirable Requested by: Juergen Weigert (jnweiger) Partner organization: openSUSE.org Description: I suggest to have a configuration option cause a suspend on lid-close regardless of other circumstances. Currently * presence of AC-power, * the selected desktop KDE/Gnome/Text, and * presence of docking station all have influence on suspend. The exact logic is apparently changing between beta versions. I'd like to be able to configure a general and unconditional suspend on- lid-close function. Discussion: #1: Axel Braun (docb) (2009-04-27 13:06:57) Good idea! That would allow a laptop to close even if you are on the login-screen. #2: Martin Seidler (pistazienfresser) (2010-04-26 13:52:45) Only suspend to RAM (sleep)? Could suspend to disk cause problems (especially with dual boot systems)? #3: Juergen Weigert (jnweiger) (2010-11-15 15:49:21) situation is unchanged, reject is not helpful. Promoting to 11.4 + #4: Michal Marek (michal-m) (2012-09-10 15:11:04) + gnome-power-manager does suspend if you are on AC power and close the + lid. Not sure about docking station. I guess you are using KDE, which + IIRC has less user friendly default. So please file a bug against the + part of KDE that takes care of power management. -- openSUSE Feature: https://features.opensuse.org/305474

1 0