Agenda for FESCo meeting (2011-09-19)
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 17:00UTC (1:00pm EDT) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #663 Late F16 Feature Java7 .fesco 663 #topic #664 Older releases need a different approach for updates / karma .fesco 664 #topic #667 Request to fix CRITPATH update process .fesco 667 = New business = #topic #669 remove non-yum depsolvers from fedora defaults .fesco 669 #topic #670 Problems with device-mapper-multipath on sysv to systemd upgrade .fesco 670 = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On 19 September 2011 01:46, Kevin Kofler kevin.kof...@chello.at wrote: Well, looks like we also need a rebuild of PackageKit-zif against the new soname (libzif.so.3, the package in F15 is built against libzif.so.2), so I think the repo is the best solution if we want people to be able to test this. Richard, what do you think? This is why I didn't backport the new zif to F15. If you're confident doing the PK and zif rebuild for F15 at the same time then I'm happy just to stick it in F15 properly rather than having a separate repo. I didn't trust myself enough to not break PK in a stable release, although it would only affect people with PackageKit-zif already installed. I'm okay with either solution. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2011-09-19 @ 15:00 UTC - Fedora QA Meeting
WHAT: Fedora QA Meeting WHEN: 15:00 UTC (11:00 EDT, 08:00 PDT) WHERE: #fedora-meeting It's meeting time again! We'll be dominated by Beta discussion this time, I expect, so I'm clearing the schedule decks for that. Please bring any bugs or other things you're particularly concerned about for Beta along with you. We have some icky blocker bugs to talk about. If anyone has anything to add to the agenda, please reply to this mail, and whoever ends up running the meeting will add it. Thanks! Proposed agenda: * Previous meeting follow-up (https://fedoraproject.org/wiki/QA/Meetings/20110829) * Beta preparation * Open discussion -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Mon, Sep 19, 2011 at 02:40:30AM +0200, Kevin Kofler wrote:
The use case I have in mind, which is a real-world case, is this:
phonon Requires: phonon-backend
phonon-backend-* Provides: phonon-backend
phonon-backend-* Requires: phonon
I want any random phonon-backend-* to satisfy the dependency, HOWEVER, I
want installing phonon when it previously wasn't installed to always drag in
phonon-backend-gstreamer, our default backend and the one working the best,
not some random backend which happens to have fewer dependencies. Yum's
convoluted logic is making it basically impossible to do that, and in fact,
on the RPM Fusion builders, phonon-backend-vlc is selected instead, which is
always fun because it means vlc's regular broken dependencies can break
builds of anything KDE-related in RPM Fusion. (I had a k3b-extras-freeworld
build break because of this very issue.) I guess users installing KDE with
RPM Fusion Free enabled will also get the VLC backend by default, which is
not what we want.
Sounds like you want weak dependencies (i.e. Suggests et al).
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
Matthew Garrett wrote: Debian policy is that any virtual dependencies must also have an explicit dependency. In your case it would be something like Requires: phonon-backend-gstreamer | phonon-backend Unfortunately, RPM does not support this idiom. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
Michael Schroeder wrote: Sounds like you want weak dependencies (i.e. Suggests et al). In this case, I think disjunctive dependencies (default | virtual), as Matthew Garrett pointed out, are the right solution, not soft dependencies (though those would also be nice). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
how to make systemd wait for a process to die?
Hello, I'm making a systemd service file for gogoc, a program to create IPv6 tunnels with Freenet6.net The program gets the network configuration and uses a shell script for configuring the interface, and when receives the HUP signal, calls the shell script again for shutting down the tunnel, but it needs a few seconds for doing this. What's the better way for doing this? at the moment, I do: [Service] WorkingDirectory=/var/lib/gogoc Type=simple EnvironmentFile=-/etc/sysconfig/gogoc ExecStart=/usr/bin/gogoc -f /etc/gogoc/gogoc.conf $GOGOC_OPTS ExecStop=/bin/kill -s SIGHUP $MAINPID it sends the HUP, but then it kills the daemon immediately, there's no time for shutting down the tunnel properly. Is correct to put a sleep? It looks awful ExecStop=/bin/kill -s SIGHUP $MAINPID; sleep 5 What do you think? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to make systemd wait for a process to die?
On 09/19/2011 11:25 AM, Juan Orti Alcaine wrote: [Service] WorkingDirectory=/var/lib/gogoc Type=simple EnvironmentFile=-/etc/sysconfig/gogoc ExecStart=/usr/bin/gogoc -f /etc/gogoc/gogoc.conf $GOGOC_OPTS ExecStop=/bin/kill -s SIGHUP $MAINPID Try this totally untested instead... [Service] WorkingDirectory=/var/lib/gogoc EnvironmentFile=-/etc/sysconfig/gogoc ExecStart=/usr/bin/gogoc -f /etc/gogoc/gogoc.conf $GOGOC_OPTS TimeoutSec=5 KillMode=process KillSignal=SIGHUP -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Mon, Sep 19, 2011 at 01:00:35PM +0200, Kevin Kofler wrote: Matthew Garrett wrote: Debian policy is that any virtual dependencies must also have an explicit dependency. In your case it would be something like Requires: phonon-backend-gstreamer | phonon-backend Unfortunately, RPM does not support this idiom. I know. I'm just pointing out that this is a problem that's been solved in the past. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Why was the design-suite group added to comps?
Hi, I wonder why the 'design-suite' group was added to comps. According to the wiki the idea of the feature was to *rename* the 'graphics' group [1] but now we have two apps with graphic apps. Looks kind of off in gpk-application's group view. Adding the feature owner and the committer to CC. Regards, Christoph [1] https://fedoraproject.org/wiki/Features/Design_Suite_Group -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to make systemd wait for a process to die?
It works. I deleted the line KillMode because it has some child processes I want to shut down even if the script times out. I have increased the timeout to 30 secs because I noticed sometimes it takes a lot longer to close the tunnel. Is there any problem about this? This is the way I have it: [Service] WorkingDirectory=/var/lib/gogoc Type=simple EnvironmentFile=-/etc/sysconfig/gogoc ExecStart=/usr/bin/gogoc -f /etc/gogoc/gogoc.conf $GOGOC_OPTS TimeoutSec=30 KillSignal=SIGHUP 2011/9/19 Jóhann B. Guðmundsson johan...@gmail.com Try this totally untested instead... [Service] WorkingDirectory=/var/lib/gogoc EnvironmentFile=-/etc/sysconfig/gogoc ExecStart=/usr/bin/gogoc -f /etc/gogoc/gogoc.conf $GOGOC_OPTS TimeoutSec=5 KillMode=process KillSignal=SIGHUP -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Data-Section-Simple/el6] Update to 0.03
Summary of changes: 44f0225... Update to 0.03 (*) (*) 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
rawhide report: 20110919 changes
Compose started at Mon Sep 19 08:15:01 UTC 2011 Broken deps for x86_64 -- 389-admin-1.1.23-1.fc17.i686 requires libicuuc.so.46 389-admin-1.1.23-1.fc17.i686 requires libicui18n.so.46 389-admin-1.1.23-1.fc17.i686 requires libicudata.so.46 389-admin-1.1.23-1.fc17.x86_64 requires libicuuc.so.46()(64bit) 389-admin-1.1.23-1.fc17.x86_64 requires libicui18n.so.46()(64bit) 389-admin-1.1.23-1.fc17.x86_64 requires libicudata.so.46()(64bit) 389-adminutil-1.1.14-1.fc16.i686 requires libicuuc.so.46 389-adminutil-1.1.14-1.fc16.i686 requires libicui18n.so.46 389-adminutil-1.1.14-1.fc16.i686 requires libicudata.so.46 389-adminutil-1.1.14-1.fc16.x86_64 requires libicuuc.so.46()(64bit) 389-adminutil-1.1.14-1.fc16.x86_64 requires libicui18n.so.46()(64bit) 389-adminutil-1.1.14-1.fc16.x86_64 requires libicudata.so.46()(64bit) 389-dsgw-1.1.7-1.fc16.x86_64 requires libicuuc.so.46()(64bit) 389-dsgw-1.1.7-1.fc16.x86_64 requires libicui18n.so.46()(64bit) 389-dsgw-1.1.7-1.fc16.x86_64 requires libicudata.so.46()(64bit) R-core-2.13.1-4.fc17.i686 requires libicuuc.so.46 R-core-2.13.1-4.fc17.i686 requires libicui18n.so.46 R-core-2.13.1-4.fc17.x86_64 requires libicuuc.so.46()(64bit) R-core-2.13.1-4.fc17.x86_64 requires libicui18n.so.46()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libicuuc.so.46()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libicui18n.so.46()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) claws-mail-plugins-geolocation-3.7.9-9.fc17.x86_64 requires libchamplain-gtk-0.10.so.0()(64bit) claws-mail-plugins-geolocation-3.7.9-9.fc17.x86_64 requires libchamplain-0.10.so.0()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicuuc.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicui18n.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicudata.so.46()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave emerillon-0.1.90-1.fc16.x86_64 requires libchamplain-gtk-0.10.so.0()(64bit) emerillon-0.1.90-1.fc16.x86_64 requires libchamplain-0.10.so.0()(64bit) emerillon-devel-0.1.90-1.fc16.i686 requires pkgconfig(champlain-0.10) emerillon-devel-0.1.90-1.fc16.x86_64 requires pkgconfig(champlain-0.10) eog-plugins-3.1.2-2.fc16.x86_64 requires libchamplain-gtk-0.10.so.0()(64bit) eog-plugins-3.1.2-2.fc16.x86_64 requires libchamplain-0.10.so.0()(64bit) fawkes-core-0.4.2-4.fc16.i686 requires libopencv_video.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_objdetect.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_ml.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_legacy.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_imgproc.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_highgui.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_flann.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_features2d.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_core.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires
Delinquent mirror process
I've noticed that mirror.bytemark.co.uk hasn't been updated since 8th September: http://mirror.bytemark.co.uk/fedora/linux/updates/15/x86_64/repodata/ However, it's still being handed out by our mirror list. It seems to me they should be, at least temporarily, dropped as an official mirror. Is there a process for doing that? Also, is there a way to contact them to ask if they've permanently dropped Fedora, or if this is just a blip? Their mirror site suggests only Bytemark customers should contact them. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Delinquent mirror process
On 19/09/11 16:06, Matthew Booth wrote: I've noticed that mirror.bytemark.co.uk hasn't been updated since 8th September: http://mirror.bytemark.co.uk/fedora/linux/updates/15/x86_64/repodata/ However, it's still being handed out by our mirror list. It seems to me they should be, at least temporarily, dropped as an official mirror. Is there a process for doing that? Also, is there a way to contact them to ask if they've permanently dropped Fedora, or if this is just a blip? Their mirror site suggests only Bytemark customers should contact them. I'm a customer so I pinged a tweet at them pointing them at your message. I'm sure they wouldn't have objected to the upstream for the mirror contacting them though. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Starman-0.2014.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Starman: 9f2e58e3d9916148a90edc4c99452bf1 Starman-0.2014.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-Starman] Update to 0.2014
commit 351eb3f2c4996cd228817324c5aa0a72d067b25c
Author: Emmanuel Seyman emmanuel.sey...@club-internet.fr
Date: Mon Sep 19 17:42:42 2011 +0200
Update to 0.2014
.gitignore|1 +
perl-Starman.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 588f3c3..ee402eb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/Starman-0.2013.tar.gz
+/Starman-0.2014.tar.gz
diff --git a/perl-Starman.spec b/perl-Starman.spec
index 7b1e268..1f43d7b 100644
--- a/perl-Starman.spec
+++ b/perl-Starman.spec
@@ -1,6 +1,6 @@
Name: perl-Starman
-Version:0.2013
-Release:3%{?dist}
+Version:0.2014
+Release:1%{?dist}
Summary:High-performance preforking PSGI/Plack web server
License:GPL+ or Artistic
Group: Development/Libraries
@@ -57,6 +57,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Sep 19 2011 Emmanuel Seyman emmanuel.sey...@club-internet.fr 0.2014-1
+- Update to 0.2014
+
* Wed Jul 20 2011 Petr Sabata con...@redhat.com - 0.2013-3
- Perl mass rebuild
diff --git a/sources b/sources
index 5b423fa..1819cb2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-302a9955f8721a5a26f04e7d562f683c Starman-0.2013.tar.gz
+9f2e58e3d9916148a90edc4c99452bf1 Starman-0.2014.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: how to have yum prefer one dependency over others
On Mon, Sep 19, 2011 at 1:00 PM, Kevin Kofler kevin.kof...@chello.at wrote: Matthew Garrett wrote: Debian policy is that any virtual dependencies must also have an explicit dependency. In your case it would be something like Requires: phonon-backend-gstreamer | phonon-backend Unfortunately, RPM does not support this idiom. trolling Why don't you just replace rpm, with deb too, while you are at it ? /trolling -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
FYI: ocamlnet in Rawhide updated to (incompatible) upstream version 3.4
ocamlnet 2.x and 3.x are not compatible. I stuck with ocamlnet 2.x for quite a long time because some other packages dependended on the old API. However ocamlnet 3.x has now been around for well over a year, so it's time to follow upstream. There may be some breakage from this change, but I'll try to fix things as they come up. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
Kevin Kofler wrote on Mon, Sep 19, 2011 at 01:02:26PM +0200: Michael Schroeder wrote: Sounds like you want weak dependencies (i.e. Suggests et al). In this case, I think disjunctive dependencies (default | virtual), as Matthew Garrett pointed out, are the right solution, not soft dependencies (though those would also be nice). Kevin Kofler Functionally speaking, what is the difference between a soft dependency and a disjunctive dependency? How can you satisfy a soft dependency if you don't know what virtual dependency it is being used to provide? -Matyas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Mon, Sep 19, 2011 at 10:51:26AM -0500, Matyas Selmeci wrote: Kevin Kofler wrote on Mon, Sep 19, 2011 at 01:02:26PM +0200: Michael Schroeder wrote: Sounds like you want weak dependencies (i.e. Suggests et al). In this case, I think disjunctive dependencies (default | virtual), as Matthew Garrett pointed out, are the right solution, not soft dependencies (though those would also be nice). Kevin Kofler Functionally speaking, what is the difference between a soft dependency and a disjunctive dependency? How can you satisfy a soft dependency if you don't know what virtual dependency it is being used to provide? If we have: Requires: phonon-backend Suggests: phonon-backend-gstreamer What would you expect the outcome to be on a system that has phonon-backend-xine? I'd have thought that phonon-backend-gstreamer would get installed, even if you can later remove it. That's not the desired outcome. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
Matthew Garrett wrote on Mon, Sep 19, 2011 at 05:00:28PM +0100: On Mon, Sep 19, 2011 at 10:51:26AM -0500, Matyas Selmeci wrote: Kevin Kofler wrote on Mon, Sep 19, 2011 at 01:02:26PM +0200: Michael Schroeder wrote: Sounds like you want weak dependencies (i.e. Suggests et al). In this case, I think disjunctive dependencies (default | virtual), as Matthew Garrett pointed out, are the right solution, not soft dependencies (though those would also be nice). Kevin Kofler Functionally speaking, what is the difference between a soft dependency and a disjunctive dependency? How can you satisfy a soft dependency if you don't know what virtual dependency it is being used to provide? If we have: Requires: phonon-backend Suggests: phonon-backend-gstreamer What would you expect the outcome to be on a system that has phonon-backend-xine? I'd have thought that phonon-backend-gstreamer would get installed, even if you can later remove it. That's not the desired outcome. I see. So 'Suggests' means it gets automatically installed (unless it explicitly conflicts with something already install I presume?), but can be removed without breaking the package it was brought in for (unless no other package provides the phonon-backend dependency). Do I have that right? -Matyas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Mon, Sep 19, 2011 at 5:46 PM, tim.laurid...@gmail.com tim.laurid...@gmail.com wrote: On Mon, Sep 19, 2011 at 1:00 PM, Kevin Kofler kevin.kof...@chello.at wrote: Matthew Garrett wrote: Debian policy is that any virtual dependencies must also have an explicit dependency. In your case it would be something like Requires: phonon-backend-gstreamer | phonon-backend Unfortunately, RPM does not support this idiom. trolling Why don't you just replace rpm, with deb too, while you are at it ? /trolling Well as long as the tools we are talking about 1) Do use rpm 2) Do valid dependency resolution (i.e not --nodeps or something like that) I don't see why we shouldn't allow them. lets say yum install foo does: foo, bar1, baz1 $nonyumtool install foo does: foo, bar2, baz2 Both bar1/baz1 and bar2/baz2 are valid deps for foo (both statify the dependency). So why would it matter what in the end? If that causes bugs then either of the deps are wrong (and the packages in question ought to be fixed). So I don't get what this flamefest is all about ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Mon, Sep 19, 2011 at 11:05:47AM -0500, Matyas Selmeci wrote:
I see. So 'Suggests' means it gets automatically installed (unless it
explicitly conflicts with something already install I presume?), but
can be removed without breaking the package it was brought in for
(unless no other package provides the phonon-backend dependency).
Do I have that right?
Actually 'Recommends' should be used when you want automatic
installation. Suggests is more a hint for the user.
Depsolvers often also use it to break ambiguities, so when
multiple packages provide some dependency, the suggested one
is chosen.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Mon, Sep 19, 2011 at 11:05:47AM -0500, Matyas Selmeci wrote: Matthew Garrett wrote on Mon, Sep 19, 2011 at 05:00:28PM +0100: On Mon, Sep 19, 2011 at 10:51:26AM -0500, Matyas Selmeci wrote: Kevin Kofler wrote on Mon, Sep 19, 2011 at 01:02:26PM +0200: Michael Schroeder wrote: Sounds like you want weak dependencies (i.e. Suggests et al). In this case, I think disjunctive dependencies (default | virtual), as Matthew Garrett pointed out, are the right solution, not soft dependencies (though those would also be nice). Kevin Kofler Functionally speaking, what is the difference between a soft dependency and a disjunctive dependency? How can you satisfy a soft dependency if you don't know what virtual dependency it is being used to provide? If we have: Requires: phonon-backend Suggests: phonon-backend-gstreamer What would you expect the outcome to be on a system that has phonon-backend-xine? I'd have thought that phonon-backend-gstreamer would get installed, even if you can later remove it. That's not the desired outcome. I see. So 'Suggests' means it gets automatically installed (unless it explicitly conflicts with something already install I presume?), but can be removed without breaking the package it was brought in for (unless no other package provides the phonon-backend dependency). Do I have that right? In Debian, 'Suggests', 'Recommends' etc have very specific meanings. See in particular section 7.2 here: http://www.debian.org/doc/debian-policy/ch-relationships.html RPM of course doesn't have anything except hard requirements. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME and Xfce terminal entries not distinguishable in menus
On Sat, Sep 17, 2011 at 12:04:36PM +0200, Jos Vos wrote: After having installed both GNOME and Xfce since F15, I noticed that the GNOME terminal (package gnome-terminal) and Xfce terminal (package Terminal) use the same Name and Icon in their desktop files. So when using the System menu, you have to try (and remember) which one is the one you want. Additionally, once you start an XFCE terminal, GNOME Shell thinks that it's actually a GNOME terminal and gets the window ownership wrong: https://bugzilla.gnome.org/show_bug.cgi?id=656300 -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 - F16 upgrade
2011/9/18 Michał Piotrowski mkkp...@gmail.com: Just to let you know - I had to downgrade bind-libs-lite after the update, because my network was broken. There is a problem with loading lib that is required by dhclient. This happened to me as well. I think that it happened because I had been updating my F15 system from updates-testing by manually enabling the updates-testing repo from the yum command line. Since updates-testing wasn't enabled in the config file preupgrade didn't use the F16 updates-testing repo as a part of the upgrade process. bind was recently updated so my installed bind from F15 updates-testing was considered newer than the F16 bind. I also have an old kernel uname -a Linux ozzy.pl 2.6.40.4-5.fc15.x86_64 #1 SMP Tue Aug 30 14:38:32 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux This happened to me as well, but I'm not sure/don't remember why. -- Jeff Ollie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Sun, Sep 18, 2011 at 2:44 PM, Kevin Kofler kevin.kof...@chello.atwrote: Richard Hughes wrote: Naa, try the version of zif in F16, or grab the latest upstream SRPM and rebuild it for f15 from here: http://people.freedesktop.org/~hughsient/fedora/15/SRPMS/ I submitted a Koji scratch build of zif-0.2.4-0.78.20110918git for F15: http://koji.fedoraproject.org/koji/taskinfo?taskID=3359296 Hey, Kevin and Richard I've installed this zif from koji and I'm still not able to complete a zif install paprefs transaction with realworld F15 configured public repository set, whereas all the yum based tools: yum. repoquery etc... complete as expected. Here is what yum repolist returns repo id repo name status adobe-linux-i386 Adobe Systems Incorporated 18 fedora Fedora 15 - x86_64 24,085 google-musicmanager google-musicmanager 1 google-talkplugin google-talkplugin 1 openshift-express Openshift-express 1 rpmfusion-free RPM Fusion for Fedora 15 - Free 438 rpmfusion-free-updates RPM Fusion for Fedora 15 - Free - Updates 287 rpmfusion-nonfreeRPM Fusion for Fedora 15 - Nonfree 179 rpmfusion-nonfree-updatesRPM Fusion for Fedora 15 - Nonfree - Updates120 updates Fedora 15 - x86_64 - Updates 6,408 updates-testing Fedora 15 - x86_64 - Test Updates 1,239 Guys what's going on with zif? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
- Original Message - On Fri, Sep 16, 2011 at 03:01:06PM -0400, Doug Ledford wrote: On 9/15/2011 12:01 PM, Matthew Garrett wrote: On Thu, Sep 15, 2011 at 04:56:43PM +0100, Richard W.M. Jones wrote: The most obvious case where it can fail involves grub being effectively unmaintained, and so various vendors have extended it in different ways. You may end up with valid configuration files for one distribution that can't be parsed by the grub for another. The assumption you're making is fragile. It's even worse for grub2, since it has a built-in module loader. Modules built for one version of grub aren't guaranteed (or even really expected) to work when loaded into another. No it's not. Grub doesn't install the 1.5 stage or the 2nd stage loaders, it uses the ones present in the root filesystem defined by the install command. In this case, that's going to be the modules in the guest vm filesystem. As such, anything valid in the guest vm's copy of grub will work in the guest vm even if the grub used to install the master boot record comes from the host. grub-install *does* install the 1.5 and 2nd stage loaders. OK, technically it install the 1.5 or the 2.0 if you don't use a 1.5 (if you install both the 1.5 and 2.0, then it patches the name of the 2.0 into the 1.5 that it installs and the 1.5 reads the filesystem to find the 2.0 so that it isn't subject to breaking boot if the 2.0 moves due to an updated version or some such). However, it installs them from the files you list to the install command as I listed in my previous email. So, they are still compatible with the guest vm grub if you follow a procedure like I listed. I haven't looked to see if the 512 byte MBR is hard coded in grub or if it grabs it from /boot/grub and installs what it finds there, so I can't speak to that. Even if it didn't, I'm not convinced it's guaranteed that an arbitrary grub stage 1 can launch an arbitrary grub stage 1.5 since there are assumptions about register and stack state - see start.S. And I'm sure those assumptions haven't changed probably in the last 5 years or more. But, I can look through the old grub CVS versions if it would help settle your concerns. Those sorts of hard coded constants tend not to change much, especially if the coders have any sort of clue what so ever about compatibility issues. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
- Original Message - On Mon, Sep 19, 2011 at 10:51:26AM -0500, Matyas Selmeci wrote: Kevin Kofler wrote on Mon, Sep 19, 2011 at 01:02:26PM +0200: Michael Schroeder wrote: Sounds like you want weak dependencies (i.e. Suggests et al). In this case, I think disjunctive dependencies (default | virtual), as Matthew Garrett pointed out, are the right solution, not soft dependencies (though those would also be nice). Kevin Kofler Functionally speaking, what is the difference between a soft dependency and a disjunctive dependency? How can you satisfy a soft dependency if you don't know what virtual dependency it is being used to provide? If we have: Requires: phonon-backend Suggests: phonon-backend-gstreamer What would you expect the outcome to be on a system that has phonon-backend-xine? I'd have thought that phonon-backend-gstreamer would get installed, even if you can later remove it. That's not the desired outcome. I wouldn't have thought that. I would have thought that if the Requires was already satisfied by phonon-backend-xine, that processing would stop there. You have no need for suggests or recommends either one when the dependency is already satisfied IMO. But, I didn't write any spec around that, so it may be implemented differently in the real (deb) world. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fix of License tag in UpTools
I will fix the license of UpTools package, it was mistagged as BSD but is BSD with attribution. -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com LPIC-2 Certified - http://www.lpi.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpmlint complains about BSD with attribution
Hi, I'd want to notify that rmplint warns about BSD with attribution, I mean it hasn't the complete list of valid licenses of http://fedoraproject.org/wiki/Licensing#SoftwareLicenses. Thanks in advance! -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com LPIC-2 Certified - http://www.lpi.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 739461] Surprising value for --optimize in generated spec file
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=739461 --- Comment #1 from Steven Pritchard st...@silug.org 2011-09-19 13:02:40 EDT --- That is fixed in the current git tree, which I'll be releasing as an update soon. For now, see https://github.com/silug/cpanspec -- 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: how to have yum prefer one dependency over others
tim.laurid...@gmail.com wrote: trolling Why don't you just replace rpm, with deb too, while you are at it ? /trolling * Because dpkg is missing essential RPM features (e.g. file and soname dependencies). * Because replacing RPM essentially means creating a new distribution, whereas the depsolver can be easily replaced, and in fact you can even use multiple depsolvers on the same machine at the same time (well, you can't do the transactions simultaneously, obviously, but you can have both installed and use one or the other as you see fit). Sorry, couldn't resist feeding the troll. ;-) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
On Mon, Sep 19, 2011 at 12:44:58PM -0400, Doug Ledford wrote: OK, technically it install the 1.5 or the 2.0 if you don't use a 1.5 (if you install both the 1.5 and 2.0, then it patches the name of the 2.0 into the 1.5 that it installs and the 1.5 reads the filesystem to find the 2.0 so that it isn't subject to breaking boot if the 2.0 moves due to an updated version or some such). However, it installs them from the files you list to the install command as I listed in my previous email. So, they are still compatible with the guest vm grub if you follow a procedure like I listed. I haven't looked to see if the 512 byte MBR is hard coded in grub or if it grabs it from /boot/grub and installs what it finds there, so I can't speak to that. Sure. If you're installing the files from the guest then there's no problem. But in that case you only need enough code in the host to be able to write the new images, whereas what Richard's been telling us is that the host-side grub binaries are required. Even if it didn't, I'm not convinced it's guaranteed that an arbitrary grub stage 1 can launch an arbitrary grub stage 1.5 since there are assumptions about register and stack state - see start.S. And I'm sure those assumptions haven't changed probably in the last 5 years or more. But, I can look through the old grub CVS versions if it would help settle your concerns. Those sorts of hard coded constants tend not to change much, especially if the coders have any sort of clue what so ever about compatibility issues. Given that you're always supposed to install the stage 1.5/stage 2 along with the mbr, I don't see where compatibility issues come into it. If you're using the code as you're meant to use the code then you'll always be safe. If you're not, it's not guaranteed to be safe. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Mon, Sep 19, 2011 at 12:51:29PM -0400, Doug Ledford wrote: I wouldn't have thought that. I would have thought that if the Requires was already satisfied by phonon-backend-xine, that processing would stop there. You have no need for suggests or recommends either one when the dependency is already satisfied IMO. But, I didn't write any spec around that, so it may be implemented differently in the real (deb) world. It is. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to make systemd wait for a process to die?
On Mon, 19.09.11 13:25, Juan Orti Alcaine (j.orti.alca...@gmail.com) wrote: Hello, I'm making a systemd service file for gogoc, a program to create IPv6 tunnels with Freenet6.net The program gets the network configuration and uses a shell script for configuring the interface, and when receives the HUP signal, calls the shell script again for shutting down the tunnel, but it needs a few seconds for doing this. What's the better way for doing this? at the moment, I do: [Service] WorkingDirectory=/var/lib/gogoc Type=simple EnvironmentFile=-/etc/sysconfig/gogoc ExecStart=/usr/bin/gogoc -f /etc/gogoc/gogoc.conf $GOGOC_OPTS ExecStop=/bin/kill -s SIGHUP $MAINPID it sends the HUP, but then it kills the daemon immediately, there's no time for shutting down the tunnel properly. Is correct to put a sleep? It looks awful ExecStop=/bin/kill -s SIGHUP $MAINPID; sleep 5 What do you think? ExecStop is supposed to synchronously shut down a service. It's the same for SysV's stop verb. I must say I find it quite a poort choice of this software to use SIGHUP for termination. They should use SIGSTOP for that, as the generally accepted default meaning for SIGHUP for daemons is to reload configuration. Note that by default systemd sends SIGSTOP to all processes of a service and waits for a while to ensure the service shuts down. You can influence the signal sent via KillSignal=. See systemd.service(5) for more information. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to make systemd wait for a process to die?
On Mon, 19.09.11 14:25, Juan Orti Alcaine (j.orti.alca...@gmail.com) wrote: It works. I deleted the line KillMode because it has some child processes I want to shut down even if the script times out. I have increased the timeout to 30 secs because I noticed sometimes it takes a lot longer to close the tunnel. Is there any problem about this? Unless there's a really good reason to change TimeoutSec= I'd always recommend not setting it at all (which leaves it at the default of 90s). Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to make systemd wait for a process to die?
On Mon, 19.09.11 19:28, Lennart Poettering (mzerq...@0pointer.de) wrote: On Mon, 19.09.11 13:25, Juan Orti Alcaine (j.orti.alca...@gmail.com) wrote: Hello, I'm making a systemd service file for gogoc, a program to create IPv6 tunnels with Freenet6.net The program gets the network configuration and uses a shell script for configuring the interface, and when receives the HUP signal, calls the shell script again for shutting down the tunnel, but it needs a few seconds for doing this. What's the better way for doing this? at the moment, I do: [Service] WorkingDirectory=/var/lib/gogoc Type=simple EnvironmentFile=-/etc/sysconfig/gogoc ExecStart=/usr/bin/gogoc -f /etc/gogoc/gogoc.conf $GOGOC_OPTS ExecStop=/bin/kill -s SIGHUP $MAINPID it sends the HUP, but then it kills the daemon immediately, there's no time for shutting down the tunnel properly. Is correct to put a sleep? It looks awful ExecStop=/bin/kill -s SIGHUP $MAINPID; sleep 5 What do you think? ExecStop is supposed to synchronously shut down a service. It's the same for SysV's stop verb. I must say I find it quite a poort choice of this software to use SIGHUP for termination. They should use SIGSTOP for that, as the generally accepted default meaning for SIGHUP for daemons is to reload configuration. Note that by default systemd sends SIGSTOP to all processes of a service and waits for a while to ensure the service shuts down. You can influence the signal sent via KillSignal=. See systemd.service(5) for more information. Mehh, s/SIGSTOP/SIGTERM/. Sorry for the confusion. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On 19 September 2011 17:41, Jef Spaleta jspal...@gmail.com wrote: I've installed this zif from koji and I'm still not able to complete a zif install paprefs transaction with realworld F15 configured public repository set, whereas all the yum based tools: yum. repoquery etc... complete as expected. Guys what's going on with zif? Can you open a ticket on Red Hat bugzilla please, component zif and attach the output of zif install paprefs -v I've not tested zif on F15 in a lng time and it's probably just a trivial bug. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SysV to systemd conversion: please double-check the default and post-upgrade state of your services
On Sat, Sep 17, 2011 at 12:59:06AM -0700, Adam Williamson wrote: Hey, everyone. I'm starting to get a bit concerned about one aspect of the SysV to systemd conversion process. I've come across three separate bugs where the default and/or post-upgrade state of services was incorrect: in two cases, the service changed from being disabled by default in F15 to being enabled by default in F16, and in another case, a service went from being enabled by default in F15 to being disabled by default in F16. These changes were not intentional, simply mistaken. Obviously both of these can have major consequences (one of the above cases broke libvirt networking and certain aspects of NetworkManager, another prevented sealert from working by default), so I'd ask those who've migrated their package's services from sysv to systemd to please double-check their handling of this. It's pretty simple. This %post snippet enables a service by default: One other thing to note. If you've followed adam's instructions on constructing the spec file but the service still isn't starting when the systemctl enable command is run, you may also want to look inside the unit file (in most cases , *.service) to see what's happening there. The unit file needs to specify a systemd dependency on the multi-user target if you want the service to start in multi-user. -Toshio pgpW2XFEDNdFc.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Delinquent mirror process
On Mon, Sep 19, 2011 at 04:06:47PM +0100, Matthew Booth wrote: I've noticed that mirror.bytemark.co.uk hasn't been updated since 8th September: http://mirror.bytemark.co.uk/fedora/linux/updates/15/x86_64/repodata/ However, it's still being handed out by our mirror list. It seems to me they should be, at least temporarily, dropped as an official mirror. Is there a process for doing that? I just checked and I do not see it in the list any longer: https://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f15arch=x86_64country=gb Do you still get the mirror listed? It is not in database listed as up to date for f15 updates. Adrian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME and Xfce terminal entries not distinguishable in menus
On Mon, Sep 19, 2011 at 10:33:06AM -0600, Andrew McNabb wrote: Additionally, once you start an XFCE terminal, GNOME Shell thinks that it's actually a GNOME terminal and gets the window ownership wrong: https://bugzilla.gnome.org/show_bug.cgi?id=656300 And the other way around, when starting a GNOME terminal in Xfce, the GNOME terminal immdiately shrinks itself (you see it shrinking!) horizontally to a width of 28 characters. No idea why this happens, I'm happy with the Xfce terminal, so I don't need it... Maybe I should file a bug or can anyone see if this is still the case in F16? -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME and Xfce terminal entries not distinguishable in menus
On Mon, 19 Sep 2011 20:16:57 +0200 Jos Vos j...@xos.nl wrote: On Mon, Sep 19, 2011 at 10:33:06AM -0600, Andrew McNabb wrote: Additionally, once you start an XFCE terminal, GNOME Shell thinks that it's actually a GNOME terminal and gets the window ownership wrong: https://bugzilla.gnome.org/show_bug.cgi?id=656300 And the other way around, when starting a GNOME terminal in Xfce, the GNOME terminal immdiately shrinks itself (you see it shrinking!) horizontally to a width of 28 characters. No idea why this happens, I'm happy with the Xfce terminal, so I don't need it... Maybe I should file a bug or can anyone see if this is still the case in F16? https://bugzilla.redhat.com/show_bug.cgi?id=670173 kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 696725] RPM doesn't create /var/run/amavisd
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=696725 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #18 from Fedora Update System upda...@fedoraproject.org 2011-09-19 14:32:14 EDT --- Package amavisd-new-2.6.6-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing amavisd-new-2.6.6-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/amavisd-new-2.6.6-1.fc16 then log in and leave karma (feedback). -- 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 548234] Freshclam cannot notify clamd of database updates due to permission denied
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=548234 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #8 from Fedora Update System upda...@fedoraproject.org 2011-09-19 14:31:17 EDT --- Package amavisd-new-2.6.6-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing amavisd-new-2.6.6-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/amavisd-new-2.6.6-1.fc16 then log in and leave karma (feedback). -- 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 734271] Missing /etc/tmpfiles.d/amavisd.conf file
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=734271 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2011-09-19 14:32:07 EDT --- Package amavisd-new-2.6.6-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing amavisd-new-2.6.6-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/amavisd-new-2.6.6-1.fc16 then log in and leave karma (feedback). -- 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 676430] amavisd-new does not work with systemd
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=676430 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2011-09-19 14:31:43 EDT --- Package amavisd-new-2.6.6-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing amavisd-new-2.6.6-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/amavisd-new-2.6.6-1.fc16 then log in and leave karma (feedback). -- 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 710984] clamd.amavisd does not start without manual intervention
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=710984 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2011-09-19 14:31:57 EDT --- Package amavisd-new-2.6.6-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing amavisd-new-2.6.6-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/amavisd-new-2.6.6-1.fc16 then log in and leave karma (feedback). -- 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 656544] Please Update Spec File to use %ghost on files in /var/run and /var/lock
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=656544 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System upda...@fedoraproject.org 2011-09-19 14:31:27 EDT --- Package amavisd-new-2.6.6-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing amavisd-new-2.6.6-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/amavisd-new-2.6.6-1.fc16 then log in and leave karma (feedback). -- 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: rpmlint complains about BSD with attribution
SB == Sergio Belkin seb...@gmail.com writes: SB I'd want to notify that rmplint warns about BSD with SB attribution, Please file a bug against rpmlint. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
selinux versus chcon
I've reviewing my buildRPM spec file so that it works in newer distributions
(currently playing with RHEL 5.6), but my question is applicable to
Fedora xxx as well.
During the development of my package, I had encountered issues with my
build and install procedures during the slow migration/acceptance of SELinux.
In my %post part of my spec file I had added both chcon commands and
semanage commands and restorecon commands. As time goes by I've
forgotten why I used chcon versus semanage, and why I needed the
restorecon command at all. :-(
(Today's issue is setroubleshoot browser is recommending I use a chcon
command to add httpd_sys_content_t to /var/cache/fontconfig/*)
My spec file currently contains this:
%{_bindir}/chcon -t httpd_sys_script_exec_t
/var/www/html/nia/scripts/* 2/dev/null
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/nia/tmp'
2/dev/null
restorecon -v '/var/www/html/nia/tmp' 2/dev/null
From what I can remember:
1/ I added the 'chcon' so that my scripts are executable by apache.
2/ I used semanage to make my temp directory writable by my scripts
3/ I needed the 'restorecon' to 'make the semanage stuff 'sticky'.
From what I've been able to read:
chcon affects the filesystem, whereas
semanage affects 'policy' and
restorecon is used to 're-affect the filesystem according to policy'
(set by semanage (and others)).
Is this a valid interpretation?
If so... why use chcon versus the semanage/restorecon technique?
or if my assesement is wrong... can someone point me to a better
explanation/tutorial?
TIA
Fulko
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpmlint complains about BSD with attribution
2011/9/19 Jason L Tibbitts III ti...@math.uh.edu: SB == Sergio Belkin seb...@gmail.com writes: SB I'd want to notify that rmplint warns about BSD with SB attribution, Please file a bug against rpmlint. OK, I will do it:) - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com LPIC-2 Certified - http://www.lpi.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
- Original Message - On Mon, Sep 19, 2011 at 12:44:58PM -0400, Doug Ledford wrote: OK, technically it install the 1.5 or the 2.0 if you don't use a 1.5 (if you install both the 1.5 and 2.0, then it patches the name of the 2.0 into the 1.5 that it installs and the 1.5 reads the filesystem to find the 2.0 so that it isn't subject to breaking boot if the 2.0 moves due to an updated version or some such). However, it installs them from the files you list to the install command as I listed in my previous email. So, they are still compatible with the guest vm grub if you follow a procedure like I listed. I haven't looked to see if the 512 byte MBR is hard coded in grub or if it grabs it from /boot/grub and installs what it finds there, so I can't speak to that. Sure. If you're installing the files from the guest then there's no problem. But in that case you only need enough code in the host to be able to write the new images, whereas what Richard's been telling us is that the host-side grub binaries are required. The minimal code you need to do what I suggested is the grub binary itself. Shouldn't need grub-install or any of the other support files, but as the grub binary is in the base package, you need the grub package in addition to the grub2 package. Even if it didn't, I'm not convinced it's guaranteed that an arbitrary grub stage 1 can launch an arbitrary grub stage 1.5 since there are assumptions about register and stack state - see start.S. And I'm sure those assumptions haven't changed probably in the last 5 years or more. But, I can look through the old grub CVS versions if it would help settle your concerns. Those sorts of hard coded constants tend not to change much, especially if the coders have any sort of clue what so ever about compatibility issues. Given that you're always supposed to install the stage 1.5/stage 2 along with the mbr, This is incorrect. The whole reason the stage1.5 portion is an fs compatible reader is so that you can update the stage2 file and it will pick the changes up without needing to be reinstalled. This is also born out by the fact that on package update, there is no %post action in the spec to reinstall the mbr and stage 1.5 files even though the stage2 file likely just changed. I don't see where compatibility issues come into it. If you're using the code as you're meant to use the code then you'll always be safe. If you're not, it's not guaranteed to be safe. Like I said, not true. The grub package is designed to be updateable without requiring an mbr reinstall. What's more is I had a look at the stage1.[hS] files in the grub shipped in FC-1 and RHEL-5, and just like I said, they are indeed binary compatible. So even if the grub user space application pulls its MBR from a statically linked copy of the MBR, it will still work with pretty much any stage1.5 or stage2 you find in a guest. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Perl6-Junction] Created tag perl-Perl6-Junction-1.40000-4.el6
The lightweight tag 'perl-Perl6-Junction-1.4-4.el6' was created pointing to: e005e9f... Include Changes and README files -- 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: selinux versus chcon
Sorry for the top posting. No, chcon is not necessary in your example.
Perhaps the advice message is wrong, or it is something historical.
Hth
2011/9/19, Fulko Hew fulko@gmail.com:
I've reviewing my buildRPM spec file so that it works in newer distributions
(currently playing with RHEL 5.6), but my question is applicable to
Fedora xxx as well.
During the development of my package, I had encountered issues with my
build and install procedures during the slow migration/acceptance of
SELinux.
In my %post part of my spec file I had added both chcon commands and
semanage commands and restorecon commands. As time goes by I've
forgotten why I used chcon versus semanage, and why I needed the
restorecon command at all. :-(
(Today's issue is setroubleshoot browser is recommending I use a chcon
command to add httpd_sys_content_t to /var/cache/fontconfig/*)
My spec file currently contains this:
%{_bindir}/chcon -t httpd_sys_script_exec_t
/var/www/html/nia/scripts/* 2/dev/null
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/nia/tmp'
2/dev/null
restorecon -v '/var/www/html/nia/tmp' 2/dev/null
From what I can remember:
1/ I added the 'chcon' so that my scripts are executable by apache.
2/ I used semanage to make my temp directory writable by my scripts
3/ I needed the 'restorecon' to 'make the semanage stuff 'sticky'.
From what I've been able to read:
chcon affects the filesystem, whereas
semanage affects 'policy' and
restorecon is used to 're-affect the filesystem according to policy'
(set by semanage (and others)).
Is this a valid interpretation?
If so... why use chcon versus the semanage/restorecon technique?
or if my assesement is wrong... can someone point me to a better
explanation/tutorial?
TIA
Fulko
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Inviato dal mio dispositivo mobile
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
On Mon, Sep 19, 2011 at 02:53:11PM -0400, Doug Ledford wrote: This is incorrect. The whole reason the stage1.5 portion is an fs compatible reader is so that you can update the stage2 file and it will pick the changes up without needing to be reinstalled. This is also born out by the fact that on package update, there is no %post action in the spec to reinstall the mbr and stage 1.5 files even though the stage2 file likely just changed. We never update the stage 2 file without reinstalling the mbr and stage 1.5. The output of rpm -qf grub may be instructive. I don't see where compatibility issues come into it. If you're using the code as you're meant to use the code then you'll always be safe. If you're not, it's not guaranteed to be safe. Like I said, not true. The grub package is designed to be updateable without requiring an mbr reinstall. What's more is I had a look at the stage1.[hS] files in the grub shipped in FC-1 and RHEL-5, and just like I said, they are indeed binary compatible. So even if the grub user space application pulls its MBR from a statically linked copy of the MBR, it will still work with pretty much any stage1.5 or stage2 you find in a guest. The grub package (as provided in Fedora) is not designed for that. This would be a much easier discussion to have if you stopped describing things that are manifestly true as not true. And while it is the case that grub *is* binary compatible between every version we've ever released, it is *not* guaranteed that that remains true, or even that it's true between us and any distribution that may be installed in a guest. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
On Mon, Sep 19, 2011 at 10:53 AM, Doug Ledford dledf...@redhat.com wrote: Like I said, not true. The grub package is designed to be updateable without requiring an mbr reinstall. What's more is I had a look at the stage1.[hS] files in the grub shipped in FC-1 and RHEL-5, and just like I said, they are indeed binary compatible. So even if the grub user space application pulls its MBR from a statically linked copy of the MBR, it will still work with pretty much any stage1.5 or stage2 you find in a guest. Pretty much any? Hmm are you saying that random other linux distribution's grub binaries are garunteed(or promised/expected) to be binary compatible? Other distributors do have the ability to patch that 1.5 stage code in non-binary compatible ways don't they? We aren't talking strictly about the Fedora/RHEL ecosystem are we? Just because RHEL and Fedora have chosen not to include binary incompatible patches, doesn't mean its a truism across the guest OS landscape does it? Is that binary compatibility tested for as part of operation? Is that compatibility strictly a consequence of distribution level decision making concerning Fedora and RHEL? Is that binary compatibility guaranteed or promised from other distribution's grub1 variants being shipped? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
Matthew Garrett wrote: The output of rpm -qf grub may be instructive. I suppose you mean rpm -ql grub… Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
- Original Message - On Mon, Sep 19, 2011 at 10:53 AM, Doug Ledford dledf...@redhat.com wrote: Like I said, not true. The grub package is designed to be updateable without requiring an mbr reinstall. What's more is I had a look at the stage1.[hS] files in the grub shipped in FC-1 and RHEL-5, and just like I said, they are indeed binary compatible. So even if the grub user space application pulls its MBR from a statically linked copy of the MBR, it will still work with pretty much any stage1.5 or stage2 you find in a guest. Pretty much any? Hmm are you saying that random other linux distribution's grub binaries are garunteed(or promised/expected) to be binary compatible? Can I guarantee it, no. I didn't look at their stage1.[hS] files. However, as I said in my original comment about this, the stage1 loader is *dirt simple*. There is a very low chance that it will be incompatible simply due to the fact that almost nothing interesting happens there. There is a much greater chance in the stage1.5 files though. But, since the grub command line utility, when used as I directed, reads the stage1.5 and stage2 files from the filesystem and doesn't try to use its own internal version of those files, incompatibility at that layer isn't a problem. Other distributors do have the ability to patch that 1.5 stage code in non-binary compatible ways don't they? They do. But unless they have assembler code masochists, they likely don't. We aren't talking strictly about the Fedora/RHEL ecosystem are we? Just because RHEL and Fedora have chosen not to include binary incompatible patches, doesn't mean its a truism across the guest OS landscape does it? No, but again, the chances of a binary incompatible stage1 are very low. Is that binary compatibility tested for as part of operation? You would have to ask the grub maintainer about that. I just know that a grub update does not reinstall the stage1 or stage1.5 files, while the stage2 file is replaced in the filesystem, meaning that the previous stage1.5 file will attempt to use the new stage2 file in chain loading fashion. Whether or not that is ever tested or just assumed to work I can't speak to. Is that compatibility strictly a consequence of distribution level decision making concerning Fedora and RHEL? Between the stage1.5 and stage2, that could very well be. Between the stage1 and stage1.5, it's more a consequence of the fact that the stage1 loader has one very distinct job to perform, in a very small amount of instruction space, and you don't go around adding features to the stage1 loader, it simply doesn't have the room for it. Is that binary compatibility guaranteed or promised from other distribution's grub1 variants being shipped? No clue. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to make systemd wait for a process to die?
Yes, it's a poor choice for the daemon to use SIGHUP, I have found a lot of oddities with this program. A collateral effect of this is that the router advertisement daemon (radvd) is run as a child and meanwhile gogoc is closing the tunnel, radvd is reloading its configuration, and then dying with SIGKILL, because it never receives a SIGTERM, doesn't it? Anyway, now it works ok, and there is always the possibility of creating a shell script. Thank you and good work with systemd, it's fantastic! 2011/9/19 Lennart Poettering mzerq...@0pointer.de On Mon, 19.09.11 13:25, Juan Orti Alcaine (j.orti.alca...@gmail.com) wrote: Hello, I'm making a systemd service file for gogoc, a program to create IPv6 tunnels with Freenet6.net The program gets the network configuration and uses a shell script for configuring the interface, and when receives the HUP signal, calls the shell script again for shutting down the tunnel, but it needs a few seconds for doing this. What's the better way for doing this? at the moment, I do: [Service] WorkingDirectory=/var/lib/gogoc Type=simple EnvironmentFile=-/etc/sysconfig/gogoc ExecStart=/usr/bin/gogoc -f /etc/gogoc/gogoc.conf $GOGOC_OPTS ExecStop=/bin/kill -s SIGHUP $MAINPID it sends the HUP, but then it kills the daemon immediately, there's no time for shutting down the tunnel properly. Is correct to put a sleep? It looks awful ExecStop=/bin/kill -s SIGHUP $MAINPID; sleep 5 What do you think? ExecStop is supposed to synchronously shut down a service. It's the same for SysV's stop verb. I must say I find it quite a poort choice of this software to use SIGHUP for termination. They should use SIGSTOP for that, as the generally accepted default meaning for SIGHUP for daemons is to reload configuration. Note that by default systemd sends SIGSTOP to all processes of a service and waits for a while to ensure the service shuts down. You can influence the signal sent via KillSignal=. See systemd.service(5) for more information. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
- Original Message - Matthew Garrett wrote: The output of rpm -qf grub may be instructive. I suppose you mean rpm -ql grub… That worked better. And I see your point. I was mistaken in thinking that the grub files resided directly in /boot/grub. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: selinux versus chcon
On Mon, 2011-09-19 at 14:49 -0400, Fulko Hew wrote: If so... why use chcon versus the semanage/restorecon technique? or if my assesement is wrong... can someone point me to a better explanation/tutorial? chcon is almost never the right way to go. It changes the file on the FS, but it is likely to get changed back the next time a file is installed in that location. semanage fcontext -a will tell the userspace policy what the right label for the file should be. restorecon then queries the 'right' label from the policy and does the same underlying thing chcon does to set that label. So semanage+restorecon == will last, chcon == will likely get blown away and make you angry later. -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
- Original Message - On Mon, Sep 19, 2011 at 02:53:11PM -0400, Doug Ledford wrote: This is incorrect. The whole reason the stage1.5 portion is an fs compatible reader is so that you can update the stage2 file and it will pick the changes up without needing to be reinstalled. This is also born out by the fact that on package update, there is no %post action in the spec to reinstall the mbr and stage 1.5 files even though the stage2 file likely just changed. We never update the stage 2 file without reinstalling the mbr and stage 1.5. The output of rpm -qf grub may be instructive. Which has it's own gotchas. I never use grub-install as it does the wrong things in certain circumstances. I always manually run grub then do the install command myself. In my case, after a grub update, I'm going to end up with a newer MBR but older stage1.5 and stage2 files because I didn't know I needed to copy them from /usr/share after an rpm upgrade. I don't see where compatibility issues come into it. If you're using the code as you're meant to use the code then you'll always be safe. If you're not, it's not guaranteed to be safe. Like I said, not true. The grub package is designed to be updateable without requiring an mbr reinstall. What's more is I had a look at the stage1.[hS] files in the grub shipped in FC-1 and RHEL-5, and just like I said, they are indeed binary compatible. So even if the grub user space application pulls its MBR from a statically linked copy of the MBR, it will still work with pretty much any stage1.5 or stage2 you find in a guest. The grub package (as provided in Fedora) is not designed for that. This would be a much easier discussion to have if you stopped describing things that are manifestly true as not true. And while it is the case that grub *is* binary compatible between every version we've ever released, it is *not* guaranteed that that remains true, or even that it's true between us and any distribution that may be installed in a guest. I never said it was guaranteed, just that it was highly likely. And for the stage1 loader, I stand by that. For the stage1.5 and stage2 loaders, they are installed as a pair by the grub install command I sent out in this thread and so incompatibilities between them are taken care of. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME and Xfce terminal entries not distinguishable in menus
Am Montag, den 19.09.2011, 12:30 -0600 schrieb Kevin Fenzi: On Mon, 19 Sep 2011 20:16:57 +0200 Jos Vos j...@xos.nl wrote: And the other way around, when starting a GNOME terminal in Xfce, the GNOME terminal immdiately shrinks itself (you see it shrinking!) horizontally to a width of 28 characters. No idea why this happens, I'm happy with the Xfce terminal, so I don't need it... Maybe I should file a bug or can anyone see if this is still the case in F16? https://bugzilla.redhat.com/show_bug.cgi?id=670173 I have taken it over and fixed it. For reference: http://bugzilla.gnome.org/show_bug.cgi?id=649680 http://bugzilla.xfce.org/show_bug.cgi?id=7445 Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Mon, Sep 19, 2011 at 9:33 AM, Richard Hughes hughsi...@gmail.com wrote: Can you open a ticket on Red Hat bugzilla please, component zif and attach the output of zif install paprefs -v I've not tested zif on F15 in a lng time and it's probably just a trivial bug. Thanks. Filed : Bug 739701 https://bugzilla.redhat.com/show_bug.cgi?id=739701 -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[pkgdb] perl-WWW-Curl ownership changed
Package perl-WWW-Curl in Fedora devel was orphaned by eponyme To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-WWW-Curl -- 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: selinux versus chcon
On Mon, Sep 19, 2011 at 3:32 PM, Eric Paris epa...@redhat.com wrote: On Mon, 2011-09-19 at 14:49 -0400, Fulko Hew wrote: If so... why use chcon versus the semanage/restorecon technique? or if my assesement is wrong... can someone point me to a better explanation/tutorial? ... snip ... So semanage+restorecon == will last, chcon == will likely get blown away and make you angry later. Thanks for confirming that for me. Now my next issue is 'apparently' unknown contexts. My original RPM spec file added the 'httpd_sys_rw_content_t' context to a directory. Which was great for the versions of Fedora I was testing on, but now in RHEL 5.6 semanage complains with: type 'httpd_sys_rw_content_t' not defined. So it seems that my %post section of my RPM file has to either 'know' what distribution or version of selinux support is installed so I can avoid attempting to use types that are not defined, or having some way of finding out what 'types' are available 'in this OS' so that I issue the 'appropriate commands'. How can I find out what 'types' are available'? Fulko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphnaing some of my packages
Hi, Due to a lack of time, and to focus on the pacakges I use, I'm orphaning some of my packages : gestikk https://admin.fedoraproject.org/pkgdb/acls/name/gestikk?_csrf_token=407467ba7d127d6459b785cab7ed113a5011e8f0 -- Use mouse gestures to control your PC (one bug : https://bugzilla.redhat.com/show_bug.cgi?id=694969) immix https://admin.fedoraproject.org/pkgdb/acls/name/immix?_csrf_token=407467ba7d127d6459b785cab7ed113a5011e8f0 -- An image mixer (no bug) itaka https://admin.fedoraproject.org/pkgdb/acls/name/itaka?_csrf_token=407467ba7d127d6459b785cab7ed113a5011e8f0 -- On-demand screen capture server (no bug) perl-WWW-Curl https://admin.fedoraproject.org/pkgdb/acls/name/perl-WWW-Curl?_csrf_token=407467ba7d127d6459b785cab7ed113a5011e8f0 -- Perl extension interface for libcurl (no bug) vbindiff https://admin.fedoraproject.org/pkgdb/acls/name/vbindiff?_csrf_token=407467ba7d127d6459b785cab7ed113a5011e8f0 -- Visual binary diff (no bug) xcftools https://admin.fedoraproject.org/pkgdb/acls/name/xcftools?_csrf_token=407467ba7d127d6459b785cab7ed113a5011e8f0 -- Command-line tools for extracting information from XCF files (no bug) I've also deprecated 2 packages : abby : Front-end for cclive and clive : this project has been replaced by nomnom (available since F15), from the same author trustyRC : Fully modular IRC robot : dead project (I'm upstream) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to make systemd wait for a process to die?
On Mon, 19.09.11 21:26, Juan Orti Alcaine (j.orti.alca...@gmail.com) wrote: Yes, it's a poor choice for the daemon to use SIGHUP, I have found a lot of oddities with this program. A collateral effect of this is that the router advertisement daemon (radvd) is run as a child and meanwhile gogoc is closing the tunnel, radvd is reloading its configuration, and then dying with SIGKILL, because it never receives a SIGTERM, doesn't it? This sounds to me as if you need to set KillMode=process. The default KillMode is control-group which means all processes in the cgroup get a SIGHUP if you use this in conjunction with KillSignal=SIGHUP. However, if you want to make sure that only the parent PID gets the SIGHUP (which is then responsible to kill the child, too), then use KillMode=process. Thank you and good work with systemd, it's fantastic! Thanks! Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: selinux versus chcon
On Mon, Sep 19, 2011 at 4:38 PM, Ken Dreyer ktdre...@ktdreyer.com wrote:
On Mon, Sep 19, 2011 at 12:49 PM, Fulko Hew fulko@gmail.com wrote:
%{_bindir}/chcon -t httpd_sys_script_exec_t
/var/www/html/nia/scripts/* 2/dev/null
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/nia/tmp'
2/dev/null
restorecon -v '/var/www/html/nia/tmp' 2/dev/null
As an aside, it is a good idea to avoid placing packaged files into
/var/www. You can check out the packaging guidelines at
https://fedoraproject.org/wiki/Packaging:Guidelines#Web_Applications
First, my excuse is... this project is 12+ years old... long before that
standard/document was ever written,
Second, thanks for pointing it out. I'll consider changing it in a future rev.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Zif backport repository for F15 available for testing
Hi,
I have put up a repository with an updated zif snapshot for Fedora 15 at:
http://repos.fedorapeople.org/repos/kkofler/zif-backport/fedora-zif-backport.repo
The repository also includes a rebuild of PackageKit to deal with the bumped
zif soname. This should only affect PackageKit-zif, but all subpackages
including the main package are rebuilt, and provided because of the strict
%{version}-%{release} dependencies.
WARNING: This is a backport repository for testing purposes. Zif in Fedora
15 should be considered a technology preview. This repository
updates it to a newer version, which is a major improvement over
what's currently in Fedora 15, but should still be considered a
technology preview. It needs all the testing it can get, which is
the purpose of this repository.
Please note that the zif package itself contains only the library, you
will want one or more of the following packages, which all require zif:
* PackageKit-zif: Probably the most interesting one. Adds support for zif to
PackageKit (and thus gnome-packagekit and KPackageKit). Please read the
notes at https://github.com/hughsie/zif/blob/master/README.PackageKit for
how to enable it (or just remove PackageKit-yum if you're really brave ;-) ).
* zif-tools: This contains the command-line zif utility, useful for
debugging. It can also be used as a replacement for the yum command line,
though that's not really what it is designed for. (In particular, do NOT
expect support for all those fancy yum plugins, nor for the yum history.)
But if you're a command-line junkie who wants something faster than yum to
play with, you might end up liking it anyway. ;-)
* zif-devel, if you're a developer and want to use zif in your own code.
Otherwise you'll have little to no use for this particular subpackage. ;-)
Any issues with the repository itself should be reported to me, any issues
encountered with the actual software should be reported to Richard Hughes
(by filing a bug against zif at bugzilla.redhat.com).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 739461] New: Surprising value for --optimize in generated spec file
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Surprising value for --optimize in generated spec file
https://bugzilla.redhat.com/show_bug.cgi?id=739461
Summary: Surprising value for --optimize in generated spec file
Product: Fedora
Version: 16
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: unspecified
Priority: unspecified
Component: cpanspec
AssignedTo: st...@silug.org
ReportedBy: boche...@fedoraproject.org
QAContact: extras...@fedoraproject.org
CC: st...@silug.org, fedora-perl-devel-l...@redhat.com
Classification: Fedora
Story Points: ---
Type: ---
Description of problem:
As described in https://bugzilla.redhat.com/show_bug.cgi?id=738525#c2, here is
what I get when I run:
$ cpanspec ExtUtils::H2PM
[... snip ...]
%{__perl} Build.PL installdirs=vendor optimize=$RPM_OPT_FLAGS
[... snip ...]
$ cpanspec -m ExtUtils::H2PM
[... snip ...]
%{__perl} Build.PL installdirs=vendor optimize=%{optimize}
[... snip ...]
However:
$ rpm --eval %{optimize}
%{optimize}
So why is cpanspec writing %{optimize} in the generated spec file? Shouldn't it
use %{optflags} instead?
Version-Release number of selected component (if applicable):
cpanspec-1.78-9.fc16.noarch
How reproducible:
Always.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File CGI-Emulate-PSGI-0.13.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-CGI-Emulate-PSGI: 94ee97caa18d66d30d9f8467038c6a01 CGI-Emulate-PSGI-0.13.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CGI-Emulate-PSGI] Upstream update.
commit 6fed80eb3326857dfef0b56a82babcafef7061c5
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Mon Sep 19 10:10:05 2011 +0200
Upstream update.
.gitignore |1 +
perl-CGI-Emulate-PSGI.spec |8 ++--
sources|2 +-
3 files changed, 8 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 715f7b3..bd37462 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/CGI-Emulate-PSGI-0.12.tar.gz
+/CGI-Emulate-PSGI-0.13.tar.gz
diff --git a/perl-CGI-Emulate-PSGI.spec b/perl-CGI-Emulate-PSGI.spec
index bb5000f..03b702c 100644
--- a/perl-CGI-Emulate-PSGI.spec
+++ b/perl-CGI-Emulate-PSGI.spec
@@ -1,6 +1,6 @@
Name: perl-CGI-Emulate-PSGI
-Version:0.12
-Release:2%{?dist}
+Version:0.13
+Release:1%{?dist}
Summary:PSGI adapter for CGI applications
License:GPL+ or Artistic
Group: Development/Libraries
@@ -12,6 +12,7 @@ BuildRequires: perl(CGI)
BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
BuildRequires: perl(HTTP::Response)
BuildRequires: perl(Test::Builder::Module)
+BuildRequires: perl(Plack::Test)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%{?perl_default_filter}
@@ -45,6 +46,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Sep 19 2011 Ralf Corsépius corse...@fedoraproject.org 0.13-1
+- Upstream update.
+
* Tue Jun 21 2011 Marcela Mašláňová mmasl...@redhat.com - 0.12-2
- Perl mass rebuild
diff --git a/sources b/sources
index d1d43b9..e000e65 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f1c950b8e45c4d72f6544e934179d784 CGI-Emulate-PSGI-0.12.tar.gz
+94ee97caa18d66d30d9f8467038c6a01 CGI-Emulate-PSGI-0.13.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Number-Compare-0.02.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-Number-Compare: e77d5218a236184064c2866f334f9702 Number-Compare-0.02.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Number-Compare] Upstream update. Spec file cleanup.
commit 6e772fe6b99bc4c1187a4ab19defdffa2c87c3a4
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Mon Sep 19 10:25:45 2011 +0200
Upstream update.
Spec file cleanup.
.gitignore |1 +
Number-Compare-0.01-uninitialized.patch | 11 ---
perl-Number-Compare.spec| 21 +++--
sources |2 +-
4 files changed, 9 insertions(+), 26 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 5bcf3cc..df2ef9e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Number-Compare-0.01.tar.gz
+/Number-Compare-0.02.tar.gz
diff --git a/perl-Number-Compare.spec b/perl-Number-Compare.spec
index e053b44..5605b4f 100644
--- a/perl-Number-Compare.spec
+++ b/perl-Number-Compare.spec
@@ -1,15 +1,11 @@
Name: perl-Number-Compare
-Version: 0.01
-Release: 16%{?dist}
+Version: 0.02
+Release: 1%{?dist}
Summary: Perl module for numeric comparisons
License: GPL+ or Artistic
Group: Development/Libraries
URL: http://search.cpan.org/dist/Number-Compare/
-Source0:
http://www.cpan.org/modules/by-module/Number/Number-Compare-%{version}.tar.gz
-# Address https://bugzilla.redhat.com/show_bug.cgi?id=607982
-# Patch from https://rt.cpan.org/Public/Bug/Display.html?id=58466
-Patch0:
https://rt.cpan.org/Ticket/Attachment/792151/410599/Number-Compare-0.01-uninitialized.patch
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Source0:
http://www.cpan.org/authors/id/R/RC/RCLAMP/Number-Compare-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
@@ -22,7 +18,6 @@ which you can call with a value to be tested again.
%prep
%setup -q -n Number-Compare-%{version}
-%patch0 -p1
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -30,17 +25,11 @@ make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2/dev/null ';'
chmod -R u+w $RPM_BUILD_ROOT/*
-
-%clean
-rm -rf $RPM_BUILD_ROOT
-
-
%check
make test
@@ -51,6 +40,10 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Sep 19 2011 Ralf Corsépius corse...@fedoraproject.org - 0.02-1
+- Upstream update.
+- Spec file cleanup.
+
* Tue Dec 21 2010 Marcela Maslanova mmasl...@redhat.com - 0.01-16
- 661697 rebuild for fixing problems with vendorach/lib
diff --git a/sources b/sources
index 6ce86d7..ca13d78 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-519a4434e35033e9bd034d27cd2fd299 Number-Compare-0.01.tar.gz
+e77d5218a236184064c2866f334f9702 Number-Compare-0.02.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CGI-Emulate-PSGI/f16] Upstream update.
Summary of changes: 6fed80e... 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
[pkgdb] perl-Text-CSV_XS ownership changed
Package perl-Text-CSV_XS in Fedora EPEL 6 is now owned by pghmcfc To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Text-CSV_XS -- 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
[pkgdb] perl-Text-CSV_XS ownership changed
Package perl-Text-CSV_XS in Fedora EPEL 5 is now owned by pghmcfc To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Text-CSV_XS -- 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
[pkgdb] perl-Text-CSV_XS ownership changed
Package perl-Text-CSV_XS in Fedora EPEL 4 is now owned by pghmcfc To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Text-CSV_XS -- 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 739373] perl-XML-LibXSLT-1.71 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=739373 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com AssignedTo|mmasl...@redhat.com |psab...@redhat.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Number-Compare/f16] Upstream update. Spec file cleanup.
Summary of changes: 6e772fe... Upstream update. Spec file cleanup. (*) (*) 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-CGI-Emulate-PSGI/f15] (2 commits) ...Upstream update.
Summary of changes: 5f0f90e... Perl mass rebuild (*) 6fed80e... 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
[perl-CGI-Emulate-PSGI/f15] Merge cleanup.
commit c9b1469cc6db29e91127a38b5e9839888bbf1197 Author: Ralf Corsépius corse...@fedoraproject.org Date: Mon Sep 19 10:42:34 2011 +0200 Merge cleanup. perl-CGI-Emulate-PSGI.spec |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) --- diff --git a/perl-CGI-Emulate-PSGI.spec b/perl-CGI-Emulate-PSGI.spec index 03b702c..d040ae4 100644 --- a/perl-CGI-Emulate-PSGI.spec +++ b/perl-CGI-Emulate-PSGI.spec @@ -49,9 +49,6 @@ make test * Mon Sep 19 2011 Ralf Corsépius corse...@fedoraproject.org 0.13-1 - Upstream update. -* Tue Jun 21 2011 Marcela Mašláňová mmasl...@redhat.com - 0.12-2 -- Perl mass rebuild - * Mon Jun 20 2011 Ralf Corsépius corse...@fedoraproject.org 0.12-1 - Upstream update. - Remove BuildRoot. -- 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-Number-Compare/f15] Upstream update. Spec file cleanup.
Summary of changes: 6e772fe... Upstream update. Spec file cleanup. (*) (*) 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-CGI-Emulate-PSGI/f14] (4 commits) ...Merge remote-tracking branch 'origin/f15' into f14
Summary of changes: 5f0f90e... Perl mass rebuild (*) 6fed80e... Upstream update. (*) c9b1469... Merge cleanup. (*) a20dfd2... Merge remote-tracking branch 'origin/f15' into f14 (*) 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-CGI-Emulate-PSGI/f14: 4/4] Merge remote-tracking branch 'origin/f15' into f14
commit a20dfd29e03b9c99a9beb4accf8b553c2e3eebe5 Merge: b7fe1dd c9b1469 Author: Ralf Corsépius corse...@fedoraproject.org Date: Mon Sep 19 11:00:14 2011 +0200 Merge remote-tracking branch 'origin/f15' into f14 .gitignore |1 + perl-CGI-Emulate-PSGI.spec |6 +- sources|2 +- 3 files changed, 7 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
File HTML-Selector-XPath-0.08.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-HTML-Selector-XPath: c711f2672044cee9f6eba917e15eb263 HTML-Selector-XPath-0.08.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTML-Selector-XPath] Upstream update.
commit 3040023cc46ab91399b5d6f752019ddbc411b8c1
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Mon Sep 19 11:09:58 2011 +0200
Upstream update.
.gitignore|4 +---
perl-HTML-Selector-XPath.spec | 13 +
sources |2 +-
3 files changed, 7 insertions(+), 12 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index bf2ad3b..289630a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1 @@
-/HTML-Selector-XPath-0.04.tar.gz
-/HTML-Selector-XPath-0.06.tar.gz
-/HTML-Selector-XPath-0.07.tar.gz
+/HTML-Selector-XPath-0.08.tar.gz
diff --git a/perl-HTML-Selector-XPath.spec b/perl-HTML-Selector-XPath.spec
index 5fc3e50..dfb1592 100644
--- a/perl-HTML-Selector-XPath.spec
+++ b/perl-HTML-Selector-XPath.spec
@@ -1,12 +1,11 @@
Name: perl-HTML-Selector-XPath
-Version:0.07
-Release:2%{?dist}
+Version:0.08
+Release:1%{?dist}
Summary:CSS Selector to XPath compiler
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/HTML-Selector-XPath/
Source0:
http://www.cpan.org/authors/id/M/MI/MIYAGAWA/HTML-Selector-XPath-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl = 1:5.8.1
BuildRequires: perl(ExtUtils::MakeMaker)
@@ -31,8 +30,6 @@ equivalent XPath expression.
make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
-
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
@@ -43,9 +40,6 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%check
make test
-%clean
-rm -rf $RPM_BUILD_ROOT
-
%files
%defattr(-,root,root,-)
%doc Changes README
@@ -53,6 +47,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Mon Sep 19 2011 Ralf Corsépius corse...@fedoraproject.org 0.08-1
+- Upstream update.
+
* Wed Jun 29 2011 Marcela Mašláňová mmasl...@redhat.com - 0.07-2
- Perl mass rebuild
diff --git a/sources b/sources
index 7c9cc98..f8cada4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c3e22c0cdcaec1031f0c60ec8650134d HTML-Selector-XPath-0.07.tar.gz
+c711f2672044cee9f6eba917e15eb263 HTML-Selector-XPath-0.08.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTML-Selector-XPath/f16] Upstream update.
Summary of changes: 3040023... 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
[perl-HTML-Selector-XPath/f15] (3 commits) ...Merge cleanup.
Summary of changes: 37d49bc... Perl mass rebuild (*) 3040023... Upstream update. (*) d803780... Merge cleanup. (*) 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-Selector-XPath/f15: 3/3] Merge cleanup.
commit d803780e7caa0a0a1523d1bdbc74e12354a521e0 Author: Ralf Corsépius corse...@fedoraproject.org Date: Mon Sep 19 11:37:53 2011 +0200 Merge cleanup. perl-HTML-Selector-XPath.spec |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) --- diff --git a/perl-HTML-Selector-XPath.spec b/perl-HTML-Selector-XPath.spec index dfb1592..46a200d 100644 --- a/perl-HTML-Selector-XPath.spec +++ b/perl-HTML-Selector-XPath.spec @@ -50,9 +50,6 @@ make test * Mon Sep 19 2011 Ralf Corsépius corse...@fedoraproject.org 0.08-1 - Upstream update. -* Wed Jun 29 2011 Marcela Mašláňová mmasl...@redhat.com - 0.07-2 -- Perl mass rebuild - * Sun Mar 27 2011 Ralf Corsépius corse...@fedoraproject.org 0.07-1 - Upstream update. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File XML-LibXSLT-1.71.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-XML-LibXSLT: 6a2fc4a3b2d7f0cc02b6cbd0cac7ee7b XML-LibXSLT-1.71.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Perl-Critic-Pulp-65.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Perl-Critic-Pulp: 8462c043e0b5eb30b8a888f130545dbc Perl-Critic-Pulp-65.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Perl-Critic-Pulp] 65 bump
commit e7cc75b1296d805a9b85bd8d35d65b6599f1affb
Author: Petr Písař ppi...@redhat.com
Date: Mon Sep 19 11:43:03 2011 +0200
65 bump
.gitignore |1 +
perl-Perl-Critic-Pulp.spec |5 -
sources|2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index b8904be..33f76ec 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,3 +10,4 @@
/Perl-Critic-Pulp-61.tar.gz
/Perl-Critic-Pulp-62.tar.gz
/Perl-Critic-Pulp-64.tar.gz
+/Perl-Critic-Pulp-65.tar.gz
diff --git a/perl-Perl-Critic-Pulp.spec b/perl-Perl-Critic-Pulp.spec
index 624d2fb..3bd3d83 100644
--- a/perl-Perl-Critic-Pulp.spec
+++ b/perl-Perl-Critic-Pulp.spec
@@ -1,5 +1,5 @@
Name: perl-Perl-Critic-Pulp
-Version:64
+Version:65
Release:1%{?dist}
Summary:Some add-on perlcritic policies
License:GPLv3+
@@ -93,6 +93,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Sep 19 2011 Petr Pisar ppi...@redhat.com - 65-1
+- 65 bump
+
* Mon Aug 22 2011 Petr Pisar ppi...@redhat.com - 64-1
- 64 bump
diff --git a/sources b/sources
index 428e1b4..6c44a55 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-71edfb82d31614752295d1e5f4784267 Perl-Critic-Pulp-64.tar.gz
+8462c043e0b5eb30b8a888f130545dbc Perl-Critic-Pulp-65.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-XML-LibXSLT] 1.71 bump
commit 931c067bde8d918cd608458d928ff72459882b9b
Author: Petr Sabata con...@redhat.com
Date: Mon Sep 19 11:42:28 2011 +0200
1.71 bump
.gitignore|1 +
perl-XML-LibXSLT.spec | 32 +++-
sources |2 +-
3 files changed, 17 insertions(+), 18 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 5d4c794..25bfc63 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
XML-LibXSLT-1.70.tar.gz
+/XML-LibXSLT-1.71.tar.gz
diff --git a/perl-XML-LibXSLT.spec b/perl-XML-LibXSLT.spec
index 48eb590..9bd58b9 100644
--- a/perl-XML-LibXSLT.spec
+++ b/perl-XML-LibXSLT.spec
@@ -1,28 +1,21 @@
-%{!?perl_vendorarch: %define perl_vendorarch %(eval `%{__perl}
-V:installvendorarch`; echo $installvendorarch)}
-
Name: perl-XML-LibXSLT
-
# NOTE: also update perl-XML-LibXML to a compatible version. See below why.
-Version: 1.70
-Release: 8%{?dist}
-
+Version: 1.71
+Release: 1%{?dist}
Summary: Perl module for interfacing to GNOME's libxslt
-
Group: Development/Libraries
License: GPL+ or Artistic
URL: http://search.cpan.org/dist/XML-LibXSLT/
Source0:
http://search.cpan.org/CPAN/authors/id/P/PA/PAJAS/XML-LibXSLT-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: libxslt-devel = 1.1.18, gdbm-devel, libgcrypt-devel,
libgpg-error-devel
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-
# the package shares code with perl-XML-LibXML, we have to require a
compatible version
# see https://bugzilla.redhat.com/show_bug.cgi?id=469480
# for testing is needed the same version of XML::LibXML
# BUT XML::LibXML has new bugfix releases, but XML::LibXSLT not
-BuildRequires: perl(XML::LibXML) = 1.70
-Requires: perl(XML::LibXML) = 1.70
+BuildRequires: perl(XML::LibXML) = %{version}
+Requires: perl(XML::LibXML) = %{version}
%description
This module is a fast XSLT library, based on the Gnome libxslt engine
@@ -34,15 +27,15 @@ that you can find at http://www.xmlsoft.org/XSLT/
%setup -q -n XML-LibXSLT-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
+%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=%{optflags}
make %{?_smp_mflags}
%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 f -name '*.bs' -a -size 0 -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2/dev/null ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
+make pure_install PERL_INSTALL_ROOT=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'
+find %{buildroot} -type d -depth -exec rmdir {} 2/dev/null ';'
+chmod -R u+w %{buildroot}/*
%check
make test
@@ -55,6 +48,11 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Mon Sep 19 2011 Petr Sabata con...@redhat.com - 1.71-1
+- 1.71 bump
+- Remove BuildRoot tag
+- Remove useless vendorarch macro definition
+
* Wed Jul 20 2011 Petr Sabata con...@redhat.com - 1.70-8
- Perl mass rebuild
diff --git a/sources b/sources
index 7abef0b..97941c8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c63a7913999de076e5c911810f69b392 XML-LibXSLT-1.70.tar.gz
+6a2fc4a3b2d7f0cc02b6cbd0cac7ee7b XML-LibXSLT-1.71.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 739373] perl-XML-LibXSLT-1.71 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=739373 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-XML-LibXSLT-1.71-1.fc1 ||7 Resolution||RAWHIDE Last Closed||2011-09-19 05:47:13 -- 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 739293] perl-Perl-Critic-Pulp-65 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=739293 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||RAWHIDE Fixed In Version||perl-Perl-Critic-Pulp-65-1. ||fc17 Last Closed||2011-09-19 05:52:09 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Number-Compare/f14] (2 commits) ...Upstream update. Spec file cleanup.
Summary of changes: 772d3c8... - 661697 rebuild for fixing problems with vendorach/lib (*) 6e772fe... Upstream update. Spec file cleanup. (*) (*) 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
