Re: MariaDB and Fedora

2009-12-14 Thread Steven Moix

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

2009-08-29 Thread Steven Moix

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

2009-08-11 Thread Steven Moix

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

2009-08-11 Thread Steven Moix

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)

2009-06-17 Thread Steven Moix

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)

2009-06-17 Thread Steven Moix

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

2009-06-17 Thread Steven Moix

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