February 2009 - openSUSE Features - openSUSE Mailing Lists

[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 305783] Integrate latest stable KDE4 release
by fate_noreply＠suse.de 05 Nov '09

05 Nov '09

Feature added by: Stephan Binner (Beineri) Feature #305783, revision 1, last change by Title: Integrate latest stable KDE4 release openSUSE-11.2: New Priority Requester: Mandatory Requested by: Stephan Binner (beineri) Partner organization: openSUSE.org Description: Depending on what the openSUSE 11.2 schedule allows, the next release has to contain either the latest KDE 4.2.x or KDE 4.3.x packages including usual nifties (see external link) and integration with the distribution. In any case it should be tested and run with Qt 4.5 and KDE applications should be used in KDE4 versions as far as possible. Relations: - Ideas what to achieve with KDE on 11.2 (url: http://en.opensuse.org/KDE/Ideas/11.2) -- openSUSE Feature: https://features.opensuse.org/305783

1 17

[openFate 305624] Allow downloading all packages before installing
by fate_noreply＠suse.de 30 Oct '09

30 Oct '09

Feature added by: Jiri Srain <jsrain(a)novell.com> Feature #305624, revision 1, last change by Title: Allow downloading all packages before installing openSUSE-11.2: New Requested by: Jiri Srain (jsrain) Interested: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Libzypp should allow to set a policy to first download all packages and afterwards install all packages at once. It should be considered whether to enable this policy under some scenarios (e.g. makes sense for online update, but not for distro installation) References: https://bugzilla.novell.com:443/show_bug.cgi?id=448040 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305624

1 42

[openFate 305730] Add Package-Wishlist as 'Products' Component
by fate_noreply＠suse.de 21 Oct '09

21 Oct '09

Feature added by: Lars Vogdt (lrupp) Feature #305730, revision 1, last change by Title: Add Package-Wishlist as 'Products' Component openFATE: Unconfirmed Priority Requester: Important Requested by: Lars Vogdt (lrupp) Partner organization: openSUSE.org Description: So current solution for openSUSE users to suggest new packages for inclusion in openSUSE is a bit complicated and diverted in many places: * see the Wislists (http://en.opensuse.org/Wishlist) in the Wiki * see the Bugzilla (http://devzilla.novell.com/education/) of openSUSE-Education * see Novells Bugzilla (https://bugzilla.novell.com/) * see the openSUSE-Forums and Mailinglists... A possible solution with the new openFATE could be to unify the process to request new packages for openSUSE on one single place: openFATE! To make requests of new packages easy, someone should be able to file a request against a "Product" named "New packages" or "Package Wishlist". Perhaps it's possible to create a simple Wizard for this special product in the future, including: * At least two mandatory fields for packagename and upstream URL * and a simple "search for pending requests" after entering the two mandatory fields to avoid duplicates. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305730

1 7

[openFate 305691] Support ext4 as installation option
by fate_noreply＠suse.de 19 Oct '09

19 Oct '09

Feature added by: Stephan Binner (Beineri) Feature #305691, revision 1, last change by Title: Support ext4 as installation option openSUSE-11.2: New Priority Requester: Mandatory Requested by: Stephan Binner (beineri) Partner organization: openSUSE.org Description: Next openSUSE release should at least support to use (versus "default to") ext4 as file system. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305691

1 35

[openFate 305702] Finer checks for a syslog reload need in dhcp client scripts
by fate_noreply＠suse.de 12 Oct '09

12 Oct '09

Feature added by: Marius Tomaschewski (mtomaschewski) Feature #305702, revision 1, last change by Title: Finer checks for a syslog reload need in dhcp client scripts openSUSE-11.2: New Priority Requester: Neutral Requested by: Karl Katzke (karlkatzke) Interested: Stefan Behlert (sbehlert) Interested: Stephan Kulow (coolo) Partner organization: openSUSE.org Description: Syslog reloads every time the DHCP lease is renewed, even though the "change hostname via DHCP" option is turned off in the configuration. Finer control requested in bugzilla, bug 466198, by Karl Katzke. Would be a finer control / finer checks (hostname, ip address changes) desirable to implement? Relations: - syslog does not get right hostname when dhcp is used (novell/bugzilla/id: 116466) https://bugzilla.novell.com/show_bug.cgi?id=116466 - DHCP renewal causes syslog-ng reset even if host name has not changed (novell/bugzilla/id: 466198) https://bugzilla.novell.com/show_bug.cgi?id=466198 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305702

1 8

[openFATE 305888] Disable PulseAudio by default
by fate_noreply＠suse.de 06 Oct '09

06 Oct '09

Feature added by: Stephan Kulow (coolo) Feature #305888, revision 1, last change by Title: Disable PulseAudio by default openSUSE-11.2: Unconfirmed Priority Requester: Mandatory Requested by: Alberto Passalacqua (albertop) Description: PulseAudio has been one of the major sources of complaints and of problems for both the 11.0 and 11.1 release, with significant annoyances for openSUSE users, as reported on IRC and on local forums. As a consequence it is worth to consider the possibility to disable it by default on freshly installed systems for openSUSE 11.2. This enhancement request aims to collect the votes of those who agree with this. According to a discussion in IRC with coolo, if there are enough requests, this might be done. So, please, if you want to see PA disabled by default, in favour of a working audio system out of the box for many more users, just comment here. Relations: - Disable PulseAudio by default (novell/bugzilla/id: 478511) https://bugzilla.novell.com/show_bug.cgi?id=478511 Discussion: #1: Criss Peress (pieris) (2009-02-22 12:52:19) +1 #2: Jakub Rusinek (liviopl) (2009-02-22 13:31:25) You should have a look at what Lennart says on pulseaudio-discuss list [1], 'cause this might be important for openSUSE. 1| https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-February/003150… #3: Luigi Bettin (gigi888) (2009-02-22 13:55:58) +1 #4: Alberto Passalacqua (albertop) (2009-02-22 14:23:28) On comment #2: that has nothing to do with this discussion. Please keep it on topic! Fedora, cited in the link as the distribution doing something in the suggested direction, has similar complaints to those we had for openSUSE 11.0 and 11.1. Bye, A. #5: andrea florio (anubisg1) (2009-02-22 16:57:39) +1 for me #6: andrea martin (il_cjargnel) (2009-02-22 23:54:03) +1 for me (no pulse audio of default in 11.2) #7: Takashi Iwai (tiwai) (2009-02-23 01:07:08) Guys, the bugzilla is no place for voting or discussions, and it's no user forum. It's the place to report a bug and fix the bug. Please vote/discuss on ML at first. Then report back the result to bugzilla as the consensus of the whole community. Thanks. #8: Sven Burmeister (rabauke) (2009-02-23 04:28:01) I do not see any discussion here. Enabling pa by default can be regarded as a bug and not doing so as an enhancement people vote on. Bugzilla is about bugs/enhancements (not features) and voting. #9: Alberto Passalacqua (albertop) (2009-02-23 07:22:54) In answer to comment #7: This is an enhancement request, and bugzilla is exactly the place where this kind of discussion, to collect votes for it. Further discussion happened in the IRC anyway, and this bug report was opened as a consequence of it to collect user's feedback in a clean and organized manner, so that the decisionmaker can decide without reading an endless discussion in a mailing-list. As a consequence I reopen it. Regards, A. #10: Alberto Passalacqua (albertop) (2009-02-23 07:26:33) @Takashi Iwai: You might want to take part to the IRC life of openSUSE and discuss with us. Any suggestion/help is welcome! :-) #11: Takashi Iwai (tiwai) (2009-02-23 07:43:54) Could you give the exact voting result here? (And, no I'm not going to join IRC just for this purpose.) The vote must be done in an open way, and needs to take from a wide range of voters (users) without bias. Voting in bugzilla doesn't make sense for this kind of issue because the bugzilla (a specific bug entry) isn't the place where every user takes a look. It's the place where the people with the same problems take a look. Thus, of course, it will result in votes just by haters. Also, the endless discussion in ML is the result you have to respect. If there is no clear sign in the discussions in ML, it means there is no clear way to go, too. The rest is the political decision, and not about technical ones (remember KDE vs GNOME). So, please give more concrete technical issues rather than emotional +1/-1 votes. #12: Michael Skiba (mirrakor) (2009-02-23 10:03:31) > So, please give more concrete technical issues rather than emotional +1/-1 votes. There's nothing emotional about it. > It's the place where the people with the same problems take a look. Thus, of course, it will result in votes just by haters. Which is exactly the point - this isn't an open "opinion poll" it's about messuring how big the disturbances/problems (->bug) with PA really is, and if it affects enough people it's worth thinking about disabling it by default. #13: Alberto Passalacqua (albertop) (2009-02-23 10:07:28) Hi Takashi, the result of the voting, done with the usual procedure to vote bugs and requests, can be read at the top of the page. Currently this request has 27 votes. Each user can give a maximum of five votes. I probably wasn't clear in the initial post. We discussed to disable PA on IRC, and coolo suggested that is can be done if there is a sufficient number of requests. I don't know what "sufficient" means, but I thought it would have been easier to collect the votes in a quantitative manner here, using bugzilla features. I think it is important to notice that I'm not asking to remove PulseAudio, but to simply disable it by default, so that users don't meet the problems it is causing to them. PulseAudio can be already be disabled with one click in YaST, and the same can done to enable it again. My idea is that we should not activate it by default, because for 11.0 and 11.1 releases we had quite a lot of complaints due to it. Users who want it will be able to enable it with a simple click, but the new unexperienced user won't have to fight to make it work to listen to his music, which will result in a better image of the distribution that "works out of the box" and at the same time provides "the latest stack" for those who want/need it. The concrete technical issues are the following (I sum up what reported): - PA audio glitches often. - It gives troubles with Flash and other players, which capture the server, making other applications unable to work correctly. - It crashes, leaving you without controls on the audio system (Connection refused). - It doesn't work properly with some player and sound tool (someone reported issues with audacity, skype (I know it's skype problem but people wants to use it) gives problems too). Anyway, if you prefer, we can post the link on the ML to make it available to a wider public. I simply fear it will become noisy. I already spread it on IRC when I opened the request. P.S. My invitation on IRC was friendly. If you don't like it, there is no problem. But I'm serious when I say that suggestions are welcome. After all we are here to improve things, and not to fight between us :-) Regards, Alberto #14: Daniele Tombolini (kailed) (2009-02-23 11:47:18) +1 at least, under kde is unuseful. #15: Takashi Iwai (tiwai) (2009-02-23 12:11:37) OK, then I reassign this bug to coolo. Please reassign back after the decision is made. My position is neutral about this. I myself don't use PA, and I won't. But I do understand that some (other) people want PA as default, too. #16: alberto rossi (al9000) (2009-02-23 12:13:09) no to pulseaudio by default in opensuse 11.2 #17: Rajko Matovic (rajko_m) (2009-02-23 13:17:47) This is discussion about this enhancement request: http://lists.opensuse.org/opensuse-factory/2009-02/msg00208.html #18: Alberto Passalacqua (albertop) (2009-02-23 13:21:34) FYI, opened a discussion here so the interested people can say their opinion and we can collect more feedback: http://lists.opensuse.org/opensuse-factory/2009-02/msg00208.html A. #19: Vincent Untz (vuntz) (2009-02-23 14:47:36) Stupid question, if people think that the votes on this bug can be taken into account for the decision: how can people vote to keep pulseaudio? IMHO, bugzilla is not the right place for this -- this is not an enhancement request, this is a technical decision. Starting a thread on opensuse-factory was a good thing, though :-) #20: Andras Barna (sartek) (2009-02-23 19:59:13) for me alsa worked perfectly, so why change it.. so +1 #21: Jigish Gohil (cyberorg) (2009-02-23 22:45:22) Can we get kernel people look into the points raised in link posted on comment #2? https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-February/003150… Quoting relevant parts from that post for everyone's benefit here. "Apparently OpenSUSE ships a kernel (2.6.27.7-9-pae) that causes scheduling latencies of > 210ms. That is a lot. That is really really really a lot." "Fedora-kernels that easily give latencies of 5ms or so." "1) For fucks sakes: get your bloody kernels fixed. Enable preempt, set HZ to 1000. Get rid of low-quality drivers that block the CPU. Latencies of 210ms is *REALLY NOT NECESSARY*. 2) If you want to stick with your crap kernel, then either disable g-f entirely or adjust the #defines at the top of src/modules/alsa-sink.c and src/modules/alsa-source.c." So why do our kernel suck so bad? -- openSUSE Feature: https://features.opensuse.org/305888

1 28

[openFATE 305845] YaST - keyword search for modules
by fate_noreply＠suse.de 30 Sep '09

30 Sep '09

Feature added by: Pavol Rusnak (prusnak) Feature #305845, revision 1, last change by Title: YaST - keyword search for modules openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Pavol Rusnak (prusnak) Description: System Preferences in Mac OS X (YaST equivalent from Apple :)) has a group of keywords associated with each module. It would be nice if YaST had the same. Example: * module: Hardware -> Graphics Card and Monitor * keywords: graphics, monitor, screen, resolution, ... When user wants to change the resolution, he/she starts YaST, type "resolution" in search box and "Graphics Card and Monitor" module will show up. This is not possible now, because YaST only searches in descriptions of modules. -- openSUSE Feature: https://features.opensuse.org/305845

1 5

[openFate 305343] Partitioner: Support RAID10
by fate_noreply＠suse.de 25 Sep '09

25 Sep '09

Feature added by: Arvin Schnell <aschnell(a)novell.com> Feature #305343, revision 1, last change by Title: Partitioner: Support RAID10 openSUSE-11.2: New Priority Requester: Important SLES-12: New Priority Requester: Important Requested by: V K <truckk(a)inbox.lv> Partner organization: openSUSE.org Description: There is interesting raid-10 config on 2 disks witch can be created like that: mdadm --create /dev/md1 --bitmap=internal --metadata=1.0 --level=raid10 --raid-devices=2 --layout=f2 /dev/sda2 /dev/sdb2 such configuration gives about 2x sequential read performance in comparison with plain raid-1 partitioner shows only RAID Type: RAID_UNKNOWN. Discussion: #1: Arvin Schnell <aschnell(a)novell.com> (2008-10-17 04:05:48) I know, same is true for RAID6. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305343

1 8

[openFate 305631] vlan support in initrd
by fate_noreply＠suse.de 15 Sep '09

15 Sep '09

Feature added by: Bernhard Walle <bwalle(a)novell.com> Feature #305631, revision 1, last change by Title: vlan support in initrd openSUSE-11.2: New Requested by: Bernhard Walle (bwalle) Partner organization: openSUSE.org Description: Quoting from Bugzilla 415389 (because external reporters are not able to create a FATE entry): It would be very useful to be able to create vlan network interfaces in initrd via kernel command line parameters. This makes network support in initrd more complete. In our case we need vlan support because all servers have two physical network interfaces. eth0 is connected to the default vlan, which is internet in our case. eth1 is a trunk interface connected to several internal vlans. We need the vlans to seperate traffic from different virtual machines. Only one vlan supports nfs, other vlans are more restricted or private to a customer owning a virtual machine. Because a xen dom0 server doesn't need much diskspace, we boot them from the network. This requires the initrd to login to the nfs server, which requires vlan support. Business case (Partner benefit): openSUSE.org: I don't see any business case here. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305631

1 4

[openFate 305594] Logging support for osc meta and others ...
by fate_noreply＠suse.de 14 Sep '09

14 Sep '09

Feature added by: Pavol Rusnak <prusnak(a)novell.com> Feature #305594, revision 1, last change by Title: Logging support for osc meta and others ... Buildservice: New Priority Requester: Important Requested by: Pavol Rusnak <prusnak(a)novell.com> Partner organization: openSUSE.org Description: * The logging support missing for osc meta and other potentially dangerous ctions. When anyone changes a project conf for example, there's no information who changed what. So the current commit logs support should be extended to all other changes in package/project. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305594

1 2

[openFate 305731] Remove scrollkeeper
by fate_noreply＠suse.de 07 Sep '09

07 Sep '09

Feature added by: Vincent Untz (vuntz) Feature #305731, revision 1, last change by Title: Remove scrollkeeper openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Vincent Untz (vuntz) Partner organization: openSUSE.org Description: We should remove scrollkeeper from the distribution and only use a rarian-based solution. This implies working upstream on migrating the modules. Also, we could make packages install their help in /usr/share/datatir/gnome-panel/help (eg), instead of /usr/share/gnome/help which is difficult to handle from a package ownership point of view. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305731

1 5

[openFate 305345] Replace cups-autoconfig with hal-cups-utils
by fate_noreply＠suse.de 07 Sep '09

07 Sep '09

Feature added by: Vincent Untz <vuntz(a)novell.com> Feature #305345, revision 1, last change by Title: Replace cups-autoconfig with hal-cups-utils openSUSE-11.2: New Priority Requester: Important Requested by: Vincent Untz <vuntz(a)novell.com> Partner organization: openSUSE.org Description: In openSUSE, we use cups-autoconfig to automatically configure new printers detected by HAL. However, no other distro uses this, and hal-cups-utils seems to be the long-term solution. Switching to hal-cups-utils means easier maintenance for us. hal-cups-utils also ships the hal backend for cups that we have in cups-backends. I've packaged a new cups-backends package (without the hal backend) and a hal-cups-utils package (with the hal backend, patched like what we had in cups-backends) in home:vuntz:factory-playground. So it's all ready for testing. Note: yast2-printer makes it possible to edit /etc/cups-autoconfig.conf. We might want to keep the configuration option of /etc/cups-autoconfig.conf in hal-cups-utils. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305345

1 9

[openFate 305308] Installation into Windows Partition (Wubi-like)
by fate_noreply＠suse.de 27 Aug '09

27 Aug '09

Feature added by: Stephan Binner <stbinner(a)novell.com> Feature #305308, revision 1, last change by Title: Installation into Windows Partition (Wubi-like) openSUSE-11.2: New Priority Requester: Desirable Requested by: Stephan Binner <stbinner(a)novell.com> Partner organization: openSUSE.org Description: Wubi allows the installation of Ubuntu on a MS Windows System without changing the partition setup. Users can test-drive a Linux system without major performance loss like when using a Live-CD, have data persistence beyond reboot and an easy way to deinstall like any other application after trial. References: http://wubi-installer.org , https://wiki.ubuntu.com/WubiGuide , http://en.wikipedia.org/wiki/Wubi_(Ubuntu) Business case (Partner benefit): openSUSE.org: Having a Wubi-alike installer for openSUSE would be a great way to promote openSUSE to Windows users. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305308

1 14

[openFate 305320] Show accessed mirror(s)
by fate_noreply＠suse.de 18 Aug '09

18 Aug '09

Feature added by: Peter Poeml <poeml(a)novell.com> Feature #305320, revision 1, last change by Title: Show accessed mirror(s) openSUSE-11.1: New Priority Requester: Mandatory Requested by: Peter Poeml <poeml(a)novell.com> Partner organization: openSUSE.org Description: This concerns both YaST and zypper. It would help a lot if they would show the mirror which is accessed when downloading a package. (Technically, the download client is following redirects and the actually URL needs to be shown, not just the first URL that was contacted but that redirected to another URL) It is a long-standing problem that this information is lacking and it makes debugging and optimizing much harder than necessary, because this information is only available deeply buried in some logfile. We need this information for two reasons: 1) Debugging - to see which URL was accessed when something goes wrong, like a mirror timing out. For example, Whenever a mirror returns garbage, it takes a lot of additional time to find out which one, because all reports are lacking the critical detail, and it is usually hard to find it out later. 2) Optimizing the load sharing between different mirrors - to distinguish slow mirrors from fast ones. For example, I am very much in need of information about the situation in the US, but even though people in the US run installations for me and are willing to send me logs, I can't get this information. In reply to a question from Stano: > Do you want the information in the log or to be shown in e.g. zypper -vvv ? Shown, in normal output. It is already in some log I believe, I don't know which one exactly anymore though. Thing is, users won't be able to tell us anything useful if they weren't shown the information. And later it is not reproducible. At least in a failure situation the URLs must be shown. That alone wouldn't give us the chance to find out about slow mirrors, but at least it would allow to debug problems. Real life example #1: If a mirror is behind a firewall that lets every 10th connection stall (so the transfer hangs or the connection is reset), it usually takes weeks (!) to find out about it. But it hits virtually every user from mirrors country during the time. We have had this 4 times during the last 18 months. Real life example #2: I got feedback from someone who did a network install of openSUSE 11.0 from download.opensuse.org, located in the US. He had to let it running overnight because it took a long time. Next morning, the install hadn't even completed. YaST was hanging and waiting for somebody to hit retry. Problem is, it took us a lot of work to find out which mirror was at fault. We actually had to repeat the install, I had to follow the log and live watching his machine accessing download.opensuse.org, to see where it was redirected, and where it spent most time (while downloading some package). We found a mirror which was really slow, and I could disable it. I have a suspicion though, that we have more such mirrors, because I have got some similar reports from recently. But how to find out? People only complain about slowness, without the ability to give any useful detail. See http://news.opensuse.org/2008/09/23/upcoming-factory-changes/#comments (http://news.opensuse.org/2008/09/23/upcoming-factory-changes/#comments) for examples of this. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305320

1 18

[openFate 305694] Separate Desktop / Server Kernels
by fate_noreply＠suse.de 18 Aug '09

18 Aug '09

Feature added by: Dean Hilkewich (deanjo13) Feature #305694, revision 1, last change by Title: Separate Desktop / Server Kernels openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Dean Hilkewich (deanjo13) Partner organization: openSUSE.org Description: It seems to me that the current default kernels are somewhat hurting openSUSE's performance perception. Current kernel configs are OK but are not very well suited for desktop usage. In the future I would like to see a kernel package that is optimized for desktop usage. Current timer settings and no preemption really (sometimes drastically) hurts openGL performance and applications such as wine and causes alot of issues such as audio studdering. It would be nice to see a separate desktop performance kernel package with options such as Preemption model set to Preemptable Kenel (low-latency Desktop) and Timer Frequency Set to 1000 Hz, HPET support, Tickless System, disable optimize for size, disable Control Group support and disable Group CPU scheduler. You could also disable items and modules that are extremely rare in a desktop environment such as ATM support, Infiniband etc etc as these are not typically used in a desktop scenario which would be a large majority of openSUSE users. Further performance enhancements would also be done through out the system aimed at desktop use as well such as disabling barriers (even making it a simple checkmark option in the partitioner). Such optimizations for desktop usage can overcome openSUSE's reputation as being slower then the other mainstream distro's. The kernel settings alone can make up to a 30-40% increase in framerates in wine games for example and can cure alot of hiccups in multimedia apps. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305694

1 53

[openFate 305680] access table contents in YaST in more ways than just by push buttons
by fate_noreply＠suse.de 17 Aug '09

17 Aug '09

Feature added by: Martin Schmidkunz (mschmidkunz) Feature #305680, revision 1, last change by Title: access table contents in YaST in more ways than just by push buttons openSUSE-11.2: New Priority Requester: Important Requested by: Martin Schmidkunz (mschmidkunz) Interested: Johannes Meixner (jsmeix) Interested: Katarina Machalkova (kmachalkova) Interested: Lukas Ocilka (locilka) Interested: Martin Vidner (mvidner) Interested: Ricardo Cruz (rpmcruz) Description: There is feedback (e.g. http://mvidner.blogspot.com/2009/01/yast-ui-table-usability.html) that users might get confused with the fact that table actions (performed on the table items) are accesible only as push buttons below the table. What users are used to from other GUI applications and what they miss in YaST UI is: a) context menu activated by right click on table item (e.g. edit/delete this item) b) more function key bindings (e.g. 'Delete' key will do the same what would pushing delete button do) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305680

1 6

[openFATE 305803] improve command_not_found_helper speed
by fate_noreply＠suse.de 14 Aug '09

14 Aug '09

Feature added by: Susanne Oberhauser (froh) Feature #305803, revision 1, last change by Title: improve command_not_found_helper speed openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Susanne Oberhauser (froh) Description: In the discussion on opensuse-factory [opensuse-factory] issues with command-not-found speed (Message-ID: <20081210084607.GA2988@taygeta>), I've suggested a different approach: I'd very much prefer bash to tell me without any delay: Command not found. If this is not a typo, type "man make-it-work" for help. And then the make-it-work man page will tell you right away to run "make-it-work commandname' to locate and install the package providing fancytool. with a little practice you will go one back in history, prefix your last command with 'make-it-work ' and have fun... imho the current solution is solving a problem that doesn't really exist (pretend all software is preinstalled) and creates a new one (lag). Michal Vyskocil pointed out that such magic should at least look in /sbin and /usr/sbin and give a usefull message if the command is found there: command found in /sbin or /usr/sbin. Maybe retry as root, e.g. with 'sudo $command' -- openSUSE Feature: https://features.opensuse.org/305803

1 6

[openFate 305658] Official USB stick images
by fate_noreply＠suse.de 14 Aug '09

14 Aug '09

Feature added by: Stephan Binner <stbinner(a)novell.com> Feature #305658, revision 1, last change by Title: Official USB stick images openSUSE-11.2: New Priority Requester: Desirable Requested by: Stephan Binner (beineri) Description: It would like to see openSUSE releases with official USB images (one with KDE, one with GNOME) next to the Live-CDs. As alternative the Live-CD images could be mastered in a way that they also can boot from USB (afaik they are not able atm) together with a small app/script to install them to USB - other distributions offer that. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305658

1 49

[openFate 305318] Move gconf schemas to /usr
by fate_noreply＠suse.de 14 Aug '09

14 Aug '09

Feature added by: Vincent Untz <vuntz(a)novell.com> Feature #305318, revision 1, last change by Title: Move gconf schemas to /usr openSUSE-11.2: New Priority Requester: Desirable Requested by: Vincent Untz <vuntz(a)novell.com> Partner organization: openSUSE.org Description: We store gconf schemas in /etc/gconf. However, the schemas are not configuration files, but simply data. Therefore, we should move the schemas to /usr. Simply changing a line in /etc/gconf/2/path should make gconf work with the new location. Note that Debian already implements this. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305318

1 7