devel

devel@lists.centos.org

3 participants
4676 discussions

centos on hp proliant dl 580
by Marek Mahut 02 Nov '06

02 Nov '06

Hello all, someone with experiance of centos 4 on hp proliant DL580 (the old one - the white one) ? I have some questions... Thank in advance, Marek Mahut.

1 0

kernel-*-devel and yum updates for CentOS-4.x
by Johnny Hughes 28 Oct '06

28 Oct '06

Yum does not install kernel-smp-devel (or kernel-hugemem-devel, kernel- largesmp-devel), but it upgrades them. Yum does install kernel-devel, and it does not upgrade it. Yum should be consistent in how kernel-devel files are handled. ----------------------------------------------- This issue is addressed in this CentOS bug: http://bugs.centos.org/view.php?id=1549 and in this upstream bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155988 The upstream fix is rolled into FC >= 4 and RHEL >= 5 ... but it is not rolled into RHEL <= 4. That leaves CentOS-4 with this bug. ----------------------------------- There are 3 options here: 1. Patch CentOS-4 yum to make yum install all kernel-*-devel files like it does for kernel-devel (or the reverse ... make kernel-devel and upgrade like the other files). 2. Modify the kernel-2.6.spec to do what FC >= 4 does. 3. Do nothing and tell people to choose what they want by updating this variable in /etc/yum.conf installonlyn= ------------------------------------ I think that 2 is a bad choice as it makes the CentOS kernel deviate from the upstream kernel. I think that 3 is a better choice than 2 ... but I think 1 is the optimal choice. That yum needs to be updated to treat kernel-*-devel files like it treats kernel-devel. What does everyone else think? ----------------------------------- Note: This is my attempt to solicit input for package changes from the public and not make unilateral decisions and push them with only the developers present. If there is no discussion of this item on this list by non-centos developers, then I will revert back to making bug changes based on only what the developers think :P Therefore, the people who want input into how packages are updated need to speak up. ------------------------------------ Thanks, Johnny Hughes

9 15

Re: [CentOS-devel] Metalinks for CentOS (all mirrors & checksums in one file)
by Anthony L. Bryan 24 Oct '06

24 Oct '06

I made a mockup of how you could use metalinks for ISO downloads: http://www.metalinker.org/centos/ I made them all with metalink tools (http://prog.infosnel.nl/metalinks/) but only linked in the ones for 4.4. Someone who is more aesthetically inclined could design the page nicer. I like it because you've got single links that can use all the mirrors and automatic checksum verification, and you see which archs are updated for the current release. People can choose to download the old way, from one server and verify the checksums manually if they want to. (( Anthony Bryan )) Metalink [ http://www.metalinker.org ]

1 0

testing / qa process
by Karanbir Singh 20 Oct '06

20 Oct '06

Dear centos-devel'ers, We have a problem that needs fixing. The strategy to release testable rpms to dev.centos.org, then request feedback and move the rpms to stable, when we have enough positive - isnt working. We're not getting that feedback, either positive or negative. End result is that we have packages going stale and now some of those packages need updates in themselves. Looking at the logs, I can assure you that people are using those packages, just not telling us anything about them. There is one chain of though, that such request based qa process's dont work and have been tried by other Open Source projects before and not really had much of a success rate. Now, there are a few options and alternative process's that I've been thinking about, but rather than throw that out here, I'd really like to see what everyone on this list thinks and what options / process's / workaround's we might be able to come up with here. So the issue : The CentOS Project provides packages in addition to the packages from RH's sources. We need to ensure that these packages are tested in a user environment for a while, and only released to the public via the mirror.centos.org network once there is some reasonable surety as to the functional and bugs situation with the package. ideas / comments / noise welcome.. -- Karanbir Singh : http://www.karan.org/ : 2522219@icq

8 15

Re: Metalinks for CentOS (all mirrors & checksums in one file)
by Anthony L. Bryan 17 Oct '06

17 Oct '06

> We spoke about this earlier, and I also asked for comments - we didnt > get too many here on this list. But, it would still be a good idea to > get this somehow integrated into the CentOS release process. > > Making it easier and adding more options to spread loads is always a > good idea IMHO. Yes, some comments would be encouraging but I guess this isn't all that interesting. Anything I can do to make metalink more useful to you, let me know. I agree, spreading load & making things easier is good. I definitely think metalink could simplify your ISO download page as well. How about an alternate page for ISO downloads to test metalink out? Have a link for feedback on what people think. If it's positive, make it more prominent. I think once you start using it, you'll prefer it, like the groups using it now. Metalink tools (http://prog.infosnel.nl/metalinks/) generates them easily. It either creates all the hashes for files, or can read an md5sum file and generate them from a list of mirrors. I have a text list of your mirrors but it might not be fully up to date. I used it to make the ones at http://www.metalinker.org/samples.html#isos for the live CD, install CDs, & DVD for i386. (( Anthony Bryan )) Metalink [ http://www.metalinker.org ]

1 0

Re: [CentOS-devel] CentOS-4.4 yumconf
by C.M. Connelly 17 Oct '06

17 Oct '06

"CMC" == C.M. Connelly <cmc(a)math.hmc.edu> "JH" == Johnny Hughes <mailing-lists(a)hughesjr.com> I'm sorry if my comment was misconstrued -- I do appreciate the (unpaid) time and energy you and others devote to CentOS, but as an end user, while I can and do try to contribute in some ways (such as filing bugs and reading and participating in mailing lists), I cannot justify hanging out on IRC in the hope that something I need to know might get discussed. [...] JH> If that is not the kind of OS you want, then you can pay JH> $2500.00 a pop for a much more professional one. Oh, but JH> every update cycle, they still make major changes. Look JH> at the new things added this update cycle. I did. I read through the upstream release notes before the packages were built for CentOS. There's nothing in RH's notes about the change in YUM/up2date configuration files. Looking at the notes again now, I see that they have lots of changelog extracts from various packages. But not for redhat-release. The CentOS release notes also don't mention the change. JH> That might be true and MANY things are worked out devel JH> list. MANY, MANY things are discussed here. However, the JH> yum configuration files, as well as the ones for up2date JH> and any other update mechanism need to be in JH> centos-release ... and that is where they are staying. Ultimately I don't care where the files live, but it would have been nice to have had a heads-up about the change so that my machines didn't suddenly start updating from random mirrors. And it would have been even nicer to have had some advice from the CentOS developers on the ``right way'' to change the configuration so that it wouldn't break. JH> I apologize for not discussing this issue on this list JH> before it was done, however it is still where those files JH> belong. One of the things that is in our goals is to be JH> more like upstream. It just makes sense to do it the same JH> way where ever possible ... I am sorry that this affected JH> some power users in an unexpected way, but it is still JH> where the files belong. As it happens, all it really did was to make my workstation and a test machine start getting packages from other mirrors, as I haven't yet rolled CentOS 4 out more widely. I wasn't angry about the change, just a bit annoyed that I hadn't known about it beforehand and that there didn't seem to be a clear way to set things up so that they would work properly. I think that we have that now (any of several possible solutions that include removing CentOS-Base.repo and replace with an empty file), so I'm satisfied. (Keeping the separate yumconf package would have been easier for me, but I totally understand where you're coming from in wanting to track upstream closely, and it's clear from Fedora that that's where RH is going with these files.) I'm sorry that you and Karanbir took my and others technical criticism so personally. I *greatly* appreciate the work of the CentOS developers -- you've saved me an enormous amount of work, as the announcement of CentOS came when I was in the process of doing a major reassessment of our OS plans after Red Hat had announced the end of life of Red Hat Linux and before they'd said anything about academic pricing. CentOS allowed me to build on the work I'd already done to support deployment and maintenance instead of starting from scratch with a new distro. At this point, we could buy licenses from RH for a much lower academic price, but the department doesn't really have that kind of money. CentOS allows me to run an OS that has better support than RH's current offerings for academia (i.e., *any*); is more up to date than some other options (e.g., Debian), but still quite stable; and also allows me to contribute something back to the community in the form of feedback and bug reports, as well as the mirror we provide for the releases and architectures that we currently run. Thank you both for your work (as well as the other developers not participating in this thread). And thank you for your apology for not discussing the change on the list. Claire *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Claire Connelly cmc(a)math.hmc.edu Systems Administrator (909) 621-8754 Department of Mathematics Harvey Mudd College *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

1 0

Metalinks for CentOS (all mirrors & checksums in one file)
by Anthony L. Bryan 16 Oct '06

16 Oct '06

Hi, Still seeing if you'd like to use metalinks for your ISO downloads. Metalinks contain mirror and p2p locations along with checksums and other metadata for faster and easier downloads. Downloads are distributed between mirrors and checksums are automatically verified when it finishes. Here's a good description: 'Metalink makes complex download pages obsolete by replacing long lists of download mirrors and BitTorrent trackers with a single .metalink file. As you might have already guessed, a .metalink file is a file that tells a download manager all the different ways it can download a file. The file itself takes the form of an open XML standard that can list an unlimited number of HTTP and FTP sources as well as BitTorrent trackers and ed2k and magnet links.' (http://www.downloadsquad.com/2006/08/28/metalinks-integrated-bittorrent-htt p-and-ftp-downloads/) There's a metalink for CentOS at http://www.metalinker.org/samples/CentOS-4.4-i386-LiveCD.iso.metalink if anyone wants to try it out. Here's what part of it looks like: <file name="CentOS-4.4-i386-LiveCD.iso"> <version>4.4</version> <verification> <hash type="md5">747c9e33a10fdbf5919d9fd188ab7d23</hash> </verification> <resources> <url type="http" preference="100">http://altruistic.lbl.gov/mirrors/centos/4.4/isos/i386/Cent OS-4.4-i386-LiveCD.iso</url> <url type="http" preference="100">http://centos.mirror.nac.net/4.4/isos/i386/CentOS-4.4-i386- LiveCD.iso</url> <url type="http" preference="100">http://dist1.800hosting.com/centos/4.4/isos/i386/CentOS-4.4 -i386-LiveCD.iso</url> <url type="http" location="us" preference="100">http://ftp.osuosl.org/pub/centos/4.4/isos/i386/CentOS-4.4-i 386-LiveCD.iso</url> </resources> Download clients are available for Unix, Mac, & Windows. aria2 RPMs for Red Hat Enterprise Linux 4 are at http://dries.ulyssis.org/rpm/packages/aria2/info.html OpenOffice.org and many Linux/BSD distributions are using metalink. Here's a few places: http://distribution.openoffice.org/p2p/magnet.html http://en.opensuse.org/Released_Version#Metalink http://desktopbsd.net/index.php?id=73 http://www.pcbsd.org/?p=download http://www.archlinux.org/download/ http://www.redwall-firewall.com/content/view/14/33/ http://yui.mine.nu/berry/edownload.php http://puppylinux.org/wikka/Puppy210 (( Anthony Bryan )) Metalink [ http://www.metalinker.org ]

2 1

Holger Daehre/SPOERLE ist außer Haus.
by Holger Daehre 15 Oct '06

15 Oct '06

Ich werde ab 02.10.2006 nicht im Büro sein. Ich kehre zurück am 30.10.2006. Ich werde Ihre Nachricht nach meiner Rückkehr beantworten.

2 1

Re: [CentOS-devel] CentOS-4.4 yumconf
by C.M. Connelly 14 Oct '06

14 Oct '06

"JP" == Jim Perrin <jperrin(a)gmail.com> Jim, JP> This was discussed before implementation, in the -devel JP> channel on IRC. The full ramifications weren't felt JP> initially because it worked fine for stock centos. If JP> you'd like to participate in the discussions, you're JP> welcome to join the irc channel. Like, I suspect, most people using CentOS, I'm not paid to work on the OS, and I don't have time to hang out on IRC on the off chance that someone will bring up something that might completely screw up my systems down the road. To be frank, saying, ``Oh, we talked about that on IRC,'' is about as useful as saying, ``Jennie, Bob, and I talked about it over a drink at the Boo Bar.'' IRC is a great place to work out implementation details and maybe even do some thought experiments to imagine what the impact might be, but mailing lists are a much better place to have real discussions, especially when your changes might impact people outside the tiny circle of people who frequent the IRC channel. Claire *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Claire Connelly cmc(a)math.hmc.edu Systems Administrator (909) 621-8754 Department of Mathematics Harvey Mudd College *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

9 14

RE: [CentOS-devel] Re: testing / qa process
by Alex Palenschat 13 Oct '06

13 Oct '06

> Instead of blocking on (lack-of) feedback, I'd suggest > considering something > like: > 1. Put pkgs in "testing" > 2. If no bugs reported after X days/weeks, move out of testing > > At least this way nothing gets perpetually stalled in testing. > > -- Rex > Just my 2 cents, but I have used some packages in the testing repo successfully. I certainly am not in a position to test them in a large production/enterprise environment and outside of the testing repo I try really hard to stay as vanilla as I can with my boxes. But I'm not certain what I can do except troll this list and say WorksForMe when somebody asks. I wouldn't guess that the signal-to-noise-ratio would be acceptable if everytime I successfully installed and used for a week package x that I post a new thread saying it worked. Perhaps you could find a method of requiring prospective users of the testing repo to subscribe to this mailing list. That way more users would see when a question/poll was asked in regards to a given package. Just an idea, Alex

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel