Re: gcc 4.6 for package monkeys
On Fri, Jan 28, 2011 at 08:26:36AM +0100, Julian Sikorski wrote: I have just run into an issue with gcc-4.6, namely RPM Fusion's mame failed to compile [1]. I was told that #include stddef.h was missing. So I have two questions: why did including this header directly became necessary (code builds fine with 4.5) and are there any other issues we package monkeys might run into with a new compiler? Some C++ headers were including cstdef header internally just so that they could use std::size_t and std::ptrdiff_t. Those types are in 4.6+ defined in an internal libstdc++ header using compiler builtin preprocessor macros (that existed for a while), so if you need anything else from cstddef/stddef.h, you need to include it yourself, as basically none of the standard C++ headers include cstddef any more. For more details see: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00257.html http://gcc.gnu.org/viewcvs?root=gccview=revrev=160231 Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc 4.6 for package monkeys
On Thu, Jan 27, 2011 at 11:29:45PM -0800, Garrett Holmstrom wrote: On 1/27/2011 23:26, Julian Sikorski wrote: I have just run into an issue with gcc-4.6, namely RPM Fusion's mame failed to compile [1]. I was told that #includestddef.h was missing. So I have two questions: why did including this header directly became necessary (code builds fine with 4.5) and are there any other issues we package monkeys might run into with a new compiler? GCC 4.6 changed a lot of compiler warnings to errors, so a lot of code (especially C++ code) that used to get away with violations like omitting headers or assigning to un-assignable things will now fail to build. Care to share details? Of course there were many changes in the C++ FE, especially for C++0x, and maybe some warnings changed into errors, but nothing I'd describe as a lot. We haven't still written http://gcc.gnu.org/gcc-4.6/porting_to.html so if you have interesting info about changes that affect a lot of packages, details would be certainly welcome. The STL changes not to include cstddef internally is certainly one thing that will be added there. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc 4.6 for package monkeys
On Fri, Jan 28, 2011 at 12:11 AM, Jakub Jelinek ja...@redhat.com wrote: On Thu, Jan 27, 2011 at 11:29:45PM -0800, Garrett Holmstrom wrote: On 1/27/2011 23:26, Julian Sikorski wrote: I have just run into an issue with gcc-4.6, namely RPM Fusion's mame failed to compile [1]. I was told that #includestddef.h was missing. So I have two questions: why did including this header directly became necessary (code builds fine with 4.5) and are there any other issues we package monkeys might run into with a new compiler? GCC 4.6 changed a lot of compiler warnings to errors, so a lot of code (especially C++ code) that used to get away with violations like omitting headers or assigning to un-assignable things will now fail to build. Care to share details? Of course there were many changes in the C++ FE, especially for C++0x, and maybe some warnings changed into errors, but nothing I'd describe as a lot. We haven't still written http://gcc.gnu.org/gcc-4.6/porting_to.html so if you have interesting info about changes that affect a lot of packages, details would be certainly welcome. The STL changes not to include cstddef internally is certainly one thing that will be added there. Jakub -- 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: fedpkg build version numbering discrepancy
On Thu, 27 Jan 2011 18:10:31 -0500, Jean-Marc wrote:
Hello,
Hoping to be wrong.
Today I was working on my package after a long time,
I upgraded from version 2.1-320 to 2.1-400.
I didn't fedpkg new-sources and only updated
the spec file to be 2.1-400 (sources file was
still referring to 2.1-320).
fedpkg commit ; fedpkg push
Next, fedpkg build
Koji reported me 2.1-400 was compiled no trouble.
how come? new tar file was not event uploaded...
Is my understanding right?, koji build
report spec file version while crunching
sources file version!
Did I missed something or we are in easy mistake
situation??.
I'm aware this has been solved in the rest of this thread already,
so just a comment on what else has happened to some packagers before:
They didn't use %{version} in the Source tag URL and used a %setup with
options to specify a custom version-less builddir. So. the source tarball
from the sources file had a different version than %version and no
version in its root directory name. As why this hadn't been an obvious
mistake? %version and %release consisted of an overly complex
concatenation of several macro-fied numbers related to the upstream
versioning scheme, which made the spec less readable.
rversion=2.1
subversion=400
Spec file extract:
Version: %{rversion}.%{subversion}
Source: ./%{name}-%{version}.tar.gz
IMO, it would be more clear to separate strictly between upstream version
(= tarball version) and Fedora package version. Apparently, both are the
same in your case, so why reconstruct them? Once you've started a particular
versioning scheme, you don't win a lot of flexibility by hiding the real
version in variables. You only increase the risk that an improper version
bump breaks the upgrade path, i.e. one cannot mess with %subversion anyway
and must increment it correctly in the context of the full %version. The
full %version is also absolutely important with regard to versioned
dependencies, Obsoletes and Provides. It would be fine to just use
Version: 2.1.400
and if the 2.1 prefix is really needed elsewhere in the spec file and
perhaps has a meaning other than being just a number, assign it to a
separate variable.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
debugfs query
Hi, Currently Fedora doesn't automatically mount debugfs at boot time. So I thought that it might be worth asking whether this should be the case? One alternative would be to only mount it when a package was installed that requires debugfs. The issue there is that there are potentially, at least, multiple packages and they would need to cooperate somehow in mounting debugfs. They could do it be appending a line to fstab, or they could use their own scripts to mount it. Is there a preferred method? Bearing in mind that it would be a lot simpler just to have debugfs mounted as part of the default fstab, that would be my suggested solution, unless there is a good reason not to do that? Steve. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110128 changes
Compose started at Fri Jan 28 08:15:23 UTC 2011 Broken deps for x86_64 -- beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit) beagle-0.3.9-19.fc14.x86_64 requires libwv-1.2.so.3()(64bit) bugzilla-3.6.4-1.fc15.noarch requires perl(DBD::Oracle) bugzilla-3.6.4-1.fc15.noarch requires perl(DBI::db) bugzilla-3.6.4-1.fc15.noarch requires perl(DBI::st) cairo-java-1.0.8-2.fc15.i686 requires libgcj.so.11 cairo-java-1.0.8-2.fc15.x86_64 requires libgcj.so.11()(64bit) coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Osetb) = 0:8f21a0a4f771662673604ed92a237d79 coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Flag) = 0:88862d84db594e5181afc1c5f7aa87fb coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(ANSITerminal) = 0:3d0d1700618d8b3a4e4b2308f28cefb6 coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Oassocb) = 0:d873c4a1eeb6fa5c5333f8658c49d1db coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Dumper) = 0:76126ba149caeb2d34f12e11187a9d4e coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(SetPt) = 0:b69c030e8ca717d556d3d9bd2a5d22fd coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Setb) = 0:93bdb588146a13126bfad4eab6c58206 coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Mapb) = 0:617c09a110cef9f040335b35078c7234 coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Sexplib) = 0:a990ea80438337d5407bbc0343c7236a coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Ograph2way) = 0:7442f647b0a74ed48a5c9361fc42ccc4 coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Oassoch) = 0:87f7dc2635e5a7ed1ab03b7cd5380ace coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Oassoc_buffer) = 0:cf6fbee4fcc6644a0a90f07da8eb6c7b coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Oseti) = 0:a937e7661f510c17bfd21d4372507795 compat-gcc-34-c++-3.4.6-20.fc14.x86_64 requires libstdc++ 0:4.6.0 cpm-0.23-0.3.beta.fc12.x86_64 requires libdotconf-1.0.so.0()(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dh-make-0.55-2.fc15.noarch requires debhelper eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit) fmt-ptrn-java-1.3.21-1.fc15.i686 requires libgcj.so.11 fmt-ptrn-java-1.3.21-1.fc15.x86_64 requires libgcj.so.11()(64bit) frysk-0.4-28.fc15.x86_64 requires libgcj.so.11()(64bit) frysk-devel-0.4-28.fc15.i386 requires libgcj.so.11 frysk-devel-0.4-28.fc15.x86_64 requires libgcj.so.11()(64bit) frysk-gnome-0.4-28.fc15.x86_64 requires libgcj.so.11()(64bit) gdcm-2.0.16-8.fc15.i686 requires libopenjpeg.so.2 gdcm-2.0.16-8.fc15.x86_64 requires libopenjpeg.so.2()(64bit) gedit-vala-0.10.2-2.fc15.i686 requires libvala-0.10.so.0 gedit-vala-0.10.2-2.fc15.x86_64 requires libvala-0.10.so.0()(64bit) glib-java-0.4.2-3.fc15.i686 requires libgcj.so.11 glib-java-0.4.2-3.fc15.x86_64 requires libgcj.so.11()(64bit) 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-gmail-notifier-0.10.1-1.fc14.x86_64 requires libnotify.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-gdl-2.25.3-22.fc15.x86_64 requires libgdl-1.so.3()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0 gnustep-back-0.18.0-4.fc14.x86_64 requires libobjc.so.2()(64bit) gnustep-base-1.20.1-2.fc14.i686 requires libobjc.so.2 gnustep-base-1.20.1-2.fc14.x86_64 requires libobjc.so.2()(64bit) gnustep-examples-1.3.0-4.fc15.x86_64 requires libobjc.so.2()(64bit) gnustep-gui-0.18.0-2.fc14.x86_64 requires libobjc.so.2()(64bit) gnustep-gui-libs-0.18.0-2.fc14.i686 requires libobjc.so.2 gnustep-gui-libs-0.18.0-2.fc14.x86_64 requires libobjc.so.2()(64bit) gorm-1.2.12-2.fc15.i686 requires libobjc.so.2 gorm-1.2.12-2.fc15.x86_64 requires libobjc.so.2()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libgdl-1.so.3()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires
again, was Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you. (fwd)
This nonsense is still present in th el5 package. Can a provenpackager please get rid of it. Bug 522053 is even closed now Paul Preparing...### [100%] 1:tor-core ### [ 33%] 2:tor-lsb### [ 67%] /var/tmp/rpm-tmp.70176: line 1: /usrp/lib/lsb/install_initd: No such file or directory oouch... redhat-lsb is still broken. See the report https://bugzilla.redhat.com/show_bug.cgi?id=522053 for details. 3:tor### [100%] error: %postun(tor-lsb-0.2.1.19-4.el5.x86_64) scriptlet failed, exit status 1 -- Forwarded message -- Date: Thu, 3 Jun 2010 13:48:31 -0400 From: Matthew Miller mat...@mattdm.org To: Development discussions related to Fedora devel@lists.fedoraproject.org Subject: Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you. On Wed, Jun 02, 2010 at 02:55:53AM +0200, Kevin Kofler wrote: FYI, FESCo decided on this particular issue that a provenpackager can fix tor to comply with our initscripts guidelines for released Fedoras. (As far as I know, the maintainer already fixed the Rawhide package.) It's true; it is fixed in Rawhide. Okay then. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- 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: Haskell packaging questions
Hi Andrew,
Please have a look at the review template here
[1]http://narasim.fedorapeople.org/haskell_review_template.txt. Some
items from the Package review guidelines which do not apply are
marked [NA].
The cabal2spec program generates the template for the .spec file from the
.cabal file. Then the packager modifies certain values and thats about it.
The macros used in the template come from /etc/rpm/macros.ghc. There are
cases were there is a need to add some files not picked by the macros and
that has been done. Eg
[2]http://petersen.fedorapeople.org/ghc-gtk/ghc-gtk.spec
For haskell packaging/review related queries , you could also mail to
fedora-haskell-l...@redhat.com or ask at #fedora-haskell .
-Thanks
On Sat, Jan 29, 2011 at 12:38 AM, Andrew McNabb amcn...@mcnabbs.org wrote:
I recently came across an issue in a package review where I would
appreciate guidance. In particular, I have never dealt with Haskell
packages before, and I haven't been able to find enough detail in the
Haskell Packaging Guidelines to answer my questions:
http://fedoraproject.org/wiki/Packaging/Haskell
It seems that there's a tool called cabal2spec that autogenerates spec
files for Haskell programs. However, the spec files that it outputs are
a little unusual.
The spec file I'm reviewing has no %package sections and no %files
sections. Instead, there is a reference to a %{?ghc_lib_package}
macro that implicitly defines the package and two subpackages. The
Haskell Packaging Guidelines don't seem to describe how all of the magic
works, so I'm not quite sure what standards I'm supposed to use in my
review. Here's a link to the package request:
https://bugzilla.redhat.com/show_bug.cgi?id=662258
It looks like other Haskell libraries are packaged in a similar way, but
it's enough different from most packages that the Package Review
Guidelines don't seem to cleanly apply. I would appreciate advice on
how to proceed. Thanks.
--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Regards
Lakshmi Narasimhan T V
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 673125] perl-Module-Build-0.3624 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=673125 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Module-Build-0.3623 is |perl-Module-Build-0.3624 is |available |available --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org 2011-01-28 03:20:37 EST --- Latest upstream release: 0.3624 Current version in Fedora Rawhide: 0.3607 URL: http://search.cpan.org/dist/Module-Build/ Please consult the package update guidelines before you issue an update to a stable branch: https://fedoraproject.org/wiki/Package_update_guidelines More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- 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
[Bug 673435] New: perl-Capture-Tiny-0.09 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Capture-Tiny-0.09 is available https://bugzilla.redhat.com/show_bug.cgi?id=673435 Summary: perl-Capture-Tiny-0.09 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Capture-Tiny AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora Latest upstream release: 0.09 Current version in Fedora Rawhide: 0.08 URL: http://search.cpan.org/dist/Capture-Tiny/ Please consult the package update guidelines before you issue an update to a stable branch: https://fedoraproject.org/wiki/Package_update_guidelines More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- 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
Re: Patches for CVE-2011-0009
On 01/27/2011 12:43 AM, Xavier Bachelot wrote: On 01/26/2011 09:16 PM, Xavier Bachelot wrote: On 01/26/2011 12:00 AM, Xavier Bachelot wrote: Hi, I've been looking at the issue for both rt 3.6 and 3.8. I have a rather full featured patch for 3.8 and I took the Debian patch for 3.6. However, I'm not happy with 3.6, it's lacking the script to fix all the passwords. I'll try to come up with something better in the next few days. Here's my WIP for reference. Regards, Xavier Here are the updated patches against master and el5 branches. I only have an rt 3.6 to test against, so the 3.8 patch is not run time tested, but I'm confident. The only missing bit is a paragraph about the password mass-update script in the UPGRADING file for 3.6. Sorry, slightly wrong patches, it was missing the patch to the UPGRADING file. Here is a fixed one for 3.8. I've pushed the 3.6 patch to el5. http://koji.fedoraproject.org/koji/taskinfo?taskID=2744662 https://admin.fedoraproject.org/updates/rt3-3.6.10-2.el5 Ralf, Mark, I let you give a test at 3.8 on Rawhide/F14/F13 and EL6, respectively. Xavier, please don't try to rush it. I'm not trying to rush anything. I'm satisfied with the patches I have, so I've built the rpms for the OS release I'm running in production. I've indeed tested it locally. However I can't test against rawhide, F13, F14 and EL6, because I don't have any RT instance with this releases. I obviously won't commit anything to this branches and let this for people that can actually test the patches. So far, from visual inspection only, I am not necessarily opposed to your patch but I like the debian patches more. Imho, the Debian patches are incomplete. It only fixes password hashes upon user login, which is not enough to fix the security issue. You can't expect to force all users to log in and all hashes that have not been updated are still vulnerable to a brute force attack. The only real solution is to use the vulnerable-passwords script to mass update them. This script is missing with the Debian patches. My own patches were created using the commits from the 3.8-salted_password branch from RT's git repository, that I then adapted to target 3.6. Regards, Xavier -- 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-JSON-PP] Created tag perl-JSON-PP-2.27104-3.fc15
The lightweight tag 'perl-JSON-PP-2.27104-3.fc15' was created pointing to: 7c46ef9... Initial import (perl-JSON-PP-2.27104-3) -- 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 673435] perl-Capture-Tiny-0.09 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=673435 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC|mmasl...@redhat.com |ppi...@redhat.com AssignedTo|mmasl...@redhat.com |ppi...@redhat.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- 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
[Bug 673435] perl-Capture-Tiny-0.09 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=673435 --- Comment #1 from Petr Pisar ppi...@redhat.com 2011-01-28 05:03:49 EST --- Created attachment 475764 -- https://bugzilla.redhat.com/attachment.cgi?id=475764 Upgrade to 0.09 Hanging patch as I have no write access right now. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- 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
File Capture-Tiny-0.09.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Capture-Tiny: 189a521f75b918402571cdc8b7c934bf Capture-Tiny-0.09.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
Broken dependencies: perl-RPM2
perl-RPM2 has broken dependencies in the rawhide tree: On x86_64: perl-RPM2-0.68-9.fc15.x86_64 requires librpmio.so.1()(64bit) perl-RPM2-0.68-9.fc15.x86_64 requires librpm.so.1()(64bit) On i386: perl-RPM2-0.68-9.fc15.i686 requires librpm.so.1 perl-RPM2-0.68-9.fc15.i686 requires librpmio.so.1 Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Spreadsheet-WriteExcel
perl-Spreadsheet-WriteExcel has broken dependencies in the rawhide tree: On x86_64: perl-Spreadsheet-WriteExcel-2.37-3.fc15.noarch requires perl(Apache::URI) perl-Spreadsheet-WriteExcel-2.37-3.fc15.noarch requires perl(Apache::Request) On i386: perl-Spreadsheet-WriteExcel-2.37-3.fc15.noarch requires perl(Apache::URI) perl-Spreadsheet-WriteExcel-2.37-3.fc15.noarch requires perl(Apache::Request) Please resolve this as soon as possible. -- 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-Spreadsheet-WriteExcel] * Fri Jan 28 2011 Oliver Falk oli...@linux-kernel.at - 2.37-4 - Rebuild
commit 9619737402f322c37771bb0a76ba9beb1ecb35cc
Author: Oliver Falk oli...@linux-kernel.at
Date: Fri Jan 28 14:27:31 2011 +0100
* Fri Jan 28 2011 Oliver Falk oli...@linux-kernel.at - 2.37-4
- Rebuild
perl-Spreadsheet-WriteExcel.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Spreadsheet-WriteExcel.spec b/perl-Spreadsheet-WriteExcel.spec
index 5ec632e..af13f8b 100644
--- a/perl-Spreadsheet-WriteExcel.spec
+++ b/perl-Spreadsheet-WriteExcel.spec
@@ -1,6 +1,6 @@
Name: perl-Spreadsheet-WriteExcel
Version: 2.37
-Release: 3%{?dist}
+Release: 4%{?dist}
Summary: Write formatted text and numbers to a cross-platform
Excel binary file
Group: Development/Libraries
@@ -79,6 +79,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*.3*
%changelog
+* Fri Jan 28 2011 Oliver Falk oli...@linux-kernel.at - 2.37-4
+- Rebuild
+
* Thu Jan 27 2011 Oliver Falk oli...@linux-kernel.at - 2.37-3
- Rebuild with new perl-5.12.3
--
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-Capture-Tiny] Fix spec file typo
commit 749362b1d95a70fa405e913012393349e4197577
Author: Petr Písař ppi...@redhat.com
Date: Fri Jan 28 14:53:54 2011 +0100
Fix spec file typo
perl-Capture-Tiny.spec |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/perl-Capture-Tiny.spec b/perl-Capture-Tiny.spec
index 5a0ac7d..b67f517 100644
--- a/perl-Capture-Tiny.spec
+++ b/perl-Capture-Tiny.spec
@@ -7,7 +7,7 @@ Group: Development/Libraries
URL:http://search.cpan.org/dist/Capture-Tiny/
Source0:
http://www.cpan.org/authors/id/D/DA/DAGOLDEN/Capture-Tiny-%{version}.tar.gz
BuildArch: noarch
-BuildArch: perl(ExtUtils::MakeMaker) = 6.31
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.31
BuildRequires: perl(Test::More) = 0.62
# Tests only:
BuildRequires: perl(Config)
--
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-Capture-Tiny] 0.09 bump
commit dbe59588775fca861f3473b08a1d61de04cc5126
Author: Petr Písař ppi...@redhat.com
Date: Fri Jan 28 11:01:00 2011 +0100
0.09 bump
.gitignore |1 +
perl-Capture-Tiny.spec | 39 ++-
sources|2 +-
3 files changed, 24 insertions(+), 18 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e118432..cb00dba 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Capture-Tiny-0.08.tar.gz
+/Capture-Tiny-0.09.tar.gz
diff --git a/perl-Capture-Tiny.spec b/perl-Capture-Tiny.spec
index 066a37a..5a0ac7d 100644
--- a/perl-Capture-Tiny.spec
+++ b/perl-Capture-Tiny.spec
@@ -1,16 +1,20 @@
Name: perl-Capture-Tiny
-Version:0.08
-Release:2%{?dist}
+Version:0.09
+Release:1%{?dist}
Summary:Capture STDOUT and STDERR from Perl, XS or external programs
License:ASL 2.0
Group: Development/Libraries
URL:http://search.cpan.org/dist/Capture-Tiny/
Source0:
http://www.cpan.org/authors/id/D/DA/DAGOLDEN/Capture-Tiny-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
-BuildRequires: perl = 0:5.006
-BuildRequires: perl(Module::Build) = 0.36
+BuildArch: perl(ExtUtils::MakeMaker) = 6.31
BuildRequires: perl(Test::More) = 0.62
+# Tests only:
+BuildRequires: perl(Config)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(IO::Handle)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
@@ -25,30 +29,31 @@ in any particular situation and just use this one.
%setup -q -n Capture-Tiny-%{version}
%build
-%{__perl} Build.PL installdirs=vendor
-./Build
+%{__perl} Makefile.PL INSTALLDIRS=perl
+make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
-
-./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
-
%{_fixperms} $RPM_BUILD_ROOT/*
%check
-./Build test
-
-%clean
-rm -rf $RPM_BUILD_ROOT
+make test
%files
%defattr(-,root,root,-)
-%doc Changes LICENSE README Todo
-%{perl_vendorlib}/*
+%doc Changes examples LICENSE perlcritic.rc README Todo
+%{perl_privlib}/*
%{_mandir}/man3/*
%changelog
+* Fri Jan 28 2011 Petr Pisar ppi...@redhat.com - 0.09-1
+- 0.09 bump
+- Remove BuildRoot stuff
+- Migrate from Module::Build to ExtUtils::MakeMaker
+- Install into perl core directory
+
* Wed Dec 15 2010 Marcela Maslanova mmasl...@redhat.com - 0.08-2
- 661697 rebuild for fixing problems with vendorach/lib
diff --git a/sources b/sources
index 359f96e..50ed214 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-dadea406a04a114b31a9248772b8c136 Capture-Tiny-0.08.tar.gz
+189a521f75b918402571cdc8b7c934bf Capture-Tiny-0.09.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 673435] perl-Capture-Tiny-0.09 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=673435 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Capture-Tiny-0.09-1.fc ||15 Resolution||RAWHIDE Last Closed||2011-01-28 09:05:56 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- 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
Re: cpanspec - proposal of default behaviour
On Fri, Jan 28, 2011 at 05:20:55PM +0100, Marcela Mašláňová wrote: I'd like to propose a change in default behaviour of cpanspec. There shouldn't be defined buildroot, called rm -rf in build phase, etc. These changes are optional, the old behaviour can be triggered with --epel option. [1] There's already a --old option. Wouldn't it make more sense to expand that, or maybe make it cumulative? (-o to get recent behavior, -oo to get %check || : and other cruft like that?) I'd like to see this change soon at least in rawhide, because I have to manually fix it in all my reviews. If you don't have time for this, I could attach it as a patch in Fedora's cpanspec. Just let me know, what do you prefer. I've been working for a while now on a new version that looks for build dependencies in tests. If you wouldn't mind testing that out, I'd be happy to make the change there... The source is on github: http://github.com/silug/cpanspec -- 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 671445] [PATCH] specfile accords to new packaging guidelines
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=671445 Iain Arnell iarn...@gmail.com changed: What|Removed |Added Attachment #474630|0 |1 is patch|| Attachment #474630|application/x-awk |text/plain mime type|| -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- 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
[Bug 671445] [PATCH] specfile accords to new packaging guidelines
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=671445 Ralf Corsepius rc040...@freenet.de changed: What|Removed |Added CC||rc040...@freenet.de --- Comment #1 from Ralf Corsepius rc040...@freenet.de 2011-01-28 23:45:57 EST --- I think it would be better to add an a general option to specify a distribution's name instead of one option per distro. I.e. I'd suggest to use --distro=epel-4 --distro=epel-5 --distro=centos-6 --distro=fedora-27 instead of --epel Otherwise we'd end up with one new option per distro, whenever a the rpm conventions will change. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- 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
[Bug 671445] [PATCH] specfile accords to new packaging guidelines
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=671445 --- Comment #2 from Iain Arnell iarn...@gmail.com 2011-01-29 01:34:35 EST --- Created attachment 475924 -- https://bugzilla.redhat.com/attachment.cgi?id=475924 incremental support for older RHEL releases I liked Steve's suggestion on the list: extend the existing --old option to support old and older conventions by making it cumulative. That's how my own ~/bin/cpanspec is working. I'd meant to clean it up and submit it a while back but never got around to it. The attached patch will allow cpanspec to generate specs suitable for f13+ (and el6) by default; using --old will generate specs suitable for older fedora and el4/5; using --old --old generates specs for antique distributions (as the current --old option does). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- 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
