Re: Lack of space on /
On Wed, Jul 13, 2011 at 11:28 AM, Adam Williamson awill...@redhat.comwrote: On Wed, 2011-07-13 at 11:08 +1000, Chris Jones wrote: Some of us do watch movies also, which of course requires an X session. Not really. mplayer has several outputs which function without an X session - less usefully, aalib; more usefully, directfb. I dunno if they work in modern Fedora, though. might be an interesting weekend poke. -- Adam Williamson In theory, probably possible yes. Whether it's very usable and workable in the real world is another matter altogether. Feel free to give it a shot. But personally, I've got better things to do. Cheers Chris -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages in F-16
On Tue, Jul 12, 2011 at 03:28:59PM -0400, Bill Nottingham wrote: Orphan perl-Danga-Socket Orphan perl-Sys-Syscall I've taken those two in Fedora; EPEL is still available. -- # Petr Sabata pgpBHMFr09km4.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages in F-16
On Tue, 2011-07-12 at 15:28 -0400, Bill Nottingham wrote: Orphan python-igraph I'll take this one, looks like something I could play with. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fwd: rpm packaging: package configuration
Hi, I am a newby regarding rpm packaging (more used to deb packaging). I want to know if there is a way to configure a package at install using rpmdev stuff, like debconf in Debian. Or do we need to create our own config script management? Thanks Olivier -- Olivier Sallou IRISA / University of Rennes 1 Campus de Beaulieu, 35000 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (pgp.mit.edu) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: rpm packaging: package configuration
On 07/13/2011 01:10 PM, Olivier Sallou wrote: Hi, I am a newby regarding rpm packaging (more used to deb packaging). I want to know if there is a way to configure a package at install using rpmdev stuff, like debconf in Debian. Or do we need to create our own config script management? If you provide more details on what exactly you are trying to do, more specific suggestions could be given Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v2] Retiring packages in F-16
On Tue, Jul 12, 2011 at 05:10:01PM -0400, Bill Nottingham wrote: Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 16. New this go-round is that we are also blocking packages that have failed to build since before Fedora 14. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. Orphan libwps taken D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages in F-16
On Tue, Jul 12, 2011 at 04:22:05PM -0400, Bill Nottingham wrote: Bruno Wolff III (br...@wolff.to) said: Orphan: gdk-pixbuf freetennis requires gdk-pixbuf-devel = 1:0.22.0-38.fc12 I'll take this one to keep freetennis, which seems to be a fairly highly rated game. gdk-pixbuf is FTBFS, but I think I can get it building before alpha. This looks like a rather bogus dep, IMO - gdk-pixbuf is for GTK1 apps, and freetennis is gtk2. freetennis is also very dead upstream (no updates since ~2005). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: rpm packaging: package configuration
I create a new package. At install, we need to ask for some quesitons to the user to preconfigure the application. At upgrade, it would be nice to get already answered questions rather than ask again for configuration. This can be managed manually, but it would be nicer to get this managed with packaging tools. Olivier Le 7/13/11 10:09 AM, Rahul Sundaram a écrit : On 07/13/2011 01:10 PM, Olivier Sallou wrote: Hi, I am a newby regarding rpm packaging (more used to deb packaging). I want to know if there is a way to configure a package at install using rpmdev stuff, like debconf in Debian. Or do we need to create our own config script management? If you provide more details on what exactly you are trying to do, more specific suggestions could be given Rahul -- Olivier Sallou IRISA / University of Rennes 1 Campus de Beaulieu, 35000 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (pgp.mit.edu) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages in F-16
On 2011-07-12, Bill Nottingham nott...@redhat.com wrote: Orphan perl-Gearman Orphan perl-Gearman-Client-Async Orphan perl-Gearman-Server Orphan perl-MogileFS-Client Orphan perl-MogileFS-Utils Orphan perl-Perlbal-XS-HTTPHeaders Orphan perl-mogilefs-server Orphan root-tail Fedora branches overtaken. EPEL still for free. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
R: Fwd: rpm packaging: package configuration
Sorry for not quoting. On github exists a little application rpm-gen-configuration or so that can create an rpm from configuration data. It generate automatically the deps required and it is safe regarding conflict and upgrade. Dunno if can useful to you. Best regards Messaggio originale Da: Olivier Sallou Inviato: 13/07/2011, 09:40 A: devel@lists.fedoraproject.org Oggetto: Fwd: rpm packaging: package configuration Hi, I am a newby regarding rpm packaging (more used to deb packaging). I want to know if there is a way to configure a package at install using rpmdev stuff, like debconf in Debian. Or do we need to create our own config script management? Thanks Olivier -- Olivier Sallou IRISA / University of Rennes 1 Campus de Beaulieu, 35000 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (pgp.mit.edu) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- 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: Fwd: rpm packaging: package configuration
On 07/13/2011 10:57 AM, Olivier Sallou wrote: I create a new package. At install, we need to ask for some quesitons to the user to preconfigure the application. rpm-based installations are supposed to be non-interactive, i.e. this is not allowed. At upgrade, it would be nice to get already answered questions rather than ask again for configuration. Installations are supposed to respect what the user had previously configured. This can be managed manually, but it would be nicer to get this managed with packaging tools. rpm-based systems' philosophy is to let users configure their systems after package installations/updates, not during installation. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages in F-16
2011/7/12 Bill Nottingham nott...@redhat.com: Orphan fvwm comaintained by: pertusus Took this one. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v2] Retiring packages in F-16
On Tue, Jul 12, 2011 at 05:10:01PM -0400, Bill Nottingham wrote: Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 16. New this go-round is that we are also blocking packages that have failed to build since before Fedora 14. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. This list has been fixed to properly show all orphaned packages. It's a lot longer. [...] Orphan libcmpiutil comaintained by: veillard [...] Orphan libvirt-cim comaintained by: veillard I sent a mail to this very list one week ago: Date: Wed, 6 Jul 2011 09:07:57 +0800 From: Daniel Veillard veill...@redhat.com To: devel@lists.fedoraproject.org Subject: Taking ownership of libcmpiutil and libvirt-cim to avoid them being retired, never got an answer. At the time visiting https://admin.fedoraproject.org/pkgdb/acls/name/libcmpiutil didn't show any option to take ownership, was that a temporary failure, I'm sure I checked and was logged in, weird ... Anyway I now took ownership of both. BTW could someone could take care of rel-eng request #4805 http://fedorahosted.org/rel-eng I'm unable to build a recent libvirt-cim for F15 due to the libcmpi update dependancy, thanks in advance ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 718190] perl-Coro-6.02 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=718190 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Coro-6.01 is available |perl-Coro-6.02 is available --- Comment #3 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org 2011-07-13 06:35:37 EDT --- Latest upstream release: 6.02 Current version in Fedora Rawhide: 5.372 URL: http://search.cpan.org/dist/Coro/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [ACTION REQUIRED v2] Retiring packages in F-16
On Tuesday, July 12, 2011 11:10:01 PM Bill Nottingham wrote: Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 16. New this go-round is that we are also blocking packages that have failed to build since before Fedora 14. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. This list has been fixed to properly show all orphaned packages. It's a lot longer. Orphan contextkit comaintained by: jreznik A comaintainer I take this one. Orphan qct I use it sometimes, taken. Orphan qtcurve-kde4 comaintained by: rdieter hein Just not to forget, I take this one as rdieter and Sho are comaintainers, feel free to ask me to take ownership. Jaroslav -- Jaroslav Řezník jrez...@redhat.com Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages in F-16
On Wed, 13 Jul 2011 09:55:30 +1000 Peter Hutterer wrote: On Tue, Jul 12, 2011 at 11:05:14PM +0200, Thomas Spura wrote: On Tue, 12 Jul 2011 15:28:59 -0400 Bill Nottingham wrote: Orphan gpointing-device-settings This is co-maintained by whot (not shown in this list). I definitely want to keep this. Peter: Do you continue as primary maintainer and I'll co-maintain it, or do you want to stay co-maintainer? I got added as maintainer when the package was added but it's been quite a while since I found time to look at it, nevermind attempting to fix any bugs. I'd be happy for you to take over this package, I'll remove myself from the maintainers list then. Thanks. Unorphaned in F-15 and devel. Will try to look at the bugs soon... Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v2] Retiring packages in F-16
Orphan scitools I'm going to take this -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v2] Retiring packages in F-16
On Tue, 2011-07-12 at 17:10 -0400, Bill Nottingham wrote: Orphan netsniff-ng comaintained by: fab No more orphaned. I've grabbed it Fedora+EPEL. Skalnik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v2] Retiring packages in F-16
Orphan spyder comaintained by: rnovacek I have taken spyder, as I'm comaintainer. Radek Novacek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Poll: Does ACPI lid state work on your Linux laptop?
On Tue, Jul 12, 2011 at 05:01:11PM -0400, Adam Jackson wrote: On Tue, 2011-07-12 at 23:44 +0300, Pasi Kärkkäinen wrote: Hello list, I'm curious to know how many laptops have problems with ACPI lid state in Linux. I've been told some laptops report wrong lid state through ACPI, while my laptop seems to report it properly. Once you have this data, what do you intend to do with it? Good question. I was just curious to know how widespread problem that is. I tend to use my laptop in the docking station, only using external monitor, so it's annoying when testing new alpha/beta/final Fedora releases and Fedora uses the internal lvds, under the *closed* lid, as a primary display.. ie. the installer/livedesktop is not visible at all on my setup, until I open the lid. So just trying to find some kind of workaround to that.. Using clone-mode as a default would solve the problem.. (now the default mode in Fedora is to use extended desktop) -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Poll: Does ACPI lid state work on your Linux laptop?
On Tue, Jul 12, 2011 at 10:01:25PM +0100, Matthew Garrett wrote: On Tue, Jul 12, 2011 at 11:44:59PM +0300, Pasi Kärkkäinen wrote: I guess that should cover all the usecases.. Please post your findings to this list. Please don't. ACPI lid state is not reliable on a range of hardware for a bunch of reasons, ranging from open events that are never fired to query methods that read from the wrong register. We can't pay attention to it by default, and running a survey doesn't change that. Ok. Do you know if there are other (better working) methods to get the lid state info? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages in F-16
Orphan etherape I take it -- JFCh jchad...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
New feature for Fedora 16: new mkdumprd
Hello, Fedora people, Would any of you kindly help to review my proposed feature for Fedora 16? https://fedoraproject.org/wiki/Features/NewMkdumprd Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New feature for Fedora 16: new mkdumprd
On Wed, Jul 13, 2011 at 09:31:39PM +0800, Américo Wang wrote: Hello, Fedora people, Would any of you kindly help to review my proposed feature for Fedora 16? https://fedoraproject.org/wiki/Features/NewMkdumprd In case anyone was wondering, Américo also addressed this to me because I previously gave him some tips on constructing a Fedora feature page. :-) Discuss away! -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New feature for Fedora 16: new mkdumprd
On Wed, Jul 13, 2011 at 09:46:30AM -0400, Paul W. Frields wrote: On Wed, Jul 13, 2011 at 09:31:39PM +0800, Américo Wang wrote: Hello, Fedora people, Would any of you kindly help to review my proposed feature for Fedora 16? https://fedoraproject.org/wiki/Features/NewMkdumprd In case anyone was wondering, Américo also addressed this to me because I previously gave him some tips on constructing a Fedora feature page. :-) Discuss away! Feature proposal dealing was yesterday? -- Tomasz Torcz God, root, what's the difference? xmpp: zdzich...@chrome.pl God is more forgiving. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New feature for Fedora 16: new mkdumprd
On Wed, Jul 13, 2011 at 03:50:07PM +0200, Tomasz Torcz wrote: Would any of you kindly help to review my proposed feature for Fedora 16? https://fedoraproject.org/wiki/Features/NewMkdumprd Feature proposal dealing was yesterday? deadline, of course. -- Tomasz Torcz God, root, what's the difference? xmpp: zdzich...@chrome.pl God is more forgiving. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New feature for Fedora 16: new mkdumprd
On Wed, Jul 13, 2011 at 09:46:30AM -0400, Paul W. Frields wrote: On Wed, Jul 13, 2011 at 09:31:39PM +0800, Américo Wang wrote: Hello, Fedora people, Would any of you kindly help to review my proposed feature for Fedora 16? https://fedoraproject.org/wiki/Features/NewMkdumprd In case anyone was wondering, Américo also addressed this to me because I previously gave him some tips on constructing a Fedora feature page. :-) Discuss away! *sigh* Never mind -- I got a copy of this and thought it was addressed to me personally. Need more coffee. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Poll: Does ACPI lid state work on your Linux laptop?
On Wed, 2011-07-13 at 15:22 +0300, Pasi Kärkkäinen wrote: On Tue, Jul 12, 2011 at 10:01:25PM +0100, Matthew Garrett wrote: Please don't. ACPI lid state is not reliable on a range of hardware for a bunch of reasons, ranging from open events that are never fired to query methods that read from the wrong register. We can't pay attention to it by default, and running a survey doesn't change that. Ok. Do you know if there are other (better working) methods to get the lid state info? If we knew of any, they'd be implemented in the kernel, and we'd be using them. I know this is a frustrating thing to hear, and I empathize, I really do. But the state of the art right now is that there's one interface for laptop lids, it's in ACPI, and it's not reliable. Once upon a time there was an effort to make a Linux-based test kit for firmware [1], so vendors could run it before releasing hardware and verify that the Linux interfaces function. Lid state and lid events could have been one such test case. Sadly the effort seems to have stagnated; it could really use a revival. But even such a test kit would only fix new hardware, existing machines will continue to be as broken as they currently are forever. [1] - http://linuxfirmwarekit.org/ - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cmake so versioning issue
On Tue, 2011-07-12 at 13:54 -0500, Richard Shaw wrote: Dang line wrapping :) Here's another version using LIBRARIES_SOVERSION instead. Didn't see it the first time. http://pastebin.com/8wQeM6XQ Richard Hi Richard, That didn't work either :/ I decided to hack it down, and now this is what my spec looks like: http://ankursinha.fedorapeople.org/opennl/OpenNL.spec -- Thanks, Regards, Ankur: FranciscoD http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: rpm packaging: package configuration
On 07/13/2011 05:14 AM, Ralf Corsepius wrote: On 07/13/2011 10:57 AM, Olivier Sallou wrote: This can be managed manually, but it would be nicer to get this managed with packaging tools. rpm-based systems' philosophy is to let users configure their systems after package installations/updates, not during installation. OK, but post-installation configuration is a serious deployment issue in some environments; sometimes it is a legal requirement (custom login messages, participation in enterprise account management, this kind of thing). Doing manual tweaking on many machines is not fun---I can see two ways of dealing with this: 1) deployment of a configuration system like puppet 2) private configuration packages installed after standard package sets, that tweak the installation 1) is preferred, but requires serious prep and setup, and in any case it implies some additional client configuration that simply does not happen in the standard install. Is 2) an acceptable solution to the assembled wisdom? It doesn't seem that different to what selinux policy packages are doing in the SELinux area. Maybe there are other ways to approach it that worked well for people---please comment. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cmake so versioning issue
On Wed, Jul 13, 2011 at 9:18 AM, Ankur Sinha sanjay.an...@gmail.com wrote: On Tue, 2011-07-12 at 13:54 -0500, Richard Shaw wrote: Hi Richard, That didn't work either :/ I was going purely by the patch and I'm certainly not a cmake expert but this did work for me on a new package I'm working on... I decided to hack it down, and now this is what my spec looks like: http://ankursinha.fedorapeople.org/opennl/OpenNL.spec Does that actually set the soversion in the library? What does: readelf -d library.so | grep -i SONAME give you? An example from my package: # readelf -d libpugixml.so | grep -i SONAME 0x000e (SONAME) Library soname: [libpugixml.so.1.0] Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Poll: Does ACPI lid state work on your Linux laptop?
Hi, On 07/13/2011 04:11 PM, Adam Jackson wrote: On Wed, 2011-07-13 at 15:22 +0300, Pasi Kärkkäinen wrote: On Tue, Jul 12, 2011 at 10:01:25PM +0100, Matthew Garrett wrote: Please don't. ACPI lid state is not reliable on a range of hardware for a bunch of reasons, ranging from open events that are never fired to query methods that read from the wrong register. We can't pay attention to it by default, and running a survey doesn't change that. Ok. Do you know if there are other (better working) methods to get the lid state info? If we knew of any, they'd be implemented in the kernel, and we'd be using them. I know this is a frustrating thing to hear, and I empathize, I really do. But the state of the art right now is that there's one interface for laptop lids, it's in ACPI, and it's not reliable. Once upon a time there was an effort to make a Linux-based test kit for firmware [1], so vendors could run it before releasing hardware and verify that the Linux interfaces function. Lid state and lid events could have been one such test case. Sadly the effort seems to have stagnated; it could really use a revival. But even such a test kit would only fix new hardware, existing machines will continue to be as broken as they currently are forever. Maybe it it is an idea to build a whitelist for machines which do have working ACPI lid support? I realize maintaining such a list is a pain, but this way people who care and are lucky enough to have actually working hardware can at least use this ? Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cmake so versioning issue
On Wed, 2011-07-13 at 09:30 -0500, Richard Shaw wrote: On Wed, Jul 13, 2011 at 9:18 AM, Ankur Sinha sanjay.an...@gmail.com wrote: On Tue, 2011-07-12 at 13:54 -0500, Richard Shaw wrote: Hi Richard, That didn't work either :/ I was going purely by the patch and I'm certainly not a cmake expert but this did work for me on a new package I'm working on... I decided to hack it down, and now this is what my spec looks like: http://ankursinha.fedorapeople.org/opennl/OpenNL.spec Does that actually set the soversion in the library? What does: readelf -d library.so | grep -i SONAME give you? An example from my package: # readelf -d libpugixml.so | grep -i SONAME 0x000e (SONAME) Library soname: [libpugixml.so.1.0] Thanks, Richard Yep! It does :D [root@ankur lib]# ls libopennl.so.3.4.1 [root@ankur lib]# readelf -d libopennl.so.3.4.1 | egrep -i soname 0x000e (SONAME) Library soname: [libopennl.so.3] -- Thanks, Regards, Ankur: FranciscoD http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 695589] Providing native systemd file for upcoming F15 Feature 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=695589 Jóhann B. Guðmundsson johan...@hi.is changed: What|Removed |Added Blocks||713562(SysVtoSystemd) --- Comment #6 from Jóhann B. Guðmundsson johan...@hi.is 2011-07-13 11:10:22 EDT --- https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd https://fedoraproject.org/wiki/Packaging:Tmpfiles.d -- 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 695597] Providing native systemd file for upcoming F15 Feature 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=695597 Jóhann B. Guðmundsson johan...@hi.is changed: What|Removed |Added Blocks||713562(SysVtoSystemd) --- Comment #2 from Jóhann B. Guðmundsson johan...@hi.is 2011-07-13 11:10:42 EDT --- https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd https://fedoraproject.org/wiki/Packaging:Tmpfiles.d -- 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: [ACTION REQUIRED v2] Retiring packages in F-16
Bill Nottingham wrote, at 07/13/2011 06:10 AM +9:00: Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 16. New this go-round is that we are also blocking packages that have failed to build since before Fedora 14. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. This list has been fixed to properly show all orphaned packages. It's a lot longer. Orphan kazehakase I am the current (orignal) owner of kazehakase and now I fixed the build (FTBFS issue). Any other action needed? Thank you in advance. Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v2] Retiring packages in F-16
TASAKA Mamoru (mtas...@fedoraproject.org) said: Orphan kazehakase I am the current (orignal) owner of kazehakase and now I fixed the build (FTBFS issue). Any other action needed? Nope, the FTBFS will be re-checked against what's built in dist-f16 before we retire anything. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Poll: Does ACPI lid state work on your Linux laptop?
On Wed, 2011-07-13 at 16:57 +0200, Hans de Goede wrote: Maybe it it is an idea to build a whitelist for machines which do have working ACPI lid support? I realize maintaining such a list is a pain, but this way people who care and are lucky enough to have actually working hardware can at least use this ? It's an idea, but not one I'd do. Either a whitelist or a blacklist would be oppressively large. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning iDesk
Hello all, I've orphaned idesk. Upstream is long dead and I'm currently do not have the necessary free time to get it to work under Fedora 15. - Gilboa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: rpm packaging: package configuration
On Wed, Jul 13, 2011 at 3:14 AM, Ralf Corsepius rc040...@freenet.de wrote: On 07/13/2011 10:57 AM, Olivier Sallou wrote: I create a new package. At install, we need to ask for some quesitons to the user to preconfigure the application. rpm-based installations are supposed to be non-interactive, i.e. this is not allowed. If a package has this sort of thing, it will be separate from RPM or yum. See MySQL's mysql_secure_installation script for an example. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Net-SSLeay] drop obsolete BRs
commit 6a58efa8d736d5fdcebbe1ce3928b6f3f36c4367
Author: Iain Arnell iarn...@gmail.com
Date: Wed Jul 13 18:11:43 2011 +0200
drop obsolete BRs
perl-Net-SSLeay.spec |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
---
diff --git a/perl-Net-SSLeay.spec b/perl-Net-SSLeay.spec
index 9c5b9fb..35487cc 100644
--- a/perl-Net-SSLeay.spec
+++ b/perl-Net-SSLeay.spec
@@ -1,6 +1,6 @@
Name: perl-Net-SSLeay
Version: 1.36
-Release: 4%{?dist}
+Release: 5%{?dist}
Summary: Perl extension for using OpenSSL
Group: Development/Libraries
License: OpenSSL
@@ -9,9 +9,9 @@ Source0:
http://search.cpan.org/CPAN/authors/id/F/FL/FLORA/Net-SSLeay-%{version}
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildRequires: perl(ExtUtils::MakeMaker), openssl-devel
-BuildRequires: perl(Array::Compare), perl(MIME::Base64), perl(Sub::Uplevel)
+BuildRequires: perl(MIME::Base64)
BuildRequires: perl(Test::Exception), perl(Test::NoWarnings), perl(Test::Pod)
-BuildRequires: perl(Test::Warn), perl(Tree::DAG_Node)
+BuildRequires: perl(Test::Warn)
# don't provide private Perl libs or the redundant unversioned
perl(Net::SSLeay) one
%global _use_internal_dependency_generator 0
@@ -67,6 +67,9 @@ PERL_MM_USE_DEFAULT=1 %{__perl} Makefile.PL \
%{_mandir}/man3/Net::SSLeay*.3*
%changelog
+* Wed Jul 13 2011 Iain Arnell iarn...@gmail.com 1.36-5
+- drop obsolete BRs Array::Compare, Sub::Uplevel, Tree::DAG_Node
+
* Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.36-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [ACTION REQUIRED v2] Retiring packages in F-16
On Wed, Jul 13, 2011 at 06:06:37PM +0800, Daniel Veillard wrote: On Tue, Jul 12, 2011 at 05:10:01PM -0400, Bill Nottingham wrote: Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 16. New this go-round is that we are also blocking packages that have failed to build since before Fedora 14. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. This list has been fixed to properly show all orphaned packages. It's a lot longer. [...] Orphan libcmpiutil comaintained by: veillard [...] Orphan libvirt-cim comaintained by: veillard I sent a mail to this very list one week ago: Date: Wed, 6 Jul 2011 09:07:57 +0800 From: Daniel Veillard veill...@redhat.com To: devel@lists.fedoraproject.org Subject: Taking ownership of libcmpiutil and libvirt-cim to avoid them being retired, never got an answer. At the time visiting https://admin.fedoraproject.org/pkgdb/acls/name/libcmpiutil didn't show any option to take ownership, was that a temporary failure, I'm sure I checked and was logged in, weird ... Sorta. These packages were orphaned due to the maintainer not signing the FPCA. When that script was run, I failed to properly set the status to Orphaned which left you unable to take ownership. Sorry for missing your earlier email about the problem and thanks for taking them now! -Toshio pgp0bnwlVCAYy.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Catalyst-Plugin-Session/el6] drop circular build deps
Summary of changes: e046513... drop circular build deps (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fwd: rpm packaging: package configuration
On Wed, Jul 13, 2011 at 10:57:03AM +0200, Olivier Sallou wrote: I create a new package. At install, we need to ask for some quesitons to the user to preconfigure the application. As others have said, this is a bad idea and not permitted for Fedora. Personally I think it's a misfeature of apt/dpkg that updates are not completely automated by default. Nevertheless, it *is* possible to write an RPM which asks questions during the %post script, and in fact I have used RPMs which did this in the past (a bit of proprietary software where installation required a license key to be entered on the keyboard as part of the EULA). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: rpm packaging: package configuration
On Wed, 2011-07-13 at 09:40 +0200, Olivier Sallou wrote: Hi, I am a newby regarding rpm packaging (more used to deb packaging). I want to know if there is a way to configure a package at install using rpmdev stuff, like debconf in Debian. Or do we need to create our own config script management? RPM doesn't have anything equivalent; it's considered a no-no in RPM packaging to have any interactivity as part of a package's scripts, packages are expected to be installable unattended. -- Adam Williamson Fedora QA Community Monkey IRC: adamw http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Poll: Does ACPI lid state work on your Linux laptop?
On Wed, 2011-07-13 at 15:21 +0300, Pasi Kärkkäinen wrote: On Tue, Jul 12, 2011 at 05:01:11PM -0400, Adam Jackson wrote: On Tue, 2011-07-12 at 23:44 +0300, Pasi Kärkkäinen wrote: Hello list, I'm curious to know how many laptops have problems with ACPI lid state in Linux. I've been told some laptops report wrong lid state through ACPI, while my laptop seems to report it properly. Once you have this data, what do you intend to do with it? Good question. I was just curious to know how widespread problem that is. I tend to use my laptop in the docking station, only using external monitor, so it's annoying when testing new alpha/beta/final Fedora releases and Fedora uses the internal lvds, under the *closed* lid, as a primary display.. ie. the installer/livedesktop is not visible at all on my setup, until I open the lid. So just trying to find some kind of workaround to that.. Using clone-mode as a default would solve the problem.. (now the default mode in Fedora is to use extended desktop) I think I recall discussing this with the anaconda team before; we agreed in principle that it would make sense for anaconda to default to clone mode, but the problem is X doesn't have any very easy mechanism for overriding the default, there is no simple command line parameter anaconda could pass to X to launch it in clone mode instead of span mode. anaconda would have to include an X config stub to specify clone mode and then ensure that stub wasn't installed. I think no-one got around to getting that done yet. I'm not sure if there's a bug for it, but you could have a look. -- Adam Williamson Fedora QA Community Monkey IRC: adamw http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Poll: Does ACPI lid state work on your Linux laptop?
On Wed, 2011-07-13 at 11:35 -0400, Adam Jackson wrote: On Wed, 2011-07-13 at 16:57 +0200, Hans de Goede wrote: Maybe it it is an idea to build a whitelist for machines which do have working ACPI lid support? I realize maintaining such a list is a pain, but this way people who care and are lucky enough to have actually working hardware can at least use this ? It's an idea, but not one I'd do. Either a whitelist or a blacklist would be oppressively large. I suppose a whitelist has the advantage that it can't hurt anything compared to the current state, and no matter how short it is, it benefits *some* people. -- Adam Williamson Fedora QA Community Monkey IRC: adamw http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Poll: Does ACPI lid state work on your Linux laptop?
On Wed, 2011-07-13 at 10:47 -0700, Adam Williamson wrote: On Wed, 2011-07-13 at 11:35 -0400, Adam Jackson wrote: On Wed, 2011-07-13 at 16:57 +0200, Hans de Goede wrote: Maybe it it is an idea to build a whitelist for machines which do have working ACPI lid support? I realize maintaining such a list is a pain, but this way people who care and are lucky enough to have actually working hardware can at least use this ? It's an idea, but not one I'd do. Either a whitelist or a blacklist would be oppressively large. I suppose a whitelist has the advantage that it can't hurt anything compared to the current state, and no matter how short it is, it benefits *some* people. Oh, and depending on how it was implemented, it would provide a way for competent users to manually add their own systems to the whitelist and enable lid state functionality if they were happy with its performance on their particular system; right now there's no way you can say 'no, really, the lid switch works on my system, please use it'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Poll: Does ACPI lid state work on your Linux laptop?
On Wed, Jul 13, 2011 at 12:50 PM, Adam Williamson awill...@redhat.com wrote: Oh, and depending on how it was implemented, it would provide a way for competent users to manually add their own systems to the whitelist and enable lid state functionality if they were happy with its performance on their particular system; right now there's no way you can say 'no, really, the lid switch works on my system, please use it'. I'm not volunteering since I don't have enough time or programming skill, but... What about some kind of simple (python?) GUI interface that would first check against a whitelist, then if not on it could test for the correct events by instructing the user clone and open their lids a few times and then (if successful) ask the user if they want to enable lid support? Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
# F16 Alpha Blocker Review meeting #1 # Date: 2011-07-15 # Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT, 10:00 MST) # Location: #fedora-bugzappers on irc.freenode.net Hard to believe, but the vacation is over. Fedora 16 Alpha test compose is a few weeks away (Jul 26) and the Alpha is about a month away (Aug 10 for go/no_go meeting). In an effort to reduce last minute bug scramble, the blocker review meetings will be starting up again [2]. Each Friday, between now and the Alpha release, a blocker review will take place in #fedora-bugzappers. Mark your calendars ... the first Alpha blocker review meeting starts at 17:00 UTC in #fedora-bugzappers. We'll review proposed and accepted F16 Alpha blocker bugs. An updated list of blocker bugs is available at https://fedoraproject.org/wiki/Current_Release_Blockers (also attached to this mail). We'll be reviewing the bugs to determine ... 1. whether they meet the Alpha release criteria [3] and should stay on the list 2. are getting the attention they need For guidance on Blocker and Nice-to-have (NTH) bugs, refer to https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and https://fedoraproject.org/wiki/QA:SOP_nth_bug_process == Suggested Meeting Preparation == Maintainers ... * If your bug is *not* MODIFIED ... this issue is at risk of slipping the F16 Alpha release date * If your bug is in MODIFIED ... please make sure a build with the fix exists, and is available as a bodhi update. Testers ... * If you REPORT a bug ... please be responsive to any requests for additional information. * If a bug is in ON_QA ... please take a moment to apply the update, and post karma feedback (doesn't apply to rawhide at the moment) [1] https://fedoraproject.org/wiki/Infrastructure/UTCHowto [2] http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html [3] https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria Thanks, James == Approved Blockers == The following list of bugs are approved blockers that must be resolved. There are 0 bugs affecting 0 components. == Proposed Blockers == The following list of bugs are not yet approved to block the release. There are 108 bugs affecting 106 components. For guidance on reviewing the following bugs, refer to [[QA:SOP_blocker_bug_process]]. * 389-admin - http://bugzilla.redhat.com/show_bug.cgi?id=695741 (NEW) - Providing native systemd file * 389-ds-base - http://bugzilla.redhat.com/show_bug.cgi?id=695736 (NEW) - Providing native systemd file * Ajaxterm - http://bugzilla.redhat.com/show_bug.cgi?id=657565 (NEW) - Providing native systemd file for upcoming F15 Feature Systemd * BackupPC - http://bugzilla.redhat.com/show_bug.cgi?id=699441 (ASSIGNED) - Providing native systemd file for upcoming F15 Feature Systemd * NetworkManager - http://bugzilla.redhat.com/show_bug.cgi?id=714702 (NEW) - Legacy SysV initscript file must go into an optional subpackage. * NetworkManager - http://bugzilla.redhat.com/show_bug.cgi?id=716904 (NEW) - Legacy SysV initscript file must go into an optional subpackage. * Pound - http://bugzilla.redhat.com/show_bug.cgi?id=720448 (NEW) - Provide native systemd unit file * aiccu - http://bugzilla.redhat.com/show_bug.cgi?id=656886 (NEW) - provide native aiccu.service systemd file * am-utils - http://bugzilla.redhat.com/show_bug.cgi?id=658116 (NEW) - Providing native systemd file for upcoming F15 Feature Systemd * amavisd-new - http://bugzilla.redhat.com/show_bug.cgi?id=695589 (NEW) - Providing native systemd file for upcoming F15 Feature Systemd * amavisd-new - http://bugzilla.redhat.com/show_bug.cgi?id=695597 (NEW) - Providing native systemd file for upcoming F15 Feature Systemd * apmd - http://bugzilla.redhat.com/show_bug.cgi?id=716970 (NEW) - Provide native systemd unit file * apt - http://bugzilla.redhat.com/show_bug.cgi?id=699293 (NEW) - Providing native systemd file for upcoming F15 Feature Systemd * argus - http://bugzilla.redhat.com/show_bug.cgi?id=699292 (NEW) - Providing native systemd file for upcoming F15 Feature Systemd * arm4 - http://bugzilla.redhat.com/show_bug.cgi?id=699289 (NEW) - Providing native systemd file for upcoming F15 Feature Systemd * at - http://bugzilla.redhat.com/show_bug.cgi?id=714642 (NEW) - Legacy SysV initscript file must go into an optional subpackage. * audit - http://bugzilla.redhat.com/show_bug.cgi?id=617321 (NEW) - Providing native systemd file for upcoming F14 Feature Systemd * autofs - http://bugzilla.redhat.com/show_bug.cgi?id=718701 (NEW) - Provide native systemd unit file * avahi - http://bugzilla.redhat.com/show_bug.cgi?id=714649 (NEW) - Legacy SysV initscript file must go into an optional subpackage. * bacula - http://bugzilla.redhat.com/show_bug.cgi?id=657216 (NEW) - Providing native systemd file for upcoming F15 Feature Systemd * bind - http://bugzilla.redhat.com/show_bug.cgi?id=719419
Re: [ACTION REQUIRED v2] Retiring packages in F-16
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Orphan gtranslator comaintained by: tbzatek I'm interested in this application. If co-maintainer does not take it, I'd like to take it over. I'm not yet a Fedora package maintainer, only have proposed a couple of packages, that have not yet been accepted. - -- Aurimas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOHez8AAoJECtTeRAzEaLPrRoH/3kDs381+1GgcXYR0K+hKu52 B12LMMMHi8se6ViyHT6T+ii5O+fUqLBzoGN2x1VZFWcpuRGdEVYyAU5i3GuBPJl2 1R5wukNZzgH3jUYigsTJDOrW9C9HNYHflzLP89Bh/K7Vtr7u3y1BGeoKLsXJfhJF GLIYSPJUg5eaoPbZ8YAKvsMNtwHRLwPxVfvQR+mxJ4F8clAs0PXZeYH1cHJ3LpWH AHUuTMl4LM8kRbnRVPF6JtaQWmY7qgyh+qKn0cC61CQFoHw7L15XdSu79bIzdAtq hjxb+AKEjEKSOVaQFA17xYeRatrM6+40n/nLfBS4xs9W4b+MZzbFQ8j2C2iB4lg= =bRwD -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 720744] Rebuild required to work correctly with perl 5.12.4
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=720744 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System upda...@fedoraproject.org 2011-07-13 15:27:34 EDT --- Package perl-Devel-Cover-0.78-1.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Devel-Cover-0.78-1.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/perl-Devel-Cover-0.78-1.fc15 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
[dspam/f15] start as dspam user
commit 9424dcf0793d78e198c379aa8aac31d9685b17ba
Author: Nathanael D. Noblet nathan...@gnat.ca
Date: Wed Jul 13 13:28:54 2011 -0600
start as dspam user
dspam-init.d| 13 ++---
dspam-sysconfig |3 ++-
dspam.spec |5 -
3 files changed, 12 insertions(+), 9 deletions(-)
---
diff --git a/dspam-init.d b/dspam-init.d
index 8b331b0..eae9f75 100644
--- a/dspam-init.d
+++ b/dspam-init.d
@@ -23,6 +23,7 @@ if [ -f /etc/sysconfig/dspam ] ; then
. /etc/sysconfig/dspam
else
DSPAM_BIN=/usr/bin/dspam
+DSPAM_USER=dspam
fi
# Check that networking is up.
@@ -36,13 +37,11 @@ start() {
if [ -f /var/lock/subsys/dspam ]; then
RETVAL=0
else
-${DSPAM_BIN} --daemon 2/dev/null
-RETVAL=$?
-if [ $RETVAL -eq 0 ]; then
-echo_success
-else
-echo_failure
-fi
+daemon --check ${DSPAM_BIN} --user ${DSPAM_USER} ${DSPAM_BIN} --daemon
2/dev/null
+
+sleep 1
+
+status ${prog} /dev/null echo_success || echo_failure
fi
echo
[ $RETVAL -eq 0 ] touch /var/lock/subsys/dspam
diff --git a/dspam-sysconfig b/dspam-sysconfig
index 986b490..dbe961a 100644
--- a/dspam-sysconfig
+++ b/dspam-sysconfig
@@ -1,2 +1,3 @@
# Location of dspam binary
-DSPAM_BIN=/usr/bin/dspam
\ No newline at end of file
+DSPAM_BIN=/usr/bin/dspam
+DSPAM_USER=dspam
\ No newline at end of file
diff --git a/dspam.spec b/dspam.spec
index ff464c6..93255a3 100644
--- a/dspam.spec
+++ b/dspam.spec
@@ -11,7 +11,7 @@
Summary:A library and Mail Delivery Agent for Bayesian SPAM
filtering
Name: dspam
Version:3.9.0
-Release:20%{?dist}
+Release:21%{?dist}
License:GPLv2
Group: System Environment/Daemons
Source0:
http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
@@ -376,6 +376,9 @@ exit 0
%config(noreplace) %{_sysconfdir}/httpd/conf.d/dspam-web.conf
%changelog
+* Wed July 13 2011 Nathanael Noblet nathan...@gnat.ca - 3.9.0-21
+- Start daemon as dspam user
+
* Wed May 25 2011 Nathanael Noblet nathan...@gnat.ca - 3.9.0-20
- add tmpfile for /var/run/dspam
- remove rpaths that suddenly show up in F15
--
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
[dspam/f14] (5 commits) ...Merge branch 'f15' into f14
Summary of changes: d28a6b7... remove configure patch since bash is fixed (*) 345c5db... rebuilt for libmysqlclient soname bump (*) 18bcc05... added tmpfiles rpath fix (*) 9424dcf... start as dspam user (*) bda6641... Merge branch '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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[dspam/f14: 5/5] Merge branch 'f15' into f14
commit bda66417ac5ea90bd6ce2978735dfdef02842826 Merge: df00717 9424dcf Author: Nathanael D. Noblet nathan...@gnat.ca Date: Wed Jul 13 13:29:53 2011 -0600 Merge branch 'f15' into f14 dspam-3.9.0-configure.patch | 194 --- dspam-init.d| 13 ++-- dspam-sysconfig |3 +- dspam-tmpfiles |1 + dspam.spec | 26 +- 5 files changed, 31 insertions(+), 206 deletions(-) --- -- 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 720295] perlbrew-0.27 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=720295 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System upda...@fedoraproject.org 2011-07-13 15:25:51 EDT --- Package perlbrew-0.27-1.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perlbrew-0.27-1.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/perlbrew-0.27-1.fc15 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
[dspam/el6] (5 commits) ...Merge branch 'f15' into el6
Summary of changes: d28a6b7... remove configure patch since bash is fixed (*) 345c5db... rebuilt for libmysqlclient soname bump (*) 18bcc05... added tmpfiles rpath fix (*) 9424dcf... start as dspam user (*) 3327938... Merge branch 'f15' into el6 (*) 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
[dspam/el6: 5/5] Merge branch 'f15' into el6
commit 33279386edb873e3b21f95c295a230245dca45b3 Merge: 6b8829c 9424dcf Author: Nathanael D. Noblet nathan...@gnat.ca Date: Wed Jul 13 13:30:44 2011 -0600 Merge branch 'f15' into el6 dspam-3.9.0-configure.patch | 194 --- dspam-init.d| 13 ++-- dspam-sysconfig |3 +- dspam-tmpfiles |1 + dspam.spec | 26 +- 5 files changed, 31 insertions(+), 206 deletions(-) --- -- 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: Fwd: rpm packaging: package configuration
Przemek Klosowski wrote: Doing manual tweaking on many machines is not fun That's when you bring out Kickstart I believe. Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[dspam/el5] (2 commits) ...Merge branch 'f15' into el5
Summary of changes: 8af1ab0... fix changelog date 32229ad... Merge branch 'f15' into el5 -- 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
[dspam/el5: 1/2] fix changelog date
commit 8af1ab0019b6c29f3c49a366aec325621c2d8432
Author: Nathanael D. Noblet nathan...@gnat.ca
Date: Wed Jul 13 13:47:56 2011 -0600
fix changelog date
dspam.spec |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/dspam.spec b/dspam.spec
index 93255a3..327195e 100644
--- a/dspam.spec
+++ b/dspam.spec
@@ -376,7 +376,7 @@ exit 0
%config(noreplace) %{_sysconfdir}/httpd/conf.d/dspam-web.conf
%changelog
-* Wed July 13 2011 Nathanael Noblet nathan...@gnat.ca - 3.9.0-21
+* Wed Jul 13 2011 Nathanael Noblet nathan...@gnat.ca - 3.9.0-21
- Start daemon as dspam user
* Wed May 25 2011 Nathanael Noblet nathan...@gnat.ca - 3.9.0-20
--
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
[dspam/el5: 2/2] Merge branch 'f15' into el5
commit 32229ad7abd5a4ddc6b750dbd54b68ce5bdb2970 Merge: dcc8ee4 8af1ab0 Author: Nathanael D. Noblet nathan...@gnat.ca Date: Wed Jul 13 13:51:16 2011 -0600 Merge branch 'f15' into el5 dspam.spec |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) --- -- 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
[dspam/el6] (2 commits) ...Merge branch 'f15' into el6
Summary of changes: 8af1ab0... fix changelog date (*) 46b8530... Merge branch 'f15' into el6 (*) 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
[dspam/el6: 2/2] Merge branch 'f15' into el6
commit 46b853046cbe36b651fda266a467b99ebfc3894a Merge: 3327938 8af1ab0 Author: Nathanael D. Noblet nathan...@gnat.ca Date: Wed Jul 13 13:50:59 2011 -0600 Merge branch 'f15' into el6 dspam.spec |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) --- -- 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
[dspam/f14] (2 commits) ...Merge branch 'f15' into f14
Summary of changes: 8af1ab0... fix changelog date (*) 8529418... Merge branch '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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[dspam/f14: 2/2] Merge branch 'f15' into f14
commit 8529418be37c3a202b472854aa24630137b6fcf1 Merge: bda6641 8af1ab0 Author: Nathanael D. Noblet nathan...@gnat.ca Date: Wed Jul 13 13:50:38 2011 -0600 Merge branch 'f15' into f14 dspam.spec |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) --- -- 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
[dspam/f15] fix changelog date
Summary of changes: 8af1ab0... fix changelog date (*) (*) 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
[dspam] fix changelog date
Summary of changes: 8af1ab0... fix changelog date (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: systemd: Is it wrong? - wrong order
On Mon, Jul 11, 2011 at 07:50:58PM +0200, Lennart Poettering wrote: On Mon, 11.07.11 13:20, Steve Dickson (ste...@redhat.com) wrote: they are handling the systemd conversation... What other distro are planing to use it? I lost track of this a bit, but MeeGo already switched, and Mandriva did too afair. OpenSUSE will switch in the coming release. + next Mageia will have it (version 2) Gentoo, Debian, Arch have it in the disro, but not default. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
BTRFS: The Good, The Bad and The Ugly
Today I'll be switching from BTRFS to Ext4 again because of the troubles I've been having with the New Linux Filesystem. As BTRFS is going to be the Default in F16 I wanted the developers to know what kind of troubles I've been experiencing with this FS in F15 so they can take a look at them in order to have a better F16 release: The Good: Since BTRFS arrived into my computer (Everything in the HDD is formated with BTRFS excluding /boot) I've seen a performance improvement in the data transfer part from and to the computer (copying files seem to be faster than before) But that's all about the good things I noticed... The Bad: BTRFS has reduced system's overall performance, at this point, sometimes it is OK, sometimes it is VERY BAD, I've noticed Performance Peaks in F15 with BTRFS and the Boot times are not nice: I mean, they are not the slowest ones, but they're not as good as Before in F14 with Ext4 instead of BTRFS. The performance Running/Launching apps has been afected too and now the PC freezes sometimes (that never happened in F14 unless I forced it a lot with 4 VM's to suck the 4GB of RAM I have); And Now it freezes very often when it wants without a lot of effort. The Ugly: Running VM's when having their virtual HDD's stored in a BTRFS partition is DEATH! They're very slow, sometimes they open, sometimes they not, usually they freeze, You can't work with them. Same thing about Gnome Shell working over a BTRFS partition: it is really slow, sometimes it reacts but most of the time is pretty unresponsive. Reading in the Web, I found that some users think that the BTRFS poor performance is caused by some special kind of fragmentation it suffers, others think it's because of it's CopyonWrite attributes and some others blame other stuff, God Knows! the only thing I know is that BTRFS is not ready for being used in normal production machines (as I tought) and it needs to be fixed before the release of F16, because it's performance is really far from good... Other Stuff I noticed is that with Kernel 2.6.38.8-35 the system seems to work better that with the previous one, just a little, but is some kind of improvement. Here you have all the info I found on the net about BTRFS Performance issues noticed by users: https://bugzilla.redhat.com/show_bug.cgi?id=689127 http://arosenfeld.wordpress.com/2010/12/27/back-to-ext4-from-btrfs/ http://www.vyatta4people.org/btrfs-is-a-bad-choice-when-running-kvm/ http://lkml.org/lkml/2010/7/13/475 http://blog.patshead.com/2011/03/btrfs---six-months-later.html I only have a question: Why Any Kind of VM is Sooo Slow when being stored on a BTRFS partition? Any Way to Solve this? or at least have a BTRFS performance improvement? Thanks! Hope this mail help the Developers improving the new FS. Have a Nice Day! -- Manuel Escudero Linux User #509052 Twitter: @Jmlevick http://twitter.com/Jmlevick Blogger: Blog Xenode http://xenodesystems.blogspot.com/ PGP/GnuPG: E2F5 12FA E1C3 FA58 CF15 8481 B77B 00CA C1E1 0FA7 Xenode Systems - xenodesystems.com http://www.xenodesystems.com/ - Conéctate a Tu Mundo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS: The Good, The Bad and The Ugly
On Wed, Jul 13, 2011 at 4:53 PM, Manuel Escudero jmlev...@gmail.com wrote: Today I'll be switching from BTRFS to Ext4 again because of the troubles I've been having with the New Linux Filesystem. As BTRFS is going to be the Default in F16 I wanted the developers to know what kind of troubles I've been experiencing with this FS in F15 so they can take a look at them in order to have a better F16 release: The Good: Since BTRFS arrived into my computer (Everything in the HDD is formated with BTRFS excluding /boot) I've seen a performance improvement in the data transfer part from and to the computer (copying files seem to be faster than before) But that's all about the good things I noticed... The Bad: BTRFS has reduced system's overall performance, at this point, sometimes it is OK, sometimes it is VERY BAD, I've noticed Performance Peaks in F15 with BTRFS and the Boot times are not nice: I mean, they are not the slowest ones, but they're not as good as Before in F14 with Ext4 instead of BTRFS. The performance Running/Launching apps has been afected too and now the PC freezes sometimes (that never happened in F14 unless I forced it a lot with 4 VM's to suck the 4GB of RAM I have); And Now it freezes very often when it wants without a lot of effort. The Ugly: Running VM's when having their virtual HDD's stored in a BTRFS partition is DEATH! They're very slow, sometimes they open, sometimes they not, usually they freeze, You can't work with them. Same thing about Gnome Shell working over a BTRFS partition: it is really slow, sometimes it reacts but most of the time is pretty unresponsive. Reading in the Web, I found that some users think that the BTRFS poor performance is caused by some special kind of fragmentation it suffers, others think it's because of it's CopyonWrite attributes and some others blame other stuff, God Knows! the only thing I know is that BTRFS is not ready for being used in normal production machines (as I tought) and it needs to be fixed before the release of F16, because it's performance is really far from good... Other Stuff I noticed is that with Kernel 2.6.38.8-35 the system seems to work better that with the previous one, just a little, but is some kind of improvement. Here you have all the info I found on the net about BTRFS Performance issues noticed by users: https://bugzilla.redhat.com/show_bug.cgi?id=689127 http://arosenfeld.wordpress.com/2010/12/27/back-to-ext4-from-btrfs/ http://www.vyatta4people.org/btrfs-is-a-bad-choice-when-running-kvm/ http://lkml.org/lkml/2010/7/13/475 http://blog.patshead.com/2011/03/btrfs---six-months-later.html I only have a question: Why Any Kind of VM is Sooo Slow when being stored on a BTRFS partition? Any Way to Solve this? or at least have a BTRFS performance improvement? Yeah VMs are a particular problem with Btrfs. There are a ton of reasons for this, for example by default we use fsync. Fsync _sucks_ for btrfs currently, and it has historically not been a well optimized piece of code. I'm working on fixing this, but it requires VFS level changes that are currently sitting in Al's queue. I suspect they will go into 3.1 and so we can move ahead with our work, but for now, it sucks. You can use cache=none you get better performance, but still not that great. And this is all because of one major thing Btrfs has threads for _everything_. This works out fantastically when you have big chunks of reads or writes you want done. This _sucks_ when you are doing little piddly io's. The reason for all of this is because we don't want you to get bottlenecked on us calculating/verifying checksums, so we farm all IO and endio out to different threads, which as I said works out great if you are trying to cram gigs of data down your drives throat. But with VMs you are doing small scattered IO's, so the IO comes down, we prepare it, and farm it off to a thread and wait for that thread to wake up and submit the io. Then the io is completed and that is farmed off to another thread and we wait on that. This switching around and waiting for things to wake up is hugely painful when all you want to do is write a few bytes. If you were to do dd if=/dev/zero of=/mnt/btrfs/file bs=4k count=100 oflag=direct on a btrfs fs and then do it on an ext4 fs, you would see about a 20% difference between the 2. But if you do say bs=20M, the gap closes quite a bit. I fixed part of this problem for O_DIRECT (which is cache=none with qemu), if the IO's are small we don't send it off to a thread but submit it within our threads context, which is what got us with 20% of ext4 as opposed to 50%. The other half is doing the completion in the submitters context, which is going to take some extra work. I'm fixing this in the fsync case as well, but as I said we need a VFS patch to do it properly so that will be a little later coming. After that I can do the endio part of it and hopefully get us within spitting
Re: BTRFS: The Good, The Bad and The Ugly
2011/7/13 Josef Bacik jo...@toxicpanda.com On Wed, Jul 13, 2011 at 4:53 PM, Manuel Escudero jmlev...@gmail.com wrote: Today I'll be switching from BTRFS to Ext4 again because of the troubles I've been having with the New Linux Filesystem. As BTRFS is going to be the Default in F16 I wanted the developers to know what kind of troubles I've been experiencing with this FS in F15 so they can take a look at them in order to have a better F16 release: The Good: Since BTRFS arrived into my computer (Everything in the HDD is formated with BTRFS excluding /boot) I've seen a performance improvement in the data transfer part from and to the computer (copying files seem to be faster than before) But that's all about the good things I noticed... The Bad: BTRFS has reduced system's overall performance, at this point, sometimes it is OK, sometimes it is VERY BAD, I've noticed Performance Peaks in F15 with BTRFS and the Boot times are not nice: I mean, they are not the slowest ones, but they're not as good as Before in F14 with Ext4 instead of BTRFS. The performance Running/Launching apps has been afected too and now the PC freezes sometimes (that never happened in F14 unless I forced it a lot with 4 VM's to suck the 4GB of RAM I have); And Now it freezes very often when it wants without a lot of effort. The Ugly: Running VM's when having their virtual HDD's stored in a BTRFS partition is DEATH! They're very slow, sometimes they open, sometimes they not, usually they freeze, You can't work with them. Same thing about Gnome Shell working over a BTRFS partition: it is really slow, sometimes it reacts but most of the time is pretty unresponsive. Reading in the Web, I found that some users think that the BTRFS poor performance is caused by some special kind of fragmentation it suffers, others think it's because of it's CopyonWrite attributes and some others blame other stuff, God Knows! the only thing I know is that BTRFS is not ready for being used in normal production machines (as I tought) and it needs to be fixed before the release of F16, because it's performance is really far from good... Other Stuff I noticed is that with Kernel 2.6.38.8-35 the system seems to work better that with the previous one, just a little, but is some kind of improvement. Here you have all the info I found on the net about BTRFS Performance issues noticed by users: https://bugzilla.redhat.com/show_bug.cgi?id=689127 http://arosenfeld.wordpress.com/2010/12/27/back-to-ext4-from-btrfs/ http://www.vyatta4people.org/btrfs-is-a-bad-choice-when-running-kvm/ http://lkml.org/lkml/2010/7/13/475 http://blog.patshead.com/2011/03/btrfs---six-months-later.html I only have a question: Why Any Kind of VM is Sooo Slow when being stored on a BTRFS partition? Any Way to Solve this? or at least have a BTRFS performance improvement? Yeah VMs are a particular problem with Btrfs. There are a ton of reasons for this, for example by default we use fsync. Fsync _sucks_ for btrfs currently, and it has historically not been a well optimized piece of code. I'm working on fixing this, but it requires VFS level changes that are currently sitting in Al's queue. I suspect they will go into 3.1 and so we can move ahead with our work, but for now, it sucks. You can use cache=none you get better performance, but still not that great. And this is all because of one major thing Btrfs has threads for _everything_. This works out fantastically when you have big chunks of reads or writes you want done. This _sucks_ when you are doing little piddly io's. The reason for all of this is because we don't want you to get bottlenecked on us calculating/verifying checksums, so we farm all IO and endio out to different threads, which as I said works out great if you are trying to cram gigs of data down your drives throat. But with VMs you are doing small scattered IO's, so the IO comes down, we prepare it, and farm it off to a thread and wait for that thread to wake up and submit the io. Then the io is completed and that is farmed off to another thread and we wait on that. This switching around and waiting for things to wake up is hugely painful when all you want to do is write a few bytes. If you were to do dd if=/dev/zero of=/mnt/btrfs/file bs=4k count=100 oflag=direct on a btrfs fs and then do it on an ext4 fs, you would see about a 20% difference between the 2. But if you do say bs=20M, the gap closes quite a bit. I fixed part of this problem for O_DIRECT (which is cache=none with qemu), if the IO's are small we don't send it off to a thread but submit it within our threads context, which is what got us with 20% of ext4 as opposed to 50%. The other half is doing the completion in the submitters context, which is going to take some extra work. I'm fixing this in the fsync case as well, but as I said we need a VFS
Re: BTRFS: The Good, The Bad and The Ugly
On 07/13/2011 11:14 PM, Josef Bacik wrote: On Wed, Jul 13, 2011 at 4:53 PM, Manuel Escudero jmlev...@gmail.com wrote: Today I'll be switching from BTRFS to Ext4 again because of the troubles I've been having with the New Linux Filesystem. As BTRFS is going to be the Default in F16 I wanted the developers to know what kind of troubles I've been experiencing with this FS in F15 so they can take a look at them in order to have a better F16 release: The Good: Since BTRFS arrived into my computer (Everything in the HDD is formated with BTRFS excluding /boot) I've seen a performance improvement in the data transfer part from and to the computer (copying files seem to be faster than before) But that's all about the good things I noticed... The Bad: BTRFS has reduced system's overall performance, at this point, sometimes it is OK, sometimes it is VERY BAD, I've noticed Performance Peaks in F15 with BTRFS and the Boot times are not nice: I mean, they are not the slowest ones, but they're not as good as Before in F14 with Ext4 instead of BTRFS. The performance Running/Launching apps has been afected too and now the PC freezes sometimes (that never happened in F14 unless I forced it a lot with 4 VM's to suck the 4GB of RAM I have); And Now it freezes very often when it wants without a lot of effort. The Ugly: Running VM's when having their virtual HDD's stored in a BTRFS partition is DEATH! They're very slow, sometimes they open, sometimes they not, usually they freeze, You can't work with them. Same thing about Gnome Shell working over a BTRFS partition: it is really slow, sometimes it reacts but most of the time is pretty unresponsive. Reading in the Web, I found that some users think that the BTRFS poor performance is caused by some special kind of fragmentation it suffers, others think it's because of it's CopyonWrite attributes and some others blame other stuff, God Knows! the only thing I know is that BTRFS is not ready for being used in normal production machines (as I tought) and it needs to be fixed before the release of F16, because it's performance is really far from good... Other Stuff I noticed is that with Kernel 2.6.38.8-35 the system seems to work better that with the previous one, just a little, but is some kind of improvement. Here you have all the info I found on the net about BTRFS Performance issues noticed by users: https://bugzilla.redhat.com/show_bug.cgi?id=689127 http://arosenfeld.wordpress.com/2010/12/27/back-to-ext4-from-btrfs/ http://www.vyatta4people.org/btrfs-is-a-bad-choice-when-running-kvm/ http://lkml.org/lkml/2010/7/13/475 http://blog.patshead.com/2011/03/btrfs---six-months-later.html I only have a question: Why Any Kind of VM is Sooo Slow when being stored on a BTRFS partition? Any Way to Solve this? or at least have a BTRFS performance improvement? Yeah VMs are a particular problem with Btrfs. There are a ton of reasons for this, for example by default we use fsync. Fsync _sucks_ for btrfs currently, and it has historically not been a well optimized piece of code. I'm working on fixing this, but it requires VFS level changes that are currently sitting in Al's queue. I suspect they will go into 3.1 and so we can move ahead with our work, but for now, it sucks. You can use cache=none you get better performance, but still not that great. And this is all because of one major thing Btrfs has threads for _everything_. This works out fantastically when you have big chunks of reads or writes you want done. This _sucks_ when you are doing little piddly io's. The reason for all of this is because we don't want you to get bottlenecked on us calculating/verifying checksums, so we farm all IO and endio out to different threads, which as I said works out great if you are trying to cram gigs of data down your drives throat. But with VMs you are doing small scattered IO's, so the IO comes down, we prepare it, and farm it off to a thread and wait for that thread to wake up and submit the io. Then the io is completed and that is farmed off to another thread and we wait on that. This switching around and waiting for things to wake up is hugely painful when all you want to do is write a few bytes. If you were to do dd if=/dev/zero of=/mnt/btrfs/file bs=4k count=100 oflag=direct on a btrfs fs and then do it on an ext4 fs, you would see about a 20% difference between the 2. But if you do say bs=20M, the gap closes quite a bit. I fixed part of this problem for O_DIRECT (which is cache=none with qemu), if the IO's are small we don't send it off to a thread but submit it within our threads context, which is what got us with 20% of ext4 as opposed to 50%. The other half is doing the completion in the submitters context, which is going to take some extra work. I'm fixing this in the fsync case as well, but as I said we need a VFS patch to do it properly so that will be a little later coming.
Re: BTRFS: The Good, The Bad and The Ugly
Farkas Levente wrote: if you said that this's the current state of btrfs than it's not ready as a default fs for f16. so please postpone it at least to f17. If f16 gets kernel 3.1 (or backported stuff into 3.0), IMHO there is no reason to slip it one release. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS: The Good, The Bad and The Ugly
On Wed, Jul 13, 2011 at 16:54:44 -0500, Michael Cronenworth m...@cchtml.com wrote: Farkas Levente wrote: if you said that this's the current state of btrfs than it's not ready as a default fs for f16. so please postpone it at least to f17. If f16 gets kernel 3.1 (or backported stuff into 3.0), IMHO there is no reason to slip it one release. It's very likely that F16 will get 3.1. 3.2 probably won't be ready in time. 3.0 is likely going to be out within a week. 3.1 should be ready in plenty of time to be safe for F16. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS: The Good, The Bad and The Ugly
Am 13.07.2011 23:51, schrieb Farkas Levente: So there's my long ass explanation of why VMs on Btrfs suck. I'm sorry, I'm aware of the problem and I'm trying to fix it, but it's a slow going process. if you said that this's the current state of btrfs than it's not ready as a default fs for f16. so please postpone it at least to f17 +1 bleeeding edge / modern technology is not the same as dangerous defaults unstable / unfinsihed packages should never be default in GA nor replace existing and over a long time well working things - never! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS: The Good, The Bad and The Ugly
Am 13.07.2011 23:54, schrieb Michael Cronenworth: Farkas Levente wrote: if you said that this's the current state of btrfs than it's not ready as a default fs for f16. so please postpone it at least to f17. If f16 gets kernel 3.1 (or backported stuff into 3.0), IMHO there is no reason to slip it one release there are many reasons! replacing an essential part of the OS as filesystems are with finally not well tested piece of new software is simply a dangerous game with no benefit hopefully stable at release is my definition of untested the normal users have not enough knowledge to chagnge the defaults and they are primary for them and advanced users which konwig what they do can select it on install time signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v2] Retiring packages in F-16
On Wed, Jul 13, 2011 at 09:26:25AM -0700, Toshio Kuratomi wrote: On Wed, Jul 13, 2011 at 06:06:37PM +0800, Daniel Veillard wrote: On Tue, Jul 12, 2011 at 05:10:01PM -0400, Bill Nottingham wrote: Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 16. New this go-round is that we are also blocking packages that have failed to build since before Fedora 14. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. This list has been fixed to properly show all orphaned packages. It's a lot longer. [...] Orphan libcmpiutil comaintained by: veillard [...] Orphan libvirt-cim comaintained by: veillard I sent a mail to this very list one week ago: Date: Wed, 6 Jul 2011 09:07:57 +0800 From: Daniel Veillard veill...@redhat.com To: devel@lists.fedoraproject.org Subject: Taking ownership of libcmpiutil and libvirt-cim to avoid them being retired, never got an answer. At the time visiting https://admin.fedoraproject.org/pkgdb/acls/name/libcmpiutil didn't show any option to take ownership, was that a temporary failure, I'm sure I checked and was logged in, weird ... Sorta. These packages were orphaned due to the maintainer not signing the FPCA. When that script was run, I failed to properly set the status to Orphaned which left you unable to take ownership. Sorry for missing your earlier email about the problem and thanks for taking them now! Ah, okay, there is an explanation, I was a bit puzzled to not see the take ownership button though it was owned by orphan, I was thinking the feature wasn't available anymore. thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS: The Good, The Bad and The Ugly
On Wed, Jul 13, 2011 at 5:59 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 13.07.2011 23:54, schrieb Michael Cronenworth: Farkas Levente wrote: if you said that this's the current state of btrfs than it's not ready as a default fs for f16. so please postpone it at least to f17. If f16 gets kernel 3.1 (or backported stuff into 3.0), IMHO there is no reason to slip it one release there are many reasons! replacing an essential part of the OS as filesystems are with finally not well tested piece of new software is simply a dangerous game with no benefit hopefully stable at release is my definition of untested That's not the case at all, I'm not sure where you are getting that. If we don't have a released offline fsck by Alpha, which IIRC is the beginning of August we're not even going to make the switch. We aren't aiming for hopefully stable, we're aiming for actually stable and reasonably safe. If we don't meet certain basic requirements no switch will be made and everything will carry on as normal. I'm not trying to shove Btrfs down peoples throats. The last thing I want is to switch over to Btrfs before it's fully ready for everybody to be using it, which is why there are a bunch of requirements that need to be met before the switch is actually met. Thanks, Josef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS: The Good, The Bad and The Ugly
On 7/13/11 4:55 PM, Reindl Harald wrote: Am 13.07.2011 23:51, schrieb Farkas Levente: So there's my long ass explanation of why VMs on Btrfs suck. I'm sorry, I'm aware of the problem and I'm trying to fix it, but it's a slow going process. if you said that this's the current state of btrfs than it's not ready as a default fs for f16. so please postpone it at least to f17 +1 bleeeding edge / modern technology is not the same as dangerous defaults unstable / unfinsihed packages should never be default in GA nor replace existing and over a long time well working things - never! You might have said the same thing about ext4 in Fwhatever it was and yet, here we are, shipping it as default for many releases now, with little trouble. Not every big change to Fedora breaks badly, although I can see how some might get that impression. ;) -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Askbot status update and a call for help
Hi As discussed in this list earlier, I along with several others (see wiki page for details) have been working on packaging Askbot (http://askbot.org) and its dependencies for Fedora (and EPEL). Askbot is a question and answer oriented forum along the lines of Stack Overflow and I would like to see a instance of it hosted and run within the Fedora infrastructure. You can find more detailed information about this at https://fedoraproject.org/wiki/Askbot You can help by testing it and providing feedback. We have made good progress by reviewing and approving several dependencies and building them for both Fedora and EPEL 6. Askbot is written in Django and Python. To provide a good experience and integration with Fedora, we would like to add several new features to it. For instance, PJP has already added support for logging in using the Fedora account system id (upstream made authentication extensible to support us) and we are planning on adding support for logging using identi.ca and quickly posting a question link to identi.ca (support for Twitter already exists upstream). There are several more features I would like to see added. The primary upstream developer is quite receptive and has already added some features and fixed bugs we pointed out. So if you are familiar with Django and Python, do let me know. Many of these features are fairly easy to add. I am available in #fedora-devel and #fedora-india as mether or you can also drop me a mail offlist. Upstream source is at https://github.com/ASKBOT/askbot-devel/ Also Askbot can be installed via pip or easy_install and a test repository for RHEL 6 (and rebuilds) is at http://repos.fedorapeople.org/repos/pjp/askbot/ Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS: The Good, The Bad and The Ugly
2011/7/13 Eric Sandeen sand...@redhat.com On 7/13/11 4:55 PM, Reindl Harald wrote: Am 13.07.2011 23:51, schrieb Farkas Levente: So there's my long ass explanation of why VMs on Btrfs suck. I'm sorry, I'm aware of the problem and I'm trying to fix it, but it's a slow going process. if you said that this's the current state of btrfs than it's not ready as a default fs for f16. so please postpone it at least to f17 +1 bleeeding edge / modern technology is not the same as dangerous defaults unstable / unfinsihed packages should never be default in GA nor replace existing and over a long time well working things - never! You might have said the same thing about ext4 in Fwhatever it was and yet, here we are, shipping it as default for many releases now, with little trouble. Not every big change to Fedora breaks badly, although I can see how some might get that impression. ;) -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Josef Couldn't say it better: Let's not be dramatic... I'm pretty sure Fedora Developers are not going to make the Switch to BTRFS in F16 if it's not ready, that's why I sen't my feedback and little investigation, in order to help them track down the issues before anything gets released, that's why we work as community and I'm pretty sure that everything is gonna be Okey. P.S. Now I'm in ext4, almost finished reinstalling my system ;) -- Manuel Escudero Linux User #509052 Twitter: @Jmlevick http://twitter.com/Jmlevick Blogger: Blog Xenode http://xenodesystems.blogspot.com/ PGP/GnuPG: E2F5 12FA E1C3 FA58 CF15 8481 B77B 00CA C1E1 0FA7 Xenode Systems - xenodesystems.com http://www.xenodesystems.com/ - Conéctate a Tu Mundo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New feature for Fedora 16: new mkdumprd
On Wed, Jul 13, 2011 at 9:52 PM, Tomasz Torcz to...@pipebreaker.pl wrote: On Wed, Jul 13, 2011 at 03:50:07PM +0200, Tomasz Torcz wrote: Would any of you kindly help to review my proposed feature for Fedora 16? https://fedoraproject.org/wiki/Features/NewMkdumprd Feature proposal dealing was yesterday? deadline, of course. Am I too late? I made the page before the deadline, just sent it out a little late. :-/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Status of startup-notifications
Hi, I recently found that startup-notification is quite old in fedora and filed a bug to update to the recent upstream version. [1] So far I didn't get any feedback and would like to ask if someone of those [2] who also have commit on this package could update it or explain what the reason for this old version is. Thanks Johannes [1] https://bugzilla.redhat.com/show_bug.cgi?id=718501 [2] https://admin.fedoraproject.org/pkgdb/acls/name/startup-notification -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Unicode-Casing-0.07.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Unicode-Casing: 335647cf4a966f86f0ee6e8f2bc4ab13 Unicode-Casing-0.07.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 Sys-Virt-0.9.3.tar.gz uploaded to lookaside cache by berrange
A file has been added to the lookaside cache for perl-Sys-Virt: 2a9eef6c9ee8f73b26cd5fb78a18d391 Sys-Virt-0.9.3.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-Sys-Virt] Update to 0.9.3 release
commit a47da9915e25eb82fa08613188ee6fc22867f5ed
Author: Daniel P. Berrange berra...@redhat.com
Date: Wed Jul 13 10:32:40 2011 +0100
Update to 0.9.3 release
perl-Sys-Virt.spec |7 +--
sources|2 +-
2 files changed, 6 insertions(+), 3 deletions(-)
---
diff --git a/perl-Sys-Virt.spec b/perl-Sys-Virt.spec
index 25cd23a..ac4cb11 100644
--- a/perl-Sys-Virt.spec
+++ b/perl-Sys-Virt.spec
@@ -1,5 +1,5 @@
Name: perl-Sys-Virt
-Version:0.9.2
+Version:0.9.3
Release:1%{?dist}
Summary:Represent and manage a libvirt hypervisor connection
License:GPLv2+ or Artistic
@@ -11,7 +11,7 @@ BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
BuildRequires: perl(XML::XPath)
-BuildRequires: libvirt-devel = 0.9.2
+BuildRequires: libvirt-devel = 0.9.3
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
@@ -55,6 +55,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Jul 12 2011 Daniel P. Berrange berra...@redhat.com - 0.9.3-1
+- Update to 0.9.3 release
+
* Fri Jul 8 2011 Daniel P. Berrange berra...@redhat.com - 0.9.2-1
- Update to 0.9.2 release
diff --git a/sources b/sources
index 5100e2e..864fdbc 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-7dbf47975e43a6debce21ca8034fa0ab Sys-Virt-0.9.2.tar.gz
+2a9eef6c9ee8f73b26cd5fb78a18d391 Sys-Virt-0.9.3.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 Term-Animation-2.6.tar.gz uploaded to lookaside cache by lbazan
A file has been added to the lookaside cache for perl-Term-Animation: d22643b339495cfc0a4f0b405dbae1d1 Term-Animation-2.6.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-Pod-Eventual] drop circular Pod::Coverage::TrustPod buildreq
commit f4bcffec4ed2f637694d8fd47f36b4caa7314d0c
Author: Iain Arnell iarn...@gmail.com
Date: Wed Jul 13 17:16:46 2011 +0200
drop circular Pod::Coverage::TrustPod buildreq
perl-Pod-Eventual.spec | 13 +
1 files changed, 9 insertions(+), 4 deletions(-)
---
diff --git a/perl-Pod-Eventual.spec b/perl-Pod-Eventual.spec
index cb528c8..c86c7dc 100644
--- a/perl-Pod-Eventual.spec
+++ b/perl-Pod-Eventual.spec
@@ -1,6 +1,6 @@
Name: perl-Pod-Eventual
Version:0.093330
-Release:5%{?dist}
+Release:6%{?dist}
Summary:Read a POD document as a series of trivial events
License:GPL+ or Artistic
Group: Development/Libraries
@@ -13,8 +13,9 @@ BuildRequires: perl(Mixin::Linewise::Readers) = 0.001
BuildRequires: perl(Test::Deep)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
-BuildRequires: perl(Test::Pod::Coverage)
-BuildRequires: perl(Pod::Coverage::TrustPod)
+#BuildRequires: perl(Test::Pod::Coverage)
+# causes circular builddeps
+#BuildRequires: perl(Pod::Coverage::TrustPod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
@@ -54,7 +55,7 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
-RELEASE_TESTING=1 make test
+make test
%clean
rm -rf $RPM_BUILD_ROOT
@@ -66,6 +67,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Jul 13 2011 Iain Arnell iarn...@gmail.com 0.093330-6
+- drop circular Pod::Coverage::TrustPod buildreq
+- don't run release tests
+
* Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.093330-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Term-Animation/f15] perl-Term-Animation
Summary of changes: 1ff33e7... perl-Term-Animation (*) (*) 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-Catalyst-Plugin-Session] drop circular build deps
commit e046513ecef896ddc6cd430f3ee2506be582dfaa
Author: Iain Arnell iarn...@gmail.com
Date: Wed Jul 13 18:02:27 2011 +0200
drop circular build deps
perl-Catalyst-Plugin-Session.spec | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/perl-Catalyst-Plugin-Session.spec
b/perl-Catalyst-Plugin-Session.spec
index ca5188a..903a5bf 100644
--- a/perl-Catalyst-Plugin-Session.spec
+++ b/perl-Catalyst-Plugin-Session.spec
@@ -1,7 +1,7 @@
Name: perl-Catalyst-Plugin-Session
Summary:Catalyst generic session plugin
Version:0.31
-Release:1%{?dist}
+Release:2%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/B/BO/BOBTFISH/Catalyst-Plugin-Session-%{version}.tar.gz
@@ -10,7 +10,6 @@ Requires: perl(:MODULE_COMPAT_%(eval `%{__perl}
-V:version`; echo $versi
BuildArch: noarch
BuildRequires: perl(Catalyst::Runtime) = 5.71001
-BuildRequires: perl(Catalyst::Plugin::Session::State::Cookie) = 0.03
BuildRequires: perl(Digest)
BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
BuildRequires: perl(File::Spec)
@@ -24,8 +23,10 @@ BuildRequires: perl(Test::Deep)
BuildRequires: perl(Test::Exception)
BuildRequires: perl(Test::More) = 0.88
BuildRequires: perl(Test::Pod)
-BuildRequires: perl(Test::WWW::Mechanize::Catalyst) = 0.51
BuildRequires: perl(Tie::RefHash) = 1.34
+# these cause circular builddeps
+#BuildRequires: perl(Catalyst::Plugin::Session::State::Cookie) = 0.03
+#BuildRequires: perl(Test::WWW::Mechanize::Catalyst) = 0.51
Requires: perl(Catalyst::Runtime) = 5.71001
Requires: perl(Digest)
@@ -81,6 +82,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Jul 13 2011 Iain Arnell iarn...@gmail.com 0.31-2
+- drop additional BRs again - they cause circular build deps
+
* Sun Mar 13 2011 Iain Arnell iarn...@gmail.com 0.31-1
- update to latest upstream version
- clean up spec for modern rpmbuild
--
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
[dspam/el5] (18 commits) ...Merge branch 'el6' into el5
Summary of changes: a1d1ee3... inital F-12 import (*) d9fa18f... updated dspam cron file (*) 33e7cf3... fixed initscript ordering bug (*) 42bd353... Initialize branch EL-6 for dspam (*) 4c6472b... data dir permissions (*) db043f1... dist-git conversion (*) 82a2e8d... Merge remote branch 'origin/master' into el6/master (*) 45fc273... Merge remote branch 'origin/master' into el6/master (*) 0ebdcd2... Merge remote branch 'origin/master' into el6/master (*) cdc77fe... Merge remote branch 'origin/master' into el6/master (*) 34dccaa... Merge remote-tracking branch 'origin/master' into el6 (*) 6b8829c... Merge remote-tracking branch 'origin/master' into el6 (*) d28a6b7... remove configure patch since bash is fixed (*) 345c5db... rebuilt for libmysqlclient soname bump (*) 18bcc05... added tmpfiles rpath fix (*) 9424dcf... start as dspam user (*) 3327938... Merge branch 'f15' into el6 (*) dcc8ee4... Merge branch 'el6' into el5 (*) 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
[dspam/el5: 18/18] Merge branch 'el6' into el5
commit dcc8ee4e7652dbe391274e627a50fc6eff8f6da7 Merge: 86ab539 3327938 Author: Nathanael D. Noblet nathan...@gnat.ca Date: Wed Jul 13 13:31:31 2011 -0600 Merge branch 'el6' into el5 dspam-3.9.0-configure.patch | 194 --- dspam-init.d| 13 ++-- dspam-sysconfig |3 +- dspam-tmpfiles |1 + dspam.spec | 30 ++-- 5 files changed, 33 insertions(+), 208 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
[dspam] start as dspam user
Summary of changes: 9424dcf... start as dspam user (*) (*) 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
[dspam] Initial systemd unit file
commit 0e480f7f6823905354bc4b4a56f2152d39718f8f
Author: Nathanael D. Noblet nathan...@gnat.ca
Date: Wed Jul 13 14:48:56 2011 -0600
Initial systemd unit file
dspam-systemd | 11 +++
dspam.spec| 39 +++
2 files changed, 34 insertions(+), 16 deletions(-)
---
diff --git a/dspam-systemd b/dspam-systemd
new file mode 100644
index 000..66d14ea
--- /dev/null
+++ b/dspam-systemd
@@ -0,0 +1,11 @@
+[Unit]
+Description=A highly accurate statistical spam filter minimal resources
+
+[Service]
+Type=Forking
+EnvironmentFile=-/etc/sysconfig/dspam
+User=${DSPAM_USER}
+ExecStart=${DSPAM_BIN} --daemon 2/dev/null
+
+[Install]
+WantedBy=multi-user.target
\ No newline at end of file
diff --git a/dspam.spec b/dspam.spec
index 327195e..3970b09 100644
--- a/dspam.spec
+++ b/dspam.spec
@@ -11,7 +11,7 @@
Summary:A library and Mail Delivery Agent for Bayesian SPAM
filtering
Name: dspam
Version:3.9.0
-Release:21%{?dist}
+Release:22%{?dist}
License:GPLv2
Group: System Environment/Daemons
Source0:
http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
@@ -22,6 +22,7 @@ Source4:dspam-web.conf
Source5:dspam-front
Source6:dspam-sysconfig
Source7: dspam-tmpfiles
+Source8: dspam-systemd
Source99: dspam-filter-requires.sh
Patch0: dspam-3.9.0-file-name.patch
Patch1: dspam-3.9.0-docs.patch
@@ -36,11 +37,10 @@ BuildRequires: mysql-devel
BuildRequires: postgresql-devel
BuildRequires: sqlite-devel
BuildRequires: openldap-devel
+BuildRequires: systemd-units
Requires: dspam-libs = %{version}-%{release}
-Requires(post): chkconfig
-Requires(preun):chkconfig
-Requires(preun):initscripts
+Requires(post):systemd-sysv
%description
The DSPAM agent masquerades as the email server's local delivery agent
@@ -127,7 +127,6 @@ Summary:Web-based interface for DSPAM
Group: System Environment/Daemons
Requires: dspam = %{version}-%{release}
Requires: webserver
-Requires(post): initscripts
%description web
Web-based interface for DSPAM's powerful Anti-Spam engine.
@@ -218,8 +217,8 @@ find $RPM_BUILD_ROOT -name *.a -exec rm {} \;
echo Scanned and tagged as SPAM with DSPAM %{version} by Your ISP.com
$RPM_BUILD_ROOT%{dspam_homedir}/txt/msgtag.spam
echo Scanned and tagged as non-SPAM with DSPAM %{version} by Your ISP.com
$RPM_BUILD_ROOT%{dspam_homedir}/txt/msgtag.nonspam
-# install init.d script
-%{__install} -Dp -m0755 %{SOURCE1} $RPM_BUILD_ROOT%{_initrddir}/dspam
+# install systemd script
+%{__install} -Dp -m0644 %{SOURCE8} $RPM_BUILD_ROOT%{_unitdir}/dspam.service
# install cron script
%{__install} -Dp -m0755 %{SOURCE2}
$RPM_BUILD_ROOT%{_sysconfdir}/cron.daily/dspam
@@ -263,21 +262,26 @@ do
done
%{__install} -Dp -m 0644 %{SOURCE4} $RPM_BUILD_ROOT%{_sysconfdir}/httpd/conf.d/
+[...]
%post
-/sbin/chkconfig --add %{name}
-if [ $1 -gt 1 ]; then
-/sbin/chkconfig %{name} resetpriorities
+if [ $1 -eq 1 ] ; then
+# Initial installation
+/bin/systemctl daemon-reload /dev/null 21 || :
fi
%preun
-if [ $1 -eq 0 ]; then
-/sbin/service %{name} stop /dev/null || :
-/sbin/chkconfig --del %{name}
+if [ $1 -eq 0 ] ; then
+# Package removal, not upgrade
+/bin/systemctl --no-reload disable dspam.service /dev/null 21 || :
+/bin/systemctl stop dspam.service /dev/null 21 || :
fi
%postun
-if [ $1 -ge 1 ]; then
-/sbin/service %{name} condrestart /dev/null || :
+/bin/systemctl daemon-reload /dev/null 21 || :
+if [ $1 -ge 1 ] ; then
+ /sbin/chkconfig --del httpd /dev/null 21 || :
+# Package upgrade, not uninstall
+/bin/systemctl try-restart dspam.service /dev/null 21 || :
fi
%pre libs
@@ -309,7 +313,7 @@ exit 0
%config(noreplace) %{_sysconfdir}/logrotate.d/dspam
%attr(0640,root,%{mail_group}) %config(noreplace) %{dspam_confdir}/dspam.conf
%attr(0644,root,%{mail_group}) %config(noreplace)
%{dspam_confdir}/dspam.conf.default
-%{_initrddir}/dspam
+%{_unitdir}/dspam.service
%{_mandir}/man1/*
%attr(%{dspam_mode},%{dspam_user},%{mail_group}) %{_bindir}/dspam
%{_bindir}/dspam_2sql
@@ -376,6 +380,9 @@ exit 0
%config(noreplace) %{_sysconfdir}/httpd/conf.d/dspam-web.conf
%changelog
+* Wed Jul 13 2011 Nathanael Noblet nathan...@gnat.ca - 3.9.0-22
+- Systemd unit file
+
* Wed Jul 13 2011 Nathanael Noblet nathan...@gnat.ca - 3.9.0-21
- Start daemon as dspam user
--
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
[dspam] copy/paste typo
commit 11665256e10f4bda8a53724217f84ae1f534ffa1
Author: Nathanael D. Noblet nathan...@gnat.ca
Date: Wed Jul 13 14:58:52 2011 -0600
copy/paste typo
dspam.spec |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
---
diff --git a/dspam.spec b/dspam.spec
index 3970b09..7f20636 100644
--- a/dspam.spec
+++ b/dspam.spec
@@ -262,7 +262,6 @@ do
done
%{__install} -Dp -m 0644 %{SOURCE4} $RPM_BUILD_ROOT%{_sysconfdir}/httpd/conf.d/
-[...]
%post
if [ $1 -eq 1 ] ; then
# Initial installation
--
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-YAML-Tiny] drop Test::MinimumVersion BR to avoid circular build deps
commit 211230db2eebf1852fb052b61ac3c8e97e8f13fc
Author: Iain Arnell iarn...@gmail.com
Date: Thu Jul 14 05:12:31 2011 +0200
drop Test::MinimumVersion BR to avoid circular build deps
perl-YAML-Tiny.spec |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
---
diff --git a/perl-YAML-Tiny.spec b/perl-YAML-Tiny.spec
index a93a2a1..0a6f7dc 100644
--- a/perl-YAML-Tiny.spec
+++ b/perl-YAML-Tiny.spec
@@ -1,6 +1,6 @@
Name: perl-YAML-Tiny
Version:1.50
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Read/Write YAML files with as little code as possible
License:GPL+ or Artistic
Group: Development/Libraries
@@ -11,7 +11,6 @@ BuildRequires: perl(Exporter)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Spec) = 0.80
BuildRequires: perl(Scalar::Util)
-BuildRequires: perl(Test::MinimumVersion)
BuildRequires: perl(Test::More) = 0.47
BuildRequires: perl(Test::Pod)
BuildRequires: perl(YAML)
@@ -49,6 +48,9 @@ make test AUTOMATED_TESTING=1
%{_mandir}/man3/*
%changelog
+* Thu Jul 14 2011 Iain Arnell iarn...@gmail.com 1.50-2
+- drop Test::MinimumVersion BR to avoid circular build deps
+
* Mon Jun 27 2011 Petr Sabata con...@redhat.com - 1.50-1
- 1.50 bump
- Cleaning the spec file (I assume pre-EPEL6 compatibility is no longer
--
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
