Schedule for Monday's FESCo Meeting (2012-07-30)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 17:00UTC (1:00pm EDT) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = New business = #topic #911 F18 Feature: Samba 4.0 - https://fedoraproject.org/wiki/Features/Samba4 .fesco 911 #topic #921 F18 Feature: IPA v3 trusts update - https://fedoraproject.org/wiki/Features/IPAv3Trusts .fesco 912 #topic #913 F18 Feature: oVirt engine 3.1 - https://fedoraproject.org/wiki/Features/oVirtEngine_3.1 .fesco 913 #topic #914 F18 Feature: Python 3.3 - https://fedoraproject.org/wiki/Features/Python_3.3 .fesco 914 #topic #915 F18 Feature: Agent-Free Systems Management - https://fedoraproject.org/wiki/Features/AgentFreeManagement .fesco 915 #topic #916 F18 Feature: Sugar 0.98 - https://fedoraproject.org/wiki/Features/Sugar_0.98 .fesco 916 #topic #917 F18 Feature: MATE Desktop - https://fedoraproject.org/wiki/Features/MATE-Desktop .fesco 917 #topic #918 F18 Feature: FedFS - https://fedoraproject.org/wiki/Features/FedFS .fesco 918 #topic #919 F18 Feature: LTTng 2.0 - https://fedoraproject.org/wiki/Features/LTTng .fesco 919 #topic #920 F18 Feature: ownCloud - https://fedoraproject.org/wiki/Features/OwnCloud .fesco 920 #topic #921 F18 Feature: Server KMS Drivers - https://fedoraproject.org/wiki/Features/ServerKMSDrivers .fesco 921 #topic #922 F18 Feature: LLVM support on 64-bit POWER systems - https://fedoraproject.org/wiki/Features/LLVMonPPC64 .fesco 922 #topic #923 F18 Feature: Print Service - https://fedoraproject.org/wiki/Features/PrintService .fesco 923 #topic #924 F18 Feature: Systemtap 2.0 - https://fedoraproject.org/wiki/Features/Systemtap2 .fesco 924 #topic #925 F18 Feature: NFSometer - https://fedoraproject.org/wiki/Features/NFSometer .fesco 925 #topic #926 F18 Feature: SELinux Systemd Access Control - https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl .fesco 926 #topic #927 F18 Feature: VNCServer support for LLVMpipe/Mesa on 64-bit IBM Power Systems -https://fedoraproject.org/wiki/Features/VNCServerWithLLVMpipe .fesco 927 #topic #928 F18 Feature: QXL/Spice KMS Driver - https://fedoraproject.org/wiki/Features/QXLKMSSupport .fesco 928 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shorewall and kernel-modules-extra
On Sun, Jul 29, 2012 at 01:44:00PM +, Glandvador wrote: > Hi, > > Some shorewall (firewall) operations depend on several modules moved to > kernel-modules-extra package. > > Without the kernel-modules-extra package shorewall stops with errors like: > RTNETLINK answers: No such file or directory > leaving the system without network connectivity. Very fun for when upgrading a > network only device :) In my case at least sch_ingress and sch_sfq. > > The functionality concerns traffic shaping and I think there are a lot of > traffic shape scripts depending of those modules out of there. At least google > suggest it. > > So how to deal with that? From my POI, either make shorewall depending of the > kernel-modules-extra or move back some of the sch_* modules to the main kernel > package. Need to know in order to fill a bug report :) IIUC, the point of kernel-modules-extra was to hold modules that are not used by any Fedora applications, nor commonly needed by end users. If Shorewall doesn't work without some of these modules, IMHO, the modules in question should be moved back into the main kernel RPM. We've already requested this several times for virtualization related bits and the Fedora kernel maintainers were happy to oblige. So I suggest that you simply file a BZ ticket against the kernel RPM asking for the modules to be moved & giving your use case. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FYI: ocaml 4.00.0 beta going into Rawhide
I think we're down to our last 3 packages now: - coccinelle: Builds, but the build is obviously broken, ie. the program doesn't work for any non-trivial input. I have asked upstream about this. - frama-c: Requires further changes to work with the new Hashtbl signature in OCaml 4. You are in a twisty maze of functors, all alike. - why: Depends on on frama-c. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Boot a pungi DVD and access a kickstart file
Hi, I'm trying to generate a custom spin with pungi *and* add a kickstart file (and be able to use that). The custom spin works, I also can add a kickstart file to the DVD (using growisofs), but I don't seem to be able to access it. I tried both of these boot options: ks=cdrom:/ks.cfg ks=file:/run/initramfs/live/ks.cfg Using the first method, the installer stops with: dracut Warming: Unable to process initqueue Dropping to debug shell. The second attempt continues a bit further (it starts services) and finally stops with: The following problem occurred on line 0 of the kickstart file: Unable to open input kickstart file: Could not open/read file:///run/install/ks.cfg P.S. Accessing a kickstart file via the network works, but I explicitly want to create a DVD that does not need the network. I think I ran out of options now... Any suggestions are welcome. Thx, -- --Jos Vos --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 839744] Review Request: perl-Rose-DateTime - DateTime helper functions and objects
https://bugzilla.redhat.com/show_bug.cgi?id=839744 --- Comment #7 from Fedora Update System --- perl-Rose-DateTime-0.537-4.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/perl-Rose-DateTime-0.537-4.fc16 -- 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: rawhide report: 20120728 changes
On Saturday 28 July 2012 14:47:28 you wrote: > On Sat, 28 Jul 2012 12:36:26 + > Fedora Rawhide Report wrote: > > [...] > > > --- > > * Fri Jul 27 2012 - Andreas Schneider - > > 2:4.0.0-132.beta4 > > - Don't define an Epoch in RHEL releases. > > May I ask why? > > This makes it harder to compare versions between Fedora and RHEL. I > know it is not a 1:1 mapping anyway, but it is useful to see branching > points etc. > > Differing Epoch will be confusing later down the road, I think. It's > not like it's in the way? [reply to the list] The Epoch in the Fedora samba4 package has been added to be able to correctly conflict with samba packages. The samba packages bumped the epoch some time ago for a special update path. The RHEL samba package doesn't have any epoch set, so Epoch is 0. There is no reason why the samba4 packages in RHEL should have an Epoch of 2. Dealing with an Epoch > 0 and Requires, Conflicts, Obsoletes etc. makes your live a lot harder. If RHEL doesn't have any Epoch set, I don't see a reason why it should be set to 2 and make our life harder packaging for RHEL. Better readability of a diff between RHEL and Fedora isn't an argument. Having to spend days to get different Epoch numbers in Conflicts: Requires: and Obsoletes: correctly and testing them with different installations is an argument. It is valueable time I can spent on other things. Cheers, -- andreas -- Andreas Schneider GPG-ID: 8B7EB4B8 Red Hat a...@redhat.com Samba Team a...@samba.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 844139] perl-Dancer-1.3098 is available
https://bugzilla.redhat.com/show_bug.cgi?id=844139 --- Comment #1 from Jitka Plesnikova --- *** Bug 808855 has been marked as a duplicate of this bug. *** -- 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 808855] perl-Dancer-1.3095 is available
https://bugzilla.redhat.com/show_bug.cgi?id=808855 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED CC||jples...@redhat.com Resolution|--- |DUPLICATE Last Closed||2012-07-30 10:27:04 --- Comment #2 from Jitka Plesnikova --- *** This bug has been marked as a duplicate of bug 844139 *** -- 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: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Thu, Jul 26, 2012 at 10:12:19PM +0100, Matthew Garrett wrote: > On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote: > > > When booting Fedora 17 x64 there's the GRUB bootloader with graphical > > background image, > > I let it boot the default entry "Fedora 17", I see it the allocating memory > > pages, loading VMLINUZ etc, > > and then the display mode / resolution changes, and then there's just blank > > screen and a cursor blinking.. > > If you see a resoution change then try booting with nomodeset. > "nomodeset" doesn't help or change anything unfortunately.. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Thu, Jul 26, 2012 at 05:35:20PM -0400, Gerry Reno wrote: > On 07/26/2012 05:12 PM, Matthew Garrett wrote: > > On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote: > > > >> When booting Fedora 17 x64 there's the GRUB bootloader with graphical > >> background image, > >> I let it boot the default entry "Fedora 17", I see it the allocating > >> memory pages, loading VMLINUZ etc, > >> and then the display mode / resolution changes, and then there's just > >> blank screen and a cursor blinking.. > > If you see a resoution change then try booting with nomodeset. > > > > You might also see if you can get one of the alternate terminals. If that > works then the kernel is booted and its just > X which is not starting. > I can't change terminals. I assume the kernel doesn't boot at all, or crashes very early. I can't see any kind of activity from Linux kernel after GRUB-efi messages and the screen switches to blank.. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On 07/30/2012 10:58 AM, Pasi Kärkkäinen wrote: > On Thu, Jul 26, 2012 at 05:35:20PM -0400, Gerry Reno wrote: >> On 07/26/2012 05:12 PM, Matthew Garrett wrote: >>> On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote: >>> When booting Fedora 17 x64 there's the GRUB bootloader with graphical background image, I let it boot the default entry "Fedora 17", I see it the allocating memory pages, loading VMLINUZ etc, and then the display mode / resolution changes, and then there's just blank screen and a cursor blinking.. >>> If you see a resoution change then try booting with nomodeset. >>> >> You might also see if you can get one of the alternate terminals. If that >> works then the kernel is booted and its just >> X which is not starting. >> > I can't change terminals. I assume the kernel doesn't boot at all, or crashes > very early. > I can't see any kind of activity from Linux kernel after GRUB-efi messages > and the screen switches to blank.. > > -- Pasi > Have you tried booting with more logging? Without "quiet" param? . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Mon, Jul 30, 2012 at 11:21:54AM -0400, Gerry Reno wrote: > On 07/30/2012 10:58 AM, Pasi Kärkkäinen wrote: > > On Thu, Jul 26, 2012 at 05:35:20PM -0400, Gerry Reno wrote: > >> On 07/26/2012 05:12 PM, Matthew Garrett wrote: > >>> On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote: > >>> > When booting Fedora 17 x64 there's the GRUB bootloader with graphical > background image, > I let it boot the default entry "Fedora 17", I see it the allocating > memory pages, loading VMLINUZ etc, > and then the display mode / resolution changes, and then there's just > blank screen and a cursor blinking.. > >>> If you see a resoution change then try booting with nomodeset. > >>> > >> You might also see if you can get one of the alternate terminals. If that > >> works then the kernel is booted and its just > >> X which is not starting. > >> > > I can't change terminals. I assume the kernel doesn't boot at all, or > > crashes very early. > > I can't see any kind of activity from Linux kernel after GRUB-efi messages > > and the screen switches to blank.. > > > > -- Pasi > > > > Have you tried booting with more logging? Without "quiet" param? > There's no "quiet" param. The default UEFI boot options are "verbose" as a default. I can't see *any* output from Linux kernel. Also I tried settings up SOL serial console, but I can't see any Linux messages there either. SOL stays empty/silent. Is serial console supposed to work OK in the usual way, with UEFI boot? And again: Booting in legacy BIOS mode works OK, and the serial console works there aswell. I have problems only in UEFI mode, where I can't get *any* output from Linux. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On 07/30/2012 11:28 AM, Pasi Kärkkäinen wrote: > On Mon, Jul 30, 2012 at 11:21:54AM -0400, Gerry Reno wrote: >> On 07/30/2012 10:58 AM, Pasi Kärkkäinen wrote: >>> On Thu, Jul 26, 2012 at 05:35:20PM -0400, Gerry Reno wrote: On 07/26/2012 05:12 PM, Matthew Garrett wrote: > On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote: > >> When booting Fedora 17 x64 there's the GRUB bootloader with graphical >> background image, >> I let it boot the default entry "Fedora 17", I see it the allocating >> memory pages, loading VMLINUZ etc, >> and then the display mode / resolution changes, and then there's just >> blank screen and a cursor blinking.. > If you see a resoution change then try booting with nomodeset. > You might also see if you can get one of the alternate terminals. If that works then the kernel is booted and its just X which is not starting. >>> I can't change terminals. I assume the kernel doesn't boot at all, or >>> crashes very early. >>> I can't see any kind of activity from Linux kernel after GRUB-efi messages >>> and the screen switches to blank.. >>> >>> -- Pasi >>> >> Have you tried booting with more logging? Without "quiet" param? >> > There's no "quiet" param. The default UEFI boot options are "verbose" as a > default. > > I can't see *any* output from Linux kernel. Also I tried settings up SOL > serial console, > but I can't see any Linux messages there either. SOL stays empty/silent. > > Is serial console supposed to work OK in the usual way, with UEFI boot? > > And again: Booting in legacy BIOS mode works OK, and the serial console works > there aswell. > I have problems only in UEFI mode, where I can't get *any* output from Linux. > > -- Pasi > > Are you booting x86 or x86_64 version? I don't think x86 is supported for UEFI boot. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Mon, Jul 30, 2012 at 11:34:12AM -0400, Gerry Reno wrote: > On 07/30/2012 11:28 AM, Pasi Kärkkäinen wrote: > > On Mon, Jul 30, 2012 at 11:21:54AM -0400, Gerry Reno wrote: > >> On 07/30/2012 10:58 AM, Pasi Kärkkäinen wrote: > >>> On Thu, Jul 26, 2012 at 05:35:20PM -0400, Gerry Reno wrote: > On 07/26/2012 05:12 PM, Matthew Garrett wrote: > > On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote: > > > >> When booting Fedora 17 x64 there's the GRUB bootloader with graphical > >> background image, > >> I let it boot the default entry "Fedora 17", I see it the allocating > >> memory pages, loading VMLINUZ etc, > >> and then the display mode / resolution changes, and then there's just > >> blank screen and a cursor blinking.. > > If you see a resoution change then try booting with nomodeset. > > > You might also see if you can get one of the alternate terminals. If > that works then the kernel is booted and its just > X which is not starting. > > >>> I can't change terminals. I assume the kernel doesn't boot at all, or > >>> crashes very early. > >>> I can't see any kind of activity from Linux kernel after GRUB-efi > >>> messages and the screen switches to blank.. > >>> > >>> -- Pasi > >>> > >> Have you tried booting with more logging? Without "quiet" param? > >> > > There's no "quiet" param. The default UEFI boot options are "verbose" as a > > default. > > > > I can't see *any* output from Linux kernel. Also I tried settings up SOL > > serial console, > > but I can't see any Linux messages there either. SOL stays empty/silent. > > > > Is serial console supposed to work OK in the usual way, with UEFI boot? > > > > And again: Booting in legacy BIOS mode works OK, and the serial console > > works there aswell. > > I have problems only in UEFI mode, where I can't get *any* output from > > Linux. > > > > -- Pasi > > > > > > Are you booting x86 or x86_64 version? > > I don't think x86 is supported for UEFI boot. > x86_64 (64bit), of course. I get grub-EFI boot menu from the DVD, I choose Fedora, I get the grub-EFI texts about allocating memory pages for LINUX-EFI, loading VMLINUZ, etc.. and then the screen goes blank and everything stops there. Multiple people have confirmed UEFI boot is broken on Intel 7-series motherboards, so I believe this is Intel BIOS/firmware bug. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shorewall and kernel-modules-extra
Daniel P. Berrange redhat.com> writes: > IIUC, the point of kernel-modules-extra was to hold modules that are > not used by any Fedora applications, nor commonly needed by end users. > If Shorewall doesn't work without some of these modules, IMHO, the > modules in question should be moved back into the main kernel RPM. > > We've already requested this several times for virtualization related > bits and the Fedora kernel maintainers were happy to oblige. So I > suggest that you simply file a BZ ticket against the kernel RPM asking > for the modules to be moved & giving your use case. Done. https://bugzilla.redhat.com/show_bug.cgi?id=844436 Thank you (both) for the tip. glandvador -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Jul 30, 2012, at 9:36 AM, Pasi Kärkkäinen wrote: > Multiple people have confirmed UEFI boot is broken on Intel 7-series > motherboards, > so I believe this is Intel BIOS/firmware bug. Does it UEFI boot a Windows 7 X86_64 install disk? Does Intel think it's broken? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Boot a pungi DVD and access a kickstart file [SOLVED]
To answer my own question, to help others when googling this: On Mon, Jul 30, 2012 at 03:46:48PM +0200, Jos Vos wrote: > I'm trying to generate a custom spin with pungi *and* add a kickstart > file (and be able to use that). The custom spin works, I also can > add a kickstart file to the DVD (using growisofs), but I don't seem > to be able to access it. > > I tried both of these boot options: > >ks=cdrom:/ks.cfg >ks=file:/run/initramfs/live/ks.cfg > > Using the first method, the installer stops with: > >dracut Warming: Unable to process initqueue >Dropping to debug shell. > > The second attempt continues a bit further (it starts services) and > finally stops with: > >The following problem occurred on line 0 of the kickstart file: >Unable to open input kickstart file: Could not open/read > file:///run/install/ks.cfg The correct boot option seems to need a device name, e.g. ks=cdrom:/dev/sr0:/ks.cfg and now it works. This appearantly is listed wrong in http://fedoraproject.org/wiki/Anaconda/Kickstart#Boot_CD-ROM but I found the correct answer in http://fedoraproject.org/wiki/Anaconda_Boot_Options#ks Maybe someone can update the wrong info. -- --Jos Vos --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Config-IniFiles-2.77.tar.gz uploaded to lookaside cache by spot
A file has been added to the lookaside cache for perl-Config-IniFiles: 0cb0b5dac10bb1737ed97d7ae143da73 Config-IniFiles-2.77.tar.gz -- 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
[perl-Config-IniFiles] 2.77
commit fd3c2d8b0bc00b8a81512922e5a3c63903b0ed2f
Author: Tom Callaway
Date: Mon Jul 30 13:05:55 2012 -0400
2.77
.gitignore|1 +
perl-Config-IniFiles.spec | 25 -
sources |2 +-
3 files changed, 10 insertions(+), 18 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a1215c0..f7c4593 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
Config-IniFiles-2.58.tar.gz
/Config-IniFiles-2.68.tar.gz
/Config-IniFiles-2.72.tar.gz
+/Config-IniFiles-2.77.tar.gz
diff --git a/perl-Config-IniFiles.spec b/perl-Config-IniFiles.spec
index 455cd62..7235c0f 100644
--- a/perl-Config-IniFiles.spec
+++ b/perl-Config-IniFiles.spec
@@ -1,22 +1,21 @@
Name: perl-Config-IniFiles
-Version:2.72
-Release:3%{?dist}
+Version:2.77
+Release:1%{?dist}
Summary:A module for reading .ini-style configuration files
-
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Config-IniFiles/
Source0:
http://www.cpan.org/authors/id/S/SH/SHLOMIF/Config-IniFiles-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
BuildRequires: perl(Module::Build::Compat)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::More)
-BuildRequires: perl(List::MoreUtils)
+BuildRequires: perl(List::MoreUtils) >= 0.33
BuildArch: noarch
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
# Not autodetected. Found in lib/Config/IniFiles.pm:2265
Requires: perl(IO::Scalar) >= 2.109
+# Also not autodetected
+Requires: perl(List::MoreUtils) >= 0.33
%description
Config::IniFiles provides a way to have readable configuration files
@@ -24,7 +23,6 @@ outside your Perl script. Configurations can be imported
(inherited,
stacked,...), sections can be grouped, and settings can be accessed
from a tied hash.
-
%prep
%setup -q -n Config-IniFiles-%{version}
@@ -32,31 +30,24 @@ from a tied hash.
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
-
%install
-rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null ';'
chmod -R u+w $RPM_BUILD_ROOT/*
-
%check
make test
-
-%clean
-rm -rf $RPM_BUILD_ROOT
-
-
%files
-%defattr(-,root,root,-)
%doc README Changes
%{perl_vendorlib}/Config/
%{_mandir}/man3/*.3pm*
-
%changelog
+* Mon Jul 30 2012 Tom Callaway - 2.77-1
+- update to 2.77
+
* Fri Jul 20 2012 Fedora Release Engineering
- 2.72-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
diff --git a/sources b/sources
index 5a15349..9d7deda 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-513d01cf4945e9b1faccc80e153bd27e Config-IniFiles-2.72.tar.gz
+0cb0b5dac10bb1737ed97d7ae143da73 Config-IniFiles-2.77.tar.gz
--
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: Boot a pungi DVD and access a kickstart file [SOLVED]
On 07/30/2012 02:01 PM, Jos Vos wrote: To answer my own question, to help others when googling this: On Mon, Jul 30, 2012 at 03:46:48PM +0200, Jos Vos wrote: I'm trying to generate a custom spin with pungi *and* add a kickstart file (and be able to use that). The custom spin works, I also can add a kickstart file to the DVD (using growisofs), but I don't seem to be able to access it. I tried both of these boot options: ks=cdrom:/ks.cfg ks=file:/run/initramfs/live/ks.cfg Using the first method, the installer stops with: dracut Warming: Unable to process initqueue Dropping to debug shell. The second attempt continues a bit further (it starts services) and finally stops with: The following problem occurred on line 0 of the kickstart file: Unable to open input kickstart file: Could not open/read file:///run/install/ks.cfg The correct boot option seems to need a device name, e.g. ks=cdrom:/dev/sr0:/ks.cfg and now it works. This appearantly is listed wrong in http://fedoraproject.org/wiki/Anaconda/Kickstart#Boot_CD-ROM but I found the correct answer in http://fedoraproject.org/wiki/Anaconda_Boot_Options#ks Maybe someone can update the wrong info. Thanks for sharing the solution! Germán. -- Germán A. Racca Fedora Package Maintainer https://fedoraproject.org/wiki/User:Skytux -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Boot a pungi DVD and access a kickstart file [SOLVED]
Jos Vos wrote: > Maybe someone can update the wrong info. Anyone with a FAS account can edit that page. Feel free to make the change yourself. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Boot a pungi DVD and access a kickstart file [SOLVED]
On Mon, Jul 30, 2012 at 12:22:03PM -0500, Michael Cronenworth wrote: > Anyone with a FAS account can edit that page. Feel free to make the > change yourself. OK, I just did. -- --Jos Vos --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Mon, Jul 30, 2012 at 09:59:11AM -0600, Chris Murphy wrote: > > On Jul 30, 2012, at 9:36 AM, Pasi Kärkkäinen wrote: > > > Multiple people have confirmed UEFI boot is broken on Intel 7-series > > motherboards, > > so I believe this is Intel BIOS/firmware bug. > > Does it UEFI boot a Windows 7 X86_64 install disk? > I just tried it, and yes, Win7 SP1 x64 seems to install and work in UEFI mode. After win7 x64 installation I verified there is a GPT system partition on the hdd, and also I used "bcdedit" to verify Windows has booted using bootmgfw.efi and winload.efi. > Does Intel think it's broken? > I opened a thread about it on Intel forums/communities, where a person from Intel asked if "supported operating system" worked OK.. It seems RHEL is "supported", and RHEL 6.3 server x64 shows the same problem as Fedora, so that's good in a way. I guess I need to figure out how to open a proper bugreport to Intel. http://communities.intel.com/message/162124 so in short: Win7 x64 UEFI works, but fedora16/fedora17/rhel63 x64 fail in UEFI mode. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Thu, Jul 26, 2012 at 11:02:07PM +0300, Pasi Kärkkäinen wrote: > > > >I'm pretty sure this is a Intel firmware bug, but it'd be nice to be able > > >to > > >confirm that somehow.. > > > > Well, either the bootloader or the kernel (or something after that) is not > > succeeding If Windows works in UEFI mode on the machine, then we would still > > consider it to be a bug we should fix, even if the firmware fails to comply > > to > > precisely to our previous interpretation of the spec. > > > > I'll try installing Windows aswell. > I just tried Win7 SP1 x64, and it seems to install and work OK in UEFI mode. After installation I verified it had created GPT system partition, and also I used "bcdedit" to verify windows has booted using bootmgfw.efi and winload.efi. So yes, win7 works in UEFI mode, but f16/f17/rhel63 x64 fail in UEFI mode. Should I open a fedora bugzilla ticket? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes for today's FESCo meeting (2012-07-30)
=== #fedora-meeting: FESCO (2012-07-30) === Meeting started by mmaslano at 17:00:27 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-07-30/fesco.2012-07-30-17.00.log.html . Meeting summary --- * init process (mmaslano, 17:01:09) * #911 F18 Feature: Samba 4.0 - https://fedoraproject.org/wiki/Features/Samba4 (mmaslano, 17:03:23) * AGREED: Samba4.0 is an approved feature (+8,-0) (mmaslano, 17:08:20) * #917 F18 Feature: MATE Desktop - https://fedoraproject.org/wiki/Features/MATE-Desktop (mmaslano, 17:08:31) * AGREED: MATE is accepted as a feature (+9,-0) (mmaslano, 17:20:14) * #913 F18 Feature: oVirt engine 3.1 - https://fedoraproject.org/wiki/Features/oVirtEngine_3.1 (mmaslano, 17:20:45) * AGREED: oVirt is approved as a feature (+7,-0) (mmaslano, 17:23:49) * #915 F18 Feature: Agent-Free Systems Management - https://fedoraproject.org/wiki/Features/AgentFreeManagement (mmaslano, 17:23:57) * AGREED: Agent-Free Systems Management's owner must answer few question first (+6,-0) (mmaslano, 17:30:21) * #916 F18 Feature: Sugar 0.98 - https://fedoraproject.org/wiki/Features/Sugar_0.98 (mmaslano, 17:30:29) * AGREED: Sugar 0.98 is approved as a feature (+6,-0) (mmaslano, 17:32:32) * #919 F18 Feature: LTTng 2.0 - https://fedoraproject.org/wiki/Features/LTTng (mmaslano, 17:32:43) * LTTng feature must update the feature page (notes about kernel module) (mmaslano, 17:36:56) * AGREED: LTTng 2.0 is approved as a feature (+8,-0) (mmaslano, 17:38:13) * #920 F18 Feature: ownCloud - https://fedoraproject.org/wiki/Features/OwnCloud (mmaslano, 17:38:19) * AGREED: ownCloud is approved as a feature (+8,-0) (mmaslano, 17:39:45) * #923 F18 Feature: Print Service - https://fedoraproject.org/wiki/Features/PrintService (mmaslano, 17:39:55) * AGREED: Print Service will be postponed to F-19. In F-18 will be tech preview. (mmaslano, 17:43:36) * #926 F18 Feature: SELinux Systemd Access Control - https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl (mmaslano, 17:43:51) * AGREED: SELinux Systemd Access Control is approved as a feature (+8,-0) (mmaslano, 17:46:48) * AGREED: SELinux Systemd Access Control is approved as a feature (+9,-0) (mmaslano, 17:47:06) * #921 F18 Feature: IPA v3 trusts update - https://fedoraproject.org/wiki/Features/IPAv3Trusts (mmaslano, 17:47:31) * AGREED: Feature: IPA v3 trusts update (+5,-0) (mmaslano, 17:49:04) * #914 F18 Feature: Python 3.3 - https://fedoraproject.org/wiki/Features/Python_3.3 (mmaslano, 17:49:09) * AGREED: Feature: Python 3.3 (+5,-0) (mmaslano, 17:49:30) * #918 F18 Feature: FedFS - https://fedoraproject.org/wiki/Features/FedFS (mmaslano, 17:49:40) * AGREED: Feature: FedFS (+5,-0) (mmaslano, 17:49:57) * #921 F18 Feature: Server KMS Drivers - https://fedoraproject.org/wiki/Features/ServerKMSDrivers (mmaslano, 17:50:05) * AGREED: Feature: Server KMS Drivers (+5,-0) (mmaslano, 17:50:26) * #922 F18 Feature: LLVM support on 64-bit POWER systems - https://fedoraproject.org/wiki/Features/LLVMonPPC64 (mmaslano, 17:50:34) * AGREED: Feature: LLVM support on 64-bit POWER systems (+5,-0) (mmaslano, 17:50:50) * #924 F18 Feature: Systemtap 2.0 - https://fedoraproject.org/wiki/Features/Systemtap2 (mmaslano, 17:50:57) * AGREED: Feature: Systemtap 2.0 (+5,-0) (mmaslano, 17:51:12) * #925 F18 Feature: NFSometer - https://fedoraproject.org/wiki/Features/NFSometer (mmaslano, 17:51:20) * AGREED: Feature: NFSometer (+5,-0) (mmaslano, 17:51:37) * #927 F18 Feature: VNCServer support for LLVMpipe/Mesa on 64-bit IBM Power Systems -https://fedoraproject.org/wiki/Features/VNCServerWithLLVMpipe (mmaslano, 17:51:49) * AGREED: Feature: VNCServer support for LLVMpipe/Mesa on 64-bit IBM Power Systems (+5,-0) (mmaslano, 17:52:04) * #928 F18 Feature: QXL/Spice KMS Driver - https://fedoraproject.org/wiki/Features/QXLKMSSupport (mmaslano, 17:52:11) * AGREED: Feature: QXL/Spice KMS Driver (+5,-0) (mmaslano, 17:52:25) * Next week's chair (mmaslano, 17:54:27) * ACTION: mitr will be chairman next week (mmaslano, 17:55:32) * Open Floor (mmaslano, 17:55:39) * LINK: https://fedoraproject.org/wiki/Features/AvahiDefaultOnDesktop (mmaslano, 17:58:41) * 897 (mmaslano, 17:58:55) * ACTION: mitr will ask twoerner about co-operation of firewalld and avahi (mmaslano, 18:02:12) * Open Floor (mmaslano, 18:03:10) Meeting ended at 18:06:42 UTC. Action Items * mitr will be chairman next week * mitr will ask twoerner about co-operation of firewalld and avahi Action Items, by person --- * ab * mitr will ask twoerner about co-operation of firewalld and avahi * mitr * mitr will be chairman next week * mitr will ask twoerner about co-operation of firewalld and a
Re: Suggestion: Continuous mass rebuild
On 07/29/2012 10:38 AM, Richard W.M. Jones wrote: Currently we're doing a mass rebuild about every couple of releases, ie. once a year. Since Dennis Gilmore has written this rebuild script already, why don't we run the script more or less continuously? Obviously we could pace the builds so they happen for each package about once a month and don't overload Koji. Then we track packages that don't build, say, 3 times in a row, and file FTBFS bugs for them and after that prioritize fixing them or kick them out of the distro. Rich. Matt Domsch used to do this on the side, which is the right way to do it. If he's not doing it anymore, I would urge some concerned contributor to help setup the infrastructure to do it again. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Suggestion: Continuous mass rebuild
On Mon, 30 Jul 2012, Jesse Keating wrote: On 07/29/2012 10:38 AM, Richard W.M. Jones wrote: Currently we're doing a mass rebuild about every couple of releases, ie. once a year. Since Dennis Gilmore has written this rebuild script already, why don't we run the script more or less continuously? Obviously we could pace the builds so they happen for each package about once a month and don't overload Koji. Then we track packages that don't build, say, 3 times in a row, and file FTBFS bugs for them and after that prioritize fixing them or kick them out of the distro. Rich. Matt Domsch used to do this on the side, which is the right way to do it. If he's not doing it anymore, I would urge some concerned contributor to help setup the infrastructure to do it again. There's been a lot of work to make it so we can do it ourselves. If anyone wants to help out on it I can point you to what we built. Until we get the new hw active we will be limited on where we can run, though. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Suggestion: Continuous mass rebuild
On 07/30/2012 12:02 PM, Seth Vidal wrote: On Mon, 30 Jul 2012, Jesse Keating wrote: On 07/29/2012 10:38 AM, Richard W.M. Jones wrote: Currently we're doing a mass rebuild about every couple of releases, ie. once a year. Since Dennis Gilmore has written this rebuild script already, why don't we run the script more or less continuously? Obviously we could pace the builds so they happen for each package about once a month and don't overload Koji. Then we track packages that don't build, say, 3 times in a row, and file FTBFS bugs for them and after that prioritize fixing them or kick them out of the distro. Rich. Matt Domsch used to do this on the side, which is the right way to do it. If he's not doing it anymore, I would urge some concerned contributor to help setup the infrastructure to do it again. There's been a lot of work to make it so we can do it ourselves. If anyone wants to help out on it I can point you to what we built. Until we get the new hw active we will be limited on where we can run, though. -sv I believe I misphrased my statement above. I'm not necessarily encouraging somebody to go outside the Fedora Infrastructure to do mass rebuild attempts. My goal was to encourage people to do it in a throw-away method, not an actual spec committing build bumping use of Koji. The rebuilds should be attempted outside of koji and without modifying the sources. If there is room to do that inside Fedora's Infrastructure, all the better. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction
My name is Samuel Sieb. I live near Vancouver, Canada. I'm on IRC on moznet and freenode with the nick "ssieb". I started programming around the time I started high school, beginning with Assembler on an Apple II and working up to higher level languages after that. :-) I've been using RedHat/Fedora since RH5.1 and love the freedom and openness of Linux and the community around it. I'm married and we have four boys, so my available time is somewhat limited which has kept me from getting as involved as I would like. I'm also one of the developers of the ChatZilla IRC client and as the current maintainer of the package does not have time to keep it updated, I would like to co-maintain it. However, he is not able to sponsor me and after reading the wiki pages, I'm still not sure what the process would be for me to get involved in this case. I'm familiar with building RPMs as I have done it many times for creating and testing patches in various packages, but I haven't directly used the Fedora build system. The documentations appears to be clear and useful though. I have a FAS account and SSH key setup. I would appreciate if someone would let me know what the next step should be or if there is any other information you would like me to provide. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On 12-07-25 6:24 PM, Bill Nottingham wrote: Package gnofract4d (fails to build) comaintained by: firewing Sorry I didn't see this earlier. It looks like this FTBFS was fixed by jjames on the Jul 26, my thanks! That said, I no longer have any use for this package. If jjames (or anyone else) would like to continue maintaining it please feel free to take it. Regards, Stewart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Suggestion: Continuous mass rebuild
Richard W.M. Jones píše v Ne 29. 07. 2012 v 18:38 +0100: > Currently we're doing a mass rebuild about every couple of releases, > ie. once a year. > > Since Dennis Gilmore has written this rebuild script already, why > don't we run the script more or less continuously? Obviously we could > pace the builds so they happen for each package about once a month and > don't overload Koji. > > Then we track packages that don't build, say, 3 times in a row, and > file FTBFS bugs for them and after that prioritize fixing them or kick > them out of the distro. please keep in mind that the resources available to secondary arches are limited and can't undergo the load the mass rebuild generate. They can follow the normal load of builds coming from primary for rawhide and updates for 2 released versions, but such peaks are way above the capacity. What takes 4 days in primary koji with dozens of builders it takes 2 or 3 weeks in secondaries (ppc, s390) with other work mostly stopped ... Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Mon, Jul 30, 2012 at 2:04 PM, Stewart Adam wrote: > On 12-07-25 6:24 PM, Bill Nottingham wrote: >> >> Package gnofract4d (fails to build) >> comaintained by: firewing > > > Sorry I didn't see this earlier. It looks like this FTBFS was fixed by > jjames on the Jul 26, my thanks! You're welcome. > That said, I no longer have any use for this package. If jjames (or anyone > else) would like to continue maintaining it please feel free to take it. I'm happy to take it, if you will orphan it in pkgdb. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Suggestion: Continuous mass rebuild
On Mon, Jul 30, 2012 at 9:46 PM, Dan Horák wrote: > Richard W.M. Jones píše v Ne 29. 07. 2012 v 18:38 +0100: >> Currently we're doing a mass rebuild about every couple of releases, >> ie. once a year. >> >> Since Dennis Gilmore has written this rebuild script already, why >> don't we run the script more or less continuously? Obviously we could >> pace the builds so they happen for each package about once a month and >> don't overload Koji. >> >> Then we track packages that don't build, say, 3 times in a row, and >> file FTBFS bugs for them and after that prioritize fixing them or kick >> them out of the distro. > > please keep in mind that the resources available to secondary arches are > limited and can't undergo the load the mass rebuild generate. They can > follow the normal load of builds coming from primary for rawhide and > updates for 2 released versions, but such peaks are way above the > capacity. What takes 4 days in primary koji with dozens of builders it > takes 2 or 3 weeks in secondaries (ppc, s390) with other work mostly > stopped ... I agree with this as we experience this with ARM as well. That said the proposed scratch rebuilding in parallel (without committing to git) is something I applaud from a secondary arch PoV as a lot of the build issues I experience on secondary are actually also FTBFS on Primary when I test it further due to some other chance since the build was done so this will get more attention to those issues and help secondary arches greatly as it will be easy to tell if there's a known problem on primary. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
