June 2011 - openSUSE Features - openSUSE Mailing Lists

[openFATE 311297] Get rid of SuSEconfig.groff
by fate_noreply＠suse.de 28 Jun '11

28 Jun '11

Feature changed by: Karl Eichwalder (keichwa) Feature #311297, revision 22 Title: Get rid of SuSEconfig.groff openSUSE Distribution: Done Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Michal Svec (msvec) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Documentation Editor: (Novell) Partner organization: openSUSE.org Description: There is no point to run that code after installation of every package (and it's not run when you use zypper or 3rd party tools anyways). Possible solutions: 1) Fix groff to respect locale settings (LC_PAPER); ideal solution. 2) Add that code to yast2 language (write things during installation and whenever the user changes it later); should be easy to do. 3) Drop SuSEconfig.groff without replacement; unclear consequences. 4) Add that code to yast2 language (write things only during installation), based on comment #1. I would vote for 1, as it's a proper solution. If not doable or not doable with a reasonable effort let's at least do 2. Discussion: #1: Thorsten Kukuk (kukuk) (2011-02-15 13:24:41) Option 1 is for various reason no option. My proposal is based on 2: YaST2 should write /etc/papersize during installation, and only there. Rewriting it later is a bad idea, since the admin could have choosen to change the default. #2: Michal Svec (msvec) (2011-02-15 13:35:25) (reply to #1) Can you elaborate why is 1 not an option? Regarding your proposal it is now changed everytime a new package is installed (unless turned off in sysconfig), so I don't think it would hurt to update it from YaST, but I am fine with both options. #3: Thorsten Kukuk (kukuk) (2011-02-15 13:38:13) (reply to #2) Read the code, the file is not changed if the administrator has modified it. #4: Michal Svec (msvec) (2011-02-15 13:43:49) (reply to #3) OK. And why is 1 not an option? #5: Thorsten Kukuk (kukuk) (2011-02-15 13:49:28) (reply to #4) You don't want to have that code in YaST2, this gives only surprises and is a support nightmare, if YaST2 sometimes changes the config and sometimes not. #6: Michal Svec (msvec) (2011-02-15 14:04:44) (reply to #5) That is clear. I wonder why we cannot go with option 1 (fix groff). #7: Thorsten Kukuk (kukuk) (2011-02-15 14:07:59) (reply to #6) Sorry, misunderstoood. We cannot fix groff because it is not broken. groff has a config file, and that should be honoured. I for example don't want letter output only because I prefer an english locale. #8: Michal Svec (msvec) (2011-02-15 14:11:18) (reply to #7) I would expect you to set LC_PAPER correctly then. But anyways, I can live with option 4. #9: Michal Vyskocil (mvyskocil) (2011-02-15 14:21:42) (reply to #3) SuSEconfig.groff in sle-11-sp1 version overwrites the /etc/papersize everytime - see bnc#644467 (https://bugzilla.novell.com/show_bug.cgi?id=644467) . The fix is easy (I assume the check_md5_and_move is in SLE-11-SP1). So in case you decided to stay with this script, this bug should be fixed. #11: Thorsten Kukuk (kukuk) (2011-05-18 10:09:45) For openSUSE: We can break with everything, so I suggest to remove the SuSEconfig.groff file completly without replacement. Background: groff does not read this file by default, you have to specify it on the command line. For SLE11 SP2 this is not an option, since we don't know if there aren't scripts using that option and expecting that the file exists. #12: Michal Vyskocil (mvyskocil) (2011-06-28 09:17:18) (reply to #11) Removed together with 1.21 update - sent to Factory by request 74706. Marked as done for openSUSE and SLE-12. Release Notes: groff: /etc/papersize No Longer Depends on sysconfig Variables Challenge: /etc/papersize no longer inherits settings from /etc/sysconfig/language when running SuSEconfig. Solution: Set /etc/papersize directly, e.g.: echo "letter" > /etc/papersize For details, see man 5 groff_font ('papersize string'). -- openSUSE Feature: https://features.opensuse.org/311297

1 0

[openFATE 311297] Get rid of SuSEconfig.groff
by fate_noreply＠suse.de 28 Jun '11

28 Jun '11

Feature changed by: Karl Eichwalder (keichwa) Feature #311297, revision 21 Title: Get rid of SuSEconfig.groff openSUSE Distribution: Done Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Michal Svec (msvec) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) + Documentation Editor: (Novell) Partner organization: openSUSE.org Description: There is no point to run that code after installation of every package (and it's not run when you use zypper or 3rd party tools anyways). Possible solutions: 1) Fix groff to respect locale settings (LC_PAPER); ideal solution. 2) Add that code to yast2 language (write things during installation and whenever the user changes it later); should be easy to do. 3) Drop SuSEconfig.groff without replacement; unclear consequences. 4) Add that code to yast2 language (write things only during installation), based on comment #1. I would vote for 1, as it's a proper solution. If not doable or not doable with a reasonable effort let's at least do 2. Discussion: #1: Thorsten Kukuk (kukuk) (2011-02-15 13:24:41) Option 1 is for various reason no option. My proposal is based on 2: YaST2 should write /etc/papersize during installation, and only there. Rewriting it later is a bad idea, since the admin could have choosen to change the default. #2: Michal Svec (msvec) (2011-02-15 13:35:25) (reply to #1) Can you elaborate why is 1 not an option? Regarding your proposal it is now changed everytime a new package is installed (unless turned off in sysconfig), so I don't think it would hurt to update it from YaST, but I am fine with both options. #3: Thorsten Kukuk (kukuk) (2011-02-15 13:38:13) (reply to #2) Read the code, the file is not changed if the administrator has modified it. #4: Michal Svec (msvec) (2011-02-15 13:43:49) (reply to #3) OK. And why is 1 not an option? #5: Thorsten Kukuk (kukuk) (2011-02-15 13:49:28) (reply to #4) You don't want to have that code in YaST2, this gives only surprises and is a support nightmare, if YaST2 sometimes changes the config and sometimes not. #6: Michal Svec (msvec) (2011-02-15 14:04:44) (reply to #5) That is clear. I wonder why we cannot go with option 1 (fix groff). #7: Thorsten Kukuk (kukuk) (2011-02-15 14:07:59) (reply to #6) Sorry, misunderstoood. We cannot fix groff because it is not broken. groff has a config file, and that should be honoured. I for example don't want letter output only because I prefer an english locale. #8: Michal Svec (msvec) (2011-02-15 14:11:18) (reply to #7) I would expect you to set LC_PAPER correctly then. But anyways, I can live with option 4. #9: Michal Vyskocil (mvyskocil) (2011-02-15 14:21:42) (reply to #3) SuSEconfig.groff in sle-11-sp1 version overwrites the /etc/papersize everytime - see bnc#644467 (https://bugzilla.novell.com/show_bug.cgi?id=644467) . The fix is easy (I assume the check_md5_and_move is in SLE-11-SP1). So in case you decided to stay with this script, this bug should be fixed. #11: Thorsten Kukuk (kukuk) (2011-05-18 10:09:45) For openSUSE: We can break with everything, so I suggest to remove the SuSEconfig.groff file completly without replacement. Background: groff does not read this file by default, you have to specify it on the command line. For SLE11 SP2 this is not an option, since we don't know if there aren't scripts using that option and expecting that the file exists. #12: Michal Vyskocil (mvyskocil) (2011-06-28 09:17:18) (reply to #11) Removed together with 1.21 update - sent to Factory by request 74706. Marked as done for openSUSE and SLE-12. + Release Notes: groff: /etc/papersize No Longer Depends on sysconfig + Variables + Challenge: + /etc/papersize no longer inherits settings from /etc/sysconfig/language + when running SuSEconfig. + Solution: + Set /etc/papersize directly, e.g.: + echo "letter" > /etc/papersize + For details, see man 5 groff_font ('papersize string'). -- openSUSE Feature: https://features.opensuse.org/311297

1 0

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

28 Jun '11

Feature changed by: Michael Andres (mlandres) Feature #308626, revision 49 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: Evaluation by project manager Priority Requester: Important Info Provider: (Novell) Info Provider: (Novell) Info Provider: (Novell) Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Engineering Manager: (Novell) Developer: (Novell) Documentation Editor: (Novell) Technical Contact: (Novell) Technical Contact: (Novell) Technical Contact: (Novell) 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. -- openSUSE Feature: https://features.opensuse.org/308626

1 0

[openFATE 311297] Get rid of SuSEconfig.groff
by fate_noreply＠suse.de 28 Jun '11

28 Jun '11

Feature changed by: Michal Vyskocil (mvyskocil) Feature #311297, revision 20 Title: Get rid of SuSEconfig.groff openSUSE Distribution: Done Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Michal Svec (msvec) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) + Partner organization: openSUSE.org Description: There is no point to run that code after installation of every package (and it's not run when you use zypper or 3rd party tools anyways). Possible solutions: 1) Fix groff to respect locale settings (LC_PAPER); ideal solution. 2) Add that code to yast2 language (write things during installation and whenever the user changes it later); should be easy to do. 3) Drop SuSEconfig.groff without replacement; unclear consequences. 4) Add that code to yast2 language (write things only during installation), based on comment #1. I would vote for 1, as it's a proper solution. If not doable or not doable with a reasonable effort let's at least do 2. Discussion: #1: Thorsten Kukuk (kukuk) (2011-02-15 13:24:41) Option 1 is for various reason no option. My proposal is based on 2: YaST2 should write /etc/papersize during installation, and only there. Rewriting it later is a bad idea, since the admin could have choosen to change the default. #2: Michal Svec (msvec) (2011-02-15 13:35:25) (reply to #1) Can you elaborate why is 1 not an option? Regarding your proposal it is now changed everytime a new package is installed (unless turned off in sysconfig), so I don't think it would hurt to update it from YaST, but I am fine with both options. #3: Thorsten Kukuk (kukuk) (2011-02-15 13:38:13) (reply to #2) Read the code, the file is not changed if the administrator has modified it. #4: Michal Svec (msvec) (2011-02-15 13:43:49) (reply to #3) OK. And why is 1 not an option? #5: Thorsten Kukuk (kukuk) (2011-02-15 13:49:28) (reply to #4) You don't want to have that code in YaST2, this gives only surprises and is a support nightmare, if YaST2 sometimes changes the config and sometimes not. #6: Michal Svec (msvec) (2011-02-15 14:04:44) (reply to #5) That is clear. I wonder why we cannot go with option 1 (fix groff). #7: Thorsten Kukuk (kukuk) (2011-02-15 14:07:59) (reply to #6) Sorry, misunderstoood. We cannot fix groff because it is not broken. groff has a config file, and that should be honoured. I for example don't want letter output only because I prefer an english locale. #8: Michal Svec (msvec) (2011-02-15 14:11:18) (reply to #7) I would expect you to set LC_PAPER correctly then. But anyways, I can live with option 4. #9: Michal Vyskocil (mvyskocil) (2011-02-15 14:21:42) (reply to #3) SuSEconfig.groff in sle-11-sp1 version overwrites the /etc/papersize everytime - see bnc#644467 (https://bugzilla.novell.com/show_bug.cgi?id=644467) . The fix is easy (I assume the check_md5_and_move is in SLE-11-SP1). So in case you decided to stay with this script, this bug should be fixed. #11: Thorsten Kukuk (kukuk) (2011-05-18 10:09:45) For openSUSE: We can break with everything, so I suggest to remove the SuSEconfig.groff file completly without replacement. Background: groff does not read this file by default, you have to specify it on the command line. For SLE11 SP2 this is not an option, since we don't know if there aren't scripts using that option and expecting that the file exists. #12: Michal Vyskocil (mvyskocil) (2011-06-28 09:17:18) (reply to #11) Removed together with 1.21 update - sent to Factory by request 74706. Marked as done for openSUSE and SLE-12. -- openSUSE Feature: https://features.opensuse.org/311297

1 0

[New: openFATE 312566] Add Iron To The repos
by fate_noreply＠suse.de 25 Jun '11

25 Jun '11

Feature added by: Narayansamy S (vazhavandan) Feature #312566, revision 1 Title: Add Iron To The repos openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Narayansamy S (vazhavandan) Partner organization: openSUSE.org Description: Add Iron To The repos This seems to be a promising browser based on chromium source Kindly consider adding it to opensuse repos Iron removes all the questionable features from chrome Ref:- http://www.srware.net/en/software_srware_iron_chrome_vs_iron.php Business case (Partner benefit): openSUSE.org: I read about tools, which try to anonymize Chrome. Why not use these? Right, there are tools, which try to do the same than Iron. But these don't work with the sourcecode and so they only provide a limited control. E.g. they can't disbale functions like th URL-Tracker. Can i really check that Iron doesn't submit any private data, how you say? Yes, you can. There are tools like Wireshark, which scan the whole network-traffic. We could not recognize any obvious activity. But you can proof this by yourself. PS: We also disabled the DNS-Precaching by default, because this could perhaps used by spammers (see this Link) -- openSUSE Feature: https://features.opensuse.org/312566

1 1

[New: openFATE 312565] Add Iron To The repos
by fate_noreply＠suse.de 25 Jun '11

25 Jun '11

Feature added by: Narayansamy S (vazhavandan) Feature #312565, revision 1 Title: Add Iron To The repos openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Narayansamy S (vazhavandan) Partner organization: openSUSE.org Description: Add Iron To The repos This seems to be a promising browser based on chromium source Kindly consider adding it to opensuse repos Iron removes all the questionable features from chrome Ref:- http://www.srware.net/en/software_srware_iron_chrome_vs_iron.php Business case (Partner benefit): openSUSE.org: I read about tools, which try to anonymize Chrome. Why not use these? Right, there are tools, which try to do the same than Iron. But these don't work with the sourcecode and so they only provide a limited control. E.g. they can't disbale functions like th URL-Tracker. Can i really check that Iron doesn't submit any private data, how you say? Yes, you can. There are tools like Wireshark, which scan the whole network-traffic. We could not recognize any obvious activity. But you can proof this by yourself. PS: We also disabled the DNS-Precaching by default, because this could perhaps used by spammers (see this Link) -- openSUSE Feature: https://features.opensuse.org/312565

1 1

[New: openFATE 312564] Add Iron To The repos
by fate_noreply＠suse.de 25 Jun '11

25 Jun '11

Feature added by: Narayansamy S (vazhavandan) Feature #312564, revision 1 Title: Add Iron To The repos openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Narayansamy S (vazhavandan) Partner organization: openSUSE.org Description: Add Iron To The repos This seems to be a promising browser based on chromium source Kindly consider adding it to opensuse repos Iron removes all the questionable features from chrome Ref:- http://www.srware.net/en/software_srware_iron_chrome_vs_iron.php Business case (Partner benefit): openSUSE.org: I read about tools, which try to anonymize Chrome. Why not use these? Right, there are tools, which try to do the same than Iron. But these don't work with the sourcecode and so they only provide a limited control. E.g. they can't disbale functions like th URL-Tracker. Can i really check that Iron doesn't submit any private data, how you say? Yes, you can. There are tools like Wireshark, which scan the whole network-traffic. We could not recognize any obvious activity. But you can proof this by yourself. PS: We also disabled the DNS-Precaching by default, because this could perhaps used by spammers (see this Link) -- openSUSE Feature: https://features.opensuse.org/312564

1 1

[New: openFATE 312563] Add Iron To The repos
by fate_noreply＠suse.de 25 Jun '11

25 Jun '11

Feature added by: Narayansamy S (vazhavandan) Feature #312563, revision 1 Title: Add Iron To The repos openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Narayansamy S (vazhavandan) Partner organization: openSUSE.org Description: Add Iron To The repos This seems to be a promising browser based on chromium source Kindly consider adding it to opensuse repos Iron removes all the questionable features from chrome Ref:- http://www.srware.net/en/software_srware_iron_chrome_vs_iron.php Business case (Partner benefit): openSUSE.org: I read about tools, which try to anonymize Chrome. Why not use these? Right, there are tools, which try to do the same than Iron. But these don't work with the sourcecode and so they only provide a limited control. E.g. they can't disbale functions like th URL-Tracker. Can i really check that Iron doesn't submit any private data, how you say? Yes, you can. There are tools like Wireshark, which scan the whole network-traffic. We could not recognize any obvious activity. But you can proof this by yourself. PS: We also disabled the DNS-Precaching by default, because this could perhaps used by spammers (see this Link) -- openSUSE Feature: https://features.opensuse.org/312563

1 1

[New: openFATE 312562] Add Iron To The repos
by fate_noreply＠suse.de 25 Jun '11

25 Jun '11

Feature added by: Narayansamy S (vazhavandan) Feature #312562, revision 1 Title: Add Iron To The repos openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Narayansamy S (vazhavandan) Partner organization: openSUSE.org Description: Add Iron To The repos This seems to be a promising browser based on chromium source Kindly consider adding it to opensuse repos Iron removes all the questionable features from chrome Ref:- http://www.srware.net/en/software_srware_iron_chrome_vs_iron.php -- openSUSE Feature: https://features.opensuse.org/312562

1 1

[New: openFATE 312561] Add Iron To The repos
by fate_noreply＠suse.de 25 Jun '11

25 Jun '11

Feature added by: Narayansamy S (vazhavandan) Feature #312561, revision 1 Title: Add Iron To The repos openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Narayansamy S (vazhavandan) Partner organization: openSUSE.org Description: Add Iron To The repos This seems to be a promising browser based on chromium source Kindly consider adding it to opensuse repos Iron removes all the questionable features from chrome Ref:- http://www.srware.net/en/software_srware_iron_chrome_vs_iron.php -- openSUSE Feature: https://features.opensuse.org/312561

1 1