Re: ipv6 tools + ipv4 tools fusion.
On Thu, Apr 28, 2011 at 06:57:53AM -0700, Wes Hardaker wrote: On Thu, 28 Apr 2011 02:59:09 +0200, Reindl Harald h.rei...@thelounge.net said: RH Am 28.04.2011 01:17, schrieb Itamar Reis Peixoto: why ipv6 and ipv4 have different name for the tools ? ... RH because the same hostname can have A and AAA records That argument makes sense up until the point that you realize there are a fair number of hosts out there with multiple A records too, and ping has to randomly choose between them. I'm all for a single unified set of commands (-4, -6). The real question, is what should the default be? And if 4 now, when do you switch later? [thus, I think -both now with v6 first if a is available otherwise v4 is probably the right answer] -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ Why don't we let the getaddrinfo() decide in this case as well? It's already used in other applications so why not here? I'm in favor of the usual -4/-6 options. -- Petr 'contyk' Sabata, Red Hat pgp3lsE4J48N3.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
W dniu 29 kwietnia 2011 04:09 użytkownik Jasper Boot jasper.b...@gmail.com napisał: Hi, 2011/4/29 Michał Piotrowski mkkp...@gmail.com Hi, By the way, maybe it would be good to think about the meaning of /srv existance? For seven years FHS requires that this directory exists http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A but The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done - so even the authors of the standard did not have anything to say about how this directory should be used. Is there a rational reason for the existence of this directory besides FHS conformance? For years now I've been using /srv to contain the content for the various (world visible) services my machines run. Instead of having a mix of /var/www/ /home/apache /home/httpd/ /var/lib/mysql/ /var/named/ and other directories the different distributions come up with (usually somewhere in /var), I've standardized on /srv/www /srv/svn /srv/git/ /srv/mysql and /srv/dns for all machines and distros. Instead of just getting rid of such a useful directory I'd rather see an effort to come up with a beter standardization / description. Because /var already contains a lot of other variable/transient data, e.g. log, spool and temporary files, I like the fact that I can have another hierarchy for 'content' data instead of 'variable run/state' data. In /srv is the really important data I need to backup and restore; /var is just variable data that is needed in a running system, but isn't that essential and specific to my system. You could almost say that /srv is the system-wide /home in my case. Ok, so it has some use. For the purpose that you described I use data dir that is somewhere on other than / partition $ ls /home/data/ backup mysql pgsql www Probably I should use /srv for this, but this would mean that I need yet another partition. -- Regards, Jasper -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
On 29/04/11 00:37, Michał Piotrowski wrote: Hi, I think it's a very good decision - I never understood why selinux dir is directly under /. By the way, maybe it would be good to think about the meaning of /srv existance? For seven years FHS requires that this directory exists http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A but The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done - so even the authors of the standard did not have anything to say about how this directory should be used. Is there a rational reason for the existence of this directory besides FHS conformance? These are two separate issues. /srv tends to prevent people creating top level mounts, so I would definitely keep it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self (Re)Introduction
Hi, On 04/29/2011 01:19 AM, Andy Grimm wrote: Hello, all. A brief bio on me: I started using Red Hat Linux in college in 1997. I spent half a decade as a Linux sys admin, and long ago I used to lurk in #redhat and #fedora giving tech support to new users. I first met some of these fine Fedora folks at FUDCon 2005. I finally signed up to be a Fedora contributor while at Ingres in 2007, but that didn't go quite as I expected, and I never submitted packages for review. I left Ingres for rPath, where I spent four years doing support and sustaining engineering for rPath Linux, Conary, and other rPath software; related to that, I've run Foresight Linux on my laptop for a while, so I'm still catching up on some the changes in the world of Fedora since 2007. This month, I joined Eucalyptus as a release engineer, and Garrett Holmstrom and I plan to co-maintain various Eucalyptus-related packages and their dependencies. I also hope to make other contributions as time permits. Welcome! Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New packager introduction
Hi, On 04/29/2011 12:37 AM, Richard Shaw wrote: Hello, I've been a Fedora user since FC6 and a little RH6 before that. Our family pretty much uses Fedora exclusively, including my desktop, MythTV box, and wife's laptop. The wife's laptop can still dual boot Vista, but she never uses it. I've been lurking on the devel mailing list for a while but now I'm officially a Fedora packager, my first package being openCOLLADA[1]. Actually, technically my first package was openshot on RPMFusion and then shortly thereafter picked up avidemux. If only I knew what I was signing up for with that one! :) I look forward to taking on another couple of packages once I get the handle on the process and time permits. Welcome :) Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Announcing the release of Fedora 15 Beta!!
On 04/26/2011 06:44 PM, Adam Williamson wrote: On Fri, 2011-04-22 at 07:55 +0200, Ralf Corsepius wrote: I decided to reinstall using netinstall.iso. Just a general note here: during pre-release time netinstall is always more likely to have trouble than media install. We test installation of the pre-release media (Alpha, Beta) quite heavily. Network install, even with updates-testing disabled, will use whatever packages have made it to stable; making it to stable isn't contingent on anyone doing installation testing, so it's perfectly normal for issues to creep in (these are the ones we wind up shaking out around the TC stage when we get to a pre-release point). So just in general, you're more likely to hit problems doing a network install than a media install, at pre-release time. Hi, Adam. This was why in another thread on the test list that I'd asked about the possibility of making the images hybrid. That would allow them to be dd'ed to a USB key instead of burning a DVD with each new prerelease. Right now the only options, to my knowledge, are to use the netinst (hybrid image) or use some special tool/process to convert the DVD ISO into a bootable USB key. The former can be flaky (as you mention) and the latter is cumbersome (and has the drawback of essentially testing something different than the actual DVD image). Would hybrid DVD ISOs be feasible going forward? - John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Announcing the release of Fedora 15 Beta!!
On Fri, Apr 29, 2011 at 8:14 AM, John Keller fed...@johnkeller.com wrote: Right now the only options, to my knowledge, are to use the netinst (hybrid image) or use some special tool/process to convert the DVD ISO into a bootable USB key. The former can be flaky (as you mention) and the latter is cumbersome (and has the drawback of essentially testing something different than the actual DVD image). Would hybrid DVD ISOs be feasible going forward? I use livecd-iso-to-disk (regularly and frequently), to make a bootable USB key for the DVD isos to do installs - it just works - I am puzzled as to why there is perceived to be a need to have additional tools or additional hybrid isos? -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110429 changes
Compose started at Fri Apr 29 08:15:02 UTC 2011 Broken deps for x86_64 -- beldi-0.9.25-3.fc15.x86_64 requires libhal-storage.so.1()(64bit) beldi-0.9.25-3.fc15.x86_64 requires libhal.so.1()(64bit) beldi-0.9.25-3.fc15.x86_64 requires hal callweaver-javascript-1.2.1-8.fc16.x86_64 requires libjs.so.1()(64bit) camcardsync-0.1.1-4.fc15.x86_64 requires libhal.so.1()(64bit) couchdb-1.0.2-2.fc16.x86_64 requires libjs.so.1()(64bit) cpm-0.23-0.3.beta.fc12.x86_64 requires libdotconf-1.0.so.0()(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dh-make-0.55-3.fc15.noarch requires debhelper emerillon-0.1.2-14.fc15.x86_64 requires libchamplain-gtk-0.8.so.1()(64bit) emerillon-0.1.2-14.fc15.x86_64 requires libchamplain-0.8.so.1()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gedit-valencia-0.3.0-4.fc14.x86_64 requires libvala-0.10.so.0()(64bit) 2:gimp-2.6.11-8.fc16.x86_64 requires libhal.so.1()(64bit) glunarclock-0.34.1-1.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-bubblemon-2.0.15-1.fc13.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-cpufire-1.6-3.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-globalmenu-0.7.9-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-music-2.5.1-5.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0 gnome-applet-sensors-2.2.7-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sshmenu-3.18-3.fc15.noarch requires ruby(panelapplet2) gnome-applet-window-picker-0.5.8-2.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) 1:gnome-applets-2.32.0-3.fc15.x86_64 requires libpanel-applet-3.so.0()(64bit) 1:gnome-applets-2.32.0-3.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) 1:gnome-applets-2.32.0-3.fc15.x86_64 requires libgweather.so.1()(64bit) gnome-device-manager-0.2-6.fc15.x86_64 requires libhal.so.1()(64bit) gnome-device-manager-devel-0.2-6.fc15.i686 requires hal-devel = 0:0.5.10 gnome-device-manager-devel-0.2-6.fc15.i686 requires pkgconfig(hal) gnome-device-manager-devel-0.2-6.fc15.x86_64 requires hal-devel = 0:0.5.10 gnome-device-manager-devel-0.2-6.fc15.x86_64 requires pkgconfig(hal) gnome-device-manager-libs-0.2-6.fc15.i686 requires libhal.so.1 gnome-device-manager-libs-0.2-6.fc15.i686 requires hal = 0:0.5.10 gnome-device-manager-libs-0.2-6.fc15.x86_64 requires libhal.so.1()(64bit) gnome-device-manager-libs-0.2-6.fc15.x86_64 requires hal = 0:0.5.10 gnome-netstatus-2.28.2-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotdconduit.so.3()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotd.so.5()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotdcm.so.4()(64bit) gnome-python2-applet-2.32.0-1.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-gdl-2.25.3-22.fc15.x86_64 requires libgdl-1.so.3()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0 gnotime-2.3.0-8.fc15.x86_64 requires libgtkhtml-3.15.so.19()(64bit) gnubiff-2.2.13-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gold-2.1.12.2-5.fc15.noarch requires perl(Data::Properties) gorm-1.2.13-0.20110331.fc16.i686 requires libgnustep-gui.so.0.19 gorm-1.2.13-0.20110331.fc16.i686 requires libgnustep-base.so.1.21 gorm-1.2.13-0.20110331.fc16.x86_64 requires libgnustep-gui.so.0.19()(64bit) gorm-1.2.13-0.20110331.fc16.x86_64 requires libgnustep-base.so.1.21()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-gtk-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libgdl-1.so.3()(64bit)
Re: Announcing the release of Fedora 15 Beta!!
On Tue 26 April 2011 21:58:08 Mathieu Bridon wrote: On Tue, 2011-04-26 at 15:43 +0200, Kevin Kofler wrote: it is better to have the package (even if it's poorly maintained) than to not have it at all! I think that's where some of us disagree with you. Having lots of parts of poor quality doesn't raise the global quality of Fedora. Having only a few parts, each of excellent quality, does. Yeah, it's great until users start leaving for distros which actually have packages of stuff they use. r -- Ryan Rix == http://hackersramblings.wordpress.com | http://rix.si/ == == http://rix.si/page/contact/ if you need a word == signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Announcing the release of Fedora 15 Beta!!
On Fri, 2011-04-29 at 02:29 -0700, Ryan Rix wrote: On Tue 26 April 2011 21:58:08 Mathieu Bridon wrote: On Tue, 2011-04-26 at 15:43 +0200, Kevin Kofler wrote: it is better to have the package (even if it's poorly maintained) than to not have it at all! I think that's where some of us disagree with you. Having lots of parts of poor quality doesn't raise the global quality of Fedora. Having only a few parts, each of excellent quality, does. Yeah, it's great until users start leaving for distros which actually have packages of stuff they use. The alternative being that users leave for distros which actually properly maintain packages of stuff they use. :) -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Announcing the release of Fedora 15 Beta!!
On 04/29/2011 05:43 AM, Mathieu Bridon wrote: On Fri, 2011-04-29 at 02:29 -0700, Ryan Rix wrote: On Tue 26 April 2011 21:58:08 Mathieu Bridon wrote: On Tue, 2011-04-26 at 15:43 +0200, Kevin Kofler wrote: it is better to have the package (even if it's poorly maintained) than to not have it at all! I think that's where some of us disagree with you. Having lots of parts of poor quality doesn't raise the global quality of Fedora. Having only a few parts, each of excellent quality, does. Yeah, it's great until users start leaving for distros which actually have packages of stuff they use. The alternative being that users leave for distros which actually properly maintain packages of stuff they use. :) Could we put them into a low-no-maintenance repo then - so they are available but caveat emptor? However the primay benefit of a repo, is that (a) its simple to install (b) it will update easily via yum. For things that are not being maintained upstream, (b) does not apply so its only (a). For things that are not maintained by fedora team but are active upstream, having them in a fedora repo seems silly. gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
incompatible KDE library errors
All, After updating my system two days ago I have been having errors when running vlc, system settings to name a couple. Below is some of what I am seeing in my .xsession-errors file. I am not sure where to continue looking to try and correct these errors. I have tried gnome and xcfe desktop environments, and they are working with out errors. It is only when I am using KDE. Thanks, Phillip Lynn [plynn55@plynn55 ~]$ less .xsession-errors startkde: Starting up... Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) kbuildsycoca4 running... kded(5360) Kded::loadModule: Could not load library kded_device_automounter . [ The plugin 'kded_device_automounter' uses an incompatible KDE library (4.6.2 (4.6.2)). ] kded(5360) Kded::loadModule: Could not load library kded_statusnotifierwatcher . [ The plugin 'kded_statusnotifierwatcher' uses an incompatible KDE library (4.6.2 (4.6.2)). ] kded(5360) Kded::loadModule: Could not load library kded_powerdevil . [ The plugin 'kded_powerdevil' uses an incompatible KDE library (4.6.2 (4.6.2)). ] kded(5360) Kded::loadModule: Could not load library kded_keyboard . [ The plugin 'kded_keyboard' uses an incompatible KDE library (4.6.2 (4.6.2)). ] Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: incompatible KDE library errors
Phillip Lynn wrote: All, After updating my system two days ago I have been having errors when running vlc, system settings to name a couple. Below is some of what I am seeing in my .xsession-errors file. I am not sure where to continue looking to try and correct these errors. I have tried gnome and xcfe desktop environments, and they are working with out errors. It is only when I am using KDE. I'd suggest : 1. post the output of: rpm -q qt kdelibs kdebase kdebase-runtime 2. try running: kbuildsycoca4 --noincremental 3. is this reproducible by 1 user on this same box? -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ipv6 tools + ipv4 tools fusion.
On 04/29/2011 12:14 AM, Petr Sabata wrote: Why don't we let the getaddrinfo() decide in this case as well? It's already used in other applications so why not here? Just to give it some more exposure (somewhat related): https://bugzilla.redhat.com/show_bug.cgi?id=697149 getaddrinfo() should disregard link-local IPv6 addresses for AI_ADDRCONFIG purposes I've also been filing bugs for software to use AI_ADDRCONFIG. Most recent is for python: https://bugzilla.redhat.com/show_bug.cgi?id=699576 There are other workarounds for these issues (use a different DNS server), but it would be nice if the software helped out a bit too. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Params-Util] Upstream update.
commit 5c6ad956ee98c2a584a3cdcfd0d46524f8dfc590
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Fri Apr 29 15:07:51 2011 +0200
Upstream update.
.gitignore|1 +
perl-Params-Util.spec | 12 +---
sources |2 +-
3 files changed, 7 insertions(+), 8 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 165a74c..78be2f0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
Params-Util-1.01.tar.gz
/Params-Util-1.03.tar.gz
+/Params-Util-1.04.tar.gz
diff --git a/perl-Params-Util.spec b/perl-Params-Util.spec
index c10722d..88d61a2 100644
--- a/perl-Params-Util.spec
+++ b/perl-Params-Util.spec
@@ -1,12 +1,11 @@
Name: perl-Params-Util
-Version: 1.03
-Release: 2%{?dist}
+Version: 1.04
+Release: 1%{?dist}
Summary: Simple standalone param-checking functions
License: GPL+ or Artistic
Group: Development/Libraries
URL: http://search.cpan.org/dist/Params-Util/
Source0:
http://search.cpan.org/CPAN/authors/id/A/AD/ADAMK/Params-Util-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
@@ -27,16 +26,12 @@ makes checking parameters a hell of a lot easier.
make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2/dev/null ';'
chmod -R u+w $RPM_BUILD_ROOT/*
-%clean
-rm -rf $RPM_BUILD_ROOT
-
%check
make test AUTOMATED_TESTING=1
@@ -49,6 +44,9 @@ make test AUTOMATED_TESTING=1
%{_mandir}/man3/*
%changelog
+* Fri Apr 29 2011 Ralf Corsépius corse...@fedoraproject.org - 1.04-1
+- Upstream update.
+
* Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.03-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
diff --git a/sources b/sources
index d870f5b..2a2250c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-9e5ae2987472f15fddf8ab806f4de867 Params-Util-1.03.tar.gz
+84bfb0a16cff67f2077ece0e24408b0f Params-Util-1.04.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: New packager introduction
Oh! And thanks to Hans for taking me under his wing! Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: incompatible KDE library errors
On Fri, 2011-04-29 at 07:33 -0500, Rex Dieter wrote: Phillip Lynn wrote: All, After updating my system two days ago I have been having errors when running vlc, system settings to name a couple. Below is some of what I am seeing in my .xsession-errors file. I am not sure where to continue looking to try and correct these errors. I have tried gnome and xcfe desktop environments, and they are working with out errors. It is only when I am using KDE. I'd suggest : 1. post the output of: rpm -q qt kdelibs kdebase kdebase-runtime 2. try running: kbuildsycoca4 --noincremental 3. is this reproducible by 1 user on this same box? -- Rex 1. [plynn55@plynn55 ~]$ rpm -q qt kdelibs kdebase kdebase-runtime qt-4.7.2-8.fc14.x86_64 qt-4.7.2-8.fc14.i686 kdelibs-4.6.2-1.fc14.x86_64 kdebase-4.6.2-1.fc14.x86_64 kdebase-runtime-4.6.2-1.fc14.x86_64 After running the rpm I did a yum remove qt-4.7.2-8.fc14.i686. Still had the same issues. 2. kbuildsycoca4 --noincremental [plynn55@plynn55 ~]$ kbuildsycoca4 --noincremental kbuildsycoca4 running... kbuildsycoca4(9611) VFolderMenu::loadDoc: Parse error in /home/plynn55/.config/menus/applications-merged/xdg-desktop-menu-dummy.menu , line 1 , col 1 : unexpected end of file kbuildsycoca4(9611) KConfigGroup::readXdgListEntry: List entry Categories in AmnesiaTheDarkDescentDemo.desktop is not compliant with XDG standard (missing trailing semicolon). kbuildsycoca4(9611) KConfigGroup::readXdgListEntry: List entry Categories in AmnesiaTheDarkDescentDemoManual.desktop is not compliant with XDG standard (missing trailing semicolon). kbuildsycoca4(9611) KConfigGroup::readXdgListEntry: List entry Categories in Google-googleearth.desktop is not compliant with XDG standard (missing trailing semicolon). kbuildsycoca4(9611) KConfigGroup::readXdgListEntry: List entry MimeType in Google-googleearth.desktop is not compliant with XDG standard (missing trailing semicolon). kbuildsycoca4(9611) KConfigGroup::readXdgListEntry: List entry MimeType in .hidden/kmdr-executor.desktop is not compliant with XDG standard (missing trailing semicolon). kbuildsycoca4(9611)/kdecore (services) KServicePrivate::init: The desktop entry file /usr/share/applications/kde/khtml_filter.desktop has Type= Application but also has a X-KDE-Library key. This works for now, but makes user-preference handling difficult, so support for this might be removed at some point. Consider splitting it into two desktop files. kbuildsycoca4(9611)/kdecore (services) KServicePrivate::init: The desktop entry file /usr/share/applications/kde/bell.desktop has Type= Application but also has a X-KDE-Library key. This works for now, but makes user-preference handling difficult, so support for this might be removed at some point. Consider splitting it into two desktop files. snip There was a long list of .desktop issues so I cut it short. 3. yes logged in as a new user and same issue. I am thinking about logging in gnome and removing kde and re-installing it. What do you think about this? Thanks, Phillip Lynn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
AutoQA 0.4.7 released
Please read: http://kparal.wordpress.com/2011/04/29/autoqa-0-4-7-released/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 Fallback Mode
Am I the only one having problems with entries in /etc/xdg/autostart not getting executed in the fallback session? This leads for example to the fact that policykit authentication does not work, since the authentication agent is not running. Thanks Sandro On 04/28/2011 05:55 PM, Bastien Nocera wrote: On Wed, 2011-04-27 at 16:27 +0200, Martin Stransky wrote: On 04/27/2011 03:10 PM, Adam Jackson wrote: Lots of things are unfortunate. This is software, after all. I regret not working on this earlier, since it would probably have saved the effort invested in fallback mode entirely. I think the fallback mode is a great idea, not everyone is excited by gnome shell and those people are looking at Xfce. Except that the fallback mode is a poor-man's shell, not a completely different environment that will take its own direction. It's like looking at the picture in the tour guide when standing in front of the monument. Sure you can do it, but the experience isn't going to be that interesting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Some changes to EPEL package reviews
On Thu, 28 Apr 2011 22:28:15 -0700 Garrett Holmstrom gho...@fedoraproject.org wrote: On 4/28/2011 13:25, Bill Nottingham wrote: EPEL now has a 'Package Review' component in bugzilla. If you've got an EPEL-only package you'd like to get reviewed, feel free to file it there. How is this any different, given that process-git-requests creates a rawhide branch without regard to whether one asks for it or not? I think the idea is that it allows people who wish to see reviews that are EPEL only. So, perhaps they have more interest or desire to review those. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self (Re)Introduction
On Thu, 28 Apr 2011 19:19:29 -0400 Andy Grimm agr...@gmail.com wrote: Hello, all. A brief bio on me: I started using Red Hat Linux in college in 1997. I spent half a decade as a Linux sys admin, and long ago I used to lurk in #redhat and #fedora giving tech support to new users. I first met some of these fine Fedora folks at FUDCon 2005. I finally signed up to be a Fedora contributor while at Ingres in 2007, but that didn't go quite as I expected, and I never submitted packages for review. I left Ingres for rPath, where I spent four years doing support and sustaining engineering for rPath Linux, Conary, and other rPath software; related to that, I've run Foresight Linux on my laptop for a while, so I'm still catching up on some the changes in the world of Fedora since 2007. This month, I joined Eucalyptus as a release engineer, and Garrett Holmstrom and I plan to co-maintain various Eucalyptus-related packages and their dependencies. I also hope to make other contributions as time permits. Welcome. I look forward to seeing Eucalyptus in Fedora and EPEL. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Params-Util/f15/master] Upstream update.
Summary of changes: 5c6ad95... Upstream update. (*) (*) 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Params-Util/f14/master] (4 commits) ...Merge.
Summary of changes: a30b1c9... - Upstream update. (*) 50ac7d9... - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass (*) 5c6ad95... Upstream update. (*) 7de2192... Merge. (*) 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Params-Util/f14/master: 4/4] Merge.
commit 7de2192c2ed9c5c43c762b2030d6d44c34404804
Merge: 64bcb78 5c6ad95
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Fri Apr 29 16:05:46 2011 +0200
Merge.
.gitignore|1 +
perl-Params-Util.spec | 10 --
sources |2 +-
3 files changed, 6 insertions(+), 7 deletions(-)
---
diff --cc perl-Params-Util.spec
index 9a947a8,88d61a2..8f6d473
--- a/perl-Params-Util.spec
+++ b/perl-Params-Util.spec
@@@ -49,6 -44,12 +44,9 @@@ make test AUTOMATED_TESTING=
%{_mandir}/man3/*
%changelog
+ * Fri Apr 29 2011 Ralf Corsépius corse...@fedoraproject.org - 1.04-1
+ - Upstream update.
+
-* Tue Feb 08 2011 Fedora Release Engineering
rel-...@lists.fedoraproject.org - 1.03-2
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
-
* Mon Dec 06 2010 Ralf Corsépius corse...@fedoraproject.org - 1.03-1
- Upstream update.
--
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: Self Introduction
Hi, On 04/28/2011, Martin Cermak mcer...@redhat.com wrote: On 04/27/2011, Hans De Goede hdego...@redhat.com wrote: I'm a sponsor and I would be happy to sponsor you. But first I would like to see slightly more of your packaging skills / understanding of the Fedora packaging guidelines (I already took a quick look at your pal package). There are 2 ways to show your package ninja skills, you can create 1 or 2 more packages (which I will then review together with pal), see here for a list of potential candidates: http://fedoraproject.org/wiki/PackageMaintainers/WishList That's great! I picked spindown daemon from the WishList. I packaged it and created a review request https://bugzilla.redhat.com/show_bug.cgi?id=700571 If you won't explicitly stop me I'll try to create one more new package as you requested 1 or 2 of them :-) Here is my third package ready for review (colorgcc): https://bugzilla.redhat.com/show_bug.cgi?id=700833 Please, be so kind and have a look at it. With best regards, Martin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Params-Util/f13/master] (9 commits) ...Merge.
Summary of changes: 06fd3e6... - Mass rebuild with perl-5.12.0 (*) 8ea50d5... - Mass rebuild with perl-5.12.0 (*) b81229d... - Upstream update. - Revert Marcela's 2010-05-04 changes. - (*) 7d922d5... - Rebuild for perl-5.12.x. (*) d199eb5... dist-git conversion (*) a30b1c9... - Upstream update. (*) 50ac7d9... - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass (*) 5c6ad95... Upstream update. (*) 2c5ed62... Merge. (*) 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Params-Util/f13/master: 9/9] Merge.
commit 2c5ed62890cba7e788e889766d6f75ff99661011
Merge: 05e9519 5c6ad95
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Fri Apr 29 17:05:27 2011 +0200
Merge.
.gitignore|1 +
perl-Params-Util.spec | 10 --
sources |2 +-
3 files changed, 6 insertions(+), 7 deletions(-)
---
diff --cc perl-Params-Util.spec
index cbafae1,88d61a2..00334c3
--- a/perl-Params-Util.spec
+++ b/perl-Params-Util.spec
@@@ -49,6 -44,12 +44,9 @@@ make test AUTOMATED_TESTING=
%{_mandir}/man3/*
%changelog
+ * Fri Apr 29 2011 Ralf Corsépius corse...@fedoraproject.org - 1.04-1
+ - Upstream update.
+
-* Tue Feb 08 2011 Fedora Release Engineering
rel-...@lists.fedoraproject.org - 1.03-2
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
-
* Mon Dec 06 2010 Ralf Corsépius corse...@fedoraproject.org - 1.03-1
- Upstream update.
--
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: systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
On Fri, 2011-04-29 at 00:37 +0200, Michał Piotrowski wrote: Hi, I think it's a very good decision - I never understood why selinux dir is directly under /. I guess I missed some discussion of this. You'd need to update libselinux at least, definition of SELINUXMNT in libselinux/src/policy.h, used by selinux_init_load_policy() to mount selinuxfs for initial policy load. And it may break rc scripts and other scripts/programs that have become accustomed to /selinux. -- Stephen Smalley National Security Agency -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/29/2011 11:07 AM, Stephen Smalley wrote:
On Fri, 2011-04-29 at 00:37 +0200, Michał Piotrowski wrote:
Hi,
I think it's a very good decision - I never understood why selinux dir
is directly under /.
I guess I missed some discussion of this. You'd need to update
libselinux at least, definition of SELINUXMNT in
libselinux/src/policy.h, used by selinux_init_load_policy() to mount
selinuxfs for initial policy load. And it may break rc scripts and
other scripts/programs that have become accustomed to /selinux.
Here is the patch I am thinking about.
I think mock might need to be updated, maybe livecd tools.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2615cACgkQrlYvE4MpobPYlQCfeB3H0/eTVITUbOkv66/P+0DB
7pAAn3nYJZSDLyJnDv7+VXwTlZQ3TW9R
=2hkb
-END PGP SIGNATURE-
diff --git a/libselinux/src/init.c b/libselinux/src/init.c
index a948920..43aa296 100644
--- a/libselinux/src/init.c
+++ b/libselinux/src/init.c
@@ -45,6 +45,18 @@ static void init_selinuxmnt(void)
}
}
+ /* We check to see if the original mount point for selinux file
+* system has a selinuxfs. */
+ do {
+ rc = statfs(/selinux, sfbuf);
+ } while (rc 0 errno == EINTR);
+ if (rc == 0) {
+ if ((uint32_t)sfbuf.f_type == (uint32_t)SELINUX_MAGIC) {
+ selinux_mnt = strdup(/selinux);
+ return;
+ }
+ }
+
/* Drop back to detecting it the long way. */
fp = fopen(/proc/filesystems, r);
if (!fp)
diff --git a/libselinux/src/load_policy.c b/libselinux/src/load_policy.c
index 83d2143..4078f69 100644
--- a/libselinux/src/load_policy.c
+++ b/libselinux/src/load_policy.c
@@ -369,7 +369,17 @@ int selinux_init_load_policy(int *enforce)
* Check for the existence of SELinux via selinuxfs, and
* mount it if present for use in the calls below.
*/
- if (mount(selinuxfs, SELINUXMNT, selinuxfs, 0, 0) 0 errno !=
EBUSY) {
+ char *mntpoint = NULL;
+ if (mount(selinuxfs, SELINUXMNT, selinuxfs, 0, 0) == 0 || errno ==
EBUSY) {
+ mntpoint = SELINUXMNT;
+ } else {
+ /* check old mountpoint */
+ if (mount(selinuxfs, /selinux, selinuxfs, 0, 0) == 0 ||
errno == EBUSY) {
+ mntpoint = /selinux;
+ }
+ }
+
+ if (! mntpoint ) {
if (errno == ENODEV) {
/*
* SELinux was disabled in the kernel, either
@@ -384,8 +394,8 @@ int selinux_init_load_policy(int *enforce)
}
goto noload;
- }
- set_selinuxmnt(SELINUXMNT);
+ }
+ set_selinuxmnt(mntpoint);
/*
* Note: The following code depends on having selinuxfs
@@ -397,7 +407,7 @@ int selinux_init_load_policy(int *enforce)
rc = security_disable();
if (rc == 0) {
/* Successfully disabled, so umount selinuxfs too. */
- umount(SELINUXMNT);
+ umount(selinux_mnt);
fini_selinuxmnt();
}
/*
diff --git a/libselinux/src/policy.h b/libselinux/src/policy.h
index 10e8712..76f968e 100644
--- a/libselinux/src/policy.h
+++ b/libselinux/src/policy.h
@@ -13,7 +13,7 @@
#define SELINUX_MAGIC 0xf97cff8c
/* Preferred selinux mount location */
-#define SELINUXMNT /selinux
+#define SELINUXMNT /sys/fs/selinux
/* selinuxfs mount point */
extern char *selinux_mnt;
libselinux-mountpoint.patch.sig
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
2011/4/29 seth vidal skvi...@fedoraproject.org: On Thu, 2011-04-28 at 23:32 -0400, Matthew Miller wrote: On Fri, Apr 29, 2011 at 12:37:26AM +0200, Michał Piotrowski wrote: By the way, maybe it would be good to think about the meaning of /srv existance? For seven years FHS requires that this directory exists http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A but The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done - so even the authors of the standard did not have anything to say about how this directory should be used. Is there a rational reason for the existence of this directory besides FHS conformance? Yes. It's where to put non-transient service data that does not belong to a user, and does not belong to a package. +1 - I think /srv is a good dir to have in place to encourage good practices for storing that kind of data. I think it is very unlikely that the services will start to use /srv/ instead of /var/something because of the backward compatibility. I create my own dir for data and it seemed to me that most people are doing the same. Thats why I wondered if there is any use for this dir. -sv -- 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: systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
On Fri, 2011-04-29 at 17:26 +0200, Michał Piotrowski wrote: 2011/4/29 seth vidal skvi...@fedoraproject.org: On Thu, 2011-04-28 at 23:32 -0400, Matthew Miller wrote: On Fri, Apr 29, 2011 at 12:37:26AM +0200, Michał Piotrowski wrote: By the way, maybe it would be good to think about the meaning of /srv existance? For seven years FHS requires that this directory exists http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A but The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done - so even the authors of the standard did not have anything to say about how this directory should be used. Is there a rational reason for the existence of this directory besides FHS conformance? Yes. It's where to put non-transient service data that does not belong to a user, and does not belong to a package. +1 - I think /srv is a good dir to have in place to encourage good practices for storing that kind of data. I think it is very unlikely that the services will start to use /srv/ instead of /var/something because of the backward compatibility. I create my own dir for data and it seemed to me that most people are doing the same. Thats why I wondered if there is any use for this dir. services should not be using /srv by default - I said it is a good habit for admins to get into so places where they store data are commonly available in normal locations -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Outage: FAS and dependent web apps - 2011-05-02 21:00 UTC
Outage: FAS and dependent web apps - 2011-05-02 21:00 UTC There will be an outage starting at 2011-05-02 21:00 UTC, which will last approximately 1 hour. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2011-05-02 21:00 UTC' Reason for outage: Performing an upgrade of the Fedora Account System (FAS) which will require database schema changes. This requires taking down FAS while the schema is updated. While FAS is down, the dependent web application services will be unavailable. Affected Services: Bodhi - https://admin.fedoraproject.org/updates/ Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ Additionally, the following services will be available for reading but not available for making changes: Fedora Hosted - https://fedorahosted.org/ Fedora Insight - https://insight.fedoraproject.org/ Translation Services - http://translate.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Unaffected Services: BFO - http://boot.fedoraproject.org/ Buildsystem - http://koji.fedoraproject.org/ GIT / Source Control DNS - ns1.fedoraproject.org, ns2.fedoraproject.org Docs - http://docs.fedoraproject.org/ Email system Fedora People - http://fedorapeople.org/ Fedora Talk - http://talk.fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Smolt - http://smolts.org/ Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Main Website - http://fedoraproject.org/ Ticket: https://fedorahosted.org/fedora-infrastructure/ticket/2748 Contact Information: Please join #fedora-admin in irc.freenode.net or add comments to the ticket for this outage above. -Toshio Kuratomi pgpK3tLnWJ89V.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Some changes to EPEL package reviews
Kevin Fenzi (ke...@scrye.com) said: On 4/28/2011 13:25, Bill Nottingham wrote: EPEL now has a 'Package Review' component in bugzilla. If you've got an EPEL-only package you'd like to get reviewed, feel free to file it there. How is this any different, given that process-git-requests creates a rawhide branch without regard to whether one asks for it or not? I think the idea is that it allows people who wish to see reviews that are EPEL only. So, perhaps they have more interest or desire to review those. ;) Correct. And it gives us something to key off of to possibly change process-git-requests in the future. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File HTML-Format-2.07.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-HTML-Format: 07b43da2e23ad4f6eeacee8219c65fa4 HTML-Format-2.07.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTML-Format/f15/master] Upstream update. Reflect upstream having switched to Build.PL.
commit f5a71422d0eb3eb0a163d39b5746fec6824ae95a
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Fri Apr 29 17:55:33 2011 +0200
Upstream update.
Reflect upstream having switched to Build.PL.
.gitignore|1 +
perl-HTML-Format.spec | 19 +++
sources |2 +-
3 files changed, 13 insertions(+), 9 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index eb981d2..ace4bf5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
HTML-Format-2.04.tar.gz
/HTML-Format-2.05.tar.gz
+/HTML-Format-2.07.tar.gz
diff --git a/perl-HTML-Format.spec b/perl-HTML-Format.spec
index e3970d9..32fb970 100644
--- a/perl-HTML-Format.spec
+++ b/perl-HTML-Format.spec
@@ -1,5 +1,5 @@
Name: perl-HTML-Format
-Version:2.05
+Version:2.07
Release: 1%{?dist}
Summary:HTML formatter modules
@@ -16,6 +16,7 @@ BuildRequires:perl(HTML::Element) = 3.15
BuildRequires: perl(HTML::TreeBuilder)
BuildRequires: perl(Font::AFM) = 1.17
BuildRequires: perl(File::Slurp)
+BuildRequires: perl(Module::Build)
BuildRequires: perl(Test::More) = 0.96
BuildRequires: perl(Font::Metrics::Courier)
BuildRequires: perl(Font::Metrics::CourierBold)
@@ -66,17 +67,15 @@ A collection of modules that formats HTML as plaintext,
PostScript or RTF.
%setup -q -n HTML-Format-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
-make %{?_smp_mflags}
+%{__perl} Build.PL installdirs=vendor
+./Build
%install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2/dev/null ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
+./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+%{_fixperms} $RPM_BUILD_ROOT/*
%check
-make test RELEASE_TESTING=1
+RELEASE_TESTING=1 ./Build test
%files
%defattr(-,root,root,-)
@@ -85,6 +84,10 @@ make test RELEASE_TESTING=1
%{_mandir}/man3/HTML*
%changelog
+* Fri Apr 29 2011 Ralf Corsépius corse...@fedoraproject.org - 2.07-1
+- Upstream update.
+- Reflect upstream having switched to Build.PL.
+
* Thu Mar 03 2011 Ralf Corsépius corse...@fedoraproject.org - 2.05-1
- Upstream update.
- Reflect Source0:-URL having changed.
diff --git a/sources b/sources
index 446b4ce..f210cf2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-fa410f4789f442eaf1e7a63b33fe9d91 HTML-Format-2.05.tar.gz
+07b43da2e23ad4f6eeacee8219c65fa4 HTML-Format-2.07.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTML-Format] Upstream update. Reflect upstream having switched to Build.PL.
Summary of changes: f5a7142... Upstream update. Reflect upstream having switched to Build. (*) (*) 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Some changes to EPEL package reviews
On 4/29/11 8:54 AM, Bill Nottingham wrote: How is this any different, given that process-git-requests creates a rawhide branch without regard to whether one asks for it or not? I think the idea is that it allows people who wish to see reviews that are EPEL only. So, perhaps they have more interest or desire to review those.;) Correct. And it gives us something to key off of to possibly change process-git-requests in the future. It is somewhat difficult, and odd, to create a git repo that does not have a master branch. It would be a little more odd to potentially at some point in the future create the master branch for a package should it find a home within Fedora. There need not be much/any content in the master branch, but there should still be one for each package. -- 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
Self Introduction
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm new to contributing but not new to Linux. I started on RHL 7.1 around 2000 and have used Slackware, Gentoo and Debian in the past. I was active at my university LUG and Gaming Club (running the game servers on Slackware) and now I work for Red Hat since August 2007 in support. I have been building RPMs for myself on and off almost since I started at Red Hat and switched from Debian to Fedora. I built RPMs for Rivendell [1] which is a large radio automation suite and some recommended getting that into Fedora but at the time it seemed too daunting. Now I am getting into DJing and in particular using FOSS to do it. I have used Mixxx and xwax. I am becoming the co-maintainer of Mixxx in rpmfusion [2] and have just submitted my first package review request for Fedora for xwax. [3] I would like to make Fedora a good platform for digital DJing. Mixxx was affected by a portaudio bug that had been fixed in Ubuntu but not Fedora so I opened a bug [4] on that and got that fixed. I have created a mixxx on fedora page for the Mixxx wiki. [5] My FAS account is John2583 but you can find me on Freenode as JBstrikesagain (I think that username was too long for FAS). I am in #fedora and #fedora-devel among other channels. You can check out my website to see some other stuff I do: http://cupcakecarnival.net/ 1) http://people.redhat.com/~jbrier/rivendell/ 2) https://bugzilla.rpmfusion.org/show_bug.cgi?id=1667 3) https://bugzilla.redhat.com/show_bug.cgi?id=700551 4) https://bugzilla.redhat.com/show_bug.cgi?id=691148 5) http://mixxx.org/wiki/doku.php/mixxx_on_fedora - -- John Brier, RHCA, RHCVA, RHCX Senior Technical Support Engineer - NA gpg: 1024D/251D9FF9 6F7B 242A 9375 F4CC BC6D F453 60D8 35FF 251D 9FF9 http://opensource.com - Where Open Source Multiplies -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk267R4ACgkQYNg1/yUdn/mWIACgo65xXmUXtl1PGIQOWhIGa1yJ xtYAniwjr8b+tYSuG3rP8oMggoJGjfqo =fBlB -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wireless-tools/net-tools are DEPRECATED
On Wed, 2011-04-27 at 23:01 +0200, Tomasz Torcz wrote: On Wed, Apr 27, 2011 at 01:58:57PM -0500, Dan Williams wrote: On Sun, 2011-04-24 at 23:06 +0200, Tomasz Torcz wrote: On Sun, Apr 24, 2011 at 07:10:48PM +0200, Kevin Kofler wrote: Ben Boeckel wrote: One thing I liked a lot with my ifconfig scripts/wpa_supplicant pairing is that when wireless is spotty, the network doesn't keep going up and down. Instead, applications see lots of dropped packets. When reauthentication can take 5 to 10s (or more), assuming that the connection is steady when its just spotty can result in better behavior. Also nice when quickly swapping ethernet cables. A network is gone event gets different reactions from applications (particularly those that are NM-aware which makes those applications MUCH more annoying to deal with in these cases) than some packets were lost. An option to persist connections despite something probably not actually existing would be nice for situations like this. I've found NM to actually be quite tolerant of spotty wireless connections. In fact, usually, it's me who triggers a reconnect (or if possible, a connect to a different access point, e.g. when I'm at the university in a shared building with the business university (WU), I try switching from eduroam to eduroam-wu when reception of my university's eduroam is poor), NM just happily stays connected even with 100% packet loss. Well, I have opposite experience with my wired connection. It takes only about 5 flip-flop (carrier on/carrier off) in 10 seconds for NM to consider connection down. When carrier state changes happen, NM sets the carrier state internally, but won't do anything about it for 4 seconds. If you get another carrier change within that 4 seconds, NM pushes the action off for another 4 seconds. If you get another, then it pushes it off for another 4 seconds. So basically, whenever the device settles down and stops spamming carrier changes, NM won't do anything for 4 seconds. That's not what I'm seeing: Looking at the code, the 4-second delay is only used when the device is actually connected to something. State 3 == DISCONNECTED, state 2 == UNAVAILABLE, so it's performing as expected here. Were there actually an IP address assigned to 'nf' then the 4-second delay would be used. Given that nothing really happens to the device when it's DISCONNECTED anyway, the logs you see are pretty much a NOP for NM. Dan messages-20110403:Mar 29 13:08:11 mother NetworkManager[1285]: info (nf): carrier now OFF (device state 3) messages-20110403:Mar 29 13:08:11 mother NetworkManager[1285]: info (nf): device state change: 3 - 2 (reason 40) messages-20110403:Mar 29 13:08:11 mother NetworkManager[1285]: info (nf): deactivating device (reason: 40). messages-20110403:Mar 29 13:08:21 mother NetworkManager[1285]: info (nf): carrier now ON (device state 2) messages-20110403:Mar 29 13:08:21 mother NetworkManager[1285]: info (nf): device state change: 2 - 3 (reason 40) messages-20110403:Mar 29 13:09:06 mother NetworkManager[1285]: info (nf): carrier now OFF (device state 3) messages-20110403:Mar 29 13:09:06 mother NetworkManager[1285]: info (nf): device state change: 3 - 2 (reason 40) messages-20110403:Mar 29 13:09:06 mother NetworkManager[1285]: info (nf): deactivating device (reason: 40). messages-20110403:Mar 29 13:09:07 mother NetworkManager[1285]: info (nf): carrier now ON (device state 2) messages-20110403:Mar 29 13:09:07 mother NetworkManager[1285]: info (nf): device state change: 2 - 3 (reason 40) messages-20110403:Mar 29 13:09:09 mother NetworkManager[1285]: info (nf): carrier now OFF (device state 3) messages-20110403:Mar 29 13:09:09 mother NetworkManager[1285]: info (nf): device state change: 3 - 2 (reason 40) messages-20110403:Mar 29 13:09:09 mother NetworkManager[1285]: info (nf): deactivating device (reason: 40). messages-20110403:Mar 29 13:09:11 mother NetworkManager[1285]: info (nf): carrier now ON (device state 2) messages-20110403:Mar 29 13:09:11 mother NetworkManager[1285]: info (nf): device state change: 2 - 3 (reason 40) messages-20110403:Mar 29 13:09:17 mother NetworkManager[1285]: info (nf): carrier now OFF (device state 3) messages-20110403:Mar 29 13:09:17 mother NetworkManager[1285]: info (nf): device state change: 3 - 2 (reason 40) messages-20110403:Mar 29 13:09:17 mother NetworkManager[1285]: info (nf): deactivating device (reason: 40). messages-20110403:Mar 29 13:09:17 mother NetworkManager[1285]: info (nf): canceled DHCP transaction, DHCP client pid 7250 At this point I need to manually do nmcli con up uuid xxx to have connection working again. The next question, what's causing your carrier to flip-flop int he first place? Power problems at the other end of ehternet cable. Beyond my
Re: [Guidelines Change] Changes to the Packaging Guidelines
A tangentially related question about spec files... As a new package maintainer I read the guidelines many a time and noticed that the current spec temples don't quite agree with the packaging guidelines Shouldn't they be updated to no longer include BuildRoot: or %clean as they are obsolete? Or rather that both Fedora versions (F12 and F10 respectively) that needed them are EOL'd? Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
No sleep-on-lid-close with F-15 beta KDE?
Having been not terribly impressed with GNOME 3 in F-15 alpha, I thought I'd try installing the beta with KDE, just to see if the grass is any greener. I'm still trying to find my way around that one too, but I've run into one significant problem: when I close my laptop, the machine doesn't go to sleep. (The sleep indicator light doesn't go on, I can still ssh into it, it stays rather warmer than it should, etc.) Is this: 1. An F-15 bug (and if so, which component ought I file it against)? 2. Expected behavior/missing feature for KDE? 3. My own ignorance about how to configure KDE? (I did look into the power management settings, which seem remarkably over-engineered and don't offer any clear sleep option...) regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please Review: (700890) Check return value of open() properly in libadmin
https://bugzilla.redhat.com/show_bug.cgi?id=700890 https://bugzilla.redhat.com/attachment.cgi?id=495832action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: No sleep-on-lid-close with F-15 beta KDE?
Tom Lane wrote: 1. An F-15 bug (and if so, which component ought I file it against)? Something here. The expectation is the system to go to sleep (mine does). -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
2011-04-29 - F-15 blocker bug review #3 - recap
= #fedora-bugzappers: F15 blocker review #3 = Minutes: http://meetbot.fedoraproject.org/fedora-bugzappers/2011-04-29/f15-blocker-review.2011-04-29-17.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-bugzappers/2011-04-29/f15-blocker-review.2011-04-29-17.00.txt Log: http://meetbot.fedoraproject.org/fedora-bugzappers/2011-04-29/f15-blocker-review.2011-04-29-17.00.log.html Meeting summary --- * Roll Call (jlaska, 17:00:18) * Why are we here (this meeting, not life)? (jlaska, 17:02:49) * Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. (jlaska, 17:02:55) * LINK: https://fedoraproject.org/wiki/Current_Release_Blockers (jlaska, 17:03:06) * LINK: https://fedoraproject.org/wiki/Fedora_15_Final_Release_Criteria (jlaska, 17:03:08) * LINK: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting (jlaska, 17:03:11) * https://bugzilla.redhat.com/show_bug.cgi?id=695389 (jlaska, 17:06:26) * Traceback when writing a kickstart for an unused lvm-on-raid (TypeError: 'NoneType' object is not subscriptable) (jlaska, 17:06:30) * https://bugzilla.redhat.com/show_bug.cgi?id=696320 (jlaska, 17:07:48) * After text-mode iSCSI install and boot, firstboot-text and getty are both running - unable to login on console (jlaska, 17:07:53) * LINK: http://rbergero.fedorapeople.org/schedules/f-15/f-15-quality-tasks.html (jlaska, 17:11:21) * ACTION: jlaska - reach out to mgracik for input on 696320 (jlaska, 17:13:03) * https://bugzilla.redhat.com/show_bug.cgi?id=684846 (jlaska, 17:13:11) * selinux denial prevents dbus activation of gnome-keyring-daemon (jlaska, 17:13:15) * ACTION: adamw reaching out to rdieter for status of 684846 (jlaska, 17:14:27) * https://bugzilla.redhat.com/show_bug.cgi?id=697834 (jlaska, 17:14:32) * Other menu appears in default installation (jlaska, 17:14:36) * Discussing adjustments to the stated desktop menu criteria, which may lower the importance of this bug (jlaska, 17:17:51) * https://bugzilla.redhat.com/show_bug.cgi?id=693809 (jlaska, 17:18:25) * Error message about missing input methods should be removed (jlaska, 17:18:29) * HELP: 693809 - needs test feedback for updated imsettings to land in F15 (jlaska, 17:21:47) * ACTION: jlaska - add https://admin.fedoraproject.org/updates/imsettings-1.2.2-1.fc15 to F15-TC1 rel-eng ticket (jlaska, 17:23:43) * https://bugzilla.redhat.com/show_bug.cgi?id=683629 (jlaska, 17:23:58) * KWin doesn't start up in firstboot, error message: Configuration file /root/.kde/share/config/kdedrc not writable (jlaska, 17:24:11) * https://bugzilla.redhat.com/show_bug.cgi?id=682001 (jlaska, 17:26:16) * s-c-services - all read and disabled, needs to cope with systemd (jlaska, 17:26:22) * https://bugzilla.redhat.com/show_bug.cgi?id=696278 (jlaska, 17:29:58) * The system network services are not compatible with this version. (jlaska, 17:30:04) * AGREED: 696278 - NEEDINFO? - Unable to pinpoint any specific failures, follow-up with reporter to further isolate failure (jlaska, 17:42:36) * https://bugzilla.redhat.com/show_bug.cgi?id=698184 (jlaska, 17:43:03) * Enabling session saving with Gnome shell makes GUI login unusable (jlaska, 17:43:07) * AGREED: 698184 - AcceptedBlocker - impacted by the criteria that upgraded system must meet all criteria, and gnome-session saving was considered common enough to block (jlaska, 17:46:33) * https://bugzilla.redhat.com/show_bug.cgi?id=696864 (jlaska, 17:47:32) * [abrt] ibus-chewing-1.3.9.2-2.fc15: Process /usr/libexec/ibus-engine-chewing was killed by signal 6 (SIGABRT) (jlaska, 17:47:37) * AGREED: 696864 - AcceptedBlocker - Affects desktop default panel (or equivalent) criteria for all mainland chinese installs (jlaska, 17:52:23) * https://bugzilla.redhat.com/show_bug.cgi?id=692230 (jlaska, 17:54:01) * /etc/init.d/iscsi check for network presence needs to be systemd aware (jlaska, 17:54:06) * AGREED: 692230 - AcceptedBlocker - Impacts non-root network (_netdev) partitions failing to mount on boot (e.g. iSCSI) (jlaska, 17:56:22) * https://bugzilla.redhat.com/show_bug.cgi?id=699896 (jlaska, 17:56:39) * AGREED: 699896 - AcceptedBlocker - tested fix available in bodhi (jlaska, 18:08:30) * https://bugzilla.redhat.com/show_bug.cgi?id=699905 (jlaska, 18:08:58) * Mesa rebuild for fixed LLVM 2.8 (jlaska, 18:09:03) * AGREED: 699896 - AcceptedBlocker - mesa rebuild required to address previously accepted blocker 699896 (jlaska, 18:10:28) * https://bugzilla.redhat.com/show_bug.cgi?id=700276 (jlaska, 18:10:43) * Enabling session saving with Gnome shell makes GUI
Re: incompatible KDE library errors
On Fri, 2011-04-29 at 09:20 -0400, Phillip Lynn wrote: On Fri, 2011-04-29 at 07:33 -0500, Rex Dieter wrote: Phillip Lynn wrote: All, After updating my system two days ago I have been having errors when running vlc, system settings to name a couple. Below is some of what I am seeing in my .xsession-errors file. I am not sure where to continue looking to try and correct these errors. I have tried gnome and xcfe desktop environments, and they are working with out errors. It is only when I am using KDE. I'd suggest : 1. post the output of: rpm -q qt kdelibs kdebase kdebase-runtime 2. try running: kbuildsycoca4 --noincremental 3. is this reproducible by 1 user on this same box? -- Rex 1. [plynn55@plynn55 ~]$ rpm -q qt kdelibs kdebase kdebase-runtime qt-4.7.2-8.fc14.x86_64 qt-4.7.2-8.fc14.i686 kdelibs-4.6.2-1.fc14.x86_64 kdebase-4.6.2-1.fc14.x86_64 kdebase-runtime-4.6.2-1.fc14.x86_64 After running the rpm I did a yum remove qt-4.7.2-8.fc14.i686. Still had the same issues. 2. kbuildsycoca4 --noincremental [plynn55@plynn55 ~]$ kbuildsycoca4 --noincremental kbuildsycoca4 running... kbuildsycoca4(9611) VFolderMenu::loadDoc: Parse error in /home/plynn55/.config/menus/applications-merged/xdg-desktop-menu-dummy.menu , line 1 , col 1 : unexpected end of file kbuildsycoca4(9611) KConfigGroup::readXdgListEntry: List entry Categories in AmnesiaTheDarkDescentDemo.desktop is not compliant with XDG standard (missing trailing semicolon). kbuildsycoca4(9611) KConfigGroup::readXdgListEntry: List entry Categories in AmnesiaTheDarkDescentDemoManual.desktop is not compliant with XDG standard (missing trailing semicolon). kbuildsycoca4(9611) KConfigGroup::readXdgListEntry: List entry Categories in Google-googleearth.desktop is not compliant with XDG standard (missing trailing semicolon). kbuildsycoca4(9611) KConfigGroup::readXdgListEntry: List entry MimeType in Google-googleearth.desktop is not compliant with XDG standard (missing trailing semicolon). kbuildsycoca4(9611) KConfigGroup::readXdgListEntry: List entry MimeType in .hidden/kmdr-executor.desktop is not compliant with XDG standard (missing trailing semicolon). kbuildsycoca4(9611)/kdecore (services) KServicePrivate::init: The desktop entry file /usr/share/applications/kde/khtml_filter.desktop has Type= Application but also has a X-KDE-Library key. This works for now, but makes user-preference handling difficult, so support for this might be removed at some point. Consider splitting it into two desktop files. kbuildsycoca4(9611)/kdecore (services) KServicePrivate::init: The desktop entry file /usr/share/applications/kde/bell.desktop has Type= Application but also has a X-KDE-Library key. This works for now, but makes user-preference handling difficult, so support for this might be removed at some point. Consider splitting it into two desktop files. snip There was a long list of .desktop issues so I cut it short. 3. yes logged in as a new user and same issue. I am thinking about logging in gnome and removing kde and re-installing it. What do you think about this? Thanks, Phillip Lynn All, My system is back and running. I found I had several old kde rpms on my system. I ran rpm -qa | grep kde | grep i686, then removed the old KDE rpms. Still having problems, removed KDE, reinstalled KDE several times was using yumex, and the group KDE keep giving me an incorrect install. I used sudo yum groupinstall KDE , then system installed correctly. Rebooted, still had a problem KDE was really slow, unusable! Found a post online about kde4.6 being slow, same problem I was having. first they said to kbuildsycoca4 --noincremental which I had done earlier this morning. So I did the second thing which was to run rm -rf /var/tmp/kdecache-'usrname'. After this I rebooted my system and all appears to be working... Thanks to those who replied with suggestions. Thanks, Phillip Lynn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
On 04/29/2011 11:53 PM, Richard Shaw wrote: A tangentially related question about spec files... As a new package maintainer I read the guidelines many a time and noticed that the current spec temples don't quite agree with the packaging guidelines Shouldn't they be updated to no longer include BuildRoot: or %clean as they are obsolete? Or rather that both Fedora versions (F12 and F10 respectively) that needed them are EOL'd? EPEL 4 and 5 needs them Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
On Fri, Apr 29, 2011 at 2:14 PM, Rahul Sundaram methe...@gmail.com wrote: On 04/29/2011 11:53 PM, Richard Shaw wrote: A tangentially related question about spec files... As a new package maintainer I read the guidelines many a time and noticed that the current spec temples don't quite agree with the packaging guidelines Shouldn't they be updated to no longer include BuildRoot: or %clean as they are obsolete? Or rather that both Fedora versions (F12 and F10 respectively) that needed them are EOL'd? EPEL 4 and 5 needs them Is it essential that the templates remain the same across distros or is it more for simplicity of maintaining the package? Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
On 04/30/2011 12:53 AM, Richard Shaw wrote: Is it essential that the templates remain the same across distros or is it more for simplicity of maintaining the package? Simplicity. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps
Hi Jerry, /*Jerry James loganje...@gmail.com*/ wrote on 04/28/2011 10:19:39 PM +0450: Hi all, I'd like to swap a couple of reviews. My packages: openfst: https://bugzilla.redhat.com/show_bug.cgi?id=681976 This is the next chunk of a voice recognition stack (CMU Sphinx) I've slowly been pushing into Fedora. csdp: https://bugzilla.redhat.com/show_bug.cgi?id=689039 This is used by some theorem provers, namely coq (which is already in Fedora, and complains bitterly that csdp is missing if you do certain things), and Isabelle (which I hope to see in Fedora sometime before I die). Both are moderately complex packages. Let me know what I can review for you in exchange. I'll take csdp. You can take one of the following (or both ;) ); they should be relatively easy to review: os-prober: https://bugzilla.redhat.com/show_bug.cgi?id=678442 Saaghar: https://bugzilla.redhat.com/show_bug.cgi?id=678634 Thanks, Hedayat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Test-NoTabs-1.1.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Test-NoTabs: 2f084761009e61084ff9c3bb8facb732 Test-NoTabs-1.1.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: systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
On Fri, 29.04.11 00:37, Michał Piotrowski (mkkp...@gmail.com) wrote: Hi, I think it's a very good decision - I never understood why selinux dir is directly under /. Yes, I think this would be a good thing to have in F16. Note however that this needs a tiny kernel patch to work, to create the mount point under /sys/fs/selinux. This is a trivial patch and has been done for /sys/fs/cgroup before, so I assume this would be easy to get in and just needs a champion to push this forward. By the way, maybe it would be good to think about the meaning of /srv existance? For seven years FHS requires that this directory exists http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A but The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done - so even the authors of the standard did not have anything to say about how this directory should be used. Is there a rational reason for the existence of this directory besides FHS conformance? I think /srv actually makes a lot of sense. Probably not so much on the desktop, but the boundaries are blurry, and I see no reason to set things up differently in this respect between servers and desktops. I see little benefit in removing this directory. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-MooseX-Object-Pluggable
perl-MooseX-Object-Pluggable has broken dependencies in the F-15 tree: On x86_64: perl-MooseX-Object-Pluggable-0.0011-6.fc15.noarch requires perl(Class::MOP) On i386: perl-MooseX-Object-Pluggable-0.0011-6.fc15.noarch requires perl(Class::MOP) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-MooseX-Emulate-Class-Accessor-Fast
perl-MooseX-Emulate-Class-Accessor-Fast has broken dependencies in the F-15 tree: On x86_64: perl-MooseX-Emulate-Class-Accessor-Fast-0.00903-5.fc15.noarch requires perl(Class::MOP) On i386: perl-MooseX-Emulate-Class-Accessor-Fast-0.00903-5.fc15.noarch requires perl(Class::MOP) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Catalyst-Controller-ActionRole
perl-Catalyst-Controller-ActionRole has broken dependencies in the F-15 tree: On x86_64: perl-Catalyst-Controller-ActionRole-0.15-3.fc15.noarch requires perl(Class::MOP) perl-Catalyst-Controller-ActionRole-0.15-3.fc15.noarch requires perl(Class::MOP) = 0:0.80 On i386: perl-Catalyst-Controller-ActionRole-0.15-3.fc15.noarch requires perl(Class::MOP) perl-Catalyst-Controller-ActionRole-0.15-3.fc15.noarch requires perl(Class::MOP) = 0:0.80 Please resolve this as soon as possible. -- 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
Broken dependencies: perl-MooseX-Types-Path-Class
perl-MooseX-Types-Path-Class has broken dependencies in the F-15 tree: On x86_64: perl-MooseX-Types-Path-Class-0.05-10.fc15.noarch requires perl(Class::MOP) On i386: perl-MooseX-Types-Path-Class-0.05-10.fc15.noarch requires perl(Class::MOP) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-CHI
perl-CHI has broken dependencies in the F-15 tree: On x86_64: perl-CHI-0.44-3.fc15.noarch requires perl(Class::MOP) On i386: perl-CHI-0.44-3.fc15.noarch requires perl(Class::MOP) On x86_64: perl-CHI-Test-0.44-3.fc15.noarch requires perl(Class::MOP) On i386: perl-CHI-Test-0.44-3.fc15.noarch requires perl(Class::MOP) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Catalyst-Runtime
perl-Catalyst-Runtime has broken dependencies in the F-15 tree: On x86_64: perl-Catalyst-Runtime-5.80032-1.fc15.noarch requires perl(Class::MOP) perl-Catalyst-Runtime-5.80032-1.fc15.noarch requires perl(Class::MOP) = 0:0.95 perl-Catalyst-Runtime-5.80032-1.fc15.noarch requires perl(Class::MOP::Object) On i386: perl-Catalyst-Runtime-5.80032-1.fc15.noarch requires perl(Class::MOP) perl-Catalyst-Runtime-5.80032-1.fc15.noarch requires perl(Class::MOP::Object) perl-Catalyst-Runtime-5.80032-1.fc15.noarch requires perl(Class::MOP) = 0:0.95 Please resolve this as soon as possible. -- 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
Broken dependencies: perl-File-ChangeNotify
perl-File-ChangeNotify has broken dependencies in the F-15 tree: On x86_64: perl-File-ChangeNotify-0.16-3.fc15.noarch requires perl(Class::MOP) On i386: perl-File-ChangeNotify-0.16-3.fc15.noarch requires perl(Class::MOP) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-MooseX-InsideOut
perl-MooseX-InsideOut has broken dependencies in the F-15 tree: On x86_64: perl-MooseX-InsideOut-0.105-2.fc15.noarch requires perl(Class::MOP) = 0:0.80 On i386: perl-MooseX-InsideOut-0.105-2.fc15.noarch requires perl(Class::MOP) = 0:0.80 Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Pod-Coverage-Moose
perl-Pod-Coverage-Moose has broken dependencies in the F-15 tree: On x86_64: perl-Pod-Coverage-Moose-0.02-4.fc15.noarch requires perl(Class::MOP) On i386: perl-Pod-Coverage-Moose-0.02-4.fc15.noarch requires perl(Class::MOP) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-MooseX-Traits-Pluggable
perl-MooseX-Traits-Pluggable has broken dependencies in the F-15 tree: On x86_64: perl-MooseX-Traits-Pluggable-0.09-4.fc15.noarch requires perl(Class::MOP) = 0:0.84 On i386: perl-MooseX-Traits-Pluggable-0.09-4.fc15.noarch requires perl(Class::MOP) = 0:0.84 Please resolve this as soon as possible. -- 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
Broken dependencies: perl-MooseX-Types
perl-MooseX-Types has broken dependencies in the F-15 tree: On x86_64: perl-MooseX-Types-0.22-3.fc15.noarch requires perl(Class::MOP) On i386: perl-MooseX-Types-0.22-3.fc15.noarch requires perl(Class::MOP) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Moose
perl-Moose has broken dependencies in the F-15 tree: On x86_64: perl-Moose-1.25-1.fc15.x86_64 requires perl(Class::MOP::Module) perl-Moose-1.25-1.fc15.x86_64 requires perl(Class::MOP::Attribute) perl-Moose-1.25-1.fc15.x86_64 requires perl(metaclass) perl-Moose-1.25-1.fc15.x86_64 requires perl(Class::MOP) = 0:1.10 perl-Moose-1.25-1.fc15.x86_64 requires perl(Class::MOP) = 0:1.11 perl-Moose-1.25-1.fc15.x86_64 requires perl(Class::MOP) perl-Moose-1.25-1.fc15.x86_64 requires perl(Class::MOP) = 0:0.60 perl-Moose-1.25-1.fc15.x86_64 requires perl(Class::MOP::Object) perl-Moose-1.25-1.fc15.x86_64 requires perl(Class::MOP::MiniTrait) perl-Moose-1.25-1.fc15.x86_64 requires perl(Class::MOP::Mixin::AttributeCore) perl-Moose-1.25-1.fc15.x86_64 requires perl(Class::MOP::Instance) perl-Moose-1.25-1.fc15.x86_64 requires perl(Class::MOP::Class::Immutable::Trait) perl-Moose-1.25-1.fc15.x86_64 requires perl(Class::MOP::Method) perl-Moose-1.25-1.fc15.x86_64 requires perl(Class::MOP::Class) On i386: perl-Moose-1.25-1.fc15.i686 requires perl(Class::MOP::Module) perl-Moose-1.25-1.fc15.i686 requires perl(Class::MOP::Attribute) perl-Moose-1.25-1.fc15.i686 requires perl(metaclass) perl-Moose-1.25-1.fc15.i686 requires perl(Class::MOP) perl-Moose-1.25-1.fc15.i686 requires perl(Class::MOP::Object) perl-Moose-1.25-1.fc15.i686 requires perl(Class::MOP::MiniTrait) perl-Moose-1.25-1.fc15.i686 requires perl(Class::MOP::Mixin::AttributeCore) perl-Moose-1.25-1.fc15.i686 requires perl(Class::MOP::Instance) perl-Moose-1.25-1.fc15.i686 requires perl(Class::MOP::Class::Immutable::Trait) perl-Moose-1.25-1.fc15.i686 requires perl(Class::MOP) = 0:1.10 perl-Moose-1.25-1.fc15.i686 requires perl(Class::MOP) = 0:1.11 perl-Moose-1.25-1.fc15.i686 requires perl(Class::MOP) = 0:0.60 perl-Moose-1.25-1.fc15.i686 requires perl(Class::MOP::Method) perl-Moose-1.25-1.fc15.i686 requires perl(Class::MOP::Class) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Catalyst-View-Component-SubInclude
perl-Catalyst-View-Component-SubInclude has broken dependencies in the F-15 tree: On x86_64: perl-Catalyst-View-Component-SubInclude-0.10-2.fc15.noarch requires perl(Class::MOP) On i386: perl-Catalyst-View-Component-SubInclude-0.10-2.fc15.noarch requires perl(Class::MOP) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Moose-Autobox
perl-Moose-Autobox has broken dependencies in the F-15 tree: On x86_64: perl-Moose-Autobox-0.11-2.fc15.noarch requires perl(metaclass) On i386: perl-Moose-Autobox-0.11-2.fc15.noarch requires perl(metaclass) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-MooseX-Traits
perl-MooseX-Traits has broken dependencies in the F-15 tree: On x86_64: perl-MooseX-Traits-0.11-4.fc15.noarch requires perl(Class::MOP) = 0:0.84 On i386: perl-MooseX-Traits-0.11-4.fc15.noarch requires perl(Class::MOP) = 0:0.84 Please resolve this as soon as possible. -- 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: systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
On Fri, 29.04.11 17:26, Michał Piotrowski (mkkp...@gmail.com) wrote: 2011/4/29 seth vidal skvi...@fedoraproject.org: On Thu, 2011-04-28 at 23:32 -0400, Matthew Miller wrote: On Fri, Apr 29, 2011 at 12:37:26AM +0200, Michał Piotrowski wrote: By the way, maybe it would be good to think about the meaning of /srv existance? For seven years FHS requires that this directory exists http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A but The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done - so even the authors of the standard did not have anything to say about how this directory should be used. Is there a rational reason for the existence of this directory besides FHS conformance? Yes. It's where to put non-transient service data that does not belong to a user, and does not belong to a package. +1 - I think /srv is a good dir to have in place to encourage good practices for storing that kind of data. I think it is very unlikely that the services will start to use /srv/ instead of /var/something because of the backward compatibility. I create my own dir for data and it seemed to me that most people are doing the same. Thats why I wondered if there is any use for this dir. /srv is not package manager territory really. It's admin territory. He should create dirs underneath it, and nobody else. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[OT] EuroPython anyone?
I just bought tickets for EuroPython (http://ep2011.europython.eu/) and I'm wondering if anyone here is going to the event. It would be nice to meet some Fedora friend there :) -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/29/2011 06:56 PM, Lennart Poettering wrote: On Fri, 29.04.11 00:37, Michał Piotrowski (mkkp...@gmail.com) wrote: Hi, I think it's a very good decision - I never understood why selinux dir is directly under /. Yes, I think this would be a good thing to have in F16. Note however that this needs a tiny kernel patch to work, to create the mount point under /sys/fs/selinux. This is a trivial patch and has been done for /sys/fs/cgroup before, so I assume this would be easy to get in and just needs a champion to push this forward. By the way, maybe it would be good to think about the meaning of /srv existance? For seven years FHS requires that this directory exists http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A but The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done - so even the authors of the standard did not have anything to say about how this directory should be used. Is there a rational reason for the existence of this directory besides FHS conformance? I think /srv actually makes a lot of sense. Probably not so much on the desktop, but the boundaries are blurry, and I see no reason to set things up differently in this respect between servers and desktops. I see little benefit in removing this directory. Lennart I think moving /selinux is a bit more complicated then just a simple kernel change. We have libselinux changes, Lots of tools have learned over the years the path of /selinux and lots of users know about it. I am willing to work towards the goal of moving /selinux, but I might end up with a symbolic link if we can not fix all of the problems. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk27RKUACgkQrlYvE4MpobOCoACgvLrAnXtzvxV7ztHP4aiGr8Df VZ4AnAnqTzUofp62+IHkc9WmTvh74sRE =NLi7 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
On Fri, 29.04.11 11:21, Daniel J Walsh (dwa...@redhat.com) wrote:
I guess I missed some discussion of this. You'd need to update
libselinux at least, definition of SELINUXMNT in
libselinux/src/policy.h, used by selinux_init_load_policy() to mount
selinuxfs for initial policy load. And it may break rc scripts and
other scripts/programs that have become accustomed to /selinux.
Here is the patch I am thinking about.
I think mock might need to be updated, maybe livecd tools.
+ /* We check to see if the original mount point for selinux file
+ * system has a selinuxfs. */
+ do {
+ rc = statfs(/selinux, sfbuf);
+ } while (rc 0 errno == EINTR);
+ if (rc == 0) {
+ if ((uint32_t)sfbuf.f_type == (uint32_t)SELINUX_MAGIC) {
+ selinux_mnt = strdup(/selinux);
+ return;
+ }
I like the patch.
One little feature request where we already are on this:
Given that there is a statfs() in here anyway, could we also maybe
extend this a tiny bit, and add a statvfs() call as well, and if
ST_RDONLY is set in .f_flag consider selinux to be off? That would be
very handy in containers/chroots and stuff like that, where you might
want to make the container assume selinux is off even though the host
has it enabled. If the container/chroot manager simply bind mounts
/selinux into the namespace read-only this would then be an effective
way to make selinux appear off to the container code.
I think using whether /selinux is read-only as a flag for selinux off is
a pretty natural nice way.
mock currently tries do work-around this by placing a fake
/proc/filesystems file in the namespace, and I think that's quite
ugly. Using read-only /selinux as flag appears much nicer to me, since
it in itself already disables a number of selinux operations.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
On Fri, 29.04.11 11:07, Stephen Smalley (s...@tycho.nsa.gov) wrote: On Fri, 2011-04-29 at 00:37 +0200, Michał Piotrowski wrote: Hi, I think it's a very good decision - I never understood why selinux dir is directly under /. I guess I missed some discussion of this. You'd need to update libselinux at least, definition of SELINUXMNT in libselinux/src/policy.h, used by selinux_init_load_policy() to mount selinuxfs for initial policy load. And it may break rc scripts and other scripts/programs that have become accustomed to /selinux. Yupp, systemd would also need a fix for this. But I'd be more than happy to make this change. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
2011/4/30 Daniel J Walsh dwa...@redhat.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/29/2011 06:56 PM, Lennart Poettering wrote: On Fri, 29.04.11 00:37, Michał Piotrowski (mkkp...@gmail.com) wrote: Hi, I think it's a very good decision - I never understood why selinux dir is directly under /. Yes, I think this would be a good thing to have in F16. Note however that this needs a tiny kernel patch to work, to create the mount point under /sys/fs/selinux. This is a trivial patch and has been done for /sys/fs/cgroup before, so I assume this would be easy to get in and just needs a champion to push this forward. By the way, maybe it would be good to think about the meaning of /srv existance? For seven years FHS requires that this directory exists http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A but The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done - so even the authors of the standard did not have anything to say about how this directory should be used. Is there a rational reason for the existence of this directory besides FHS conformance? I think /srv actually makes a lot of sense. Probably not so much on the desktop, but the boundaries are blurry, and I see no reason to set things up differently in this respect between servers and desktops. I see little benefit in removing this directory. Lennart I think moving /selinux is a bit more complicated then just a simple kernel change. We have libselinux changes, Lots of tools have learned over the years the path of /selinux and lots of users know about it. I am willing to work towards the goal of moving /selinux, but I might end up with a symbolic link if we can not fix all of the problems. What was the original intention of creating selinux directory directly under / ? Was this file system created at a 2.4 times when sysfs didn't existed yet? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk27RKUACgkQrlYvE4MpobOCoACgvLrAnXtzvxV7ztHP4aiGr8Df VZ4AnAnqTzUofp62+IHkc9WmTvh74sRE =NLi7 -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-15 Branched report: 20110429 changes
Compose started at Fri Apr 29 13:15:40 UTC 2011 Broken deps for x86_64 -- collectd-mysql-4.10.2-2.fc15.x86_64 requires libmysqlclient.so.16()(64bit) collectd-mysql-4.10.2-2.fc15.x86_64 requires libmysqlclient.so.16(libmysqlclient_16)(64bit) cpm-0.23-0.3.beta.fc12.x86_64 requires libdotconf-1.0.so.0()(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 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 eog-plugins-2.91.90-1.fc15.x86_64 requires libchamplain-gtk-0.10.so.0()(64bit) eog-plugins-2.91.90-1.fc15.x86_64 requires libchamplain-0.10.so.0()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) glunarclock-0.34.1-1.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-bubblemon-2.0.15-1.fc13.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-cpufire-1.6-3.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-globalmenu-0.7.9-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-music-2.5.1-5.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0 gnome-applet-sensors-2.2.7-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sshmenu-3.18-3.fc15.noarch requires ruby(panelapplet2) gnome-applet-window-picker-0.5.8-2.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) 1:gnome-applets-2.32.0-3.fc15.x86_64 requires libpanel-applet-3.so.0()(64bit) 1:gnome-applets-2.32.0-3.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) 1:gnome-applets-2.32.0-3.fc15.x86_64 requires libgweather.so.1()(64bit) gnome-netstatus-2.28.2-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotd.so.5()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotdcm.so.4()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotdconduit.so.3()(64bit) gnome-python2-applet-2.32.0-1.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-gdl-2.25.3-22.fc15.x86_64 requires libgdl-1.so.3()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0 gnomeradio-1.8-9.fc15.x86_64 requires libgtk-3.0.so.0()(64bit) gnomeradio-1.8-9.fc15.x86_64 requires libgdk-3.0.so.0()(64bit) gnotime-2.3.0-8.fc15.x86_64 requires libgtkhtml-3.15.so.19()(64bit) gnubiff-2.2.13-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnustep-back-0.18.0-4.fc14.x86_64 requires libobjc.so.2()(64bit) gnustep-back-0.18.0-4.fc14.x86_64 requires libgnustep-base.so.1.20()(64bit) gnustep-examples-1.3.0-4.fc15.x86_64 requires libgnustep-base.so.1.20()(64bit) gnustep-examples-1.3.0-4.fc15.x86_64 requires libobjc.so.2()(64bit) gnustep-gui-0.18.0-2.fc14.x86_64 requires libgnustep-base.so.1.20()(64bit) gnustep-gui-0.18.0-2.fc14.x86_64 requires libobjc.so.2()(64bit) gnustep-gui-libs-0.18.0-2.fc14.i686 requires libobjc.so.2 gnustep-gui-libs-0.18.0-2.fc14.i686 requires libgnustep-base.so.1.20 gnustep-gui-libs-0.18.0-2.fc14.x86_64 requires libgnustep-base.so.1.20()(64bit) gnustep-gui-libs-0.18.0-2.fc14.x86_64 requires libobjc.so.2()(64bit) gold-2.1.12.2-5.fc15.noarch requires perl(Data::Properties) gorm-1.2.12-2.fc15.i686 requires libobjc.so.2 gorm-1.2.12-2.fc15.i686 requires libgnustep-base.so.1.20 gorm-1.2.12-2.fc15.x86_64 requires libgnustep-base.so.1.20()(64bit) gorm-1.2.12-2.fc15.x86_64 requires libobjc.so.2()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-gtk-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libgdl-1.so.3()(64bit) gyachi-plugin-libnotify-1.2.10-3.fc14.x86_64 requires libnotify.so.1()(64bit)
Re: wireless-tools/net-tools are DEPRECATED
On Fri, Apr 29, 2011 at 12:30:02PM -0500, Dan Williams wrote: Looking at the code, the 4-second delay is only used when the device is actually connected to something. State 3 == DISCONNECTED, state 2 == UNAVAILABLE, so it's performing as expected here. Were there actually an IP address assigned to 'nf' then the 4-second delay would be used. Given that nothing really happens to the device when it's DISCONNECTED anyway, the logs you see are pretty much a NOP for NM. I would really /love/ it if NM could log the human readable state names and reason codes, rather than the cryptic numbers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
On Fri, 29.04.11 16:34, Greg KH (g...@kroah.com) wrote: I think it's a very good decision - I never understood why selinux dir is directly under /. Yes, I think this would be a good thing to have in F16. Note however that this needs a tiny kernel patch to work, to create the mount point under /sys/fs/selinux. This is a trivial patch and has been done for /sys/fs/cgroup before, so I assume this would be easy to get in and just needs a champion to push this forward. As I did this for /sys/fs/cgroup I can do it for /sys/fs/selinux as well, just let me know. I'd say yes, please to this, right-away. But I guess this is up to Dan Walsh to say. Dan, could you say yes to this, please? If so, then the first step to making this happen for F16 would already have been taken! Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
On Fri, 29.04.11 17:46, Greg KH (g...@kroah.com) wrote: I think /srv actually makes a lot of sense. Probably not so much on the desktop, but the boundaries are blurry, and I see no reason to set things up differently in this respect between servers and desktops. I see little benefit in removing this directory. Lennart I think moving /selinux is a bit more complicated then just a simple kernel change. We have libselinux changes, Lots of tools have learned over the years the path of /selinux and lots of users know about it. I am willing to work towards the goal of moving /selinux, but I might end up with a symbolic link if we can not fix all of the problems. A symbolic link from /selinux to point at /sys/fs/selinux/ is a good idea to help people migrate. The startup tools should be able to create this if /sys/fs/selinux/ is not present, right? This is not necessarily easy to do actually, since for upgraded systems /selinux needs to be an actual directory in the rootfs to be useful as mount points. At boot time the rootfs is read-only, hence removing the dir then and turning it into a symlink is difficult. However, we can use the same approach as we did for moving /var/run to /run: on new installs create it as a symlink and on upgrades simply make it a bind mount. For the long run we could also add %post scripts to filesystem.rpm which moves away the old /selinux, and recreates it as symlink. Unfortunately that cannot be done completely atomic, but that property is not really necessary here anyway I think. So, yeah, it isn't super-pretty doing this move, but we can handle it more or less exactly like the /var/run → /run move. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: unison updates
On Tue, Apr 26, 2011 at 09:08:10PM -0400, Bill McGonigle wrote: On 04/19/2011 05:49 PM, Adam Williamson wrote: Actually it looks like I was even lazier than that and just built it from source. I seem to be running 2.32.52. I just needed whatever version would interoperate with my Mandriva machines. Good news is current unison builds just fine with the existing SPEC with trivial updates. Can somebody recommend an existing package to use as an example that maintains multiple versions of a source tree to build multiple versions of the main binary? Don't do that. It's not a good path to take. When you have multiple binary rpms built from a single source rpm, anytime there's a change to any of the included sources all of the binary rpms end up being updated. This is not desirable for end users. Yes, maintaining separate source and binary packages is more work for the packager but it is nicer for the end user. -Toshio pgpjUCE6QLejV.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Some changes to EPEL package reviews
On 4/29/2011 9:12, Jesse Keating wrote: It is somewhat difficult, and odd, to create a git repo that does not have a master branch. It would be a little more odd to potentially at some point in the future create the master branch for a package should it find a home within Fedora. As you say, this practice is somewhat unusual, but it is not difficult. It takes but a single easily-scriptable command prior to the first commit to change the name of the initial branch. Since Fedora's repo creation scripts already do an initial commit in every new package repository this should not be difficult to add to that process. Creating a master branch where none existed would primarily be a matter of deciding which existing branch to branch the new master branch from. This part should only be difficult to do programmatically if the desired preexisting branch is not the initial one that the repository's first commit was created on. There need not be much/any content in the master branch, but there should still be one for each package. For the sake of code simplicity, I agree: every repo ought to have a master branch. Having one omnipresent branch lets Fedora's repo management scripts make some very useful assumptions. (Yes, this opinion flies in the face of my previous statements.) ;-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-List-UtilsBy/f13/master] (6 commits) ...Merge.
Summary of changes: 31ad9d8... Import. (*) 81f8ea7... Import. (*) f1bd5ab... - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass (*) c7e68e7... Upstream update. Spec cleanup. (*) d831afb... Merge. (*) 974fea1... Merge. (*) 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-List-UtilsBy/f13/master: 6/6] Merge.
commit 974fea1492e7db654b61777c9ea5d608c8517355 Merge: 815d06a d831afb Author: Ralf Corsépius corse...@fedoraproject.org Date: Fri Apr 29 08:02:18 2011 +0200 Merge. .gitignore |1 + perl-List-UtilsBy.spec | 12 +--- sources|2 +- 3 files changed, 7 insertions(+), 8 deletions(-) --- -- 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-File-Slurp/f15/master] Upstream update.
Summary of changes: 222729b... Upstream update. (*) (*) 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
Re: About placement of dual-life modules
On Tue, Apr 26, 2011 at 2:40 PM, Robin Lee robinlee.s...@gmail.com wrote:
On Tue, Apr 26, 2011 at 5:51 PM, Petr Pisar ppi...@redhat.com wrote:
On Fri, Apr 22, 2011 at 11:00:46PM +0800, Robin Lee wrote:
Some dual-life modules, like PathTools and CGI, are placed within
vendor path in Fedora 15. This situation is not expected by some
applications, for example, cpanm -L command will definitely fail if
an installing package needs such dual-life modules.
This is problem of that applications. They should not expect exact location.
Not really. I think it's legitimate to assume that core modules are
available in archlib/privlib. In a normal perl installation, that's
always true. When upgrading a dual-lifed module from the CPAN, you
don't remove or overwrite the files from core, you just install the
new version in sitearch/sitelib.
Formally, some packagers wanted to install all Fedora modules into core.
That would also break cpanm -L by making it think that *all*
installed modules were part of core and then failing to pick up any
non-core dependencies. This is a good reason to keep the proper
core/vendor split with all of our modules going to vendor.
But
there are some RPM-related problems (files in debuginfo subpackages would
conflict because debug data are delivered by one subpackage for all
subpackages together) and some packagers were against it.
I agree that this is the true obstacle.
Yep, this prevents a simple workaround of installing arch-specific
dual-lifed modules from the cpan in core directories. I think for
noarch packages, we're okay.
There is a possible solution, though - basically replicating what
normal perl does. Rather than uninstalling the core module when
replaced with cpan version, arrange things so that both core version
and cpan version are installed simultaneously (or core version only if
that's newer than cpan version).
In perl.spec, we can create additional perlcore-Dist-Name sub-packages, e.g:
%package Scalar-List-Utils
Summary:A selection of general-utility scalar and list subroutines
Group: Development/Libraries
License:GPL+ or Artistic
%global Scalar_List_Utils_epoch 0
%global Scalar_List_Utils_version 1.22
Epoch: %{Scalar_List_Utils_epoch}
Version:%{Scalar_List_Utils_version}
Requires: perl = %{perl_epoch}:%{perl_version}-%{release}
Requires: perlcore-Scalar-List-Utils = %{epoch}:%{version}-%{release}
Obsoletes: perlcpan-Scalar-List-Utils = %{epoch}:%{version}-%{release}
%description Scalar-List-Utils
Scalar::Util and List::Util contain a selection of subroutines that people have
expressed would be nice to have in the perl core, but the usage would not
really be high enough to warrant the use of a keyword, and the size so small
such that being individual extensions would be wasteful.
%package -n perlcore-Scalar-List-Utils
Summary:Scalar-List-Utils from Perl core
Group: Development/Libraries
License:GPL+ or Artistic
Epoch: %{Scalar_List_Utils_epoch}
Version:%{Scalar_List_Utils_version}
Requires: perl = %{perl_epoch}:%{perl_version}-%{release}
Requires: perl-Scalar-List-Utils = %{epoch}:%{version}-%{release}
%description -n perlcore-Scalar-List-Utils
Scalar-List-Utils implementation from Perl core.
%files Scalar-List-Utils
%{_mandir}/man3/List::Util*
%{_mandir}/man3/Scalar::Util*
%files -n perlcore-Scalar-List-Utils
%defattr(-,root,root,-)
%{archlib}/List/
%{archlib}/List/Util/
%{archlib}/List/Util.pm
%{archlib}/Scalar/
%{archlib}/Scalar/Util/
%{archlib}/Scalar/Util.pm
%{archlib}/auto/List/
%{archlib}/auto/List/Util/
And in each of the dual-lifed perl-Dist-Name packages, create
perlcpan-Dist-Name sub-packages, e.g:
%package -n perlcpan-Scalar-List-Utils
Summary:Scalar-List-Utils from the CPAN
Group: Development/Libraries
License:GPL+ or Artistic
Requires: perl-Scalar-List-Utils = %{epoch}:%{version}-%{release}
%description -n perlcpan-Scalar-List-Utils
Scalar-List-Utils implementation from the CPAN.
%files
%defattr(-,root,root,-)
%doc Changes README
%{_mandir}/man3/*
%files -n perlcpan-Scalar-List-Utils
%{perl_vendorarch}/auto/*
%{perl_vendorarch}/List*
%{perl_vendorarch}/Scalar*
So that we end up with:
perl-Scalar-List-Utils-1.22-158.fc15.x86_64.rpm
perlcore-Scalar-List-Utils-1.22-158.fc15.x86_64.rpm
and
perl-Scalar-List-Utils-1.23-2.fc15.x86_64.rpm
perlcpan-Scalar-List-Utils-1.23-2.fc15.x86_64.rpm
Where perlcpan-Scalar-List-Utils-1.23 is the best provider of
perl(Scalar::Util) and the dependencies ensure that perlcpan package
pulls in perl-Scalar-List-Utils-1.23, which in turn pulls in
perlcore-Scalar-List-Utils-1.22.
If at some point in the future, perl 5.14.x comes with a newer
Scalar-List-Utils, we end up with
perl-Scalar-List-Utils-1.24-199.fc16.x86_64.rpm
perlcore-Scalar-List-Utils-1.24-199.fc16.x86_64.rpm
and
perl-Scalar-List-Utils-1.23-2.fc15.x86_64.rpm
[Bug 700412] perl-Software-License-0.103001 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=700412 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Software-License-0.103 |perl-Software-License-0.103 |000 is available|001 is available --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org 2011-04-29 06:46:57 EDT --- Latest upstream release: 0.103001 Current version in Fedora Rawhide: 0.102341 URL: http://search.cpan.org/dist/Software-License/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: About placement of dual-life modules
On Fri, Apr 29, 2011 at 10:45:40AM +0200, Iain Arnell wrote:
On Tue, Apr 26, 2011 at 2:40 PM, Robin Lee robinlee.s...@gmail.com wrote:
On Tue, Apr 26, 2011 at 5:51 PM, Petr Pisar ppi...@redhat.com wrote:
On Fri, Apr 22, 2011 at 11:00:46PM +0800, Robin Lee wrote:
Some dual-life modules, like PathTools and CGI, are placed within
vendor path in Fedora 15. This situation is not expected by some
applications, for example, cpanm -L command will definitely fail if
an installing package needs such dual-life modules.
This is problem of that applications. They should not expect exact
location.
Not really. I think it's legitimate to assume that core modules are
available in archlib/privlib. In a normal perl installation, that's
always true. When upgrading a dual-lifed module from the CPAN, you
don't remove or overwrite the files from core, you just install the
new version in sitearch/sitelib.
Formally, some packagers wanted to install all Fedora modules into core.
That would also break cpanm -L by making it think that *all*
installed modules were part of core and then failing to pick up any
non-core dependencies. This is a good reason to keep the proper
core/vendor split with all of our modules going to vendor.
But
there are some RPM-related problems (files in debuginfo subpackages would
conflict because debug data are delivered by one subpackage for all
subpackages together) and some packagers were against it.
I agree that this is the true obstacle.
Yep, this prevents a simple workaround of installing arch-specific
dual-lifed modules from the cpan in core directories. I think for
noarch packages, we're okay.
There is a possible solution, though - basically replicating what
normal perl does. Rather than uninstalling the core module when
replaced with cpan version, arrange things so that both core version
and cpan version are installed simultaneously (or core version only if
that's newer than cpan version).
In perl.spec, we can create additional perlcore-Dist-Name sub-packages, e.g:
%package Scalar-List-Utils
Summary:A selection of general-utility scalar and list subroutines
Group: Development/Libraries
License:GPL+ or Artistic
%global Scalar_List_Utils_epoch 0
%global Scalar_List_Utils_version 1.22
Epoch: %{Scalar_List_Utils_epoch}
Version:%{Scalar_List_Utils_version}
Requires: perl = %{perl_epoch}:%{perl_version}-%{release}
Requires: perlcore-Scalar-List-Utils = %{epoch}:%{version}-%{release}
Obsoletes: perlcpan-Scalar-List-Utils = %{epoch}:%{version}-%{release}
%description Scalar-List-Utils
Scalar::Util and List::Util contain a selection of subroutines that people
have
expressed would be nice to have in the perl core, but the usage would not
really be high enough to warrant the use of a keyword, and the size so small
such that being individual extensions would be wasteful.
%package -n perlcore-Scalar-List-Utils
Summary:Scalar-List-Utils from Perl core
Group: Development/Libraries
License:GPL+ or Artistic
Epoch: %{Scalar_List_Utils_epoch}
Version:%{Scalar_List_Utils_version}
Requires: perl = %{perl_epoch}:%{perl_version}-%{release}
Requires: perl-Scalar-List-Utils = %{epoch}:%{version}-%{release}
%description -n perlcore-Scalar-List-Utils
Scalar-List-Utils implementation from Perl core.
%files Scalar-List-Utils
%{_mandir}/man3/List::Util*
%{_mandir}/man3/Scalar::Util*
%files -n perlcore-Scalar-List-Utils
%defattr(-,root,root,-)
%{archlib}/List/
%{archlib}/List/Util/
%{archlib}/List/Util.pm
%{archlib}/Scalar/
%{archlib}/Scalar/Util/
%{archlib}/Scalar/Util.pm
%{archlib}/auto/List/
%{archlib}/auto/List/Util/
And in each of the dual-lifed perl-Dist-Name packages, create
perlcpan-Dist-Name sub-packages, e.g:
%package -n perlcpan-Scalar-List-Utils
Summary:Scalar-List-Utils from the CPAN
Group: Development/Libraries
License:GPL+ or Artistic
Requires: perl-Scalar-List-Utils = %{epoch}:%{version}-%{release}
%description -n perlcpan-Scalar-List-Utils
Scalar-List-Utils implementation from the CPAN.
%files
%defattr(-,root,root,-)
%doc Changes README
%{_mandir}/man3/*
%files -n perlcpan-Scalar-List-Utils
%{perl_vendorarch}/auto/*
%{perl_vendorarch}/List*
%{perl_vendorarch}/Scalar*
So that we end up with:
perl-Scalar-List-Utils-1.22-158.fc15.x86_64.rpm
perlcore-Scalar-List-Utils-1.22-158.fc15.x86_64.rpm
and
perl-Scalar-List-Utils-1.23-2.fc15.x86_64.rpm
perlcpan-Scalar-List-Utils-1.23-2.fc15.x86_64.rpm
Where perlcpan-Scalar-List-Utils-1.23 is the best provider of
perl(Scalar::Util) and the dependencies ensure that perlcpan package
pulls in perl-Scalar-List-Utils-1.23, which in turn pulls in
perlcore-Scalar-List-Utils-1.22.
If at some point in the future, perl 5.14.x comes with a newer
[perl-File-Slurp/f14/master: 2/2] Merge remote-tracking branch 'origin/master' into f14/master
commit 3bf6ef6ace704aa06bb16be653cfa987f2526e75 Merge: 29721ee 222729b Author: Ralf Corsépius corse...@fedoraproject.org Date: Fri Apr 29 14:31:49 2011 +0200 Merge remote-tracking branch 'origin/master' into f14/master .gitignore |1 + perl-File-Slurp.spec |5 - sources |2 +- 3 files changed, 6 insertions(+), 2 deletions(-) --- -- 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-File-Slurp/f13/master] (2 commits) ...Merge remote-tracking branch 'origin/master' into f13/master
Summary of changes: 222729b... Upstream update. (*) 751485d... Merge remote-tracking branch 'origin/master' into f13/maste (*) 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-File-Slurp/f13/master: 2/2] Merge remote-tracking branch 'origin/master' into f13/master
commit 751485daa150ab25d3d8175bd9535391afbca60c Merge: 81c74a4 222729b Author: Ralf Corsépius corse...@fedoraproject.org Date: Fri Apr 29 14:34:58 2011 +0200 Merge remote-tracking branch 'origin/master' into f13/master .gitignore |1 + perl-File-Slurp.spec |5 - sources |2 +- 3 files changed, 6 insertions(+), 2 deletions(-) --- -- 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-HTML-Format/f14/master] (5 commits) ...Merge.
Summary of changes: ab2d6e6... - 661697 rebuild for fixing problems with vendorach/lib (*) 845754e... - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass (*) 8b78c3b... Upstream update. Reflect Source0:-URL having changed. Rewor (*) f5a7142... Upstream update. Reflect upstream having switched to Build. (*) d2c282a... Merge. (*) 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-HTML-Format/f14/master: 5/5] Merge.
commit d2c282afd6ef9003b579d31e49f2a7de49da6a7f Author: Ralf Corsépius corse...@fedoraproject.org Date: Fri Apr 29 18:49:01 2011 +0200 Merge. perl-HTML-Format.spec |9 - 1 files changed, 0 insertions(+), 9 deletions(-) --- diff --git a/perl-HTML-Format.spec b/perl-HTML-Format.spec index 32fb970..afe2079 100644 --- a/perl-HTML-Format.spec +++ b/perl-HTML-Format.spec @@ -87,18 +87,9 @@ RELEASE_TESTING=1 ./Build test * Fri Apr 29 2011 Ralf Corsépius corse...@fedoraproject.org - 2.07-1 - Upstream update. - Reflect upstream having switched to Build.PL. - -* Thu Mar 03 2011 Ralf Corsépius corse...@fedoraproject.org - 2.05-1 -- Upstream update. - Reflect Source0:-URL having changed. - Rework spec-file. -* Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org - 2.04-15 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild - -* Fri Dec 17 2010 Marcela Maslanova mmasl...@redhat.com - 2.04-14 -- 661697 rebuild for fixing problems with vendorach/lib - * Sun May 02 2010 Marcela Maslanova mmasl...@redhat.com - 2.04-13 - Mass rebuild with perl-5.12.0 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 700923] [abrt] perl-Padre-0.64-1.fc14: Process /usr/bin/perl was killed by signal 11 (SIGSEGV)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=700923 --- Comment #1 from Gajdos Tamás gajdipa...@gmail.com 2011-04-29 15:44:06 EDT --- Created attachment 495852 -- https://bugzilla.redhat.com/attachment.cgi?id=495852 File: backtrace -- 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 700923] New: [abrt] perl-Padre-0.64-1.fc14: Process /usr/bin/perl was killed by signal 11 (SIGSEGV)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: [abrt] perl-Padre-0.64-1.fc14: Process /usr/bin/perl was killed by signal 11 (SIGSEGV) https://bugzilla.redhat.com/show_bug.cgi?id=700923 Summary: [abrt] perl-Padre-0.64-1.fc14: Process /usr/bin/perl was killed by signal 11 (SIGSEGV) Product: Fedora Version: 14 Platform: i686 OS/Version: Unspecified Status: NEW Status Whiteboard: abrt_hash:03e6c96a7df85ce266a02d4fef52f18b4dd80536 Severity: unspecified Priority: unspecified Component: perl-Padre AssignedTo: mmasl...@redhat.com ReportedBy: gajdipa...@gmail.com QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora Story Points: --- abrt version: 1.1.18 architecture: i686 Attached file: backtrace, 56249 bytes cmdline: /usr/bin/perl /usr/bin/padre component: perl-Padre Attached file: coredump, 20484096 bytes crash_function: wxControlContainer::SetLastFocus executable: /usr/bin/perl kernel: 2.6.35.10-74.fc14.i686 package: perl-Padre-0.64-1.fc14 rating: 4 reason: Process /usr/bin/perl was killed by signal 11 (SIGSEGV) release: Fedora release 14 (Laughlin) time: 1295971294 uid: 0 How to reproduce - 1. 2. 3. Don't know. I'm just an operator. -- 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
[389-devel] Please Review: (700875) Cleanup ds_bring_up_server_install() in dsalib
https://bugzilla.redhat.com/show_bug.cgi?id=700875 https://bugzilla.redhat.com/attachment.cgi?id=495819action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
