Discuss June 2009

discuss@lists.centos.org

286 participants
327 discussions

CentOS-announce Digest, Vol 52, Issue 13
by centos-announce-request＠centos.org 30 Jun '09

30 Jun '09

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 ***********************************************

1 0

Re: [CentOS] Web photo gallery options
by Ray Leventhal 30 Jun '09

30 Jun '09

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

1 0

Re: [CentOS] Dag's comment at linuxtag
by Radu-Cristian FOTESCU 30 Jun '09

30 Jun '09

> 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/

1 0

Re: [CentOS] Dag's comment at linuxtag
by Radu-Cristian FOTESCU 30 Jun '09

30 Jun '09

> 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/

1 0

Re: [CentOS] Dag's comment at linuxtag
by Radu-Cristian FOTESCU 30 Jun '09

30 Jun '09

> 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/

1 0

change gnome back to default settings
by Jerry Geis 30 Jun '09

30 Jun '09

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

2 1

Re: [CentOS] Dag's comment at linuxtag
by Radu-Cristian FOTESCU 30 Jun '09

30 Jun '09

> 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/

3 2

filesize limitation in CentOS or exim?
by Helmut Drodofsky 30 Jun '09

30 Jun '09

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

4 4

logical volume over NFS permissions problem
by Tomas Ruprich 30 Jun '09

30 Jun '09

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

2 2

commercial support page
by Geoff Galitz 30 Jun '09

30 Jun '09

So we had that nice long thread about the commercial support page a week ago. There were a few recommendations on changes to the page. What next? It is not clear to me if any recommendations were accepted or are being debated internally or if this fizzled out somehow. Is there any process to this kind of thing other than a few developers agreeing it a good thing and then just doing it? I'm not complaining, but I am genuinely curious. --------------------------------- Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/

2 1

← Newer
1
2
3
4
5
6
7
...
33
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss June 2009