January 2010 - openSUSE Features - openSUSE Mailing Lists

[openFATE 308798] osc pull - fetch changes from an another branch
by fate_noreply＠suse.de 21 Jan '10

21 Jan '10

Feature changed by: Adrian Schröter (adrianSuSE) Feature #308798, revision 3 Title: osc pull - fetch changes from an another branch - Buildservice: New + Buildservice: Evaluation Priority Requester: Desirable + Projectmanager: Desirable Requested by: Michal Vyskocil (mvyskocil) + Developer: Marcus Hüwe (marcus_h) Description: osc pull can be used for merging changes when the original developer did not send a submitrequest and a maintainer want to have his changes. The current existing approach is not easy - export a diff with his changes, apply them and commit - and it also break his branch. osc pull would do the same including repair of the origin package. Eg. Someone will update pidgin to new version, so home:branches:foo: GNOME:Factory/pidgin contains _link new_pidgin.tarball project.diff maintainer of pidgin calls osc pull home:branches:foo:GNOME: Factory/pidgin and the changes will be merged to the GNOME: Factory/pidgin and his branch will contain a _link. + Discussion: + #1: Adrian Schröter (adriansuse) (2010-01-21 12:40:05) + it is indeed desirable, but not that easy to implement. + Even though there is already an "osc pull", but this one only merge + from the branch tree so far. -- openSUSE Feature: https://features.opensuse.org/308798

1 0

[openFATE 308133] Easy way to add information about a repository to be shown during its activation
by fate_noreply＠suse.de 21 Jan '10

21 Jan '10

Feature added by: Lubos Lunak (llunak) Feature #308133, revision 1 Title: Easy way to add information about a repository to be shown during its activation Buildservice: New Priority Requester: Desirable Requested by: Lubos Lunak (llunak) Description: Currently there doesn't seem to be a simple way to give information to use users who add a repository. For example, users adding the KDE:KDE4:Factory:Desktop repository should know that the KDE provided there a working version for the next openSUSE release and it may not be as stable as they might expect (they can just read about the repository e.g. in a forum and not know more). One way to do this could be to reuse the licence dialog, showing information about the repository instead of a licence, but there appears to be no simple way to do this (it reportedly requires creating a ftp product somehow, for which I could find any usable instructions). -- openSUSE Feature: https://features.opensuse.org/308133

1 1

[openFATE 308494] Obsolete suseRegister for openSUSE
by fate_noreply＠suse.de 21 Jan '10

21 Jan '10

Feature changed by: Michael Löffler (michl19) Feature #308494, revision 3 Title: Obsolete suseRegister for openSUSE openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Description: AFAIK we do not need registration at all anymore for openSUSE, let's obsolete it's usage and tools. + Discussion: + #1: Michael Löffler (michl19) (2010-01-21 12:34:30) + I made the feature public so Stefan Werden who's producing the retail + box can check if he needs suseRegister or not. But at first glance I + don't see use of suseRegister for openSUSE. -- openSUSE Feature: https://features.opensuse.org/308494

1 0

[openFATE 306529] Deactivate build if home:user:branch:foo is inactive for 1 or 2 weeks
by fate_noreply＠suse.de 21 Jan '10

21 Jan '10

Feature added by: Jan-Simon Möller (dl9pf) Feature #306529, revision 1 Title: Deactivate build if home:user:branch:foo is inactive for 1 or 2 weeks Buildservice: Unconfirmed Priority Requester: Important Requested by: Jan-Simon Möller (dl9pf) Description: It would save quite some cpu-cycles if branches which are not in active use - e.g. no change in 1 or 2 weeks - would just get the build disabled. Thus the wave during each factory checkin wouldn't be that high. Or even delete branches if they're inactive for 1 or 2 weeks and only the pristine _link is there. This could be extended to disable the build for factory repos in user's home-dir if there're no checkin's for some time. I don't want to prevent ppl from tracking factory in their home: , but a plain _link is just pointless and build should be disabled automagically after some time. -- openSUSE Feature: https://features.opensuse.org/306529

1 3

[openFATE 306426] Add Package Wishlist
by fate_noreply＠suse.de 21 Jan '10

21 Jan '10

Feature added by: Klaas Freitag (kfreitag) Feature #306426, revision 1, last change by Title: Add Package Wishlist Buildservice: Unconfirmed Priority Requester: Important Requested by: Klaas Freitag (kfreitag) Description: In the Buildservice, the package wishlist should be accessible. That would make it easy to pick packages and build it if bored. -- openSUSE Feature: https://features.opensuse.org/306426

1 5

[New: openFATE 308843] rcs: project-wide diffing ...
by fate_noreply＠suse.de 21 Jan '10

21 Jan '10

Feature added by: Michael Meeks (michael_meeks) Feature #308843, revision 1 Title: rcs: project-wide diffing ... Buildservice: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Partner organization: openSUSE.org Description: Often, it is the case (with many people working inside a project), that we go from a working state, to a broken state. However - it is not known what exactly changed. With staff in different timezones, intermittently available etc. it is simply not possible to ask them all - and latency is a killer. At the present time, it is simply not possible to easily answer the question "what changed between Then and Now". We loose revision history all over the place - if it is even recorded: (it is not for prjconf eg.). But being able to do a "full project" diff of even what we have is highly non-easy: and would typically be some excessive shell command [ which is unlikely to tell you if packages have appeared or disappeared etc. ]. Having an easy way to do this sort of diff would be rather helpful. Preferably achieved by putting each project in a git repository :-) Business case (Partner benefit): openSUSE.org: We can't reliably tell what changed. -- openSUSE Feature: https://features.opensuse.org/308843

1 1

[New: openFATE 308845] performance: off-line building
by fate_noreply＠suse.de 21 Jan '10

21 Jan '10

Feature added by: Michael Meeks (michael_meeks) Feature #308845, revision 1 Title: performance: off-line building Buildservice: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: The ability to build off-line is rather useful, when travelling, and (of course) when the servers are not playing nicely. -- openSUSE Feature: https://features.opensuse.org/308845

1 4

[New: openFATE 308851] reliability
by fate_noreply＠suse.de 21 Jan '10

21 Jan '10

Feature added by: Michael Meeks (michael_meeks) Feature #308851, revision 1 Title: reliability Buildservice: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: The build service is frequently inoperable, and / or suffers from transient errors. We seem to have a very weak versioning scheme, and/or separation between development and stable versions. Checkout has corrupts files on (aborted / failed) checkout: https://bugzilla.novell.com/show_bug.cgi?id=503365 https://bugzilla.novell.com/show_bug.cgi?id=516168 and likes to fail: https://bugzilla.novell.com/show_bug.cgi?id=519227 "Failed to reach a server: [Errno 8] _ssl.c:482: EOF occurred in violation of protocol" - perhaps a fails-to-work-with-proxies problem: https://bugzilla.novell.com/show_bug.cgi?id=521334 is this now fixed ? https://bugzilla.novell.com/show_bug.cgi?id=554509 The Web UI routinely fails to work, with different sets of errors: https://bugzilla.novell.com/show_bug.cgi?id=539313 https://bugzilla.novell.com/show_bug.cgi?id=542526 Sometimes it stops working, and starts again with (apparently) no change between times: https://bugzilla.novell.com/show_bug.cgi?id=544654 If we do get errors, the explanation is often not helpful: https://bugzilla.novell.com/show_bug.cgi?id=483382 -- openSUSE Feature: https://features.opensuse.org/308851

1 1

[openFATE 306404] Provide access to manuals
by fate_noreply＠suse.de 20 Jan '10

20 Jan '10

Feature changed by: Stefan Behlert (sbehlert) Feature #306404, revision 36 Title: Provide access to manuals - openSUSE-11.2: Rejected by (michl19) + openSUSE-11.2: Rejected by Gary Ekker (michl19) reject date: 2009-12-10 16:21:53 reject reason: 11.2 is past Priority Requester: Important openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Frank Sundermeyer (fsundermeyer) Description: In openSUSE 11.1 it is almost impossible for a regular user to access the official manuals. By default, only the complete set of HTML manuals is installed, while the PDFs are not installed by default. There is no way of easily locating the packages containing them unless you know the package names. In order to improve this * the term "manual" has to appear in the package name or at least in the summary of the package * a Pattern "Manuals" is needed Theoretically the HTML manuals should be accessible via the KDE or GNOME help center. In the past the help centers have made lots of trouble when integrating the manuals, so they almost always were either not available in KDE or GNOME. Since the release of KDE4, for example, they can no longer be integrated into the KDE help center. Apart from that, the help center has certain disadvantages: * no proper search within the manuals * too many clicks are needed to access a manual * not printable * users of other GUIs have no easy access to the manuals (via the filesystem only) Therefore the PDFs have to be installed by default, too. Additionally an entry "Manuals" with links to the PDFs has to be added to the main menus of the GUIs (KDE, GNOME, XFCE,...). Furthermore, the manuals are not accessible directly from the media (the start-up guide being the sole exception), so one can only use them after having installed the system. Therefore providing Installation an Quickstart Guide is kind of absurd. I propose to host the PDFs under /docu in all repositories and create "empty" RPM packages just copying the PDFs from there. Documentation Impact: Evaluate if RPMs can postinstall the unpacked PDFs from the install- Media Discussion: #1: Michael Löffler (michl19) (2009-06-05 16:15:21) Having the manuals accessible in the Help Center is sufficient, adding pdfs imo just nice to have. #2: Frank Sundermeyer (fsundermeyer) (2009-12-01 16:39:11) (reply to #1) As I pointed out in the initial description: Since the release of KDE4 the manuals are no longer available from the KDE help center. #3: Juergen Weigert (jnweiger) (2009-12-01 17:26:58) This request comes from doc-team and doc-team will implement it. The request is only here to synchronize efforts. I see the following defects: - we obsolete old docu packages with opensuse-manuals_en, but do not require the set of new packages. So nothing is currently installed. - user has to guess package names and activly hunt for the packages. do we have a reason for not installing docs? Disc space should not be a limitation. - installation manual should also be unpacked in the root directory of the install medium. RPM package for the installed system also has a copy of this. Look into a more clever RPM package. - create appropriate mene entries. (desktop files?) - place a doc-icon on the plasma desktop (decide if we have PDF or HTML there?) - integrate searchable docs in the startup menue search engine. I see no reasons for not doing any of the above. PM, please advise. #4: Karl Eichwalder (keichwa) (2009-12-02 08:04:28) HTML in KDE4: According to https://bugzilla.novell.com/show_bug.cgi?id=391185 it finally worked on 11.1 (maybe, there is still a confusion with KDE3 and KDE4). A KDE expert must check this please and tell us how the desktop files must look alike and where we should install them. Installing PDF by default: Sometime ago we were told that we should not clutter the user's disk with install two falors of our manuals and that HTML would be the better choice. In earlier times the PDFs used to be unpackaged on the media, though. Aside: I'd rather prefer Info files (and PDFs), but that's a different story. Invisibility of the docs: There is quite some noise about the books in the wiki (and on novell.com/documentation) If you ask google about "opensuse documentation" or "docs", en.opensuse.org/Documentation is the first hit. It looks a little bit different, if you use "manuals" instead of "Documentation", but still fine. Label or Summary of the package description: I just stick with the book title (modulo bugs). Everything else will lead to confusion. These days, package metadata are either kept in BS config files or in our special attributes" files. I would be fine with me, if some human being or an automatic make command would maintain the attributes file. #7: Juergen Weigert (jnweiger) (2009-12-03 19:24:29) (reply to #5) I added SP1 - I know this is a late feature, and I should file such requests. Sorry. Let us please have some improvement to the current situation in SP1. Minimum effort for SP1 is adding appropriate desktop files. Do we have approval here? #6: Karl Eichwalder (keichwa) (2009-12-03 14:13:31) This is a related feature: fate#306322 Accessing PDFs from within the help centers #10: Juergen Weigert (jnweiger) (2009-12-04 15:24:27) Karl, Stefan pointed me to /work/SRC/all/sled-gnome-cbt_en/ *.spec cbt. desktop implements an icon on the GNOME desktop. Is this helpful? Are *. desktop files menat to be KDE or GNOME specific... ? :-( #13: Karl Eichwalder (keichwa) (2009-12-07 10:18:31) (reply to #10) Putting Icons an the desktop is something different. .desktop files are general (see freedesktop.org) but vendor enhancements are possible. Maybe, we should split theis feature. ATM, I do not understand what we want to achieve. On the GNOME desktop (SLED 11 SP1a2), if you click "Computer" > "Help", "SLED Documentation (en)" is listed. If you click on it, the HTML flavor of our docs is shown. You can see something similar on openSUSE. This, at least, is a start. Not sure, what needs to be done on KDE, though. #11: Jan Engelhardt (jengelh) (2009-12-05 13:50:14) This looks solved to me -- openSUSE 11.2 installs openSUSE-manual_en- pdf by default, even for a Minimal install chosen in yast. #12: Karl Eichwalder (keichwa) (2009-12-07 09:50:36) (reply to #11) openSUSE-manual_en-pdf is just a meta package. #14: Barry Nichols (barry_nichols) (2009-12-07 12:48:39) I consider myself to be a regular user and I found the manual pdfs easily enough. -- openSUSE Feature: https://features.opensuse.org/306404

1 0

[New: openFATE 308858] Update IEEE1994 to JuJu interface
by fate_noreply＠suse.de 20 Jan '10

20 Jan '10

Feature added by: Roger Oberholtzer (rogeroberholtzer) Feature #308858, revision 1 Title: Update IEEE1994 to JuJu interface openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Roger Oberholtzer (rogeroberholtzer) Description: The Linux kernel has been getting improved support for FireWire. Despite USB 3.0, there are lots of FireWire devices around. So I think it is worth wile keeping up to date. A good start would be to update the 1394 libraries to newer versions that detect if the old or new kernel support is present. This would allow developers to see that their code works with the newer libraries. Then, when appropriate, the kernel modules themselves can be updated. In fact, both the old and the new can be available, only the desired ones being loaded. See http://ieee1394.wiki.kernel.org/index.php/Juju_Migration for details. -- openSUSE Feature: https://features.opensuse.org/308858

1 1