Re: Self Introduction
Just subscribed! Thanks for the tip. On Wed, Jan 2, 2013 at 2:33 AM, Mo Morsi wrote: > On 12/21/2012 05:06 PM, Moses Mendoza wrote: > > Hello all, > > I'm interested in becoming a Fedora package maintainer, thought I'd > throw out the self-introduction. A bit about me: I currently work as a > release engineer at Puppet Labs in Portland, Oregon, and before that was a > Mac sysadmin for a local college here. Most of my packaging experience has > been gained here at Puppet, packaging our products as rpms, debs, and in > various other forms (my heart has always been with rpm packaging). My > goals here are both to contribute back to Open Source and do my part to > help keep the Fedora platform awesome, and also work with the Fedora > maintainers of puppet to making sure Puppet upstream is a good citizen of > the Fedora community and ease its adoption. In this spirit, I commented on > this BZ https://bugzilla.redhat.com/show_bug.cgi?id=782560 with some help > to move it along as a Puppet dependency, but alas, it hasn't gotten a ton > of traction just yet. Anyway, just thought I'd introduce myself, perhaps in > search of a sponsor. > > Cheers, > Moses Mendoza > mo...@puppetlabs.com > > > Hey Moses, welcome to Fedora! > > If you haven't already, you might be interested in joining the Fedora Ruby > SIG (mailing list here [1]) as there is alot of exciting stuff going on in > the Fedora/Ruby community these days and that's where it's at! > > Take care, > -Mo > > [1] http://fedoraproject.org/wiki/Ruby_SIG > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction
Hi everyone, I am interested in becoming a Fedora package maintainer. I was checking the wiki pages about the 'Fedora Package Maintainers' and found the secion 'Introduce Yourself' (https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Introduce_yourself). I thought I should send out this email and introduce myself. I am 'Sankar Tanguturi'. I work as 'Member of Technical Staff' in 'platform-group' at 'VMware INC, Palo Alto'. Our team takes care of 'VMware Tools' [1] components that run inside the virtual machine. 'VMware Tools' is a suite of utilities that enhances the performance of the virtual machines' guest operating system and improves management of the virtual machine. This suite includes 'VMware Tools service', 'VMware device drivers', 'VMware User process' and 'VMware Tools control panel. 'VMware' released a large portion of VMware Tools for Linux, Solaris and FreeBSD guests under GPL and GPL-compatible licenses. These components are publicly available as an open source project under the name 'Open Virtual Machine Tools' [2]. We are planning to upstream a major part of 'Open Virtual Machine Tools' project in RHEL 7.0. You can check https://bugzilla.redhat.com/show_bug.cgi?id=883614 for more information about our plan for upstreaming. We would like to maintian a package for this in Fedora. I don't have much experience with the installers/packages. I just started checking out wiki pages in 'fedoraproject.org'. So far, all the wikis were very useful to set up my build environment and I was able to write a basic SPEC file and get an initial version of RPM built. Soon, I will send out the work for review. Hope this is a good 'self introduction' about what we are working. [1] - http://bit.ly/VDRzX9 [2] - http://open-vm-tools.sourceforge.net/faq.php -Thanks Sankar Aditya Tanguturi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
> CCing Benjamin if he is again interested in writing > http://gcc.gnu.org/gcc-4.8/porting_to.html and could find this > information useful. Interesting as always, thanks Jakub. Will do. -benjamin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
> CCing Benjamin if he is again interested in writing > http://gcc.gnu.org/gcc-4.8/porting_to.html and could find this > information useful. Interesting as always, thanks Jakub. Will do. -benjamin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GRUB menu hidden by default?
On Fri, 2013-01-04 at 23:29 +0100, Miloslav Trmač wrote: > On Fri, Jan 4, 2013 at 11:20 PM, Adam Williamson wrote: > > Apart from all the bullshit about cars, which part of "it's part of > > upstream grub2" are you people not understanding? This is not our code. > > This is how grub2-mkconfig works. We are not going to get into the game > > of patching bootloader behaviour downstream again. You don't want grub2 > > to generate nested menus by default, you can go upstream and argue with > > the grub developers. Please keep this crap out of Fedora lists. > > Not that I care about the details of grub2 - still I don't understand > the above reasoning. If an user-visible aspect of the user experience > is "not our code" and doesn't belong on these lists, what _does_ > belong on Fedora-devel? After all there is a separate mailing list > even for Anaconda. Well, let's look at the recent threads: "Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19" Hey look, that's about building the distribution. So, 'devel'oping 'fedora'. Seems relevant! "perl-podlators-2.5.0 in F19" notification of a change for dependent package builds: relevant! "Please review vdr-vnsiserver - VDR plugin to handle XBMC clients via VNSI" request for a package review: relevant! It's not like we're short of appropriate discussions. > And if we are not supposed to patch code shipped by upstreams, what > good can Fedora do at all? We provide upstream code in a unified set of repositories, tested to interact properly. Did I say that we're not supposed to patch code shipped by upstream? No. What I said - or rather, the belief my statement was based on, because this isn't exactly what I said - is that we don't generally carry permanent long-term downstream patches just to change upstream behaviour that we disagree with. This is a bad thing to do. Here's what our policies say: https://fedoraproject.org/wiki/Packaging:Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment "All patches should have an upstream bug link or comment All patches in Fedora spec files SHOULD have a comment above them about their upstream status. Any time you create a patch, it is best practice to file it in an upstream bug tracker, and include a link to that in the comment above the patch." This is based on (and links to) https://fedoraproject.org/wiki/Staying_close_to_upstream_projects : "The Fedora Project focuses, as much as possible, on not deviating from upstream in the software it includes in the repository. The following guidelines are a general set of best practices, and provide reasons why this is a good idea, tips for sending your patches upstream, and potential exceptions Fedora might make. The primary goal is to share the benefits of a common codebase for end users and developers while simultaneously reducing unnecessary maintenance efforts." i.e., we try to avoid carrying patches permanently downstream, except in cases where we obviously have to patch something which it would not be appropriate to upstream (say, adding a Fedora logo to the login screen, or something). > (I can perhaps see a case for "we are not going to significantly > diverge from bootloader's upstream again", as a way to avoid repeating > the grub1 semi-fork. However applying it to the configuration of the > bootloader is a stretch.) > Mirek -- 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: GRUB menu hidden by default?
On Fri, Jan 4, 2013 at 11:20 PM, Adam Williamson wrote: > Apart from all the bullshit about cars, which part of "it's part of > upstream grub2" are you people not understanding? This is not our code. > This is how grub2-mkconfig works. We are not going to get into the game > of patching bootloader behaviour downstream again. You don't want grub2 > to generate nested menus by default, you can go upstream and argue with > the grub developers. Please keep this crap out of Fedora lists. Not that I care about the details of grub2 - still I don't understand the above reasoning. If an user-visible aspect of the user experience is "not our code" and doesn't belong on these lists, what _does_ belong on Fedora-devel? After all there is a separate mailing list even for Anaconda. And if we are not supposed to patch code shipped by upstreams, what good can Fedora do at all? (I can perhaps see a case for "we are not going to significantly diverge from bootloader's upstream again", as a way to avoid repeating the grub1 semi-fork. However applying it to the configuration of the bootloader is a stretch.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
Jakub Jelinek píše v Pá 04. 01. 2013 v 21:40 +0100: > sh-elf-binutils-2.21-5.fc19.src.rpm > packages built with -Werror, for which the new > -Wsizeof-pointer-memaccess warning included in -Wall warns > and -Werror makes a fatal error out of it we can probably kill sh-elf-binutils when we have binutils-sh-linux-gnu built from cross-binutils Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
On Fri, Jan 4, 2013 at 1:40 PM, Jakub Jelinek wrote:
> mpir-2.6.0-2.fc19.src.rpm
> similarly to getdata bug, another clear out of bounds access in a
> loop:
> #define numberof(x) (sizeof (x) / sizeof ((x)[0]))
> ...
> for (oindex = 0; oindex <= numberof (offset); oindex++)
> {
> o = offset[oindex];
> ...
> }
This bug is in the tests, not the actual library, so I'm not going to
rebuild right away. I notified upstream of the bug, and upstream
already replied that this will be fixed in the next release. Wow,
that's got to be the fastest response I've ever received to a bug
report.
--
Jerry James
http://www.jamezone.org/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
On Fri, Jan 04, 2013 at 04:41:45PM -0500, Adam Jackson wrote: > Thanks for this! One question... > > On Fri, 2013-01-04 at 21:40 +0100, Jakub Jelinek wrote: > > > llvm-3.1-12.fc19.src.rpm > > gcc bug, not fixed yet, see http://gcc.gnu.org/PR55875 > > My reading of that bug is that -fno-ivopts could be a workaround? Worse > code, but if my options are that and no llvm builds... Yes, but the other option is that the bug is just going to be fixed. It is a P1 bug, so a release blocker, after all. The real mass rebuild won't happen next week... Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
Thanks for this! One question... On Fri, 2013-01-04 at 21:40 +0100, Jakub Jelinek wrote: > llvm-3.1-12.fc19.src.rpm > gcc bug, not fixed yet, see http://gcc.gnu.org/PR55875 My reading of that bug is that -fno-ivopts could be a workaround? Worse code, but if my options are that and no llvm builds... - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GRUB menu hidden by default?
Am 04.01.2013 17:47, schrieb Adam Jackson: > On Fri, 2013-01-04 at 01:26 +0100, Reindl Harald wrote: > >> i would love to also get rid of this useless submenu for >> differenct kernel-versions and ALL the fancy stuff in GRUB >> which is not needed for a clean system boot > > I look forward to your patches oh the code must exist in grubby because submenu is not generated at kernel updates with YUM, only grub2-mkconfig creates it again and destroys booting if your configuration is secured with a password because it removes "--unrestricted" leading to enter password for boot the machine again the other fancy crap goes away with remove "rhgb" and "quiet" rd.plymouth=0 plymouth.enable=0 removes the rest unbelieveable how many time and code was spent in the last years to make a shiny boot hide anything from the users because they could look and learn what their systems does signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
Hi! As part of preparations for possible switch of system compiler in F19 to GCC 4.8.0, we (myself and Marek Polacek) have performed a test mass rebuild of rawhide (December 17th package list) using gcc-4.8.0-0.1.fc19 on x86_64, and for those packages that failed also rebuilt the same package with gcc-4.7.2-9.fc19 to quickly remove from the list packages that fail for non-gcc related reasons. 11687 packages built fine, 933 packages failed to build with both gcc-4.8.0-0.1.f19.x86_64.rpm and gcc-4.7.2-9.fc19.x86_64.rpm (ignored for this analysis, unlikely to be gcc 4.8 related). The remaining packages, that failed to build with 4.8.0-0.1 and succeeded with 4.7.2-9 are listed below. 67 of these look like issues on the package side, 22 gcc bugs that were supposedly fixed by now upstream and thus should be ok in 4.8.0-0.3 when it is built next week and 3 are not yet fixed gcc issues. CCing Benjamin if he is again interested in writing http://gcc.gnu.org/gcc-4.8/porting_to.html and could find this information useful. Besides build failures, the -Wsizeof-pointer-memaccess warning triggered in several packages that succeeded building, but it would be nice if package maintainers actually checked those and fixed up, most likely those are real package bugs. The list of such packages is included in first attachment. For the more aggresive loop optimizations if the loop contain undefined behavior, while it caused build failures just for 12 packages during the mass rebuild, supposedly more packages will be affected, just the problems weren't triggered during package build. Usually such loops are either turned into infinite loops that soon crash, or hang, or as can be seen on the perl-PDL case loops can be turned into just conditional non-looping code (e.g. when compiler assumes that it can validly loop just at most once). blktap-2.0.90-6.git20111216.62de90d.fc18.src.rpm cdrkit-1.1.11-14.fc19.src.rpm elfutils-0.155-1.fc19.src.rpm isomd5sum-1.0.9-2.fc18.src.rpm libopensync-plugin-opie-0.22-8.fc18.src.rpm linphone-3.5.2-4.fc18.src.rpm lldpad-0.9.45-3.fc19.src.rpm openvas-libraries-5.0.4-1.fc19.src.rpm pilot-link-0.12.5-13.fc18.src.rpm sh-elf-binutils-2.21-5.fc19.src.rpm packages built with -Werror, for which the new -Wsizeof-pointer-memaccess warning included in -Wall warns and -Werror makes a fatal error out of it bamf-0.2.104-4.fc18.src.rpm byzanz-0.3-0.5.fc17.src.rpm fvkbd-0.2.2-6.fc18.src.rpm gedit-collaboration-3.6.0-1.fc18.src.rpm gtkimageview-1.6.4-6.fc18.src.rpm gypsy-0.8-6.fc17.src.rpm libindicator-0.4.94-3.fc18.src.rpm ltrace-0.7.0-1.fc19.src.rpm mail-notification-5.4-64.git.eab5c13.fc19.src.rpm ModemManager-0.6.0.0-2.fc19.src.rpm physfs-2.0.2-3.fc18.src.rpm roboptim-core-0.5-6.fc18.src.rpm v8-3.10.8-2.fc18.src.rpm xen-4.2.0-6.fc19.src.rpm packages built with -Werror, for which the new -Wunused-local-typedefs warning included in -Wall warns and -Werror makes a fatal error out of it trafficserver-3.2.0-3.fc18.src.rpm package built with -Werror, and -Wmaybe-uninitialized warns about possibly uninitialized fields which are uninitialized if inc_gmtime_r returns -1 (and ink_time_current_mdy doesn't bother to check that return value) armacycles-ad-0.2.8.3.2-3.fc18.src.rpm irrlicht-1.8-1.fc19.src.rpm kdevelop-4.4.1-2.fc19.src.rpm kst-2.0.3-7.fc18.src.rpm maildrop-2.5.0-17.fc18.src.rpm megaglest-3.7.1-1.fc19.src.rpm opal-3.10.9-2.fc19.src.rpm oxygen-gtk2-1.3.1-1.fc19.src.rpm oxygen-gtk3-1.1.1-2.fc19.src.rpm supertuxkart-0.7.3-3.fc19.src.rpm syncevolution-1.3.2-1.fc19.src.rpm gcc bug - internal compiler error in inline_call, fixed upstream already, see http://gcc.gnu.org/PR55683 pari-2.5.3-1.fc19.src.rpm gcc bug - internal compiler error in LRA, fixed upstream already, see http://gcc.gnu.org/PR55775 avrdude-5.11.1-2.fc18.src.rpm gcc bug - internal compiler error in remove_redundant_iv_tests, fixed upstream already, see http://gcc.gnu.org/PR55684 openttd-1.2.2-1.fc19.src.rpm gcc bug - the package is built with LTO, and the problem is extremely hard to reduce, just rebuild without --with-lto for now b43-openfwwf-5.2-8.fc18.src.rpm ccache-3.1.8-1.fc18.src.rpm openchange-1.0-12.fc19.src.rpm openttd-opengfx-0.4.5-1.fc19.src.rpm samba-4.0.0-171.fc19.rc6.src.rpm /usr/include/stdc-predef.h issues gcc preprocessor now in C/C++ modes automatically includes header, packages which are using preprocessor for non-C/C++ code or doing weird things with the preprocessor might run into issues. For non-C/C++ code, it is always better to preprocess as assembly instead of C libxc-1.2.0-2.fc18.src.rpm /usr/include/stdc-predef.h issues - using cpp -C -ansi to preprocess Fortran sources is simply a very bad idea adobe-source-libraries-1.0.43-13.fc19.src.rpm asl-gcc.patch patch needs to be tweaked also for
Re: Fedora ARM F18 Beta VFAD - Test Images posted
On 01/04/2013 07:01 AM, Lukas Zapletal wrote: Pardon my ignorance, but where can I find the kernel images? These are just root systems, right? I'd love to try Kirkwood on NSA-310. If you want to test the kernel used in the F18 ARM Beta release candidate the best option is to download the kirkwood image then extract the kernel and initramfs. Here's a link to the image: http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta-rc1/F18-kirkwood-20121220.img.xz Ucompress and as root use kpartx to expose the partitions as loopback devices: xz -d F18-kirkwood-20121220.img.xz kpartx -av F18-kirkwood-20121220.img From here you can mount the partition with the files you need. I'm not sure which one it is so you'll have to experiment: mount /dev/mapper/loop0p1 /somewhere Good luck, and don't forget to umount and kpartx -d that image when you're done. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Please review vdr-vnsiserver - VDR plugin to handle XBMC clients via VNSI
Hi Till, Alex and I are already packaging opdenkamp's xbmc-pvr-addons inside the xbmc package RPM Fusion. We're shipping this plugin there.[1] I'd be interested in collaborating with you on the best way to package the plugins. Our latest spec file is in Git [2], along with some notes in a TODO file about how to best split off these plugins. The pvr-addons have been in flux for a while, so that's why we bundled them in XBMC. However, it may make sense to eventually ship them as a separate "xbmc-pvr-addons" package, or even separate plugins (as you've done there). - Ken [1] http://ktdreyer.fedorapeople.org/xbmc/vdr-vnsi-client.png [2] http://fedorapeople.org/cgit/alexlan/public_git/xbmc-rpm.git On Fri, Jan 4, 2013 at 3:12 AM, Dr. Tilmann Bubeck wrote: > Hello! > > Could someone please review > > https://bugzilla.redhat.com/show_bug.cgi?id=887611 > > It is a very small package to use VDR (Video Disc Recorder) for the upcoming > XBMC version 12. VDR is already part of Fedora and can then be used together > with XBMC. > > There were already some feedbacks for the SPEC file which resulted in an > updated version for review. It is close to final. > > Thanks for any support! > Till > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
perl-podlators-2.5.0 in F19
I'm building latest 2.5.0 version of perl-podlators in rawhide now. This package provides tools pod2man and pod2text. Version 2.5.0 makes failing these two tools, if syntax error is found in input POD document. So if your package (building script) uses one of these two tools and starts failing, you have a typo probably in documentation. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GRUB menu hidden by default?
On Fri, 2013-01-04 at 01:26 +0100, Reindl Harald wrote: > i would love to also get rid of this useless submenu for > differenct kernel-versions and ALL the fancy stuff in GRUB > which is not needed for a clean system boot I look forward to your patches. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-DateTime-Format-Pg] update to 0.16008
commit 3d0e7842bb81d16b0524aeafb3dc2830e35d6d56
Author: Iain Arnell
Date: Fri Jan 4 09:35:08 2013 -0700
update to 0.16008
.gitignore |1 +
perl-DateTime-Format-Pg.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 807e674..70e5db1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
DateTime-Format-Pg-0.16004.tar.gz
/DateTime-Format-Pg-0.16005.tar.gz
/DateTime-Format-Pg-0.16007.tar.gz
+/DateTime-Format-Pg-0.16008.tar.gz
diff --git a/perl-DateTime-Format-Pg.spec b/perl-DateTime-Format-Pg.spec
index 8680305..5e85184 100644
--- a/perl-DateTime-Format-Pg.spec
+++ b/perl-DateTime-Format-Pg.spec
@@ -1,6 +1,6 @@
Name: perl-DateTime-Format-Pg
-Version:0.16007
-Release:4%{?dist}
+Version:0.16008
+Release:1%{?dist}
Summary:Parse and format PostgreSQL dates and times
License:GPL+ or Artistic
Group: Development/Libraries
@@ -66,6 +66,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Jan 04 2013 Iain Arnell 0.16008-1
+- update to latest upstream version
+
* Fri Jul 20 2012 Fedora Release Engineering
- 0.16007-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
diff --git a/sources b/sources
index d722b1a..9768cdc 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-6fe01e4e42a3b57b9f92e738b26a50f9 DateTime-Format-Pg-0.16007.tar.gz
+1a10b6eb5573a666b1061991cfa28f58 DateTime-Format-Pg-0.16008.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-podlators] 2.5.0 bump
commit 9f6bf126f1b0cd18da6e57acb5254c6ce1382945
Author: Petr Písař
Date: Fri Jan 4 17:33:19 2013 +0100
2.5.0 bump
.gitignore |1 +
.rpmlint|2 ++
perl-podlators.spec |8 ++--
sources |2 +-
4 files changed, 10 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 9fe6995..22b3fdc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/podlators-2.4.2.tar.gz
+/podlators-2.5.0.tar.gz
diff --git a/.rpmlint b/.rpmlint
new file mode 100644
index 000..efd792c
--- /dev/null
+++ b/.rpmlint
@@ -0,0 +1,2 @@
+from Config import *
+addFilter("spelling-error .* rpmlint");
diff --git a/perl-podlators.spec b/perl-podlators.spec
index 4076b3c..3e34ce2 100644
--- a/perl-podlators.spec
+++ b/perl-podlators.spec
@@ -1,6 +1,6 @@
Name: perl-podlators
-Version:2.4.2
-Release:3%{?dist}
+Version:2.5.0
+Release:1%{?dist}
Summary:Format POD source into various output formats
License:GPL+ or Artistic
Group: Development/Libraries
@@ -58,6 +58,10 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Jan 04 2013 Petr Pisar - 2.5.0-1
+- 2.5.0 bump
+- This version makes pod2* tools failing if POD syntax error is encountered
+
* Thu Nov 01 2012 Petr Pisar - 2.4.2-3
- Do not export under-specified dependencies
diff --git a/sources b/sources
index b10d9a4..1b373c0 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-6fc141b0ab668b7d52aa48c26909d604 podlators-2.4.2.tar.gz
+964f19e1ab23420a2f7c8753943b8a03 podlators-2.5.0.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
File podlators-2.5.0.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-podlators: 964f19e1ab23420a2f7c8753943b8a03 podlators-2.5.0.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: prefered way of configuring X11 keyboard layouts in F18
On Fri, Jan 4, 2013 at 7:23 AM, Adam Williamson wrote: > On Mon, 2012-12-31 at 15:01 -0800, Adam Williamson wrote: > >> As discussed in the bug, if systemd-localed is doing 'fuzzy matching' it >> may be the case that we actually get a decent match for most layouts, >> I'll have to do more testing. But the situation is clearly different to >> the F17 one in that we are now relying on systemd-localed to map xkb >> layouts to console ones, where we really weren't before. There is >> certainly at least a potential for regression here. The systemd-localed >> list of keymaps may not have regressed but it has taken on more >> significance. > > OK. Since that last mail I investigated things in quite a lot more > detail. > > The big takeaway from that: the gap between 'kbd' and 'xkb' coverage is > just way too large for this 'mapping' solution to be practical going > forward. We really need the code to support xkb layouts at the console, > it is the only sane way forward. I have sent patches to systemd to > improve the xkb<->kbd mapping a little bit, but there are just huge > swathes of layouts xkb has which kbd simply does not have, and there's > no way to patch around that. We simply need to ditch kbd and have One > True Source Of Keymaps. This should be a high priority for F19 > development. If I could write code, this is the code I would be writing. Either way, this is the kind of code I used to enjoy writing, back in another life. Too bad I have to work at something else these days to pay rent and feed the wife and kids. But, knowing first hand about how many different keyboard layouts, controllers, manufacturers, sources of the maps and other documentation, etc., there are, I'd agree with your conclusion that it's a lot of work to go to for not much gain, to duplicate the xkb keymaps for kbd. I'm definitely guessing that all the strange irregular details make automated conversion a really hard problem. Setting up different automatic conversion programs for different classes of keyboards might be a good approach (and a good job for long-term job security if someone were paying for it). But I think it would not be particularly timely, relative to coming releases of Fedora. -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-ZMQ-LibZMQ2] Update to version 1.04
commit 06aeaa2487f416443c09a5b4039bb624f95315c7
Author: Jose Pedro Oliveira
Date: Fri Jan 4 16:53:34 2013 +
Update to version 1.04
.gitignore|1 +
perl-ZMQ-LibZMQ2.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index dfc0feb..137dc84 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/ZMQ-LibZMQ2-1.03.tar.gz
+/ZMQ-LibZMQ2-1.04.tar.gz
diff --git a/perl-ZMQ-LibZMQ2.spec b/perl-ZMQ-LibZMQ2.spec
index 8db32c3..ce3f7ba 100644
--- a/perl-ZMQ-LibZMQ2.spec
+++ b/perl-ZMQ-LibZMQ2.spec
@@ -1,6 +1,6 @@
Name: perl-ZMQ-LibZMQ2
-Version:1.03
-Release:2%{?dist}
+Version:1.04
+Release:1%{?dist}
Summary:Perl wrapper for the libzmq 2.x library
License:GPL+ or Artistic
@@ -58,6 +58,9 @@ make test
%changelog
+* Fri Jan 4 2013 Jose Pedro Oliveira - 1.04-1
+- Update to version 1.04
+
* Thu Dec 27 2012 Jose Pedro Oliveira - 1.03-2
- Handle review itens (#868529)
diff --git a/sources b/sources
index c164406..94bd41e 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2a309240a34a43dea4107df77ef0cdf0 ZMQ-LibZMQ2-1.03.tar.gz
+48b3d706d3037db5a4cb425dd044c5fd ZMQ-LibZMQ2-1.04.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-BackPAN-Index] update to 0.42
commit e0042caa6e3bbe22c48e58381dc1ec569f7a4222
Author: Iain Arnell
Date: Fri Jan 4 08:51:20 2013 -0700
update to 0.42
.gitignore |1 +
perl-BackPAN-Index.spec | 18 +++---
sources |2 +-
test-no-internet.patch | 21 -
4 files changed, 9 insertions(+), 33 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 865b6b0..638030f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/BackPAN-Index-0.39.tar.gz
/BackPAN-Index-0.40.tar.gz
+/BackPAN-Index-0.42.tar.gz
diff --git a/perl-BackPAN-Index.spec b/perl-BackPAN-Index.spec
index 87a6bb4..05fceb1 100644
--- a/perl-BackPAN-Index.spec
+++ b/perl-BackPAN-Index.spec
@@ -1,38 +1,33 @@
Name: perl-BackPAN-Index
-Version:0.40
-Release:7%{?dist}
+Version:0.42
+Release:1%{?dist}
Summary:Interface to the BackPAN index
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/BackPAN-Index/
Source0:
http://www.cpan.org/authors/id/M/MS/MSCHWERN/BackPAN-Index-%{version}.tar.gz
-# force tests to run with local backpan index
-Patch0: test-no-internet.patch
BuildArch: noarch
BuildRequires: perl(App::Cache) >= 0.37
BuildRequires: perl(Archive::Extract)
BuildRequires: perl(autodie)
BuildRequires: perl(CLASS) >= 1.00
-BuildRequires: perl(Class::Accessor::Fast)
BuildRequires: perl(CPAN::DistnameInfo) >= 0.09
BuildRequires: perl(DBD::SQLite) >= 1.25
BuildRequires: perl(DBIx::Class) >= 0.08109
-BuildRequires: perl(DBIx::Class::Schema::Loader) >= 0.05003
BuildRequires: perl(File::Path)
BuildRequires: perl(File::Spec)
BuildRequires: perl(File::Spec::Unix)
BuildRequires: perl(LWP::Simple)
BuildRequires: perl(Module::Build) >= 0.37
+BuildRequires: perl(Mouse) >= 0.64
BuildRequires: perl(parent)
BuildRequires: perl(Path::Class) >= 0.17
BuildRequires: perl(Test::Compile) >= 0.11
BuildRequires: perl(Test::More) >= 0.90
-BuildRequires: perl(URI::file)
+BuildRequires: perl(URI) >= 1.54
Requires: perl(CLASS) >= 1.00
-Requires: perl(Class::Accessor::Fast)
Requires: perl(DBD::SQLite) >= 1.25
Requires: perl(DBIx::Class) >= 0.08109
-Requires: perl(DBIx::Class::Schema::Loader) >= 0.05003
Requires: perl(Path::Class) >= 0.17
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
@@ -51,7 +46,6 @@ for efficient querying.
%prep
%setup -q -n BackPAN-Index-%{version}
-%patch0 -p 1
sed -i -e '1s~^#!.*perl~#!%{__perl}~' examples/backpan.pl
@@ -69,12 +63,14 @@ find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null
\;
BACKPAN_INDEX_TEST_NO_INTERNET=1 ./Build test
%files
-%defattr(-,root,root,-)
%doc CHANGES examples LICENSE README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Fri Jan 04 2013 Iain Arnell 0.42-1
+- update to latest upstream version
+
* Fri Jul 20 2012 Fedora Release Engineering
- 0.40-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
diff --git a/sources b/sources
index cf15e33..5713fc4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-e95c44656032890ef7925a778467ab34 BackPAN-Index-0.40.tar.gz
+14404bf91f6a0a65782701d2ee0ea1bb BackPAN-Index-0.42.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: Fedora ARM F18 Beta VFAD - Test Images posted
Hi Lukas, Have you tried kernel.org? On Jan 4, 2013 7:01 AM, "Lukas Zapletal" wrote: > Pardon my ignorance, but where can I find the kernel images? These are > just root systems, right? I'd love to try Kirkwood on NSA-310. > > Thanks! > > LZ > > On Mon, Dec 03, 2012 at 12:57:19PM -0500, Paul Whalen wrote: > > Please join us today (December 3rd, 2012) in #fedora-arm on Freenode for > another Fedora ARM VFAD. > > > > There are a number of pre-created F18 ARM Beta TC1 images available for > testing, including: Pandaboard, > > Trimslice, vexpress (QEMU) and Kirkwood. > > > > Images can be downloaded from: > > http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta-tc1/ > > > > Please help us track the results by adding your findings to: > > > https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/2012-12-03-VFAD-Fedora_18_Beta > > > > All help is appreciated and we look forward to your participation. > > > > Thanks, > > Paul > > -- > > devel mailing list > > devel@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/devel > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM F18 Beta VFAD - Test Images posted
Pardon my ignorance, but where can I find the kernel images? These are just root systems, right? I'd love to try Kirkwood on NSA-310. Thanks! LZ On Mon, Dec 03, 2012 at 12:57:19PM -0500, Paul Whalen wrote: > Please join us today (December 3rd, 2012) in #fedora-arm on Freenode for > another Fedora ARM VFAD. > > There are a number of pre-created F18 ARM Beta TC1 images available for > testing, including: Pandaboard, > Trimslice, vexpress (QEMU) and Kirkwood. > > Images can be downloaded from: > http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta-tc1/ > > Please help us track the results by adding your findings to: > https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/2012-12-03-VFAD-Fedora_18_Beta > > All help is appreciated and we look forward to your participation. > > Thanks, > Paul > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Later, Lukas "lzap" Zapletal #katello #systemengine -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Language-Prolog-Yaswi] Rebuild against pl-6.2.5
commit a093e00740d64b69ab81a6aedeab5d7f3b454c81
Author: Petr Písař
Date: Fri Jan 4 14:45:24 2013 +0100
Rebuild against pl-6.2.5
perl-Language-Prolog-Yaswi.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Language-Prolog-Yaswi.spec b/perl-Language-Prolog-Yaswi.spec
index 4bee738..753ae72 100644
--- a/perl-Language-Prolog-Yaswi.spec
+++ b/perl-Language-Prolog-Yaswi.spec
@@ -1,6 +1,6 @@
Name: perl-Language-Prolog-Yaswi
Version:0.21
-Release:8%{?dist}
+Release:9%{?dist}
Summary:Yet another interface to SWI-Prolog
License:GPL+ or Artistic
Group: Development/Libraries
@@ -62,6 +62,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Jan 04 2013 Petr Pisar - 0.21-9
+- Rebuild against pl-6.2.5
+
* Fri Dec 14 2012 Petr Pisar - 0.21-8
- Rebuild against pl-6.2.4
--
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
F-18 Branched report: 20130104 changes
Compose started at Fri Jan 4 09:15:28 UTC 2013 Updated Packages: dracut-024-18.git20130102.fc18 -- * Wed Jan 02 2013 Harald Hoyer 024-18.git20130102 - fixed rd.driver.* kernel command line arguments by creating /etc/modprobe.d Resolves: rhbz#873220 - fixed btrfs subvol mounting for /usr, if root is also on a subvol Resolves: rhbz#890577 Summary: Added Packages: 0 Removed Packages: 0 Upgraded Packages: 1 Compose finished at Fri Jan 4 13:40:26 UTC 2013 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Please review vdr-vnsiserver - VDR plugin to handle XBMC clients via VNSI
Hello! Could someone please review https://bugzilla.redhat.com/show_bug.cgi?id=887611 It is a very small package to use VDR (Video Disc Recorder) for the upcoming XBMC version 12. VDR is already part of Fedora and can then be used together with XBMC. There were already some feedbacks for the SPEC file which resulted in an updated version for review. It is close to final. Thanks for any support! Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
