October 2012 - openSUSE Features - openSUSE Mailing Lists

[openFATE 307378] YaST2 Partitioner should detect external partition type changes and update fstab
by fate_noreply＠suse.de 09 Oct '12

09 Oct '12

Feature added by: Alexander shaduri (alex_sh) Feature #307378, revision 1 Title: YaST2 Partitioner should detect external partition type changes and update fstab openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Alexander shaduri (alex_sh) Description: If partition was changed from fat32 to ntfs externally, there's no way to specify that in YaST Partitioner. Initial partition layout: sda1: fat32 (empty), sda2: ext3 linux /, etc... The first thing I did was install openSUSE 11.1. YaST correctly identified fat32 partition and wrote the respective line to fstab. Then, I installed Vista on sda1. The problem with Vista is that it won't install to fat32, it needs ntfs. So, it converted sda1 to ntfs and installed ok. Now, the problem is that fstab in openSUSE still contained "vfat" as filesystem type. KDE4 wouldn't open in from Konqueror, etc... I tried to make YaST re-learn the type of sda1, so it would write the correct line to fstab, since I didn't remember what are the openSUSE-default options for ntfs-3g. Unfortunately, there doesn't seem to be a way to do this. I think this will affect lots of people who, for example, had XP and decided to switch to Vista. Also, since openSUSE doesn't allow formatting to ntfs, this will also affect all the people who install Linux on a clean disk (reserving a space for Windows with fat32 partition), and then install XP or Vista, converting the filesystem to ntfs in the process. Steps to Reproduce: 1. Install openSUSE on a clean disk, making the first partition fat32. 2. Convert the first partition to ntfs via third-party tool. 3. Try to use the drive from openSUSE as an average "joe the user". I filed it as a bug https://bugzilla.novell.com/show_bug.cgi?id=524784 and was told that this was a feature request - "The partitioner does assume that the enties in fstab are correct and does not try to fix them. Changing this behaviour requires a feature request." So, here it is. -- openSUSE Feature: https://features.opensuse.org/307378

1 8

[New: openFATE 309234] Make expert partitioner more intuitive
by fate_noreply＠suse.de 09 Oct '12

09 Oct '12

Feature added by: Marco Poletti (poletti_marco) Feature #309234, revision 1 Title: Make expert partitioner more intuitive openFATE: Unconfirmed Priority Requester: Important Requested by: Marco Poletti (poletti_marco) Description: I propose to restructure the expert partitioner, my suggestions are these: 1) I think the "Overview" and "Used devices" tabs associated with each drive are out of place, I think they should become the property window of the drive, that can be accessed by right-clicking the drive and selecting the new item "Properties" or by selecting it and clicking the new button "Properties" in the "Hard disk" view, or by right-clicking an empty space in the drive's own view and selecting Properties, or by clicking the new button "Drive properties" in the drive's own view. 2) About partitions, I'd completely remove them from the tree and move those informations to the partition's Properties window, accessible from right-clicking the partition and selecting the new item "Properties" or selecting the partition and clicking the new "Properties" button, both in the drive view and in the "Hard disks" view. 3) In computers with not too many HDs, say max 6, I'd show all the graphical bars in the "Hard disk" view. Test Case: Use Case: -- openSUSE Feature: https://features.opensuse.org/309234

1 5

[New: openFATE 314530] add submit request groups
by fate_noreply＠suse.de 08 Oct '12

08 Oct '12

Feature added by: Bernhard Wiedemann (bmwiedemann) Feature #314530, revision 1 Title: add submit request groups Buildservice: Unconfirmed Priority Requester: Mandatory Requested by: Bernhard Wiedemann (bmwiedemann) Partner organization: openSUSE.org Description: In many cases (usually with GNOME&KDE) when doing submit requests of multiple packages, it happens that the new version of A depends on the new version of B and the new version of B depends on the new version of A. This will break building in the target repo unless all packages are submitted at the same time (which often does not happen because of necessary reviews) This can be solved by adding a Submit-Request-Group feature, where a number of packages are submitted as a group. Individual SRs should be created for each package for review. And it should be possible to supersede SRs. Packages must only be copied to the target repo once all SRs in the group are approved. -- openSUSE Feature: https://features.opensuse.org/314530

1 0

[New: openFATE 308940] zypper: provide ways to show reason for install
by fate_noreply＠suse.de 07 Oct '12

07 Oct '12

Feature added by: Jan Engelhardt (jengelh) Feature #308940, revision 1 Title: zypper: provide ways to show reason for install openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Jan Engelhardt (jengelh) Partner organization: openSUSE.org Description: The smart package manager had a --explain option with which one could have the pm dump reasons for a package being installed. The same would be desirable to have for zypper, as there are sometimes strange updates. Use Case: # zypper up The following NEW packages are going to be installed: bundle-lang-gnome-ar glib2-lang gnome-keyring-lang gnome-vfs2-lang gtk2-lang With an --explain switch, there could be: glib2-lang (required by updated glib2-2.22.4-0.1.1) Business case (Partner benefit): openSUSE.org: https://bugzilla.novell.com/show_bug.cgi?id=576623 -- openSUSE Feature: https://features.opensuse.org/308940

1 1

[openFATE 314477] Support UEFI Secure Boot
by fate_noreply＠suse.de 03 Oct '12

03 Oct '12

Feature changed by: Jeffrey Cheung (Jeffreycheung) Feature #314477, revision 9 Title: Support UEFI Secure Boot Requested by: Jeffrey Cheung (jeffreycheung) + Partner organization: openSUSE.org Description: We need to support secure boot end-to-end in openSUSE 12.3. It is because ODM/OEM will ship UEFI secure boot enablement notebook at 2012 Q4, so openSUSE should support those machines. From technical view: + base on the approach on SUSE blogs. Our Planned Approach to Secure Boot (https://www.suse.com/blogs/uefi-secure-boot-plan/) (https://www.suse.com/blogs/uefi-secure-boot-details/) + use shim to be the forefront boot loader for verify the grub2 and kernel should signed by openSUSE key or MOKs(machine owner keys). + shim will sign by Microsoft key through Microsoft sign service + grub2 need load kernel to memory and call the verify protocol that provied by shim to verify kernel signed by openSUSE key or MOKs + kernel need signed by openSUSE key by default + user can use tool to sign grub2 and kernel with MOK by himself, and MOK can be import to NVRAM in UEFI BIOS that maintain by shim. + For support secure boot, kernel need included Matthew Garrett's patch from upstream (reviewing, will in v3.6 or v3.7) to lock io port /dev/mem and kexec(or kexec can verify signed kernel). + xorg-x11-server at least need included the d01921ec18c21f21d377b60626cc2d3418b84a7c patch to avoid set the I/O privilege level. On secure boot mode, kernel will lock io port then any user space process can't set it. + Against to io port and pci register lock down by kernel, need check if any user space applications have problem. -- openSUSE Feature: https://features.opensuse.org/314477

1 0

[New: openFATE 314498] keep old rpms for some hours after publish
by fate_noreply＠suse.de 02 Oct '12

02 Oct '12

Feature added by: Bernhard Wiedemann (bmwiedemann) Feature #314498, revision 1 Title: keep old rpms for some hours after publish Buildservice: Unconfirmed Priority Requester: Important Requested by: Bernhard Wiedemann (bmwiedemann) Partner organization: openSUSE.org Description: When installing a larger number of packages from an OBS repo (can take a few hours), it often happens that a publish event happens in the middle and zypper can no more download an rpm, because it was deleted on the server side. Workarounding this in zypper is hard and workarounding this in every script calling zypper is ugly. This works for our update repos, because all old rpms are kept in there. And it works for our released product repos, because they do not change after the release. The cleanest way to solve this for OBS repos is to keep old rpms around for at least three hours after a publish happened. For example, it could take the form of a cron.hourly job that searches for repos that were last published x hours ago and then runs rsync --delete on them. Use Case: For our SUSE Cloud Product we do continuous integration testing that automatically installs the latest version of all packages on a fresh VM and this sometimes fails from repo publishing. -- openSUSE Feature: https://features.opensuse.org/314498

1 0