September 2011 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 312790] Samba - creator
by fate_noreply＠suse.de 21 Sep '11

21 Sep '11

Feature added by: Zajączkowski Marcin (edved) Feature #312790, revision 1 Title: Samba - creator openFATE: Unconfirmed Priority Requester: Important Requested by: Zajączkowski Marcin (edved) Partner organization: openSUSE.org Description: Hello. I have such a proposal to improve OpenSUSE. It's about the samba module and its creator. At the moment, only the PDC has the option. At this point it is hard to set the WORKGROUP group Samba to be seen in the home network and printer and make available resources. I think that could be improved configurator and setup wizard so that normal user can run the network on its own warehouse OpenSUSE. I am from his experience had many problems with this to properly configure so that was visible in the network and the tutorials are very helpful. For me it was easier to just such a possibility to be able to run your own Samba server on OpenSUSE data. Greetings to all -- openSUSE Feature: https://features.opensuse.org/312790

1 1

[openFATE 308626] Snapshot/Rollback interface to the ZYpp stack
by fate_noreply＠suse.de 21 Sep '11

21 Sep '11

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #308626, revision 55 Title: Snapshot/Rollback interface to the ZYpp stack openSUSE-11.3: Rejected by Gerald Pfeifer (geraldpfeifer) reject date: 2010-11-17 00:53:34 reject reason: openSUSE 11.3 has been released months ago. Priority Requester: Mandatory openSUSE-11.4: New Priority Requester: Important openSUSE 12.1: Done Priority Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: Ability for libzypp and exposed via zypper to snapshot either automatically or explicitly the system before commit happens, plus an interface to revert the system. The interface should be generic and allow for different possible implementations which should be offered depending on the context: * btrfs based if /root is btrfs * simple based on package list before commit, plus package history and current package list to determine diff last transaction * two root partitions, where the interface would clone root filesystem before commit and switch them at rollback time. The feature includes the concept, and a working implementation with one or more of the strategies described before. References: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs http://dev.chromium.org/chromium-os/chromiumos-design-docs/filesystem-autou… http://wiki.rpath.com/wiki/Conary:conary_rollback packages: libzypp snapper zypper Relations: - grub1 patch for btrfs boot (url: ) Documentation Impact: Requires description of the functionality in zypper options Test Case: zypper install foo bar zypper rollback System should be as before the installation. Corner cases are not important. Use Case: Administrator installs a bunch of updates, which leaves the system in an an unworkable state. He types zypper rollback to undo the changes. Business case (Partner benefit): openSUSE.org: * Customer asked about snapshoting during our last meeting. * Feature parity with Solaris which is implementing package rollback based on ZFS * RHEL goes the same route, announced btrfs rollbacks in yum * We can do better, offering something more flexible and not btrfs dependent to support different scenarios: SLES (btrfs), Appliances (dual system partition), openSUSE (simple package list) Discussion: #1: Federico Lucifredi (flucifredi) (2010-03-05 07:29:41) PM: Important for 11.3. (sorry, on web client). #3: Joachim Werner (joachimwerner) (2010-04-28 18:10:50) I have SLEPOS-specific use cases for this feature, too. IBM implemented a similar rollback feature in IRES2, based on tripwire AFAIK. Some techical considerations we need to understand: Rolling back the right things What customers really want is not a dumb rollback of everything on the system to the old state, but just the changes done by the update. So it may be necessary to make sure the snapshot only applies to the configuration directories (usually /etc) and the code directories (/usr) affected by the update, but not things like logfiles (which should be continuous) or application data (nobody wants to get their database files rolled back by accident, or data a user has saved in /home/username in the meantime). Another potential issue with some applications is that they can be in an inconsistent state if they aren't stopped during a snapshot. This is a more generic problem with snapshots as such. For this Windows has mechanisms to inform an application that it's going to do a shadow copy now. In Linux there is no single interface to trigger that, although some databases and other applications have there own way of switching into a read-only snapshotting-safe mode. So, this is all doable, but just applying a system-wide snapshot seems to be too simple. Maybe we can just copy what Red Hat is doing here (if it's good enough). Red Hat has finished this feature in Fedora, and it's probably going to be in RHEL6 at some point, too. https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs (https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs) contains a few considerations on this. Avoiding situations that can't be recovered zypper rollback sounds like a good plan at first, but it is not in all cases. If you apply an update that breaks the system, this could mean that a kernel update went wrong and you can't even boot beyond a certain stage. So there needs to be a way of entering the recovery from the earliest possible level, the boot prompt. There needs to be an option to boot into the snapshotted system, and from there eliminate the changes made after the snapshot and declare the snapshot to be the current state. For the worst case (a broken grub package or so kills the bootloader configuration) we need to have a recovery workflow (from CD or so) that can still bring back the old working state. Do one thing right, not three things that solve the same problem If we decide to go down the btrfs route (which I like) we should not also solve the same problem using several other approaches. Why use dual system partitions if you can have snapshots? #7: Duncan Mac-Vicar (dmacvicar) (2010-10-21 10:43:26) I would like to clarify some issues: For rollbacks, it would be the ideal situation to have the root filesystem completely under btrfs, otherwise you run into the problem that kernels are not affected by the rollback and this increases complexity. * a) For this we need to boot with btrfs. Matthias told me we should ignore this problem because under EFI you have to put the kernel under /efi in a FAT partition, but my own research tells me that what is in FAT /efi is the grub EFI program, and therefore the kernel could be in btrfs if the grub EFI program supports finding the kernel with btrfs. Can anyone confirm this? * b) For booting with btrfs we need either grub2, or syslinux or a patch for grub1 (added as a reference to the feature). Which route will we follow here? Do we have anyone empowered to make this decision soon? * c) if b) is solved with grub1 patch I suggest we open a feature entry to track that one. #9: Olaf Kirch (okir) (2010-10-22 12:56:49) (reply to #7) My preferred solution would be to enable grub1 for btrfs; it seems to pose the least risk - assuming the btrfs code is stable enough. (BTW either my fate client is too old, or the link you added is broken). #13: Gerald Pfeifer (geraldpfeifer) (2010-11-17 00:53:01) One further idea that came up is adding a bootloader entry (or several) that, when chosen, would revert the system into an old state as represented/described by that entry and boot into it. This is more involved than the more basic scenarios here and might be suitable for another, linked FATE? #15: Federico Lucifredi (flucifredi) (2011-03-25 21:02:37) (reply to #13) I like that. If at all possible, we should provide a boot item into the previous snapshot. #14: Jörg Schmela (herz-von-hessen) (2011-02-25 18:42:40) therefore my full Consent #18: Michael Andres (mlandres) (2011-06-28 12:32:03) libzypp ability to execute pre/post commit plugin scripts is done (see http://doc.opensuse.org/projects/libzypp/HEAD/plugin-commit.html). Arvin is about to provide the snapper plugin, which actually takes the snapshots. #19: Arvin Schnell (aschnell) (2011-06-29 10:12:38) (reply to #18) I have now added a python-plugin for zypp that calls snapper pre and post to commits. I was told that this is all we provide for SLE11 SP2 so I'm setting this feature to Done although many more ideas are mentioned here. + #20: Duncan Mac-Vicar (dmacvicar) (2011-09-21 13:33:56) + State was wrong. ZYpp does not support this on 11.4. Set it to done on + 12.1. Coolo, can you reject for 11.4? -- openSUSE Feature: https://features.opensuse.org/308626

1 0

[openFATE 308626] Snapshot/Rollback interface to the ZYpp stack
by fate_noreply＠suse.de 21 Sep '11

21 Sep '11

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #308626, revision 54 Title: Snapshot/Rollback interface to the ZYpp stack openSUSE-11.3: Rejected by Gerald Pfeifer (geraldpfeifer) reject date: 2010-11-17 00:53:34 reject reason: openSUSE 11.3 has been released months ago. Priority Requester: Mandatory - openSUSE-11.4: Done + openSUSE-11.4: New Priority Requester: Important + openSUSE 12.1: Done + Priority + Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: Ability for libzypp and exposed via zypper to snapshot either automatically or explicitly the system before commit happens, plus an interface to revert the system. The interface should be generic and allow for different possible implementations which should be offered depending on the context: * btrfs based if /root is btrfs * simple based on package list before commit, plus package history and current package list to determine diff last transaction * two root partitions, where the interface would clone root filesystem before commit and switch them at rollback time. The feature includes the concept, and a working implementation with one or more of the strategies described before. References: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs http://dev.chromium.org/chromium-os/chromiumos-design-docs/filesystem-autou… http://wiki.rpath.com/wiki/Conary:conary_rollback packages: libzypp snapper zypper Relations: - grub1 patch for btrfs boot (url: ) Documentation Impact: Requires description of the functionality in zypper options Test Case: zypper install foo bar zypper rollback System should be as before the installation. Corner cases are not important. Use Case: Administrator installs a bunch of updates, which leaves the system in an an unworkable state. He types zypper rollback to undo the changes. Business case (Partner benefit): openSUSE.org: * Customer asked about snapshoting during our last meeting. * Feature parity with Solaris which is implementing package rollback based on ZFS * RHEL goes the same route, announced btrfs rollbacks in yum * We can do better, offering something more flexible and not btrfs dependent to support different scenarios: SLES (btrfs), Appliances (dual system partition), openSUSE (simple package list) Discussion: #1: Federico Lucifredi (flucifredi) (2010-03-05 07:29:41) PM: Important for 11.3. (sorry, on web client). #3: Joachim Werner (joachimwerner) (2010-04-28 18:10:50) I have SLEPOS-specific use cases for this feature, too. IBM implemented a similar rollback feature in IRES2, based on tripwire AFAIK. Some techical considerations we need to understand: Rolling back the right things What customers really want is not a dumb rollback of everything on the system to the old state, but just the changes done by the update. So it may be necessary to make sure the snapshot only applies to the configuration directories (usually /etc) and the code directories (/usr) affected by the update, but not things like logfiles (which should be continuous) or application data (nobody wants to get their database files rolled back by accident, or data a user has saved in /home/username in the meantime). Another potential issue with some applications is that they can be in an inconsistent state if they aren't stopped during a snapshot. This is a more generic problem with snapshots as such. For this Windows has mechanisms to inform an application that it's going to do a shadow copy now. In Linux there is no single interface to trigger that, although some databases and other applications have there own way of switching into a read-only snapshotting-safe mode. So, this is all doable, but just applying a system-wide snapshot seems to be too simple. Maybe we can just copy what Red Hat is doing here (if it's good enough). Red Hat has finished this feature in Fedora, and it's probably going to be in RHEL6 at some point, too. https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs (https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs) contains a few considerations on this. Avoiding situations that can't be recovered zypper rollback sounds like a good plan at first, but it is not in all cases. If you apply an update that breaks the system, this could mean that a kernel update went wrong and you can't even boot beyond a certain stage. So there needs to be a way of entering the recovery from the earliest possible level, the boot prompt. There needs to be an option to boot into the snapshotted system, and from there eliminate the changes made after the snapshot and declare the snapshot to be the current state. For the worst case (a broken grub package or so kills the bootloader configuration) we need to have a recovery workflow (from CD or so) that can still bring back the old working state. Do one thing right, not three things that solve the same problem If we decide to go down the btrfs route (which I like) we should not also solve the same problem using several other approaches. Why use dual system partitions if you can have snapshots? #7: Duncan Mac-Vicar (dmacvicar) (2010-10-21 10:43:26) I would like to clarify some issues: For rollbacks, it would be the ideal situation to have the root filesystem completely under btrfs, otherwise you run into the problem that kernels are not affected by the rollback and this increases complexity. * a) For this we need to boot with btrfs. Matthias told me we should ignore this problem because under EFI you have to put the kernel under /efi in a FAT partition, but my own research tells me that what is in FAT /efi is the grub EFI program, and therefore the kernel could be in btrfs if the grub EFI program supports finding the kernel with btrfs. Can anyone confirm this? * b) For booting with btrfs we need either grub2, or syslinux or a patch for grub1 (added as a reference to the feature). Which route will we follow here? Do we have anyone empowered to make this decision soon? * c) if b) is solved with grub1 patch I suggest we open a feature entry to track that one. #9: Olaf Kirch (okir) (2010-10-22 12:56:49) (reply to #7) My preferred solution would be to enable grub1 for btrfs; it seems to pose the least risk - assuming the btrfs code is stable enough. (BTW either my fate client is too old, or the link you added is broken). #13: Gerald Pfeifer (geraldpfeifer) (2010-11-17 00:53:01) One further idea that came up is adding a bootloader entry (or several) that, when chosen, would revert the system into an old state as represented/described by that entry and boot into it. This is more involved than the more basic scenarios here and might be suitable for another, linked FATE? #15: Federico Lucifredi (flucifredi) (2011-03-25 21:02:37) (reply to #13) I like that. If at all possible, we should provide a boot item into the previous snapshot. #14: Jörg Schmela (herz-von-hessen) (2011-02-25 18:42:40) therefore my full Consent #18: Michael Andres (mlandres) (2011-06-28 12:32:03) libzypp ability to execute pre/post commit plugin scripts is done (see http://doc.opensuse.org/projects/libzypp/HEAD/plugin-commit.html). Arvin is about to provide the snapper plugin, which actually takes the snapshots. #19: Arvin Schnell (aschnell) (2011-06-29 10:12:38) (reply to #18) I have now added a python-plugin for zypp that calls snapper pre and post to commits. I was told that this is all we provide for SLE11 SP2 so I'm setting this feature to Done although many more ideas are mentioned here. -- openSUSE Feature: https://features.opensuse.org/308626

1 0

[openFATE 72] Thank good brainshare is over
by fate_noreply＠suse.de 21 Sep '11

21 Sep '11

Feature changed by: Thomas Schmidt (digitaltomm) Feature #72, revision 242 Title: Thank good brainshare is over Requested by: Thomas Schmidt (digitaltomm) Partner organization: openSUSE.org Description: We are all tired. Feet are hurtingXXX Rejected: Was just a test dummy during feature tool training. dbxml updated to 2.2.13 testing partner notification + new keeper testing partner notification CC testing testing new notification system test References: http://www.pfeifer.com/gerald/gerald.jerus.png Relations: - 55555 (novell/bugzilla/id: 55555) https://bugzilla.novell.com/show_bug.cgi?id=55555 - Test Case (novell/testopia/case: 12345) https://bugzilla.novell.com/tr_show_case.cgi?case_id=12345 Documentation Impact: tremendous Test Case: foo bar external ID: 123 Discussion: #1: Inttools Team (inttools) (2005-11-02 16:06:21) Remove some comments, test utf8 with kate: ???????????? #2: Gerald Pfeifer (geraldpfeifer) (2007-10-25 09:51:22) (reply to #1) Dudle. #17: Andre Duffeck (aduffeck) (2008-05-20 06:59:31) (reply to #2) test #25: Thomas Schmidt (digitaltomm) (2008-07-17 13:37:50) (reply to #17) test +šščřžčřýřáýáí #51: Michael Löffler (michl19) (2009-03-13 14:02:34) (reply to #1) blabla #4: Andre Duffeck (aduffeck) (2007-10-25 14:17:35) webfate test #5: Gerald Pfeifer (geraldpfeifer) (2007-10-26 14:58:39) blub #6: Stephan Kulow (coolo) (2007-11-19 18:20:44) testing if this crashes too #7: Stephan Kulow (coolo) (2007-11-19 18:21:17) (reply to #6) hmm, this works #8: Andre Duffeck (aduffeck) (2008-01-07 19:10:09) test #9: Thomas Schmidt (digitaltomm) (2008-01-07 19:13:11) test #10: Andre Duffeck (aduffeck) (2008-01-07 19:43:19) test #11: Sukanta Dash (sukantadash) (2008-01-30 10:18:52) Test entry added as advised by Gerald. #12: Stephan Kulow (coolo) (2008-02-13 12:45:46) please do not use a product we're currently looking at for such tests #13: Thomas Schmidt (digitaltomm) (2008-02-20 16:14:01) test #14: Christopher Hofmann (cwh) (2008-02-21 19:32:56) Hallo, Mary Lou #15: Matthias Eckermann (mge1512) (2008-02-22 15:26:03) Brainshare will restart soon, ... #16: Andre Duffeck (aduffeck) (2008-03-05 13:20:23) blubb #19: Andre Duffeck (aduffeck) (2008-05-23 11:35:26) test #20: Gerald Pfeifer (geraldpfeifer) (2008-05-24 12:55:27) (reply to #19) Tst. #32: Juergen Weigert (jnweiger) (2008-07-23 11:31:38) (reply to #19) mal dere kleine crash zwischendurch von JW. #33: Juergen Weigert (jnweiger) (2008-07-23 11:47:57) (reply to #32) der war einfach. nochmal crash mit kdebugdialog --fullmode #41: Juergen Weigert (jnweiger) (2008-07-23 15:04:45) (reply to #33) so, und nun nochmal mit [x] enable cache .... #42: Juergen Weigert (jnweiger) (2008-07-23 15:06:09) (reply to #41) viel besser jetzt! #21: Christopher Hofmann (cwh) (2008-06-04 13:27:58) linkszwodreivier #22: Andre Duffeck (aduffeck) (2008-06-11 07:37:50) test #23: Andre Duffeck (aduffeck) (2008-06-11 07:38:18) testzwei #24: Thomas Schmidt (digitaltomm) (2008-06-11 12:15:59) Added attachment (patch_information.xml) #27: Andre Duffeck (aduffeck) (2008-07-17 16:36:20) test #30: Thomas Schmidt (digitaltomm) (2008-07-21 20:09:23) tuut #31: Andre Duffeck (aduffeck) (2008-07-23 11:22:26) test #34: Juergen Weigert (jnweiger) (2008-07-23 14:09:20) noch ein crash! #35: Andre Duffeck (aduffeck) (2008-07-23 14:11:00) blubb #36: Juergen Weigert (jnweiger) (2008-07-23 14:13:25) ghjhghj #37: Juergen Weigert (jnweiger) (2008-07-23 14:14:03) dsfgdfgfhh #38: Andre Duffeck (aduffeck) (2008-07-23 14:15:48) testcrash #39: Andre Duffeck (aduffeck) (2008-07-23 14:20:13) ttttt #40: Andre Duffeck (aduffeck) (2008-07-23 14:28:26) asdf #43: Andre Duffeck (aduffeck) (2008-07-30 07:29:33) test #44: Thomas Roelz (tomout) (2008-07-31 18:17:36) sdgdfhdfhd #45: Gerald Pfeifer (geraldpfeifer) (2008-08-15 15:36:13) (reply to #44) d #46: Andre Duffeck (aduffeck) (2008-08-26 13:56:51) test #47: Andre Duffeck (aduffeck) (2008-11-28 18:18:55) bla #49: Gerald Pfeifer (geraldpfeifer) (2009-02-09 17:16:42) (reply to #47) Nein! + #54: Thomas Schmidt (digitaltomm) (2011-09-21 12:42:04) (reply to #49) + Doch #50: Andre Duffeck (aduffeck) (2009-02-25 09:11:25) Changed attachment patch (patch_information.xml) #52: Thomas Schmidt (digitaltomm) (2010-08-11 14:43:33) test #53: Andre Duffeck (aduffeck) (2011-01-31 11:11:33) test -- openSUSE Feature: https://features.opensuse.org/72

1 0

[New: openFATE 311316] Improve syslog daemon switch and SystemV & SystemD integration
by fate_noreply＠suse.de 20 Sep '11

20 Sep '11

Feature added by: Marius Tomaschewski (mtomaschewski) Feature #311316, revision 1 Title: Improve syslog daemon switch and SystemV & SystemD integration openSUSE.org: New Priority Requester: Important Requested by: Marius Tomaschewski (mtomaschewski) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Engineering Manager: (Novell) Developer: (Novell) Developer: (Novell) Technical Contact: (Novell) Partner organization: openSUSE.org Description: Currently all syslog daemons (syslogd,rsyslog,syslog-ng) are started via /etc/init.d/syslog script and switched using the SYSLOG_DAEMON variable in /etc/sysconfig/syslog . This provides a single, daemon independent, interface to the syslog service for * log rotation ( /etc/logrotate.d files just call /etc/init.d/syslog reload ), * allows programs to request additional $chroot/dev/log sockets by adding a SYSLOGD_ADDITIONAL_SOCKET<service name> variable * start klogd when the daemon needs it or skip when the syslog daemon has built-in klogd The /etc/init.d/syslog script handles the above cases, even syslogd needs e.g. the additional sockets via -a parameter while rsyslog & syslog-ng in the config file (denerated & included in main config). Because there are no conflicts between the daemon packages, this even allows the use a different daemon to handle local machine logs and a different to implement a log-host (with additional init script), when the user wishes to do it. On openSUSE-11.4, systemd that may optionally be used instead of sysvinit / upstart . We've adopted the syslog-daemons (https://bugzilla.novell.com/show_bug.cgi?id=656104) to support systemd socket activation [systemd.socket(5)] allowing to restart and switch between daemons without to close the sockets. We currently do not use a systemd native systemd.service(5) file, because we'd have to start it via /etc/init.d/syslog due to features listed above anyway and systemd exposes the /etc/init.d/syslog script as LSB syslog.service already. This request is to rethink all the mechanisms and improve the current syslog packages. It includes splits/changes to the syslog packages, adoption of all packages that request additional chroot sockets, adoption of yast2 modules that may configure the syslog service and systemd to provide all the functionality required to implement the systemd socket activation support in Type=forking systemd.service(5) mode as shared library and a devel package (reported as https://bugzilla.novell.com/show_bug.cgi?id=656259). I consider this library as mandatory for any future changes regarding systemd socket activation, because at the moment all the required code is included inline in (at least) 3 daemons + startproc and we have to get rid of this as soon as possible. Relations: - Use systemd session manager instead of SysVinit/upstart (feature/id: 310327) - Init Systems: To System V, systemd, or upstart? (feature/id: 310421) - syslog daemon -- socket activation / systemd integration (novell/bugzilla/id: 656104) https://bugzilla.novell.com/show_bug.cgi?id=656104 - systemd does not provide headers / lib usable in daemons (novell/bugzilla/id: 656259) https://bugzilla.novell.com/show_bug.cgi?id=656259 -- openSUSE Feature: https://features.opensuse.org/311316

1 5

[New: openFATE 312809] Build a wirless lan access point
by fate_noreply＠suse.de 20 Sep '11

20 Sep '11

Feature added by: Juergen Weigert (jnweiger) Feature #312809, revision 1 Title: Build a wirless lan access point openSUSE.org: Unconfirmed Priority Requester: Important Requested by: Juergen Weigert (jnweiger) Partner organization: openSUSE.org Description: Use hostap mode to turn a laptop into a full featured access point. (not just ad-hoc). Find out which hardware is suitable. I have an USB-Wlan-dongle with rt73 chipset, whichis reported to support AP-mode. -- openSUSE Feature: https://features.opensuse.org/312809

1 0

[New: openFATE 312808] Build a wirless lan access point
by fate_noreply＠suse.de 20 Sep '11

20 Sep '11

Feature added by: Juergen Weigert (jnweiger) Feature #312808, revision 1 Title: Build a wirless lan access point openSUSE.org: Unconfirmed Priority Requester: Important Requested by: Juergen Weigert (jnweiger) Partner organization: openSUSE.org Description: Use hostap mode to turn a laptop into a full featured access point. (not just ad-hoc). Find out which hardware is suitable. I have an USB-Wlan-dongle with rt73 chipset, whichis reported to support AP-mode. -- openSUSE Feature: https://features.opensuse.org/312808

1 0

[New: openFATE 309274] zypper: option to automatically select "keep obsolete xyz" answer
by fate_noreply＠suse.de 20 Sep '11

20 Sep '11

Feature added by: Michal Marek (michal-m) Feature #309274, revision 1 Title: zypper: option to automatically select "keep obsolete xyz" answer openSUSE-11.3: New Priority Requester: Desirable Requested by: Michal Marek (michal-m) Description: When tracking Factory, it often happens that there is a new library A, but package B built against this new library is not available yet. zypper dup usually offers to either delete B, switch A and B from x86_64 to i586 or to not update A. I almost always chose not to update A in such cases. I want new packages, but not at any cost :-). So I'd like an option like zypper dup --fallback-keep-obsolete that would answer such questions automatically and let me review only "real" problems. -- openSUSE Feature: https://features.opensuse.org/309274

1 5

[New: openFATE 308389] Zypper - ingore All
by fate_noreply＠suse.de 20 Sep '11

20 Sep '11

Feature added by: Josef Reidinger (jreidinger) Feature #308389, revision 1 Title: Zypper - ingore All openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Josef Reidinger (jreidinger) Partner organization: openSUSE.org Description: I think it would nice to have use same answer for similar questions. Like if repository is not accessible or recently synced, then ignore all problems instead of individual answers. Use Case: For example if factory is synced and package is no longer available, then use ignore all and after run refresh and repair via verify problems. Business case (Partner benefit): openSUSE.org: If update contain many packages and user testing factory, then manual ignoring problems takes too much time and decrease time to testing. -- openSUSE Feature: https://features.opensuse.org/308389

1 2

[New: openFATE 312503] tuxguitar
by fate_noreply＠suse.de 20 Sep '11

20 Sep '11

Feature added by: Christopher Kappe (Nox_Diesque) Feature #312503, revision 1 Title: tuxguitar Package Wishlist: Unconfirmed Priority Requester: Desirable Requested by: Christopher Kappe (nox_diesque) Partner organization: openSUSE.org Description: Since openSUSE 11.4 the program "tuxguitar" (http://tuxguitar.herac.com.ar) isn't available any more - not even in a "home" repository. I'd very much appreciate if it was to be found anywhere ready to install. Business case (Partner benefit): openSUSE.org: It's such a popular software! If you don't want to buy the commercial "GuitarPro", then this is your choice. Many many guitar players and other musicians use it. It's available for Windows and Mac and to be honest: I don't know any Linux distribution besides suse 11.4 that doesn't have it in its repos (Debian, Ubuntu, Fedora, etc.). -- openSUSE Feature: https://features.opensuse.org/312503

1 6