Re: MariaDB and Fedora
Hi On 12/14/2009 04:56 AM, Nathanael Noblet wrote: As a DBA / Developer, I second this... obviously I can't complain because they are both free. However the setup/configuration of postgreSQL compared to MySQL is basically something easy, versus something where I don't have a clue what is going on, and there are million ways to do it, and when I'm done I have no idea if I'm wide open to the entire world, or as secure as on MySQL. There are a few other odd bits too, I mean I really don't get the purpose of copying template1, what is that? etc etc etc... MySQL is just more intuitive. I agree on that, and a "major" problem with PostgreSQL at the moment is that it doesn't have a clustering engine. So MySQL is still the simplest choice out there for the end user. Steven -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: cpqarrayd for fedora 11 and 12
Hi, On 08/28/2009 09:13 AM, Howard Wilkinson wrote: Is it really true that nobody else uses cpqarrayd? If so what do people use to monitor the HP/Compaq hardware in the Proliant range of servers? I'm using http://sourceforge.net/projects/cciss/files/cciss_vol_status/ for that purpose, with a cron job that checks it and sends a mail in case of a problem. Note: take the CVS version for support of the latest controllers, I had a little mail exchange with an HP guy: You can get the CVS version this way: scame...@zuul:~/testit$ export CVSROOT=:pserver:anonym...@cciss.cvs.sourceforge.net:/cvsroot/cciss scame...@zuul:~/testit$ cvs login (just hit return when it asks for a password) scame...@zuul:~/testit$ cvs co cciss_vol_status I suppose it's about time I made a new release of cciss_vol_status. Steven -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Requires question in SPEC
On 08/11/2009 10:15 AM, Jaroslav Reznik wrote: On Tuesday 11 August 2009 10:02:23 Steven Moix wrote: Hello all, I'm facing a problem with one of my SPEC files...I'm packaging a program (motion, in RPM Fusion) that has a startup script. In the start() section of this startup script, I have added an "LD_PRELOAD=/usr/lib64/libv4l/v4l2convert.so daemon $motion" to support more cameras. You can patch your package to use libv4l directly. Usually it's easy - there are some issues but... Check some packages using v4l to check what you have to do to port it. I talked to the upstream devs, and they will (probably) do that in the future, but right now I think that I'm going to let rpmlint complain and simply comment my spec file. Also check this blogpost by Hans de Goede (libv4l author) [1]. [1] http://hansdegoede.livejournal.com/3636.html That's where the feature request came from initially, https://bugzilla.rpmfusion.org/show_bug.cgi?id=681 Steven -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Requires question in SPEC
Hello all, I'm facing a problem with one of my SPEC files...I'm packaging a program (motion, in RPM Fusion) that has a startup script. In the start() section of this startup script, I have added an "LD_PRELOAD=/usr/lib64/libv4l/v4l2convert.so daemon $motion" to support more cameras. So I naturally added a "Requires: libv4l" in my SPEC file, but of course rpmlint complains with "E: explicit-lib-dependency libv4l". The problem here is that I can't see how RPM could automatically add libv4l as a dependency when I build the package...it's not in the code, only a call in the startup script. So... * Should I consider that libv4l is installed by default on F10/11 and not put the require. * Put the require and let rpmlint complain. Any advice on that? Note that if you launch the startup script on a system that doesn't have libv4l, it simply doesn't do the LD_PRELOAD, but still works "as usual". Thanks Steven -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On 06/17/2009 11:39 PM, Luya Tshimbalanga wrote: On 06/17/2009 10:52 AM, Bill Nottingham wrote: Given the loud feedback, I've updated the proposal at: https://fedoraproject.org/wiki/Features/F12X86Support The revised proposal: - Build all packages for i686 (this requires cmov) - Optimize for Atom Why? - We don't really support i586 in any meaningful matter - OLPC still works with base i686 - We are likely doing a mass rebuild for F-12 anyways, might as well switch while we're doing it - Atom is the only currently produced 32-bit x86 chip of note; optimize for what's currently available What about Pentium M family aka Centrino? The Pentium M chips are powerful enough not to care too much about 1-2% optimizations IMO, Atom is another story. Steven -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On 06/17/2009 07:52 PM, Bill Nottingham wrote: Given the loud feedback, I've updated the proposal at: https://fedoraproject.org/wiki/Features/F12X86Support The revised proposal: - Build all packages for i686 (this requires cmov) - Optimize for Atom Why? - We don't really support i586 in any meaningful matter - OLPC still works with base i686 - We are likely doing a mass rebuild for F-12 anyways, might as well switch while we're doing it - Atom is the only currently produced 32-bit x86 chip of note; optimize for what's currently available If you want numbers, I did some benchmarking of code [1] with various build options on a variety of processors, with the F-11 gcc code. All of these results are relative to a F-11 baseline of "-march=i586 -mtune=generic". P4 2.4Ghz Athlon 3400+Core2Duo E6850 Atom N270 march=i686/ -1.1% +2.0% +0.9% +0.6% mtune=generic march=i586/ +0.3% -0.3% -0.2% +1.3% mtune=atom march=i686/ -1.5% +1.2% +0.5% +1.7% mtune=atom Bill [1] gzip, bzip2, math simulation, mp3 encode/decode, ogg encode/decode This sounds a perfectly fine and sensible solution to me, thanks for taking the feedback into account :) Steven -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
On 06/15/2009 07:53 PM, Bill Nottingham wrote: Way back when in February [1], FESCo decided that for Fedora 11, i586 would be the default architecture, and for Fedora 12, it would be some variant of i686. It's time to follow through on that action item. ... I'm in favour of keeping i586 or i686 without SSE for x86 systems. As many people pointed out, users with these systems don't expect huge performance improvements; you should go to x86-64 for that. So in my opinion it's not worth killing the huge PIII/Athlon system base for a small performance gain. I'm not counting the public reaction, marketing-wise, if we do this (yes, this also counts). I'm against having i586 and i686+SSE2 as as secondary arch for management reasons, they are too close and would probably generate too much work for nothing. Steven -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
