April 2016 - openSUSE Features - openSUSE Mailing Lists

[openFATE 307884] Yafaray instead of Yafray for Blender
by fate_noreply＠suse.de 07 Jun '16

07 Jun '16

Feature added by: Rene Bernhard (rebe) Feature #307884, revision 1 Title: Yafaray instead of Yafray for Blender Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Rene Bernhard (rebe) Description: Hello. As the Yafray render engine for Blender is not longer developed I apreciate if you would replace it with the Yafaray render engine in one of the next openSUSE versions. Or maybe it is possible to make a package for the repositories to download. Thank you very much for your efforts. Best regards rebe -- openSUSE Feature: https://features.opensuse.org/307884

1 4

[New: openFATE 312491] Explicit IPv6 support for YaST printer module
by fate_noreply＠suse.de 11 May '16

11 May '16

Feature added by: Johannes Meixner (jsmeix) Feature #312491, revision 1 Title: Explicit IPv6 support for YaST printer module openSUSE Distribution: Unconfirmed Priority Requester: Mandatory Requested by: Johannes Meixner (jsmeix) Partner organization: openSUSE.org Description: Currently there is not any kind of special IPv6 support in yast2-printer. Currently IPv6 works only where it is compatible to IPv4 but there are cases where IPv6 needs special handling: For example the tests whether or not a remote host is accessible run "ping <IP-address or hostname>" which fails if IP-address is an IPv6 address because for IPv6 ping6 must be used. See https://bugzilla.novell.com/show_bug.cgi?id=697833 Unfortunately ping6 cannot be used for IPv4 addresses so that yast2-printer needs to implement special distinction of cases in particular if a hostname is given depending on whether or not this hostname has an IPv4 or IPv6 address or both. Probably there are some more special distinction of cases needed to distinguish between IPv4 and IPv6 stuff. -- openSUSE Feature: https://features.opensuse.org/312491

1 20

[New: openFATE 314657] Add setting to not create Failsafe entries in grub menu
by fate_noreply＠suse.de 18 Apr '16

18 Apr '16

Feature added by: Michal Marek (michal-m) Feature #314657, revision 1 Title: Add setting to not create Failsafe entries in grub menu openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Michal Marek (michal-m) Partner organization: openSUSE.org Description: When testing multiple kernels, the grub menu quickly becomes a mess, because every kernel is listed twice. I would love to have a setting in /etc/sysconfig/bootloader, that would allow to tell perl-Bootloader to stop generating the Failsafe entries. -- openSUSE Feature: https://features.opensuse.org/314657

1 1

[New: openFATE 320744] requests should have titles
by fate_noreply＠suse.de 08 Apr '16

08 Apr '16

Feature added by: Adam Spiers (aspiers) Feature #320744, revision 1 Title: requests should have titles Buildservice: Unconfirmed Priority Requester: Important Requested by: Adam Spiers (aspiers) Partner organization: openSUSE.org Description: Currently requests are only referred to by number. Probably by now everyone is used to this, but imagine how much less convenient it would be if github pull requests did not have titles; that thought experiment should make it clear how much OBS requests could benefit from titles. Use Case: As a developer, I receive a bunch of submitreqs to my email inbox and want to be able to quickly get a sense of what each one is about, without having to read a diff. Business case (Partner benefit): openSUSE.org: I really hope this is very obvious. Humans are not machines, so we don't remember everything using 6-digit numbers. -- openSUSE Feature: https://features.opensuse.org/320744

1 3

[New: openFATE 308839] performance: prompt early on failure ...
by fate_noreply＠suse.de 05 Apr '16

05 Apr '16

Feature added by: Michael Meeks (michael_meeks) Feature #308839, revision 1 Title: performance: prompt early on failure ... Buildservice: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: For local builds, osc has an unfortunate habit of doing a large amount of work, before failing very late. For slow building or leaf packages this can be excessively painful - wasting an "overnight" build slot eg. Many of the checks that we currently do in the middle, should be moved to the beginning (or perhaps just duplicated there). Some examples I have fallen over: * prompt-user-to-re-build-jail - this currently happens after any new packages are downloaded - a process that can take as long as the building. We can know that a jail was dirty before we start & warn then; if we even need dirty jails [cf. fate#308837# ] * simple RPM syntax problems - could be linted ahead of time, currently done after jail construction. + we should catch in particular: missing / mis-named files + mis-applied / not-applied patches + anything else obvious that we can catch Doing this early - while the human is watching is likely to hide long pipeline stalls, and context switching overhead for packagers. -- openSUSE Feature: https://features.opensuse.org/308839

1 3

[New: openFATE 313077] New PAM modules must not be deployed unnoticed by sec team
by fate_noreply＠suse.de 05 Apr '16

05 Apr '16

Feature added by: Sebastian Krahmer (krahmer) Feature #313077, revision 1 Title: New PAM modules must not be deployed unnoticed by sec team openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Sebastian Krahmer (krahmer) Partner organization: openSUSE.org Description: New PAM modules should be reviewed by security team. Just like any suid/daemon/DBUS service. In particular if they are installed by default. -- openSUSE Feature: https://features.opensuse.org/313077

1 4

[New: openFATE 311163] packaging firefox add-ons
by fate_noreply＠suse.de 05 Apr '16

05 Apr '16

Feature added by: Ludwig Nussel (lnussel) Feature #311163, revision 1 Title: packaging firefox add-ons Hackweek VI: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: We lack a way to be able to easily package firefox add-ons as rpm. Packages of add-ons are useful both for the distro vendor and for admins. Distro (or appliance) vendors may install some add-ons by default. Admins want all users to have certain add-ons by default. Moreover some add-ons are not noarch (like bonjourfoxy) and need to be compiled specifically for each distro so a package is unavoidable. To make all of that possible the firefox package needs to provide rpm macros so spec files for add-ons become really simple. By creating a script that downloads version, description etc from addons.mozilla.org and automatically creates spec files the task of packaging add-ons becomes a piece of cake. See home:lnussel:firefox for current status. -- openSUSE Feature: https://features.opensuse.org/311163

1 6

[New: openFATE 320729] Automatic shell syntax highlighting for PKGBUILDs
by fate_noreply＠suse.de 03 Apr '16

03 Apr '16

Feature added by: Brenton Horne (fusion809) Feature #320729, revision 1 Title: Automatic shell syntax highlighting for PKGBUILDs Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Brenton Horne (fusion809) Partner organization: openSUSE.org Description: I would like to request that the text editor of the OBS (i.e., the one used to edit spec, PKGBUILDs, etc.) automatically recognize PKGBUILD files (i.e., files with the exact name "PKGBUILD") and apply shell syntax highlighting to them, as they are shell scripts. -- openSUSE Feature: https://features.opensuse.org/320729

1 0

[openFATE 305336] Ship man page for every executable
by fate_noreply＠suse.de 01 Apr '16

01 Apr '16

Feature changed by: иван иванов (cpon) Feature #305336, revision 73 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 Priority Requester: Important Requested by: Matthias Eckermann (mge1512) Engineering Manager: Juergen Weigert (jnweiger) 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. + Business case (Partner benefit): + openSUSE.org: webkit-app-region: no-drag;-webkit-appearance: none;- + webkit-background-composite: source-over;-webkit-border-horizontal- + spacing: 0px;-webkit-border-vertical-spacing: 0px;-webkit-box-align: + stretch;-webkit-box-decoration-break: slice;-webkit-box-direction: + normal;-webkit-box-flex: 0;-webkit-box-flex-group: 1;-webkit-box-lines: + single;-webkit-box-ordinal-group:1;-webkit-box-orient:horizontal;- + webkit-box-pack: start;-webkit-box-reflect: none;-webkit-column-break- + after: auto;-webkit-column-break-before: auto;-webkit-column-break- + inside: auto;-webkit-column-count:auto;-webkit-column-gap:normal;- + webkit-column-rule-color:rgb(0, 0, 0);-webkit-column-rule-style:none;- + webkit-column-rule-width:0px;-webkit-column-span: none;-webkit-column- + width:auto;-webkit-font-smoothing:auto;-webkit-highlight: none;-webkit- + hyphenate-character: auto;-webkit-line-box-contain:block inline + replaced;-webkit-line-break: auto;-webkit-line-clamp: none;-webkit- + locale: 'ru';-webkit-margin-after-collapse: collapse;-webkit-margin- + before-collapse: collapse;-webkit-mask-box-image:none;-webkit-mask-box- + image-outset: 0px;-webkit-mask-box-image-repeat: stretch;-webkit-mask- + box-image-slice: 0 fill;-webkit-mask-box-image-source: none;-webkit- + mask-box-image-width: auto;-webkit-mask-clip: border-box;-webkit-mask- + composite:source-over;-webkit-mask-image: none;-webkit-mask-origin: + border-box;-webkit-mask-position: 0% 0%;-webkit-mask-repeat:repeat;- + webkit-mask-size: auto;-webkit-print-color-adjust: economy;-webkit-rtl- + ordering:logical;-webkit-tap-highlight-color: rgba(0, 0, 0, 0.180392);- + webkit-text-combine:none;-webkit-text-decorations-in-effect: none;- + webkit-text-emphasis-color: rgb(0, 0, 0);-webkit-text-emphasis- + position: over;-webkit-text-emphasis-style: none;-webkit-text-fill- + color:rgb(0, 0, 0);-webkit-text-orientation:vertical-right;-webkit-text- + security:none;-webkit-text-stroke-color:rgb(0, 0, 0);-webkit-text- + stroke-width:0px;-webkit-user-drag: auto;-webkit-user-modify: read-only; + -webkit-user-select: text;align-content: start;align-items: start;align- + self: start;alignment-baseline: auto;animation-delay: 0s;animation- + direction:normal;animation-duration: 0s;animation-fill-mode: none; + animation-iteration-count:1;animation-name: none;animation-play-state: + running;animation-timing-function:ease;backface-visibility:visible; + background-attachment:scroll;background-blend-mode:normal;background- + clip: border-box;background-color: rgba(0, 0, 0, 0);background-image: + none;background-origin:padding-box;background-position: 0% 0%; + background-repeat: repeat;background-size: auto;baseline-shift: 0px; + border-bottom-color: rgb(0, 0, 0);border-bottom-left-radius:0px;border- + bottom-right-radius: 0px;border-bottom-style: none;border-bottom-width: + 0px;border-collapse: separate;-webkit-border-image:none;border-image- + outset: 0px;border-image-repeat:stretch;border-image-slice: 100%;border- + image-source: none;border-image-width: 1;border-left-color: rgb(0, 0, + 0);border-left-style: none;border-left-width: 0px;border-right-color: + rgb(0, 0, 0);border-right-style: none;border-right-width: 0px;border- + top-color: rgb(204, 204, 204);border-top-left-radius:0px;border-top- + right-radius:0px;border-top-style: solid;border-top-width: 1px;bottom: + auto;box-shadow: none;box-sizing: content-box;buffered-rendering: auto; + caption-side: top;clear: none;clip: auto;clip-path: none;clip-rule: + nonzero;color: rgb(0, 0, 0);color-interpolation: sRGB;color- + interpolation-filters: linearRGB;color-rendering: auto;cursor: default; + cx: 0px;cy: 0px;direction: ltr;display: table-cell;dominant-baseline: + auto;empty-cells: show;fill: rgb(0, 0, 0);fill-opacity: 1;fill-rule: + nonzero;filter: none;flex-basis: auto;flex-direction: row;flex-grow: 0; + flex-shrink: 1;flex-wrap: nowrap;float: none;flood-color: rgb(0, 0, 0); + flood-opacity: 1;font-family: 'Droid Sans', 'Lucida Grande', Arial, + 'DejaVu Sans', Verdana, sans-serif;font-kerning: auto;font-size: + 12.8000001907349px;font-stretch: normal;font-style: normal;font- + variant: normal;font-variant-ligatures:normal;font-weight: normal;glyph- + orientation-horizontal: 0deg;glyph-orientation-vertical: auto;height: + 26px;image-rendering: auto;isolation: auto;justify-content: start;left: + auto;letter-spacing: normal;lighting-color: rgb(255, 255, 255);line- + height:19.2000007629395px;list-style-image: none;list-style-position: + outside;list-style-type: disc;margin-bottom: 0px;margin-left: 0px; + margin-right: 0px;margin-top: 0px;marker-end: none;marker-mid: none; + marker-start: none;mask: none;mask-type: luminance;max-height: none;max- + width: none;min-height: 0px;min-width: 0px;mix-blend-mode: normal; + object-fit: fill;object-position: 50% 50%;opacity: 1;order: 0;orphans: + auto;outline-color: rgb(0, 0, 0);outline-offset: 0px;outline-style: + none;outline-width: 0px;overflow-wrap: normal;overflow-x: visible; + overflow-y: visible;padding-bottom: 0px;padding-left: 0px;padding- + right: 0px;padding-top: 1px;page-break-after: auto;page-break-before: + auto;page-break-inside: auto;paint-order: fill stroke markers; + perspective: none;perspective-origin:300.5px 14px;pointer-events: auto; + position: static;r: 0px;resize: none;right: auto;rx: 0px;ry: 0px;shape- + image-threshold: 0;shape-margin: 0px;shape-outside: none;shape- + rendering: auto;speak: normal;stop-color: rgb(0, 0, 0);stop-opacity: 1; + stroke: none;stroke-dasharray: none;stroke-dashoffset: 0px;stroke- + linecap: butt;stroke-linejoin: miter;stroke-miterlimit: 4;stroke- + opacity: 1;stroke-width: 1px;tab-size: 8;table-layout: auto;text-align: + left;text-anchor: start;text-decoration: none;text-indent: 0px;text- + overflow: clip;text-rendering: auto;text-shadow: none;text-transform: + none;top: auto;touch-action: auto;transform: none;transform-origin: + 300.5px 14px;transform-style: flat;transition-delay: 0s;transition- + duration: 0s;transition-property: all;transition-timing-function: ease; + unicode-bidi: normal;vector-effect: none;vertical-align: top; + visibility: visible;white-space: nowrap;widows: 1;width: 601px;will- + change: auto;word-break: normal;word-spacing: 0px;word-wrap: normal; + writing-mode: lr-tb;-webkit-writing-mode:horizontal-tb;x: 0px;y: 0px;z- + index: auto;zoom: 1; 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. #48: Ruediger Meier (rudi_m) (2013-08-02 02:41:24) IMO more important is that every binary (every executable thing - not only the ones in $PATH!) should understand --help ... not only -h or -H or -help or even worse nothing ... BTW you can never be sure that a man page somewhere in $MANPATH really describes what you would get when executing a binary from $PATH. Since most man pages are generated by help2man anyway we should focus on nice, reliable --help for everything. At least --help should give an error if not supported rather than just doing something odd. #49: Matthias Eckermann (mge1512) (2013-08-02 02:59:28) (reply to #48) While I agree that a consistent behaviour is highly desirable, it is hard to achieve given the different "worlds" (BSD style, GNU style, ...) the tools on Linux come from. Convincing the different communities can become challeging. And then there are some tools not taking any cmdline option, as they only work with pipes, ... Nevertheless, the idea is worth thinking about, and if you want to pursue it, I suggest you open a new feature request and start a discussion on opensuse-factory. -- openSUSE Feature: https://features.opensuse.org/305336

1 0