February 2010 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305930] Don't increase version number if not strictly needed
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Joop Boonen (worldcitizen) Feature #305930, revision 1, last change by Title: Don't increase version number if not strictly needed Buildservice: Unconfirmed Priority Requester: Important Requested by: Joop Boonen (worldcitizen) Description: As I use KDE42 and other newer packages I often do a factory update. I see that the footprint is very big. Because a package gets always rebuild when for instance a dependent library get rebuild. Even if the package is 100% the same it'll gets the same version number. If possible I would like to have binary identical packages yo keep the same version number this reduces bandwidth usage for users/mirrors and it can give people a false feeling that Linux is buggy "as so many packages need to be updated". -- openSUSE Feature: https://features.opensuse.org/305930

1 4

[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 305656] Make hyperlinks from source project names on 'My Projects' page
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature changed by: Adrian Schröter (adrianSuSE) Feature #305656, revision 6 Title: Make hyperlinks from source project names on 'My Projects' page - Buildservice: New + Buildservice: Done 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 + #4: Adrian Schröter (adriansuse) (2010-02-20 09:36:25) + got implemented. -- openSUSE Feature: https://features.opensuse.org/305656

1 0

[openFATE 305591] Define Purpose for each openSUSE Build Service Project
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature changed by: Adrian Schröter (adrianSuSE) Feature #305591, revision 8 Title: Define Purpose for each openSUSE Build Service Project Buildservice: Evaluation Priority Requester: Important Requested by: Pavol Rusnak (prusnak) Description: define purpose for each project, like: * add-on package * fresh packages + libraries (eg. games) * bleeding edge packages (eg. zypp:svn) * backports for older distributions (eg. zypp:Backport) * playground (eg. all home projects) So, * this sets users expectations * purpose could be indicated by naming conventions, or even better by project flags * purpose must be shown in the search result for this method to work References: http://lists.opensuse.org/opensuse-buildservice/2008-12/msg00056.html Discussion: #1: Andreas Jaeger (a_jaeger) (2009-08-11 15:51:09) This sounds like a good idea. What needs to be done to make this happen? + #2: Adrian Schröter (adriansuse) (2010-02-20 09:25:34) + I think we can fullfill this request by two independend features: + * Project classification setting to be set by the project owner (this + is handled in #306232) + * Automatic QA validation how a package will influence the system, for + example: + * replace base packages + * replace files + * replace libaries + * just being an add-on -- openSUSE Feature: https://features.opensuse.org/305591

1 0

[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

[New: openFATE 309025] BRL-CAD, a GPLed Computer Aided Design suite
by fate_noreply＠suse.de 19 Feb '10

19 Feb '10

Feature added by: Matthew Ayres (Solar_Granulation) Feature #309025, revision 1 Title: BRL-CAD, a GPLed Computer Aided Design suite Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Matthew Ayres (solar_granulation) Partner organization: openSUSE.org Description: All over the internet I find demand for good Computer Aided Design software on Linux and, sometimes, people stumble onto BRL-CAD and find it to be just what they want. It's surprisingly little known, but it's well developed, versatile and stable. Here's a blurb from the website: "BRL-CAD is a powerful cross-platform open source solid modeling system that includes interactive geometry editing, high-performance ray-tracing for rendering and geometric analysis, image and signal-processing tools, a system performance analysis benchmark suite, libraries for robust geometric representation, with more than 20 years of active development." Its development was kicked off, the best part of thirty years ago, by the US military because they needed CAD software capable of ballistic and radar analysis. They have used BRL-CAD now for a long time and, a few years ago, opened the project to the community under a set of open-source licenses in which LGPL is the most largely represented. Although some of its techniques are a little dated (using a solid modelling system, rather than concentrating on surfaces) it is very powerful and continues to find new users. Use Case: A dedicated openSUSE user wants to build a robot, perhaps as an academic project or to enter in a competition. He can compile code using the tool-chain and can design circuits with KTechLab and PCB schematics using pcb. But how does he design the robot itself? A little research tells him that CAD software would be worth a look, so he puts the acronym into YaST to see what pops up. What does he find? He might find FreeCAD or PythonCAD, but these are rather underdeveloped and underpowered. But if he finds BRL-CAD, with a description alluding to its prestigious background, he will have discovered software that can handle the task with ease after little study. Business case (Partner benefit): openSUSE.org: Adding BRL-CAD to openSUSE's repositories will open the world of Computer Aided Design to openSUSE's users. As the suite's presence in the distribution becomes more widely known, those wishing to migrate their CAD work to Linux will find openSUSE more desirable than other distributions due to this software's presence. Adding this CAD suite will also help to show that Linux can be a viable system for engineers and scientists who need this kind of functionality. -- openSUSE Feature: https://features.opensuse.org/309025

1 2