> yes, perhaps the english language is alien to you - the
> word 'testing' means something, there is a reason why
> those packages are there in 'testing' - people who
> dont know what they are doing are recommended to
> NOT use them.
Karanbir, I've always 'appreciated' you being such a 'nice'
person and giving so 'detailed insights' on this list, that
I'm so tempted to give a politically-incorrect reply...
Otherwise, I am using CentOS *despite* you being a member
of the team. (Not that anyone would care.)
OTOH, it's such an accomplishment to have *all* the packages
in "testing" since 2007 and none of them passing the QA
requirements...
R-C
__________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!
http://www.flickr.com/gift/
Send CentOS-announce mailing list submissions to
centos-announce(a)centos.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-request(a)centos.org
You can reach the person managing the list at
centos-announce-owner(a)centos.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."
Today's Topics:
1. CEBA-2009:1133 CentOS 5 i386 kernel Update (Karanbir Singh)
2. CEBA-2009:1133 CentOS 5 x86_64 kernel Update (Karanbir Singh)
----------------------------------------------------------------------
Message: 1
Date: Tue, 30 Jun 2009 15:08:31 +0000
From: Karanbir Singh <kbsingh(a)centos.org>
Subject: [CentOS-announce] CEBA-2009:1133 CentOS 5 i386 kernel Update
To: centos-announce(a)centos.org
Message-ID: <20090630150831.GA2275(a)tantra.karan.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Bugfix Advisory 2009:1133
Upstream details at : https://rhn.redhat.com/errata/RHBA-2009-1133.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( md5sum Filename )
i386:
74757a235fe8d3f13251204b870137d6 kernel-2.6.18-128.1.16.el5.i686.rpm
2824473a0757040cf38dd4b9267d2533 kernel-debug-2.6.18-128.1.16.el5.i686.rpm
574bbbfd8e71050030e06f0a19d43ea5 kernel-debug-devel-2.6.18-128.1.16.el5.i686.rpm
2f9e5fbf7a54f30752709c53bae0bff0 kernel-devel-2.6.18-128.1.16.el5.i686.rpm
fa9b81fa95b62a281dc5d5a2a5ff1323 kernel-doc-2.6.18-128.1.16.el5.noarch.rpm
a5c8caf879bed9fb53d59bb5257c8d7c kernel-headers-2.6.18-128.1.16.el5.i386.rpm
6bc06713f58b3c3c1a98612b24a16a9b kernel-PAE-2.6.18-128.1.16.el5.i686.rpm
a0a2bd2a14f7e93cf1049e5c451fae5e kernel-PAE-devel-2.6.18-128.1.16.el5.i686.rpm
71b227106dd44bb6abfe5993af653442 kernel-xen-2.6.18-128.1.16.el5.i686.rpm
4ed28b0d65a754f4379aa07facf00d92 kernel-xen-devel-2.6.18-128.1.16.el5.i686.rpm
Source:
74a14ed1df21b2b039c9f49e8ff25023 kernel-2.6.18-128.1.16.el5.src.rpm
--
Karanbir Singh
CentOS Project { http://www.centos.org/ }
irc: z00dax, #centos(a)irc.freenode.net
------------------------------
Message: 2
Date: Tue, 30 Jun 2009 15:08:32 +0000
From: Karanbir Singh <kbsingh(a)centos.org>
Subject: [CentOS-announce] CEBA-2009:1133 CentOS 5 x86_64 kernel
Update
To: centos-announce(a)centos.org
Message-ID: <20090630150832.GA2290(a)tantra.karan.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Bugfix Advisory 2009:1133
Upstream details at : https://rhn.redhat.com/errata/RHBA-2009-1133.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( md5sum Filename )
x86_64:
fe9be7aabc871d26ad8cdedd47df01f3 kernel-2.6.18-128.1.16.el5.x86_64.rpm
db148cb2a953679cbe7ac6af1b46bf45 kernel-debug-2.6.18-128.1.16.el5.x86_64.rpm
122d1913dcdcdc8ea24b40a9a3a8d128 kernel-debug-devel-2.6.18-128.1.16.el5.x86_64.rpm
dd017dcee8bcfb6e454779619db46907 kernel-devel-2.6.18-128.1.16.el5.x86_64.rpm
a22b4103b441a7c122205b07e2681ee1 kernel-doc-2.6.18-128.1.16.el5.noarch.rpm
5570c187ca4206d58a6ce15162b23873 kernel-headers-2.6.18-128.1.16.el5.x86_64.rpm
7993d19667fe92b1799157d1c7b1b000 kernel-xen-2.6.18-128.1.16.el5.x86_64.rpm
5ab996bb8244ffc1284d39d4f9ab3da2 kernel-xen-devel-2.6.18-128.1.16.el5.x86_64.rpm
Source:
74a14ed1df21b2b039c9f49e8ff25023 kernel-2.6.18-128.1.16.el5.src.rpm
--
Karanbir Singh
CentOS Project { http://www.centos.org/ }
irc: z00dax, #centos(a)irc.freenode.net
------------------------------
_______________________________________________
CentOS-announce mailing list
CentOS-announce(a)centos.org
http://lists.centos.org/mailman/listinfo/centos-announce
End of CentOS-announce Digest, Vol 52, Issue 13
***********************************************
Sorin Srbu wrote:
>> -----Original Message-----
>> From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] On
>>
> Behalf
>
>> Of Lucian(a)lastdot.org
>> Sent: Tuesday, June 30, 2009 9:24 AM
>> To: CentOS mailing list
>> Subject: Re: [CentOS] Web photo gallery options
>>
>> jalbum is a hog with large collections.. performance must be 5-6x less
>> than that of picasa on my computer (amd athlon x2, 1 gb ram, sata
>> drive, centos 5 32bit, around 8000 hires pictures)..
>>
>
> That bad?? Guess my Amd Duron/750 and 384MB ram is a no-go then...
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> CentOS mailing list
> CentOS(a)centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
I've been rather happy with Jalbum, mostly because of the wide range of
capabilities. By default, it creates the album on your system...you can
upload to their servers or your own, at your discretion. While picassa
is certainly an answer, and one I use on occassion, I'm far happier
using my own server(s) or hosting locally on my workstaion than relying
solely on google's cloud (rock solid though it is...no negative
connotation about google intended).
You also get what you want out of it...if it's a 'hog', consider if
you're linking from thumbs to mid-size display and from *that* to
original hi-res. That's my basic setup and I haven't had a problem with
resources on my local workstation (1gb ram, 2,4mhz intel, 0.5TB drive,
albums of 5K pictures or more, centos 5.3 32bit) or on my servers.
YMMV,
-R
> He wants me to do some things for him for free
> (unfortunately I am a freelancer and not a millionaire).
Not for *me*!!!
It's only a matter of perception. I normally don't like
when a SRPM doesn't build, and I believe that until it's
fixed, it should either be removed (alongside with the
corresponing RPMs), or be moved to a "testing" section.
That's all.
But this also means that helping to fix some issues in
such a huge repo is frightening, and as long as it won't
fix the RF<->EPEL incompatibility, I won't see the motivation!
As Dag noted, those 4 newer libs in EPEL that break VLC and MPlayer
(so my repo ugly fixes the issue for *me* and for whoever likes
to use those repos the way *I* do it) are not an easy issue:
should anyone want to rebuild everything in RPMforge that depends on
them, most likely some packages wouldn't build at all!
So: RF can't be "fixed", EPEL can't be "fixed". To avoid the annoyance
of protecting packages and whatnot, I've put in *my* repo Dag's older
libs with versions higher than whatever is now in EPEL, so that EPEL won't
break Dag's VLC and MPlayer. Oh, maybe this breaks some other multimedia
apps from EPEL, but I am not using EPEL for multimedia, so I don't care.
Maybe I am stuck with my ideas, and maybe I should be thinking
"outside of the box". OK, but I also know that "outside of the box
be dragons", so I just won't go outside of the box ;-)
R-C
__________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!
http://www.flickr.com/gift/
> Firefox was better than Mozilla.Â
Nay. Only Firefox 0.9 was better than Mozilla.
Later on, bloatware won.
> It's definitely worth noting that, Epiphany &
> Firefox popped up so quickly because they built on
> Mozilla's rendering, etc.
Yes, it's easier to add bloatware on a solid open-sourced
base...
> Things get pushed in the kernel, Xorg, etc. for a good
> reason, even if we fail to see it.
Hopefully, there is Someone up there who sees it. Then
He will come for a second time to bring salvation to us.
Hopefully, there is no HAL, no UDEV, no PulseAudio in
either heaven or hell.
> Well, you just said a few lines up that enough maintainers
> are proven to keep up even 3x this size. Not to
> mention the (PLD, I think) examples someone else brought
> in the thread.
I can't tell of PLD, as I have never used it.
Next time someone will tell of Arch etc. etc.
Not the right approach IMHO.
Cheers,
R-C
__________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!
http://www.flickr.com/gift/
> How many employees does Canonical have? AFAIK, it all
> started with a group of 30 odd Debian developers.
Yes, but when they started, they mainly rebuilt the upstream
(Debian) packages, right?
> Compare this with the russian ALT Linux distribution:
> 150 paid full time developers only to maintain the distro.
I'm not buying this number. It's too big. Compare to
Pardus, which also employs a number of paid developers,
it's more popular than ALT, and it still has less paid devs.
But maybe they are employing 150, what do I know...
> As for Red Hat, according to recent news, they're moving
> from 2.000 to approximately 2.800 employees.
And they still refuse to add even 10 or 20 packages to EL,
even as a "technology preview" (which is unsupported, AFAIR).
Cheers,
R-C
__________________________________________________________________
Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
Some how I have changed something such that the command line:
gconftool-2 -t string --set /desktop/gnome/background/picture_filename
/usr/share/backgrounds/images/other.jpg
does not change my background any longer.
Has someone come across this before?
How can I change gnome back to ALL default settings?
Jerry
> I am still waiting for it. I am willing to give you commit
> access to fix all the things that irritate you. I offered
> the same to others.
Actually, how do we know what builds and validates in RF and
what doesn't?
You should rather trigger a global SRPMS rebuild and...
whatever fails to build should go to /dev/null!
Take the example of RF's Comix package. I dunno how have
you built the RPM, because the SRPM won't build no matter
what I tried! (I even suspected that someone has built
Comix on a Fedora box, and since the binary seemed to work
on CentOS/EL too...)
In my view, a repo should be consistent, and its own SRPMS
should only need the official EL clone repo to build, or
whatever is agreed to be a required dependency (e.g. Fusion
declaratively requires EPEL, and even my tiny repo requires
or *might* require EPEL for *some* dependencies).
If a SRPMS builds under CentOS 5.0 and it doesn't under 5.3,
then this package is broekn.
I am sorry to decline your offer: I don't need access to a
8,000-package repo, for later I could be accused of some
breakage I might have not caused. Unless RF starts from zero
(that is, by tossing whatever does not build), I am not
interested: better not touch it.
Otherwise, everyone is free to rebuild from:
http://odiecolon.lastdot.org/el5/SRPMS/
If it doesn't work... c'est la vie. This is the first time
in my life that I've built RPMs, so...
> It was maintained by matthias in the past, and he
> left. I could remove the packages, but that would not
> help.
Oh yes, it would. Instead of many broken packages, better
fewer, but self-containing/self-consistent.
> > Should the Fedora people be insensitive, what prevents
> > you from just "suck in" the newer libdvdread, libdvdnav,
> > libcaca
> > and lzo from EPEL and just rebuild RF's VLC and MPlayer?
>
> I recommend you to go and try do it and see how much else
> depends on these and what no longer builds because of it
> and how much time you end up spending for something that
> doesn't do more than before eventually if you make it work.
This is the problem with a 8,000-package repo. Hey, even RHEL
has only 2,400 or whatever they have!
> Should I rebuild it just because EPEL upgraded their
> libraries ? Will EPEL fix the compatibility with the
> clamav package, a conflict they introduced ?
That's a delicate question.
> RPMforge has about 20 to 30 new commits every week, and we
> do update lots of packages regularly. The hard ones we may
> not do unless there is a compelling reason and it still
> compiles against older distributions.
Umm... so let me get it straight (yes, I can be very mean):
you *update* or *add* new packages instead of fixing the
broken ones? Isn't this approach more like... Ubuntu's?
> An automated buildsystem that would rebuild all dependencies
> would be great, I don't have it though.
Moi non plus.
> We have those 400 rock solid packages, even more than that.
> I'd say less than 5% are in a bad shape. And audacious is
> probaby one of the more visible ones. But again, why do
> you expect me to fix them, when you have a need for it ?
Because a repo should be consistent. It should be able to
rebuild from its own SRPMS. Whatever doesn't fit the picture
should go to /dev/null.
> What is the difference between a package that cannot be
> installed, and a package that is not available ?
The same as the difference between "honey, I wanted to cheat
on you, but I couldn't find anyone willing to fsck with me"
and "honey, this temptation never existed for me"!
It's peace of mind. "Now, let's see if this package is broken
or not.... oh, it's not broken."
But seriously, it's not 5%. If a SRPM doesn't build, then it's
broken. This way you could very well have 20% of breakage, in
real terms.
You know, in the F/LOSS world the idea is that the sources be
available *and* that they would build.
> Everyone expects it to be fixed.
Just delete the packages that don't rebuild. Then, maybe
someone will get involved.
> Fine, but then stop demanding something to be fixed,
> because you're talking about the little free time I
> have. Send me a fix, or even better offer to fix it
> yourself.
Whatever I could fix and build and I was interested in,
would normally get into my tiny repo. SRPMs available.
> Then do something about it. Instead of a consumer (and
> complainer), become a producer (and contributor).
VLC and MPlayer have so many dependencies, that my nerves
just broke. Really. I wanted to build them, but then...
> And the believe that one repo will rule them all (which
> is what Fedora and EPEL wants you to believe) is just
> debunked by yourself above :-)
Well, I don't have such a strong belief in any repo, the same
way I have zero belief in God.
> let my users down because there is no real upgrade path
> (the fact that you
> for some reason need RPMforge is the proof).
That's cute. Indeed, I *need* RF, despite all the "defamatory"
howto/disclaimer on how I use my repo with EPEL and only
enable RF for a few things, etc.
> But don't expect me (or dries, christoph, fabian, ...) to
> fix it because that simply *does* *not* *scale*.
7,600 packages is really too much for a couple of people to
maintain. Unless it's scaled *down*...
Regards,
R-C
__________________________________________________________________
The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
Hallo,
today I had a surprising situation. Exim stopped. It's a German centos 5.3 64 Bit installation so the messages are partial in German.
Then I tried a restart:
[root@centos ~]# service exim restart
exim beenden: [FEHLGESCHLAGEN]
exim starten: /bin/bash: line 1: 6596 Die maximale Dateigröße ist überschritten /usr/sbin/exim -bd -q30m
[FEHLGESCHLAGEN]
Reducing the size of /var/log/exim/main.log has solved the Problem.
I presume it is a message of CentOS, not from exim. Is this correct?
I think, max filesize in CentOS is 2 TB? See http://www.centos.org/product.html in "Filesystem".
Where can I change it?
Best regards
Helmut
Hi all,
i've problem with mounting logical volumes over NFS.
On NFS server, i have following logical volume
[root@nfs_server ~]# lvdisplay
--- Logical volume ---
LV Name /dev/escience/vv_25
VGnfs_servernfs_servernfs_servernfs_servernfs_server escience
LV UUID iMhNq7-iC7L-VTDO-Xcwv-a6yv-sEAD-EZWASV
LV Write Access read/write
LV Status available
# open 0
LV Size 5.00 GB
Current LE 1280
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:2
This logical volume is mounted on NFS server, the group information is
taken from LDAP server.
[root@nfs_server ~]# mount | grep vv_25
/dev/mapper/escience-vv_25 on /export/escience/vv_25 type ext3 (rw)
[root@nfs_server ~]# ls -ld /export/escience/vv_25
drwxrwx--- 3 root vv153 4096 Jun 24 16:04 /export/escience/vv_25
But when i mount /export/escience on the nfs client, i'm missing all the
permissions and ownership informations:
[root@client ~]# mount.nfs nfs_server:/export/escience/ /mnt/escience
[root@client ~]# ls -ld /mnt/escience/vv_25
drwxr-xr-x 2 root root 4096 2009-06-24 16:04 vv_25
The setting of NFS exports is following:
[root@nfs_server ~]# cat /etc/exports
/export/escience client(rw,sync,no_root_squash)
[root@nfs_server ~]# exportfs -v
/export/escience client(rw,wdelay,no_root_squash,no_subtree_check,anonuid=65534,anongid=65534)
Server is running latest CentOS 5.3
[root@nfs_server ~]# cat /etc/redhat-release
CentOS release 5.3 (Final)
[root@nfs_server ~]# uname -a
Linux nfs_server 2.6.18-128.1.14.el5 #1 SMP Wed Jun 17 06:38:05 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
No denials from selinux, client's IP is completely opened on firewall.
Is there some possibility to debug the NFS mount process? I don't see
nothing more then verbose mode in man, which doesn't provide much
informations :( Or is it some configuration issue?
thanks for help,
Tomáš Ruprich <ruprich(a)uikt.mendelu.cz>
DCD IICT MUAF Brno <www.mendelu.cz, is.mendelu.cz>
tomyk(a)jabber.cz