URL for Fedora Mirrors
I'm getting 404 Not Found when folowing URL is used. http://mirrors.fedoraproject.org/publiclist/ Can we redirect to following? http://mirrors.fedoraproject.org/publiclist Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
app3 mirrormanager publiclist/ pages horked
On Wed, Jun 20, 2007 at 12:30:34AM -0700, Thomas Chung wrote: On 6/20/07, Thomas Chung [EMAIL PROTECTED] wrote: I'm getting 404 Not Found when folowing URL is used. http://mirrors.fedoraproject.org/publiclist/ Can we redirect to following? http://mirrors.fedoraproject.org/publiclist Hmm, interesting. If I reload both URLs, I'm getting different pages with different format. Sometimes with banner. Sometimes without banner. Sometimes 404 Not Found. Sometimes it looks just fine. What's going on? The pages are regenerated at the top of each hour on each of the two separate servers. There can be a few seconds during the rsync update (it uses rsync --delay-updates even for the local file copy) while the new pages are copied into place. But app3 /srv/tg/mirrormanager/mirrorlists isn't happy which is why it's throwing the 404. The yum mirrorlists are still running fine, which makes me think it's just a failure of the one copy... My Fedora ssh key is in a machine that's offline due to my move, so I can't get onto app3 right now to fix it myself. If someone can: sudo su - cd /srv/tg/mirrormanager rm -rf mirrorlists rm -f /tmp/mirrormanager-update-each-server.lock sudo -u apache sh -c ./update-each-server That will force a regeneration of the mirrorlists. it will take about 5 minutes to run. App4 could use that too, once app3 finishes... Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: app3 mirrormanager publiclist/ pages horked
On Wed, 2007-06-20 at 15:08 +0100, Damian Myerscough wrote: Matt, Done. Ill do App4 Sorry for the bad follow up on my part: I took care of these this morning around 9am. There was an error in the db where a host didn't have a country code associated with it that was causing the whole process to die. I took care of the changes Matt requested and re-ran the code. It's fine now. Again, sorry for not commenting on it further. -sv ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Fedora Magazine RFR
Anand Capur wrote: Anand Wrote: eGroupware (which I will package for Fedora if needed). * Web Server: Apache 2.2.4 * PHP 5.2.2 * Database Server: MySQL 5.0.41 * Mail Server: Postfix * DNS Server: BIND9 (chrooted) * FTP Server: pureftpd * POP3/IMAP server: Dovecot * Webalizer for web site statistics I found egroupware packaged for fedora core 5/6 already. The link was on the egroupware site. http://software.opensuse.org/download/server:/eGroupWare/Fedora_Extras_6/noarch/ Ouch. If it's not in our repositories, it isn't properly packaged, or no-one ever took ownership and just dumped that package in. IMHO, that package is just like this one package I have: This-will-burn-your-machine-1.0.1-4.fc7.noarch.rpm Nonetheless, the package can save you a lot of work since you would only need to adjust the spec file and maybe build some patches to match the packaging guidelines and pass review, right? Kind regards, Jeroen van Meeuwen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Fedora Magazine RFR
I found egroupware packaged for fedora core 5/6 already. The link was on the egroupware site. http://software.opensuse.org/download/server:/eGroupWare/Fedora_Extras_6/noarch/ Ouch. If it's not in our repositories, it isn't properly packaged, or no-one ever took ownership and just dumped that package in. IMHO, that package is just like this one package I have: This-will-burn-your-machine-1.0.1-4.fc7.noarch.rpm Nonetheless, the package can save you a lot of work since you would only need to adjust the spec file and maybe build some patches to match the packaging guidelines and pass review, right? Kind regards, Jeroen van Meeuwen Yeah, it should. Since it is just a PHP Script I wouldn't need to make it compatible with fedora 7. I don't need to include php right? ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Fedora Magazine RFR
Anand Capur wrote: Yeah, it should. Since it is just a PHP Script I wouldn't need to make it compatible with fedora 7. I don't need to include php right? Actually you do. http://fedoraproject.org/wiki/PackageMaintainers/Join -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Fedora Magazine RFR
On Mon, 2007-06-18 at 23:24 +0530, Anand Capur wrote: (it is a magazine that will be under a no-copyright, so as the wiki needs we would need that agreement signed also). What do you mean by no-copyright? The CLA doesn't grant copyright to anyone; you retain that for the work you do. It provides an agreement whereby Fedora (via Red Hat) can use your copyright material under an open source license. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 // signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: URL for Fedora Mirrors
On Wed, 2007-06-20 at 00:30 -0700, Thomas Chung wrote: Hmm, interesting. If I reload both URLs, I'm getting different pages with different format. Sometimes with banner. Sometimes without banner. Sometimes 404 Not Found. Sometimes it looks just fine. What's going on? Usually these days, that means something is wonky with one of the frontline proxies. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 // signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Our SCM
On Tue, 2007-06-19 at 16:01 -0400, Jesse Keating wrote: I'd really like there to be offline support in a manner that allows non-commiters to be able to clone, modify, and provide a repo back to us that we can pull from. +1 I think the barrier described earlier is worse than we realize. It may seem like delving into technical details, but actually centralized v. distributed VCS is actually a strategic question. Strategically, we need to move _all_ of Fedora in the direction of distributed VCS. Honestly, this is the whole truth behind why we are working our arses off in Docs and L10N to get new ways for people to be able to contribute. We *must* have the XML/PO-based tools to get the work done, but making people go through all the hoops to gain write access to the SCM means we get maybe 1% of the interested people from I want to help to actually helping. You see a larger successful percentage with developers because they have been through the VCS account system learning curve in the past. Not so with people who want to write content or translate. This is why everything from GPG keys to CVS committing are so new to so much of our prospective contributors. So, Infrastructure is much closer to developers, in that the pool of potentials are more likely to be clued. But keeping it this hard to contribute means we are missing out on the 1x more people who are not clued enough to get over the walls, but who would become so clued if we could get them in and working their way along the path to Enlightenment. This goes back to the stuff Blizzard keeps talking about -- getting down the barriers between users and developers that our open collaboration tools ironically create. /rant - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 // signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Our SCM
On Wed, 2007-06-20 at 11:22 -0700, Karsten Wade wrote: So, Infrastructure is much closer to developers, in that the pool of potentials are more likely to be clued. But keeping it this hard to contribute means we are missing out on the 1x more people who are not clued enough to get over the walls, but who would become so clued if we could get them in and working their way along the path to Enlightenment. This goes back to the stuff Blizzard keeps talking about -- getting down the barriers between users and developers that our open collaboration tools ironically create. Right! So here's another question for you: how do we make things easier? And I don't mean just getting the model right (i.e. DVCS as a mechanism) but also keeping things super-easy to use? Here's a completely crazy idea: do an online translation activity that uses google gears on the backend that lets people do their work offline and then can sync up when it's done? That way anyone on linux/windows/mac can participate and they can get hooked directly up to web services we have in place? That's outside of our comfort zone, but it's not completely crazy. Our work has to be about enabling people so that working with us and the rest of the open source community is easy easy easy. --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Our SCM
On Wed, Jun 20, 2007 at 03:15:59PM -0400, Christopher Blizzard wrote: On Wed, 2007-06-20 at 11:22 -0700, Karsten Wade wrote: Right! So here's another question for you: how do we make things easier? And I don't mean just getting the model right (i.e. DVCS as a mechanism) but also keeping things super-easy to use? Here's a completely crazy idea: do an online translation activity that uses google gears on the backend that lets people do their work offline and then can sync up when it's done? That way anyone on linux/windows/mac can participate and they can get hooked directly up to web services we have in place? That's outside of our comfort zone, but it's not completely crazy. Our work has to be about enabling people so that working with us and the rest of the open source community is easy easy easy. It's far from completely crazy. Ubuntu's got a program whereby, when running an app, you can click I want to re-translate this string, or this page and up pops their translation tool / web app. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Fedora Magazine RFR
On 6/21/07, Dennis Gilmore [EMAIL PROTECTED] wrote: Allright, thanks! Also, do I need to include PHP PEAR extensions that are required? If they are not in fedora yet then yes. preferably one tarball per srpm -- Dennis Gilmore, RHCE ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Our SCM
On Wed, 2007-06-20 at 15:15 -0400, Christopher Blizzard wrote: On Wed, 2007-06-20 at 11:22 -0700, Karsten Wade wrote: Right! So here's another question for you: how do we make things easier? And I don't mean just getting the model right (i.e. DVCS as a mechanism) but also keeping things super-easy to use? Here's a completely crazy idea: do an online translation activity that uses google gears on the backend that lets people do their work offline and then can sync up when it's done? That way anyone on linux/windows/mac can participate and they can get hooked directly up to web services we have in place? That's outside of our comfort zone, but it's not completely crazy. Our work has to be about enabling people so that working with us and the rest of the open source community is easy easy easy. I was thinking about this subject this week. All the ideas I've heard, thus far, for how to achieve the above involve fedora having nearly limitless resources for people to use in terms of bandwidth/disk space/etc. They focus on developers coming to work on our systems with us. My problem is that it seems to scale less well b/c we're essentially creating a monstrous silo that we are inviting any and everyone to come play in. I think we've had that before, it was called sourceforge. It sucks resources and is a pain to maintain. However, I do like the objective but the implementations I've heard so far don't fill me with joy. So I was wondering if it might be possible to reverse the model a bit. Why not make it so our buildsys and related pieces can easily pull from upstream's scm's. so we don't keep an infinite number of copies of upstream internally and/or end up with special forks. Now, the bad parts of this are fairly obvious: - we rely on the consistency of upstream (which we do already, we just delude ourselves into thinking that somehow the vcs checkout or the tarball is more consistent) I'd suggest something like this: 1. where upstream is willing to play ball, we ask them to setup a fedora branch/subdir in their dvcs repo that points to our git/hg tree. 2. when not possible we use our own vcs for that data and we offer to: a. work upstream if they want b. grant them access to work out of our vcs in the same was as in [1], just reversed. This way upstream can retain as much control as possible w/o us having to have an infinite fork of everything in every upstream project. Does that make any sense at all? -sv ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Fedora Magazine RFR
Anand Capur wrote: Thanks! We do need a real CMS, not a Wiki. I already ditched Joomla and I think i'll use plone. I'm sorta experienced with it and like you said I can use the knowledge already gained from the main site installation of plone. eGroupWare is how we will track the projects, articles, progress, calendar, etc So we've come a long way in the last couple of days. I always appreciate enthusiasm for something new and you certainly seem to have it. Please be patient with the team though as it's very difficult for us to determine serious contributors from fly by night people. And fly by night people really do take a bad toll on our work. The task list as I see it is you'd still like to see eGroupWare to track articles, progress and calendar stuff. In theory this could be used in other areas of our infrastructure as well. So the first task I see for you is to get eGroupWare packaged and in Fedora. Beyond that I'd like to ask you to contact Thomas Chung about Fedora Weekly News if you have not already done so. It sounds like the two of you are targeting very similar audiences and Fedora Weekly News is absolutely outstanding in my opinion and more contributors will only make it better. I think it would be best if the two of you worked together to find commonalities like branding/look, release cycle, tools, etc. Then Thomas's group could continue to report on all things Fedora and you could add to it maybe interviews and technical documentation. Perhaps Thomas would like to use Plone in the future for Fedora Weekly News when it comes out. What do you think? -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Our SCM
seth vidal wrote: So I was wondering if it might be possible to reverse the model a bit. Why not make it so our buildsys and related pieces can easily pull from upstream's scm's. This seems to be the best way to take advantage of distributed SCM's to me, and it allows for having one less resource to manage (i.e. Fedora CVS). Right now, I find Fedora CVS a bit annoying as, well, it means using yet-another-version control repository -- and lots of seperate checkins when I want to push content to 3 seperate repos. However it does rely on the accessibility of those upstream repos. Shouldn't be a major issue. If it's down, no updates. Branching is one way to tackle this, though I'd really prefer tags. For each release, the user could log in and specify what tag to build from where. That way I could build the same arbitrary tag identically for FC-6, FC-7, and devel ... if I want. Which, being upstream and relatively not-caring about the differences between those distros as my source repository already takes care of that, that's usually what I want. Seems like this could be very slow for the build system, though. Alternatively, I'd like the same features and be able to push my repository to the Fedora server.Either way, something more flexible and quicker to use would be welcome. --Michael ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Our SCM
seth vidal wrote: On Wed, 2007-06-20 at 16:06 -0400, Michael DeHaan wrote: seth vidal wrote: but things can go away 'forever' and we still want them around. You'd have the entire history in the last pull, right? It seems like no matter which way I turn this around in my head we end up having to have a complete copy of everything in fedora's pkg vcs to reliably do what we need to do. Not to mention the issues of firewalls and the buildsys talking to hosts in $not_okay_countries. True.Hosting and pushing to a DVCS sounds better -- and it's not any harder. sounds like push down from upstream will be about the only thing we'll be able to do w/o getting into a bunch of other issues. I like this. OT -- Mercurial has on a few occasions accepted a push that resulted in the target repository losing history or merging in ways that I would consider fundamentally wrong. I can't prove this, but we've seen it on a few occasions enough to believe it wasn't user error. I figured I should share that. I really haven't had this need with git -- with hg, I did have to recreate the repo on the server a few times.That might be a problem for administration and needs a nice way to be automatically cleaned out and repushed without pinging an admin, I think. git has a bit too many commands and is not user friendly in a lot of cases, but from a while using both, I prefer git. -sv ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: URL for Fedora Mirrors
On 6/20/07, seth vidal [EMAIL PROTECTED] wrote: On Wed, 2007-06-20 at 11:10 -0700, Karsten Wade wrote: On Wed, 2007-06-20 at 00:30 -0700, Thomas Chung wrote: Hmm, interesting. If I reload both URLs, I'm getting different pages with different format. Sometimes with banner. Sometimes without banner. Sometimes 404 Not Found. Sometimes it looks just fine. What's going on? Usually these days, that means something is wonky with one of the frontline proxies. in this case it was the code on the app instances behind it them being odd. It should be all fixed up, now. -sv Thank you Seth and Matt, I can confirm it's been fixed. :) Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Our SCM
Yeah i though we were talking about our own SCM... The one we use to maintain the configs for our different tools, webservers and apps :) The other is still a good discussion, but should take place in the other thread (i might be wrong of course :P) Paulo On 6/20/07, Mike McGrath [EMAIL PROTECTED] wrote: Karsten Wade wrote: On Tue, 2007-06-19 at 16:01 -0400, Jesse Keating wrote: I'd really like there to be offline support in a manner that allows non-commiters to be able to clone, modify, and provide a repo back to us that we can pull from. +1 I think the barrier described earlier is worse than we realize. It may seem like delving into technical details, but actually centralized v. distributed VCS is actually a strategic question. Strategically, we need to move _all_ of Fedora in the direction of distributed VCS. Honestly, this is the whole truth behind why we are working our arses off in Docs and L10N to get new ways for people to be able to contribute. We *must* have the XML/PO-based tools to get the work done, but making people go through all the hoops to gain write access to the SCM means we get maybe 1% of the interested people from I want to help to actually helping. You see a larger successful percentage with developers because they have been through the VCS account system learning curve in the past. Not so with people who want to write content or translate. This is why everything from GPG keys to CVS committing are so new to so much of our prospective contributors. So, Infrastructure is much closer to developers, in that the pool of potentials are more likely to be clued. But keeping it this hard to contribute means we are missing out on the 1x more people who are not clued enough to get over the walls, but who would become so clued if we could get them in and working their way along the path to Enlightenment. This goes back to the stuff Blizzard keeps talking about -- getting down the barriers between users and developers that our open collaboration tools ironically create. /rant :) I think this thread took a spin away from the Infrastructure SCM and on to something else. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Our SCM
On Wed, 2007-06-20 at 15:52 -0400, seth vidal wrote: Does that make any sense at all? My specific proposal was mostly about translations which I don't think have the same scaling problems you (rightfully) point out with source in general. I like a lot of what you had to say there. Instead of saying that we pull from an upstream VCS I might say that we keep our own copy. I think that we always want to have a copy of the source that we use for builds somewhere local. But I do like the idea of trying to get upstream repos to keep track of the fedora branch or coming up with a set of best practices around that. Anything we can do to make ourselves closer to upstream projects is for teh win. --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Our SCM
On Wed, 2007-06-20 at 16:06 -0400, Michael DeHaan wrote: However it does rely on the accessibility of those upstream repos. Shouldn't be a major issue. If it's down, no updates. Trust me when I say you don't want to do this. You always want to have a local copy. For OLPC we have a jhbuild script that used to pull from a lot of different repos and someone was _always_ down. We want coupling, but we want it to be loose coupling. --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Our SCM
On Wed, 2007-06-20 at 21:20 -0400, Christopher Blizzard wrote: On Wed, 2007-06-20 at 16:06 -0400, Michael DeHaan wrote: However it does rely on the accessibility of those upstream repos. Shouldn't be a major issue. If it's down, no updates. Trust me when I say you don't want to do this. You always want to have a local copy. For OLPC we have a jhbuild script that used to pull from a lot of different repos and someone was _always_ down. We want coupling, but we want it to be loose coupling. Yeah, just think SourceForge CVS... Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
