Access rights for system logs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, currently, I'm the maintainer of logcheck. It parses system logs and sends mails defined by regular expressions. It's a package mostly adopted for debian. The README says, it is recommended to create an own user and put it into adm group. This leads to some problems, because fedoras system logs are currently owned root:root and currently just readable by user. Three possible solutions appear: - - make logcheck owned by root (against package maintainers hint) - - make the log reading program use the sticky option - - change systems logs owners from root:root mode 600 to root:adm mode 640 (or something similar) I would prefer the latter. What package owns /var/log/messages? (Who to contact...?) yum provides */messages did not list it. Is it really unowned? What do you think? Did I miss something? Has anybody of you another hint? Thanks, Matthias -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNZ2SoAAoJEOnz8qQwcaIWTI0H/0P3rL7bBhcbfLP85wKHt8TK STEv8xQSu8c1vxUZdr/acyOM/18iTfEl/rH9odj07qoHvwiuUl7ZD+GRgLlI/Geo xKhDquRfcm6qZeBAAYV/oHsbFywl4nkRmftfndTwgibyKk9XN4bkPes99x/k5yxy qG65tdanoBQP9nRPLLjoeZKxtU49lYMCEZve0NQY8hfgBEsh7zyLRkpUcBlQ/pi2 Ipcf/sKdAJ8fxVgr5mvKKjUxfA2C8kSE/n7rmNypQVWdu7e+Kn+Pog0VDmvmKD9j mxp85+JA1XIL8HnOsj1VeiymvYm4M5aczH/gXP5cGWg7eJHvDTpJP5uVWIL10mA= =Sa/e -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bugs in debuginfo packages
On Thu, 24 Feb 2011 09:28:10 +0100, KK == Karel Klic kk...@redhat.com wrote: KK component: Canna (tagoh) KK file: Canna-3.7p3-31.fc15.i686/usr/bin/cannaping KK- debuginfo missing; ELF stripped KK file: Canna-3.7p3-31.fc15.i686/usr/sbin/cannaserver KK- debuginfo missing; ELF stripped Fixed in Canna-3.7p3-32.fc15 -- Akira TAGOH pgpya8OH4lLRQ.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plans for BTRFS in Fedora
Dne 24.2.2011 20:54, Ric Wheeler napsal(a): Can we have pointers to these crashes or BZ reports please? As Josef has noted, btrfs has been quite stable in our testing and we are certainly going to pursue any reports. Will do ... I am hesitant to do so, because so many of my previous bug reports didn't make much difference, and given fsck core dumping (for the last three years), it seems to me that BTRFS is just nothing I would take seriously. Yet. Just to answer your last question, we do not intend to slow it down. Rather, we hope to speed it up considerably by adding developers, testing and users :) I meant obviously slowing down accepting BTRFS as default filesystem for Fedora and throwing away LVM from default, not development of BTRFS itself. Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC smime.p7s Description: S/MIME Cryptographic Signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plans for BTRFS in Fedora
On Thu, Feb 24, 2011 at 7:54 PM, Ric Wheeler rwhee...@redhat.com wrote: On 02/24/2011 08:44 AM, Matej Cepl wrote: Dne 23.2.2011 20:49, Matthew Garrett napsal(a): btrfs does the former without anywhere near as much of the latter. BTRFS so far only makes my kernel panicking as it did anytime I have been trying it since Fedora 9 (yes, I am crazy). This is absolutely not meant as anything personal against Josef (I know very well how incredibly small group are BTRFS developers), but just a bit of suspicion, whether we have fsck now (or we will have fsck soon) really leads so quickly let's make it default. I am quite OK with having crashing and unstable systemd or Gnome 3 (and again, nothing against their developers, this is Rawhide and Fedora, so when my kids are alive despite me using it I am pretty happy), but unstable file system is quite a different matter. Could we slow down a bit, please? Matěj Can we have pointers to these crashes or BZ reports please? As Josef has noted, btrfs has been quite stable in our testing and we are certainly going to pursue any reports. Also note that the btrfs community of developers is not so small these days and rivals (if not surpasses) the size of the team working on ext4. Just to answer your last question, we do not intend to slow it down. Rather, we hope to speed it up considerably by adding developers, testing and users :) I've seen a number of crashes using 2.6.37 on a Dell 6410 using btrfs in a luks encrypted LVM volume. Sometimes its a message in dmesg, other times an out right crash. Each time it happens I submit the kernel oops using abrt, but unlike RHBZ reports you don't get a URL for the report so I have no idea where they get reported to but it might be worthwhile reviewing that information where ever it ends up. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Bio-Graphics] filter requires, update run test
commit d153154a87a32b7dea8fd3b2243b312e9559534e
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Fri Feb 25 10:10:24 2011 +0100
filter requires, update run test
.gitignore |1 +
perl-Bio-Graphics.spec | 18 +-
sources|2 +-
3 files changed, 15 insertions(+), 6 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 42bdf8c..d8dbf40 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
Bio-Graphics-1.994.tar.gz
Bio-Graphics-2.11.tar.gz
+/Bio-Graphics-2.14.tar.gz
diff --git a/perl-Bio-Graphics.spec b/perl-Bio-Graphics.spec
index 0f5c06b..9166e09 100644
--- a/perl-Bio-Graphics.spec
+++ b/perl-Bio-Graphics.spec
@@ -1,6 +1,6 @@
Name: perl-Bio-Graphics
-Version:2.11
-Release:4%{?dist}
+Version:2.14
+Release:1%{?dist}
Summary:Generate GD images of Bio::Seq objects
License:GPL+ or Artistic
Group: Development/Libraries
@@ -25,12 +25,17 @@ to draw sequence annotations, physical (contig) maps,
protein domains,
or any other type of map in which a set of discrete ranges need to be
laid out on the number line
+%{?filter_setup:
+%filter_from_requires /^perl(colors)/d
+%{?perl_default_filter}
+}
+
%prep
%setup -q -n Bio-Graphics-%{version}
# temporarily remove modules Bio/Graphics/Glyph/trace.pm until the dependency:
# Bio::SCF is packaged
-rm lib/Bio/Graphics/Glyph/trace.pm
+#rm lib/Bio/Graphics/Glyph/trace.pm
%build
%{__perl} Build.PL installdirs=vendor
@@ -46,8 +51,7 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%check
-# because of removed file in prep
-#./Build test
+./Build test
%clean
rm -rf $RPM_BUILD_ROOT
@@ -61,6 +65,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Fri Feb 25 2011 Marcela Maslanova mmasl...@redhat.com - 2.14-1
+- filter requires
+- update run test
+
* Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.11-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
diff --git a/sources b/sources
index 39bf52c..5accc9a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-faa639b78860ef59052b43ce1dc5fbfe Bio-Graphics-2.11.tar.gz
+8a19807fb3f5c91551066956c17cd933 Bio-Graphics-2.14.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: Access rights for system logs
Dne 25.2.2011 09:13, Matthias Runge napsal(a): What do you think? Did I miss something? Has anybody of you another hint? No detailed analysis, but just brief +1 (unless some terrible issue is discovered in further discussion) ... I really liked this on Debian. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Access rights for system logs
On 02/25/2011 09:13 AM, Matthias Runge wrote: yum provides */messages did not list it. Is it really unowned? In order to give Big Brother read access to /var/log/messages I have added: create 640 root wheel to /etc/logrotate.d/syslog and have added bbuser to the wheel group. That file is owned by rsyslog in Fedora and sysklogd in RHEL. Mogens -- Mogens Kjaer, m...@lemo.dk http://www.lemo.dk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
nasm-2.09 breaks compatibility
Hello, I'v just been bitten by nasm-2.09 (https://bugzilla.redhat.com/show_bug.cgi?id=678818) that changed a derivation of __OUTPUT__FORMAT__ macro derivation from `-f FORMAT' option (http://www.nasm.us/doc/nasmdocc.html). If your package uses nasm and conditionalizes some assembly code by %ifidn __OUTPUT_FORMAT__,elf %endif statement, resulting binary will not be what you would expect. Backward nasm and yasm compatible solution is to change the `elf' value to `elf32' or `elf64' (depending on target architecture) in the macro test _and_ at the `-f elf' nasm option. nasm-2.09 has been introduced in Fedora 14 while beeing rawhide. Following listing of F14 SRPM shows some victims: $ repoquery --repoid=fedora-source --repoid=updates-source \ --repoid=updates-testing-source --arch=src --whatrequires 'nasm' nasm-0:2.09.03-2.fc14.src libjpeg-turbo-0:1.0.1-1.fc14.1.src quake3-0:1.36-7.svn1783.fc14.src quake3-0:1.36-8.svn1802.fc14.src syslinux-0:4.02-3.fc14.src tigervnc-0:1.0.90-0.22.20100813svn4123.fc14.src tigervnc-0:1.0.90-0.24.20100813svn4123.fc14.src As you can see SDL is missing there for unknown reason. Maybe because the nasm BuildRequires is conditionalized by architecture. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plans for BTRFS in Fedora
On 02/25/2011 04:06 AM, Peter Robinson wrote: On Thu, Feb 24, 2011 at 7:54 PM, Ric Wheelerrwhee...@redhat.com wrote: On 02/24/2011 08:44 AM, Matej Cepl wrote: Dne 23.2.2011 20:49, Matthew Garrett napsal(a): btrfs does the former without anywhere near as much of the latter. BTRFS so far only makes my kernel panicking as it did anytime I have been trying it since Fedora 9 (yes, I am crazy). This is absolutely not meant as anything personal against Josef (I know very well how incredibly small group are BTRFS developers), but just a bit of suspicion, whether we have fsck now (or we will have fsck soon) really leads so quickly let's make it default. I am quite OK with having crashing and unstable systemd or Gnome 3 (and again, nothing against their developers, this is Rawhide and Fedora, so when my kids are alive despite me using it I am pretty happy), but unstable file system is quite a different matter. Could we slow down a bit, please? Matěj Can we have pointers to these crashes or BZ reports please? As Josef has noted, btrfs has been quite stable in our testing and we are certainly going to pursue any reports. Also note that the btrfs community of developers is not so small these days and rivals (if not surpasses) the size of the team working on ext4. Just to answer your last question, we do not intend to slow it down. Rather, we hope to speed it up considerably by adding developers, testing and users :) I've seen a number of crashes using 2.6.37 on a Dell 6410 using btrfs in a luks encrypted LVM volume. Sometimes its a message in dmesg, other times an out right crash. Each time it happens I submit the kernel oops using abrt, but unlike RHBZ reports you don't get a URL for the report so I have no idea where they get reported to but it might be worthwhile reviewing that information where ever it ends up. Peter I think that it is probably best to report issues to the linux-btrfs list where the developers are. If you report them via bugzilla, we will see them directly there as well. Seems that we need to figure out where these abrt generated BZ's go, I have not seen them come in via our normal bugzilla reports but might need to figure out how to do specific queries for them. Thanks! Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plans for BTRFS in Fedora
On Fri, Feb 25, 2011 at 1:31 PM, Ric Wheeler rwhee...@redhat.com wrote: On 02/25/2011 04:06 AM, Peter Robinson wrote: On Thu, Feb 24, 2011 at 7:54 PM, Ric Wheelerrwhee...@redhat.com wrote: On 02/24/2011 08:44 AM, Matej Cepl wrote: Dne 23.2.2011 20:49, Matthew Garrett napsal(a): btrfs does the former without anywhere near as much of the latter. BTRFS so far only makes my kernel panicking as it did anytime I have been trying it since Fedora 9 (yes, I am crazy). This is absolutely not meant as anything personal against Josef (I know very well how incredibly small group are BTRFS developers), but just a bit of suspicion, whether we have fsck now (or we will have fsck soon) really leads so quickly let's make it default. I am quite OK with having crashing and unstable systemd or Gnome 3 (and again, nothing against their developers, this is Rawhide and Fedora, so when my kids are alive despite me using it I am pretty happy), but unstable file system is quite a different matter. Could we slow down a bit, please? Matěj Can we have pointers to these crashes or BZ reports please? As Josef has noted, btrfs has been quite stable in our testing and we are certainly going to pursue any reports. Also note that the btrfs community of developers is not so small these days and rivals (if not surpasses) the size of the team working on ext4. Just to answer your last question, we do not intend to slow it down. Rather, we hope to speed it up considerably by adding developers, testing and users :) I've seen a number of crashes using 2.6.37 on a Dell 6410 using btrfs in a luks encrypted LVM volume. Sometimes its a message in dmesg, other times an out right crash. Each time it happens I submit the kernel oops using abrt, but unlike RHBZ reports you don't get a URL for the report so I have no idea where they get reported to but it might be worthwhile reviewing that information where ever it ends up. Peter I think that it is probably best to report issues to the linux-btrfs list where the developers are. If you report them via bugzilla, we will see them directly there as well. Seems that we need to figure out where these abrt generated BZ's go, I have not seen them come in via our normal bugzilla reports but might need to figure out how to do specific queries for them. I think the kernel ones get submitted here http://kerneloops.org/ but if not you'd have to look closer at the abrt-addon-kerneloops for details on where its sent. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plans for BTRFS in Fedora
On 02/25/2011 08:52 AM, Peter Robinson wrote: On Fri, Feb 25, 2011 at 1:31 PM, Ric Wheelerrwhee...@redhat.com wrote: On 02/25/2011 04:06 AM, Peter Robinson wrote: On Thu, Feb 24, 2011 at 7:54 PM, Ric Wheelerrwhee...@redhat.comwrote: On 02/24/2011 08:44 AM, Matej Cepl wrote: Dne 23.2.2011 20:49, Matthew Garrett napsal(a): btrfs does the former without anywhere near as much of the latter. BTRFS so far only makes my kernel panicking as it did anytime I have been trying it since Fedora 9 (yes, I am crazy). This is absolutely not meant as anything personal against Josef (I know very well how incredibly small group are BTRFS developers), but just a bit of suspicion, whether we have fsck now (or we will have fsck soon) really leads so quickly let's make it default. I am quite OK with having crashing and unstable systemd or Gnome 3 (and again, nothing against their developers, this is Rawhide and Fedora, so when my kids are alive despite me using it I am pretty happy), but unstable file system is quite a different matter. Could we slow down a bit, please? Matěj Can we have pointers to these crashes or BZ reports please? As Josef has noted, btrfs has been quite stable in our testing and we are certainly going to pursue any reports. Also note that the btrfs community of developers is not so small these days and rivals (if not surpasses) the size of the team working on ext4. Just to answer your last question, we do not intend to slow it down. Rather, we hope to speed it up considerably by adding developers, testing and users :) I've seen a number of crashes using 2.6.37 on a Dell 6410 using btrfs in a luks encrypted LVM volume. Sometimes its a message in dmesg, other times an out right crash. Each time it happens I submit the kernel oops using abrt, but unlike RHBZ reports you don't get a URL for the report so I have no idea where they get reported to but it might be worthwhile reviewing that information where ever it ends up. Peter I think that it is probably best to report issues to the linux-btrfs list where the developers are. If you report them via bugzilla, we will see them directly there as well. Seems that we need to figure out where these abrt generated BZ's go, I have not seen them come in via our normal bugzilla reports but might need to figure out how to do specific queries for them. I think the kernel ones get submitted here http://kerneloops.org/ but if not you'd have to look closer at the abrt-addon-kerneloops for details on where its sent. Peter Not sure who monitors all kernel oops reports, but I personally don't see them. If you have a btrfs issue (or other issue with fedora file systems), feel free to drop me an email to make sure that we know about it so we can have a look at it :) ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Access rights for system logs
Dne 25.2.2011 10:39, Mogens Kjaer napsal(a): create 640 root wheel to /etc/logrotate.d/syslog and have added bbuser to the wheel group. That file is owned by rsyslog in Fedora and sysklogd in RHEL. I am not sure whether wheel is the correct group ... I don't think we should mix together two different things (who can use sudo, who can see logs). Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
git repository with Fedora kernel(s) sources
Hello. I've got an interesting idea - why not to provide a git repository with the sources of current Fedora kernel? This could simplify the maintenance of patches, allows other to easily backport stuff from kernel.org's master and greatly improves the current situation with transparency of development process. I mean I almost sure that Fedora Kernel team uses git internally, so why not to allow others to fork it? -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git repository with Fedora kernel(s) sources
Hi, 2011/2/25 Peter Lemenkov lemen...@gmail.com: Hello. I've got an interesting idea - why not to provide a git repository with the sources of current Fedora kernel? This could simplify the maintenance of patches, allows other to easily backport stuff from kernel.org's master and greatly improves the current situation with transparency of development process. I mean I almost sure that Fedora Kernel team uses git internally, so why not to allow others to fork it? git://pkgs.fedoraproject.org/kernel -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plans for BTRFS in Fedora
On 2/25/11 2:54 AM, Matěj Cepl wrote: Dne 24.2.2011 20:54, Ric Wheeler napsal(a): Can we have pointers to these crashes or BZ reports please? As Josef has noted, btrfs has been quite stable in our testing and we are certainly going to pursue any reports. Will do ... I am hesitant to do so, because so many of my previous bug reports didn't make much difference, Do you have pointers to those? Were they on the kernel.org bugzilla, or the red hat bugzilla, the list, or elsewhere? Thanks, -Eric and given fsck core dumping (for the last three years), it seems to me that BTRFS is just nothing I would take seriously. Yet. Just to answer your last question, we do not intend to slow it down. Rather, we hope to speed it up considerably by adding developers, testing and users :) I meant obviously slowing down accepting BTRFS as default filesystem for Fedora and throwing away LVM from default, not development of BTRFS itself. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Services that can start by default policy feedback
On Thu, Feb 24, 2011 at 09:46:06PM +, Matthew Garrett wrote: On Thu, Feb 24, 2011 at 10:25:44PM +0100, Till Maas wrote: For me essential services are the services that are required to start other services. If there are no services required to boot Fedora, login as root and start other services, then I do not see any point of requiring services to be enabled by default. So we should default to init=/bin/sh and take it from there? Is it possible to start there and to get to a gdm login by only using the command service foo start[0] and making this persistent by using chkconfig foo on[0]? I doubt it, as editing /boot/grub/grub.conf does not happen using this interface, which is where init=/bin/sh is set. Using the command service foo start is what I meant by starting other services as this is the usual interface for this on Fedora. Regards Till [0] Or the respective systemd command pgpk8ecyscz2R.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Fedora-r-devel-list] [Fwd: [R] R 2.12.2 is released]
FYI :-) Pierre ---BeginMessage--- I've rolled up R-2.12.2.tar.gz a short while ago. This is an update release, which fixes a number of mostly minor issues, and one major issue in which complex arithmetic was being messed up on some compiler platform. You can get it from http://cran.r-project.org/src/base/R-2/R-2.12.2.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team Peter Dalgaard These are the md5sums for the freshly created files, in case you wish to check that they are uncorrupted: MD5 (AUTHORS) = ac9746b4845ae81f51cfc99262f5 MD5 (COPYING) = eb723b61539feef013de476e68b5c50a MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343 MD5 (FAQ) = 72deeabefdf6fd14e83bf5703dce9176 MD5 (INSTALL) = 70447ae7f2c35233d3065b004aa4f331 MD5 (NEWS) = 30b55e4f34c155fcb2fafa7ebb55528e MD5 (ONEWS) = 0c3e10eef74439786e5fceddd06dac71 MD5 (OONEWS) = b0d650eba25fc5664980528c147a20db MD5 (R-latest.tar.gz) = bc70b51dddab8aa39066710624e55d5e MD5 (README) = 296871fcf14f49787910c57b92655c76 MD5 (RESOURCES) = 020479f381d5f9038dcb18708997f5da MD5 (THANKS) = f2ccf22f3e20ebaa86f8ee5cc6b0f655 MD5 (R-2/R-2.12.2.tar.gz) = bc70b51dddab8aa39066710624e55d5e This is the relevant part of the NEWS file: R News CHANGES IN R VERSION 2.12.2: SIGNIFICANT USER-VISIBLE CHANGES: • Complex arithmetic (notably z^n for complex z and integer n) gave incorrect results since R 2.10.0 on platforms without C99 complex support. This and some lesser issues in trignometric functions have been corrected. Such platforms were rare (we know of Cygwin and FreeBSD). However, because of new compiler optimizations in the way complex arguments are handled, the same code was selected on x86_64 Linux with gcc 4.5.x at the default -O2 optimization (but not at -O). • There is a workaround for crashes seen with several packages on systems using zlib 1.2.5: see the INSTALLATION section. NEW FEATURES: • PCRE has been updated to 8.12 (two bug-fix releases since 8.10). • rep(), seq(), seq.int() and seq_len() report more often when the first element is taken of an argument of incorrect length. • The Cocoa back-end for the quartz() graphics device on Mac OS X provides a way to disable event loop processing temporarily (useful, e.g., for forked instances of R). • kernel()'s default for m was not appropriate if coef was a set of coefficients. (Reported by Pierre Chausse.) • bug.report() has been updated for the current R bug tracker, which does not accept emailed submissions. • R CMD check now checks for the correct use of $(LAPACK_LIBS) (as well as $(BLAS_LIBS)), since several CRAN recent submissions have ignored ‘Writing R Extensions’. INSTALLATION: • The zlib sources in the distribution are now built with all symbols remapped: this is intended to avoid problems seen with packages such as XML and rggobi which link to zlib.so.1 on systems using zlib 1.2.5. • The default for FFLAGS and FCFLAGS with gfortran on x86_64 Linux has been changed back to -g -O2: however, setting -g -O may still be needed for gfortran 4.3.x. PACKAGE INSTALLATION: • A LazyDataCompression field in the DESCRIPTION file will be used to set the value for the --data-compress option of R CMD INSTALL. • Files R/sysdata.rda of more than 1Mb are now stored in the lazyload daabase using xz compression: this for example halves the installed size of package Imap. • R CMD INSTALL now ensures that directories installed from inst have search permission for everyone. It no longer installs files inst/doc/Rplots.ps and inst/doc/Rplots.pdf. These are almost certainly left-overs from Sweave runs, and are often large. DEPRECATED DEFUNCT: • The ‘experimental’ alternative specification of a name space via .Export() etc is now deprecated. • zip.file.extract() is now deprecated. • Zip-ing data sets in packages (and hence R CMD INSTALL --use-zip-data and the ZipData: yes field in a DESCRIPTION file) is deprecated: using efficiently compressed .rda images and lazy-loading of data has superseded it. BUG FIXES: • identical() could in rare cases generate a warning about non-pairlist attributes on CHARSXPs. As these are used for internal purposes, the attribute check should be skipped. (Reported by Niels Richard Hansen). • If the filename extension (usually .Rnw) was not included in a call to Sweave(), source references would not work properly and the keep.source option failed. (PR#14459) • format.data.frame() now keeps zero character column names. • pretty(x) no longer raises an error when x contains solely non-finite values. (PR#14468) • The plot.TukeyHSD() function now uses
Re: Access rights for system logs
On Fri, Feb 25, 2011 at 03:50:57PM +0100, Matej Cepl wrote: Dne 25.2.2011 10:39, Mogens Kjaer napsal(a): create 640 root wheel to /etc/logrotate.d/syslog and have added bbuser to the wheel group. That file is owned by rsyslog in Fedora and sysklogd in RHEL. I am not sure whether wheel is the correct group ... I don't think we should mix together two different things (who can use sudo, who can see logs). I like a special group just for accounts that should be able to read all log files, too, e.g. a group logread. Regards Till pgpAxhzlaryyE.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Object-InsideOut] update to 3.79
commit 5dd4db1a4ec162da15e88eea08e21bd2cb957d3c
Author: Iain Arnell iarn...@gmail.com
Date: Fri Feb 25 17:20:49 2011 +0100
update to 3.79
filter-provides.sh |3 ---
perl-Object-InsideOut.spec | 12
2 files changed, 8 insertions(+), 7 deletions(-)
---
diff --git a/perl-Object-InsideOut.spec b/perl-Object-InsideOut.spec
index 32e99bc..07ee1f4 100644
--- a/perl-Object-InsideOut.spec
+++ b/perl-Object-InsideOut.spec
@@ -1,6 +1,6 @@
Name: perl-Object-InsideOut
-Version:3.56
-Release:8%{?dist}
+Version:3.79
+Release:1%{?dist}
Summary:Comprehensive inside-out object support module
Group: Development/Libraries
@@ -13,13 +13,14 @@ BuildRequires: perl(Exception::Class) = 1.29
BuildRequires: perl(Want) = 0.12
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(Math::Random::MT::Auto)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
### auto-added brs!
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Data::Dumper)
-BuildRequires: perl(Scalar::Util) = 1.21
+BuildRequires: perl(Scalar::Util) = 1.23
BuildRequires: perl(Config)
BuildRequires: perl(Test::More) = 0.5
BuildRequires: perl(B)
@@ -29,7 +30,7 @@ Requires: perl(B)
Requires: perl(Config)
Requires: perl(Data::Dumper)
Requires: perl(Exception::Class) = 1.29
-Requires: perl(Scalar::Util) = 1.21
+Requires: perl(Scalar::Util) = 1.23
%description
This module provides comprehensive support for implementing classes using the
@@ -78,6 +79,9 @@ make test
%changelog
+* Fri Feb 25 2011 Iain Arnell iarn...@gmail.com 3.79-1
+- update to latest upstream version
+
* Sat Feb 19 2011 Iain Arnell iarn...@gmail.com 3.56-8
- only filter unversioned perl(Object::InsideOut) from provides
--
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: git repository with Fedora kernel(s) sources
On 2/25/2011 7:19, Michał Piotrowski wrote: I've got an interesting idea - why not to provide a git repository with the sources of current Fedora kernel? This could simplify the maintenance of patches, allows other to easily backport stuff from kernel.org's master and greatly improves the current situation with transparency of development process. I mean I almost sure that Fedora Kernel team uses git internally, so why not to allow others to fork it? git://pkgs.fedoraproject.org/kernel That repository has the spec file and build files; he means using git for the kernel sources themselves. Rather than keeping a stack of patches and porting them forward all the time, one can instead keep Fedora's patched kernel sources in a git repository and then include kernel-2.6.38-1.1.fc15.tar.bz2 in the source RPM instead of vanilla kernel-2.6.38.tar.bz2 and fifty patches. Red Hat appears to do this with RHEL 6's kernel, but their kernel repository is not publicly-accessible. While I can see how this might make things a bit easier, it can obscure what commits are Fedora-specific as they are lost in the sea of the upstream kernel's commits, making me firmly against the proposal. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git repository with Fedora kernel(s) sources
2011/2/25 Garrett Holmstrom gho...@fedoraproject.org: While I can see how this might make things a bit easier, it can obscure what commits are Fedora-specific as they are lost in the sea of the upstream kernel's commits, making me firmly against the proposal. Using topgit to control the Fedora patches would be an option, essentially creating a topic branch for each of these patches (and recording their dependencies). I have no clue however if that scales well to ~90 patches. -- Thomas Moschny thomas.mosc...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Services that can start by default policy feedback
On Fri, Feb 25, 2011 at 05:18:34PM +0100, Till Maas wrote: On Thu, Feb 24, 2011 at 09:46:06PM +, Matthew Garrett wrote: So we should default to init=/bin/sh and take it from there? Is it possible to start there and to get to a gdm login by only using the command service foo start[0] and making this persistent by using chkconfig foo on[0]? I doubt it, as editing /boot/grub/grub.conf does not happen using this interface, which is where init=/bin/sh is set. Using the command service foo start is what I meant by starting other services as this is the usual interface for this on Fedora. No, but if that's your definition of essential then all we need is to launch init and have it give you a getty. chkconfigging gdm on would give you a graphical login, and you could probably even get a session. A bunch of stuff wouldn't work because you'd be missing dbus and udev, you'd be wasting extra power and losing performance becase there'd be no irq balancing, you'd have no networking, you wouldn't be able to mount anything via nfs, bluetooth would obviously be right out the window and system logs wouldn't be updated. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bugs in debuginfo packages
Haïkel Guémar karlthe...@gmail.com wrote: Not sure, at least, it is used in kernel and glibc spec. Also mentionned in the RPM package creation howto featured in Packages Maintainer wiki page. Actually, we don't generate -debuginfo packages[1], so I'd say the script is looking for the debuginfo for the libs, not finding it and reporting. Blacklisting ghc-* and otehr ghc-built code should be added to the script (or just not reporting if there is no -debuginfo package, but this may hide real issues). --Ben [1]http://koji.fedoraproject.org/koji/buildinfo?buildID=229517 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Services that can start by default policy feedback
On Fri, Feb 25, 2011 at 04:45:35PM +, Matthew Garrett wrote: No, but if that's your definition of essential then all we need is to launch init and have it give you a getty. chkconfigging gdm on would give you a graphical login, and you could probably even get a session. A bunch of stuff wouldn't work because you'd be missing dbus and udev, As long it is possible to start dbus and udev afterwards once I need something that is not working otherwise, I do not see a problem. you'd be wasting extra power and losing performance becase there'd be no irq balancing, you'd have no networking, you wouldn't be able to mount anything via nfs, bluetooth would obviously be right out the window and system logs wouldn't be updated. I do not need to mount anything via nfs and if I have to, I have no problem by starting some service first or making it persistent if I need it always. The same holds true for bluetooth. Also it is a lot easier to once start all the necessary services or enabling them than finding all services that need to be disabled. It is a lot easier to identify missing services and unwanted extra services. There could even be a command that suggest to start all the services that are more or less always useful like udev, cpufreq, irqbalance or rsyslog. Regards Till pgpaIjp89t2zV.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plans for BTRFS in Fedora
On Thu, Feb 24, 2011 at 02:25:26PM +0100, Lennart Poettering wrote: snapshotted every time we perform a package/admin operation (and perhaps also just on regular intervals for good measure), what would we then gain by adding a read-only rootfs to the mix? Security, robustness: you can be sure that nothing tempers with your basic OS tree and it is always in a defined state, unless put in a specific admin mode, where the image may be changed/administered, i.e. / is remounted rw. It'd be nice to support a separate /usr in this case as well, because changes to /etc are usually a different use-case than changes to /usr -- the former is administrator configuration actions, and the latter almost exclusively package updates, installations, or removals. (Installing packages may or may not also entail changes to /etc, of course.) -- 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
Re: Services that can start by default policy feedback
On Thu, Feb 24, 2011 at 06:32:44PM +, Matthew Garrett wrote: On Thu, Feb 24, 2011 at 05:59:33PM +0100, Till Maas wrote: On Thu, Feb 24, 2011 at 03:04:26PM +, Matthew Garrett wrote: And once you've got a default set for the default install, why not just do it at the package level and ensure some level of consistency? Because by enabling lots of potential vulnerable services you make it a PITA to use Fedora securely. A proper way would be to have some system setting to specify whether or not non-essential services require explicit enabling, e.g. a file in /etc/sysconfig/initscripts file with a variable that one can set to true, which ensures that all not explicitly enabled services won't be enabled. There are no essential services, which means any proposal that contains the phrase non-essential services is already unimplementable. You've said this many times and it seems that you do it to be obstructionist. The constructive way to deal with this is to start making a list of what people really mean by essential and then propose alternate words to use. I think, by essential, some people mean: start the bare minimum so I don't have to start any additional services to: ... I don't want anything but init and a shell [*] ... log into a getty ... log in over the network ... log into a desktop ... do any client-side operations [*] This one (but not limited to this one) also specifies that additional services would be started, just not by packaging. ie: the installer or something else will start additional services independent of packaging. I'll note that with both traditional SysV runlevels and the set of systemd targets that we'll give to people in F15, we can have multiple defintions of what services to start as well. The rescue target (formerly runlevel 1) would be different from the multi-user target would be different from the graphical target. -Toshio pgpod8H2lNoSm.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Services that can start by default policy feedback
On 2/25/11 9:46 AM, Toshio Kuratomi wrote: You've said this many times and it seems that you do it to be obstructionist. The constructive way to deal with this is to start making a list of what people really mean by essential and then propose alternate words to use. I think, by essential, some people mean: start the bare minimum so I don't have to start any additional services to: ... I don't want anything but init and a shell [*] ... log into a getty ... log in over the network ... log into a desktop ... do any client-side operations I think his point is that we could argue endlessly about what is essential, because what's essential to you is different from what is essential to Bob, or Jim, or Susie. This was the same realization that led to the removal of the labeled minimal install, too many people just wanted to argue over the meaning of the term minimal. To be constructive here, I think we as a builder of a distribution need to decide what it means to have /Fedora/ boot. What is running when something called Fedora is installed and booted. In the past it has been enough stuff to do basically what you've written above, provided the right sets of packages were installed. Some of that was dictated by anaconda, not necessarily by the contents of the rpms themselves. I understand that Fedora is in one hand a big pile of packages that users can massage and manipulate into any number of smaller end products with various configurations, but Fedora is also supposed to be a useable distribution itself, and thus we should define what it means to have Fedora boot, and perhaps avoid loaded terms such as essential. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Services that can start by default policy feedback
On Fri, Feb 25, 2011 at 09:46:08AM -0800, Toshio Kuratomi wrote: On Thu, Feb 24, 2011 at 06:32:44PM +, Matthew Garrett wrote: There are no essential services, which means any proposal that contains the phrase non-essential services is already unimplementable. You've said this many times and it seems that you do it to be obstructionist. The constructive way to deal with this is to start making a list of what people really mean by essential and then propose alternate words to use. Like Jesse said, my objection here is that using the word essential just results in us being doomed to argue over what essential means. A literal interpretation of essential means start init and have it launch a getty. I don't think anyone's advocating that that be the outcome of a vanilla Fedora install. An alternative would be Essential for a traditional UNIX experience, which would seem to preclude dbus. I don't think that's a rational outcome either. So we end up with Essential for providing an experience consistent with what we feel a vanilla Fedora install should provide, which means you haven't actually defined essential at all. So don't say essential. Say what you mean. I think, by essential, some people mean: start the bare minimum so I don't have to start any additional services to: ... I don't want anything but init and a shell [*] ... log into a getty ... log in over the network ... log into a desktop ... do any client-side operations That's my point. If people have different interpretations of essential then any policy using the word essential is meaningless. You need to define essential - and if you're doing that then you don't need to use the word in the first place. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Services that can start by default policy feedback
On Fri, Feb 25, 2011 at 06:22:25PM +, Matthew Garrett wrote: Like Jesse said, my objection here is that using the word essential just results in us being doomed to argue over what essential means. A literal interpretation of essential means start init and have it launch a getty. I don't think anyone's advocating that that be the outcome of a vanilla Fedora install. An alternative would be Essential The services that are started when the respective package is installed and the services that are enabled by default by the Fedora installer do not need to be the same and are afaik currently not the same. There is imho a huge difference, whether services are enabled during installation, because afterwards one can usually expect that there are unwanted services and whether services are enabled after the respective package is installed long after the system has been installed. Regards Till pgpgwAbGQBlNl.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Services that can start by default policy feedback
On Fri, Feb 25, 2011 at 07:30:34PM +0100, Till Maas wrote: The services that are started when the respective package is installed and the services that are enabled by default by the Fedora installer do not need to be the same and are afaik currently not the same. There is imho a huge difference, whether services are enabled during installation, because afterwards one can usually expect that there are unwanted services and whether services are enabled after the respective package is installed long after the system has been installed. I think multipath is the only service enabled by Anaconda. Everything else depends on the package doing so. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110225 changes
Compose started at Fri Feb 25 08:15:32 UTC 2011 Broken deps for x86_64 -- R-hdf5-1.6.9-10.fc15.x86_64 requires hdf5 = 0:1.8.5.patch1 audacious-plugin-xmp-3.3.0-6.fc15.x86_64 requires audacious(plugin-api) = 0:17 balsa-2.4.9-3.fc15.x86_64 requires libgtkhtml-3.15.so.19()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libwv-1.2.so.3()(64bit) 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) beanstalkd-1.4.6-2.fc15.x86_64 requires libevent-1.4.so.2()(64bit) byzanz-0.2.2-1.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) castor-0.9.5-6.fc15.1.x86_64 requires oro coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Oassocb) = 0:d873c4a1eeb6fa5c5333f8658c49d1db coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Ograph2way) = 0:7442f647b0a74ed48a5c9361fc42ccc4 coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Flag) = 0:522d7f86f1236405e53271ff74923515 coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Osetb) = 0:8f21a0a4f771662673604ed92a237d79 coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Oseti) = 0:a937e7661f510c17bfd21d4372507795 coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Setb) = 0:93bdb588146a13126bfad4eab6c58206 coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Oassoc_buffer) = 0:cf6fbee4fcc6644a0a90f07da8eb6c7b coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Mapb) = 0:617c09a110cef9f040335b35078c7234 coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Sexplib) = 0:a990ea80438337d5407bbc0343c7236a coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Dumper) = 0:76126ba149caeb2d34f12e11187a9d4e coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Oassoch) = 0:87f7dc2635e5a7ed1ab03b7cd5380ace coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(SetPt) = 0:b69c030e8ca717d556d3d9bd2a5d22fd coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(ANSITerminal) = 0:3d0d1700618d8b3a4e4b2308f28cefb6 conmux-0.0-12.493svn.fc15.noarch requires perl(Payload) conmux-0.0-12.493svn.fc15.noarch requires perl(Client) cpm-0.23-0.3.beta.fc12.x86_64 requires libdotconf-1.0.so.0()(64bit) cvs2cl-2.72-4.noarch requires perl(CVS::Utils::ChangeLog::EntrySet::Output) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dbmail-3.0.0-0.3.rc1.fc15.x86_64 requires libevent-1.4.so.2()(64bit) dbmail-auth-ldap-3.0.0-0.3.rc1.fc15.x86_64 requires libevent-1.4.so.2()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper drupal6-views_bulk_operations-1.10-6.fc15.noarch requires drupal6-views ember-0.6.0-1.fc15.x86_64 requires libboost_thread-mt.so.1.44.0()(64bit) empathy-2.91.6.1-5.fc15.x86_64 requires libtelepathy-logger.so.1()(64bit) empathy-2.91.6.1-5.fc15.x86_64 requires libfolks.so.20()(64bit) empathy-2.91.6.1-5.fc15.x86_64 requires libfolks-telepathy.so.20()(64bit) eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit) evolution-couchdb-0.5.1-5.fc15.x86_64 requires libgtk-3.0.so.0()(64bit) evolution-couchdb-0.5.1-5.fc15.x86_64 requires libgdk-3.0.so.0()(64bit) evolution-mapi-2.91.90-1.fc16.i686 requires libdcerpc.so.0 evolution-mapi-2.91.90-1.fc16.i686 requires libndr.so.0 evolution-mapi-2.91.90-1.fc16.i686 requires libsamba-hostconfig.so.0 evolution-mapi-2.91.90-1.fc16.x86_64 requires libndr.so.0()(64bit) evolution-mapi-2.91.90-1.fc16.x86_64 requires libdcerpc.so.0()(64bit) evolution-mapi-2.91.90-1.fc16.x86_64 requires libsamba-hostconfig.so.0()(64bit) 1:fife-0.3.2-1.fc15.i686 requires libboost_regex.so.1.44.0 1:fife-0.3.2-1.fc15.i686 requires libboost_system.so.1.44.0 1:fife-0.3.2-1.fc15.i686 requires libboost_filesystem.so.1.44.0 1:fife-0.3.2-1.fc15.x86_64 requires libboost_regex.so.1.44.0()(64bit) 1:fife-0.3.2-1.fc15.x86_64 requires libboost_system.so.1.44.0()(64bit) 1:fife-0.3.2-1.fc15.x86_64 requires libboost_filesystem.so.1.44.0()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::ScrolledWindow) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::MessageDialog) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Dialog) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Toolbar) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::TreeView) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::MenuBar) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::VBox) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Window) gedit-valencia-0.3.0-4.fc14.x86_64 requires libvala-0.10.so.0()(64bit)
Minimal install option (was Re: Services that can start by default policy feedback)
On Fri, 2011-02-25 at 09:53 -0800, Jesse Keating wrote: This was the same realization that led to the removal of the labeled minimal install, too many people just wanted to argue over the meaning of the term minimal. ? There's still a 'minimal' radio button in the installer at the package set selection stage. I know, I just clicked on it not half an hour ago in the F15 Alpha RC1 installer. :) Is it meant to be gone? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bugs in debuginfo packages
On 02/24/2011 10:33 AM, Radek Vokál wrote: Thanks Karel, I vote for opening bugs for all of these. Especially those which are ELF stripped might even have wrong compiler flags. See also https://bugzilla.redhat.com/show_bug.cgi?id=DebugInfo These have been caught by debugrepo-check [1] which I've run every now and then on rawhide, but on a brief look Karel's script seems to do a much more thorough job. Based on the comments in Karel's script the time and resource requirements are very different too though; debugrepo-check only looks at repodata and finishes in ~20 seconds, probably less on more powerful boxes than the one I run it on. [1] Submitted to both autoqa and yum-utils, but hasn't found its way to either at least yet; https://fedorahosted.org/autoqa/ticket/59 , http://lists.baseurl.org/pipermail/yum/2009-April/022537.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install option (was Re: Services that can start by default policy feedback)
2011/2/25 Adam Williamson awill...@redhat.com: On Fri, 2011-02-25 at 09:53 -0800, Jesse Keating wrote: This was the same realization that led to the removal of the labeled minimal install, too many people just wanted to argue over the meaning of the term minimal. ? There's still a 'minimal' radio button in the installer at the package set selection stage. I know, I just clicked on it not half an hour ago in the F15 Alpha RC1 installer. :) Is it meant to be gone? I hope not. This is an option that I use most often. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Services that can start by default policy feedback
On Fri, Feb 25, 2011 at 06:22:25PM +, Matthew Garrett wrote: On Fri, Feb 25, 2011 at 09:46:08AM -0800, Toshio Kuratomi wrote: On Thu, Feb 24, 2011 at 06:32:44PM +, Matthew Garrett wrote: There are no essential services, which means any proposal that contains the phrase non-essential services is already unimplementable. You've said this many times and it seems that you do it to be obstructionist. The constructive way to deal with this is to start making a list of what people really mean by essential and then propose alternate words to use. Like Jesse said, my objection here is that using the word essential just results in us being doomed to argue over what essential means. A literal interpretation of essential means start init and have it launch a getty. I don't think anyone's advocating that that be the outcome of a vanilla Fedora install. An alternative would be Essential for a traditional UNIX experience, which would seem to preclude dbus. I don't think that's a rational outcome either. So we end up with Essential for providing an experience consistent with what we feel a vanilla Fedora install should provide, which means you haven't actually defined essential at all. So don't say essential. Say what you mean. I think, by essential, some people mean: start the bare minimum so I don't have to start any additional services to: ... I don't want anything but init and a shell [*] ... log into a getty ... log in over the network ... log into a desktop ... do any client-side operations That's my point. If people have different interpretations of essential then any policy using the word essential is meaningless. You need to define essential - and if you're doing that then you don't need to use the word in the first place. And my point is that instead of telling people there are no essential survices and therefore jsut leading people to argue about the meaning of a word, it's much more helpful to try to figure out these definitions that they are using the word to mean and then, if the word still bothers you, assign a different word then essential to it. -Toshio pgpH8iNq7wvLs.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install option (was Re: Services that can start by default policy feedback)
This was the same realization that led to the removal of the labeled minimal install, too many people just wanted to argue over the meaning of the term minimal. ? There's still a 'minimal' radio button in the installer at the package set selection stage. I know, I just clicked on it not half an hour ago in the F15 Alpha RC1 installer. :) Is it meant to be gone? It was there a long, long time ago. It was taken away a medium long time ago. It came back a short long time ago. It's still there. - Chris -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install option (was Re: Services that can start by default policy feedback)
On 2/25/11 12:51 PM, Chris Lumens wrote: This was the same realization that led to the removal of the labeled minimal install, too many people just wanted to argue over the meaning of the term minimal. ? There's still a 'minimal' radio button in the installer at the package set selection stage. I know, I just clicked on it not half an hour ago in the F15 Alpha RC1 installer. :) Is it meant to be gone? It was there a long, long time ago. It was taken away a medium long time ago. It came back a short long time ago. It's still there. Heh, have we started getting bug reports about it not being minimal enough or it being too minimal yet? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bugs in debuginfo packages
Ben Boeckel wrote: Anything with ghc-* can be ignored; ghc does not have debuginfo in its libraries. A list of other Haskell packages which don't fit the ghc-* pattern can be gathered as well. Actually, GHC has something somewhat equivalent to debuginfo, but it's in a completely different format. See the *-prof subpackages. With those, you can do profiling and, most importantly, get stack traces, see the -xc option: http://www.haskell.org/ghc/docs/latest/html/users_guide/runtime-control.html#rts-options-debugging What there is no support for is really debugging the code, i.e. doing stuff such as step-by-step execution. It's arguable how useful that'd be in a functional language, but in any case GHC does not support it. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-15 Branched report: 20110225 changes
Compose started at Fri Feb 25 13:16:07 UTC 2011 Broken deps for x86_64 -- Io-language-extras-20080330-4.fc15.x86_64 requires libevent-1.4.so.2()(64bit) balsa-2.4.9-3.fc15.x86_64 requires libgtkhtml-3.15.so.19()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libwv-1.2.so.3()(64bit) 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) beanstalkd-1.4.6-2.fc15.x86_64 requires libevent-1.4.so.2()(64bit) bugzilla-3.6.4-4.fc15.noarch requires perl(DBD::Oracle) bugzilla-3.6.4-4.fc15.noarch requires perl(DBI::db) bugzilla-3.6.4-4.fc15.noarch requires perl(DBI::st) bugzilla-3.6.4-4.fc15.noarch requires perl(sanitycheck.cgi) byzanz-0.2.2-1.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Ograph2way) = 0:7442f647b0a74ed48a5c9361fc42ccc4 coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Flag) = 0:522d7f86f1236405e53271ff74923515 coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Osetb) = 0:8f21a0a4f771662673604ed92a237d79 coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Oassocb) = 0:d873c4a1eeb6fa5c5333f8658c49d1db coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Setb) = 0:93bdb588146a13126bfad4eab6c58206 coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Oassoc_buffer) = 0:cf6fbee4fcc6644a0a90f07da8eb6c7b coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Mapb) = 0:617c09a110cef9f040335b35078c7234 coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Sexplib) = 0:a990ea80438337d5407bbc0343c7236a coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Dumper) = 0:76126ba149caeb2d34f12e11187a9d4e coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Oassoch) = 0:87f7dc2635e5a7ed1ab03b7cd5380ace coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(SetPt) = 0:b69c030e8ca717d556d3d9bd2a5d22fd coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(ANSITerminal) = 0:3d0d1700618d8b3a4e4b2308f28cefb6 coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Oseti) = 0:a937e7661f510c17bfd21d4372507795 conmux-0.0-12.493svn.fc15.noarch requires perl(Payload) conmux-0.0-12.493svn.fc15.noarch requires perl(Client) cpm-0.23-0.3.beta.fc12.x86_64 requires libdotconf-1.0.so.0()(64bit) cvs2cl-2.72-4.noarch requires perl(CVS::Utils::ChangeLog::EntrySet::Output) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dbmail-3.0.0-0.3.rc1.fc15.x86_64 requires libevent-1.4.so.2()(64bit) dbmail-auth-ldap-3.0.0-0.3.rc1.fc15.x86_64 requires libevent-1.4.so.2()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper dmapd-0.0.34-3.fc15.i686 requires libdmapsharing.so.2 dmapd-0.0.34-3.fc15.x86_64 requires libdmapsharing.so.2()(64bit) drupal6-views_bulk_operations-1.10-6.fc15.noarch requires drupal6-views ember-0.6.0-1.fc15.x86_64 requires libboost_thread-mt.so.1.44.0()(64bit) eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit) evolution-couchdb-0.5.1-5.fc15.x86_64 requires libgtk-3.0.so.0()(64bit) evolution-couchdb-0.5.1-5.fc15.x86_64 requires libgdk-3.0.so.0()(64bit) fatrat-1.1.3-2.fc15.x86_64 requires libboost_date_time-mt.so.1.44.0()(64bit) fatrat-1.1.3-2.fc15.x86_64 requires libtorrent-rasterbar.so.5()(64bit) fatrat-1.1.3-2.fc15.x86_64 requires libboost_filesystem-mt.so.1.44.0()(64bit) fatrat-1.1.3-2.fc15.x86_64 requires libboost_system-mt.so.1.44.0()(64bit) fawkes-plugin-player-0.4.1-1.fc15.x86_64 requires libboost_signals-mt.so.1.44.0()(64bit) fawkes-plugin-player-0.4.1-1.fc15.x86_64 requires libboost_thread-mt.so.1.44.0()(64bit) 1:fife-0.3.2-1.fc15.i686 requires libboost_regex.so.1.44.0 1:fife-0.3.2-1.fc15.i686 requires libboost_system.so.1.44.0 1:fife-0.3.2-1.fc15.i686 requires libboost_filesystem.so.1.44.0 1:fife-0.3.2-1.fc15.x86_64 requires libboost_regex.so.1.44.0()(64bit) 1:fife-0.3.2-1.fc15.x86_64 requires libboost_system.so.1.44.0()(64bit) 1:fife-0.3.2-1.fc15.x86_64 requires libboost_filesystem.so.1.44.0()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::ScrolledWindow) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Dialog) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Toolbar) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::TreeView) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::MenuBar) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::VBox) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Window) gcstar-1.6.1-3.fc15.noarch requires
[Test-Announce] Announcing 389 Directory Server version 1.2.8 Alpha 3
The 389 Project team is pleased to announce the release of 389-ds-base-1.2.8 Alpha 3. This release has fixes for bugs found in 1.2.8 alpha testing and bugs from earlier releases. Installation yum install --enablerepo=updates-testing 389-ds # or for EPEL yum install --enablerepo=epel-testing 389-ds setup-ds-admin.pl Upgrade yum upgrade --enablerepo=updates-testing 389-ds-base idm-console-framework 389-admin 389-ds-console 389-admin-console # or for EPEL yum upgrade --enablerepo=epel-testing 389-ds-base idm-console-framework 389-admin 389-ds-console 389-admin-console setup-ds-admin.pl -u How to Give Feedback The best way to provide feedback is via the Fedora Update system. Each update is broken down by package and platform. For example, if you are using Fedora 13, and you have successfully installed or upgraded all of the packages, and the console and etc. works, then go to the links below for Fedora 13 and provide feedback. * 389-ds-base-1.2.8.a3 ** EL-5 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.8-0.3.a3.el5 ** Fedora 13 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.8-0.3.a3.fc13 ** Fedora 14 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.8-0.3.a3.fc14 ** Fedora 15 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.8-0.3.a3.fc15 scroll down to the bottom of the page, and click on the Add a comment link * select one of the Works for me or Does not work radio buttons, add text, and click on the Add Comment button If you are using a build on another platform, just send us an email to 389-us...@lists.fedoraproject.org Reporting Bugs If you find a bug, or would like to see a new feature, you can enter it here - https://bugzilla.redhat.com/enter_bug.cgi?product=389 More Information * Release Notes - http://port389.org/wiki/Release_Notes * Install_Guide - http://port389.org/wiki/Install_Guide * Download - http://port389.org/wiki/Download ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 15 Alpha RC2 Available Now!
Fedora 15 Alpha RC2 is now available [1]. Please refer to the following pages for download links and testing instructions. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Ideally, all Alpha priority test cases for installation [2] and desktop [3] should pass in order to meet the Alpha Release Criteria [4]. Help is available on #fedora-qa on irc.freenode.net [5], or on the test list [6]. [1] http://poelstra.fedorapeople.org/schedules/f-15/f-15-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [4] https://fedoraproject.org/wiki/Fedora_15_Alpha_Release_Criteria [5] irc://irc.freenode.net/fedora-qa [6] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Increased Anaconda memory requirements?
Hi http://anonbadger.wordpress.com/2011/02/25/need-more-memory/ Why does Anaconda need more memory? Such changes really need to be coordinated and documented better. We need changes in several documentation including installation guide and release notes not to mention changes in the default RAM allocation in virt-manager and so on. Can someone in the Anaconda team provide the details please. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Increased Anaconda memory requirements?
On Sat, 2011-02-26 at 10:51 +0530, Rahul Sundaram wrote: Hi http://anonbadger.wordpress.com/2011/02/25/need-more-memory/ Why does Anaconda need more memory? Such changes really need to be coordinated and documented better. We need changes in several documentation including installation guide and release notes not to mention changes in the default RAM allocation in virt-manager and so on. Can someone in the Anaconda team provide the details please. AFAIK it's more or less a bug. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bugs in debuginfo packages
Karel Klic wrote: component: kdissert (rdieter) file: kdissert-1.0.7-8.fc15.i686/usr/lib/kde3/libkdissapplet.so - debuginfo missing; ELF is not stripped file: kdissert-1.0.7-8.fc15.i686/usr/lib/kde3/libkdisshtmldoc.so - debuginfo missing; ELF is not stripped file: kdissert-1.0.7-8.fc15.i686/usr/lib/kde3/libkdissprosperslides.so - debuginfo missing; ELF is not stripped file: kdissert-1.0.7-8.fc15.i686/usr/lib/kde3/libkdisspdflatexbook.so - debuginfo missing; ELF is not stripped file: kdissert-1.0.7-8.fc15.i686/usr/lib/kde3/libkdissbeamerslides.so - debuginfo missing; ELF is not stripped file: kdissert-1.0.7-8.fc15.i686/usr/lib/kde3/libkdissOOOimpress.so - debuginfo missing; ELF is not stripped file: kdissert-1.0.7-8.fc15.i686/usr/lib/kde3/libkdissasciidoc.so - debuginfo missing; ELF is not stripped file: kdissert-1.0.7-8.fc15.i686/usr/lib/kde3/libkdisspdflatexarticle.so - debuginfo missing; ELF is not stripped file: kdissert-1.0.7-8.fc15.i686/usr/lib/kde3/libkdissdocbook.so - debuginfo missing; ELF is not stripped file: kdissert-1.0.7-8.fc15.i686/usr/lib/kde3/libkdissOOOdoc.so - debuginfo missing; ELF is not stripped file: kdissert-1.0.7-8.fc15.i686/usr/lib/kde3/libkdissstx.so - debuginfo missing; ELF is not stripped This is because the .so files are not installed with execute permissions (by the build system, which is a bundled copy of waf, yuck!!!). I guess some of the other debuginfo missing; ELF is not stripped problems might be due to the same issue. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Bio-Graphics] Switch off test again. They work locally, but not on koji.
commit 2cbc1029108654dd0dfbb47f36049690c40f5b63
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Fri Feb 25 10:29:16 2011 +0100
Switch off test again. They work locally, but not on koji.
perl-Bio-Graphics.spec |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
---
diff --git a/perl-Bio-Graphics.spec b/perl-Bio-Graphics.spec
index 9166e09..2aea09f 100644
--- a/perl-Bio-Graphics.spec
+++ b/perl-Bio-Graphics.spec
@@ -35,7 +35,7 @@ laid out on the number line
# temporarily remove modules Bio/Graphics/Glyph/trace.pm until the dependency:
# Bio::SCF is packaged
-#rm lib/Bio/Graphics/Glyph/trace.pm
+rm lib/Bio/Graphics/Glyph/trace.pm
%build
%{__perl} Build.PL installdirs=vendor
@@ -51,7 +51,7 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%check
-./Build test
+#./Build test
%clean
rm -rf $RPM_BUILD_ROOT
@@ -67,7 +67,7 @@ rm -rf $RPM_BUILD_ROOT
%changelog
* Fri Feb 25 2011 Marcela Maslanova mmasl...@redhat.com - 2.14-1
- filter requires
-- update run test
+- update
* Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.11-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
--
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 Bio-Graphics-2.14.tar.gz uploaded to lookaside cache by mmaslano
A file has been added to the lookaside cache for perl-Bio-Graphics: 8a19807fb3f5c91551066956c17cd933 Bio-Graphics-2.14.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 680392] New: perl-Test-Warn-0.23 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-Test-Warn-0.23 is available https://bugzilla.redhat.com/show_bug.cgi?id=680392 Summary: perl-Test-Warn-0.23 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Test-Warn AssignedTo: tcall...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: tcall...@redhat.com, fedora-perl-devel-l...@redhat.com Classification: Fedora Latest upstream release: 0.23 Current version in Fedora Rawhide: 0.22 URL: http://search.cpan.org/dist/Test-Warn/ 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 680391] New: perl-Bio-Graphics-2.14 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-Bio-Graphics-2.14 is available https://bugzilla.redhat.com/show_bug.cgi?id=680391 Summary: perl-Bio-Graphics-2.14 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Bio-Graphics AssignedTo: al...@users.sourceforge.net ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: al...@users.sourceforge.net, fedora-perl-devel-l...@redhat.com Classification: Fedora Latest upstream release: 2.14 Current version in Fedora Rawhide: 2.11 URL: http://search.cpan.org/dist/Bio-Graphics/ 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 680418] New: missing man page for xpath
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: missing man page for xpath https://bugzilla.redhat.com/show_bug.cgi?id=680418 Summary: missing man page for xpath Product: Fedora Version: 14 Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: low Priority: unspecified Component: perl-XML-XPath AssignedTo: mmasl...@redhat.com ReportedBy: msu...@redhat.com QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora Description of problem: xpath does not have man page, which is pain, expecially when xpath --help or -h does not work neither. Version-Release number of selected component (if applicable): perl-XML-XPath-1.13-12.fc14.noarch How reproducible: always Steps to Reproduce: 1. man xpath Actual results: No manual entry for xpath Expected results: Nice man page for xpath -- 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
[perl-PAR-Packer] Do not strip binaries
commit ce0c3ee9301304bb22c2469f86df76f8ad0ca62a
Author: Petr Písař ppi...@redhat.com
Date: Fri Feb 25 15:25:35 2011 +0100
Do not strip binaries
perl-PAR-Packer.spec | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
---
diff --git a/perl-PAR-Packer.spec b/perl-PAR-Packer.spec
index f1ba292..011c121 100644
--- a/perl-PAR-Packer.spec
+++ b/perl-PAR-Packer.spec
@@ -1,6 +1,6 @@
Name: perl-PAR-Packer
Version:1.008
-Release:2%{?dist}
+Release:3%{?dist}
Summary:PAR Packager
License:GPL+ or Artistic
Group: Development/Libraries
@@ -25,12 +25,8 @@ stand-alone executables, perl scripts and PAR files.
%setup -q -n PAR-Packer-%{version}
%build
-# The build procedure for binaries parl and parldyn exploits PAR through
-# a compiled binary named myldr/static and thus looks very obfuscated.
-# There is no obvious way to teach the build system not to strip the installed
-# binaries. Consequently, desable the -debuginfo subpackage:
-%global debug_package %{nil}
-%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
+# DEBUG variable needed to disable stripping binary
+DEBUG=1 %{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
# The Makefile is not parallel-safe.
# PAR_GLOBAL_TEMP seems to be needed for the build.
make PAR_GLOBAL_TEMP=/var/tmp
@@ -68,6 +64,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Fri Feb 25 2011 Petr Pisar ppi...@redhat.com - 1.008-3
+- Do not strip binaries
+
* Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.008-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
--
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-PAR-Packer/f15/master] Do not strip binaries
Summary of changes: ce0c3ee... Do not strip binaries (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-PAR-Packer/f14/master] Do not strip binaries
commit 242b457834c0967cd65c08bd9420c946b57754af
Author: Petr Písař ppi...@redhat.com
Date: Fri Feb 25 15:25:35 2011 +0100
Do not strip binaries
perl-PAR-Packer.spec | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
---
diff --git a/perl-PAR-Packer.spec b/perl-PAR-Packer.spec
index c4d703e..9473177 100644
--- a/perl-PAR-Packer.spec
+++ b/perl-PAR-Packer.spec
@@ -1,6 +1,6 @@
Name: perl-PAR-Packer
Version:1.005
-Release:2%{?dist}
+Release:3%{?dist}
Summary:PAR Packager
License:GPL+ or Artistic
Group: Development/Libraries
@@ -25,12 +25,8 @@ stand-alone executables, perl scripts and PAR files.
%setup -q -n PAR-Packer-%{version}
%build
-# The build procedure for binaries parl and parldyn exploits PAR through
-# a compiled binary named myldr/static and thus looks very obfuscated.
-# There is no obvious way to teach the build system not to strip the installed
-# binaries. Consequently, desable the -debuginfo subpackage:
-%global debug_package %{nil}
-%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
+# DEBUG variable needed to disable stripping binary
+DEBUG=1 %{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
# The Makefile is not parallel-safe.
# PAR_GLOBAL_TEMP seems to be needed for the build.
make PAR_GLOBAL_TEMP=/var/tmp
@@ -68,6 +64,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Fri Feb 25 2011 Petr Pisar ppi...@redhat.com - 1.005-3
+- Do not strip binaries
+
* Tue Aug 24 2010 Adam Tkac atkac redhat com - 1.005-2
- rebuild
--
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-PAR-Packer/f13/master] Do not strip binaries
commit 82947c47b9864602fed7f75d25a585923d6ca581
Author: Petr Písař ppi...@redhat.com
Date: Fri Feb 25 15:25:35 2011 +0100
Do not strip binaries
perl-PAR-Packer.spec | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
---
diff --git a/perl-PAR-Packer.spec b/perl-PAR-Packer.spec
index db1015c..6887c46 100644
--- a/perl-PAR-Packer.spec
+++ b/perl-PAR-Packer.spec
@@ -1,6 +1,6 @@
Name: perl-PAR-Packer
Version:1.005
-Release:1%{?dist}
+Release:2%{?dist}
Summary:PAR Packager
License:GPL+ or Artistic
Group: Development/Libraries
@@ -25,12 +25,8 @@ stand-alone executables, perl scripts and PAR files.
%setup -q -n PAR-Packer-%{version}
%build
-# The build procedure for binaries parl and parldyn exploits PAR through
-# a compiled binary named myldr/static and thus looks very obfuscated.
-# There is no obvious way to teach the build system not to strip the installed
-# binaries. Consequently, desable the -debuginfo subpackage:
-%global debug_package %{nil}
-%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
+# DEBUG variable needed to disable stripping binary
+DEBUG=1 %{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
# The Makefile is not parallel-safe.
# PAR_GLOBAL_TEMP seems to be needed for the build.
make PAR_GLOBAL_TEMP=/var/tmp
@@ -68,6 +64,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Fri Feb 25 2011 Petr Pisar ppi...@redhat.com - 1.005-2
+- Do not strip binaries
+
* Fri Jun 11 2010 Petr Sabata psab...@redhat.com - 1.005-1
- Update to the latest release, fixing #602933
--
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-Bio-Graphics
perl-Bio-Graphics has broken dependencies in the rawhide tree: On x86_64: perl-Bio-Graphics-2.11-4.fc15.noarch requires perl(colors) On i386: perl-Bio-Graphics-2.11-4.fc15.noarch requires perl(colors) 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-Kwiki-RecentChanges
perl-Kwiki-RecentChanges has broken dependencies in the F-15 tree: On x86_64: perl-Kwiki-RecentChanges-0.14-12.fc15.noarch requires perl(mixin) On i386: perl-Kwiki-RecentChanges-0.14-12.fc15.noarch requires perl(mixin) 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-Kwiki-Revisions
perl-Kwiki-Revisions has broken dependencies in the F-15 tree: On x86_64: perl-Kwiki-Revisions-0.15-14.fc15.noarch requires perl(mixin) On i386: perl-Kwiki-Revisions-0.15-14.fc15.noarch requires perl(mixin) 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-Kwiki-Search
perl-Kwiki-Search has broken dependencies in the F-15 tree: On x86_64: perl-Kwiki-Search-0.12-14.fc15.noarch requires perl(mixin) On i386: perl-Kwiki-Search-0.12-14.fc15.noarch requires perl(mixin) 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-JSON-RPC
perl-JSON-RPC has broken dependencies in the F-15 tree: On x86_64: perl-JSON-RPC-0.96-7.fc15.noarch requires perl(MyApp) On i386: perl-JSON-RPC-0.96-7.fc15.noarch requires perl(MyApp) 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-Data-ObjectDriver
perl-Data-ObjectDriver has broken dependencies in the F-15 tree: On x86_64: perl-Data-ObjectDriver-0.08-2.fc15.noarch requires perl(DBD::Oracle) perl-Data-ObjectDriver-0.08-2.fc15.noarch requires perl(DBI::db) On i386: perl-Data-ObjectDriver-0.08-2.fc15.noarch requires perl(DBD::Oracle) perl-Data-ObjectDriver-0.08-2.fc15.noarch requires perl(DBI::db) 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-Bio-Graphics
perl-Bio-Graphics has broken dependencies in the F-15 tree: On x86_64: perl-Bio-Graphics-2.11-4.fc15.noarch requires perl(colors) On i386: perl-Bio-Graphics-2.11-4.fc15.noarch requires perl(colors) 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-Kwiki-Users-Remote
perl-Kwiki-Users-Remote has broken dependencies in the F-15 tree: On x86_64: perl-Kwiki-Users-Remote-0.04-12.fc15.noarch requires perl(mixin) On i386: perl-Kwiki-Users-Remote-0.04-12.fc15.noarch requires perl(mixin) 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-CGI-Application-Structured-Tools
perl-CGI-Application-Structured-Tools has broken dependencies in the F-15 tree: On x86_64: perl-CGI-Application-Structured-Tools-0.007-4.fc15.noarch requires main_module) perl-CGI-Application-Structured-Tools-0.007-4.fc15.noarch requires perl(tmpl_var) perl-CGI-Application-Structured-Tools-0.007-4.fc15.noarch requires perl(tmpl_var On i386: perl-CGI-Application-Structured-Tools-0.007-4.fc15.noarch requires main_module) perl-CGI-Application-Structured-Tools-0.007-4.fc15.noarch requires perl(tmpl_var) perl-CGI-Application-Structured-Tools-0.007-4.fc15.noarch requires perl(tmpl_var 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-Kwiki-UserName
perl-Kwiki-UserName has broken dependencies in the F-15 tree: On x86_64: perl-Kwiki-UserName-0.14-14.fc15.noarch requires perl(mixin) On i386: perl-Kwiki-UserName-0.14-14.fc15.noarch requires perl(mixin) 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-Declare-Constraints-Simple
perl-Declare-Constraints-Simple has broken dependencies in the F-15 tree: On x86_64: perl-Declare-Constraints-Simple-0.03-11.fc15.noarch requires perl(Declare::Constraints::Simple-Library) On i386: perl-Declare-Constraints-Simple-0.03-11.fc15.noarch requires perl(Declare::Constraints::Simple-Library) 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-Gtk2-Ex-Carp
perl-Gtk2-Ex-Carp has broken dependencies in the F-15 tree: On x86_64: perl-Gtk2-Ex-Carp-0.01-10.fc15.noarch requires perl(Gtk2::Dialog) On i386: perl-Gtk2-Ex-Carp-0.01-10.fc15.noarch requires perl(Gtk2::Dialog) 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-CSS-DOM
perl-CSS-DOM has broken dependencies in the F-15 tree: On x86_64: perl-CSS-DOM-0.14-3.fc15.noarch requires perl() On i386: perl-CSS-DOM-0.14-3.fc15.noarch requires perl() 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-Ace
perl-Ace has broken dependencies in the F-15 tree: On x86_64: perl-Ace-1.92-7.fc15.noarch requires perl(Ace::Browser::LocalSiteDefs) On i386: perl-Ace-1.92-7.fc15.noarch requires perl(Ace::Browser::LocalSiteDefs) 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-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the F-15 tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-8.fc15.noarch requires perl(v6-alpha) On i386: perl-Pugs-Compiler-Rule-0.37-8.fc15.noarch requires perl(v6-alpha) 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-Object-InsideOut
perl-Object-InsideOut has broken dependencies in the F-15 tree: On x86_64: perl-Object-InsideOut-3.56-5.fc15.noarch requires perl(t::Imp1) perl-Object-InsideOut-3.56-5.fc15.noarch requires perl(t::Imp2) On i386: perl-Object-InsideOut-3.56-5.fc15.noarch requires perl(t::Imp1) perl-Object-InsideOut-3.56-5.fc15.noarch requires perl(t::Imp2) 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-DateTime-Set
perl-DateTime-Set has broken dependencies in the F-15 tree: On x86_64: perl-DateTime-Set-0.28-4.fc15.noarch requires perl(Set::Infinite) = 0:0.5502 On i386: perl-DateTime-Set-0.28-4.fc15.noarch requires perl(Set::Infinite) = 0:0.5502 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-Kwiki-UserPreferences
perl-Kwiki-UserPreferences has broken dependencies in the F-15 tree: On x86_64: perl-Kwiki-UserPreferences-0.13-13.fc15.noarch requires perl(mixin) On i386: perl-Kwiki-UserPreferences-0.13-13.fc15.noarch requires perl(mixin) 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-DBIx-ContextualFetch
perl-DBIx-ContextualFetch has broken dependencies in the F-15 tree: On x86_64: perl-DBIx-ContextualFetch-1.03-11.fc15.noarch requires perl(DBI::st) perl-DBIx-ContextualFetch-1.03-11.fc15.noarch requires perl(DBI::db) On i386: perl-DBIx-ContextualFetch-1.03-11.fc15.noarch requires perl(DBI::st) perl-DBIx-ContextualFetch-1.03-11.fc15.noarch requires perl(DBI::db) 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-Kwiki-Raw
perl-Kwiki-Raw has broken dependencies in the F-15 tree: On x86_64: perl-Kwiki-Raw-0.02-13.fc15.noarch requires perl(mixin) On i386: perl-Kwiki-Raw-0.02-13.fc15.noarch requires perl(mixin) 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-Kwiki-NewPage
perl-Kwiki-NewPage has broken dependencies in the F-15 tree: On x86_64: perl-Kwiki-NewPage-0.12-14.fc15.noarch requires perl(mixin) On i386: perl-Kwiki-NewPage-0.12-14.fc15.noarch requires perl(mixin) 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-Net-SSH-Perl
perl-Net-SSH-Perl has broken dependencies in the F-15 tree: On x86_64: perl-Net-SSH-Perl-1.34-10.fc15.noarch requires perl(Crypt::IDEA) On i386: perl-Net-SSH-Perl-1.34-10.fc15.noarch requires perl(Crypt::IDEA) 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-bioperl
perl-bioperl has broken dependencies in the F-15 tree: On x86_64: perl-bioperl-1.6.1-6.fc15.noarch requires perl(Bio::Expression::FeatureSet) On i386: perl-bioperl-1.6.1-6.fc15.noarch requires perl(Bio::Expression::FeatureSet) 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-Catalyst-Controller-FormBuilder
perl-Catalyst-Controller-FormBuilder has broken dependencies in the F-15 tree: On x86_64: perl-Catalyst-Controller-FormBuilder-0.05-7.fc15.noarch requires perl(Catalyst::View::HTML::Template) On i386: perl-Catalyst-Controller-FormBuilder-0.05-7.fc15.noarch requires perl(Catalyst::View::HTML::Template) 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-Kwiki
perl-Kwiki has broken dependencies in the F-15 tree: On x86_64: perl-Kwiki-0.39-10.fc15.noarch requires perl(mixin) On i386: perl-Kwiki-0.39-10.fc15.noarch requires perl(mixin) 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
File CPAN-Meta-2.110550.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-CPAN-Meta: 14c62b460e9a97f6ca17a91e301d8313 CPAN-Meta-2.110550.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
File Catalyst-Action-REST-0.90.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Catalyst-Action-REST: 02eea46b307e1e83f89d51f98f648cb5 Catalyst-Action-REST-0.90.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CPAN-Meta] update to 2.110550
commit 3b394e25199814acaf63f486000d927563eb1273
Author: Iain Arnell iarn...@gmail.com
Date: Sat Feb 26 05:54:51 2011 +0100
update to 2.110550
.gitignore |1 +
perl-CPAN-Meta.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 9ffeb60..b22ad80 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@ CPAN-Meta-2.102160.tar.gz
/CPAN-Meta-2.102400.tar.gz
/CPAN-Meta-2.110350.tar.gz
/CPAN-Meta-2.110440.tar.gz
+/CPAN-Meta-2.110550.tar.gz
diff --git a/perl-CPAN-Meta.spec b/perl-CPAN-Meta.spec
index 0f08b4c..f9e590a 100644
--- a/perl-CPAN-Meta.spec
+++ b/perl-CPAN-Meta.spec
@@ -1,6 +1,6 @@
Name: perl-CPAN-Meta
Summary:Distribution metadata for a CPAN dist
-Version:2.110440
+Version:2.110550
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
@@ -15,7 +15,7 @@ BuildRequires: perl(ExtUtils::MakeMaker) = 6.31
BuildRequires: perl(File::Spec)
BuildRequires: perl(File::Temp) = 0.20
BuildRequires: perl(IO::Dir)
-BuildRequires: perl(Parse::CPAN::Meta) = 1.4300
+BuildRequires: perl(Parse::CPAN::Meta) = 1.4400
BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Storable)
BuildRequires: perl(Test::More) = 0.96
@@ -62,6 +62,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Sat Feb 26 2011 Iain Arnell iarn...@gmail.com 2.110550-1
+- update to latest upstream version
+
* Thu Feb 17 2011 Iain Arnell iarn...@gmail.com 2.110440-1
- update to latest upstream
- drop BR perl(autodie)
diff --git a/sources b/sources
index 8c65285..955284a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c376d5d92a0042ec7b68824ba34f257f CPAN-Meta-2.110440.tar.gz
+14c62b460e9a97f6ca17a91e301d8313 CPAN-Meta-2.110550.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
File Perl-Version-1.011.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Perl-Version: a9644971571bce86e3014013008cbb57 Perl-Version-1.011.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Catalyst-Action-REST] update to 0.90
commit ce2d567baa0347e589e301963edb63ddc4740923
Author: Iain Arnell iarn...@gmail.com
Date: Sat Feb 26 05:59:42 2011 +0100
update to 0.90
.gitignore |1 +
perl-Catalyst-Action-REST.spec |9 +++--
sources|2 +-
3 files changed, 9 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index aca5913..af648c2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@ Catalyst-Action-REST-0.85.tar.gz
/Catalyst-Action-REST-0.87.tar.gz
/Catalyst-Action-REST-0.88.tar.gz
/Catalyst-Action-REST-0.89.tar.gz
+/Catalyst-Action-REST-0.90.tar.gz
diff --git a/perl-Catalyst-Action-REST.spec b/perl-Catalyst-Action-REST.spec
index 0ff17e2..1f207ce 100644
--- a/perl-Catalyst-Action-REST.spec
+++ b/perl-Catalyst-Action-REST.spec
@@ -1,11 +1,13 @@
Name: perl-Catalyst-Action-REST
-Version:0.89
+Version:0.90
Release:1%{?dist}
Summary:Automated REST Method Dispatching
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Catalyst-Action-REST/
-Source0:
http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/Catalyst-Action-REST-%{version}.tar.gz
+# upstream releases tend to flip between these two locations
+#Source0:
http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/Catalyst-Action-REST-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/B/BO/BOBTFISH/Catalyst-Action-REST-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl(Catalyst::Runtime) = 5.80030
BuildRequires: perl(Class::Inspector) = 1.13
@@ -76,6 +78,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Sat Feb 26 2011 Iain Arnell iarn...@gmail.com 0.90-1
+- update to latest upstream version
+
* Sun Feb 20 2011 Iain Arnell iarn...@gmail.com 0.89-1
- update to latest upstream version
diff --git a/sources b/sources
index e835b8f..28ae9bc 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b28e4403bb886ad8030092372d23a7b4 Catalyst-Action-REST-0.89.tar.gz
+02eea46b307e1e83f89d51f98f648cb5 Catalyst-Action-REST-0.90.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
File Object-InsideOut-3.79.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Object-InsideOut: 82026878433a4a417c782e485107582d Object-InsideOut-3.79.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Object-InsideOut] upload sources for 3.79 too!
commit 60c63aca63cc0f4558a3db1bf6bf3ef2915d672f Author: Iain Arnell iarn...@gmail.com Date: Sat Feb 26 06:20:57 2011 +0100 upload sources for 3.79 too! .gitignore |1 + sources|2 +- 2 files changed, 2 insertions(+), 1 deletions(-) --- diff --git a/.gitignore b/.gitignore index 237726f..7c893ee 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,2 @@ Object-InsideOut-3.56.tar.gz +/Object-InsideOut-3.79.tar.gz diff --git a/sources b/sources index fdb1b6f..55679b7 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -a7b2ade392eb7582f38177ceb675ffb0 Object-InsideOut-3.56.tar.gz +82026878433a4a417c782e485107582d Object-InsideOut-3.79.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
[389-devel] winsync building
Hello! I'm try to build WinSync v.1.1.4: http://directory.fedoraproject.org/sources/winsync-1.1.4.tar.bz2 But I have a problem. Building with build.bat requires NSPR v4.8.4 and NSS v.3.12.6. They miss on http://port389.org/built/components (http://directory.fedoraproject.org/built/components). Can you help me with advice? I can't build the project. -- Best regards, Konstantin Kondratyuk. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review: [Bug 211296] Clean up all HTML pages (Admin Express, Repl Monitor, etc)
https://bugzilla.redhat.com/show_bug.cgi?id=211296 Admin Server https://bugzilla.redhat.com/attachment.cgi?id=481106action=diff https://bugzilla.redhat.com/attachment.cgi?id=481106action=edit Description: 1) Using HTML Validator, reviewed html pages (static as well as the generated ones) and fixed the errors and warnings. 2) To allow execute perl cgi script repl-monitor-cgi.pl, enabled AddHandler cgi-script for the extention .pl. 3) repl-monitor-cgi.pl did not pass the parameters sent from the caller cgi monreplication. This patch fixes the bug. 389-ds-console https://bugzilla.redhat.com/attachment.cgi?id=481107action=diff https://bugzilla.redhat.com/attachment.cgi?id=481107action=edit 389-admin-console https://bugzilla.redhat.com/attachment.cgi?id=481109action=diff https://bugzilla.redhat.com/attachment.cgi?id=481109action=edit Description: Using HTML Validator, reviewed help pages and fixed the errors and warnings. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
