swapping disk with UEFI hardware - a dead end?
If you are knowledgeable about UEFI, I'll welcome your advice. This is the issue I encountered: 1. I enabled UEFI mode in BIOS in Lenovo X220 (more exactly I set UEFI as the preferred method). 2. I installed Fedora 17. 3. Fedora item appeared in BIOS in Boot order and also in the boot manager if you hit F12 on device start-up. 4. The Lenovo X220 machine had a broken audio connector, so I received a replacement, exactly the same X220 machine (completely same hardware), just a different piece. 5. I enabled UEFI mode in BIOS in the new X220 machine. 6. I swapped the disk from the old X220 machine to the new X220 machine. 7. The new X220 machine pretended that the harddisk was not bootable. It behaved exactly same as if the disk was blank. When I selected to boot from HDD, it just skipped HDD and went to other boot methods (CD, network, etc). Of course there was no longer any Fedora item in BIOS Boot order or the boot manager on F12 key press. 8. I had no idea how to fix that, how to force the new machine to boot my Fedora, or how to re-install the UEFI item (e.g. similar to GRUB re-installation). I had to re-install the whole system. My question obviously is: a) Is this a hardware bug, or are UEFI machines supposed to work this way? Is this the end of disk swapping between machines? b) Is it possible to re-install the UEFI item somehow, e.g. using a LiveCD? Thanks, Kamil -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On 06/28/2012 09:11 AM, Kamil Paral wrote: If you are knowledgeable about UEFI, I'll welcome your advice. This is the issue I encountered: 1. I enabled UEFI mode in BIOS in Lenovo X220 (more exactly I set UEFI as the preferred method). 2. I installed Fedora 17. 3. Fedora item appeared in BIOS in Boot order and also in the boot manager if you hit F12 on device start-up. 4. The Lenovo X220 machine had a broken audio connector, so I received a replacement, exactly the same X220 machine (completely same hardware), just a different piece. 5. I enabled UEFI mode in BIOS in the new X220 machine. 6. I swapped the disk from the old X220 machine to the new X220 machine. 7. The new X220 machine pretended that the harddisk was not bootable. It behaved exactly same as if the disk was blank. When I selected to boot from HDD, it just skipped HDD and went to other boot methods (CD, network, etc). Of course there was no longer any Fedora item in BIOS Boot order or the boot manager on F12 key press. 8. I had no idea how to fix that, how to force the new machine to boot my Fedora, or how to re-install the UEFI item (e.g. similar to GRUB re-installation). I had to re-install the whole system. My question obviously is: a) Is this a hardware bug, or are UEFI machines supposed to work this way? Is this the end of disk swapping between machines? b) Is it possible to re-install the UEFI item somehow, e.g. using a LiveCD? This certainly appears that your newer x220 isn't set to boot in UEFI mode? -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On 06/28/2012 09:25 AM, Peter Jones wrote: On 06/28/2012 09:11 AM, Kamil Paral wrote: If you are knowledgeable about UEFI, I'll welcome your advice. This is the issue I encountered: 1. I enabled UEFI mode in BIOS in Lenovo X220 (more exactly I set UEFI as the preferred method). 2. I installed Fedora 17. 3. Fedora item appeared in BIOS in Boot order and also in the boot manager if you hit F12 on device start-up. 4. The Lenovo X220 machine had a broken audio connector, so I received a replacement, exactly the same X220 machine (completely same hardware), just a different piece. 5. I enabled UEFI mode in BIOS in the new X220 machine. 6. I swapped the disk from the old X220 machine to the new X220 machine. 7. The new X220 machine pretended that the harddisk was not bootable. It behaved exactly same as if the disk was blank. When I selected to boot from HDD, it just skipped HDD and went to other boot methods (CD, network, etc). Of course there was no longer any Fedora item in BIOS Boot order or the boot manager on F12 key press. 8. I had no idea how to fix that, how to force the new machine to boot my Fedora, or how to re-install the UEFI item (e.g. similar to GRUB re-installation). I had to re-install the whole system. My question obviously is: a) Is this a hardware bug, or are UEFI machines supposed to work this way? Is this the end of disk swapping between machines? b) Is it possible to re-install the UEFI item somehow, e.g. using a LiveCD? This certainly appears that your newer x220 isn't set to boot in UEFI mode? Having sent that mail it became obvious that what's happened is that your new x220 board doesn't have the efi boot variable set. Some machines allow you to boot from a file, in which case it'll be /efi/fedora/grubx64.efi . If your firmware doesn't have that, you'll need to boot some install/rescue media to get to a shell. In either case you'll need to use efibootmgr to add /efi/fedora/grubx64.efi to the boot order. That's all assuming it's F17; if it's earlier, it'll be /efi/redhat/grub.efi . -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On Thu, 28.06.12 09:29, Peter Jones (pjo...@redhat.com) wrote: Having sent that mail it became obvious that what's happened is that your new x220 board doesn't have the efi boot variable set. Some machines allow you to boot from a file, in which case it'll be /efi/fedora/grubx64.efi . If your firmware doesn't have that, you'll need to boot some install/rescue media to get to a shell. In either case you'll need to use efibootmgr to add /efi/fedora/grubx64.efi to the boot order. That's all assuming it's F17; if it's earlier, it'll be /efi/redhat/grub.efi . Hmm, so if grub would also install itself into /efi/boot/bootx64.efi then this problem would just go away as that is the default file that the EFI bios will execute. This would enable disk images that just boot without any need to register them in the bios... Is there any reason why Fedora doesn't create that file? (it's a pity FAT can't do symlinks, hence it should just be a copcy of grubx64.efi) Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On 06/28/2012 09:40 AM, Lennart Poettering wrote: On Thu, 28.06.12 09:29, Peter Jones (pjo...@redhat.com) wrote: Having sent that mail it became obvious that what's happened is that your new x220 board doesn't have the efi boot variable set. Some machines allow you to boot from a file, in which case it'll be /efi/fedora/grubx64.efi . If your firmware doesn't have that, you'll need to boot some install/rescue media to get to a shell. In either case you'll need to use efibootmgr to add /efi/fedora/grubx64.efi to the boot order. That's all assuming it's F17; if it's earlier, it'll be /efi/redhat/grub.efi . Hmm, so if grub would also install itself into /efi/boot/bootx64.efi then this problem would just go away as that is the default file that the EFI bios will execute. This would enable disk images that just boot without any need to register them in the bios... Is there any reason why Fedora doesn't create that file? (it's a pity FAT can't do symlinks, hence it should just be a copcy of grubx64.efi) You're not wrong, we just haven't solved this right yet. Using /efi/boot/bootx64.efi on non-removable media was an addition to the spec in 2.3.1 , which came out right /before/ we joined the USWG, and it isn't what we'd really like to be there. Among other problems, obviously if you're dual booting then each OS is just going to clobber theirs on top of the other one, so whichever you install first doesn't get to play in a failure scenario. We haven't simply switched to using grub for that, because we don't really want the normal bootloader there as the boot file of last resort. The idea is to have that file look for your normal bootloader and re-add Boot entries automatically if it gets run, and then have it exec your real bootloader. I have the beginning of some code to do this, and it'll probably go in shim. We're also going to propose a best-practices at USWG for more standardized discovery in this situation, so we can do something more standard across OSes without worrying about clobbering this file as we do now. We could put grubx64.efi there as a stop-gap, and if we don't have what I've mentioned above ready for F18, we probably will. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
Having sent that mail it became obvious that what's happened is that your new x220 board doesn't have the efi boot variable set. Some machines allow you to boot from a file, in which case it'll be /efi/fedora/grubx64.efi . If your firmware doesn't have that, you'll need to boot some install/rescue media to get to a shell. In either case you'll need to use efibootmgr to add /efi/fedora/grubx64.efi to the boot order. That's all assuming it's F17; if it's earlier, it'll be /efi/redhat/grub.efi . Efibootmgr revealed following: $ efibootmgr -v ... Boot0019* Fedora HD(1,800,64000,16a05b56-2ea8-4cea-956b-f2d5499583e5)File(\EFI\redhat\grub.efi) (It's F17 clean install, but it has /grub.efi file, instead of /grubx64.efi. I installed from USB.) That means that if I can re-generate the same boot option on the new hardware, it should boot, right? That's great. I can't reproduce it easily again (the other X220 is gone now), but it's useful to know this in case I need it again. Thanks for the explanation. Do we have a Fedora page documenting boot problems somewhere (re-installing GRUB and stuff)? It would be useful to add a short help in there about UEFI too. GRUB guides are all over the Internet, but UEFI is a new stuff and I wasn't able to google anything at all about this problem. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On 06/28/2012 10:08 AM, Kamil Paral wrote:
Having sent that mail it became obvious that what's happened is that
your
new x220 board doesn't have the efi boot variable set. Some machines
allow
you to boot from a file, in which case it'll be
/efi/fedora/grubx64.efi .
If your firmware doesn't have that, you'll need to boot some
install/rescue
media to get to a shell. In either case you'll need to use efibootmgr
to
add /efi/fedora/grubx64.efi to the boot order.
That's all assuming it's F17; if it's earlier, it'll be
/efi/redhat/grub.efi .
Efibootmgr revealed following:
$ efibootmgr -v
...
Boot0019* Fedora
HD(1,800,64000,16a05b56-2ea8-4cea-956b-f2d5499583e5)File(\EFI\redhat\grub.efi)
(It's F17 clean install, but it has /grub.efi file, instead of /grubx64.efi. I
installed from USB.)
Er, yes, I've already lost what happened before the F18 tree from my mind :/.
Sorry for the confusion.
That means that if I can re-generate the same boot option on the new
hardware,it should boot, right? That's great. I can't reproduce it easily
again (the other X220 is gone now), but it's useful to know this in case I
need it again. Thanks for the explanation.
Well, the HD(...) may be slightly different, but I don't think it will be. If
you've got everything mounted and you're in the chroot then you should be able
to do:
efibootmgr -c -b ${SOMEFREEBOOTNUM} -L Fedora -l '\EFI\redhat\grub.efi'
Do we have a Fedora page documenting boot problems somewhere (re-installing
GRUB and stuff)? It would be useful to add a short help in there about UEFI
too. GRUB guides are all over the Internet, but UEFI is a new stuff and I
wasn't able to google anything at all about this problem.
Common Bugs is kinda sorta close to what you're talking about I guess?
--
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On Thu, Jun 28, 2012 at 03:40:17PM +0200, Lennart Poettering wrote: Hmm, so if grub would also install itself into /efi/boot/bootx64.efi then this problem would just go away as that is the default file that the EFI bios will execute. This would enable disk images that just boot without any need to register them in the bios... Is there any reason why Fedora doesn't create that file? Yes - it's not intended to be a bootloader, it's intended to be something that handles setting up boot options again. We (a) haven't written it, and (b) need to find a way to co-exist with other operating systems that write the same file. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Problem with fedpkg-build and NAT64/DNS64
Hi,
I have my development server running in IPv6-only LAN behind
dual-stack gateway with NAT64/DNS64 (tayga/bind9.8 on OpenWRT).
$ fedpkg -v build
Creating repo object from /home/raorn/src/wmmon
Running: rpm -q --qf %{NAME} --specfile wmmon.spec
Could not read /home/raorn/.koji/config for config values
Initiating a koji session to http://koji.fedoraproject.org/kojihub
Could not execute build: [Errno 101] Network is unreachable
As seen from strace, only A record is being resolved for
koji.fedoraproject.org, however:
$ host koji.fedoraproject.org
koji.fedoraproject.org has address 209.132.181.7
koji.fedoraproject.org has IPv6 address 64:ff9b::d184:b507
where 64:ff9b::d184:b507 is DNS64-mapped address for
209.132.181.7.
All other commands works fine, like fedpkg clone, koji search,
git, etc...
Any idea who's wrong and how to fix it?
--
Regards,--
Sir Raorn. --- http://thousandsofhate.blogspot.com/
signature.asc
Description: Digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem with fedpkg-build and NAT64/DNS64
On Thu, Jun 28, 2012 at 08:01:26PM +0400, Alexey I. Froloff wrote: I have my development server running in IPv6-only LAN behind dual-stack gateway with NAT64/DNS64 (tayga/bind9.8 on OpenWRT). With happens on F17 with updates and updates-testing. -- Regards,-- Sir Raorn. --- http://thousandsofhate.blogspot.com/ signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 828689] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=828689 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2012-06-28 12:05:56 --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- perl-Directory-Queue-1.6-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 828689] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=828689 --- Comment #7 from Fedora Update System upda...@fedoraproject.org --- perl-Directory-Queue-1.6-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: swapping disk with UEFI hardware - a dead end?
On Jun 28, 2012, at 7:29 AM, Peter Jones wrote: Having sent that mail it became obvious that what's happened is that your new x220 board doesn't have the efi boot variable set. Some machines allow you to boot from a file, in which case it'll be /efi/fedora/grubx64.efi . If your firmware doesn't have that, you'll need to boot some install/rescue media to get to a shell. It is perturbing that in 2012, with a nearly 30MB operating system as a pre-boot environment, that by design it doesn't scan the EFI System partition for other possible boot options - like a rescue mode - in the event efi boot variables aren't set. Apple hardware does just such a scan. If I blow away every bit of information in NVRAM, the firmware still scans available disks, and chooses a reasonable default as fallback. Even in the case when Apple's bootloader isn't present. So after all of this UEFI complexity and baggage, we still need rescue media in the example case? That is unbelievably stupid. The Lenovo case is either a bug or it's bad design or they enjoy creating user hostile hardware. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On 06/28/2012 12:17 PM, Chris Murphy wrote:
It is perturbing that in 2012, with a nearly 30MB operating system as a
pre-boot environment, that by design it doesn't scan the EFI System
partition for other possible boot options - like a rescue mode - in the event
efi boot variables aren't set.
Well, as a matter of fact, if you read upthread, as of 2.3.1 it launches
/boot/efi/boot${ARCH}.efi in this case. We weren't prepared for it, and so
we're a little behind, but we've got a plan and we're going to do something
about it.
Apple hardware does just such a scan. If I blow away every bit of information
in NVRAM, the firmware still scans available disks, and chooses a reasonable
default as fallback. Even in the case when Apple's bootloader isn't present.
I bet you their reasonable default doesn't seem as good if you're normally
dual-booting and using grub to chain-load apple's loader. I bet it's 50/50
based on some criteria we haven't tried to figure out.
So after all of this UEFI complexity and baggage, we still need rescue media
in the example case? That is unbelievably stupid. The Lenovo case is either a
bug or it's bad design or they enjoy creating user hostile hardware.
As lennart, myself, and mjg59 all made perfectly clear - this is our bug; it's
possible to do this according to spec (though it could be better), and we're
just not doing it yet.
--
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On Jun 28, 2012, at 8:08 AM, Kamil Paral wrote: Do we have a Fedora page documenting boot problems somewhere (re-installing GRUB and stuff)? It would be useful to add a short help in there about UEFI too. GRUB guides are all over the Internet, but UEFI is a new stuff and I wasn't able to google anything at all about this problem. On Linux, there are, in effect, four GRUBs. GRUB legacy, GRUB legacy EFI, GRUB 2, and GRUB 2 EFI. And all four are fundamentally different in the context of your question. I think any boot troubleshooting guide needs to be specific to each of these use cases, rather than being documented together. Documented together would be an example of user hostile documentation, not just a user hostile boot loading experience, because anyone needing a troubleshooting guide doesn't need to wade through 3/4 of the material that's inapplicable to their case. Since GRUB legacy EFI is a Red Hat thing, not available upstream, but is what's being used in F17, it's unlikely you're going to find much useful information online about it. I certainly haven't. My (still limited) understanding of its idiosyncrasies comes from pain and misery due to direct contact. GRUB2 EFI has the potential to be an even more painful experience due to idiosyncrasies with various UEFI implementations. I am speaking from a troubleshooting perspective, i.e., once boot loading has gone off the rails, it is a truly obnoxious experience from what I'm used to in the Apple hardware world. There, the fallback just works, doesn't matter what the OS is, and it requires no UI. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem with fedpkg-build and NAT64/DNS64
On Thu, Jun 28, 2012 at 08:01:26PM +0400, Alexey I. Froloff wrote:
$ fedpkg -v build
Creating repo object from /home/raorn/src/wmmon
Running: rpm -q --qf %{NAME} --specfile wmmon.spec
Could not read /home/raorn/.koji/config for config values
Initiating a koji session to http://koji.fedoraproject.org/kojihub
Could not execute build: [Errno 101] Network is unreachable
koji client problem - https://bugzilla.redhat.com/show_bug.cgi?id=836329
--
Regards,--
Sir Raorn. --- http://thousandsofhate.blogspot.com/
signature.asc
Description: Digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On Jun 28, 2012, at 10:26 AM, Peter Jones wrote:
On 06/28/2012 12:17 PM, Chris Murphy wrote:
It is perturbing that in 2012, with a nearly 30MB operating system as a
pre-boot environment, that by design it doesn't scan the EFI System
partition for other possible boot options - like a rescue mode - in the event
efi boot variables aren't set.
Well, as a matter of fact, if you read upthread, as of 2.3.1 it launches
/boot/efi/boot${ARCH}.efi in this case. We weren't prepared for it, and so
we're a little behind, but we've got a plan and we're going to do something
about it.
I'm confused. I'm not familiar with that location. In 12.3.1.3 the location
EFI//EFI/BOOT/BOOT[machine type short name].EFI is optional. It is only
required, with no other, for removable media. If not required, I don't see how
you can be faulted for lack of preparation for something optional.
Apple hardware does just such a scan. If I blow away every bit of information
in NVRAM, the firmware still scans available disks, and chooses a reasonable
default as fallback. Even in the case when Apple's bootloader isn't present.
I bet you their reasonable default doesn't seem as good if you're normally
dual-booting and using grub to chain-load apple's loader. I bet it's 50/50
based on some criteria we haven't tried to figure out.
In all of my testing, an empty NVRAM will always locate Apple's bootloader and
use it first. If not present, then it goes to EFI//EFI/BOOT/BOOTx64.EFI. If not
present, then it executes the first 440 bytes of the MBR (if a partition other
than MBR 1 is marked bootable). Lacking a UI entirely, I think these are rather
good fallbacks considering the target market. [1]
Now, it may very well be that absent all of those, yet with a
efi//efi/redhat/grub.efi present, that Apple hardware would not locate this and
use it, even if it were the only obvious choice. I haven't tested it. If that
doesn't work, I'd probably criticize it.
So after all of this UEFI complexity and baggage, we still need rescue media
in the example case? That is unbelievably stupid. The Lenovo case is either a
bug or it's bad design or they enjoy creating user hostile hardware.
As lennart, myself, and mjg59 all made perfectly clear - this is our bug; it's
possible to do this according to spec (though it could be better), and we're
just not doing it yet.
I think we're talking about different things.
Based on section 3.3 of the 2.3.1 spec which rather clearly says a default boot
behavior is required, though undefined (vendor specific), but must be invoked
anytime the BootOrder variable is not present or invalid. The point being the
expectation that default boot will load an operating system or a maintenance
utility.
This is a firmware requirement, not a boot loader or operating system
requirement.
I don't know what UEFI version Lenovo purports to conform to, but the lack of
an EFI//EFI/BOOT/BOOTx64.EFI image isn't an excuse for it failing to boot a
previously bootable disk that is in no way malformed. This seems to be a case
of bad firmware behavior that isn't conforming to section 3.3 of the spec.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On Jun 28, 2012, at 12:04 PM, Chris Murphy wrote: Lacking a UI entirely, I think these are rather good fallbacks considering the target market. [1] [1] The possible exception is the UI-less, optionless, no way to prevent, the activation of CSM-BIOS booting in the case there's MBR boot code and a bootable MBR partition set. As far as I'm aware, non-Apple hardware makes this a discrete user selection, rather than automatically determined by firmware. Seems like a possible attack vector. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On 06/28/2012 02:04 PM, Chris Murphy wrote:
On Jun 28, 2012, at 10:26 AM, Peter Jones wrote:
On 06/28/2012 12:17 PM, Chris Murphy wrote:
It is perturbing that in 2012, with a nearly 30MB operating system as a
pre-boot environment, that by design it doesn't scan the EFI System
partition for other possible boot options - like a rescue mode - in the event
efi boot variables aren't set.
Well, as a matter of fact, if you read upthread, as of 2.3.1 it launches
/boot/efi/boot${ARCH}.efi in this case. We weren't prepared for it, and so
we're a little behind, but we've got a plan and we're going to do something
about it.
I'm confused. I'm not familiar with that location. In 12.3.1.3 the location
EFI//EFI/BOOT/BOOT[machine type short name].EFI is optional. It is only
required, with no other, for removable media. If not required, I don't see
how you can be faulted for lack of preparation for something optional.
We're talking about 3.4.1.2 here.
In all of my testing, an empty NVRAM will always locate Apple's bootloader
and use it first. If not present, then it goes to EFI//EFI/BOOT/BOOTx64.EFI.
If not present, then it executes the first 440 bytes of the MBR (if a
partition other than MBR 1 is marked bootable). Lacking a UI entirely, I
think these are rather good fallbacks considering the target market. [1]
So what you're saying is that it really doesn't work that well unless you're
booting MacOS first. Not surprising.
So after all of this UEFI complexity and baggage, we still need rescue media
in the example case? That is unbelievably stupid. The Lenovo case is either a
bug or it's bad design or they enjoy creating user hostile hardware.
As lennart, myself, and mjg59 all made perfectly clear - this is our bug; it's
possible to do this according to spec (though it could be better), and we're
just not doing it yet.
I think we're talking about different things.
Based on section 3.3 of the 2.3.1 spec which rather clearly says a default
boot behavior is required, though undefined (vendor specific), but must be
invoked anytime the BootOrder variable is not present or invalid. The point
being the expectation that default boot will load an operating system or a
maintenance utility.
You've completely ignored all of section 3.4, which specifies what those
default boot parameters are for various kinds of devices. In version 2.2,
there's no default for non-removable media whatsoever. The spec does sort
of accidentally define that the vendor must have some default, but it really
is allowed to be set the machine on fire. That's what we're talking about.
In 2.3, section 3.4 has subclause 3.4.1.2 regarding default boot policy for
non-removeable media. In effect, the policy is that you should put a binary
such as I described earlier in the thread in /BOOT/EFI/BOOT${ARCH}.EFI on
non-removeable media as well.
This is a firmware requirement, not a boot loader or operating system
requirement.
It's a tool the OS can use. So far, we have not done so.
I don't know what UEFI version Lenovo purports to conform to, but the lack
of an EFI//EFI/BOOT/BOOTx64.EFI image isn't an excuse for it failing to boot
a previously bootable disk that is in no way malformed. This seems to be a
case of bad firmware behavior that isn't conforming to section 3.3 of the
spec.
I see no reason it isn't conforming to the current version of the spec. In
fact, I don't see any reason it isn't conforming to /any/ version of the spec.
The default behavior prior to 2.3 was to iterate all removable devices and
do what's specified there, and then if that fails, iterate all fixed media
devices and do something completely unspecified.
If we don't put a file there, the firmware is /in no way/ required to do
anything in particular. It's *never* required to default to running UEFI
applications not specified by Boot variables that are included in
BootOrder and also do not match the path /BOOT/EFI/BOOT${ARCH}.EFI .
--
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On Thu, Jun 28, 2012 at 12:04:41PM -0600, Chris Murphy wrote: I don't know what UEFI version Lenovo purports to conform to, but the lack of an EFI//EFI/BOOT/BOOTx64.EFI image isn't an excuse for it failing to boot a previously bootable disk that is in no way malformed. This seems to be a case of bad firmware behavior that isn't conforming to section 3.3 of the spec. Swapping a drive between machines means that you now have a drive UUID that doesn't match any of the boot options. 3.3 says that it should then attempt to boot from the device, and the only spec-defined boot location is EFI/BOOT/BOOT(machine type).efi. It seems to conform to the spec perfectly. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On Jun 28, 2012, at 12:29 PM, Peter Jones wrote:
In all of my testing, an empty NVRAM will always locate Apple's bootloader
and use it first. If not present, then it goes to EFI//EFI/BOOT/BOOTx64.EFI.
If not present, then it executes the first 440 bytes of the MBR (if a
partition other than MBR 1 is marked bootable). Lacking a UI entirely, I
think these are rather good fallbacks considering the target market. [1]
So what you're saying is that it really doesn't work that well unless you're
booting MacOS first. Not surprising.
I've said this how?
It is completely reasonable and rational for Apple hardware to first boot Mac
OS, if present, if NVRAM is empty or invalid. It's also consistent with section
3.3 of the UEFI spec. Vendors gets to decide the boot order. The point of that
section is to get a bootable computer, rather than a computer that craps its
diaper.
In 2.3, section 3.4 has subclause 3.4.1.2 regarding default boot policy for
non-removeable media. In effect, the policy is that you should put a binary
such as I described earlier in the thread in /BOOT/EFI/BOOT${ARCH}.EFI on
non-removeable media as well.
1.
3.4.1.2 is a bit messy. It says in paragraph 2 that default boot processing
behavior may optionally occur. Then proceeds to propose how it will occur, if
it optionally occurs, using a file to be located in an optional directory per
12.3.1.3.
2.
It doesn't at all indicate who should do this. If anything 12.3.1.3 implies
it's vendor domain. Not operating system domain.
Given there's no mandate that this subdirectory or file be created, let alone
used by the firmware, I don't see how this is your bug, as you put it.
I see no reason it isn't conforming to the current version of the spec. In
fact, I don't see any reason it isn't conforming to /any/ version of the spec.
The default behavior prior to 2.3 was to iterate all removable devices and
do what's specified there, and then if that fails, iterate all fixed media
devices and do something completely unspecified.
The intent of 3.3 plus 12.3.1.3 is rather clear that the idea is to result in
the booting of an operating system or maintenance utility. The previously
bootable disk is not malformed, the computer simply lacks the proper efi boot
variable in NVRAM, a completely understandable condition, if not common. And
yet this firmware shits its pants.
And in 20 years such a thing would never occur on Apple hardware in the same
context, which have had a keyboard command used on startup specifically
designed to obliterate the contents of NVRAM. And firmware that knows how to
reasonably intelligently recover from such condition.
If we don't put a file there, the firmware is /in no way/ required to do
anything in particular. It's *never* required to default to running UEFI
applications not specified by Boot variables that are included in
BootOrder and also do not match the path /BOOT/EFI/BOOT${ARCH}.EFI .
What is your interpretation of the first four sentences of paragraph 2 of 3.3?
To me that means the firmware is required to create a new boot order, not save
to NVRAM, and attempt to boot from each option. Obviously the only required
directory in EFI//EFI is the operating system vendor's subdirectory containing
their EFI boot image, and the intent of this section is for that to be used.
It's wholly irrational for a user to move a disk from one computer to another
and to get either puke in the face (the OP's experience) or even a vendor
provided maintenance utility, rather than booting the singular obvious option
on the non-removable disk, in this case the only frigging option that could
possibly boot the hardware. That it's the same model makes the experience
beyond absurd.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On Thu, Jun 28, 2012 at 01:54:13PM -0600, Chris Murphy wrote:
It's wholly irrational for a user to move a disk from one computer to
another and to get either puke in the face (the OP's experience) or
even a vendor provided maintenance utility, rather than booting the
singular obvious option on the non-removable disk, in this case the
only frigging option that could possibly boot the hardware. That it's
the same model makes the experience beyond absurd.
The only obvious thing for it to boot is EFI/BOOT/BOOT${ARCH}.efi.
Booting the first EFI executable you find on a drive is not a sensible
thing to do. Even Apple don't do that. Install Linux (only) on a Mac,
zap the PRAM, see what happens - it'll boot if there's a blessed
bootloader on an HFS+ partition, not otherwise.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On 06/28/2012 03:54 PM, Chris Murphy wrote:
2.
It doesn't at all indicate who should do this. If anything 12.3.1.3 implies
it's vendor domain. Not operating system domain.
It's completely obvious that if we want something to happen, we have to do it.
Given there's no mandate that this subdirectory or file be created, let
alone used by the firmware, I don't see how this is your bug, as you put it.
It's a tool for us to use. Right now we don't.
I see no reason it isn't conforming to the current version of the spec. In
fact, I don't see any reason it isn't conforming to /any/ version of the spec.
The default behavior prior to 2.3 was to iterate all removable devices and
do what's specified there, and then if that fails, iterate all fixed media
devices and do something completely unspecified.
The intent of 3.3 plus 12.3.1.3 is rather clear that the idea is to result
in the booting of an operating system or maintenance utility. The previously
bootable disk is not malformed, the computer simply lacks the proper efi
boot variable in NVRAM, a completely understandable condition, if not common.
And yet this firmware shits its pants.
/EFI/BOOT/BOOT${arch}.EFI *is* the maintenance utility the spec refers to.
If we don't put a file there, the firmware is /in no way/ required to do
anything in particular. It's *never* required to default to running UEFI
applications not specified by Boot variables that are included in
BootOrder and also do not match the path /BOOT/EFI/BOOT${ARCH}.EFI .
What is your interpretation of the first four sentences of paragraph 2 of
3.3? To me that means the firmware is required to create a new boot order,
not save to NVRAM, and attempt to boot from each option. Obviously the only
required directory in EFI//EFI is the operating system vendor's subdirectory
containing their EFI boot image, and the intent of this section is for that
to be used.
No. In fact, the spec specifically states: These new default boot options
are not saved to non volatile storage. That is, it is not allowed to create
new BootOrder or Boot variables. That's the OS's job.
It's wholly irrational for a user to move a disk from one computer to
another and to get either puke in the face (the OP's experience) or even a
vendor provided maintenance utility, rather than booting the singular obvious
option on the non-removable disk, in this case the only frigging option that
could possibly boot the hardware. That it's the same model makes the
experience beyond absurd.
It can be obvious to you and still incompatible with the reasonably working
model the spec provides.
--
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On Jun 28, 2012, at 2:01 PM, Peter Jones wrote:
The intent of 3.3 plus 12.3.1.3 is rather clear that the idea is to result
in the booting of an operating system or maintenance utility. The previously
bootable disk is not malformed, the computer simply lacks the proper efi
boot variable in NVRAM, a completely understandable condition, if not common.
And yet this firmware shits its pants.
/EFI/BOOT/BOOT${arch}.EFI *is* the maintenance utility the spec refers to.
The spec says operating system or maintenance utility.
And you're still referring to a vendor subdirectory that's optional in the
spec, and a 3.4.1.2 is also optional, but if the option is taken the vendor
firmware it to behave in the described manner. You have zero assurance any
firmware will conform, except by shear laziness on the part of firmware vendors
who may prefer a singular hard code path default fallback, rather than having
to scan the EFI system partition and come up with a dynamically generated boot
list.
What is your interpretation of the first four sentences of paragraph 2 of
3.3? To me that means the firmware is required to create a new boot order,
not save to NVRAM, and attempt to boot from each option. Obviously the only
required directory in EFI//EFI is the operating system vendor's subdirectory
containing their EFI boot image, and the intent of this section is for that
to be used.
No. In fact, the spec specifically states: These new default boot options
are not saved to non volatile storage. That is, it is not allowed to create
new BootOrder or Boot variables. That's the OS's job.
I'm not saying otherwise. I'm saying the spec specifically requires the
firmware scan for new default boot options, does not store them in NVRAM, but
does try to use them in sequence (vendor defined) to boot the system.
BOOTx64.EFI is a fallback position. The behavior in 3.3 is longstanding and was
left open ended without a final fail safe, which is the obvious point of
bootx64.efi.
There are millions of firmware out there not conforming to 2.3.1 and hence not
to 3.4.1.2 anyway.
It's wholly irrational for a user to move a disk from one computer to
another and to get either puke in the face (the OP's experience) or even a
vendor provided maintenance utility, rather than booting the singular obvious
option on the non-removable disk, in this case the only frigging option that
could possibly boot the hardware. That it's the same model makes the
experience beyond absurd.
It can be obvious to you and still incompatible with the reasonably working
model the spec provides.
I'm not bitching about the spec, I'm bitching about the firmware in the context
of the OP's described experience. The intent of 3.3 is to avoid failure. It
predates 3.4.1.2. The user is experiencing boot failure. I don't see 3.3 being
at all in Fedora's domain to solve. It's a firmware problem. Not an OS problem.
Not a spec problem.
Chris
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Package review request: Script-Tools
Hello everyone After some massiv rethoughts and rework of my previous Script-Collection (which used remote properitary files), i renamed it to Script-Tools, and reduced its output to stdout. It is considred alpha status. The coding follows now a strict order to enable manpage generation via scripts, in the beta phase which will be enabled as soon the developers section is working (sf code|files, rpm|koji, git :: svn will follow after beta). But thats for later. Currently it provides tools to: * tweak grub2 defaults * tweak services (missing feedbacks to improve) * tweak plymouth * download iso fedora iso files * a menu to write an iso file to a pluged in usb-device * Create a tarball of your developer project * upload current branch code to sf via git * build rpm * build koji for selected arch and much more. Review Request: https://bugzilla.redhat.com/show_bug.cgi?id=835089 Thank you in advance and kind regards -- Simon A. Erat (sea) Switzerland FAS: sea IRC: seasc -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On Thu, Jun 28, 2012 at 02:22:48PM -0600, Chris Murphy wrote: I'm not bitching about the spec, I'm bitching about the firmware in the context of the OP's described experience. The intent of 3.3 is to avoid failure. It predates 3.4.1.2. The user is experiencing boot failure. I don't see 3.3 being at all in Fedora's domain to solve. It's a firmware problem. Not an OS problem. Not a spec problem. The OS is expected to drop a utility in a well-known location in order to ensure that the firmware can do something sensible with 3.3. We're not doing that. What do you actually want the firmware to do here? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On Jun 28, 2012, at 1:59 PM, Matthew Garrett wrote:
The only obvious thing for it to boot is EFI/BOOT/BOOT${ARCH}.efi.
An optional file in an optional vendor subdirectory is the obvious choice?
Maybe a future spec could be more clear that the subdirectory and an EFI image
in it are required, who should provide it, and that it should be used first in
the case of invalid or missing BootOrder variables in NVRAM.
This is still in between ambiguous and optional in 2.3.1.
Booting the first EFI executable you find on a drive is not a sensible
thing to do.
Puking in the face of the user with an incoherent boot failure message is more
sensible than trying the singular boot loader on the available non-removable
drive?
I admit this strategy can also cause problems, and the UEFI spec isn't
particularly helpful[1] in resolving the problem of removed operating systems,
with residual boot loaders that point to them. But that is no worse, and still
likely to generate a more coherent boot loader produced can't find blah
message, than the OP's experienced rat race of an error message.
Even Apple don't do that. Install Linux (only) on a Mac,
zap the PRAM, see what happens - it'll boot if there's a blessed
bootloader on an HFS+ partition, not otherwise.
They have a vendor defined order, which 3.3 allows, even though Apple EFI is
not UEFI. When PRAM is zapped, the NVRAM is empty and nothing is blessed,
therefore the sequence I described earlier applies. That it may fail on a
singular valid boot loader in EFI//EFI/redhat/grub.efi I'll take your word on,
I haven't tried it and if so it's pathetic but also really unsurprising.
And notwithstanding their non-standard EFI and ensuing problems and
incompatibility it has cause, the hardware does provide a vastly superior UX in
the same situation as the OP. Apple hardware absolutely would have booted.
Unquestionably. And this is not a boot loader feature, or an OS feature, it is
a firmware behavior.
[1] Failure of the spec to use must release instead of can release. UEFI
v2.3.1, section 2.1.3: If the OS loader experiences a problem and cannot load
its operating system correctly, it can release all allocated resources and
return control back to the firmware via the Boot Service Exit() call.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On 06/28/2012 05:03 PM, Chris Murphy wrote:
On Jun 28, 2012, at 1:59 PM, Matthew Garrett wrote:
The only obvious thing for it to boot is EFI/BOOT/BOOT${ARCH}.efi.
An optional file in an optional vendor subdirectory is the obvious choice?
Maybe a future spec could be more clear that the subdirectory and an EFI image
in it are required, who should provide it, and that it should be used first in
the case of invalid or missing BootOrder variables in NVRAM.
This is still in between ambiguous and optional in 2.3.1.
Booting the first EFI executable you find on a drive is not a sensible
thing to do.
Puking in the face of the user with an incoherent boot failure message is
more sensible than trying the singular boot loader on the available
non-removable drive?
There's no way to know if a UEFI application is a boot loader. You're as
likely to accidentally run a firmware raid setup utility or the debug programs
we put there with gnu-efi.
I admit this strategy can also cause problems, and the UEFI spec isn't
particularly helpful[1] in resolving the problem of removed operating
systems, with residual boot loaders that point to them. But that is no worse,
and still likely to generate a more coherent boot loader produced can't find
blah message, than the OP's experienced rat race of an error message.
The UEFI spec is in fact quite helpful, we just haven't done the thing it says
to do yet.
--
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On 06/28/2012 05:03 PM, Chris Murphy wrote: They have a vendor defined order, which 3.3 allows, even though Apple EFI is not UEFI. When PRAM is zapped, the NVRAM is empty and nothing is blessed, therefore the sequence I described earlier applies. This is actually wrong as well. Blessing is a property of the filesystem on modern macs. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On Thu, Jun 28, 2012 at 03:03:55PM -0600, Chris Murphy wrote:
On Jun 28, 2012, at 1:59 PM, Matthew Garrett wrote:
The only obvious thing for it to boot is EFI/BOOT/BOOT${ARCH}.efi.
An optional file in an optional vendor subdirectory is the obvious
choice? Maybe a future spec could be more clear that the subdirectory
and an EFI image in it are required, who should provide it, and that
it should be used first in the case of invalid or missing BootOrder
variables in NVRAM.
It's not a vendor subdirectory. It belongs to the spec. It's also
clearly not required, since you can have an entirely functional system
without it.
Booting the first EFI executable you find on a drive is not a sensible
thing to do.
Puking in the face of the user with an incoherent boot failure message
is more sensible than trying the singular boot loader on the available
non-removable drive?
Yes. Of course any useful EFI implementation should then have an
interface to choose your bootloader, but that's a somewhat separate
issue.
Even Apple don't do that. Install Linux (only) on a Mac,
zap the PRAM, see what happens - it'll boot if there's a blessed
bootloader on an HFS+ partition, not otherwise.
They have a vendor defined order, which 3.3 allows, even though Apple
EFI is not UEFI. When PRAM is zapped, the NVRAM is empty and nothing
is blessed, therefore the sequence I described earlier applies. That
it may fail on a singular valid boot loader in
EFI//EFI/redhat/grub.efi I'll take your word on, I haven't tried it
and if so it's pathetic but also really unsurprising.
Apple's firmware will only attempt to load either blessed files or the
fallback path. The behaviour is basically identical to the one you're
complaining about.
And notwithstanding their non-standard EFI and ensuing problems and
incompatibility it has cause, the hardware does provide a vastly
superior UX in the same situation as the OP. Apple hardware absolutely
would have booted. Unquestionably. And this is not a boot loader
feature, or an OS feature, it is a firmware behavior.
What? No, Apple hardware wouldn't have booted. The only scenario in
which it would have is if you had a blessed bootloader, which is clearly
massively outside the EFI specification since it relies on HFS+.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On Jun 28, 2012, at 2:51 PM, Matthew Garrett wrote: On Thu, Jun 28, 2012 at 02:22:48PM -0600, Chris Murphy wrote: I'm not bitching about the spec, I'm bitching about the firmware in the context of the OP's described experience. The intent of 3.3 is to avoid failure. It predates 3.4.1.2. The user is experiencing boot failure. I don't see 3.3 being at all in Fedora's domain to solve. It's a firmware problem. Not an OS problem. Not a spec problem. The OS is expected to drop a utility in a well-known location in order to ensure that the firmware can do something sensible with 3.3. I don't see how 3.3 or 3.4 burdens the OS vendor with this utility. 3.3 burdens the firmware and firmware vendor with determining the boot options order, and attempting to boot from each option - with the goal of booting either an operating system or a utility. And how do you read 3.4.1.2's default boot processing behavior may optionally occur because that seems to render everything subsequent as optional for everyone, and still lacks explicit mention that the OS vendor is expected to provide a utility. Further this seems to present a conflict with the abstraction intent of UEFI between OS and firmware, if the OS is required/expected to produce a utility so the firmware knows WTF to go do with itself. We're not doing that. What do you actually want the firmware to do here? Conform to the burden placed on it by 3.3. Scan, produce new vendor defined boot options, then attempt to boot from each option. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On Jun 28, 2012, at 3:13 PM, Peter Jones wrote: There's no way to know if a UEFI application is a boot loader. You're as likely to accidentally run a firmware raid setup utility or the debug programs we put there with gnu-efi. Well that seems rather limiting, and problematic. I admit this strategy can also cause problems, and the UEFI spec isn't particularly helpful[1] in resolving the problem of removed operating systems, with residual boot loaders that point to them. But that is no worse, and still likely to generate a more coherent boot loader produced can't find blah message, than the OP's experienced rat race of an error message. The UEFI spec is in fact quite helpful, we just haven't done the thing it says to do yet. The optional thing it says you may do, without saying what that is or how to do it, and doesn't require it, doesn't require the subdirectory you want to use, doesn't require it be honored, nor requires the OS vendor to do any of this. Quite helpful. This is actually wrong as well. Blessing is a property of the filesystem on modern macs. It's more correct to say blessing is a property in NVRAM and the filesystem if it is HFS+. The primary mechanism is NVRAM, the fallback is in the HFS+ volume header. It used to be only a property of HFS long ago when NVRAM was tiny. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
On 26 June 2012 21:11, Bill Nottingham nott...@redhat.com wrote: For each legacy option (such as xyzzy) supported by your init script (such as frobozz), package an executable script named: /usr/libexec/initscripts/legacy-actions/frobozz/xyzzy Wouldn't /usr/lib/initscripts/legacy-actions/frobozz/xyzzy be a better location, given the general desire for libexec to disappear? Also, why the need for the legacy-actions part of the path? Jonathan. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On Jun 28, 2012, at 3:25 PM, Matthew Garrett wrote: An optional file in an optional vendor subdirectory is the obvious choice? Maybe a future spec could be more clear that the subdirectory and an EFI image in it are required, who should provide it, and that it should be used first in the case of invalid or missing BootOrder variables in NVRAM. It's not a vendor subdirectory. It belongs to the spec. It's also clearly not required, since you can have an entirely functional system without it. 12.3.1.3 optional vendor subdirectory called BOOT. Although it's vendor in-specific. Puking in the face of the user with an incoherent boot failure message is more sensible than trying the singular boot loader on the available non-removable drive? Yes. Of course any useful EFI implementation should then have an interface to choose your bootloader, but that's a somewhat separate issue. Ok well we disagree then because I consider this extremely user hostile behavior. There is only one choice. UI not required because the user isn't needed to choose ONE OPTION. And choosing that one option no matter what it is, statistically it's going to be a boot loader for the only operating system on the drive, which is the 99% use case. The use case in the example that started the thread. How about we save the firmware puke in the face for when there's meaningful ambiguity involved? Apple's firmware will only attempt to load either blessed files or the fallback path. The behaviour is basically identical to the one you're complaining about. The behavior I care about, is results. Swap hard drives, even dual boot, between two Apple computers, and they still boot. Lenovo example in this thread, does not boot in the same case. These are not identical behaviors. And so far all the Apple hardware I've tried does actually fall back to /EFI/BOOT/BOOTx64.efi unlike a lot of UEFI hardware. And notwithstanding their non-standard EFI and ensuing problems and incompatibility it has cause, the hardware does provide a vastly superior UX in the same situation as the OP. Apple hardware absolutely would have booted. Unquestionably. And this is not a boot loader feature, or an OS feature, it is a firmware behavior. What? No, Apple hardware wouldn't have booted. The only scenario in which it would have is if you had a blessed bootloader, which is clearly massively outside the EFI specification since it relies on HFS+. Seems like a deficiency of the UEFI specification that a dinky ass company thought of this problem 20 years ago and solved it with file system metadata. There is no reason why the UEFI spec can't do as good or better than this, and make it standard to write out an NVRAM equivalent file, or other metadata, on the EFI System partition, to resolve the ambiguity. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On Thu, 2012-06-28 at 17:55 -0600, Chris Murphy wrote: How about we save the firmware puke in the face for when there's meaningful ambiguity involved? Who is the 'we' here? Any conceivable 'we' which might be held to exist in the context of the Fedora development list does not, to me, seem to include 'Lenovo firmware engineers'. Whether you're right or Peter is (my money's on Peter...), this argument seems almost a sideshow: even if you're right and Lenovo's UEFI firmware implementation is a 'bad' one, so what? Manufacturers have been shipping bad firmwares for decades and there are no signs that this is going to stop in the glorious new UEFI era. It has long been established that, in practice, we do our best to work around poor firmware implementations where we can. Even if you win the argument, we'll probably _still_ wind up doing what Peter has proposed in Fedora. Essentially it seems to me that all you're arguing about is whether we call that 'implementing the UEFI spec' or 'working around poor UEFI implementations', which doesn't seem like something it's worth wasting a day's email time arguing about. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On Thu, Jun 28, 2012 at 05:55:09PM -0600, Chris Murphy wrote: The behavior I care about, is results. Swap hard drives, even dual boot, between two Apple computers, and they still boot. Lenovo example in this thread, does not boot in the same case. These are not identical behaviors. Yes, because HFS+ lets you put a pointer to a bootloader in the superblock and FAT doesn't. If you don't have a suggestion for how to make this work better with FAT then I don't think this thread is useful. Serialising nvram contents isn't an especially good suggestion. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: swapping disk with UEFI hardware - a dead end?
On Jun 28, 2012, at 8:52 PM, Matthew Garrett wrote: On Thu, Jun 28, 2012 at 05:55:09PM -0600, Chris Murphy wrote: The behavior I care about, is results. Swap hard drives, even dual boot, between two Apple computers, and they still boot. Lenovo example in this thread, does not boot in the same case. These are not identical behaviors. Yes, because HFS+ lets you put a pointer to a bootloader in the superblock and FAT doesn't. If you don't have a suggestion for how to make this work better with FAT then I don't think this thread is useful. Serialising nvram contents isn't an especially good suggestion. You and Peter may be desensitized to shitty computer behavior, and specs. But consider that Kamil's sequence would not have failed to boot on legacy BIOS+MBR hardware either. I find it surprising that a 2200 page spec, and the efforts of the UEFI Forum result in such spectacular failure, in a common and unremarkable situation. It seems exceptionally regressive. Curious, how are manufacturer's using bulk imaged disks, separate from the computers they will be installed in, and yet the computers still manage to UEFI boot? I can't believe manufacturers would give up bulk imaging capability, or have someone type commands into each machine's NVRAM. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Net-SSH2-0.45.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Net-SSH2: 5e18086347bc2099d1c67f898805841e Net-SSH2-0.45.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-SSH2] 0.45 bump
commit 947af1f8081fe69ade5ea40df4f65c8e3bad1708
Author: Petr Šabata con...@redhat.com
Date: Thu Jun 28 12:04:06 2012 +0200
0.45 bump
.gitignore |1 +
perl-Net-SSH2.spec |7 +--
sources|2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index cd9b06e..15ff2be 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@ Net-SSH2-0.28.tar.gz
/Net-SSH2-0.42.tar.gz
/Net-SSH2-0.43.tar.gz
/Net-SSH2-0.44.tar.gz
+/Net-SSH2-0.45.tar.gz
diff --git a/perl-Net-SSH2.spec b/perl-Net-SSH2.spec
index 08d3a1d..0f4d174 100644
--- a/perl-Net-SSH2.spec
+++ b/perl-Net-SSH2.spec
@@ -1,6 +1,6 @@
Name: perl-Net-SSH2
-Version:0.44
-Release:2%{?dist}
+Version:0.45
+Release:1%{?dist}
Summary:Support for the SSH 2 protocol via libSSH2
License:GPL+ or Artistic
Group: Development/Libraries
@@ -54,6 +54,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Jun 28 2012 Petr Šabata con...@redhat.com - 0.45-1
+- 0.45 bump (docs update)
+
* Thu Jun 07 2012 Petr Pisar ppi...@redhat.com - 0.44-2
- Perl 5.16 rebuild
diff --git a/sources b/sources
index dd5e960..5314868 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-0d18993d7783357b38e47212e64a1d96 Net-SSH2-0.44.tar.gz
+5e18086347bc2099d1c67f898805841e Net-SSH2-0.45.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DynaLoader-Functions] Perl 5.16 rebuild
commit e7e0c9bf5f76864285870c29f4b78b01032fbf5d
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 13:26:22 2012 +0200
Perl 5.16 rebuild
perl-DynaLoader-Functions.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-DynaLoader-Functions.spec b/perl-DynaLoader-Functions.spec
index 8ac6d8b..f2d0430 100644
--- a/perl-DynaLoader-Functions.spec
+++ b/perl-DynaLoader-Functions.spec
@@ -1,7 +1,7 @@
# This file is licensed under the terms of GNU GPLv2+.
Name: perl-DynaLoader-Functions
Version:0.001
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Deconstructed dynamic C library loading
License:GPL+ or Artistic
Group: Development/Libraries
@@ -56,6 +56,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_mandir}/man3/*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 0.001-4
+- Perl 5.16 rebuild
+
* Thu Jun 28 2012 Jitka Plesnikova jples...@redhat.com - 0.001-3
- Update Requires
- Exclude requires VMS::Filespec.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-Hide] patch to avoid warnings for 'defined(@array)' - rt#74225
commit 1b877eb80027d6de39543bb6d8bd734b2ad78848
Author: Iain Arnell iarn...@gmail.com
Date: Thu Jun 28 05:36:46 2012 -0600
patch to avoid warnings for 'defined(@array)' - rt#74225
perl-Devel-Hide.spec |9 -
rt74225.patch| 12
2 files changed, 20 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-Hide.spec b/perl-Devel-Hide.spec
index 1d3fc2d..182b37a 100644
--- a/perl-Devel-Hide.spec
+++ b/perl-Devel-Hide.spec
@@ -1,11 +1,14 @@
Name: perl-Devel-Hide
Version:0.0008
-Release:10%{?dist}
+Release:11%{?dist}
Summary:Forces the unavailability of specified Perl modules (for
testing)
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Devel-Hide/
Source0:
http://www.cpan.org/authors/id/F/FE/FERREIRA/Devel-Hide-%{version}.tar.gz
+# 'defined(@array)' is deprecated - avoid warnings
+# see https://rt.cpan.org/Public/Bug/Display.html?id=74225
+Patch0: rt74225.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
@@ -21,6 +24,7 @@ installed or not).
%prep
%setup -q -n Devel-Hide-%{version}
+%patch0 -p1
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -49,6 +53,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Jun 28 2012 Iain Arnell iarn...@gmail.com 0.0008-11
+- patch to avoid warnings for 'defined(@array)' - rt#74225
+
* Tue Jun 12 2012 Petr Pisar ppi...@redhat.com - 0.0008-10
- Perl 5.16 rebuild
diff --git a/rt74225.patch b/rt74225.patch
new file mode 100644
index 000..1f03ef3
--- /dev/null
+++ b/rt74225.patch
@@ -0,0 +1,12 @@
+diff -up Devel-Hide-0.0008/lib/Devel/Hide.pm.orig
Devel-Hide-0.0008/lib/Devel/Hide.pm
+--- Devel-Hide-0.0008/lib/Devel/Hide.pm.orig 2007-11-15 07:45:02.0
-0700
Devel-Hide-0.0008/lib/Devel/Hide.pm2012-06-28 05:27:24.0
-0600
+@@ -101,7 +101,7 @@ sub _push_hidden {
+ BEGIN {
+
+ # unless @HIDDEN was user-defined elsewhere, set default
+-if ( !defined @HIDDEN $ENV{DEVEL_HIDE_PM} ) {
++if ( !@HIDDEN $ENV{DEVEL_HIDE_PM} ) {
+ _push_hidden( split q{ }, $ENV{DEVEL_HIDE_PM} );
+
+ # NOTE. split ' ', $s is special. Read perldoc -f split.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Method-Signatures-20120523.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Method-Signatures: ea9668d27a109e3e49216b1ef3879adf Method-Signatures-20120523.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 836194] defined(@array) deprecated in Perl 5.15.7
https://bugzilla.redhat.com/show_bug.cgi?id=836194 Iain Arnell iarn...@gmail.com changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||0.0008-11.fc18 Resolution|--- |RAWHIDE Last Closed||2012-06-28 07:50:12 --- Comment #1 from Iain Arnell iarn...@gmail.com --- Thanks, Paul. Patched and built for rawhide. https://koji.fedoraproject.org/koji/taskinfo?taskID=4204307 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Method-Signatures/f17] additional build deps from package review
commit 087ff1a743ff1ea4ae6e81878296a4477aa16143
Author: Iain Arnell iarn...@gmail.com
Date: Thu Jun 28 05:46:33 2012 -0600
additional build deps from package review
.gitignore |1 +
perl-Method-Signatures.spec | 78 +++
sources |1 +
3 files changed, 80 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..f0dc219 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Method-Signatures-20120523.tar.gz
diff --git a/perl-Method-Signatures.spec b/perl-Method-Signatures.spec
new file mode 100644
index 000..7d9687f
--- /dev/null
+++ b/perl-Method-Signatures.spec
@@ -0,0 +1,78 @@
+Name: perl-Method-Signatures
+Version:20120523
+Release:2%{?dist}
+Summary:Method and function declarations with signatures and no source
filter
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Method-Signatures/
+Source0:
http://www.cpan.org/authors/id/B/BA/BAREFOOT/Method-Signatures-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl(Any::Moose) = 0.11
+BuildRequires: perl(attributes)
+BuildRequires: perl(base)
+BuildRequires: perl(Carp)
+BuildRequires: perl(Const::Fast) = 0.006
+BuildRequires: perl(Data::Alias) = 1.08
+BuildRequires: perl(Data::Dumper)
+BuildRequires: perl(Devel::BeginLift) = 0.001001
+BuildRequires: perl(Devel::Declare) = 0.006002
+BuildRequires: perl(Devel::Declare::MethodInstaller::Simple) = 0.006002
+BuildRequires: perl(Devel::Pragma) = 0.40
+BuildRequires: perl(Exporter)
+BuildRequires: perl(lib)
+BuildRequires: perl(Module::Build)
+BuildRequires: perl(Moose) = 0.96
+BuildRequires: perl(MooseX::Declare)
+BuildRequires: perl(MooseX::Declare::Syntax::Keyword::Method)
+BuildRequires: perl(MooseX::Declare::Syntax::Keyword::MethodModifier)
+BuildRequires: perl(Mouse) = 0.64
+BuildRequires: perl(PPI) = 1.203
+BuildRequires: perl(Sub::Name) = 0.03
+BuildRequires: perl(Test::Builder) = 0.82
+BuildRequires: perl(Test::Exception)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Warn)
+Requires: perl(Any::Moose) = 0.11
+Requires: perl(Const::Fast) = 0.006
+Requires: perl(Data::Alias) = 1.08
+Requires: perl(Data::Dumper)
+Requires: perl(Devel::BeginLift) = 0.001001
+Requires: perl(Devel::Declare) = 0.006002
+Requires: perl(Devel::Declare::MethodInstaller::Simple) = 0.006002
+Requires: perl(Devel::Pragma) = 0.40
+Requires: perl(PPI) = 1.203
+Requires: perl(Sub::Name) = 0.03
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%{?perl_default_filter}
+
+%description
+Provides two new keywords, func and method, so that you can write
+subroutines with signatures.
+
+%prep
+%setup -q -n Method-Signatures-%{version}
+
+%build
+%{__perl} Build.PL installdirs=vendor
+./Build
+
+%install
+./Build install destdir=%{buildroot} create_packlist=0
+
+%{_fixperms} %{buildroot}/*
+
+%check
+./Build test
+
+%files
+%doc Changes examples
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Thu Jun 28 2012 Iain Arnell iarn...@gmail.com 20120523-2
+- additional build deps from package review
+
+* Sun Jun 17 2012 Iain Arnell iarn...@gmail.com 20120523-1
+- Specfile autogenerated by cpanspec 1.79.
diff --git a/sources b/sources
index e69de29..18ab2e5 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+ea9668d27a109e3e49216b1ef3879adf Method-Signatures-20120523.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Method-Signatures] additional build deps from package review
Summary of changes: 087ff1a... additional build deps from package review (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Method-Signatures/f16] additional build deps from package review
Summary of changes: 087ff1a... additional build deps from package review (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-IO-Socket-IP] Perl 5.16 rebuild
commit 6309279d2fbc1c6f1b2dc77d5bdf291c2a3909c2
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 14:37:52 2012 +0200
Perl 5.16 rebuild
perl-IO-Socket-IP.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-IO-Socket-IP.spec b/perl-IO-Socket-IP.spec
index 11bb9f3..2ac100e 100644
--- a/perl-IO-Socket-IP.spec
+++ b/perl-IO-Socket-IP.spec
@@ -1,6 +1,6 @@
Name: perl-IO-Socket-IP
Version:0.16
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Drop-in replacement for IO::Socket::INET supporting both IPv4
and IPv6
License:GPL+ or Artistic
Group: Development/Libraries
@@ -46,6 +46,9 @@ find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
%{_mandir}/man3/*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 0.16-2
+- Perl 5.16 rebuild
+
* Mon Jun 25 2012 Petr Šabata con...@redhat.com - 0.16-1
- 0.16 (IO::Socket::INET compatibility enhancement)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-MogileFS-Utils] Perl 5.16 rebuild
commit df12b084e082b0574e53be23193545173b4f7f0b
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 14:37:53 2012 +0200
Perl 5.16 rebuild
perl-MogileFS-Utils.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-MogileFS-Utils.spec b/perl-MogileFS-Utils.spec
index a288166..7497802 100644
--- a/perl-MogileFS-Utils.spec
+++ b/perl-MogileFS-Utils.spec
@@ -2,7 +2,7 @@
Name: perl-%{cpan_name}
Version:2.25
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Utilities for MogileFS
License:GPL+ or Artistic
Group: Development/Libraries
@@ -47,6 +47,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 2.25-2
+- Perl 5.16 rebuild
+
* Wed Jun 27 2012 Petr Pisar ppi...@redhat.com - 2.25-1
- 2.25 bump
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Mojibake] Perl 5.16 rebuild
commit 82ff2eba82bdba66d5b8b79cd70b23b79865d0e0
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 14:37:53 2012 +0200
Perl 5.16 rebuild
perl-Test-Mojibake.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Test-Mojibake.spec b/perl-Test-Mojibake.spec
index 8de446c..ecd41c1 100644
--- a/perl-Test-Mojibake.spec
+++ b/perl-Test-Mojibake.spec
@@ -13,7 +13,7 @@
Name: perl-Test-Mojibake
Version: 0.4
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: Check your source for encoding misbehavior
Group: Development/Libraries
License: GPL+ or Artistic
@@ -156,6 +156,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/Test::Mojibake.3pm*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 0.4-2
+- Perl 5.16 rebuild
+
* Tue Jun 26 2012 Paul Howarth p...@city-fan.org - 0.4-1
- Update to 0.4
- _detect_utf8: PP version now handles overlong UTF-8 sequences
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-XML-LibXML] Perl 5.16 rebuild
commit ff120dbe03d404e0a454a4a138d90e1d30981790
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 14:37:53 2012 +0200
Perl 5.16 rebuild
perl-XML-LibXML.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-XML-LibXML.spec b/perl-XML-LibXML.spec
index c2ec0fb..3d2ef8d 100644
--- a/perl-XML-LibXML.spec
+++ b/perl-XML-LibXML.spec
@@ -4,7 +4,7 @@ Name: perl-XML-LibXML
# it might not be needed anymore
# this module is maintained, the other is not
Version:2.0001
-Release:1%{?dist}
+Release:2%{?dist}
Epoch: 1
Summary:Perl interface to the libxml2 library
@@ -102,6 +102,9 @@ fi
%{_mandir}/man3/*.3*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 1:2.0001-2
+- Perl 5.16 rebuild
+
* Thu Jun 21 2012 Petr Šabata con...@redhat.com - 1:2.0001-1
- 2.0001 bump
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-GlobalDestruction] Perl 5.16 rebuild
commit 4bf123733bffd79b91541628e84ad1af93c90235
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 14:44:41 2012 +0200
Perl 5.16 rebuild
perl-Devel-GlobalDestruction.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-GlobalDestruction.spec
b/perl-Devel-GlobalDestruction.spec
index d9125c4..380944f 100644
--- a/perl-Devel-GlobalDestruction.spec
+++ b/perl-Devel-GlobalDestruction.spec
@@ -3,7 +3,7 @@
Name: perl-Devel-GlobalDestruction
Version: 0.06
-Release: 1%{?dist}
+Release: 2%{?dist}
License: GPL+ or Artistic
Group: Development/Libraries
Summary: Expose PL_dirty, the flag that marks global destruction
@@ -67,6 +67,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/Devel::GlobalDestruction.3pm*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 0.06-2
+- Perl 5.16 rebuild
+
* Thu Jun 14 2012 Paul Howarth p...@city-fan.org - 0.06-1
- Update to 0.06
- De-retardize XS-less behavior under SpeedyCGI
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Text-TabularDisplay] Perl 5.16 rebuild
commit ede6df021e4cd3fe8d8eb59da5670f06e2147681
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 14:44:50 2012 +0200
Perl 5.16 rebuild
perl-Text-TabularDisplay.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Text-TabularDisplay.spec b/perl-Text-TabularDisplay.spec
index de91e2e..2e0f7c4 100644
--- a/perl-Text-TabularDisplay.spec
+++ b/perl-Text-TabularDisplay.spec
@@ -1,6 +1,6 @@
Name: perl-Text-TabularDisplay
Version:1.31
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Display text in formatted table output
# see TabularDisplay.pm's header
License:GPLv2
@@ -40,6 +40,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 1.31-2
+- Perl 5.16 rebuild
+
* Fri Jun 22 2012 Petr Šabata con...@redhat.com - 1.31-1
- 1.31 bump
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Text-CSV_XS] Perl 5.16 rebuild
commit 33d7e70994db656227a7559cbd31f7752467dd3f
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 14:45:45 2012 +0200
Perl 5.16 rebuild
perl-Text-CSV_XS.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Text-CSV_XS.spec b/perl-Text-CSV_XS.spec
index 5714096..3a2687b 100644
--- a/perl-Text-CSV_XS.spec
+++ b/perl-Text-CSV_XS.spec
@@ -1,6 +1,6 @@
Name: perl-Text-CSV_XS
Version:0.90
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Comma-separated values manipulation routines
Group: Development/Libraries
License:GPL+ or Artistic
@@ -57,6 +57,9 @@ make test
%{_mandir}/man3/*.3pm*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 0.90-2
+- Perl 5.16 rebuild
+
* Tue Jun 19 2012 Petr Šabata con...@redhat.com - 0.90-1
- 0.90 bump
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-App-cpanminus] Perl 5.16 rebuild
commit a23f0bced9a59db144c04928db7bb5bd7791e438
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 14:46:06 2012 +0200
Perl 5.16 rebuild
perl-App-cpanminus.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-App-cpanminus.spec b/perl-App-cpanminus.spec
index 9a7fc2a..62167be 100644
--- a/perl-App-cpanminus.spec
+++ b/perl-App-cpanminus.spec
@@ -1,6 +1,6 @@
Name: perl-App-cpanminus
Version:1.5015
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Library for get, unpack, build and install CPAN modules
License:GPL+ or Artistic
Group: Development/Libraries
@@ -66,6 +66,9 @@ make test
%{_bindir}/cpanm
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 1.5015-2
+- Perl 5.16 rebuild
+
* Mon Jun 25 2012 Petr Šabata con...@redhat.com - 1.5015-1
- 1.5015 bump
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Text-Wrapper] Perl 5.16 rebuild
commit c8675698db92daa2091757555053d1e8f9b4cb5a
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 14:50:00 2012 +0200
Perl 5.16 rebuild
perl-Text-Wrapper.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Text-Wrapper.spec b/perl-Text-Wrapper.spec
index c6f795f..17e479b 100644
--- a/perl-Text-Wrapper.spec
+++ b/perl-Text-Wrapper.spec
@@ -1,6 +1,6 @@
Name: perl-Text-Wrapper
Version: 1.04
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: Simple word wrapping perl module
License: GPL+ or Artistic
Group: Development/Libraries
@@ -45,6 +45,9 @@ make test RELEASE_TESTING=1
%{_mandir}/man3/*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 1.04-2
+- Perl 5.16 rebuild
+
* Wed Jun 27 2012 Ralf Corsépius corse...@fedoraproject.org - 1.04-1
- Upstream update.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CPAN-Meta-YAML] Perl 5.16 rebuild
commit ab90675aaa4f0b883e67b9bcacad3845e98795a7
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 14:59:35 2012 +0200
Perl 5.16 rebuild
perl-CPAN-Meta-YAML.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-CPAN-Meta-YAML.spec b/perl-CPAN-Meta-YAML.spec
index ce6a80d..20e050d 100644
--- a/perl-CPAN-Meta-YAML.spec
+++ b/perl-CPAN-Meta-YAML.spec
@@ -3,7 +3,7 @@
Name: perl-CPAN-Meta-YAML
Version: 0.008
-Release: 7%{?dist}
+Release: 8%{?dist}
Summary: Read and write a subset of YAML for CPAN Meta files
License: GPL+ or Artistic
Group: Development/Libraries
@@ -75,6 +75,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/CPAN::Meta::YAML.3pm*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 0.008-8
+- Perl 5.16 rebuild
+
* Thu Jun 7 2012 Paul Howarth p...@city-fan.org - 0.008-7
- Run the extra tests in a separate test run, and only when not bootstrapping
- Don't BR: perl(Test::Spelling) with RHEL ≥ 7 as we don't have the other
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Unicode-String] Perl 5.16 rebuild
commit 773b1123e4eb243ccdd2b760e1f00d5c1a4fd4cd
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 15:00:29 2012 +0200
Perl 5.16 rebuild
perl-Unicode-String.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Unicode-String.spec b/perl-Unicode-String.spec
index 6a5a8e4..d0c9c78 100644
--- a/perl-Unicode-String.spec
+++ b/perl-Unicode-String.spec
@@ -1,6 +1,6 @@
Name: perl-Unicode-String
Version:2.09
-Release:24%{?dist}
+Release:25%{?dist}
Summary:Perl modules to handle various Unicode issues
@@ -64,6 +64,9 @@ make test
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 2.09-25
+- Perl 5.16 rebuild
+
* Sun Jun 24 2012 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 2.09-24
- Really add the patch
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Carp] Perl 5.16 rebuild
commit 03f470964367a815657100da1e29b48f6a81a510
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 15:00:52 2012 +0200
Perl 5.16 rebuild
perl-Carp.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Carp.spec b/perl-Carp.spec
index ff76fe4..c6a23e1 100644
--- a/perl-Carp.spec
+++ b/perl-Carp.spec
@@ -1,6 +1,6 @@
Name: perl-Carp
Version:1.26
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Alternative warn and die for modules
License:GPL+ or Artistic
Group: Development/Libraries
@@ -47,6 +47,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 1.26-2
+- Perl 5.16 rebuild
+
* Tue Jun 19 2012 Petr Pisar ppi...@redhat.com - 1.26-1
- 1.26 bump
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Mojolicious] Perl 5.16 rebuild
commit fa0b5d6a48b12c1275927e4daf539116d6ffc33e
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 15:04:48 2012 +0200
Perl 5.16 rebuild
perl-Mojolicious.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Mojolicious.spec b/perl-Mojolicious.spec
index 79c028e..043d64c 100644
--- a/perl-Mojolicious.spec
+++ b/perl-Mojolicious.spec
@@ -1,6 +1,6 @@
Name: perl-Mojolicious
Version:3.0
-Release:1%{?dist}
+Release:2%{?dist}
Summary:A next generation web framework for Perl
License:Artistic 2.0
Group: Development/Libraries
@@ -53,6 +53,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 3.0-2
+- Perl 5.16 rebuild
+
* Tue Jun 26 2012 Yanko Kaneti yan...@declera.com - 3.0-1
- Update to 3.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-NoTabs] Perl 5.16 rebuild
commit df00ae6bd743c1e67ce746a14320565d304a39b2
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 15:05:43 2012 +0200
Perl 5.16 rebuild
perl-Test-NoTabs.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Test-NoTabs.spec b/perl-Test-NoTabs.spec
index eeda125..08aa884 100644
--- a/perl-Test-NoTabs.spec
+++ b/perl-Test-NoTabs.spec
@@ -1,6 +1,6 @@
Name: perl-Test-NoTabs
Version: 1.3
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: Check the presence of tabs in your project
Group: Development/Libraries
License: GPL+ or Artistic
@@ -47,6 +47,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/Test::NoTabs.3pm*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 1.3-2
+- Perl 5.16 rebuild
+
* Tue Jun 26 2012 Paul Howarth p...@city-fan.org - 1.3-1
- Update to 1.3
- Fix regex to ignore '.svn', but not 'Xsvn' - unescaped
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perltidy] Perl 5.16 rebuild
commit 90a2125c0cea24504f8497e42111af33e34bf5d9
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 15:09:06 2012 +0200
Perl 5.16 rebuild
perltidy.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perltidy.spec b/perltidy.spec
index e2f5659..bde9b4c 100644
--- a/perltidy.spec
+++ b/perltidy.spec
@@ -1,6 +1,6 @@
Name: perltidy
Version:20120619
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Tool for indenting and reformatting Perl scripts
License:GPLv2+
@@ -55,6 +55,9 @@ make test
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 20120619-2
+- Perl 5.16 rebuild
+
* Wed Jun 20 2012 Ville Skyttä ville.sky...@iki.fi - 20120619-1
- Update to 20120619.
- Clean up specfile constructs no longer needed in Fedora or EL6+.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Variable-Magic] Perl 5.16 rebuild
commit 9ebcc9563a9b1d9b64e7af6aeb2262f88918270f
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 15:11:29 2012 +0200
Perl 5.16 rebuild
perl-Variable-Magic.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Variable-Magic.spec b/perl-Variable-Magic.spec
index 372802a..13e48b1 100644
--- a/perl-Variable-Magic.spec
+++ b/perl-Variable-Magic.spec
@@ -1,6 +1,6 @@
Name: perl-Variable-Magic
Version:0.50
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Associate user-defined magic to variables from Perl
License:GPL+ or Artistic
Group: Development/Libraries
@@ -51,6 +51,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 0.50-2
+- Perl 5.16 rebuild
+
* Tue Jun 26 2012 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 0.50-1
- Update to 0.50
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-podlinkcheck] Perl 5.16 rebuild
commit 12276a76257cf3d007fdbe8f0007c4d8ba427a17
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 16:30:44 2012 +0200
Perl 5.16 rebuild
perl-podlinkcheck.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-podlinkcheck.spec b/perl-podlinkcheck.spec
index 355affe..44e49c4 100644
--- a/perl-podlinkcheck.spec
+++ b/perl-podlinkcheck.spec
@@ -1,6 +1,6 @@
Name: perl-podlinkcheck
Version:9
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Check Perl POD L link references
License:GPLv3+
Group: Development/Libraries
@@ -78,6 +78,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 9-2
+- Perl 5.16 rebuild
+
* Tue Jun 19 2012 Petr Pisar ppi...@redhat.com - 9-1
- 9 bump
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-EOL] Perl 5.16 rebuild
commit 03fedb887a5c936114db63c45770ce5f924ed559
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 16:30:45 2012 +0200
Perl 5.16 rebuild
perl-Test-EOL.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Test-EOL.spec b/perl-Test-EOL.spec
index 550d6cd..e9a67fb 100644
--- a/perl-Test-EOL.spec
+++ b/perl-Test-EOL.spec
@@ -3,7 +3,7 @@
Name: perl-Test-EOL
Version: 1.3
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: Check the correct line endings in your project
Group: Development/Libraries
License: GPL+ or Artistic
@@ -61,6 +61,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/Test::EOL.3pm*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 1.3-2
+- Perl 5.16 rebuild
+
* Sun Jun 17 2012 Paul Howarth p...@city-fan.org - 1.3-1
- Update to 1.3
- Fix to ignore inc/ directory used by Module::Install
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-IO-Socket-SSL] Perl 5.16 rebuild
commit 8edacfa03a906c5ec3b33170c9411f75a218a760
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 16:30:45 2012 +0200
Perl 5.16 rebuild
perl-IO-Socket-SSL.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-IO-Socket-SSL.spec b/perl-IO-Socket-SSL.spec
index a8dbf25..b9c1e25 100644
--- a/perl-IO-Socket-SSL.spec
+++ b/perl-IO-Socket-SSL.spec
@@ -1,6 +1,6 @@
Name: perl-IO-Socket-SSL
Version: 1.76
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: Perl library for transparent SSL
Group: Development/Libraries
License: GPL+ or Artistic
@@ -61,6 +61,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/IO::Socket::SSL.3pm*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 1.76-2
+- Perl 5.16 rebuild
+
* Mon Jun 18 2012 Paul Howarth p...@city-fan.org - 1.76-1
- Update to 1.76
- add support for IO::Socket::IP, which supports inet6 and inet4
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Module-Install-AutoLicense-0.08.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-Module-Install-AutoLicense: 1bdc939ddf41388ee6893f1339726d09 Module-Install-AutoLicense-0.08.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Smoke] Perl 5.16 rebuild
commit f11ed791d0f82ec2eafd65e9a64f4f394fec9840
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 17:06:54 2012 +0200
Perl 5.16 rebuild
perl-Test-Smoke.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Test-Smoke.spec b/perl-Test-Smoke.spec
index 6e71e73..94f44e8 100644
--- a/perl-Test-Smoke.spec
+++ b/perl-Test-Smoke.spec
@@ -1,6 +1,6 @@
Name: perl-Test-Smoke
Version:1.53
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Perl core test smoke suite
License:GPL+ or Artistic
Group: Development/Libraries
@@ -74,6 +74,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 1.53-2
+- Perl 5.16 rebuild
+
* Tue Jun 19 2012 Petr Šabata con...@redhat.com - 1.53-1
- 1.53 bump
- Drop command macros
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-DProf] Perl 5.16 rebuild
commit 70c0da279bf3f9dfe2805d51cc1576d84bbaf2d0
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 20:20:53 2012 +0200
Perl 5.16 rebuild
perl-Devel-DProf.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-DProf.spec b/perl-Devel-DProf.spec
index 693337a..d647e74 100644
--- a/perl-Devel-DProf.spec
+++ b/perl-Devel-DProf.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-DProf
Version:20110802.00
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Deprecated Perl code profiler
License:GPL+ or Artistic
Group: Development/Libraries
@@ -56,5 +56,8 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 20110802.00-2
+- Perl 5.16 rebuild
+
* Mon Jun 25 2012 Petr Pisar ppi...@redhat.com 20110802.00-1
- Restore perl 5.16 compatibility (CPAN RT #70629)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-CallChecker] Perl 5.16 rebuild
commit 79b2b215e3346d1c3d02ace7a12d983f69ea3b34
Author: Petr Písař ppi...@redhat.com
Date: Thu Jun 28 22:47:50 2012 +0200
Perl 5.16 rebuild
perl-Devel-CallChecker.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-CallChecker.spec b/perl-Devel-CallChecker.spec
index d352d06..d395b9d 100644
--- a/perl-Devel-CallChecker.spec
+++ b/perl-Devel-CallChecker.spec
@@ -1,7 +1,7 @@
# This file is licensed under the terms of GNU GPLv2+.
Name: perl-Devel-CallChecker
Version:0.005
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Custom op checking attached to subroutines
License:GPL+ or Artistic
Group: Development/Libraries
@@ -68,6 +68,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_mandir}/man3/*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 0.005-2
+- Perl 5.16 rebuild
+
* Mon Feb 13 2012 Petr Pisar ppi...@redhat.com - 0.005-1
- 0.005 bump
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-CallParser] Perl 5.16 rebuild
commit 2753e94da524f485e6c180fc28369b108e8a20bb
Author: Petr Písař ppi...@redhat.com
Date: Fri Jun 29 01:19:50 2012 +0200
Perl 5.16 rebuild
perl-Devel-CallParser.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-CallParser.spec b/perl-Devel-CallParser.spec
index 22008ba..3331bf3 100644
--- a/perl-Devel-CallParser.spec
+++ b/perl-Devel-CallParser.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-CallParser
Version:0.001
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Custom parsing attached to subroutines
License:GPL+ or Artistic
Group: Development/Libraries
@@ -64,5 +64,8 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_mandir}/man3/*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 0.001-2
+- Perl 5.16 rebuild
+
* Mon May 21 2012 Jitka Plesnikova jples...@redhat.com 0.001-1
- Specfile autogenerated by cpanspec 1.78.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-smartmatch-engine-core] Perl 5.16 rebuild
commit bc880385c5e6131ae715b0f52fabb1b9b8471db7
Author: Petr Písař ppi...@redhat.com
Date: Fri Jun 29 01:19:50 2012 +0200
Perl 5.16 rebuild
perl-smartmatch-engine-core.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-smartmatch-engine-core.spec b/perl-smartmatch-engine-core.spec
index 11931b1..9afa514 100644
--- a/perl-smartmatch-engine-core.spec
+++ b/perl-smartmatch-engine-core.spec
@@ -1,7 +1,7 @@
# This file is licensed under the terms of GNU GPLv2+
Name: perl-smartmatch-engine-core
Version:0.02
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Default smartmatch implementation from 5.10---5.14
License:GPL+ or Artistic
Group: Development/Libraries
@@ -54,5 +54,8 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Jun 28 2012 Petr Pisar ppi...@redhat.com - 0.02-2
+- Perl 5.16 rebuild
+
* Mon Jul 11 2011 Petr Pisar ppi...@redhat.com 0.02-1
- Initial version
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Syntax-Feature-Loop] Perl 5.16 rebuild
commit 94d14eb9eb83fdc2cbcf511da68a39e5534210dc
Author: Petr Písař ppi...@redhat.com
Date: Fri Jun 29 03:36:38 2012 +0200
Perl 5.16 rebuild
perl-Syntax-Feature-Loop.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Syntax-Feature-Loop.spec b/perl-Syntax-Feature-Loop.spec
index 892a8ca..c97b8bf 100644
--- a/perl-Syntax-Feature-Loop.spec
+++ b/perl-Syntax-Feature-Loop.spec
@@ -1,6 +1,6 @@
Name: perl-Syntax-Feature-Loop
Version:1.6.0
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Provides the loop BLOCK syntax for unconditional loops
License:CC0
Group: Development/Libraries
@@ -50,5 +50,8 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_mandir}/man3/*
%changelog
+* Fri Jun 29 2012 Petr Pisar ppi...@redhat.com - 1.6.0-2
+- Perl 5.16 rebuild
+
* Mon May 21 2012 Jitka Plesnikova jples...@redhat.com 1.6.0-1
- Specfile autogenerated by cpanspec 1.78.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
