December 2008 - openSUSE Features - openSUSE Mailing Lists

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

[openFate 305149] [Feature-request] Yast Expert Partitioner: should not require mounting "/" root partition
by fate_noreply＠suse.de 14 Aug '09

14 Aug '09

Feature added by: Arvin Schnell <aschnell(a)novell.com> Feature #305149, revision 1, last change by Title: [Feature-request] Yast Expert Partitioner: should not require mounting "/" root partition openSUSE-11.2: New Priority Requester: Desirable Requested by: Alexey Eremenko <al4321(a)gmail.com> Partner organization: openSUSE.org Description: Hi All ! Since openSUSE 11.1 will have brand new expert partitioner, I would like to request the ability to use SUSE's partitioner for partition hard disks for other operating systems. Currently it is not possible, because SUSE requires mounting "/" root partition. In some cases I need to install third-party OSes before I install openSUSE, so I want to use SUSE flexible partitioner to partition and format the hard disk, then install the other OSes and only in the end I want to install openSUSE. -Alexey Discussion: #1: Arvin Schnell <aschnell(a)novell.com> (2008-08-04 08:41:18) So in a nutshell you want to use the partitioner as a separate program (started from the DVD) without the other installation features like package managment. Right? #2: Arvin Schnell <aschnell(a)novell.com> (2008-08-05 12:11:02) Not mounting "/" during installation will certainly lead to a failure so I hesitate to remove the check. But we could add a special mode with disabled checks. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305149

1 9