Spec URL: http://www.codon.org.uk/~mjg59/mactel-boot/mactel-boot.spec SRPM URL: http://www.codon.org.uk/~mjg59/mactel-boot/mactel-boot-0.1-1.fc16.src.rpm Description: Files for booting Fedora on Intel-based Apple hardware using EFI
The model here is for /boot/efi to be an HFS+ partition rather than a FAT one. That's needed in order to make it show up correctly in the firmware boot picker and the OS X startup drive chooser. The various files that are dropped in there are to make it appear in the startup chooser, while the bless command is to flag it bootable for the boot picker. There's anaconda work going on that'll be needed for this to work out. The effective outcome is that a system installed on the entire drive will have an HFS+ partition but no FAT EFI system partition. A dual-boot setup will keep the EFI system partition, but we won't use it for anything. One thing that's been pointed out is that the %post code should make sure that the filesystem is HFS+ before trying to create any symlinks or run bless. This'll avoid it being dangerous on upgraded systems.
I tested on a Macmini5,1. I had problems making it work and make these comments before I have resolved all of them. Some of the problems are probably caused by some bad work-arounds. gdisk /dev/sda # 10 MB is enough, code AF00 partprobe /dev/sda mkfs.hfsplus -v fedora-hfsplus /dev/sda6 # no UUID support in mkfs.hfsplus yet vim /etc/fstab # remove old /boot/efi and add new one instead umount /boot/efi mount /boot/efi mkdir -p /boot/efi/EFI/redhat grub2-efi-mkimage -O x86_64-efi -o /boot/efi/EFI/redhat/grub.efi \ -p /EFI/redhat part_gpt hfsplus fat \ ext2 btrfs normal chain boot configfile linux appleldr minicmd \ loadbios reboot halt search font gfxterm # new config path grub2-efi-mkconfig -o /boot/efi/EFI/redhat/grub.cfg ln -sf /boot/efi/EFI/redhat/grub.cfg /etc/grub2-efi.cfg rpm -ihv mactel-boot-0.1-1.fc16.x86_64.rpm The new partition shows up in the Apple EFI "Alt" boot loader with a nice icon, but most of the time it boots OS/X instead of showing grub2. grub2 failed, probably because it lack a lot of the modules referenced in grub.cfg. They are not built into grub.efi and haven't been placed in the file system by grub2-efi-install (which can't install to folder not named grub2-efi anyway). It helped to add these extra modules to the image. I assume that if you want grub.efi to be installed directly from rpm without grub2-efi-install then all the relevant modules has to included in the build time mkimage ? I noticed some problems with hfsplus partitions created in OS/X. They will be mounted read-only by linux if they are journaled (unless they are mounted rw,force). That might deserve a documentation note somewhere. Absolute symlinks assuming the fs is mounted on /boot/efi seems bad. I guess it should be ln -sf ../../../EFI/redhat/grub.efi \ /boot/efi/System/Library/CoreServices/boot.efi /boot/efi/System/Library/CoreServices/boot.efi is a %ghost file. %scripts shouldn't rm /usr/share/pixmaps/bootloader/fedora.icns but /boot/efi/.VolumeIcon.icns bless is obviously inspired by OS/X bless, but I guess it only do the "_this_ is the boot loader of _this_ hfs partition" part of it, without touching EFI at all? It would be nice if it was clarified in the man page what it actually do. A hint that other "bless" functionality can be found in efibootmgr would also be nice. I guess the plist should start with '<?xml', and a DOCTYPE would be nice too. As indicated by your blog it would look nicer if ProductVersion in the plist came from $(sed 's, release .*$,,g' /etc/system-release) instead of showing the mactel-boot version.
Thanks, I've updated these. The grub 2 efi build probably does need to be tweaked to add more stuff to the default image (this is going to be necessary with secure boot, anyway)
Reviewers usually complain when the package is updated without bumping the nvr ... Some quick comments: I didn't expect from rpm that it automatically removed ghost files when the package was removed, but now I see that it does that and I can see that the spec now relies on that. Great. Why not make the requirements hard and make the %post actions unconditional: require grub2 and /usr/share/pixmaps/bootloader/fedora.icns (or system-logos) (which is provided by fedora-logos and generic-logos). (I guess that it - also for reuse in RHEL - would be convenient if a more generic name like system.icns was used.) Do the blessing of the partition really belong as a part of the package installation? That seems a bit too magic to me. I would expect that to be handled by anaconda. Regarding extra stuff in grub2-efi grub.efi: Is it the plan to keep /boot/grub2-efi/? What should it be used for, and how and for what should it be referenced? Or should its content be moved 100% to /boot/efi/EFI/redhat/? (I still think it would be better to run grub2-efi-install to /boot/efi, just like grub2-install is run for bios booting.)
I didn't make the requirement on the logo hard because it's possible that some artwork packages don't have the bootloader icon, and enforcing the dependency there doesn't seem entirely reasonable. grub's obviously more reasonable, but given that we haven't done the transition yet it'd just be one more thing to update. Possibly justifiable. Blessing is a problem. It needs to be done every time the inode number changes (ie, every time the grub package gets updated), but we can't have any kind of pre-dependency in grub because this package is only going to be installed on a subset of machines. There may be a better way to do it, but I think it's something we'll only work out by iterating through a few implementations. I don't see a significant problem with /boot/grub2-efi, but we're going to have to disable module loading and just build everything in in order to support secure boot, so I don't see it being used for anything in an EFI world. In that case there's no reason to use grub2-efi-install instead of just doing what grub-efi does, and shipping the binary.
(Discussion of the new grub2-efi model might be a bit off topic here, but a review of the correctness of the packaging of this special package do in my opinion depend a lot on it.) In my opinion the "interface" of system-logos is to provide whatever logos is needed for various purposes in the distribution. Packages can always drop in a picture of their favourite junk food if they can't come up with something better. I see - HFS blessing works just like a grub2 blocklist? That bless has to be rerun when grub.efi is changed only makes it more clear that bless shouldn't be run in %post of this package. A trigger on grub2-efi would perhaps work in most cases. (But if bless has to be run every time grub.efi changes, then there is no real benefit from the symlink, and we could just as well also copy grub.efi to the HFS partition before blessing. There is thus no need for mounting the Fedora bootstrap HFS partition as a fake EFI system partition on /boot/efi. Mounting it somewhere else would in my opinion be more transparent and less surprising.) I don't know how you plan to implement "secure" boot, but I assume it is incompatible with the idea of having a simple editable boot loader configuration file. Most users will prefer that the EFI firmware starts a grub.efi that trusts "everything" and doesn't extend the verification/chain of trust. It seems to me like "secure" boot will have to be a special cumbersome mode anyway. Should fonts and background images and i18n and grubenv also move from /boot/grub2-efi to the EFI system partition - and how? It _is_ possible to include a "ram disk" with everything in grub.efi, but that would either require a grub2-efi-install-ish step "on demand", or that the grub2-efi rpm includes a pre-built inflexible "ram disk". Do you want to do something like that?
Yes, a trigger is necessary, but it's still also necessary to do it on first install. The symlink is there so that we don't have two copies of grub.efi that can get out of sync. It's perfectly valid to have a configuration file that allows arbitrary configuration in a secure boot environment, but that configuration file should be living on the same filesystem as grub.efi. /boot/grub2-efi isn't necessary for that. Users may well prefer to have a grub.efi that trusts everything, and I'm sure we'll be able to provide tools for them to do that, but it's not going to be the default when run under a secure boot environment. Theming data can live where. For simplicity's sake it's still going to be easier to have it on the same filesystem as grub itself, but there's no hard requirement for that.
Actually, having re-read the docs, doing this in a %trigger ought to work. I'll implement it that way.
Spec URL: http://www.codon.org.uk/~mjg59/mactel-boot/mactel-boot.spec SRPM URL: http://www.codon.org.uk/~mjg59/mactel-boot/mactel-boot-0.1-2.fc16.src.rpm
It still doesn't work me as it is. Do the boot.efi symlink work for you? For me it always starts OS/X even when Fedora is chosen in the EFI boot menu. It works as expected when I replace the symlink with a real copy of grub.efi and bless it. (Or could the /EFI/redhat/grub.efi be blessed in place and boot.efi just be a place holder?) I am no big fan of the dependency to redhat-lsb. LSB compliance and all the dependencies should be optional. Very few packages depend on redhat-lsb - there is for example nothing in a standard installation with gnome-desktop that does. Most desktop machines do for example not want to have an MTA installed. I guess the package should own the whole System/Library/CoreServices path and remove it when the package is removed. OS/X will also create .disk_label and .disk_label.contentDetails when the Startup Disk is chosen - I guess they should be ghost (or explicitly removed) too so the directory can be removed. Not that I like the automatic blessing, but don't you need a bless in mactel-boot %post too to cover the case where grub2-efi already has been installed? The copyright "Red Hat <mjg>" looks a bit strange - is that intentional? Finally a couple of very minor comments: It seems a bit strange that bless takes both the mount point and the path to the boot loader file which must be below the same mount point. Somebody will mess that up one day and make them point to different file systems. Wouldn't it be simpler to find the hfs device from the boot loader stats? mnt_new_table is leaking ... It doesn't matter and is off topic for a review, but ... There is a superfluous ';' after 'ln -s'.
%triggerin is defined as running in that scenario. The redhat-lsb thing is problematic, yes - but on the other hand parsing /etc/fedora-release directly is just miserable. I'll see if I can come up with a better solution. The symlink works for me. This may well be some hilarious difference in behaviour between different firmware releases, but I'll look into it more. Finding the appropriate mount point automatically is possible but an utter pain. It's not high on my list of priorities. I'm also not worried about explicitly freeing stuff that's in an application that does one thing and then exits :) The copyright statement is the standard way of indicating that it's owned by a corporate entity while still providing contact details of the individual who wrote it.
Repeated and systematic testing shows that: Any boot.efi works as long as it is placed as a file in the right location. But boot.efi as a symlink doesn't work. There is no need for blessing at all. Blessing /boot/efi/.VolumeIcon.icns works just fine. Placing all the mactel-boot files on the FAT EFI system partition also works (almost (or exactly?) like a boot loader at /EFI/BOOT/bootx64.efi would). Tentative conclusion for _this_ machine: There is no need for blessing, and using a package just to copy 2 files and create a dummy is overkill. Better conclusion: Apples are very different and nothing can be known for sure. DMI: Apple Inc. Macmini5,1/Mac-8ED6AF5B48C039E1, BIOS MM51.88Z.0077.B0E.1110141154 10/14/2011 btw: os-prober will detect the HFS partition as a OS/X partition and it will thus incorrectly show up as such in grub.cfg.
I'll try to work out what the symlink behaviour is tomorrow. I'm not convinced that skipping blessing is going to work in all cases - I'll take a look at the OS X partitions to see whether they're blessed or not. It may be that there's fallback code to run boot.efi in the absence of blessing, and in your case that would potentially indicate that the blessing isn't happening at all - I could believe that the bootloader wouldn't follow the symlink, but the bless code does and would be picking up the inode of the target rather than the link itself. Could you do dd if=/dev/sdwhatever bs=1 skip=$((0x400)) count=$((0x100)) | hexdump -C on your /boot/efi partition and attach the output? And can you also check whether having it be on FAT is sufficient to make Startup Drive recognise it?
Ok, the blessing works absolutely fine here, so I'm pretty confused now. Along with the above, could you give the output of ls -i /boot/efi/EFI/redhat/grub.efi ?
A boot loader on the EFI system partition is not recognized by the OS/X Preferences Startup Drive. I guess that is because it is the EFI system partition, not because it is FAT. A /System/Library/CoreServices/boot.efi or /EFI/BOOT/bootx64.efi on the FAT EFI system partition will _not_ appear in the OS/X gui. It will however show up in the "Alt" startup menu. Using the system partition is thus not a solution if it must be possible to choose Fedora from OS/X. Being able to boot from the "Alt" menu and "blessing" with efibootmgr might however be a solution. I notice that your bless and OS/X gui both bless boot.efi, but your bless specify that it is a directory (2)? OS/X gui writes the same inode but uses 0x17 as type. They will generate exactly the same hexdump if I hack your bless to use 0x17 too (inode 0x57): 00000000 48 2b 00 04 80 00 08 00 48 2b 4c 78 00 00 00 00 |H+......H+Lx....| 00000010 ca f0 4a c1 ca f2 d3 8c 00 00 00 00 ca f0 4a c1 |..J...........J.| 00000020 00 00 00 0c 00 00 00 09 00 00 10 00 00 00 0a 00 |................| 00000030 00 00 08 57 00 00 02 4d 00 01 00 00 00 01 00 00 |...W...M........| 00000040 00 00 00 5d 00 00 00 49 00 00 00 00 00 00 00 01 |...]...I........| 00000050 00 00 00 17 00 00 00 57 00 00 00 00 00 00 00 00 |.......W........| 00000060 00 00 00 00 00 00 00 17 00 00 00 00 00 00 00 00 |................| 00000070 00 00 00 00 00 00 10 00 00 00 10 00 00 00 00 01 |................| 00000080 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 00 |................| 00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000000c0 00 00 00 00 00 01 40 00 00 01 40 00 00 00 00 14 |......@...@.....| 000000d0 00 00 00 02 00 00 00 14 00 00 00 00 00 00 00 00 |................| 000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000100 Blessing boot.efi as file or through symlink or renamed will apparently do exactly the same, both with your bless and with OS/X gui (except for the 2/0x17 issue). (Moving files around will of course change something in the first 64 bytes, but AFAICS the bless step is the same.) However, no matter if I bless with your bless os OS X gui: A symlink doesn't work. It will always use a /System/Library/CoreServices/boot.efi, either on the right partition or (very confusingly!) silently use another partition. That makes it hard and confusing to test. Could my behaviour be caused by non-standard EFI boot variables? I have previously done some experiments with OS/X bless, but I no longer have the grubx64.efi listed by: # efibootmgr -v BootCurrent: 0000 Timeout: 5 seconds BootOrder: 0080,0000 Boot0000* grub HD(1,28,64000,34b7e09a-8a76-42fd-8cad-6a2aaa332fff)File(\EFI\grub\grubx64.efi) Boot0080* Mac OS X ACPI(a0341d0,0)PCI(1f,2)03120a00000000000000HD(6,17716800,5000,aa0b2ede-b4b7-4105-aafa-09b6daeb8fa6) BootFFFF* ACPI(a0341d0,0)PCI(1f,2)03120a00000000000000HD(2,64028,3a1ec0c0,2e1af769-0d5d-4564-aaa9-9d10bb841908)File(\System\Library\CoreServices\boot.efi) btw: IIRC you mentioned that EFI variables didn't work on Macs and thus couldn't be used to solve the problem. IIRC my experience is that they do work ... but it might of course not be real EFI. Fedora already has a /usr/bin/bless packaged. That might cause confusion and might create a real conflict "soon". I guess it would be better to use some other name, such as /usr/sbin/hfs-bless. That will also avoid confusion with the OS/X tool. Have you looked into the .disk_label* boot disk labels created by OS/X blessing? It would be nice if Fedora could do the same and show something else than just "EFI Boot". http://www.finetunedmac.com/forums/ubbthreads.php?ubb=showflat&Number=15933
So something very odd is going on with your system - I have absolutely no idea what the difference is. I'll see if I can find a machine of the same vintage as yours and duplicate. EFI variables do work, but they don't integrate with the boot picker and OS X will overwrite them under a range of circumstances, so if you don't integrate with the boot picker and startup disk UI then there's no way for the user to choose them again. Less than ideal. Yeah, I'll rename to hfs-bless. Damned hex editors. The .disk_label stuff needs an app I wrote for netpbm. It's in upstream, I'll add it to the Fedora package. The volume labels are actually graphics, because Apple hate you.
Resetting PRAM and NVRAM makes no difference - except that I now have [root@fladmast ~]# efibootmgr -v BootCurrent: 0000 Timeout: 5 seconds BootOrder: 0080 Boot0080* Mac OS X ACPI(a0341d0,0)PCI(1f,2)03120a00000000000000HD(6,17716800,5000,aa0b2ede-b4b7-4105-aafa-09b6daeb8fa6) BootFFFF* ACPI(a0341d0,0)PCI(1f,2)03120a00000000000000HD(1,28,64000,34b7e09a-8a76-42fd-8cad-6a2aaa332fff)File(\System\Library\CoreServices\boot.efi) But still, OS/X blessing through a symlink makes 'bless --info' report the target file but the firmware will skip it and boot something else (the unblessed boot.efi on ESP). Another possible difference could be that I am using a file system created by hfs-mkfs which thus doesn't have any UUID. That could perhaps prevent the firmware from making an exact match on the blessed efi and make it fall back to some other mode.
Grub upstream is proposing something similar but slightly different which probably will be included in the grub used for f17: http://lists.gnu.org/archive/html/grub-devel/2011-11/msg00123.html Should mactel-boot be aligned with that somehow - or why not?
I'm going to take the liberty of CCing Chris Murphy on this, as he's fairly clued up on Mac booting issues and may be able to help with testing/review. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
> The model here is for /boot/efi to be an HFS+ partition rather than a FAT one. 1. Am I reading this correctly? Are you suggesting an hfs+ EFI System partition rather than FAT32? Apple's own EFI System partition is FAT32. The UEFI spec requires that it be FAT (FAT32 for all practical purposes). I understand that this is not UEFI, but do you propose a 2nd EFI System partition that's hfs+? Or reformatting the existing one? 2. When referred to "secure boot" and Apple hardware, do you mean UEFI 2.3.1 secure boot? Or Intel TXT Trusted Boot? Or other? I ask because none of Apple's hardware has UEFI 2.x compliant firmware, let alone 2.3.1. 3. Question: Is there something in NVRAM that Apple's EFI depends on that efibootmgr doesn't use? The Mac OS X 'nvram -p' produces more information than efibootmgr. Attached is output from that command for a MacBookPro 8,2. 4. On the EFI System partition I'm finding a 15MB file /EFI/APPLE/EXTENSIONS/Firmware.scap on two computers. Apple MBP 4,1 (2008), MBP 8,2 (2011). Diff claims they are identical. The file is not present after partitioning/formatting with Apple Disk Utility, or after installation of either Mac OS 10.6.x or 10.7.x. It appears within a few minutes of the very first login following Mac OS installation if the system has an internet connection. Does anyone know what this file is?
No, I'm suggesting that /boot/efi be HFS+ - there's no requirement that it be the EFI system partition. The secure boot side of things is something that we're going to have to manage on non-Apple EFI platforms, and we don't want to build separate grub images for the two situations. The nvram information is, as far as I've been able to tell, used by some of the Apple UI tools rather than being something necessary for the firmware, but that's something we may need to play with. The Firmware.scap files are firmware update capsules. They've probably been dropped there by the Apple software update utility.
Created attachment 542205 [details] nvram -p output from MBP8,2
I'm not sure what is meant by "firmware update capsule". The binary data and version is identical for this file on two different hardware models, which each claim different EFI firmware revisions. EFI firmware updates have always required user authentication to be applied. This file is dropped without any user notification at all.
If you pull it apart with one of the efi capsule management tools you'll find a pile of guids that match uefi functions. They may simply be overrides for some machine non-specific code.
Interesting. I'm not sure if this file is significant for EFI boot or CSM-BIOS or both or neither. Just today for the first time I am (was) able to get an EFI boot with X starting up (anaconda from F16 DVD, and gnome from the resulting installation). On a MBP 4,1, previous attempts resulted in display hang as described in bug 751147. It's been a while, but in previous attempts I'm pretty sure they were bare disks and the Firmware.scap file could not have been present if true. Today's attempt is on a MBP4,1 with this Firmware.scap file on its EFI System partition. However, the problem I'm now having after one successful boot and startup to Gnome's login window (and logging in then rebooting) is that without any changes I can't get a successful boot+startup to a gnome login. I get a different boot experience each time, usually a hang in GRUB Legacy which I can ESC from to reload GRUB but subsequent boots fail the same way. The second most frequent boot experience is failure to unpack initramfs followed by a kernel panic. And the one after that, completely black screen but apparently a successful boot as I was able to blindly switch to F2 tty shell, login as root, save dmesg to file and reboot. Getting such wildly different boot results while not seemingly changing any parameters, is making testing very difficult.
MacBookPro 4,1 - over 20 EFI boot attempts with ~4 possible boot results from DVD, and from hard disk. Appears to be some sort of intermittent corruption, resulting in initramfs unpacking problems, or VBIOS corruption. Also frequently hangs at GRUB. These entries are for a computer I own. MacBookPro 3,1 - ~ 10 EFI boot attempts also with varying results boot to boot. Same Nvidia graphics as the 4,1 model. Original bug reporter's owns this hardware. https://bugzilla.redhat.com/show_bug.cgi?id=765954 Correct me if I'm wrong, but it seems until there is a consistently bootable machine, there's not much point in using it for further testing. Next are display problems with a MacBookPro8,2 (early 2011) which likewise for the moment makes further testing very difficult since I can't see what I'm doing. https://bugzilla.redhat.com/show_bug.cgi?id=765954 Neither are afflicted in this manner when booting with CSM-BIOS. So I'm kinda stuck 2 for 2 on Apple hardware and EFI boot not even working at the moment.
Ok, I may have found the problem here. Please try http://www.codon.org.uk/~mjg59/mactel-boot/mactel-boot-0.1-3.fc16.src.rpm
(In reply to comment #26) First URL should have been for bug 751147. Unfortunately I'm no help testing these rpms until I can boot and startup with some reliability. Every model I've tried thus far I get slightly different anomalous behavior. I personally don't find the lack of a System Preferences>Startup Disk choice for Fedora to be even a minor negative. Same with the inspecific "EFI Boot" when using option/alt at powerup. Apple hard codes "Windows" for anything depending on CSM-BIOS booting and that likewise is cosmetic to me compared to not being able to reliably boot and startup at all.
(In reply to comment #27) > http://www.codon.org.uk/~mjg59/mactel-boot/mactel-boot-0.1-3.fc16.src.rpm For My Information: The content of mactel-boot-0.1.tar.bz2 changed without changing the version number. hfs-bless now takes the directory of 3rd argument as 2nd argument and the mount point of both as 1st argument. hfs-bless will now in the process umount the mount point specified as 1st argument, and before exit it will call system("mount /boot/efi"). For what it's worth: I find the command line interface even more strange and error-prone than before. The idea of a rpm trigger scripts that invokes a binary which mounts and unmounts file systems and might render the system unbootable if it fails, that do not seem very appealing to me. My previous tests and the right interpretation of them indicates that the problem has been that the directory inode wasn't written correctly. The incorrect inode was written "correctly" and I have not seen anything that indicates that it was a problem that the filesystem was mounted. However, I guess argv[1] should be used instead of hardcoding /boot/efi. I will test RSN.
The rpm can't be installed - the script and hfs-bless fails. It can be fixed with: - if (argc != 3) { + if (argc != 4) { fprintf(stderr, "usage: %s filesystem directory filename\n", argv[0]); That proves that hfs-bless and the rpm haven't been tested in a real system at all and doesn't leave much confidence in the stability of this approach. I didn't see any indications that this version works better than the previous versions, but the testing wasn't conclusive because I was interrupted by Bug 768061 after having used the boot device chooser in OS/X.
Unfortunate skew between the source I was testing with and the source I uploaded. Sorry about that. The previous approach was pretty much guaranteed to fail due to unmounting the filesystem resulting in the kernel writing back the original superblock. It's necessary to perform the modification without the filesystem being mounted.
Updated to 0.9. This requires kernel support that has been accepted upstream and should be in tomorrow's kernel builds. The unmounting dance is now avoided.
This is slightly related but is it possible to detect EFI arch of the Mac firmware (from within linux) instead of booting into Mac OS ans trying "ioreg -l -p IODeviceTree | grep firmware-abi"
Only if you've booted via EFI.
@Matthew Garrett: Of course. I think even for other UEFI systems, linux should export the uefi arch in the system, even if the uefi and kernel arch's mismatch (i686 kernel in x86_64 uefi) or if nomodeset is used (assuming only runtime services are disabled, initial uefi stuff is still used by the kernel till the boot is complete).
- Package meets naming and packaging guidelines - Spec file matches base package name. - Spec has consistant macro usage. - Meets Packaging Guidelines. - License GPLv2+ - License field in spec matches - License file included in package - Spec in American English - Spec is legible. - Sources match upstream md5sum: [jwboyer@zod ~]$ wget http://www.codon.org.uk/~mjg59/mactel-boot/mactel-boot-0.9.tar.bz2 --2012-02-09 15:16:59-- http://www.codon.org.uk/~mjg59/mactel-boot/mactel-boot-0.9.tar.bz2 Resolving www.codon.org.uk... 93.93.128.6 Connecting to www.codon.org.uk|93.93.128.6|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 7751 (7.6K) [application/x-bzip2] Saving to: “mactel-boot-0.9.tar.bz2” 100%[======================================>] 7,751 48.8K/s in 0.2s 2012-02-09 15:17:00 (48.8 KB/s) - “mactel-boot-0.9.tar.bz2” saved [7751/7751] [jwboyer@zod ~]$ md5sum mactel-boot-0.9.tar.bz2 c03ba709112ab102d6f75b8028bc3db3 mactel-boot-0.9.tar.bz2 [jwboyer@zod ~]$ md5sum ~/rpmbuild/SOURCES/mactel-boot-0.9.tar.bz2 c03ba709112ab102d6f75b8028bc3db3 /home/jwboyer/rpmbuild/SOURCES/mactel-boot-0.9.tar.bz2 [jwboyer@zod ~]$ - Package correctly uses ExclusiveArch - BuildRequires correct I think you can drop the BR on redhat-lsb here and just use the pre-defined %{fedora} in place of your %{fedora_release} macro - Package has %defattr and permissions on files is good. - Package has a correct %clean section. - Package has correct buildroot - Package is code or permissible content. - Packages %doc files don't affect runtime. - Package compiles and builds on at least one arch. [jwboyer@zod SPECS]$ rpmbuild -ba mactel-boot.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.WMqeg6 + umask 022 + cd /home/jwboyer/rpmbuild/BUILD + LANG=C + export LANG + unset DISPLAY + cd /home/jwboyer/rpmbuild/BUILD + rm -rf mactel-boot-0.9 + /usr/bin/bzip2 -dc /home/jwboyer/rpmbuild/SOURCES/mactel-boot-0.9.tar.bz2 + /bin/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd mactel-boot-0.9 + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.K1EYpT + umask 022 + cd /home/jwboyer/rpmbuild/BUILD + cd mactel-boot-0.9 + LANG=C + export LANG + unset DISPLAY ++ lsb_release -r -s + make 'PRODUCTVERSION=Fedora 16' -j4 sed "s/PRODUCTVERSION/Fedora 16/" SystemVersion.plist.in >SystemVersion.plist cc -g -o hfs-bless bless.c + exit 0 Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.lTpLaH + umask 022 + cd /home/jwboyer/rpmbuild/BUILD + '[' /home/jwboyer/rpmbuild/BUILDROOT/mactel-boot-0.9-1.fc16.x86_64 '!=' / ']' + rm -rf /home/jwboyer/rpmbuild/BUILDROOT/mactel-boot-0.9-1.fc16.x86_64 ++ dirname /home/jwboyer/rpmbuild/BUILDROOT/mactel-boot-0.9-1.fc16.x86_64 + mkdir -p /home/jwboyer/rpmbuild/BUILDROOT + mkdir /home/jwboyer/rpmbuild/BUILDROOT/mactel-boot-0.9-1.fc16.x86_64 + cd mactel-boot-0.9 + LANG=C + export LANG + unset DISPLAY + rm -rf /home/jwboyer/rpmbuild/BUILDROOT/mactel-boot-0.9-1.fc16.x86_64 + make install DESTDIR=/home/jwboyer/rpmbuild/BUILDROOT/mactel-boot-0.9-1.fc16.x86_64 install -D hfs-bless /home/jwboyer/rpmbuild/BUILDROOT/mactel-boot-0.9-1.fc16.x86_64/usr/sbin/hfs-bless install -D -m 644 bless.1 /home/jwboyer/rpmbuild/BUILDROOT/mactel-boot-0.9-1.fc16.x86_64/usr/share/man/man1/hfs-bless.1 + install -D -m 644 SystemVersion.plist /home/jwboyer/rpmbuild/BUILDROOT/mactel-boot-0.9-1.fc16.x86_64/boot/efi/System/Library/CoreServices/SystemVersion.plist + echo 'This file is required for booting' + touch /home/jwboyer/rpmbuild/BUILDROOT/mactel-boot-0.9-1.fc16.x86_64/boot/efi/System/Library/CoreServices/boot.efi + touch /home/jwboyer/rpmbuild/BUILDROOT/mactel-boot-0.9-1.fc16.x86_64/boot/efi/.VolumeIcon.icns + /usr/lib/rpm/find-debuginfo.sh --strict-build-id /home/jwboyer/rpmbuild/BUILD/mactel-boot-0.9 extracting debug info from /home/jwboyer/rpmbuild/BUILDROOT/mactel-boot-0.9-1.fc16.x86_64/usr/sbin/hfs-bless 4 blocks + /usr/lib/rpm/check-buildroot + /usr/lib/rpm/redhat/brp-compress + /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip + /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1 + /usr/lib/rpm/redhat/brp-python-hardlink + /usr/lib/rpm/redhat/brp-java-repack-jars Processing files: mactel-boot-0.9-1.fc16.x86_64 Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.6M0Ctw + umask 022 + cd /home/jwboyer/rpmbuild/BUILD + cd mactel-boot-0.9 + DOCDIR=/home/jwboyer/rpmbuild/BUILDROOT/mactel-boot-0.9-1.fc16.x86_64/usr/share/doc/mactel-boot-0.9 + export DOCDIR + /bin/mkdir -p /home/jwboyer/rpmbuild/BUILDROOT/mactel-boot-0.9-1.fc16.x86_64/usr/share/doc/mactel-boot-0.9 + cp -pr GPL /home/jwboyer/rpmbuild/BUILDROOT/mactel-boot-0.9-1.fc16.x86_64/usr/share/doc/mactel-boot-0.9 + cp -pr Copyright /home/jwboyer/rpmbuild/BUILDROOT/mactel-boot-0.9-1.fc16.x86_64/usr/share/doc/mactel-boot-0.9 + exit 0 Requires(interp): /bin/sh /bin/sh Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires(post): /bin/sh Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) rtld(GNU_HASH) Processing files: mactel-boot-debuginfo-0.9-1.fc16.x86_64 Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/jwboyer/rpmbuild/BUILDROOT/mactel-boot-0.9-1.fc16.x86_64 Wrote: /home/jwboyer/rpmbuild/SRPMS/mactel-boot-0.9-1.fc16.src.rpm Wrote: /home/jwboyer/rpmbuild/RPMS/x86_64/mactel-boot-0.9-1.fc16.x86_64.rpm Wrote: /home/jwboyer/rpmbuild/RPMS/x86_64/mactel-boot-debuginfo-0.9-1.fc16.x86_64.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.GkuXmT + umask 022 + cd /home/jwboyer/rpmbuild/BUILD + cd mactel-boot-0.9 + rm -rf /home/jwboyer/rpmbuild/BUILDROOT/mactel-boot-0.9-1.fc16.x86_64 + exit 0 - Package has no duplicate files in %files. - Package doesn't own any directories other packages own. - No rpmlint output. [jwboyer@zod SPECS]$ rpmlint ../RPMS/x86_64/mactel-boot-0.9-1.fc16.x86_64.rpm mactel-boot.x86_64: W: hidden-file-or-dir /boot/efi/.VolumeIcon.icns mactel-boot.x86_64: W: dangerous-command-in-%post ln 1 packages and 0 specfiles checked; 0 errors, 2 warnings. [jwboyer@zod SPECS]$ rpmlint ../SRPMS/mactel-boot-0.9-1.fc16.src.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. [jwboyer@zod SPECS]$ I think the warnings can be ignored here. - final provides and requires are sane: [jwboyer@zod SPECS]$ rpm -qp --provides ../RPMS/x86_64/mactel-boot-0.9-1.fc16.x86_64.rpm mactel-boot = 0.9-1.fc16 mactel-boot(x86-64) = 0.9-1.fc16 [jwboyer@zod SPECS]$ rpm -qp --requires ../RPMS/x86_64/mactel-boot-0.9-1.fc16.x86_64.rpm /bin/sh /bin/sh coreutils libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rtld(GNU_HASH) rpmlib(PayloadIsXz) <= 5.2-1 [jwboyer@zod SPECS]$ SHOULD Items: - Should build in mock. - Should build on all supported archs - Should function as described. - Should have sane scriptlets. - Should have dist tag - Should package latest version - check for outstanding bugs on package. Issues: 1. I think just cleanup the extraneous BR on redhat-lsb Conditional on that being fixed, this seems pretty straight-forward to me. APPROVED.
New Package SCM Request ======================= Package Name: mactel-boot Short Description: Support package for booting Linux on Intel-based Mac hardware Owners: mjg59 Branches: f17 InitialCC:
Git done (by process-git-requests).
Hi, I am cleaning up mactel-boot package in Linux Arch https://aur.archlinux.org/packages/mactel-boot/ and I have 2 minor nitpick suggestions wrt Makefile found in hfs-bless tool http://www.codon.org.uk/~mjg59/mactel-boot/mactel-boot-0.9.tar.bz2 1) Install hfs-bless tool to /usr/bin instead of /usr/sbin. Arch merged these directories into on /usr/bin and if I understand following document correctly then Fedora does the same https://fedoraproject.org/wiki/Features/UsrMove 2) Makefile should respect $CFLAGS. Build system might want to set system default compilation flags. Currently the project Makefile has line $(CC) -g -o hfs-bless bless.c but I believe it should like $(CC) $(CFLAGS) -o hfs-bless bless.c
Those both sound like useful suggestions, but it may be best to file a new bug for them - this bug should have been closed when the package was imported. Could you open a new bug? Thanks!