May 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 306443] change parted to use Hardware suggested sectors per track
by fate_noreply＠suse.de 05 Nov '10

05 Nov '10

Feature added by: Dean Giles (dgiles) Feature #306443, revision 1, last change by Title: change parted to use Hardware suggested sectors per track openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Dean Giles (dgiles) Description: parted creates partitions which are automatically assigned 63 sectors per track. Hardware, such as HP raid devices, advertise that they want 32 sectors per track. It advertises that through ioctl HDIO_GETGEO. fdisk can utilize the hardware reported sectors per track. parted needs to be changed to do the same. See bug # 501152. Dean -- openSUSE Feature: https://features.opensuse.org/306443

1 20

[openFATE 306427] WLAN Driver for eeePCs
by fate_noreply＠suse.de 04 Nov '10

04 Nov '10

Feature added by: Dominik Heidler (dheidler) Feature #306427, revision 1, last change by Title: WLAN Driver for eeePCs openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Dominik Heidler (dheidler) Description: When you are using openSUSE on an eeePC, only unencrypted and WEP Networks are working, because of Asus using a special Version of the Ateros WLAN chipset. You can fix this by installing the Kernel, provided at the end of this thred (http://www.pc-forum24.de/suse-treiber/10335-geloest-ralink-rt2860-unter-ope…) . -- openSUSE Feature: https://features.opensuse.org/306427

1 10

[openFATE 306308] Preview and cancel functions in openFATE edit mode
by fate_noreply＠suse.de 27 Oct '10

27 Oct '10

Feature added by: Rajko Matovic (rajko_m) Feature #306308, revision 1, last change by Title: Preview and cancel functions in openFATE edit mode openFATE: Unconfirmed Priority Requester: Desirable Requested by: Rajko Matovic (rajko_m) Description: Preview button - adds user comment, reply, usecase, testcase but leaves edit window opened, so that user can change layout. Cancel button - quits edit mode and drops all changes. -- openSUSE Feature: https://features.opensuse.org/306308

1 11

[openFATE 306194] openFATE Client
by fate_noreply＠suse.de 27 Oct '10

27 Oct '10

Feature added by: Raúl García (bgta) Feature #306194, revision 1, last change by Title: openFATE Client openFATE: Unconfirmed Priority Requester: Desirable Requested by: Raúl García (bgta) Description: It would be interesting to create a client like Bug Buddy to openFATE. With a desktop shortcut, the users can suggest new requirements for future developments. -- openSUSE Feature: https://features.opensuse.org/306194

1 6

[openFate 305690] Replace System-V init with upstart init
by fate_noreply＠suse.de 27 Oct '10

27 Oct '10

Feature added by: Vitaliy Tomin (HighwayStar) Feature #305690, revision 1, last change by Title: Replace System-V init with upstart init openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Vitaliy Tomin (highwaystar) Partner organization: openSUSE.org Description: Upstart - an event-based init daemon. It can provide more flexible init system for more faster and effective boot and communication with the init daemon over D-Bus. upstart home page http://upstart.ubuntu.com/ -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305690

1 56

[openFATE 306341] Show developer assigned information
by fate_noreply＠suse.de 26 Oct '10

26 Oct '10

Feature added by: Michael Löffler (michl19) Feature #306341, revision 1, last change by Title: Show developer assigned information openFATE: Unconfirmed Priority Requester: Important Requested by: Michael Löffler (michl19) Description: Currently its not visible for community outside Novell if a developer is set or not. To ease community conribution this information needs to be visible outside the company as well. People then can find features where help is needed much easier and/or a call for contribution can be made. -- openSUSE Feature: https://features.opensuse.org/306341

1 8

[openFate 305312] OpenSUSE <= 11.1 Alpha 2 don't install on SD card
by fate_noreply＠suse.de 06 Oct '10

06 Oct '10

Feature added by: Arvin Schnell <aschnell(a)novell.com> Feature #305312, revision 1, last change by Title: OpenSUSE <= 11.1 Alpha 2 don't install on SD card openSUSE-11.2: New Priority Requester: Important Requested by: Harald Welte <haraldwelte(a)viatech.com> Partner organization: openSUSE.org Description: [Please note that I'm working for the CPU+Chipset maker VIA and this is an actually important feature for the 'netbook' class of devices in the coming months] Recently, BIOS vendors have been starting to implement a 'boot from SD card' feature, much like they have added 'boot from USB memory stick' some years ago. The only SD-card host controller that I've seen this implemented for is SDHCI compliant host controllers. While this is a nice feature to support, for most systems it is just a gimmick and not something neccessarry. However, there are hand-held devices such as netbooks in the pipeline which do not have any other mass storage device. No hard disk and no IDE-attached flash disk or the like. They just have one (more likely two or more) SD card slots and you install and store not only your data but the entire operating system on that SD card. Furthermore, there are products like Samsung moviNAND which are basically a SDcard in a BGA package that can be soldered onto a PCB. So from a protocol and software point of view it is a SD card, but it is mechanically soldered onto the board. Such device have gained some popularity in ARM-based designs, but we'll likely see them in the x86 world, too. To make this happen, The distribution installation initrd needs to 1. include and auto-load the sdhc.ko and sdhci_pci.ko kernel modules 2. create the /dev/mmcblk* device nodes as per udev/hotplug events The actual distribution installation program needs to 1. recognize /dev/mmcblk* as block devices that can be used as target device 2. use a grub-install or similar program that can discover the bios drive number to /dev/mmcblk* device name mapping I have outlined the full details at http://wiki.gpl-devices.org/wiki/Installing_Linux_on_booting_SD_card -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305312

1 18

[openFate 305706] Facebook chat/Pidgin Integration
by fate_noreply＠suse.de 07 Sep '10

07 Sep '10

Feature added by: Kevin Dupuy (kdupuy9) Feature #305706, revision 1, last change by Title: Facebook chat/Pidgin Integration openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Kevin Dupuy (kdupuy9) Partner organization: openSUSE.org Description: Facebook is currently the most popular social networking site, and it's chat functionality is being used as an IM client for many people. With pidgin-facebookchat (http://code.google.com/p/pidgin-facebookchat/) , Pidgin seamlessly integrates Facebook friends and chats as it would any other IM service. The plugin is already there, and licensed under the GPLv3 (see website above). -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305706

1 7

[openFate 305267] Installation using Orca (screen reader) to Improve Accessibility
by fate_noreply＠suse.de 10 Aug '10

10 Aug '10

Feature added by: Lukas Ocilka <locilka(a)novell.com> Feature #305267, revision 1, last change by Title: Installation using Orca (screen reader) to Improve Accessibility openSUSE-11.2: New Priority Requester: Desirable Requested by: Darragh Ó Héiligh <d(a)digitaldarragh.com> Partner organization: openSUSE.org Description: Original title: Accessibility for installation could be automated with better results. Users can currently press F9 at the boot screen to hear the boot options spoken. THis is a fantastic new feature and is one that OpenSuSE is the first to add. For this you should be very proud. However, I would ask that you further build upon this success by recognising that accessibility at the boot menu has been enabled and automatically start the Orca screen reader with also setting gnome accessibility to enabled. One further consideration should be taken into account. To enable Orca to access the installation screen, Orca must be run as root. However, if Orca is run as root, the rest of the desktop is not accessible due to permissioning issues. Therefore, the installation should be run automatically if the f9 key si pressed. Note, a similar feature excluding the accessible boot menu has also been added to Ubuntu 8.04. Note that they also have a key press (F5) to automatically enable assistive technologies for installation on their live CD. References: See bnc #417874 (https://bugzilla.novell.com/show_bug.cgi?id=417874) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305267

1 5

[openFate 305589] Checkbox "include user home projects in search"
by fate_noreply＠suse.de 30 Jul '10

30 Jul '10

Feature added by: Pavol Rusnak <prusnak(a)novell.com> Feature #305589, revision 1, last change by Title: Checkbox "include user home projects in search" Buildservice: New Priority Requester: Desirable Requested by: Pavol Rusnak <prusnak(a)novell.com> Partner organization: openSUSE.org Description: Here's one idea to start with: on the search page, have a checkbox labeled "Include user home projects in search" which defaults to OFF. Then at least you have one level of separation (between "official" and home projects) that is clear to both developers and users. And developers will be motivated to move their generally useful packages into an "official" project by the fact that the default checkbox is OFF. http://lists.opensuse.org/opensuse-buildservice/2008-12/msg00088.html -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305589

1 4

[openFATE 305905] Package and Project Marking
by fate_noreply＠suse.de 02 Jun '10

02 Jun '10

Feature added by: Will Stephenson (wstephenson) Feature #305905, revision 1, last change by Title: Package and Project Marking Buildservice: Unconfirmed Priority Requester: Important Requested by: Will Stephenson (wstephenson) Description: * Add the ability to have a 'status update' on packages AND projects * * status updates are not package changelogs; logs refer to changes to the contents of the package, status updates relate to ongoing work on the packages * * 1:N relationship, status updates are timestamped. Like facebook or $microblogging service. * show current status on checkout or list * Add a command to read all the status updates on a package. Examples: 1) Jack is updating Commodore:Amiga:Workbench:Factory to 23.2 and disables publish on the whole project before the actual release date with the status message '20090224 - disabled publish pending 23.2 release' 2) Jill is triaging breakages in Commodore:Amiga:Workbench:Factory and marks packages without checking them out before assigning work to team members Denise and Paula, with "osc mark -m 'broken by input.device changes' Commodore:Amiga:Workbench:Factory Preferences" 3) Paula is fixing a breakage in Commodore:Amiga:Workbench:Factory Preferences and locks (see #305899) the package with status update using "osc co -l -m '20090225 - fixing build failure due to input.device changes' Commodore:Amiga:Workbench:Factory Preferences" -- openSUSE Feature: https://features.opensuse.org/305905

1 3

[openFATE 306192] Make BuildService accessible for anonymous users
by fate_noreply＠suse.de 22 Mar '10

22 Mar '10

Feature added by: Michal Vyskocil (mvyskocil) Feature #306192, revision 1, last change by Title: Make BuildService accessible for anonymous users Buildservice: Unconfirmed Priority Requester: Important Requested by: Michal Vyskocil (mvyskocil) Description: We hides many useful information about our distribution behind a Novell login, which makes a participation harder. Other distributions are much more opened even for anonymous users, so you can browse source codes, patches, changelogs, build logs, ... even if you are an anonymous users. We should be opened as much as possible if we want to be a community based distribution. Some examples: * Fedora CVS (http://cvs.fedoraproject.org/viewvc//) expose all Fedora packages with full history and for anonymous users * kojibuild info (http://koji.fedoraproject.org/koji/buildinfo?buildID=81815) - you have a full access to building informations from koji system and some of them are not available for OBS users at all. * Debian changelog browsing (http://packages.debian.org/changelogs/pool/main/c/cdbs/cdbs_0.4.52/changelog) Debian offers a changelog browsing (they don't use a centralized VCS) without registration. * lintian reports (http://lintian.debian.org/maintainer/build-common-hackers@lists.alioth.debi…) you can see a lintian issues for every package. * Debian build log (http://buildd.debian.org/pkg.cgi?pkg=libmatthew-java) Debian also offers an access to a build log of package. * Gentoo package information (http://packages.gentoo.org/package/app-office/nostaples?ts=2009-03-11T05:57…) Gentoo offers many information about package Those examples are only for illustrate of other approaches. I don't try to tell we must implement CVS because Fedora has it. And some issues like an alternative of Gentoo package view should be implemented in upcoming Software Portal. We should publish (at least for openSUSE:* projects) sources of packages and a build logs. -- openSUSE Feature: https://features.opensuse.org/306192

1 25

[openFate 305104] Provide possibility to configure WEP/WPA/WPA2/... at installation
by fate_noreply＠suse.de 09 Mar '10

09 Mar '10

Feature added by: Lukas Ocilka <locilka(a)novell.com> Feature #305104, revision 1, last change by Title: Provide possibility to configure WEP/WPA/WPA2/... at installation openSUSE-11.1: New Priority Requester: Desirable Requested by: Jim Creech <jacreech(a)suddenlink.net> Partner organization: openSUSE.org Description: It is possible to configure a network in the first stage installation but it is only possible to select DHCP or Static + configure proxy. It is impossible to configure a secure wireless connection. See also: Bug 293609 (https://bugzilla.novell.com/show_bug.cgi?id=293609) - No provision for entering WEP at installation -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305104

1 9

[openFATE 306379] Use rsync when refreshing repositories
by fate_noreply＠suse.de 02 Mar '10

02 Mar '10

Feature added by: Piotrek Juzwiak (BenderBendingRodriguez) Feature #306379, revision 1, last change by Title: Use rsync when refreshing repositories openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Piotrek Juzwiak (benderbendingrodriguez) Description: It would be a great idea to use rsync when refreshing repositories, one of the bad things is the refresh speed. It gets worse when people have many repositories. I'm not sure but it already compares if something has changed in the repo but to speed things up it would be great to use rsync. -- openSUSE Feature: https://features.opensuse.org/306379

1 14

[openFate 305724] Allow to take over old users by home directory
by fate_noreply＠suse.de 02 Mar '10

02 Mar '10

Feature added by: Jiří Suchomel (jsuchome) Feature #305724, revision 1, last change by Title: Allow to take over old users by home directory openSUSE-11.2: New Priority Requester: Neutral Requested by: Jiří Suchomel (jsuchome) Partner organization: openSUSE.org Description: (from bug reporter:) I have a seperate /home partition and whenever I reinstall/upgrade I just set up the same user as before and he gets assigned the same uid (1000) so nothing gets broken. But I guess with more users and corresponding home directories this aproach begs for wrong permissions, so I suggest the following: In case /home isn't empty it could take all directories available and list them as users to specify their data (Name, login, passwort etc as usual) and then assign corresponding uid. References: https://bugzilla.novell.com/show_bug.cgi?id=464238 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305724

1 7

[openFATE 305945] get rid of "symsets" in kernel package dependencies
by fate_noreply＠suse.de 01 Mar '10

01 Mar '10

Feature added by: Michal Marek (michal-m) Feature #305945, revision 1, last change by Title: get rid of "symsets" in kernel package dependencies openSUSE-11.2: New Priority Requester: Important Requested by: Michal Marek (michal-m) Description: Currently, the kernel rpm packages group the exported kernel and module symbols in find-provides and provide these "symsets". It has been done this way to reduce the amount of data the solver has to process. It has a number of problems though: * Moving modules around or adding symbols changes the symset checksums, so the rpm build needs symsets of the previous kernel(s) to provide both old and new checksums * changing or removing one unused or unimportant symbol means that each kmp that uses any other symbol from the same symset needs to be rebuilt Now that we have a much better solver, it's time to get rid of this and provide just the individual symbols. I created a test project in the build service: home:michal-m:kill-symsets. which rebuilds all 11.1 kmps against a normal kernel and against a kernel with symsets turned off (this kernel is built in home:michal-m:kill-symsets:changes). The size difference is rather low, total size of all the rpms on i586 and x86_64 increased by about 1.3M, installed size decreased by 2.6M (because of the removed /boot/symsets* files). Size of yum metadata increased by 1.4M. What needs to be done is to make sure that the solver can really handle this fine (-> Michael). I'm waiting for the test repos to appear on download.o.o. -- openSUSE Feature: https://features.opensuse.org/305945

1 17

[openFATE 306343] 'Pkgstars' to reward contributors
by fate_noreply＠suse.de 20 Feb '10

20 Feb '10

Feature added by: Will Stephenson (wstephenson) Feature #306343, revision 1, last change by Title: 'Pkgstars' to reward contributors Buildservice: Unconfirmed Priority Requester: Important Requested by: Will Stephenson (wstephenson) Description: In KDE we use 'dashstars' to reward those who fix build breakages. When a broken build module is fixed, the person responsible for the commit that fixed the build is awarded a 'dashstar', and an IRC bot advertises this in the developer channel with a message such as "JohnDoe fixed kdelibs (64 dashstars)" so the community sees their contribution. In addition, contributors can query their dashstar totals. A similar system for eg package build fixes or package version updates that is visible on the user's opensuse homepage and advertised in community channels (or a weekly summary mail to -project) would be a fun way to reward contributions. -- openSUSE Feature: https://features.opensuse.org/306343

1 2

[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 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

[openFATE 305937] Delete Request Mechanism
by fate_noreply＠suse.de 19 Feb '10

19 Feb '10

Feature added by: Adrian Schröter (adrianSuSE) Feature #305937, revision 1, last change by Title: Delete Request Mechanism Buildservice: Evaluation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Adrian Schröter (adriansuse) Description: As part of our PDB migration, we need a mechanism to request a package removal in a project, where no write access exists. Klaas, can you make a proposal how a package (and project ?) removal can look alike ? -- openSUSE Feature: https://features.opensuse.org/305937

1 3