From mmcgrath at redhat.com Fri Jun 1 07:11:56 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 01 Jun 2007 02:11:56 -0500 Subject: Fedora 7 Release (Post release day) Message-ID: <465FC6BC.9010809@redhat.com> Well this release went so much better then the last release. Matt has created the following page: http://fedoraproject.org/wiki/Infrastructure/F7LessonsLearned For those that don't remember last year.... It didn't go so well. Here's some issues we had this year: * Spikey load + iptables implementation broght the static pages down for a few minutes at a time at the beginning of the release (first couple of hours) This also caused some mirrors.fp.o outages - Minor issue * Wiki Load - The wiki, as always causes issues. All in all I think the wiki did ok, we never created any static pages for it (as we did last year) but we did lose app1 three times (needed to be rebooted) This also brought docs.fp.o down (see below) - Medium issue * Nagios - Just ended up creating a lot of noise. This was a known issue and is already being worked on :) This stuff will get better as we implement better service dependencies. - Known issue * Docs - This one lies on me, it went much better than last year (docs was down for close to 4 days). Unfortunately, unlike most of our apps, docs didn't get setup to load balance properly. As such all traffic was going to app1, and when moin combined with docs took app1 down, docs just died. We put a temporary site in place but it was untested and we had some display issues. We'll have this one totally corrected in no time. * Ram - This was an identified issue but not one that we had much time to fix. Seems most of the problems we had were ram related (technically swap related) There's a great deal of performance we can gain in every area by adding ram. Additionally some of our boxes are close to being out of warranty and can be replaced with 64 bit boxes. * Accounts - The accounts stuff died a bit, same issue as the wiki. Accounts is working to be replaced anyway and in the meantime the account system can be installed on more app servers (presently its only on two) Stuff that went right: * Mirrors.fp.o and smolt - Mirrors worked like a champ, so has smolt. Spread acrsoss two boxes they only required minor tweaking from matt and really just worked. This is quite an impressive feat since neither one of these apps has been under this sort of load before and we really didn't know exactly how they would work (though our initial load tests on both proved they would work fine). The public list was CRITICAL in getting users to the mirrors and it just worked. My hats off to everyone with this stuff, both of these apps are written in TurboGears. * The static pages - Boy what a difference these made. It was very nice to know we also had them on the mirrors. though never needed to use them. * #fedora-admin - For the most part stayed on topic, everyone was helpful and it was great to get all of the smart people together to test, discover what went wrong and work to fix it. * Torrent - Didn't here a word about it and AFAIK it 'just worked' amazing. * Dynamic allocation of systems. We were able to take down and add additional ram to some of our app servers as well as create a new proxy server at the temporary cost of test and build servers. now that release day is done we can just put everything back as it was. We could have done even more to help the wiki if we had more ram. App1 had 3G RAM App2 had 4G. App1 still crashed. (those are our wiki servers) * Fedora 7 Release - We had a few bumps but I'd easily call this a success. We got people to the mirrors on release day. Much better than last year, and even better still we did better then Ubuntu did on their last release :) For next time: Aside from the wiki upgrade and trying to find more efficiencies there, the big thing we need is more RAM. I'd say 95% of our issues could have been non-issues just with more RAM. Fortunately thats the easy part :) Nagios should be in good shape by next time. Thanks everyone for your hard work we've done a really good job this time out. Anyone have other comments? -Mike From justin.randell at gmail.com Fri Jun 1 07:36:52 2007 From: justin.randell at gmail.com (justin randell) Date: Fri, 1 Jun 2007 17:36:52 +1000 Subject: looking to contribute to fedora Message-ID: <34a99ab40706010036n4f5346d4tef32a7d5511fc41@mail.gmail.com> hi, http://fedoraproject.org/wiki/JustinRandell <-- my details i'm looking to help out with the fedora infrastructure team. a suggestion that came out of #fedora-admin was working on improving the efficiency of moinmoin (especially page save operations). i'm happy to start there, but i'm open to other suggestions. cheers justin From mmcgrath at redhat.com Fri Jun 1 08:11:28 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 01 Jun 2007 03:11:28 -0500 Subject: looking to contribute to fedora In-Reply-To: <34a99ab40706010036n4f5346d4tef32a7d5511fc41@mail.gmail.com> References: <34a99ab40706010036n4f5346d4tef32a7d5511fc41@mail.gmail.com> Message-ID: <465FD4B0.2040307@redhat.com> justin randell wrote: > hi, > > http://fedoraproject.org/wiki/JustinRandell <-- my details > > i'm looking to help out with the fedora infrastructure team. > > a suggestion that came out of #fedora-admin was working on improving > the efficiency of moinmoin (especially page save operations). > > i'm happy to start there, but i'm open to other suggestions. You want instant street cred? Get the darn wiki to work :) -Mike From oliver at linux-kernel.at Fri Jun 1 08:20:24 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jun 2007 10:20:24 +0200 Subject: looking to contribute to fedora In-Reply-To: <465FD4B0.2040307@redhat.com> References: <34a99ab40706010036n4f5346d4tef32a7d5511fc41@mail.gmail.com> <465FD4B0.2040307@redhat.com> Message-ID: <465FD6C8.3030601@linux-kernel.at> On 06/01/2007 10:11 AM, Mike McGrath wrote: > justin randell wrote: >> hi, >> >> http://fedoraproject.org/wiki/JustinRandell <-- my details >> >> i'm looking to help out with the fedora infrastructure team. >> >> a suggestion that came out of #fedora-admin was working on improving >> the efficiency of moinmoin (especially page save operations). >> >> i'm happy to start there, but i'm open to other suggestions. > > You want instant street cred? Get the darn wiki to work :) Moin doesn't support memcached, does it!? I experienced much better performance at my MediaWiki after I enabled memcached... -of From mmcgrath at redhat.com Fri Jun 1 09:49:52 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 01 Jun 2007 04:49:52 -0500 Subject: Wiki upgraded Message-ID: <465FEBC0.7090408@redhat.com> I've upgraded the wiki from 1.5.7 to 1.5.8 (should fix unicode error) we do strange things with our wiki so if stuff isn't working now or doesn't look right please let me know. -Mike From torsten.rausche at gmail.com Fri Jun 1 09:28:08 2007 From: torsten.rausche at gmail.com (Torsten Rausche) Date: Fri, 1 Jun 2007 11:28:08 +0200 Subject: Wrong mirrorlists for ppc Message-ID: <2c6956970706010228u718310d1jee53094954f69ffe@mail.gmail.com> Hello! Is it intended that all mirrorlists for ppc point to ppc64 directories? The ppc64 directories only contain ppc64 and noarch packages, while the ppc directories contain ppc, noarch and also ppc64 packages. So shouldn't the mirrorlists point to the ppc directories? In the current state mirrorlists are useless for my iBook and I have to point yum to a mirror manually :( Torsten From Matt_Domsch at dell.com Fri Jun 1 12:11:17 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 1 Jun 2007 07:11:17 -0500 Subject: Wrong mirrorlists for ppc In-Reply-To: <2c6956970706010228u718310d1jee53094954f69ffe@mail.gmail.com> References: <2c6956970706010228u718310d1jee53094954f69ffe@mail.gmail.com> Message-ID: <20070601121117.GN6173@lists.us.dell.com> On Fri, Jun 01, 2007 at 11:28:08AM +0200, Torsten Rausche wrote: > Hello! > > Is it intended that all mirrorlists for ppc point to ppc64 directories? > The ppc64 directories only contain ppc64 and noarch packages, while > the ppc directories contain ppc, noarch and also ppc64 packages. So > shouldn't the mirrorlists point to the ppc directories? > In the current state mirrorlists are useless for my iBook and I have > to point yum to a mirror manually :( Crud. Regexp expansion is doing this. OK, I'll see how to fix that... Thanks for the report. I've got to re-point the rawhide dirs today anyhow. 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 From Matt_Domsch at dell.com Fri Jun 1 14:05:47 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 1 Jun 2007 09:05:47 -0500 Subject: Wrong mirrorlists for ppc In-Reply-To: <20070601121117.GN6173@lists.us.dell.com> References: <2c6956970706010228u718310d1jee53094954f69ffe@mail.gmail.com> <20070601121117.GN6173@lists.us.dell.com> Message-ID: <20070601140547.GP6173@lists.us.dell.com> On Fri, Jun 01, 2007 at 07:11:17AM -0500, Matt Domsch wrote: > On Fri, Jun 01, 2007 at 11:28:08AM +0200, Torsten Rausche wrote: > > Hello! > > > > Is it intended that all mirrorlists for ppc point to ppc64 directories? > > The ppc64 directories only contain ppc64 and noarch packages, while > > the ppc directories contain ppc, noarch and also ppc64 packages. So > > shouldn't the mirrorlists point to the ppc directories? > > In the current state mirrorlists are useless for my iBook and I have > > to point yum to a mirror manually :( > > Crud. Regexp expansion is doing this. OK, I'll see how to fix > that... > > Thanks for the report. I believe this is fixed now, please confirm. http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-7&arch=ppc works for me, points to the releases/7/Everything/ppc/os directory on the mirrors like it should. 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 From torsten.rausche at gmail.com Fri Jun 1 16:26:04 2007 From: torsten.rausche at gmail.com (Torsten Rausche) Date: Fri, 1 Jun 2007 18:26:04 +0200 Subject: Wrong mirrorlists for ppc In-Reply-To: <20070601140547.GP6173@lists.us.dell.com> References: <2c6956970706010228u718310d1jee53094954f69ffe@mail.gmail.com> <20070601121117.GN6173@lists.us.dell.com> <20070601140547.GP6173@lists.us.dell.com> Message-ID: <2c6956970706010926q34c10edep6c606b16b4e42b79@mail.gmail.com> 2007/6/1, Matt Domsch : > On Fri, Jun 01, 2007 at 07:11:17AM -0500, Matt Domsch wrote: > > I believe this is fixed now, please confirm. > > http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-7&arch=ppc > > works for me, points to the releases/7/Everything/ppc/os directory on > the mirrors like it should. Works for me too. Thank you! Torsten From paulo.banon at googlemail.com Fri Jun 1 18:27:59 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Fri, 1 Jun 2007 20:27:59 +0200 Subject: Wiki upgraded In-Reply-To: <465FEBC0.7090408@redhat.com> References: <465FEBC0.7090408@redhat.com> Message-ID: <7a41c4bc0706011127g5bb821d0yd3452a843a7f1c29@mail.gmail.com> Even after the wiki upgrade the NULL char problem is still occuring... Paulo On 6/1/07, Mike McGrath wrote: > > I've upgraded the wiki from 1.5.7 to 1.5.8 (should fix unicode error) > > we do strange things with our wiki so if stuff isn't working now or > doesn't look right please let me know. > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Fri Jun 1 20:34:23 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 01 Jun 2007 15:34:23 -0500 Subject: Wiki upgraded In-Reply-To: <7a41c4bc0706011127g5bb821d0yd3452a843a7f1c29@mail.gmail.com> References: <465FEBC0.7090408@redhat.com> <7a41c4bc0706011127g5bb821d0yd3452a843a7f1c29@mail.gmail.com> Message-ID: <466082CF.4080100@redhat.com> Paulo Santos wrote: > Even after the wiki upgrade the NULL char problem is still occuring... I can confirm this. I'm in #moin right now actually discussing though not making much progress, Thomas and I keep missing eachother. -Mike From paulo.banon at googlemail.com Fri Jun 1 21:50:44 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Fri, 1 Jun 2007 23:50:44 +0200 Subject: Wiki test Message-ID: <7a41c4bc0706011450m12e0bd5ala946cb3c092a72f4@mail.gmail.com> Mike, Im getting some IOerrors in the apache logs and as such I would like to propose a set of tests in starting next week or the week afterwards. [Fri Jun 01 12:29:04 2007] [error] [client 10.8.32.56] PythonHandler MoinMoin.request::RequestModPy.run: IOError: Write failed, client closed connection. Also lots of mod_python errors in the error_log Setup the wiki in a 1 (or 2) to 1 like it was in the old days. proxy1 -> app1 proxy2 -> app1 No load balancers or anything other thing out of a normal ProxyPass. I would like to try this, so make sure that its not anything regarding the new LoadBalancer functionalities that you've added in the past weeks. It should be enough to run this test for half a day... Any comments ? Thanks, Paulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Sat Jun 2 04:46:16 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 01 Jun 2007 23:46:16 -0500 Subject: Wiki - Recent Changes Message-ID: <4660F618.4010700@redhat.com> Next time we have a failure in "RecentChanges" please leave it borked (but let me or let ThomasWaldmann in #moin know). Fix any pages that don't come up but leave the master edit log alone, the moin developers are going to take a closer look. -Mike From mmcgrath at redhat.com Sat Jun 2 04:51:09 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 01 Jun 2007 23:51:09 -0500 Subject: Wiki test In-Reply-To: <7a41c4bc0706011450m12e0bd5ala946cb3c092a72f4@mail.gmail.com> References: <7a41c4bc0706011450m12e0bd5ala946cb3c092a72f4@mail.gmail.com> Message-ID: <4660F73D.4040601@redhat.com> Paulo Santos wrote: > Mike, > > Im getting some IOerrors in the apache logs and as such I would like to > propose a set of tests in starting next week or the week afterwards. > [Fri Jun 01 12:29:04 2007] [error] [client 10.8.32.56] PythonHandler > MoinMoin.request::RequestModPy.run: IOError: Write failed, client closed > connection. > > Also lots of mod_python errors in the error_log > > Setup the wiki in a 1 (or 2) to 1 like it was in the old days. > proxy1 -> app1 > proxy2 -> app1 > > No load balancers or anything other thing out of a normal ProxyPass. > I would like to try this, so make sure that its not anything regarding > the > new LoadBalancer functionalities that you've added in the past weeks. > > It should be enough to run this test for half a day... > > Any comments ? Yeah, we've actually always gotten these. The moin developers say its when a user clicks on "stop". I don't consider that an error, but they do :-/ -Mike From mmcgrath at redhat.com Sat Jun 2 05:03:32 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 02 Jun 2007 00:03:32 -0500 Subject: Wiki - Recent Changes In-Reply-To: <4660F618.4010700@redhat.com> References: <4660F618.4010700@redhat.com> Message-ID: <4660FA24.2040401@redhat.com> Mike McGrath wrote: > Next time we have a failure in "RecentChanges" please leave it borked > (but let me or let ThomasWaldmann in #moin know). Fix any pages that > don't come up but leave the master edit log alone, the moin developers > are going to take a closer look. Actually if a page breaks leave it be and let me or ThomasWaldmann know. Just use your better judgement, if its something like FedoraMain obviously fix it but if its something with less traffic let it stay broken. -Mike From sundaram at fedoraproject.org Sat Jun 2 08:27:41 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 13:57:41 +0530 Subject: Docs site Message-ID: <466129FD.8070200@fedoraproject.org> Hi http://docs.fedoraproject.org/release-notes which is linked from the release announcement doesn't work properly. Rahul From mmcgrath at redhat.com Sat Jun 2 09:06:42 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 02 Jun 2007 04:06:42 -0500 Subject: Docs site In-Reply-To: <466129FD.8070200@fedoraproject.org> References: <466129FD.8070200@fedoraproject.org> Message-ID: <46613322.8000606@redhat.com> Rahul Sundaram wrote: > Hi > > http://docs.fedoraproject.org/release-notes which is linked from the > release announcement doesn't work properly. Which release announcement are you referring? http://docs.fedoraproject.org/release-notes/ works just fine. I'm fixing the '/' now. -Mike From sundaram at fedoraproject.org Sat Jun 2 09:12:34 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 14:42:34 +0530 Subject: Docs site In-Reply-To: <46613322.8000606@redhat.com> References: <466129FD.8070200@fedoraproject.org> <46613322.8000606@redhat.com> Message-ID: <46613482.60601@fedoraproject.org> Mike McGrath wrote: > Rahul Sundaram wrote: >> Hi >> >> http://docs.fedoraproject.org/release-notes which is linked from the >> release announcement doesn't work properly. > > Which release announcement are you referring? Fedora 7 > http://docs.fedoraproject.org/release-notes/ works just fine. No it doesn't. It redirects to http://app1.fedora.phx.redhat.com/docs/release-notes/ and the pages appear different. Links don't work. Do you need more information? Rahul From mmcgrath at redhat.com Sat Jun 2 09:15:26 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 02 Jun 2007 04:15:26 -0500 Subject: Docs site In-Reply-To: <46613482.60601@fedoraproject.org> References: <466129FD.8070200@fedoraproject.org> <46613322.8000606@redhat.com> <46613482.60601@fedoraproject.org> Message-ID: <4661352E.6050404@redhat.com> Rahul Sundaram wrote: > Mike McGrath wrote: >> Rahul Sundaram wrote: >>> Hi >>> >>> http://docs.fedoraproject.org/release-notes which is linked from the >>> release announcement doesn't work properly. >> >> Which release announcement are you referring? > > Fedora 7 > Please send me a link to which release announcement you are referring to. -Mike From mmcgrath at redhat.com Sat Jun 2 09:16:36 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 02 Jun 2007 04:16:36 -0500 Subject: Docs site In-Reply-To: <46613482.60601@fedoraproject.org> References: <466129FD.8070200@fedoraproject.org> <46613322.8000606@redhat.com> <46613482.60601@fedoraproject.org> Message-ID: <46613574.2000105@redhat.com> Rahul Sundaram wrote: > Mike McGrath wrote: >> Rahul Sundaram wrote: >>> Hi >>> >>> http://docs.fedoraproject.org/release-notes which is linked from the >>> release announcement doesn't work properly. >> >> Which release announcement are you referring? > > Fedora 7 > > >> http://docs.fedoraproject.org/release-notes/ works just fine. > > No it doesn't. It redirects to > http://app1.fedora.phx.redhat.com/docs/release-notes/ and the pages > appear different. Links don't work. > > Do you need more information? Yes, it actually does work: http://docs.fedoraproject.org/release-notes/ <-- click, works http://docs.fedoraproject.org/release-notes <--- click, doesn't work -Mike From sundaram at fedoraproject.org Sat Jun 2 09:19:06 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 14:49:06 +0530 Subject: Docs site In-Reply-To: <4661352E.6050404@redhat.com> References: <466129FD.8070200@fedoraproject.org> <46613322.8000606@redhat.com> <46613482.60601@fedoraproject.org> <4661352E.6050404@redhat.com> Message-ID: <4661360A.8000802@fedoraproject.org> Mike McGrath wrote: > Rahul Sundaram wrote: >> Mike McGrath wrote: >>> Rahul Sundaram wrote: >>>> Hi >>>> >>>> http://docs.fedoraproject.org/release-notes which is linked from the >>>> release announcement doesn't work properly. >>> >>> Which release announcement are you referring? >> >> Fedora 7 >> > Please send me a link to which release announcement you are referring to. There has only one official Fedora 7 release announcement. Not sure why there is so much confusion. https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00009.html Rahul From mmcgrath at redhat.com Sat Jun 2 09:24:28 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 02 Jun 2007 04:24:28 -0500 Subject: Docs site In-Reply-To: <4661360A.8000802@fedoraproject.org> References: <466129FD.8070200@fedoraproject.org> <46613322.8000606@redhat.com> <46613482.60601@fedoraproject.org> <4661352E.6050404@redhat.com> <4661360A.8000802@fedoraproject.org> Message-ID: <4661374C.9030802@redhat.com> Rahul Sundaram wrote: > Mike McGrath wrote: >> Rahul Sundaram wrote: >>> Mike McGrath wrote: >>>> Rahul Sundaram wrote: >>>>> Hi >>>>> >>>>> http://docs.fedoraproject.org/release-notes which is linked from >>>>> the release announcement doesn't work properly. >>>> >>>> Which release announcement are you referring? >>> >>> Fedora 7 >>> >> Please send me a link to which release announcement you are referring >> to. > > There has only one official Fedora 7 release announcement. Not sure > why there is so much confusion. > > https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00009.html > My confusion is that the release has been going on for a long time and this is the first report I've had of this. I wanted to see if I needed to drop everything I'm doing and fix it or if it was a minor thing that I could tend to later. I'm working on the fix now, expect it soon. -Mike From sundaram at fedoraproject.org Sat Jun 2 09:27:44 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 14:57:44 +0530 Subject: Docs site In-Reply-To: <4661374C.9030802@redhat.com> References: <466129FD.8070200@fedoraproject.org> <46613322.8000606@redhat.com> <46613482.60601@fedoraproject.org> <4661352E.6050404@redhat.com> <4661360A.8000802@fedoraproject.org> <4661374C.9030802@redhat.com> Message-ID: <46613810.9070908@fedoraproject.org> Mike McGrath wrote: >> https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00009.html >> > > My confusion is that the release has been going on for a long time and > this is the first report I've had of this. It used to work before. When I checked it out yesterday evening it didn't and I didnt have access to mail then. Just reporting now. I wanted to see if I needed > to drop everything I'm doing and fix it or if it was a minor thing that > I could tend to later. I'm working on the fix now, expect it soon. Thanks. Rahul From marek at mahut.sk Sat Jun 2 10:03:14 2007 From: marek at mahut.sk (Marek Mahut) Date: Sat, 02 Jun 2007 12:03:14 +0200 Subject: Wiki - Recent Changes In-Reply-To: <4660F618.4010700@redhat.com> References: <4660F618.4010700@redhat.com> Message-ID: <46614062.6030008@mahut.sk> Mike, Mike McGrath wrote: > Next time we have a failure in "RecentChanges" please leave it borked > (but let me or let ThomasWaldmann in #moin know). Fix any pages that > don't come up but leave the master edit log alone, the moin developers > are going to take a closer look. It's broken right now. -- Marek Mahut Tel.: +420-532-294-111 (ex. 826-2046) Fedora Ambassador GSM: +420-731-076-674 http://www.fedoraproject.org http://www.jamendo.com ____________________________________________________________________ From sundaram at fedoraproject.org Sat Jun 2 11:16:34 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 16:46:34 +0530 Subject: boot.iso folder location Message-ID: <46615192.3020608@fedoraproject.org> Hi Boot.iso images are not in the usual location as other images. Either we need to move it or alteast provide a symlink since many end users are not aware of its presence. https://www.redhat.com/archives/fedora-list/2007-June/msg00430.html Comments? Rahul From johan-fedora at deds.nl Sat Jun 2 11:30:07 2007 From: johan-fedora at deds.nl (Johan Kok) Date: Sat, 2 Jun 2007 13:30:07 +0200 Subject: Docs site In-Reply-To: <4661374C.9030802@redhat.com> References: <466129FD.8070200@fedoraproject.org> <46613322.8000606@redhat.com> <46613482.60601@fedoraproject.org> <4661352E.6050404@redhat.com> <4661360A.8000802@fedoraproject.org> <4661374C.9030802@redhat.com> Message-ID: On 2-jun-2007, at 11:24, Mike McGrath wrote: > My confusion is that the release has been going on for a long time > and this is the first report I've had of this. I wanted to see if > I needed to drop everything I'm doing and fix it or if it was a > minor thing that I could tend to later. I'm working on the fix > now, expect it soon. Mirrormanager appears to have the same 'feature'. There's no link (and therefore no high priority) but I accidently forgot to type the trailing slash and http://mirrors.fedoraproject.org/publiclist/Fedora/ 7 ended up at http://app4.fedora.phx.redhat.com/mirrorlists/ publiclist//Fedora/7/ Regards, Johan From mmcgrath at redhat.com Sat Jun 2 12:01:23 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 02 Jun 2007 07:01:23 -0500 Subject: Docs site In-Reply-To: References: <466129FD.8070200@fedoraproject.org> <46613322.8000606@redhat.com> <46613482.60601@fedoraproject.org> <4661352E.6050404@redhat.com> <4661360A.8000802@fedoraproject.org> <4661374C.9030802@redhat.com> Message-ID: <46615C13.3070603@redhat.com> Johan Kok wrote: > > On 2-jun-2007, at 11:24, Mike McGrath wrote: >> My confusion is that the release has been going on for a long time >> and this is the first report I've had of this. I wanted to see if I >> needed to drop everything I'm doing and fix it or if it was a minor >> thing that I could tend to later. I'm working on the fix now, expect >> it soon. > > Mirrormanager appears to have the same 'feature'. There's no link (and > therefore no high priority) but I accidently forgot to type the > trailing slash and > http://mirrors.fedoraproject.org/publiclist/Fedora/7 ended up at > http://app4.fedora.phx.redhat.com/mirrorlists/publiclist//Fedora/7/ Fixed, same issue. -Mike From jkeating at redhat.com Sat Jun 2 13:11:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 2 Jun 2007 09:11:54 -0400 Subject: boot.iso folder location In-Reply-To: <46615192.3020608@fedoraproject.org> References: <46615192.3020608@fedoraproject.org> Message-ID: <200706020911.54357.jkeating@redhat.com> On Saturday 02 June 2007 07:16:34 Rahul Sundaram wrote: > Boot.iso images are not in the usual location as other images. Either we > need to move it or alteast provide a symlink since many end users are > not aware of its presence. > > https://www.redhat.com/archives/fedora-list/2007-June/msg00430.html AFAIK boot.iso has never been in that directory, it has always been in the images/ directory, along with the images for USB / PXE and such. We recently (FC6?) put the rescue iso into the isos/ directory for better finding, and I'm up for renaming this iso to something difference since it is confusing that the rescue iso can do installs too. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Sat Jun 2 13:19:54 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 18:49:54 +0530 Subject: boot.iso folder location In-Reply-To: <200706020911.54357.jkeating@redhat.com> References: <46615192.3020608@fedoraproject.org> <200706020911.54357.jkeating@redhat.com> Message-ID: <46616E7A.60702@fedoraproject.org> Jesse Keating wrote: > On Saturday 02 June 2007 07:16:34 Rahul Sundaram wrote: >> Boot.iso images are not in the usual location as other images. Either we >> need to move it or alteast provide a symlink since many end users are >> not aware of its presence. >> >> https://www.redhat.com/archives/fedora-list/2007-June/msg00430.html > > AFAIK boot.iso has never been in that directory, it has always been in the > images/ directory, along with the images for USB / PXE and such. Can't you move that all into a single location or provide a symlink? It has always been like that way in the past isn't a sufficient reason to justify the lack of visibility and awareness of the presence of boot.iso. Every release I see claims that Fedora does not support easy network installation due to this tree structure. Rahul From jkeating at redhat.com Sat Jun 2 13:28:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 2 Jun 2007 09:28:37 -0400 Subject: boot.iso folder location In-Reply-To: <46616E7A.60702@fedoraproject.org> References: <46615192.3020608@fedoraproject.org> <200706020911.54357.jkeating@redhat.com> <46616E7A.60702@fedoraproject.org> Message-ID: <200706020928.37673.jkeating@redhat.com> On Saturday 02 June 2007 09:19:54 Rahul Sundaram wrote: > Can't you move that all into a single location or provide a symlink? It > has always been like that way in the past isn't a sufficient reason to > justify the lack of visibility and awareness of the presence of boot.iso. > > Every release I see claims that Fedora does not support easy network > installation due to this tree structure. Rescue.iso is there which is even easier for network installs as it has stage2 already there. I'm not about to go changing the tree layout after the mirrors already have it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Sat Jun 2 13:39:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 19:09:55 +0530 Subject: boot.iso folder location In-Reply-To: <200706020928.37673.jkeating@redhat.com> References: <46615192.3020608@fedoraproject.org> <200706020911.54357.jkeating@redhat.com> <46616E7A.60702@fedoraproject.org> <200706020928.37673.jkeating@redhat.com> Message-ID: <4661732B.506@fedoraproject.org> Jesse Keating wrote: > On Saturday 02 June 2007 09:19:54 Rahul Sundaram wrote: >> Can't you move that all into a single location or provide a symlink? It >> has always been like that way in the past isn't a sufficient reason to >> justify the lack of visibility and awareness of the presence of boot.iso. >> >> Every release I see claims that Fedora does not support easy network >> installation due to this tree structure. > > Rescue.iso is there which is even easier for network installs as it has stage2 > already there. It is larger too and you call it "rescue" which does not suggest network installation. > I'm not about to go changing the tree layout after the mirrors already have > it. Just in case it was not obvious I am talking about changing the tree structure to consolidate all the images for the *next release*. Rahul From jkeating at redhat.com Sat Jun 2 13:41:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 2 Jun 2007 09:41:05 -0400 Subject: boot.iso folder location In-Reply-To: <4661732B.506@fedoraproject.org> References: <46615192.3020608@fedoraproject.org> <200706020928.37673.jkeating@redhat.com> <4661732B.506@fedoraproject.org> Message-ID: <200706020941.05290.jkeating@redhat.com> On Saturday 02 June 2007 09:39:55 Rahul Sundaram wrote: > It is larger too and you call it "rescue" which does not suggest network > installation. > > > I'm not about to go changing the tree layout after the mirrors already > > have it. > > Just in case it was not obvious I am talking about changing the tree > structure to consolidate all the images for the *next release*. Next release is something I would talk about, with the anaconda folks, since they write out the boot.iso. As stated before I want to rename rescue.iso as well so that it is more obvious that you can use it for installs. Rescue.iso is no longer than what you'd get if you booted boot.iso and it downloads the stage2 images to do the install, only instead of downloading it each and every install you can have it on the media already. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Sat Jun 2 13:49:30 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 19:19:30 +0530 Subject: boot.iso folder location In-Reply-To: <200706020941.05290.jkeating@redhat.com> References: <46615192.3020608@fedoraproject.org> <200706020928.37673.jkeating@redhat.com> <4661732B.506@fedoraproject.org> <200706020941.05290.jkeating@redhat.com> Message-ID: <4661756A.30400@fedoraproject.org> Jesse Keating wrote: > On Saturday 02 June 2007 09:39:55 Rahul Sundaram wrote: >> It is larger too and you call it "rescue" which does not suggest network >> installation. >> >>> I'm not about to go changing the tree layout after the mirrors already >>> have it. >> Just in case it was not obvious I am talking about changing the tree >> structure to consolidate all the images for the *next release*. > > Next release is something I would talk about, with the anaconda folks, since > they write out the boot.iso. If they are not willing to change the location for some reason please consider providing a symlink. IIRC the RFE I filed around FC5 time is still open on this. As stated before I want to rename rescue.iso as > well so that it is more obvious that you can use it for installs. Ok. Rahul From jkeating at redhat.com Sat Jun 2 13:48:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 2 Jun 2007 09:48:31 -0400 Subject: boot.iso folder location In-Reply-To: <4661756A.30400@fedoraproject.org> References: <46615192.3020608@fedoraproject.org> <200706020941.05290.jkeating@redhat.com> <4661756A.30400@fedoraproject.org> Message-ID: <200706020948.32010.jkeating@redhat.com> On Saturday 02 June 2007 09:49:30 Rahul Sundaram wrote: > If they are not willing to change the location for some reason please > consider providing a symlink. ?IIRC the RFE I filed around FC5 time is > still open on this. With a renamed rescue image, that should be what we recommend people use. Having multiple "small" isos in there to start network installs is just confusing. boot.iso could go away all together perhaps. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cra at WPI.EDU Sat Jun 2 13:55:24 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Sat, 2 Jun 2007 09:55:24 -0400 Subject: boot.iso folder location In-Reply-To: <200706020948.32010.jkeating@redhat.com> References: <46615192.3020608@fedoraproject.org> <200706020941.05290.jkeating@redhat.com> <4661756A.30400@fedoraproject.org> <200706020948.32010.jkeating@redhat.com> Message-ID: <20070602135524.GA21424@angus.ind.WPI.EDU> On Sat, Jun 02, 2007 at 09:48:31AM -0400, Jesse Keating wrote: > With a renamed rescue image, that should be what we recommend people use. > Having multiple "small" isos in there to start network installs is just > confusing. boot.iso could go away all together perhaps. +1. You have to download boot.iso now + stage2 later, or rescue.iso now to do a network install. From mmcgrath at redhat.com Sat Jun 2 15:44:22 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 02 Jun 2007 10:44:22 -0500 Subject: Wiki - Recent Changes In-Reply-To: <46614062.6030008@mahut.sk> References: <4660F618.4010700@redhat.com> <46614062.6030008@mahut.sk> Message-ID: <46619056.90608@redhat.com> Marek Mahut wrote: > Mike, > > Mike McGrath wrote: >> Next time we have a failure in "RecentChanges" please leave it borked >> (but let me or let ThomasWaldmann in #moin know). Fix any pages that >> don't come up but leave the master edit log alone, the moin >> developers are going to take a closer look. > > It's broken right now. > Ok, the Moin developers had me add a few lines to the bottom of their logging system. Basically its just an explicit close of the log file followed by a destroy of the logfile object. Its in place now and the log file has been fixed. Lets keep an eye on it for a couple of days (fingers crossed) -Mike From kwade at redhat.com Sat Jun 2 15:48:30 2007 From: kwade at redhat.com (Karsten Wade) Date: Sat, 02 Jun 2007 08:48:30 -0700 Subject: click-through CLA for the Wiki Message-ID: <1180799310.4459.98.camel@erato.phig.org> Can someone help implement $SUBJECT with me? As per the layers set here: http://fedoraproject.org/wiki/KarstenWade/Drafts/CLAAcceptanceHierarchies A pure Wiki-contributor no longer needs to do the signed-GPG CLA. We can find a canonical location for that page now. Instead what is needed is for the user, when creating a new Wiki-account, read through and agree to the CLA as a click-through form. Then we can drop the ACL restriction and use of EditGroup. Hallelujah! I see two generic ways to implement: 1. Wiki-only -- no attempt is made to tie the NewAccount to an associated FAS account; we rely upon Moin Moin authentication to affirm that FooPerson has read and approved the CLA; we continue with the WikiLicense as a reminder of the obligation agreed to. 2. Tie into FAS -- the new FooPerson would get an associated FAS account and a be part of a new group 'cla_wiki'; the advantage is if we get additional Web tools that would require the click-through, we can grant access to people who have already run the gauntlet instead of making them click through again. Anyway, those are just my ideas. And you'll note that, looking at the above, there is almost nothing that I know how or have access to do, so I'm turning to y'all for a volunteer. :) - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Sat Jun 2 17:54:04 2007 From: kwade at redhat.com (Karsten Wade) Date: Sat, 02 Jun 2007 10:54:04 -0700 Subject: proxy server acting up Message-ID: <1180806844.4459.105.camel@erato.phig.org> One (or more) of the proxies, perhaps proxy1, is acting up. It is serving incorrect, old, or misplaced content to various requests. Most commonly, it seems to be serving rhold.fp.o in place of fp.o, fp.o/wiki, and docs.fp.o. Seems to have started around 1700 UTC or earlier, today 02 Jun. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stefmanos at gmail.com Sat Jun 2 16:09:59 2007 From: stefmanos at gmail.com (Stephanos Manos) Date: Sat, 02 Jun 2007 19:09:59 +0300 Subject: Problem with updates & updates-testing repo Message-ID: Hi Apologies for the noise if this is not the right place to report this it seams that the createrepo script didn't run correctly for updates-7 & updates-7-testing since it includes the debuginfo packages The problem is visible either with cli yum or gui tools like yumex The fix is running createrepo with -x debug/* that results in quicker run and smaller metadata files Stephanos From a.badger at gmail.com Sat Jun 2 03:34:34 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 01 Jun 2007 20:34:34 -0700 Subject: new python-fedora Message-ID: <1180755274.19774.137.camel@localhost.localdomain> After looking at a traceback from Bodhi, I put together a new python-fedora to hopefully address that. It's available from my home directory on bastion: /home/fedora/toshio/python-fedora-0.2.90.8-1.noarch.rpm I've only tested this on the pkgdb test machines so if you still have a test instance, try it out there before loading it onto the main instances of mirrormanager, Bodhi, etc. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Sat Jun 2 22:16:20 2007 From: notting at redhat.com (Bill Nottingham) Date: Sat, 2 Jun 2007 18:16:20 -0400 Subject: Problem with updates & updates-testing repo In-Reply-To: References: Message-ID: <20070602221620.GA12120@nostromo.devel.redhat.com> Stephanos Manos (stefmanos at gmail.com) said: > Apologies for the noise if this is not the right place to report this > > it seams that the createrepo script didn't run correctly for updates-7 & > updates-7-testing since it includes the debuginfo packages > > The problem is visible either with cli yum or gui tools like yumex > > The fix is running createrepo with -x debug/* that results in quicker > run and smaller metadata files Yes, we'll get this fixed. Bill From dimitris at glezos.com Sun Jun 3 00:37:07 2007 From: dimitris at glezos.com (Dimitris Glezos) Date: Sun, 03 Jun 2007 01:37:07 +0100 Subject: L10n web infrastructure Message-ID: <46620D33.60109@glezos.com> Hey guys. We've got our L10N GSoC project started, so we'll be needing a place to put 'l10n.fedoraproject.org' soon. Basically, we'll put a python Web UI up there first, and then start experimenting to use it as an intermediate to fetch PO files from remote SCMs to members of the 'cvsl10n' group. There's an RFR open for it: http://fedoraproject.org/wiki/Infrastructure/RFR/L10nCVSandUI The python thingy is GNOME's Damned Lies, and requires either SQLite or MySQL. -d -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From josemanimala at gmail.com Sun Jun 3 05:06:49 2007 From: josemanimala at gmail.com (jose manimala) Date: Sat, 2 Jun 2007 22:06:49 -0700 Subject: Voting Application Message-ID: <53a863600706022206s36ad47a8sdc14fec394c7fd3@mail.gmail.com> Any updates on the voting application!! -- Jose M Manimala S6 Computer science and engineering Rajagiri School Of Engineering And Technology Ph: +919846367850 http://www.jmm-blog.co.nr GPGkeyID: 98FF52D2 From josemanimala at gmail.com Sun Jun 3 05:08:38 2007 From: josemanimala at gmail.com (jose manimala) Date: Sat, 2 Jun 2007 22:08:38 -0700 Subject: Voting App Message-ID: <53a863600706022208u6a0cfd81n8305982a57547824@mail.gmail.com> Any updates on the voting app. Let me know if there is anything!! -- Jose M Manimala S6 Computer science and engineering Rajagiri School Of Engineering And Technology Ph: +919846367850 http://www.jmm-blog.co.nr GPGkeyID: 98FF52D2 From josemanimala at gmail.com Sun Jun 3 05:10:17 2007 From: josemanimala at gmail.com (jose manimala) Date: Sat, 2 Jun 2007 22:10:17 -0700 Subject: hey Message-ID: <53a863600706022210v448b8775v86a29123788cbdf6@mail.gmail.com> any updates on the voting application please let know. -- Jose M Manimala S6 Computer science and engineering Rajagiri School Of Engineering And Technology Ph: +919846367850 http://www.jmm-blog.co.nr GPGkeyID: 98FF52D2 From tchung at fedoraproject.org Sun Jun 3 06:28:00 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Sat, 2 Jun 2007 23:28:00 -0700 Subject: Fedora 7 Update Informatin for general users Message-ID: <369bce3b0706022328m2f2fe419hd62a447b97c05d98@mail.gmail.com> First all, thank you for Fedora Update System. It's wonderful to see that we finally have something we always wanted. While looking at the list of Stable Updates for Fedora 7[1], it gives me an idea that this could replace our static Fedora Security Advisories and Package Updates for Fedora 7[1] on our project wiki. What do you think? Could we open this system up so any general users can see this information anonymously without logging-in with Fedora Account System? Perhaps, we could create a new page specifically for anonymous users without comments field? This will be an enormous help and save my *endless-efforts* to update the wiki pages manually. :) Best Regards, [1] https://admin.fedoraproject.org/updates/F7 [2] http://fedoraproject.org/wiki/FSA/F7 -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From marek at mahut.sk Sun Jun 3 09:43:28 2007 From: marek at mahut.sk (Marek Mahut) Date: Sun, 03 Jun 2007 11:43:28 +0200 Subject: Fedora 7 Update Informatin for general users In-Reply-To: <369bce3b0706022328m2f2fe419hd62a447b97c05d98@mail.gmail.com> References: <369bce3b0706022328m2f2fe419hd62a447b97c05d98@mail.gmail.com> Message-ID: <46628D40.8090706@mahut.sk> Thomas Chung wrote: > First all, thank you for Fedora Update System. > It's wonderful to see that we finally have something we always wanted. > > While looking at the list of Stable Updates for Fedora 7[1], it gives > me an idea that this could replace our static Fedora Security > Advisories and Package Updates for Fedora 7[1] on our project wiki. > > What do you think? Could we open this system up so any general users > can see this information anonymously without logging-in with Fedora > Account System? I think it's a very good idea to open this system for public. > Perhaps, we could create a new page specifically for anonymous users > without comments field? > > This will be an enormous help and save my *endless-efforts* to update > the wiki pages manually. :) > > Best Regards, > > [1] https://admin.fedoraproject.org/updates/F7 > [2] http://fedoraproject.org/wiki/FSA/F7 -- Marek Mahut Tel.: +420-532-294-111 (ex. 826-2046) Fedora Ambassador GSM: +420-731-076-674 http://www.fedoraproject.org http://www.jamendo.com ____________________________________________________________________ From a.badger at gmail.com Sun Jun 3 08:59:26 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 03 Jun 2007 01:59:26 -0700 Subject: Voting App (was Re: hey) In-Reply-To: <53a863600706022210v448b8775v86a29123788cbdf6@mail.gmail.com> References: <53a863600706022210v448b8775v86a29123788cbdf6@mail.gmail.com> Message-ID: <1180861166.30126.40.camel@localhost.localdomain> On Sat, 2007-06-02 at 22:10 -0700, jose manimala wrote: > any updates on the voting application please let know. > Hey Jose, Does this page make sense? http://fedoraproject.org/wiki/Infrastructure/VotingApp2 If you have any questions about the goals send an email. Otherwise you can start coding. The voting project needs someone to own it and put some initial code out there. If it doesn't look like a fun project for you say that as well and we can keep looking around for other things that need doing. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From josemanimala at gmail.com Mon Jun 4 04:36:13 2007 From: josemanimala at gmail.com (jose manimala) Date: Mon, 4 Jun 2007 10:06:13 +0530 Subject: Voting App (was Re: hey) In-Reply-To: <1180861166.30126.40.camel@localhost.localdomain> References: <53a863600706022210v448b8775v86a29123788cbdf6@mail.gmail.com> <1180861166.30126.40.camel@localhost.localdomain> Message-ID: <53a863600706032136k54ecfa26pf7e40992d0f32b55@mail.gmail.com> the project is a little dry. the biggest problem i am facing is trying to understand the turbogear architecture. i dont mind working on it, but how do i modify turbo gear code. it starts up and shows me a website and everything seems to be fine, but i cannot still seem to understand turbo gears thats all. everything else is fine i guess... From frosario777 at gmail.com Mon Jun 4 05:06:58 2007 From: frosario777 at gmail.com (Freddie Rosario) Date: Sun, 3 Jun 2007 22:06:58 -0700 Subject: Voting App (was Re: hey) In-Reply-To: <53a863600706032136k54ecfa26pf7e40992d0f32b55@mail.gmail.com> References: <53a863600706022210v448b8775v86a29123788cbdf6@mail.gmail.com> <1180861166.30126.40.camel@localhost.localdomain> <53a863600706032136k54ecfa26pf7e40992d0f32b55@mail.gmail.com> Message-ID: Jose, There are a few resources you could use to learn TurboGears. You can get the book at http://www.turbogearsbook.com If you don't feel like buying the book, like me, you could check out these two tutorials to get you started: http://aymanh.com/turbogears-tutorial-social-bookmarking-application http://exogen.case.edu/turbogears.html These tutorials are not comprehensive by any criteria but you could always hunt down the documentation to the individual parts. On 6/3/07, jose manimala wrote: > > the project is a little dry. the biggest problem i am facing is trying > to understand the turbogear architecture. i dont mind working on it, > but how do i modify turbo gear code. it starts up and shows me a > website and everything seems to be fine, but i cannot still seem to > understand turbo gears thats all. everything else is fine i guess... > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- --Freddie -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmacken at redhat.com Mon Jun 4 05:37:18 2007 From: lmacken at redhat.com (Luke Macken) Date: Mon, 4 Jun 2007 01:37:18 -0400 Subject: new python-fedora In-Reply-To: <1180755274.19774.137.camel@localhost.localdomain> References: <1180755274.19774.137.camel@localhost.localdomain> Message-ID: <20070604053718.GK13318@tomservo.rochester.rr.com> On Fri, Jun 01, 2007 at 08:34:34PM -0700, Toshio Kuratomi wrote: > After looking at a traceback from Bodhi, I put together a new > python-fedora to hopefully address that. It's available from my home > directory on bastion: > /home/fedora/toshio/python-fedora-0.2.90.8-1.noarch.rpm > > I've only tested this on the pkgdb test machines so if you still have a > test instance, try it out there before loading it onto the main > instances of mirrormanager, Bodhi, etc. Seems to be working fine for me. I've been testing it for the past couple of days in my test instance, and deployed it tonight on app5 for bodhi. We should probably find a home for this thing in git/hg/whatev. luke From gerold at lugd.org Mon Jun 4 10:40:22 2007 From: gerold at lugd.org (Gerold Kassube) Date: Mon, 04 Jun 2007 12:40:22 +0200 Subject: wiki down? Message-ID: <1180953623.5090.1.camel@Amilo-GK.homenet.local> Hi all, ... the wiki seems down; could pls. anybody have a look because of I think Mike is already on his trip home from Europe ... ... and has maybe no possibility to have a look himself :-( Thanks -- Regards Gerold Kassube Fedora Ambassador Deutschland / Germany Schweiz / Switzerland Email: GeroldKa at fedoraproject.org 1024D/F33128B9 4ABC A903 F1F4 D9CC C422 AACA EDF1 DF42 F331 28B9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From marek at mahut.sk Mon Jun 4 11:30:22 2007 From: marek at mahut.sk (Marek Mahut) Date: Mon, 04 Jun 2007 13:30:22 +0200 Subject: wiki down? In-Reply-To: <1180953623.5090.1.camel@Amilo-GK.homenet.local> References: <1180953623.5090.1.camel@Amilo-GK.homenet.local> Message-ID: <4663F7CE.90001@mahut.sk> Hey, Gerold Kassube wrote: > Hi all, ... > > the wiki seems down; could pls. anybody have a look because of I think > Mike is already on his trip home from Europe ... > > ... and has maybe no possibility to have a look himself :-( Indeed it's down, but everybody are away :( > Thanks -- Marek Mahut Tel.: +420-532-294-111 (ex. 826-2046) Fedora Ambassador GSM: +420-731-076-674 http://www.fedoraproject.org http://www.jamendo.com ____________________________________________________________________ From marek at mahut.sk Mon Jun 4 12:19:37 2007 From: marek at mahut.sk (Marek Mahut) Date: Mon, 04 Jun 2007 14:19:37 +0200 Subject: wiki down? In-Reply-To: <4663F7CE.90001@mahut.sk> References: <1180953623.5090.1.camel@Amilo-GK.homenet.local> <4663F7CE.90001@mahut.sk> Message-ID: <46640359.9090801@mahut.sk> Looks like wiki is up again, thanks to Dennis. Marek Mahut wrote: > Hey, > > Gerold Kassube wrote: >> Hi all, ... >> >> the wiki seems down; could pls. anybody have a look because of I think >> Mike is already on his trip home from Europe ... >> >> ... and has maybe no possibility to have a look himself :-( > > Indeed it's down, but everybody are away :( > >> Thanks > > -- Marek Mahut Tel.: +420-532-294-111 (ex. 826-2046) Fedora Ambassador GSM: +420-731-076-674 http://www.fedoraproject.org http://www.jamendo.com ____________________________________________________________________ From kwade at redhat.com Mon Jun 4 19:05:52 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 04 Jun 2007 12:05:52 -0700 Subject: wiki down? In-Reply-To: <46640359.9090801@mahut.sk> References: <1180953623.5090.1.camel@Amilo-GK.homenet.local> <4663F7CE.90001@mahut.sk> <46640359.9090801@mahut.sk> Message-ID: <1180983952.4459.263.camel@erato.phig.org> On Mon, 2007-06-04 at 14:19 +0200, Marek Mahut wrote: > Looks like wiki is up again, thanks to Dennis. FWIW, I'm in favor of moving docs.fp.o off app1 (or whatever). Having it and the wiki hitting the same hardware/Xen host seems to be the biggest problem right now. In fact, of all the things that went *fantastic* on the Infrastructure side since the launch, this is the one little detail that bloomed into a problem. Consider it another lesson for the future -- make sure the content machine can handle the load when everyone does as we tell them and goes to read the release notes. :) ... because we did tell them to read them, and put up prominent links, and everything. And they responded, I reckon. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mmcgrath at redhat.com Mon Jun 4 19:16:53 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 04 Jun 2007 14:16:53 -0500 Subject: wiki down? In-Reply-To: <1180983952.4459.263.camel@erato.phig.org> References: <1180953623.5090.1.camel@Amilo-GK.homenet.local> <4663F7CE.90001@mahut.sk> <46640359.9090801@mahut.sk> <1180983952.4459.263.camel@erato.phig.org> Message-ID: <46646525.2040204@redhat.com> Karsten Wade wrote: > On Mon, 2007-06-04 at 14:19 +0200, Marek Mahut wrote: > >> Looks like wiki is up again, thanks to Dennis. >> > > FWIW, I'm in favor of moving docs.fp.o off app1 (or whatever). Having > it and the wiki hitting the same hardware/Xen host seems to be the > biggest problem right now. > > In fact, of all the things that went *fantastic* on the Infrastructure > side since the launch, this is the one little detail that bloomed into a > problem. Consider it another lesson for the future -- make sure the > content machine can handle the load when everyone does as we tell them > and goes to read the release notes. :) > > ... because we did tell them to read them, and put up prominent links, > and everything. And they responded, I reckon. > Actually the docs site is spread across multiple machines now. Can you confirm docs.fedoraproject.org was down during the wiki outage? I'll add it to nagios now. -Mike From mmahut at fedoraproject.org Mon Jun 4 21:10:18 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Mon, 04 Jun 2007 23:10:18 +0200 Subject: Presentation of myself Message-ID: <46647FBA.1000206@fedoraproject.org> Hello all, It's the time to present myself. My name is Marek and I'm working for one big software company right now. Before I was in HP support, administrating HP-UX, linux and few AIXs. I really want help you to maintenance fedora project infrastructures, basically from admin side, but maybe form devel as well. I think that it's maybe a good idea to build an escalation paths for infrastructure, to assure that at any time, there will be someone to fix things or get in touch with someone who can in case of problems. Let me know how can I help and what do you think about my idea. -- Marek Mahut Tel.: +420-532-294-111 (ex. 826-2046) Fedora Ambassador GSM: +420-731-076-674 http://www.fedoraproject.org http://www.jamendo.com ____________________________________________________________________ From mmcgrath at redhat.com Mon Jun 4 21:22:39 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 04 Jun 2007 16:22:39 -0500 Subject: Presentation of myself In-Reply-To: <46647FBA.1000206@fedoraproject.org> References: <46647FBA.1000206@fedoraproject.org> Message-ID: <4664829F.3060004@redhat.com> Marek Mahut wrote: > Hello all, > > It's the time to present myself. My name is Marek and I'm working for > one big software company right now. Before I was in HP support, > administrating HP-UX, linux and few AIXs. I really want help you to > maintenance fedora project infrastructures, basically from admin side, > but maybe form devel as well. > > I think that it's maybe a good idea to build an escalation paths for > infrastructure, to assure that at any time, there will be someone to > fix things or get in touch with someone who can in case of problems. Its not a bad idea really except everything will ever get fixed right away or will escalate to me I think. I'm typically notified though last night didn't have my phone on :) Having said that though, some volunteers may want to be called. Thats entirely up to them. One thing that may be good is to create a sysadmin list with the appropriate timezone everyone is in. -Mike From mmahut at fedoraproject.org Mon Jun 4 21:30:15 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Mon, 04 Jun 2007 23:30:15 +0200 Subject: Presentation of myself In-Reply-To: <4664829F.3060004@redhat.com> References: <46647FBA.1000206@fedoraproject.org> <4664829F.3060004@redhat.com> Message-ID: <46648467.9000701@fedoraproject.org> Mike McGrath wrote: > Marek Mahut wrote: >> Hello all, >> >> It's the time to present myself. My name is Marek and I'm working for >> one big software company right now. Before I was in HP support, >> administrating HP-UX, linux and few AIXs. I really want help you to >> maintenance fedora project infrastructures, basically from admin side, >> but maybe form devel as well. >> >> I think that it's maybe a good idea to build an escalation paths for >> infrastructure, to assure that at any time, there will be someone to >> fix things or get in touch with someone who can in case of problems. > > Its not a bad idea really except everything will ever get fixed right > away or will escalate to me I think. I'm typically notified though last > night didn't have my phone on :) Having said that though, some > volunteers may want to be called. Thats entirely up to them. > One thing that may be good is to create a sysadmin list with the > appropriate timezone everyone is in. In fact, and maybe with pages or cell numbers (for sms only, of course) too. I propose to do it as static html page, in case wiki goes down ;) -- Marek Mahut Tel.: +420-532-294-111 (ex. 826-2046) Fedora Ambassador GSM: +420-731-076-674 http://www.fedoraproject.org http://www.jamendo.com ____________________________________________________________________ From justin.randell at gmail.com Mon Jun 4 21:56:18 2007 From: justin.randell at gmail.com (justin randell) Date: Tue, 5 Jun 2007 07:56:18 +1000 Subject: wiki down? In-Reply-To: <46646525.2040204@redhat.com> References: <1180953623.5090.1.camel@Amilo-GK.homenet.local> <4663F7CE.90001@mahut.sk> <46640359.9090801@mahut.sk> <1180983952.4459.263.camel@erato.phig.org> <46646525.2040204@redhat.com> Message-ID: <34a99ab40706041456i377c2e6fy41fea879b823c892@mail.gmail.com> On 6/5/07, Mike McGrath wrote: > > Actually the docs site is spread across multiple machines now. Can you > confirm docs.fedoraproject.org was down during the wiki outage? I'll > add it to nagios now. yes, docs was unresponsive during the wiki issues. small thing - its probably a good idea to turn off the Etag headers for the docs site and use Expires headers. should reduce the http requests a little, which will make everything scale a bit better. (Etag headers don't work so well on multiple machines - inode-size-timestamp - so the same content will get a different tag depending on which machine it came from.) cheers justin From mmcgrath at redhat.com Mon Jun 4 22:04:34 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 04 Jun 2007 17:04:34 -0500 Subject: mod_fcgid Message-ID: <46648C72.3090504@redhat.com> the wiki is currently deployed using mod_fcgid. Puppet has been turned off so the config doesn't get overwritten. If anything breaks just restart puppet and let it do its thing (It could take a few minutes) and it should auto restart using the old mod_python method. If we make it through the night I'll commit the new configs. -Mike From wilmer at fedoraproject.org Mon Jun 4 22:58:59 2007 From: wilmer at fedoraproject.org (Wilmer Jaramillo M.) Date: Mon, 4 Jun 2007 18:58:59 -0400 Subject: Fedora 7 Update Informatin for general users In-Reply-To: <46628D40.8090706@mahut.sk> References: <369bce3b0706022328m2f2fe419hd62a447b97c05d98@mail.gmail.com> <46628D40.8090706@mahut.sk> Message-ID: <2b26c4260706041558j4a6b929eja5251b445fb3ad75@mail.gmail.com> On 6/3/07, Marek Mahut wrote: > Thomas Chung wrote: > > First all, thank you for Fedora Update System. > > It's wonderful to see that we finally have something we always wanted. > > > > While looking at the list of Stable Updates for Fedora 7[1], it gives > > me an idea that this could replace our static Fedora Security > > Advisories and Package Updates for Fedora 7[1] on our project wiki. > > > > What do you think? Could we open this system up so any general users > > can see this information anonymously without logging-in with Fedora > > Account System? > > I think it's a very good idea to open this system for public. +1 i like to participate -- Wilmer Jaramillo M. GPG Key Fingerprint = 0666 D0D3 24CE 8935 9C24 BBF1 87DD BEA2 A4B2 1E8A From wilmer at fedoraproject.org Mon Jun 4 23:47:21 2007 From: wilmer at fedoraproject.org (Wilmer Jaramillo M.) Date: Mon, 4 Jun 2007 19:47:21 -0400 Subject: Do Fedora static page handle Multi-Language requests automatically? In-Reply-To: <2b26c4260706041644r77e19422re26bb07fede8c28b@mail.gmail.com> References: <2b26c4260706041644r77e19422re26bb07fede8c28b@mail.gmail.com> Message-ID: <2b26c4260706041647j36ada346l14920e955877f0cc@mail.gmail.com> Forwarded message To: fedora-websites-list at redhat.com too. What possibility there is to translate the static page to multilanguage and to make it available to the community? respond to browser language requests with the corresponding translation via 'Accept-Language' request header field that it sends to the web server and later with mod_negotiation module or anything. For example, Apache web server would respond for the file fedoraproject.org/index.html.es or fedoraproject.org/index.html.br if the your browser preferred language is settting to Spanish or Brazilian respectively. -- Wilmer Jaramillo M. GPG Key Fingerprint = 0666 D0D3 24CE 8935 9C24 BBF1 87DD BEA2 A4B2 1E8A From mmcgrath at redhat.com Mon Jun 4 23:53:15 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 04 Jun 2007 18:53:15 -0500 Subject: Do Fedora static page handle Multi-Language requests automatically? In-Reply-To: <2b26c4260706041647j36ada346l14920e955877f0cc@mail.gmail.com> References: <2b26c4260706041644r77e19422re26bb07fede8c28b@mail.gmail.com> <2b26c4260706041647j36ada346l14920e955877f0cc@mail.gmail.com> Message-ID: <4664A5EB.2060208@redhat.com> Wilmer Jaramillo M. wrote: > Forwarded message To: fedora-websites-list at redhat.com too. > > What possibility there is to translate the static page to > multilanguage and to make it available to the community? respond to > browser language requests with the corresponding translation via > 'Accept-Language' request header field that it sends to the web server > and later with mod_negotiation module or anything. > > For example, Apache web server would respond for the file > fedoraproject.org/index.html.es or fedoraproject.org/index.html.br if > the your browser preferred language is settting to Spanish or > Brazilian respectively. Unfortunately the static pages were done very last minute (the finalized versions were done just a few days before F7). Now that the SoC stuff is in play, we're just waiting for damaestro to create a plone product for us. Once thats done we'll have a translation infrastructure in place to do this. -Mike From paulo.banon at googlemail.com Tue Jun 5 18:57:35 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Tue, 5 Jun 2007 20:57:35 +0200 Subject: Wiki - Recent Changes In-Reply-To: <46619056.90608@redhat.com> References: <4660F618.4010700@redhat.com> <46614062.6030008@mahut.sk> <46619056.90608@redhat.com> Message-ID: <7a41c4bc0706051157w71b506c8qdcb224fa8e3b0cb8@mail.gmail.com> Mike, RecentChanges are acting up again. I didnt fix anything so that you could take a look Thanks, Paulo On 6/2/07, Mike McGrath wrote: > > Marek Mahut wrote: > > Mike, > > > > Mike McGrath wrote: > >> Next time we have a failure in "RecentChanges" please leave it borked > >> (but let me or let ThomasWaldmann in #moin know). Fix any pages that > >> don't come up but leave the master edit log alone, the moin > >> developers are going to take a closer look. > > > > It's broken right now. > > > Ok, the Moin developers had me add a few lines to the bottom of their > logging system. Basically its just an explicit close of the log file > followed by a destroy of the logfile object. Its in place now and the > log file has been fixed. Lets keep an eye on it for a couple of days > (fingers crossed) > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paulo.banon at googlemail.com Tue Jun 5 18:57:35 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Tue, 5 Jun 2007 20:57:35 +0200 Subject: Wiki - Recent Changes In-Reply-To: <46619056.90608@redhat.com> References: <4660F618.4010700@redhat.com> <46614062.6030008@mahut.sk> <46619056.90608@redhat.com> Message-ID: <7a41c4bc0706051157w71b506c8qdcb224fa8e3b0cb8@mail.gmail.com> Mike, RecentChanges are acting up again. I didnt fix anything so that you could take a look Thanks, Paulo On 6/2/07, Mike McGrath wrote: > > Marek Mahut wrote: > > Mike, > > > > Mike McGrath wrote: > >> Next time we have a failure in "RecentChanges" please leave it borked > >> (but let me or let ThomasWaldmann in #moin know). Fix any pages that > >> don't come up but leave the master edit log alone, the moin > >> developers are going to take a closer look. > > > > It's broken right now. > > > Ok, the Moin developers had me add a few lines to the bottom of their > logging system. Basically its just an explicit close of the log file > followed by a destroy of the logfile object. Its in place now and the > log file has been fixed. Lets keep an eye on it for a couple of days > (fingers crossed) > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Tue Jun 5 20:12:11 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 05 Jun 2007 15:12:11 -0500 Subject: Backups Message-ID: <4665C39B.7070205@redhat.com> So I had a fire lit under my butt to get going on the backups situation. Here's what we're currently using: BackupPC. Run nightly. Over SSH. Selective backups. I'd like to move to bacula. Now that we have moved all the storage off of xen6 we can start to move backups there. It has more storage then lockbox does so I'd also like to do full backups. I've installed bacula from the review and I'll be testing with it and doing a review shortly. Any comments / suggestions? -Mike From nils at breun.nl Tue Jun 5 20:21:18 2007 From: nils at breun.nl (Nils Breunese) Date: Tue, 5 Jun 2007 22:21:18 +0200 (CEST) Subject: Backups In-Reply-To: <4665C39B.7070205@redhat.com> References: <4665C39B.7070205@redhat.com> Message-ID: <18029.82.171.200.98.1181074878.squirrel@www.breun.nl> Mike McGrath wrote: > So I had a fire lit under my butt to get going on the backups > situation. Here's what we're currently using: > > BackupPC. Run nightly. Over SSH. Selective backups. > > I'd like to move to bacula. Now that we have moved all the storage off > of xen6 we can start to move backups there. It has more storage then > lockbox does so I'd also like to do full backups. I've installed bacula > from the review and I'll be testing with it and doing a review shortly. I'm a very happy BackupPC 3.0 user (backing up ~15 full servers daily and keeping 2 weeks worth for every one, around 700 GB of data, but due to BackupPC's pooling and compression features it all fits on a 200 GB drive). I'm just wondering why we'd use Bacula over BackupPC. In my experience BackupPC is much easier to setup and much easier to use (the web interface to BackupPC is simply brilliant). It seemed to me Bacula is more geared towards tape backups (though you can use disk with 'virtual tapes') and BackupPC is more geared towards disk-based backup (though you can frequently write archives to tape). I also found Bacula's Brief Tutorial () to be not so brief... Nils Breunese. From mmcgrath at redhat.com Tue Jun 5 20:43:20 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 05 Jun 2007 15:43:20 -0500 Subject: Backups In-Reply-To: <18029.82.171.200.98.1181074878.squirrel@www.breun.nl> References: <4665C39B.7070205@redhat.com> <18029.82.171.200.98.1181074878.squirrel@www.breun.nl> Message-ID: <4665CAE8.7040302@redhat.com> Nils Breunese wrote: > Mike McGrath wrote: > > >> So I had a fire lit under my butt to get going on the backups >> situation. Here's what we're currently using: >> >> BackupPC. Run nightly. Over SSH. Selective backups. >> >> I'd like to move to bacula. Now that we have moved all the storage off >> of xen6 we can start to move backups there. It has more storage then >> lockbox does so I'd also like to do full backups. I've installed bacula >> from the review and I'll be testing with it and doing a review shortly. >> > > I'm a very happy BackupPC 3.0 user (backing up ~15 full servers daily and > keeping 2 weeks worth for every one, around 700 GB of data, but due to > BackupPC's pooling and compression features it all fits on a 200 GB > drive). > > We're starting to get into backup needs that will include a lot of data thats not redundant so backuppc's pooling won't really benefit us that much. > I'm just wondering why we'd use Bacula over BackupPC. In my experience > BackupPC is much easier to setup and much easier to use (the web interface > to BackupPC is simply brilliant). It seemed to me Bacula is more geared > towards tape backups (though you can use disk with 'virtual tapes') and > BackupPC is more geared towards disk-based backup (though you can > frequently write archives to tape). I also found Bacula's Brief Tutorial > () to be not so > brief... > Hopefully we'll be using both tape and disk backups. Once our new disk tray gets in we'll have to prepare to backup a couple TB of Binary RPMs. Some of our backups will be going to disk, some will be going to tape. Additionally it seems that bacula is more efficient at backing things up. -Mike From nils at breun.nl Tue Jun 5 21:26:40 2007 From: nils at breun.nl (Nils Breunese) Date: Tue, 5 Jun 2007 23:26:40 +0200 (CEST) Subject: Backups In-Reply-To: <4665CAE8.7040302@redhat.com> References: <4665C39B.7070205@redhat.com> <18029.82.171.200.98.1181074878.squirrel@www.breun.nl> <4665CAE8.7040302@redhat.com> Message-ID: <57602.88.211.134.38.1181078800.squirrel@www.breun.nl> Mike McGrath wrote: > We're starting to get into backup needs that will include a lot of data > thats not redundant so backuppc's pooling won't really benefit us that > much. Ok, fair enough. I thought there was talk of having static content on multiple servers, that's where BackupPC's pooling feature could come in pretty handy, but I have no idea about what amounts of data we're talking. > Hopefully we'll be using both tape and disk backups. Once our new disk > tray gets in we'll have to prepare to backup a couple TB of Binary > RPMs. Some of our backups will be going to disk, some will be going to > tape. Additionally it seems that bacula is more efficient at backing > things up. Efficient in term of what precisely? And what backend are we using with BackupPC right now? Nils Breunese. From mmcgrath at redhat.com Tue Jun 5 21:40:14 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 05 Jun 2007 16:40:14 -0500 Subject: Backups In-Reply-To: <57602.88.211.134.38.1181078800.squirrel@www.breun.nl> References: <4665C39B.7070205@redhat.com> <18029.82.171.200.98.1181074878.squirrel@www.breun.nl> <4665CAE8.7040302@redhat.com> <57602.88.211.134.38.1181078800.squirrel@www.breun.nl> Message-ID: <4665D83E.3090602@redhat.com> Nils Breunese wrote: > Mike McGrath wrote: > > >> We're starting to get into backup needs that will include a lot of data >> thats not redundant so backuppc's pooling won't really benefit us that >> much. >> > > Ok, fair enough. I thought there was talk of having static content on > multiple servers, that's where BackupPC's pooling feature could come in > pretty handy, but I have no idea about what amounts of data we're talking. > > Yeah but over time thats become a much smaller percentage of our overall backup needs. Our one-off binary files have grown much faster than our smaller static content files have. >> Hopefully we'll be using both tape and disk backups. Once our new disk >> tray gets in we'll have to prepare to backup a couple TB of Binary >> RPMs. Some of our backups will be going to disk, some will be going to >> tape. Additionally it seems that bacula is more efficient at backing >> things up. >> > > Efficient in term of what precisely? And what backend are we using with > BackupPC right now? > In terms of how long it takes to do the backups and how much load it requires. BackupPC is written in perl. -Mike From mastahnke at gmail.com Wed Jun 6 04:51:10 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 5 Jun 2007 23:51:10 -0500 Subject: Firefox Search Plugin Message-ID: <7874d9dd0706052151w68433fdcm7457f3bd073ed5cc@mail.gmail.com> I was looking for a firefox search plugin for the Fedora Wiki. I checked google/mycroft and didn't find one already existed, so I built my own. http://www.stahnkage.com/fedora should get you to it. If it doesn't work or needs updates, let me know. If it stinks (and it probably does) let me know too. (Tested on F6/ FF 1.5) stahnma From nils at breun.nl Wed Jun 6 07:15:37 2007 From: nils at breun.nl (Nils Breunese) Date: Wed, 6 Jun 2007 09:15:37 +0200 (CEST) Subject: Backups In-Reply-To: <4665D83E.3090602@redhat.com> References: <4665C39B.7070205@redhat.com> <18029.82.171.200.98.1181074878.squirrel@www.breun.nl> <4665CAE8.7040302@redhat.com> <57602.88.211.134.38.1181078800.squirrel@www.breun.nl> <4665D83E.3090602@redhat.com> Message-ID: <59509.88.211.134.38.1181114137.squirrel@www.breun.nl> Mike McGrath wrote: > Nils Breunese wrote: >> Mike McGrath wrote: >>> Hopefully we'll be using both tape and disk backups. Once our new disk >>> tray gets in we'll have to prepare to backup a couple TB of Binary >>> RPMs. Some of our backups will be going to disk, some will be going to >>> tape. Additionally it seems that bacula is more efficient at backing >>> things up. >> >> Efficient in term of what precisely? And what backend are we using with >> BackupPC right now? > > In terms of how long it takes to do the backups and how much load it > requires. BackupPC is written in perl. The backup times and load differ greatly with the backend you choose. Are we doing rsync over ssh right now? We could speed that up by using Blowfish. Maybe rsyncd? If we want to reduce the load we could also go with the tar backend, though that will increase the traffic used. But yeah, it could entirely be the case that Bacula is more suited for this job. :) Nils Breunese. From jeff at ocjtech.us Wed Jun 6 14:05:41 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 06 Jun 2007 09:05:41 -0500 Subject: RFR: GIT Package VCS Message-ID: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> With F8T1 fast approaching (it's currently scheduled to be released on 1 August 2007) we need to get cracking on a new VCS system. I've been working on converting the CVS repositories to GIT on some spare hardware that I've had laying around. I think that it's at a stage where input & testing from the community is needed to move the project forward. Therefore I'd like to request a test Xen host to move the repository over: http://fedoraproject.org/wiki/Infrastructure/RFR/GitPackageVCS More information about the repository I've been setting up can be found here: http://fedoraproject.org/wiki/JeffOllie/VCS/Git Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mmcgrath at redhat.com Wed Jun 6 14:17:24 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 06 Jun 2007 09:17:24 -0500 Subject: RFR: GIT Package VCS In-Reply-To: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> Message-ID: <4666C1F4.3010500@redhat.com> Jeffrey C. Ollie wrote: > With F8T1 fast approaching (it's currently scheduled to be released on 1 > August 2007) we need to get cracking on a new VCS system. I've been > working on converting the CVS repositories to GIT on some spare hardware > that I've had laying around. I think that it's at a stage where input & > testing from the community is needed to move the project forward. > Therefore I'd like to request a test Xen host to move the repository > over: > > http://fedoraproject.org/wiki/Infrastructure/RFR/GitPackageVCS > > More information about the repository I've been setting up can be found > here: > > http://fedoraproject.org/wiki/JeffOllie/VCS/Git > I'm glad this is started back up. One thing that amuses me is back before the F7 launch it almost seemed assured that we would all go with mercurial. This line isn't so clear now, a lot of people have been using git. It seems our future is either going to be A) do nothing and continue with CVS or B) move to HG or Git. One thing that will be tricky about this is that we'll be completely re-designing how we use our source management. Its not just removing cvs and plugging in some other technology in its place. I think Jesse and Jeremy may have had something particular in mind for this but I'm not sure. The hurdles as I see them are: ACL's Making sure checkouts and commits don't take forever Good tagging abilities What else is there? -Mike From katzj at redhat.com Wed Jun 6 14:31:22 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 06 Jun 2007 10:31:22 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <4666C1F4.3010500@redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> Message-ID: <1181140282.8071.9.camel@erebor.boston.redhat.com> On Wed, 2007-06-06 at 09:17 -0500, Mike McGrath wrote: > I'm glad this is started back up. One thing that amuses me is back > before the F7 launch it almost seemed assured that we would all go with > mercurial. This line isn't so clear now, a lot of people have been > using git. It seems our future is either going to be A) do nothing and > continue with CVS or B) move to HG or Git. Yeah, definitely time to start this back up. > One thing that will be tricky about this is that we'll be completely > re-designing how we use our source management. Its not just removing > cvs and plugging in some other technology in its place. I think Jesse > and Jeremy may have had something particular in mind for this but I'm > not sure. Right. I really don't think we want to just take our current system, switch out CVS, and end up with all of the same workflows. The change should be more about how do we improve workflows. That means thinking about things like: * How do we make it easier for a maintainer to rebase their package to a newer upstream? * How do we make it easier for a maintainer to develop, test, and create a patch to fix a problem that's being experienced in Fedora? * How do we make it easy to send these patches to the upstream of the project being worked on? * How do we enable downstreams to take our bits, track them and make changes as they need/want? * How do we better enable a user who has a problem with something we ship to be able to fix it themselves and get the fix back to us? That's the off the top of my head list to give you sort of the idea of things that really want to be thought about. Because if we're just switching out CVS for {git,hg,bzr,svn,foobarbazl} and don't think about these things then we're putting all of our developers onto a learning curve to switch for what is likely to be little gain. Jeremy From mmcgrath at redhat.com Wed Jun 6 14:35:35 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 06 Jun 2007 09:35:35 -0500 Subject: RFR: GIT Package VCS In-Reply-To: <1181140282.8071.9.camel@erebor.boston.redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> Message-ID: <4666C637.4090406@redhat.com> Jeremy Katz wrote: > Right. I really don't think we want to just take our current system, > switch out CVS, and end up with all of the same workflows. The change > should be more about how do we improve workflows. That means thinking > about things like: > * How do we make it easier for a maintainer to rebase their package to a > newer upstream? > * How do we make it easier for a maintainer to develop, test, and create > a patch to fix a problem that's being experienced in Fedora? > * How do we make it easy to send these patches to the upstream of the > project being worked on? > * How do we enable downstreams to take our bits, track them and make > changes as they need/want? > * How do we better enable a user who has a problem with something we > ship to be able to fix it themselves and get the fix back to us? > * How do we do all that while keeping it simple :) Well, I guess now we can all start thinking about it. Source Control is supposed to be a tool to empower developers, lets make sure that what we end up with is just that. -Mike From katzj at redhat.com Wed Jun 6 14:44:10 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 06 Jun 2007 10:44:10 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <1181140282.8071.9.camel@erebor.boston.redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> Message-ID: <1181141050.8071.15.camel@erebor.boston.redhat.com> On Wed, 2007-06-06 at 10:31 -0400, Jeremy Katz wrote: > On Wed, 2007-06-06 at 09:17 -0500, Mike McGrath wrote: > > I'm glad this is started back up. One thing that amuses me is back > > before the F7 launch it almost seemed assured that we would all go with > > mercurial. This line isn't so clear now, a lot of people have been > > using git. It seems our future is either going to be A) do nothing and > > continue with CVS or B) move to HG or Git. > > Yeah, definitely time to start this back up. And just to make things clear, it's time to start up talking about it, investigating our options and getting some things rolling. But that _doesn't_ mean we should rush things to just get them done based on an arbitrary deadline. This is the sort of thing we're going to have to live with for a long while, so it's better to have it take an extra release cycle before rolling out and get it right. Otherwise, we'll have a revolt on our hands :-) Jeremy From jeff at ocjtech.us Wed Jun 6 16:09:02 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 06 Jun 2007 11:09:02 -0500 Subject: RFR: GIT Package VCS In-Reply-To: <1181141050.8071.15.camel@erebor.boston.redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181141050.8071.15.camel@erebor.boston.redhat.com> Message-ID: <1181146143.4009.47.camel@lt21223.campus.dmacc.edu> On Wed, 2007-06-06 at 10:44 -0400, Jeremy Katz wrote: > On Wed, 2007-06-06 at 10:31 -0400, Jeremy Katz wrote: > > On Wed, 2007-06-06 at 09:17 -0500, Mike McGrath wrote: > > > I'm glad this is started back up. One thing that amuses me is back > > > before the F7 launch it almost seemed assured that we would all go with > > > mercurial. This line isn't so clear now, a lot of people have been > > > using git. It seems our future is either going to be A) do nothing and > > > continue with CVS or B) move to HG or Git. > > > > Yeah, definitely time to start this back up. > > And just to make things clear, it's time to start up talking about it, > investigating our options and getting some things rolling. But that > _doesn't_ mean we should rush things to just get them done based on an > arbitrary deadline. This is the sort of thing we're going to have to > live with for a long while, so it's better to have it take an extra > release cycle before rolling out and get it right. Otherwise, we'll > have a revolt on our hands :-) I agree and I disagree. Yes, we need to carefully consider our next step. On the other hand I think that we need to get off of CVS as soon as possible. From what I've seen while testing the conversion to GIT there seems to be corruption in some of the CVS repositories. It's most noticeable in large/active packages (the kernel is a notable example) but sometime small packages are affected. I don't think that it's had a major effect so far because I think that it's relatively rare that people go back and look at old revisions of the packages (probably because that's so difficult in CVS). You can see the effect of the corruption in my git repos thusly: git clone git://161.210.6.204/kernel cd kernel gitk devel origin/FC-6 If you scroll down (way way down) you'll see that the history of the FC-6 branch diverges much much sooner than it should at: 66b7d75c65cfc08a513b7e3a51b9e9661c79f793 2005-08-18 2.6.13-rc6-git10 rather than at: a81d311b742ee08174abb017b6b0caabaa369867 2006-10-12 Initialize branch FC-6 for kernel Compare that with: gitk devel origin/F-7 where you can see the histories diverge at: 80cedc3f9b0705ef0e38565d69869d7871c5c8b8 2007-05-18 Initialize branch F-7 for kernel Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Wed Jun 6 16:27:25 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 06 Jun 2007 09:27:25 -0700 Subject: Moin 1.6 and 1.7 Message-ID: <1181147245.3469.105.camel@erato.phig.org> Last summer we were tracking GSoC changes against the 1.5 trunk of Moin. Those change never got merged, so did not make the 1.6 release. FWIW, we're still looking for someone interested in Python, DocBook, and Moin to help maintain those patches; if we did, we might get them accepted into the trunk. A current SoC project is working on providing a Wiki interface for editing man/info pages. More details are found on Ville-Pekka's project page[1]. The question has come up from Ville-Pekka if we want to track our changes against the current Moin version (1.6) or the upcoming (1.7), and we need to have a decision within the week. Any thoughts on this? From the project page[1]: "* Finally decide on 1.6 vs. 1.7. This needs to happen this week as of writing (week 23). No major changes will get to 1.6 anymore, so if I based my project on it, then Fedora would need to run an unmerged branch of the code. Probably not what we want? My suggestion is to work on 1.7 branch and hopefully get my changes merged into mainline eventually." [1] http://fedoraproject.org/wiki/SummerOfCode/2007/VillePekkaVainio -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Wed Jun 6 16:55:36 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 06 Jun 2007 12:55:36 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <1181146143.4009.47.camel@lt21223.campus.dmacc.edu> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181141050.8071.15.camel@erebor.boston.redhat.com> <1181146143.4009.47.camel@lt21223.campus.dmacc.edu> Message-ID: <1181148936.8071.64.camel@erebor.boston.redhat.com> On Wed, 2007-06-06 at 11:09 -0500, Jeffrey C. Ollie wrote: > On Wed, 2007-06-06 at 10:44 -0400, Jeremy Katz wrote: > > On Wed, 2007-06-06 at 10:31 -0400, Jeremy Katz wrote: > > > On Wed, 2007-06-06 at 09:17 -0500, Mike McGrath wrote: > > > > I'm glad this is started back up. One thing that amuses me is back > > > > before the F7 launch it almost seemed assured that we would all go with > > > > mercurial. This line isn't so clear now, a lot of people have been > > > > using git. It seems our future is either going to be A) do nothing and > > > > continue with CVS or B) move to HG or Git. > > > > > > Yeah, definitely time to start this back up. > > > > And just to make things clear, it's time to start up talking about it, > > investigating our options and getting some things rolling. But that > > _doesn't_ mean we should rush things to just get them done based on an > > arbitrary deadline. This is the sort of thing we're going to have to > > live with for a long while, so it's better to have it take an extra > > release cycle before rolling out and get it right. Otherwise, we'll > > have a revolt on our hands :-) > > I agree and I disagree. Yes, we need to carefully consider our next > step. On the other hand I think that we need to get off of CVS as soon > as possible. From what I've seen while testing the conversion to GIT > there seems to be corruption in some of the CVS repositories. It's most > noticeable in large/active packages (the kernel is a notable example) > but sometime small packages are affected. I don't think that it's had a > major effect so far because I think that it's relatively rare that > people go back and look at old revisions of the packages (probably > because that's so difficult in CVS). I wouldn't be entirely certain there -- for one thing, don't discount bugs in the conversion process. Also, there have been rare cases where things have been munged a bit directly which leads to things being ... not exactly as perhaps expected. Jeremy From paulo.banon at googlemail.com Wed Jun 6 17:12:47 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Wed, 6 Jun 2007 19:12:47 +0200 Subject: Moin 1.6 and 1.7 In-Reply-To: <1181147245.3469.105.camel@erato.phig.org> References: <1181147245.3469.105.camel@erato.phig.org> Message-ID: <7a41c4bc0706061012h30dfd74exd4c6323dc412954e@mail.gmail.com> Karsten, Personally i would go for 1.7, since im sure that noone will want to maintain their own moin branch, and keep patching it manually without breaking the rest of the "new" patches. Paulo On 6/6/07, Karsten Wade wrote: > > Last summer we were tracking GSoC changes against the 1.5 trunk of Moin. > Those change never got merged, so did not make the 1.6 release. FWIW, > we're still looking for someone interested in Python, DocBook, and Moin > to help maintain those patches; if we did, we might get them accepted > into the trunk. > > A current SoC project is working on providing a Wiki interface for > editing man/info pages. More details are found on Ville-Pekka's project > page[1]. > > The question has come up from Ville-Pekka if we want to track our > changes against the current Moin version (1.6) or the upcoming (1.7), > and we need to have a decision within the week. > > Any thoughts on this? > > From the project page[1]: > > "* Finally decide on 1.6 vs. 1.7. This needs to happen this week as of > writing (week 23). No major changes will get to 1.6 anymore, so if I > based my project on it, then Fedora would need to run an unmerged branch > of the code. Probably not what we want? My suggestion is to work on 1.7 > branch and hopefully get my changes merged into mainline eventually." > > [1] http://fedoraproject.org/wiki/SummerOfCode/2007/VillePekkaVainio > > -- > Karsten Wade, 108 Editor ^ Fedora Documentation Project > Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject > quaid.108.redhat.com | gpg key: AD0E0C41 > ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dimitris at glezos.com Wed Jun 6 17:11:16 2007 From: dimitris at glezos.com (Dimitris Glezos) Date: Wed, 06 Jun 2007 18:11:16 +0100 Subject: Moin 1.6 and 1.7 In-Reply-To: <7a41c4bc0706061012h30dfd74exd4c6323dc412954e@mail.gmail.com> References: <1181147245.3469.105.camel@erato.phig.org> <7a41c4bc0706061012h30dfd74exd4c6323dc412954e@mail.gmail.com> Message-ID: <4666EAB4.1010404@glezos.com> O/H Paulo Santos ??????: > Personally i would go for 1.7, since im sure that noone will want to > maintain their own moin branch, and keep patching it manually without > breaking the rest of the "new" patches. Working with upstream 1.7 sounds more sane. -d -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From blizzard at redhat.com Wed Jun 6 17:50:49 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 06 Jun 2007 13:50:49 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <1181140282.8071.9.camel@erebor.boston.redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> Message-ID: <1181152249.22157.44.camel@localhost.localdomain> On Wed, 2007-06-06 at 10:31 -0400, Jeremy Katz wrote: > > Right. I really don't think we want to just take our current system, > switch out CVS, and end up with all of the same workflows. The change > should be more about how do we improve workflows. That means thinking > about things like: > * How do we make it easier for a maintainer to rebase their package to > a > newer upstream? > * How do we make it easier for a maintainer to develop, test, and > create > a patch to fix a problem that's being experienced in Fedora? > * How do we make it easy to send these patches to the upstream of the > project being worked on? > * How do we enable downstreams to take our bits, track them and make > changes as they need/want? > * How do we better enable a user who has a problem with something we > ship to be able to fix it themselves and get the fix back to us? > Awesome stuff. This is the right way to go about the conversation, for sure. I would love to add some stuff to this list: o How do we bring developers and consumers of technology closer together? In a less market-ey speak way to put it: how do we let software developers (not just maintainers!) get directly involved and let them deal directly with the people who want to use it without the maintainer as a mediator? o How do we deal with _more than just RPMs_ as a build and delivery mechanism. (Trust me, this is coming.) o Do we want to move to a process where code is just in a repo and it's built automatically instead of source + patches + spec file? Also, we need to think in use cases instead of abstract questions or about what technology we can use. For example: "A developer has made a patch that he thinks fixes a bug for one of his users. He mails the user and says "here's a pointer to the patch - just click on this button to try a build on your system." One of my goals that I've had for Fedora, one that's easy to understand is, "one click to try any patch." What's required to make that happen? Realistically we probably need to move to a source control system so that when the developer commits (or is pushed in the git sense) the tag with that commit or change is available to apply. Then the build system can just pull that tag, build it and make it available to the user automatically. I would like to compare this to the current work flow we have. Right now you report a bug, the developer looks at the bug, generates a patch. That patch is usually uploaded to bugzilla. Then a very advanced user might be able to take that patch, figure out how to apply it to a spec file, rebuild the rpm and then install and test it. Then that test information might be returned, it might not, but it's hard for you to share that build with other people that might want to test. Our current system creates artificial barriers between developers and users and requires a huge amount of cognitive load to get involved and to get things done. It's slowing things down and creating a bad experience. And worse, everyone doing Linux is doing the same thing. So I think we need to take the next step. Think about how to build simple, easy to understand systems and connect people closer together. So does using git for the package VCS actually help solve this? Not really. But does it mean that it's a step down the right path? Sure. But we need to make sure that we're thinking about the problems correctly instead of just trying to apply a technology to a problem without understanding which problem we're trying to solve. And I don't think our biggest problem is CVS. Our biggest problems are scale and how hard it is for people to be able to share information and be more effective. --Chris From mmcgrath at redhat.com Wed Jun 6 18:13:05 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 06 Jun 2007 13:13:05 -0500 Subject: RFR: GIT Package VCS In-Reply-To: <1181152249.22157.44.camel@localhost.localdomain> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> Message-ID: <4666F931.9040206@redhat.com> Christopher Blizzard wrote: >> > > Awesome stuff. This is the right way to go about the conversation, for > sure. I would love to add some stuff to this list: > Anyone know how our other friends are doing their package management? I know OpenSuSE doesn't really have a cvs at all, its completely lookaside cache (package/release/md5sum-filename) or some such thing. Anyone interested in doing some research on debian and Ubuntu? -Mike From notting at redhat.com Wed Jun 6 18:29:41 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 6 Jun 2007 14:29:41 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <1181140282.8071.9.camel@erebor.boston.redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> Message-ID: <20070606182941.GH5700@nostromo.devel.redhat.com> Jeremy Katz (katzj at redhat.com) said: > Right. I really don't think we want to just take our current system, > switch out CVS, and end up with all of the same workflows. The change > should be more about how do we improve workflows. That means thinking > about things like: > * How do we make it easier for a maintainer to rebase their package to a > newer upstream? > * How do we make it easier for a maintainer to develop, test, and create > a patch to fix a problem that's being experienced in Fedora? > * How do we make it easy to send these patches to the upstream of the > project being worked on? > * How do we enable downstreams to take our bits, track them and make > changes as they need/want? > * How do we better enable a user who has a problem with something we > ship to be able to fix it themselves and get the fix back to us? > > That's the off the top of my head list to give you sort of the idea of > things that really want to be thought about. > > Because if we're just switching out CVS for {git,hg,bzr,svn,foobarbazl} > and don't think about these things then we're putting all of our > developers onto a learning curve to switch for what is likely to be > little gain. Moreover,there have been requests from developers to explicitly *NOT* significantly change the development methodology for F8 after the changes of F7. Bill From jkeating at redhat.com Wed Jun 6 18:34:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 14:34:32 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <20070606182941.GH5700@nostromo.devel.redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <1181140282.8071.9.camel@erebor.boston.redhat.com> <20070606182941.GH5700@nostromo.devel.redhat.com> Message-ID: <200706061434.36162.jkeating@redhat.com> On Wednesday 06 June 2007 14:29:41 Bill Nottingham wrote: > Moreover,there have been requests from developers to explicitly *NOT* > significantly change the development methodology for F8 after the changes > of F7. I firmly believe that this is not something we can do by F8 release. This is something we need to discuss and strawman and put up proof of concepts and get more people thinking on it during the F8 cycle and try to implement during the F9 cycle if possible. From an inwardly looking perspective, this still fits well as RHEL5 just shipped and it will be a bit before RHEL6 really starts hitting heavy, so making a change to internal infrastructure to mirror whats going on in Fedora during the F9 cycle is still good timing. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeff at ocjtech.us Wed Jun 6 19:32:49 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 06 Jun 2007 14:32:49 -0500 Subject: RFR: GIT Package VCS In-Reply-To: <1181152249.22157.44.camel@localhost.localdomain> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> Message-ID: <1181158369.4009.93.camel@lt21223.campus.dmacc.edu> On Wed, 2007-06-06 at 13:50 -0400, Christopher Blizzard wrote: > On Wed, 2007-06-06 at 10:31 -0400, Jeremy Katz wrote: > > > > Right. I really don't think we want to just take our current system, > > switch out CVS, and end up with all of the same workflows. The change > > should be more about how do we improve workflows. That means thinking > > about things like: > > * How do we make it easier for a maintainer to rebase their package to > > a > > newer upstream? > > * How do we make it easier for a maintainer to develop, test, and > > create > > a patch to fix a problem that's being experienced in Fedora? > > * How do we make it easy to send these patches to the upstream of the > > project being worked on? > > * How do we enable downstreams to take our bits, track them and make > > changes as they need/want? > > * How do we better enable a user who has a problem with something we > > ship to be able to fix it themselves and get the fix back to us? > > > > Awesome stuff. This is the right way to go about the conversation, for > sure. I would love to add some stuff to this list: > > o How do we bring developers and consumers of technology closer > together? In a less market-ey speak way to put it: how do we let > software developers (not just maintainers!) get directly involved and > let them deal directly with the people who want to use it without the > maintainer as a mediator? > > o How do we deal with _more than just RPMs_ as a build and delivery > mechanism. (Trust me, this is coming.) > > o Do we want to move to a process where code is just in a repo and it's > built automatically instead of source + patches + spec file? When I first read these two posts, I thought "you guys are crazy", but then I thought about it a bit more and started thinking "Whoah! This could be really cool!" I think what is described here could certainly be done with Git (it'd probably work in another distributed SCM but I'm less famililar with those so I can't say for sure). It also occurred to me that this would be a very big change in how we manage packages so maybe some kind of hybrid approach would make the transition easier. So what about something like this: 1. We convert the package repository to a new SCM so that we can get off of CVS, but the process/workflow remains relatively unchanged. This I think that we could definitely have in place by F8. 2. We set up a parallel package repository that enables our new workflow. When a package maintainer is ready to move a package to the new workflow, building from the old-style repository is disabled and the package is built from the new-style one. > Also, we need to think in use cases instead of abstract questions or > about what technology we can use. For example: > > "A developer has made a patch that he thinks fixes a bug for one of his > users. He mails the user and says "here's a pointer to the patch - just > click on this button to try a build on your system." > > One of my goals that I've had for Fedora, one that's easy to understand > is, "one click to try any patch." > > What's required to make that happen? Realistically we probably need to > move to a source control system so that when the developer commits (or > is pushed in the git sense) the tag with that commit or change is > available to apply. Then the build system can just pull that tag, build > it and make it available to the user automatically. I think that this is more of a Web UI issue rather than a SCM issue. Koji will already build a package based upon a tag in CVS, it wouldn't take a lot of work to extend that to GIT or some other SCM (example patches for SVN are available in a ticket on Koji's bug tracker). What you would need is a Web UI that would: 1. Let users browse the packages and tags that are available in the SCM. 2. Or users could be directed to a particular package/tag by posting a link in bugzilla/mailing list post. 3. Be able to click on a button to request a build from Koji for a particular package/tag/release/arch. Since the build is going to take some time, users would need to supply an email address where a notification would be sent with a link to download the resulting packages. These packages would be cached for a while in case other people wanted to try out those packages as well. Packages built in this fashion wouldn't become part of rawhide or an update to a released package - that would still require action by the maintainer. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Wed Jun 6 20:16:25 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 06 Jun 2007 16:16:25 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <1181158369.4009.93.camel@lt21223.campus.dmacc.edu> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181158369.4009.93.camel@lt21223.campus.dmacc.edu> Message-ID: <1181160985.8071.95.camel@erebor.boston.redhat.com> On Wed, 2007-06-06 at 14:32 -0500, Jeffrey C. Ollie wrote: > When I first read these two posts, I thought "you guys are crazy", No argument here ;-) > but > then I thought about it a bit more and started thinking "Whoah! This > could be really cool!" I think what is described here could certainly > be done with Git (it'd probably work in another distributed SCM but I'm > less famililar with those so I can't say for sure). Yeah, once you start thinking about things like this it becomes pretty clear that a DVCS is almost a requirement rather than a "it'd be nice". > It also occurred to me that this would be a very big change in how we > manage packages so maybe some kind of hybrid approach would make the > transition easier. Yes, it is a big change. A huge change. A groundbreaking change even. Something which shows that Fedora isn't just sitting off quietly, but innovating and doing so with toolsets that are entirely open and available for anyone to use. > So what about something like this: > > 1. We convert the package repository to a new SCM so that we can get > off of CVS, but the process/workflow remains relatively unchanged. This > I think that we could definitely have in place by F8. > > 2. We set up a parallel package repository that enables our new > workflow. When a package maintainer is ready to move a package to the > new workflow, building from the old-style repository is disabled and the > package is built from the new-style one. The problem with a staged approach like this two-fold 1) Moving off of CVS is going to end up requiring a fair bit of relearning/retraining for people. Even if we keep the workflow the same. So by having it as a two-step thing, people have to retrain themselves _twice_ rather than just once. 2) If you let some people move and not others, then it becomes very difficult to know what you have to do to make changes to a specific package. If you're the only person that works on something, that's not such a big deal... but we want to be encouraging collaboration and working together. Having two different ways of doing that at the same time is going to mean that everyone has to get over the hump _anyway_. So why not just take our lumps in get there in a go. Jeremy From jkeating at redhat.com Wed Jun 6 20:17:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 16:17:50 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <1181158369.4009.93.camel@lt21223.campus.dmacc.edu> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <1181152249.22157.44.camel@localhost.localdomain> <1181158369.4009.93.camel@lt21223.campus.dmacc.edu> Message-ID: <200706061617.50519.jkeating@redhat.com> On Wednesday 06 June 2007 15:32:49 Jeffrey C. Ollie wrote: > 1. ?We convert the package repository to a new SCM so that we can get > off of CVS, but the process/workflow remains relatively unchanged. ?This > I think that we could definitely have in place by F8. Please, for the love of god, let us get a bit settled in F8 and finish off the other tools that have really rough edges before we drop something like dist-git on people's laps? We have such a short runway for F8 as it is... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Wed Jun 6 20:25:18 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 06 Jun 2007 15:25:18 -0500 Subject: RFR: GIT Package VCS In-Reply-To: <200706061617.50519.jkeating@redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <1181152249.22157.44.camel@localhost.localdomain> <1181158369.4009.93.camel@lt21223.campus.dmacc.edu> <200706061617.50519.jkeating@redhat.com> Message-ID: <4667182E.8090104@redhat.com> Jesse Keating wrote: > On Wednesday 06 June 2007 15:32:49 Jeffrey C. Ollie wrote: > >> 1. We convert the package repository to a new SCM so that we can get >> off of CVS, but the process/workflow remains relatively unchanged. This >> I think that we could definitely have in place by F8. >> > > Please, for the love of god, let us get a bit settled in F8 and finish off the > other tools that have really rough edges before we drop something like > dist-git on people's laps? We have such a short runway for F8 as it is... > Thats not to say that some good work couldn't get done now though, jcollie isn't that involved in polishing our current tools but he's got a git background. I say let him test and let us know what he comes up with. -Mike From jkeating at redhat.com Wed Jun 6 20:29:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 16:29:37 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <4667182E.8090104@redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <200706061617.50519.jkeating@redhat.com> <4667182E.8090104@redhat.com> Message-ID: <200706061629.37495.jkeating@redhat.com> On Wednesday 06 June 2007 16:25:18 Mike McGrath wrote: > Thats not to say that some good work couldn't get done now though, > jcollie isn't that involved in polishing our current tools but he's got > a git background. ?I say let him test and let us know what he comes up > with. Absolutely. In order to be successful in deploying during F9 time frame, we HAVE to have things up and testable during F8 timeframe. No question. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From blizzard at redhat.com Wed Jun 6 20:53:54 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 06 Jun 2007 16:53:54 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <1181160985.8071.95.camel@erebor.boston.redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181158369.4009.93.camel@lt21223.campus.dmacc.edu> <1181160985.8071.95.camel@erebor.boston.redhat.com> Message-ID: <1181163234.22157.92.camel@localhost.localdomain> On Wed, 2007-06-06 at 16:16 -0400, Jeremy Katz wrote: > > The problem with a staged approach like this two-fold > 1) Moving off of CVS is going to end up requiring a fair bit of > relearning/retraining for people. Even if we keep the workflow the > same. So by having it as a two-step thing, people have to retrain > themselves _twice_ rather than just once. > 2) If you let some people move and not others, then it becomes very > difficult to know what you have to do to make changes to a specific > package. If you're the only person that works on something, that's > not > such a big deal... but we want to be encouraging collaboration and > working together. Having two different ways of doing that at the same > time is going to mean that everyone has to get over the hump _anyway_. > So why not just take our lumps in get there in a go. So regarding 1. I would suggest that we leave "classic" packages in CVS. Learning another system is a big deal and we get almost no bang for that buck so I don't see us moving off of CVS for our current repo setup any time soon. I think that moving selectively is the option of the developer and/or maintainer and should reflect how the upstream project works. And it's only really required for stuff that's moving quickly or has a large community. Remember one of our primary goals: get as close to upstream as possible. If we're supporting them by using the same DVCS then they are more likely to assist us, not to mention how easy it gets to figure out what's different between repo a and repo b. For example for the kernel, we might want to pull from a git repo. For people who use hg, we just use that. For projects that just release tarballs, we stick with what we have. This might sound crazy (SUPPORT > 1 SYSTEM, ARE YOU CRAZY?) Well, yes, until you realize what you need to do here. To start with you only have to teach the rpm build side how pull a specific tag from a specific repo. On the query side we need a browser for each kind, which is a bit of work, but something I think we need to do anyway. (i.e. "What would git do?") Plus, to be honest, it completely avoids the whole "which damn system do we use." And I like focusing on the end user features instead of getting stuck in VCS dicussion hell. We're not going to get everyone else to agree or even use the same system. So let's build something that supports both. I understand the training costs here, but to be honest I think that local experts will continue to be local experts. And we want more of that not less. --Chris From blizzard at redhat.com Wed Jun 6 21:01:16 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 06 Jun 2007 17:01:16 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <1181163234.22157.92.camel@localhost.localdomain> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181158369.4009.93.camel@lt21223.campus.dmacc.edu> <1181160985.8071.95.camel@erebor.boston.redhat.com> <1181163234.22157.92.camel@localhost.localdomain> Message-ID: <1181163676.22157.99.camel@localhost.localdomain> On Wed, 2007-06-06 at 16:53 -0400, Christopher Blizzard wrote: > > > This might sound crazy (SUPPORT > 1 SYSTEM, ARE YOU CRAZY?) Well, > yes, > until you realize what you need to do here. To start with you only > have > to teach the rpm build side how pull a specific tag from a specific > repo. On the query side we need a browser for each kind, which is a > bit > of work, but something I think we need to do anyway. (i.e. "What > would > git do?") > One more thought for people to chew on. I honestly believe that one of our roles needs to be to service developers. Right now we're set up to service packagers + maintainers. I want to bring developers into the fold and give them tools to be more productive. So what ends up being a little bit more work for us ends up making developers lives much much easier. And that's a total win because it builds our most important base - those developers. --Chris From katzj at redhat.com Wed Jun 6 21:31:56 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 06 Jun 2007 17:31:56 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <1181163234.22157.92.camel@localhost.localdomain> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181158369.4009.93.camel@lt21223.campus.dmacc.edu> <1181160985.8071.95.camel@erebor.boston.redhat.com> <1181163234.22157.92.camel@localhost.localdomain> Message-ID: <1181165517.8071.110.camel@erebor.boston.redhat.com> On Wed, 2007-06-06 at 16:53 -0400, Christopher Blizzard wrote: > On Wed, 2007-06-06 at 16:16 -0400, Jeremy Katz wrote: > > The problem with a staged approach like this two-fold > > 1) Moving off of CVS is going to end up requiring a fair bit of > > relearning/retraining for people. Even if we keep the workflow the > > same. So by having it as a two-step thing, people have to retrain > > themselves _twice_ rather than just once. > > 2) If you let some people move and not others, then it becomes very > > difficult to know what you have to do to make changes to a specific > > package. If you're the only person that works on something, that's > > not > > such a big deal... but we want to be encouraging collaboration and > > working together. Having two different ways of doing that at the same > > time is going to mean that everyone has to get over the hump _anyway_. > > So why not just take our lumps in get there in a go. > > So regarding 1. I would suggest that we leave "classic" packages in CVS. > Learning another system is a big deal and we get almost no bang for that > buck so I don't see us moving off of CVS for our current repo setup any > time soon. > > I think that moving selectively is the option of the developer and/or > maintainer and should reflect how the upstream project works. And it's > only really required for stuff that's moving quickly or has a large > community. Remember one of our primary goals: get as close to upstream > as possible. If we're supporting them by using the same DVCS then they > are more likely to assist us, not to mention how easy it gets to figure > out what's different between repo a and repo b. > > For example for the kernel, we might want to pull from a git repo. For > people who use hg, we just use that. For projects that just release > tarballs, we stick with what we have. At the same time, I think we still need to be able to very clearly separate out our changes from what upstream has. Just a git repo of the kernel very quickly gets out of control and you end up with bazillions of things that you never push back upstream because it's easier to just keep sitting on them. So I don't think that just a VCS repo of the source is what we want... we're going to end up wanting some integration with something quilt-like to get patches out; so like stgit or mq or ... > This might sound crazy (SUPPORT > 1 SYSTEM, ARE YOU CRAZY?) Well, yes, > until you realize what you need to do here. To start with you only have > to teach the rpm build side how pull a specific tag from a specific > repo. On the query side we need a browser for each kind, which is a bit > of work, but something I think we need to do anyway. (i.e. "What would > git do?") So if I am the owner of the rpm package which has an upstream of hg and want to fix, test and commit a change to say (for the sake of argument) neon which is in git, I now have to know two different systems? You're crazy ;-) To add to the craziness of this path, think about actually maintaining these packages across different distro releases... every VCS has its own unique and specially crack-ridden way of handling branching. Or when you star to think about the "I'm a downstream of Fedora and need to change X, Y, and Z" and you are then having them set up potentially 3 different VCS systems to do so. Or the "it's time for a mass-rebuild; let's go and commit a version bump to all the packages so we can rebuild. Uhhm. Uh-oh. > Plus, to be honest, it completely avoids the whole "which damn system do > we use." And I like focusing on the end user features instead of > getting stuck in VCS dicussion hell. We're not going to get everyone > else to agree or even use the same system. So let's build something > that supports both. So instead of picking _one_ answer, we now have to make sure that we implement all of the end user features for N systems? Seriously, this is losing. Jeremy From blizzard at redhat.com Thu Jun 7 02:46:57 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 06 Jun 2007 22:46:57 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <1181165517.8071.110.camel@erebor.boston.redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181158369.4009.93.camel@lt21223.campus.dmacc.edu> <1181160985.8071.95.camel@erebor.boston.redhat.com> <1181163234.22157.92.camel@localhost.localdomain> <1181165517.8071.110.camel@erebor.boston.redhat.com> Message-ID: <1181184417.14656.13.camel@localhost.localdomain> On Wed, 2007-06-06 at 17:31 -0400, Jeremy Katz wrote: > At the same time, I think we still need to be able to very clearly > separate out our changes from what upstream has. Just a git repo of the > kernel very quickly gets out of control and you end up with bazillions > of things that you never push back upstream because it's easier to just > keep sitting on them. So I don't think that just a VCS repo of the > source is what we want... we're going to end up wanting some integration > with something quilt-like to get patches out; so like stgit or mq or ... Like I said, I think it depends on what the package is and most importantly what the maintainer and developers want to do. I know that Dave Jones didn't want to use git to build the kernel, and that's fine He doesn't have to use it. One thing I'm trying to do here is break the maintainer model that we have today. I want developers to come and work directly in Fedora. And that means taking out that extra step if we can - going directly from a VCS to a package. Using HAL as an example - want to pull in the latest one? Just point your repo at the upstream one and catch up to that release. Then click to build. Or, even better, the developer can do it himself and push it into our release. Remember, in a lot of causes for us the maintainer _is_ the main developer! So why not draw that line as close as possible? > > This might sound crazy (SUPPORT > 1 SYSTEM, ARE YOU CRAZY?) Well, yes, > > until you realize what you need to do here. To start with you only have > > to teach the rpm build side how pull a specific tag from a specific > > repo. On the query side we need a browser for each kind, which is a bit > > of work, but something I think we need to do anyway. (i.e. "What would > > git do?") > > So if I am the owner of the rpm package which has an upstream of hg and > want to fix, test and commit a change to say (for the sake of argument) > neon which is in git, I now have to know two different systems? You're > crazy ;-) No. If you happen to be a maintainer _and_ a developer and you have _chosen_ to use hg or git or whatever, then we make it easy for you. This is about adding options to bring us closer to the upstream developers and make their lives easier. > > To add to the craziness of this path, think about actually maintaining > these packages across different distro releases... every VCS has its > own unique and specially crack-ridden way of handling branching. Yes, but you only need to teach our systems about that once. > > Or when you star to think about the "I'm a downstream of Fedora and need > to change X, Y, and Z" and you are then having them set up potentially 3 > different VCS systems to do so. Depends on what they want to do. > > Or the "it's time for a mass-rebuild; let's go and commit a version bump > to all the packages so we can rebuild. Uhhm. Uh-oh. This is actually easier for those VCS packages than it is today. Right now we have to go in and edit every single spec file, edit, and commit. If we back away from having spec files like that and instead generate that info before compile time (so a "pristine source" is just a set of metadata, rules and a source tag) doing mass rebuilds is _easy_. > > > Plus, to be honest, it completely avoids the whole "which damn system do > > we use." And I like focusing on the end user features instead of > > getting stuck in VCS dicussion hell. We're not going to get everyone > > else to agree or even use the same system. So let's build something > > that supports both. > > So instead of picking _one_ answer, we now have to make sure that we > implement all of the end user features for N systems? Seriously, this > is losing. This comment inspired me to make a very special graphic: http://www.ideasuite.com/~blizzard/images/captain_no.png So let me ask you this question: where do you want Fedora to go? Just keep adding packages? Situation as usual? We got things outside of the firewall. That's nice. We will never rest on our laurels. What's next? I have a pretty specific vision for where we should be two to three years down the road, and it involves innovating in these spaces including looking at having source repos to fix real problems with developer productivity. How can we make developers (not just maintainers) lives easier? How can we shorten the distance between them? I don't see you offering ideas, only saying others are bad. --Chris From vpivaini at cs.helsinki.fi Thu Jun 7 07:26:38 2007 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Thu, 7 Jun 2007 10:26:38 +0300 Subject: Moin 1.6 and 1.7 In-Reply-To: <4666EAB4.1010404@glezos.com> References: <1181147245.3469.105.camel@erato.phig.org> <7a41c4bc0706061012h30dfd74exd4c6323dc412954e@mail.gmail.com> <4666EAB4.1010404@glezos.com> Message-ID: <200706071026.38251.vpivaini@cs.helsinki.fi> Dimitris Glezos kirjoitti viestiss??n (l?hetysaika Wednesday, 6. June 2007 20:11:16): > O/H Paulo Santos ??????: > > Personally i would go for 1.7, since im sure that noone will want to > > maintain their own moin branch, and keep patching it manually without > > breaking the rest of the "new" patches. > > Working with upstream 1.7 sounds more sane. > > -d Thanks for your input. Everyone I've talked with from Fedora and Moin have recommended using 1.7, so that's what I'm going to base my work on. Then I'll also have a chance of getting my work merged into 1.7 mainline eventually. -- Ville-Pekka Vainio vpivaini at cs.helsinki.fi From tchung at fedoraproject.org Thu Jun 7 07:39:50 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Thu, 7 Jun 2007 00:39:50 -0700 Subject: UnicodeEncodeError - Presentations Message-ID: <369bce3b0706070039v6a4149a6o3b1e0352d63c589d@mail.gmail.com> Hey folks, I found another one under "Info" page. http://fedoraproject.org/wiki/Presentations?action=info Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From katzj at redhat.com Thu Jun 7 14:25:11 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 07 Jun 2007 10:25:11 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <1181184417.14656.13.camel@localhost.localdomain> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181158369.4009.93.camel@lt21223.campus.dmacc.edu> <1181160985.8071.95.camel@erebor.boston.redhat.com> <1181163234.22157.92.camel@localhost.localdomain> <1181165517.8071.110.camel@erebor.boston.redhat.com> <1181184417.14656.13.camel@localhost.localdomain> Message-ID: <1181226311.18649.40.camel@aglarond.local> On Wed, 2007-06-06 at 22:46 -0400, Christopher Blizzard wrote: > On Wed, 2007-06-06 at 17:31 -0400, Jeremy Katz wrote: > > At the same time, I think we still need to be able to very clearly > > separate out our changes from what upstream has. Just a git repo of the > > kernel very quickly gets out of control and you end up with bazillions > > of things that you never push back upstream because it's easier to just > > keep sitting on them. So I don't think that just a VCS repo of the > > source is what we want... we're going to end up wanting some integration > > with something quilt-like to get patches out; so like stgit or mq or ... > > Like I said, I think it depends on what the package is and most > importantly what the maintainer and developers want to do. I know that > Dave Jones didn't want to use git to build the kernel, and that's fine > He doesn't have to use it. > > One thing I'm trying to do here is break the maintainer model that we > have today. I want developers to come and work directly in Fedora. And > that means taking out that extra step if we can - going directly from a > VCS to a package. Using HAL as an example - want to pull in the latest > one? Just point your repo at the upstream one and catch up to that > release. Then click to build. Or, even better, the developer can do it > himself and push it into our release. Remember, in a lot of causes for > us the maintainer _is_ the main developer! So why not draw that line as > close as possible? Because in many more cases, the maintainer _isn't_ the main upstream developer. And in a lot of cases, the main upstream developer (or developers) are very happy to have someone else take care of things that aren't directly "write new feature, fix bugs in my code, make my program kick ass". eg, they're really happy when someone volunteers to take over maintaining their project's website for them. Similarly with package maintenance. Especially because we're not going to get to a world where there's only one Linux distribution[1] and they're certainly not going to want to maintain packages for many distros. So I guess that's the point where our basic disagreement lies... I have no problems if upstream developers _want_ to maintain things. But I don't know that it's the case to optimize for. > > > This might sound crazy (SUPPORT > 1 SYSTEM, ARE YOU CRAZY?) Well, yes, > > > until you realize what you need to do here. To start with you only have > > > to teach the rpm build side how pull a specific tag from a specific > > > repo. On the query side we need a browser for each kind, which is a bit > > > of work, but something I think we need to do anyway. (i.e. "What would > > > git do?") > > > > So if I am the owner of the rpm package which has an upstream of hg and > > want to fix, test and commit a change to say (for the sake of argument) > > neon which is in git, I now have to know two different systems? You're > > crazy ;-) > > No. If you happen to be a maintainer _and_ a developer and you have > _chosen_ to use hg or git or whatever, then we make it easy for you. > This is about adding options to bring us closer to the upstream > developers and make their lives easier. But we're making the lives of the upstream developers (who, more often than not, are more experienced and going to be better able to adapt to a different VCS and some workflow on top of it) easier at the cost of our contributors who maintain a lot of packages and _aren't_ the upstream developer. > > To add to the craziness of this path, think about actually maintaining > > these packages across different distro releases... every VCS has its > > own unique and specially crack-ridden way of handling branching. > > Yes, but you only need to teach our systems about that once. And add every time a new upstream cares about the new VCS of the week. Or when $VCS changes it's branching. And maintain and test across all of the permutations. > > Or when you star to think about the "I'm a downstream of Fedora and need > > to change X, Y, and Z" and you are then having them set up potentially 3 > > different VCS systems to do so. > > Depends on what they want to do. I want to enable them to make any changes that they want. That would be one of the big points of a DVCS and also is one of the big points in making it easy for anyone to set up a build farm with koji. I want them to be able to track what goes on, adjust their changes accordingly and go on their way. I don't want the setup to involve doing the server set up of each of git, hg, bzr, svk, arch and monotone. > > Or the "it's time for a mass-rebuild; let's go and commit a version bump > > to all the packages so we can rebuild. Uhhm. Uh-oh. > > This is actually easier for those VCS packages than it is today. Right > now we have to go in and edit every single spec file, edit, and commit. > If we back away from having spec files like that and instead generate > that info before compile time (so a "pristine source" is just a set of > metadata, rules and a source tag) doing mass rebuilds is _easy_. So where's the metadata/rules kept? Do I have to use two different systems -- one for the source and one for the metadata/rules? Because I'm always going to want to be able to deal with both. If they're not in different systems, then the rebuild case still has to deal with many systems And fundamentally, I think that the "pristine source + patches" bit is just as important today as it was 10 years ago. Because otherwise, you get into a situation where you basically encourage forking and not contributing things back upstream. Your response is going to be "but it's upstream doing it" -- at the same time, there are _always_ going to be distro specific changes that won't necessarily make sense for upstream. Being able to contain and track those and making it easier for changes to be pushed upstream as opposed to carried along in a distro-specific world forever is a good thing. > > > Plus, to be honest, it completely avoids the whole "which damn system do > > > we use." And I like focusing on the end user features instead of > > > getting stuck in VCS dicussion hell. We're not going to get everyone > > > else to agree or even use the same system. So let's build something > > > that supports both. > > > > So instead of picking _one_ answer, we now have to make sure that we > > implement all of the end user features for N systems? Seriously, this > > is losing. > > So let me ask you this question: where do you want Fedora to go? Just > keep adding packages? Situation as usual? We got things outside of the > firewall. That's nice. We will never rest on our laurels. What's > next? Continuing to add packages is going to be important forever. Because the great thing is there's always more software :) > I have a pretty specific vision for where we should be two to three > years down the road, and it involves innovating in these spaces > including looking at having source repos to fix real problems with > developer productivity. How can we make developers (not just > maintainers) lives easier? How can we shorten the distance between > them? I want to make it easier for users who are interested in something to become involved in it within the context of Fedora. I see a neat application on gnomefiles and it's not in Fedora? How do we make it easier for that user to go from being just a user to being a contributor? And then, once that user is a maintainer it becomes a much easier path for them to get involved as a contributor in upstream projects. Because they've had a chance to sort of hone their skills and start off with something that's a little easier. For all of the maintainers we have today, how do we make their lives easier? And one part of that is how do we make it easier for them to interact with the upstream of the software they maintain for Fedora. But another part is how do we make it easier for them to interact with other parts of Fedora that their packages depend on. Sure, some bugs are easily traced and just in the piece of software that you're the maintainer of. But plenty of bugs are caused by a problem in another library or something else -- how do we make it easier for them to be able to track that down and fix it themselves and then quite possibly get involved with another project. But I think things are devolving a bit from the actual infrastructure discussion at this point... reply-to set appropriately Jeremy [1] The point at which there's one Linux distro is the point at which I start Jinux ;) The variety and competition within the Linux distro space is one of the things that continues to drive innovation and progress and I think that it's an incredibly important force From mmcgrath at redhat.com Thu Jun 7 15:39:15 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 07 Jun 2007 10:39:15 -0500 Subject: Fedora 7 Upgrade Message-ID: <466826A3.10905@redhat.com> We currently run many test servers, 3 app servers and 10 Build servers off of Fedora 6. Do we A) Upgrade everything to Fedora 7 B) Upgrade nothing to Fedora 7 C) Upgrade things as needed. I'm for C. I think the mash server may already have a request to be upgraded. The others I don't think there is a compelling reason to upgrade and we should wait for Fedora 8 or until something comes up that may require it. Thoughts? -Mike From jkeating at redhat.com Thu Jun 7 15:46:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 11:46:30 -0400 Subject: Fedora 7 Upgrade In-Reply-To: <466826A3.10905@redhat.com> References: <466826A3.10905@redhat.com> Message-ID: <200706071146.30373.jkeating@redhat.com> On Thursday 07 June 2007 11:39:15 Mike McGrath wrote: > We currently run many test servers, 3 app servers and 10 Build servers > off of Fedora 6. Do we > > A) Upgrade everything to Fedora 7 > B) Upgrade nothing to Fedora 7 > C) Upgrade things as needed. > > > I'm for C. I think the mash server may already have a request to be > upgraded. The others I don't think there is a compelling reason to > upgrade and we should wait for Fedora 8 or until something comes up that > may require it. > > Thoughts? My personal thought is anything that doesn't require the specifics of a Fedora release should be on RHEL5/CentOS5. I can only think of a couple things that need the specifics, the mash box and the updates system, and those should be on Fedora 7. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Thu Jun 7 15:49:57 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 07 Jun 2007 10:49:57 -0500 Subject: Fedora 7 Upgrade In-Reply-To: <200706071146.30373.jkeating@redhat.com> References: <466826A3.10905@redhat.com> <200706071146.30373.jkeating@redhat.com> Message-ID: <46682925.7070105@redhat.com> Jesse Keating wrote: > My personal thought is anything that doesn't require the specifics of a Fedora > release should be on RHEL5/CentOS5. I can only think of a couple things that > need the specifics, the mash box and the updates system, and those should be > on Fedora 7. > > I agree, I had no plans on upgrading any of our RHEL boxes (except for cvs and db1 but will stay in the RHEL upgrade path). For those of you that are new on the list we've had a lot of discussions about this in the past. Our team, for the most part, agrees that its about picking the right tool for the job. For boxes that don't need brand new technologies (like cvs) its nice to be able to set them up and forget about them. But for some boxes that do need the latest and greatest (like our builders) we've always had and kept them on Fedora. -Mike From jkeating at redhat.com Thu Jun 7 15:53:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 11:53:59 -0400 Subject: Fedora 7 Upgrade In-Reply-To: <46682925.7070105@redhat.com> References: <466826A3.10905@redhat.com> <200706071146.30373.jkeating@redhat.com> <46682925.7070105@redhat.com> Message-ID: <200706071154.00036.jkeating@redhat.com> On Thursday 07 June 2007 11:49:57 Mike McGrath wrote: > I agree, I had no plans on upgrading any of our RHEL boxes (except for > cvs and db1 but will stay in the RHEL upgrade path). ?For those of you > that are new on the list we've had a lot of discussions about this in > the past. ?Our team, for the most part, agrees that its about picking > the right tool for the job. ?For boxes that don't need brand new > technologies (like cvs) its nice to be able to set them up and forget > about them. ?But for some boxes that do need the latest and greatest > (like our builders) we've always had and kept them on Fedora. With RHEL5 out, I question the need for Fedora on the builders. In fact, before the merge, all the internal Core builders were running RHEL4. Can we not use RHEL5 on the builders now? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Thu Jun 7 16:28:17 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 07 Jun 2007 09:28:17 -0700 Subject: Fedora 7 Upgrade In-Reply-To: <200706071154.00036.jkeating@redhat.com> References: <466826A3.10905@redhat.com> <200706071146.30373.jkeating@redhat.com> <46682925.7070105@redhat.com> <200706071154.00036.jkeating@redhat.com> Message-ID: <1181233697.4070.87.camel@localhost.localdomain> On Thu, 2007-06-07 at 11:53 -0400, Jesse Keating wrote: > On Thursday 07 June 2007 11:49:57 Mike McGrath wrote: > > I agree, I had no plans on upgrading any of our RHEL boxes (except for > > cvs and db1 but will stay in the RHEL upgrade path). For those of you > > that are new on the list we've had a lot of discussions about this in > > the past. Our team, for the most part, agrees that its about picking > > the right tool for the job. For boxes that don't need brand new > > technologies (like cvs) its nice to be able to set them up and forget > > about them. But for some boxes that do need the latest and greatest > > (like our builders) we've always had and kept them on Fedora. > > With RHEL5 out, I question the need for Fedora on the builders. In fact, > before the merge, all the internal Core builders were running RHEL4. Can we > not use RHEL5 on the builders now? > Will we want to pull in new features for the builders? Something like a change in rpm is needed for a new version of mock. We want that change and so we need to upgrade? I just want to avoid flip-flopping between RHEL and Fedora. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Thu Jun 7 16:44:11 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 07 Jun 2007 09:44:11 -0700 Subject: Fedora 7 Upgrade In-Reply-To: <466826A3.10905@redhat.com> References: <466826A3.10905@redhat.com> Message-ID: <1181234651.4070.99.camel@localhost.localdomain> On Thu, 2007-06-07 at 10:39 -0500, Mike McGrath wrote: > We currently run many test servers, 3 app servers and 10 Build servers > off of Fedora 6. Do we > > A) Upgrade everything to Fedora 7 > B) Upgrade nothing to Fedora 7 > C) Upgrade things as needed. > > > I'm for C. I think the mash server may already have a request to be > upgraded. The others I don't think there is a compelling reason to > upgrade and we should wait for Fedora 8 or until something comes up that > may require it. > Depends... What is the reason for those boxes to be on Fedora instead of RHEL? If it's because FC6 had things not in RHEL4 maybe we can make a switch to RHEL5 at some point. If the reason is we want the flexibility of moving to the latest code along with Fedora instead of waiting for RHEL to upgrade/backport then perhaps they should be on the latest Fedora where the latest code is more likely to land sooner. In the case of the app servers running TurboGears, I think that it was a lack of TG requirements on RHEL4 that held us back. I also think we're close to having TG for RHEL5 so we might want to move test servers to RHEL5, check that the applications run there, and then move the app servers handling those to RHEL. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mmcgrath at redhat.com Thu Jun 7 17:19:01 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 07 Jun 2007 12:19:01 -0500 Subject: Fedora 7 Upgrade In-Reply-To: <1181234651.4070.99.camel@localhost.localdomain> References: <466826A3.10905@redhat.com> <1181234651.4070.99.camel@localhost.localdomain> Message-ID: <46683E05.5050105@redhat.com> Toshio Kuratomi wrote: > Depends... > > What is the reason for those boxes to be on Fedora instead of RHEL? If > it's because FC6 had things not in RHEL4 maybe we can make a switch to > RHEL5 at some point. If the reason is we want the flexibility of moving > to the latest code along with Fedora instead of waiting for RHEL to > upgrade/backport then perhaps they should be on the latest Fedora where > the latest code is more likely to land sooner. > > In the case of the app servers running TurboGears, I think that it was a > lack of TG requirements on RHEL4 that held us back. I also think we're > close to having TG for RHEL5 so we might want to move test servers to > RHEL5, check that the applications run there, and then move the app > servers handling those to RHEL. > This is very true as well, I've not tested the TG status in RHEL5. Has anyone else? Luke? -Mike From paulo.banon at googlemail.com Thu Jun 7 17:14:12 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Thu, 7 Jun 2007 19:14:12 +0200 Subject: Fedora 7 Upgrade In-Reply-To: <1181233697.4070.87.camel@localhost.localdomain> References: <466826A3.10905@redhat.com> <200706071146.30373.jkeating@redhat.com> <46682925.7070105@redhat.com> <200706071154.00036.jkeating@redhat.com> <1181233697.4070.87.camel@localhost.localdomain> Message-ID: <7a41c4bc0706071014u6d4ae10bib8e7f51134eb11be@mail.gmail.com> I would also prefer to standardize everything, unless necessary. But for now Glezos requests that publictest4 be upgraded to F7, since he needs some packages that exist in F7 and not in FC6. Thanks, Paulo On 6/7/07, Toshio Kuratomi wrote: > > On Thu, 2007-06-07 at 11:53 -0400, Jesse Keating wrote: > > On Thursday 07 June 2007 11:49:57 Mike McGrath wrote: > > > I agree, I had no plans on upgrading any of our RHEL boxes (except for > > > cvs and db1 but will stay in the RHEL upgrade path). For those of you > > > that are new on the list we've had a lot of discussions about this in > > > the past. Our team, for the most part, agrees that its about picking > > > the right tool for the job. For boxes that don't need brand new > > > technologies (like cvs) its nice to be able to set them up and forget > > > about them. But for some boxes that do need the latest and greatest > > > (like our builders) we've always had and kept them on Fedora. > > > > With RHEL5 out, I question the need for Fedora on the builders. In > fact, > > before the merge, all the internal Core builders were running > RHEL4. Can we > > not use RHEL5 on the builders now? > > > Will we want to pull in new features for the builders? Something like a > change in rpm is needed for a new version of mock. We want that change > and so we need to upgrade? > > I just want to avoid flip-flopping between RHEL and Fedora. > > -Toshio > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Thu Jun 7 17:28:09 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 07 Jun 2007 12:28:09 -0500 Subject: Fedora 7 Upgrade In-Reply-To: <7a41c4bc0706071014u6d4ae10bib8e7f51134eb11be@mail.gmail.com> References: <466826A3.10905@redhat.com> <200706071146.30373.jkeating@redhat.com> <46682925.7070105@redhat.com> <200706071154.00036.jkeating@redhat.com> <1181233697.4070.87.camel@localhost.localdomain> <7a41c4bc0706071014u6d4ae10bib8e7f51134eb11be@mail.gmail.com> Message-ID: <46684029.7000304@redhat.com> Paulo Santos wrote: > I would also prefer to standardize everything, unless necessary. > But for now Glezos requests that publictest4 be upgraded to F7, since he > needs some packages that exist in F7 and not in FC6. Items like this will always come up. It seems the general feel is to move towards the most recent RHEL version. Unfortunately RHEL doesn't always do what we want it to (which is why we also have production FC boxes). Its been an unspoken rule I guess to use RHEL when possible and to use Fedora when we need Fedora's features. I have a feeling we'll always be running Fedora in production for our application servers, that's not a bad thing at all. But as far as managing risk (which, at the end of the day, is what this is all about) we just have to be smart about the decisions we make. Upgrading publictest4 isn't a problem at all. But when Glezos's project is ready to be published to the world we'll have to make sure we either A) test our current FC6 boxes for an upgrade or B) Move all our FC6 stuff to RHEL and then start over with some F7 boxes. -Mike From notting at redhat.com Thu Jun 7 18:01:16 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 7 Jun 2007 14:01:16 -0400 Subject: Fedora 7 Upgrade In-Reply-To: <1181234651.4070.99.camel@localhost.localdomain> References: <466826A3.10905@redhat.com> <1181234651.4070.99.camel@localhost.localdomain> Message-ID: <20070607180116.GB27054@nostromo.devel.redhat.com> Toshio Kuratomi (a.badger at gmail.com) said: > Depends... > > What is the reason for those boxes to be on Fedora instead of RHEL? For the mash/bodhi box, it's because it requires yum-3.2.x and current createrepo. At the moment it's running them recompiled for FC6, and, well, I'd rather not do that long term (or do that on RHEL.) Bill From brandon.jasper at navy.mil Thu Jun 7 19:04:59 2007 From: brandon.jasper at navy.mil (Jasper, Brandon R STS2(SS) NSSC BANGOR WA, 00W) Date: Thu, 7 Jun 2007 12:04:59 -0700 Subject: A bit of an intro Message-ID: My name is Brandon Jasper and I'm a CTN2(SS) (Crypto Tech Networking, submarine qualified) in the US Navy. I've been a Red Hat user for a long time and in fact it was the first Linux distro I used. I saw the infrastructure team and since I'm not heavy on programming it fits with what I can do to contribute to the project. I've been a sysadmin on an SSN (nuclear fast attack submarine) and in a detachment working on underwater robotics. I'm currently the assistant information assurance manager for the pacific SSBN (strategic missile submarines) fleet. I've got a number of cast off servers sitting around my office and though I can't make any firm commitments I am going to try to drop the paperwork to get one. If I can get one I'll set it up to help out with the project, if not I'll still be glad to help where I can. -Brandon -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandon.jasper at navy.mil Thu Jun 7 19:19:35 2007 From: brandon.jasper at navy.mil (Jasper, Brandon R STS2(SS) NSSC BANGOR WA, 00W) Date: Thu, 7 Jun 2007 12:19:35 -0700 Subject: A bit of an intro In-Reply-To: References: Message-ID: A note, I recently was accepted for the rate conversion to CTN, NMCI has yet to catch up and update my info. -Brandon -----Original Message----- From: fedora-infrastructure-list-bounces at redhat.com [mailto:fedora-infrastructure-list-bounces at redhat.com] On Behalf Of Jasper, Brandon R STS2(SS) NSSC BANGOR WA, 00W Sent: Thursday, June 07, 2007 12:05 To: fedora-infrastructure-list at redhat.com Subject: A bit of an intro My name is Brandon Jasper and I'm a CTN2(SS) (Crypto Tech Networking, submarine qualified) in the US Navy. I've been a Red Hat user for a long time and in fact it was the first Linux distro I used. I saw the infrastructure team and since I'm not heavy on programming it fits with what I can do to contribute to the project. I've been a sysadmin on an SSN (nuclear fast attack submarine) and in a detachment working on underwater robotics. I'm currently the assistant information assurance manager for the pacific SSBN (strategic missile submarines) fleet. I've got a number of cast off servers sitting around my office and though I can't make any firm commitments I am going to try to drop the paperwork to get one. If I can get one I'll set it up to help out with the project, if not I'll still be glad to help where I can. -Brandon From mmcgrath at redhat.com Thu Jun 7 19:32:25 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 07 Jun 2007 14:32:25 -0500 Subject: A bit of an intro In-Reply-To: References: Message-ID: <46685D49.4070900@redhat.com> Jasper, Brandon R STS2(SS) NSSC BANGOR WA, 00W wrote: > My name is Brandon Jasper and I'm a CTN2(SS) (Crypto Tech Networking, > submarine qualified) in the US Navy. I've been a Red Hat user for a > long time and in fact it was the first Linux distro I used. I saw the > infrastructure team and since I'm not heavy on programming it fits with > what I can do to contribute to the project. I've been a sysadmin on an > SSN (nuclear fast attack submarine) and in a detachment working on > underwater robotics. I'm currently the assistant information assurance > manager for the pacific SSBN (strategic missile submarines) fleet. I've > got a number of cast off servers sitting around my office and though I > can't make any firm commitments I am going to try to drop the paperwork > to get one. If I can get one I'll set it up to help out with the > project, if not I'll still be glad to help where I can. > Well welcome, if you can make it to our meeting today at 4 Eastern that would be great, if not just keep tabs on the list and let us know if anything in particular interests you. You can also just contact one of the officers and say "Hey, I want to help give me something to do" http://fedoraproject.org/wiki/Infrastructure/Officers -Mike From poelstra at redhat.com Thu Jun 7 20:23:00 2007 From: poelstra at redhat.com (John Poelstra) Date: Thu, 07 Jun 2007 13:23:00 -0700 Subject: Fedora 7 Upgrade In-Reply-To: <200706071154.00036.jkeating@redhat.com> References: <466826A3.10905@redhat.com> <200706071146.30373.jkeating@redhat.com> <46682925.7070105@redhat.com> <200706071154.00036.jkeating@redhat.com> Message-ID: <46686924.8070708@redhat.com> Jesse Keating said the following on 06/07/2007 08:53 AM Pacific Time: > On Thursday 07 June 2007 11:49:57 Mike McGrath wrote: >> I agree, I had no plans on upgrading any of our RHEL boxes (except for >> cvs and db1 but will stay in the RHEL upgrade path). For those of you >> that are new on the list we've had a lot of discussions about this in >> the past. Our team, for the most part, agrees that its about picking >> the right tool for the job. For boxes that don't need brand new >> technologies (like cvs) its nice to be able to set them up and forget >> about them. But for some boxes that do need the latest and greatest >> (like our builders) we've always had and kept them on Fedora. > > With RHEL5 out, I question the need for Fedora on the builders. In fact, > before the merge, all the internal Core builders were running RHEL4. Can we > not use RHEL5 on the builders now? > What are the arguments against "eating our own dogfood" and running on FedoraX? I know there are probably good reasons, but thought it would be good to get it out in the open as others less informed (like myself) will probably ask :) Thanks, John From mmcgrath at redhat.com Thu Jun 7 20:27:27 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 07 Jun 2007 15:27:27 -0500 Subject: Fedora 7 Upgrade In-Reply-To: <46686924.8070708@redhat.com> References: <466826A3.10905@redhat.com> <200706071146.30373.jkeating@redhat.com> <46682925.7070105@redhat.com> <200706071154.00036.jkeating@redhat.com> <46686924.8070708@redhat.com> Message-ID: <46686A2F.7060101@redhat.com> John Poelstra wrote: > > What are the arguments against "eating our own dogfood" and running on > FedoraX? I know there are probably good reasons, but thought it would > be good to get it out in the open as others less informed (like > myself) will probably ask :) Its been discussed in previous threads and in this one. Its about picking the right tool for the job. No one wants us to schedule cvs outages regularly just to upgrade the OS. The least risky route is to set stuff like that up with an OS that A) doesn't need to be re-installed often and B) doesn't need very many updates. RHEL has far fewer updates then Fedora and we don't benefit any from running it on fedora. -Mike From jkeating at redhat.com Thu Jun 7 21:12:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 17:12:24 -0400 Subject: Fedora 7 Upgrade In-Reply-To: <1181233697.4070.87.camel@localhost.localdomain> References: <466826A3.10905@redhat.com> <200706071154.00036.jkeating@redhat.com> <1181233697.4070.87.camel@localhost.localdomain> Message-ID: <200706071712.24737.jkeating@redhat.com> On Thursday 07 June 2007 12:28:17 Toshio Kuratomi wrote: > Will we want to pull in new features for the builders? ?Something like a > change in rpm is needed for a new version of mock. ?We want that change > and so we need to upgrade? > > I just want to avoid flip-flopping between RHEL and Fedora. Well, one of the things we've been very careful with is making sure we don't put ourselves in this position, and sometimes that does mean limiting the kind of changes we can do to things like rpm in Fedora, or spec files or whatnot. While I appreciate not wanting to flip/flop between RHEL and Fedora, I don't want to upgrade the builders every 6~13 months either (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kzak at redhat.com Thu Jun 7 23:39:40 2007 From: kzak at redhat.com (Karel Zak) Date: Fri, 8 Jun 2007 01:39:40 +0200 Subject: RFR: GIT Package VCS In-Reply-To: <1181226311.18649.40.camel@aglarond.local> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181158369.4009.93.camel@lt21223.campus.dmacc.edu> <1181160985.8071.95.camel@erebor.boston.redhat.com> <1181163234.22157.92.camel@localhost.localdomain> <1181165517.8071.110.camel@erebor.boston.redhat.com> <1181184417.14656.13.camel@localhost.localdomain> <1181226311.18649.40.camel@aglarond.local> Message-ID: <20070607233940.GN16879@petra.dvoda.cz> On Thu, Jun 07, 2007 at 10:25:11AM -0400, Jeremy Katz wrote: > On Wed, 2007-06-06 at 22:46 -0400, Christopher Blizzard wrote: > > On Wed, 2007-06-06 at 17:31 -0400, Jeremy Katz wrote: > > > At the same time, I think we still need to be able to very clearly > > > separate out our changes from what upstream has. > And fundamentally, I think that the "pristine source + patches" bit is > just as important today as it was 10 years ago. Because otherwise, you > get into a situation where you basically encourage forking and not > contributing things back upstream. Your response is going to be "but I think that maintain "tarballs + patches" is no good idea. This thing is *very good* for distribution in src.rpms, but I hate it in VCS. I'd like to see all code (include upstream code) in VCS. You can still export all your changes from GIT as small patches. The solution is branches. You can use one branch for pristine upstream source code and other branch for upstream code + fedora patches. Finally, you can export pristine source and patches, compress the upstream code back to tarball and distribute the tarball + patches by src.rpm. My wish is "git rebase" always after upgrade to new upstream code. The current "make prep" is nightmare... See Linux kernel. That's normal that people maintain their patches outside official tree(s) for pretty long time. The modern VCS is the right tool for this job. "separate out our changes from what upstream has" .. is definitely no problem. Karel -- Karel Zak From notting at redhat.com Thu Jun 7 23:39:33 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 7 Jun 2007 19:39:33 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <20070607233940.GN16879@petra.dvoda.cz> References: <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181158369.4009.93.camel@lt21223.campus.dmacc.edu> <1181160985.8071.95.camel@erebor.boston.redhat.com> <1181163234.22157.92.camel@localhost.localdomain> <1181165517.8071.110.camel@erebor.boston.redhat.com> <1181184417.14656.13.camel@localhost.localdomain> <1181226311.18649.40.camel@aglarond.local> <20070607233940.GN16879@petra.dvoda.cz> Message-ID: <20070607233933.GF31520@nostromo.devel.redhat.com> Karel Zak (kzak at redhat.com) said: > My wish is "git rebase" always after upgrade to new upstream code. > The current "make prep" is nightmare... > > See Linux kernel. That's normal that people maintain their patches > outside official tree(s) for pretty long time. The modern VCS is the > right tool for this job. > > "separate out our changes from what upstream has" .. is definitely > no problem. Well, it depends on what you're doing. DaveJ tried to move to git pulling the various things we need for our kernel - it ended up being a pretty big problem getting something sane out of it, and he ended up going back to patches. Bill From kzak at redhat.com Thu Jun 7 23:50:42 2007 From: kzak at redhat.com (Karel Zak) Date: Fri, 8 Jun 2007 01:50:42 +0200 Subject: RFR: GIT Package VCS In-Reply-To: <20070607233933.GF31520@nostromo.devel.redhat.com> References: <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181158369.4009.93.camel@lt21223.campus.dmacc.edu> <1181160985.8071.95.camel@erebor.boston.redhat.com> <1181163234.22157.92.camel@localhost.localdomain> <1181165517.8071.110.camel@erebor.boston.redhat.com> <1181184417.14656.13.camel@localhost.localdomain> <1181226311.18649.40.camel@aglarond.local> <20070607233940.GN16879@petra.dvoda.cz> <20070607233933.GF31520@nostromo.devel.redhat.com> Message-ID: <20070607235040.GO16879@petra.dvoda.cz> On Thu, Jun 07, 2007 at 07:39:33PM -0400, Bill Nottingham wrote: > Karel Zak (kzak at redhat.com) said: > > My wish is "git rebase" always after upgrade to new upstream code. > > The current "make prep" is nightmare... > > > > See Linux kernel. That's normal that people maintain their patches > > outside official tree(s) for pretty long time. The modern VCS is the > > right tool for this job. > > > > "separate out our changes from what upstream has" .. is definitely > > no problem. > > Well, it depends on what you're doing. DaveJ tried to move to git > pulling the various things we need for our kernel - it ended up > being a pretty big problem getting something sane out of it, and he > ended up going back to patches. Yes, I remember a discussion about it. I'm not sure if this one DaveJ's attempt is enough to completely reject this idea ;-) Karel -- Karel Zak From lmacken at redhat.com Fri Jun 8 00:52:29 2007 From: lmacken at redhat.com (Luke Macken) Date: Thu, 7 Jun 2007 20:52:29 -0400 Subject: Fedora 7 Upgrade In-Reply-To: <46683E05.5050105@redhat.com> References: <466826A3.10905@redhat.com> <1181234651.4070.99.camel@localhost.localdomain> <46683E05.5050105@redhat.com> Message-ID: <20070608005229.GA3218@tomservo.rochester.rr.com> On Thu, Jun 07, 2007 at 12:19:01PM -0500, Mike McGrath wrote: > Toshio Kuratomi wrote: > > Depends... > > > > What is the reason for those boxes to be on Fedora instead of RHEL? If > > it's because FC6 had things not in RHEL4 maybe we can make a switch to > > RHEL5 at some point. If the reason is we want the flexibility of moving > > to the latest code along with Fedora instead of waiting for RHEL to > > upgrade/backport then perhaps they should be on the latest Fedora where > > the latest code is more likely to land sooner. > > > > In the case of the app servers running TurboGears, I think that it was a > > lack of TG requirements on RHEL4 that held us back. I also think we're > > close to having TG for RHEL5 so we might want to move test servers to > > RHEL5, check that the applications run there, and then move the app > > servers handling those to RHEL. > > > > This is very true as well, I've not tested the TG status in RHEL5. Has > anyone else? Luke? Looks like we're just waiting on python-kid[0]. luke [0]: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239134 From smooge at gmail.com Fri Jun 8 00:57:22 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 7 Jun 2007 18:57:22 -0600 Subject: RFR: GIT Package VCS In-Reply-To: <1181184417.14656.13.camel@localhost.localdomain> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181158369.4009.93.camel@lt21223.campus.dmacc.edu> <1181160985.8071.95.camel@erebor.boston.redhat.com> <1181163234.22157.92.camel@localhost.localdomain> <1181165517.8071.110.camel@erebor.boston.redhat.com> <1181184417.14656.13.camel@localhost.localdomain> Message-ID: <80d7e4090706071757h30bdfe69v1700aae7a8f7b95b@mail.gmail.com> On 6/6/07, Christopher Blizzard wrote: > > > This might sound crazy (SUPPORT > 1 SYSTEM, ARE YOU CRAZY?) Well, yes, > > > until you realize what you need to do here. To start with you only have > > > to teach the rpm build side how pull a specific tag from a specific > > > repo. On the query side we need a browser for each kind, which is a bit > > > of work, but something I think we need to do anyway. (i.e. "What would > > > git do?") > > > > So if I am the owner of the rpm package which has an upstream of hg and > > want to fix, test and commit a change to say (for the sake of argument) > > neon which is in git, I now have to know two different systems? You're > > crazy ;-) > > No. If you happen to be a maintainer _and_ a developer and you have > _chosen_ to use hg or git or whatever, then we make it easy for you. > This is about adding options to bring us closer to the upstream > developers and make their lives easier. > Its been a very very long day, and I am running on fumes of fumes... but the only way I could see the workflow you are wanting to happen is that if there are appropriate front-ends for the 'maintainer/developer/qa/nth-party' to work with. Basically the front-end does not give a rats pee about what the backend is this week or next week. All it does is give say the worker a set of common commands and then interprets those for the backend systems. The tools would be meta-meta-tools and would probably slower than an snail in a Canadian December on some systems.. but might be possible if you outline a simple choice selection and pluginability (you get 2 from column A, 1 from B.. anything else you write yourself). $ smoogeit create project kernel uses git with head git.kernel.org # this creates both locally and say a Fedora repo and uses whatever common lower end system. maybe some extra files to edit files.. it then talks to the git.kernel.org in git $ smoogeit add patch # adds the git stuff silently behind the scenes $ smoogeit create project smooge-firewall uses sccm with head local://blah the final workflow might be something like: $ smoogeit publish kernel branch F7 which pushes it in a way that the Fedora build systems might be able to handle stuff like In this never to be written system.. the build/errata/vcs/support/bugzilla system is semi-integrated together. The developer can use git for his own project and then just tell the smoogeit to publish it for SmoogeOS. The maintainer can talk to whatever the developer has and push back or keep their own local tree without having to know 8 systems. Now like I said.. its shooting the moon to see this ever work.. and I would believe that it would require you to keep the smoogeit system to a limited number of commands and let any extras that a particular system has extra in it be done as plugins like yum. My take on it would be that there might be a 'hidden/common' system underneath all this to make the buildsystem sane to debug.. so while you check out to your laptop using git/cvs/mercurial/arch/svn/darcs/rcs/sccm/monotone/MicrosoftStuff and your upstream commits are done that way.. the build system stores it in a known format. Other people could chose to pull from either the build system or the upstream... wow so many fricking choices these days and I used to have to deal with SCCM/RCS arguments. Anyway going to sleep. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From smooge at gmail.com Fri Jun 8 01:02:49 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 7 Jun 2007 19:02:49 -0600 Subject: RFR: GIT Package VCS In-Reply-To: <1181152249.22157.44.camel@localhost.localdomain> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> Message-ID: <80d7e4090706071802u797fd2f3qe4cd6e012e6c9e3a@mail.gmail.com> On 6/6/07, Christopher Blizzard wrote: > On Wed, 2007-06-06 at 10:31 -0400, Jeremy Katz wrote: > > > > Right. I really don't think we want to just take our current system, > > switch out CVS, and end up with all of the same workflows. The change > > should be more about how do we improve workflows. That means thinking > > about things like: > > * How do we make it easier for a maintainer to rebase their package to > > a > > newer upstream? > > * How do we make it easier for a maintainer to develop, test, and > > create > > a patch to fix a problem that's being experienced in Fedora? > > * How do we make it easy to send these patches to the upstream of the > > project being worked on? > > * How do we enable downstreams to take our bits, track them and make > > changes as they need/want? > > * How do we better enable a user who has a problem with something we > > ship to be able to fix it themselves and get the fix back to us? stuff snipped. > o Do we want to move to a process where code is just in a repo and it's > built automatically instead of source + patches + spec file? > I am on fumes as I said.. but I do not see how the last 2 points above from Jeremy can be done with this one. Do you have an idea or is this something that is blindingly obvious? Thanks. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jkeating at redhat.com Fri Jun 8 01:18:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 21:18:03 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <80d7e4090706071802u797fd2f3qe4cd6e012e6c9e3a@mail.gmail.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <1181152249.22157.44.camel@localhost.localdomain> <80d7e4090706071802u797fd2f3qe4cd6e012e6c9e3a@mail.gmail.com> Message-ID: <200706072118.04076.jkeating@redhat.com> On Thursday 07 June 2007 21:02:49 Stephen John Smoogen wrote: > > > * How do we enable downstreams to take our bits, track them and make > > > changes as they need/want? > > > * How do we better enable a user who has a problem with something we > > > ship to be able to fix it themselves and get the fix back to us? > > stuff snipped. > > > o Do we want to move to a process where code is just in a repo and it's > > built automatically instead of source + patches + spec file? > > I am on fumes as I said.. but I do not see how the last 2 points above > from Jeremy can be done with this one. Do you have an idea or is this > something that is blindingly obvious? We have two things for the upstream in our package SCM. We have the prestine tarball stashed away in a lookaside, and we have an exploaded tree of the source. We use the exploaded tree of the source to manage our patches to that source and to help with rebases. However the patches we manage always apply to the prestine point. At package build time, the patches we manage + the spec file + the prestine tarball stashed away are combined to make an srpm, and that is shoved through the build system. In this case, the exploaded source services us as a better way to manage our patches and to help with rebasing. It also provides a service to upstreams so that they can easily cherry pick our patches out of the exploaded source, same with downstreams, and same with somebody playing at home. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Fri Jun 8 01:59:27 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 07 Jun 2007 18:59:27 -0700 Subject: RFR: GIT Package VCS In-Reply-To: <200706072118.04076.jkeating@redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <1181152249.22157.44.camel@localhost.localdomain> <80d7e4090706071802u797fd2f3qe4cd6e012e6c9e3a@mail.gmail.com> <200706072118.04076.jkeating@redhat.com> Message-ID: <1181267967.4070.309.camel@localhost.localdomain> On Thu, 2007-06-07 at 21:18 -0400, Jesse Keating wrote: > > We have two things for the upstream in our package SCM. We have the prestine > tarball stashed away in a lookaside, and we have an exploaded tree of the > source. We use the exploaded tree of the source to manage our patches to > that source and to help with rebases. However the patches we manage always > apply to the prestine point. At package build time, the patches we manage + > the spec file + the prestine tarball stashed away are combined to make an > srpm, and that is shoved through the build system. > > So I see two ways to store patches: vendor-branch | |-- Foo.patch branch | |-- Bar.patch branch Foo.patch and Bar.patch both directly apply to the upstream vendor branch. vendor-branch | |-- Foo.patch branch | |-- Bar.patch branch Foo.patch is the first patch against vendor-branch. Bar.patch is committed to the combination of vendor-branch and Foo.patch. At first I was hoping to do the first way as it makes it easier to cherrypick changes for upstream. However, it quickly became complex as we had to manage a separate merge branch that was equivalent to the second storage graph. Whenever we rebased we would potentially have to remove conflicts from the second graph as well as the first. So I decided that going directly to the second style was preferable. That does not have the enhanced cherrypicking benefits to upstream but it still allows us to work with individual patches within the VCS more easily than when they were simply patches stored in CVS. Do you see a way around this limitation? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Fri Jun 8 05:57:59 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 08 Jun 2007 11:27:59 +0530 Subject: redirect f.r.c to fp.o and not the fp.o wiki Message-ID: <4668EFE7.6030204@fedoraproject.org> Hi Just a quick reminder that this hasn't been done yet. Rahul From mmcgrath at redhat.com Fri Jun 8 13:36:01 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 08 Jun 2007 08:36:01 -0500 Subject: redirect f.r.c to fp.o and not the fp.o wiki In-Reply-To: <4668EFE7.6030204@fedoraproject.org> References: <4668EFE7.6030204@fedoraproject.org> Message-ID: <46695B41.7010107@redhat.com> Rahul Sundaram wrote: > Hi > > Just a quick reminder that this hasn't been done yet. I'm working on some web stuff today, I'll make sure this gets done. -Mike From kwade at redhat.com Fri Jun 8 15:30:26 2007 From: kwade at redhat.com (Karsten Wade) Date: Fri, 08 Jun 2007 08:30:26 -0700 Subject: redirect f.r.c to fp.o and not the fp.o wiki In-Reply-To: <46695B41.7010107@redhat.com> References: <4668EFE7.6030204@fedoraproject.org> <46695B41.7010107@redhat.com> Message-ID: <1181316626.3469.282.camel@erato.phig.org> On Fri, 2007-06-08 at 08:36 -0500, Mike McGrath wrote: > Rahul Sundaram wrote: > > Hi > > > > Just a quick reminder that this hasn't been done yet. > > I'm working on some web stuff today, I'll make sure this gets done. Did Rahul put in a ticket for this? Does F-Infra prefer to use tickets? - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tchung at fedoraproject.org Fri Jun 8 15:37:15 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Fri, 8 Jun 2007 08:37:15 -0700 Subject: redirect f.r.c to fp.o and not the fp.o wiki In-Reply-To: <1181316626.3469.282.camel@erato.phig.org> References: <4668EFE7.6030204@fedoraproject.org> <46695B41.7010107@redhat.com> <1181316626.3469.282.camel@erato.phig.org> Message-ID: <369bce3b0706080837q135db8e3ia7a293711011b8f6@mail.gmail.com> On 6/8/07, Karsten Wade wrote: > On Fri, 2007-06-08 at 08:36 -0500, Mike McGrath wrote: > > Rahul Sundaram wrote: > > > Hi > > > > > > Just a quick reminder that this hasn't been done yet. > > > > I'm working on some web stuff today, I'll make sure this gets done. > > Did Rahul put in a ticket for this? > > Does F-Infra prefer to use tickets? Would that be Bugzilla or OTRS[1] ? http://fedoraproject.org/wiki/Infrastructure/Tickets Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From mmcgrath at redhat.com Fri Jun 8 16:06:38 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 08 Jun 2007 11:06:38 -0500 Subject: redirect f.r.c to fp.o and not the fp.o wiki In-Reply-To: <1181316626.3469.282.camel@erato.phig.org> References: <4668EFE7.6030204@fedoraproject.org> <46695B41.7010107@redhat.com> <1181316626.3469.282.camel@erato.phig.org> Message-ID: <46697E8E.5040503@redhat.com> Karsten Wade wrote: > On Fri, 2007-06-08 at 08:36 -0500, Mike McGrath wrote: > >> Rahul Sundaram wrote: >> >>> Hi >>> >>> Just a quick reminder that this hasn't been done yet. >>> >> I'm working on some web stuff today, I'll make sure this gets done. >> > > Did Rahul put in a ticket for this? > > Does F-Infra prefer to use tickets? > It goes both ways, The ticketing system, unfortunately, largely gets ignored. I still question whether we should continue using it or move to something else. -Mike From mmahut at fedoraproject.org Fri Jun 8 16:31:25 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Fri, 08 Jun 2007 18:31:25 +0200 Subject: redirect f.r.c to fp.o and not the fp.o wiki In-Reply-To: <369bce3b0706080837q135db8e3ia7a293711011b8f6@mail.gmail.com> References: <4668EFE7.6030204@fedoraproject.org> <46695B41.7010107@redhat.com> <1181316626.3469.282.camel@erato.phig.org> <369bce3b0706080837q135db8e3ia7a293711011b8f6@mail.gmail.com> Message-ID: <4669845D.6040509@fedoraproject.org> Thomas Chung wrote: > On 6/8/07, Karsten Wade wrote: >> On Fri, 2007-06-08 at 08:36 -0500, Mike McGrath wrote: >> > Rahul Sundaram wrote: >> > > Hi >> > > >> > > Just a quick reminder that this hasn't been done yet. >> > >> > I'm working on some web stuff today, I'll make sure this gets done. >> >> Did Rahul put in a ticket for this? >> >> Does F-Infra prefer to use tickets? > > Would that be Bugzilla or OTRS[1] ? > http://fedoraproject.org/wiki/Infrastructure/Tickets IMO, RequestTracker is better for this kinds of ticketing system that otrs. > Regards, -- Marek Mahut Tel.: +420-532-294-111 (ex. 826-2046) Fedora Ambassador GSM: +420-731-076-674 http://www.fedoraproject.org http://www.jamendo.com ____________________________________________________________________ From rayvd at bludgeon.org Fri Jun 8 16:36:07 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Fri, 8 Jun 2007 09:36:07 -0700 Subject: redirect f.r.c to fp.o and not the fp.o wiki In-Reply-To: <4669845D.6040509@fedoraproject.org> References: <4668EFE7.6030204@fedoraproject.org> <46695B41.7010107@redhat.com> <1181316626.3469.282.camel@erato.phig.org> <369bce3b0706080837q135db8e3ia7a293711011b8f6@mail.gmail.com> <4669845D.6040509@fedoraproject.org> Message-ID: <20070608163607.GA17181@bludgeon.org> On Fri, Jun 08, 2007 at 06:31:25PM +0200, Marek Mahut wrote: > Thomas Chung wrote: > > On 6/8/07, Karsten Wade wrote: > >> On Fri, 2007-06-08 at 08:36 -0500, Mike McGrath wrote: > >> > Rahul Sundaram wrote: > >> > > Hi > >> > > > >> > > Just a quick reminder that this hasn't been done yet. > >> > > >> > I'm working on some web stuff today, I'll make sure this gets done. > >> > >> Did Rahul put in a ticket for this? > >> > >> Does F-Infra prefer to use tickets? > > Would that be Bugzilla or OTRS[1] ? > > http://fedoraproject.org/wiki/Infrastructure/Tickets > > IMO, RequestTracker is better for this kinds of ticketing system that otrs. > There's always Roundup as well: http://roundup.sourceforge.net/ I like it because it's very lightweight. It's also Python which might be a plus as well. Ray From mmcgrath at redhat.com Fri Jun 8 16:41:19 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 08 Jun 2007 11:41:19 -0500 Subject: redirect f.r.c to fp.o and not the fp.o wiki In-Reply-To: <4669845D.6040509@fedoraproject.org> References: <4668EFE7.6030204@fedoraproject.org> <46695B41.7010107@redhat.com> <1181316626.3469.282.camel@erato.phig.org> <369bce3b0706080837q135db8e3ia7a293711011b8f6@mail.gmail.com> <4669845D.6040509@fedoraproject.org> Message-ID: <466986AF.3010604@redhat.com> Marek Mahut wrote: > > IMO, RequestTracker is better for this kinds of ticketing system that > otrs. > > The problem isn't the tool, the issue is workflow and usage. -Mike From sundaram at fedoraproject.org Fri Jun 8 18:21:39 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 08 Jun 2007 23:51:39 +0530 Subject: smolt and bug reports Message-ID: <46699E33.20301@fedoraproject.org> Hi Any reason why smolt trac instance bug reporting is being restricted at https://hosted.fedoraproject.org/projects/smolt/newticket? There isn't a bugzilla component either. Rahul From mmcgrath at redhat.com Fri Jun 8 18:26:06 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 08 Jun 2007 13:26:06 -0500 Subject: smolt and bug reports In-Reply-To: <46699E33.20301@fedoraproject.org> References: <46699E33.20301@fedoraproject.org> Message-ID: <46699F3E.2000201@redhat.com> Rahul Sundaram wrote: > Hi > > Any reason why smolt trac instance bug reporting is being restricted > at https://hosted.fedoraproject.org/projects/smolt/newticket? There > isn't a bugzilla component either. Because all track bugs are and there is a bugzilla component for smolt. -Mike From jkeating at redhat.com Fri Jun 8 18:49:18 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 14:49:18 -0400 Subject: smolt and bug reports In-Reply-To: <46699E33.20301@fedoraproject.org> References: <46699E33.20301@fedoraproject.org> Message-ID: <200706081449.18416.jkeating@redhat.com> On Friday 08 June 2007 14:21:39 Rahul Sundaram wrote: > Any reason why smolt trac instance bug reporting is being restricted at > https://hosted.fedoraproject.org/projects/smolt/newticket? To prevent spam, and to ensure that the filer uses an address that we can get back to for feedback on potential fixes. Same reason that the wiki components don't allow anonymous edits in Trac spaces. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Jun 8 18:53:14 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 09 Jun 2007 00:23:14 +0530 Subject: smolt and bug reports In-Reply-To: <200706081449.18416.jkeating@redhat.com> References: <46699E33.20301@fedoraproject.org> <200706081449.18416.jkeating@redhat.com> Message-ID: <4669A59A.3060408@fedoraproject.org> Jesse Keating wrote: > On Friday 08 June 2007 14:21:39 Rahul Sundaram wrote: >> Any reason why smolt trac instance bug reporting is being restricted at >> https://hosted.fedoraproject.org/projects/smolt/newticket? > > To prevent spam, and to ensure that the filer uses an address that we can get > back to for feedback on potential fixes. Same reason that the wiki > components don't allow anonymous edits in Trac spaces. Shouldn't all trac projects disable this then? It doesn't currently. Rahul From jkeating at redhat.com Fri Jun 8 20:02:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 16:02:08 -0400 Subject: smolt and bug reports In-Reply-To: <4669A59A.3060408@fedoraproject.org> References: <46699E33.20301@fedoraproject.org> <200706081449.18416.jkeating@redhat.com> <4669A59A.3060408@fedoraproject.org> Message-ID: <200706081602.08418.jkeating@redhat.com> On Friday 08 June 2007 14:53:14 Rahul Sundaram wrote: > Shouldn't all trac projects disable this then? It doesn't currently. I may have missed some when I started blocking it off. Can you tell me which ones don't block it? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Jun 8 21:53:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 09 Jun 2007 03:23:55 +0530 Subject: smolt and bug reports In-Reply-To: <200706081602.08418.jkeating@redhat.com> References: <46699E33.20301@fedoraproject.org> <200706081449.18416.jkeating@redhat.com> <4669A59A.3060408@fedoraproject.org> <200706081602.08418.jkeating@redhat.com> Message-ID: <4669CFF3.3080009@fedoraproject.org> Jesse Keating wrote: > On Friday 08 June 2007 14:53:14 Rahul Sundaram wrote: >> Shouldn't all trac projects disable this then? It doesn't currently. > > I may have missed some when I started blocking it off. Can you tell me which > ones don't block it? > https://hosted.fedoraproject.org/projects/revisor/newticket https://hosted.fedoraproject.org/projects/LHCP/newticket https://hosted.fedoraproject.org/projects/mirrormanager/newticket https://hosted.fedoraproject.org/projects/mock/newticket https://hosted.fedoraproject.org/projects/presto/newticket https://hosted.fedoraproject.org/projects/readahead/newticket https://hosted.fedoraproject.org/projects/revisor/newticket https://hosted.fedoraproject.org/projects/setroubleshoot/newticket Rahul From a.badger at gmail.com Fri Jun 8 23:52:45 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 08 Jun 2007 16:52:45 -0700 Subject: new python-fedora In-Reply-To: <20070604053718.GK13318@tomservo.rochester.rr.com> References: <1180755274.19774.137.camel@localhost.localdomain> <20070604053718.GK13318@tomservo.rochester.rr.com> Message-ID: <1181346765.2645.77.camel@localhost.localdomain> On Mon, 2007-06-04 at 01:37 -0400, Luke Macken wrote: > On Fri, Jun 01, 2007 at 08:34:34PM -0700, Toshio Kuratomi wrote: > > After looking at a traceback from Bodhi, I put together a new > > python-fedora to hopefully address that. It's available from my home > > directory on bastion: > > /home/fedora/toshio/python-fedora-0.2.90.8-1.noarch.rpm > > > > I've only tested this on the pkgdb test machines so if you still have a > > test instance, try it out there before loading it onto the main > > instances of mirrormanager, Bodhi, etc. > > Seems to be working fine for me. I've been testing it for the past > couple of days in my test instance, and deployed it tonight on app5 for > bodhi. > > We should probably find a home for this thing in git/hg/whatev. Yeah -- I have it in a bazaar repository on bastion [1]_ but getting it into hosted gives us an issue tracker and such. Maybe I'll look into getting a bzr server setup for hosted some night. [1]_: bzr branch sftp://bastion.fedora.redhat.com/home/fedora/toshio/repo/python-fedora -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dev at nigelj.com Sat Jun 9 03:08:00 2007 From: dev at nigelj.com (Nigel Jones) Date: Sat, 09 Jun 2007 15:08:00 +1200 Subject: Self Introduction Message-ID: <466A1990.5020601@nigelj.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm Nigel Jones, I've been putting off sending this email for a couple of weeks now (for various reasons), but as everyone is focused again for the next release, I'd like to join in and help. At the moment I'm an IT student at Computer Power Institute (http://www.computerpower.ac.nz), doing a networking diploma. I'm hoping to be able to help out with the development and testing of PackageDB which Toshio is leading (I've already talked to him on IRC). I think I've provided all the important bits. Regards, N.J. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGahmQpldg9bRmG6kRAk2RAKCFKxYM1kJ3KtrBQW4/OlNkQIR4sACeP8ba D8/UKqDTTs/GYPEuJGHP1zU= =3EhM -----END PGP SIGNATURE----- From josemanimala at gmail.com Sat Jun 9 06:48:05 2007 From: josemanimala at gmail.com (jose manimala) Date: Sat, 9 Jun 2007 12:18:05 +0530 Subject: Fedora 7 Upgrade In-Reply-To: <20070608005229.GA3218@tomservo.rochester.rr.com> References: <466826A3.10905@redhat.com> <1181234651.4070.99.camel@localhost.localdomain> <46683E05.5050105@redhat.com> <20070608005229.GA3218@tomservo.rochester.rr.com> Message-ID: <53a863600706082348i518a9550n74f245b9f018b536@mail.gmail.com> Would'nt it be a good idea to make respins of the fedora core 7 for internal use. Like For app servers we can have a permanent set of features and for test servers we can have another. there will be too many respins but it will make it easier later on in the future when we can just upgrade a respin to newer versions. That way we can avoid RHEL as such and run Fedora on all systems. I dont know but i seem to prefer Fedora over RHEL. There might still be some packages that are proprietary.... that will be the only problem faced is it not..... just a suggestion Jose M manimala From anthonybryan at gmail.com Sat Jun 9 08:22:24 2007 From: anthonybryan at gmail.com (Anthony Bryan) Date: Sat, 9 Jun 2007 04:22:24 -0400 Subject: MirrorManager (was Re: Improving availability and guaranteeing integrity in ISO downloads) Message-ID: Hello, this is a repost of a message to fedora-devel, as this seems to be the place for it. > From: Jesse Keating > > On Friday 08 June 2007 14:24:47 Anthony Bryan wrote: > > I was hoping Fedora could investigate using Metalinks for their ISO > > downloads. Metalink is an XML format for listing all the ways you can > > get a file or collection of files (mirrors + their location, rsync, > > p2p) along with checksums to automatically repair a file in case of > > error, signatures, language, OS/arch, and other metadata. It's mainly > > used for large files like ISOs, where errors can be very frustrating. > > > > It's supported by about 20 programs on unix, mac, and win, including > > aria2 (already in the Fedora repos). It's used by openSUSE, > > OpenOffice.org, cURL, and many other distributions. > > > > Here's a screenshot of a Metalink download in the DownThemAll Firefox > > extension (nightly build). What you don't see are all the mirrors and > > checksums. > > http://code.downthemall.net/maierman/metaselect4.png > > > > http://en.wikipedia.org/wiki/Metalink > > This is something interesting, and I wonder if we could make use of > MirrorManager ( https://hosted.fedoraproject.org/projects/mirrormanager ) to > have dynamic .metalink files created with updated mirror readiness info. > Certainly something that looks worth looking into. That would be quite nice, no one else has dynamic .metalinks on a large scale. When I got the F7 ISO, I noticed it would fit in well w/ the download pages which tell which mirrors have which releases. I think it would make things less frustrating for end users trying to get things, and hopefully create less strain on mirrors. Certain metalink clients will download from domestic mirrors first, if country info is in there, which should hopefully be more efficient for everyone. What can we do to make this happen? Is this the type of thing that's easier for the maintainer of MirrorManager to add, or should we supply a patch? Here's the current tools people have done, if that helps - http://www.metalinker.org/implementation.html#generate Metalink Editor - in Python, GUI cURL - they use a short Perl script that makes them based on location. Simba/RoPkg::Metalink - Perl Bouncer - there's a patch for it. Metalink tools - CLI, C++ -- (( Anthony Bryan )) Metalink [ http://www.metalinker.org ] From Matt_Domsch at dell.com Sat Jun 9 12:23:25 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 9 Jun 2007 07:23:25 -0500 Subject: MirrorManager (was Re: Improving availability and guaranteeing integrity in ISO downloads) In-Reply-To: References: Message-ID: <20070609122325.GB20769@lists.us.dell.com> On Sat, Jun 09, 2007 at 04:22:24AM -0400, Anthony Bryan wrote: > Hello, this is a repost of a message to fedora-devel, as this seems to > be the place for it. > > >From: Jesse Keating > > > >On Friday 08 June 2007 14:24:47 Anthony Bryan wrote: > >> I was hoping Fedora could investigate using Metalinks for their ISO > >> downloads. Metalink is an XML format for listing all the ways you can > >> get a file or collection of files (mirrors + their location, rsync, > >> p2p) along with checksums to automatically repair a file in case of > >> error, signatures, language, OS/arch, and other metadata. It's mainly > >> used for large files like ISOs, where errors can be very frustrating. > >> > >> It's supported by about 20 programs on unix, mac, and win, including > >> aria2 (already in the Fedora repos). It's used by openSUSE, > >> OpenOffice.org, cURL, and many other distributions. > >> > >> Here's a screenshot of a Metalink download in the DownThemAll Firefox > >> extension (nightly build). What you don't see are all the mirrors and > >> checksums. > >> http://code.downthemall.net/maierman/metaselect4.png > >> > >> http://en.wikipedia.org/wiki/Metalink > > > >This is something interesting, and I wonder if we could make use of > >MirrorManager ( https://hosted.fedoraproject.org/projects/mirrormanager ) > >to > >have dynamic .metalink files created with updated mirror readiness info. > >Certainly something that looks worth looking into. > > That would be quite nice, no one else has dynamic .metalinks on a > large scale. When I got the F7 ISO, I noticed it would fit in well w/ > the download pages which tell which mirrors have which releases. I > think it would make things less frustrating for end users trying to > get things, and hopefully create less strain on mirrors. Certain > metalink clients will download from domestic mirrors first, if country > info is in there, which should hopefully be more efficient for > everyone. > > What can we do to make this happen? Is this the type of thing that's > easier for the maintainer of MirrorManager to add, or should we supply > a patch? I saw some articles on metalink and spent time time looking at it a few weeks ago. Good stuff. Patches are certainly welcome. What I picture is a new application 'generate_metalinks' along the lines of the generate_mirrorlists application within mirrormanager that connects to the database, finds what it wants, and generates static .metalink text files. You'd probably only want to metalink the .ISOs, of which there are plenty. No sense making .metalink files for every file in the (presently) 660GB file system. Then we also need to generate static web pages that include HTML links to all the .metalink files. And link to those from somewhere in the mirrors.fedoraproject.org/ namespace, maybe mirrors.fp.o/metalink/index.html plus all the .metalink files in a dir there. Then we add it into the update-static-content script that runs at the top of the hour, so they're dynamically generated. > Here's the current tools people have done, if that helps - > http://www.metalinker.org/implementation.html#generate > > Metalink Editor - in Python, GUI > cURL - they use a short Perl script that makes them based on location. > Simba/RoPkg::Metalink - Perl > Bouncer - there's a patch for it. > Metalink tools - CLI, C++ As mm is written in python + TurboGears, it would be great if the metalink creator tool was also in python. :-) Source to mm is available here: https://hosted.fedoraproject.org/projects/mirrormanager 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 From jkeating at redhat.com Sat Jun 9 12:46:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 08:46:11 -0400 Subject: Fedora 7 Upgrade In-Reply-To: <53a863600706082348i518a9550n74f245b9f018b536@mail.gmail.com> References: <466826A3.10905@redhat.com> <20070608005229.GA3218@tomservo.rochester.rr.com> <53a863600706082348i518a9550n74f245b9f018b536@mail.gmail.com> Message-ID: <200706090846.11747.jkeating@redhat.com> On Saturday 09 June 2007 02:48:05 jose manimala wrote: > Would'nt it be a good idea to make respins of the fedora core 7 for > internal use. Like For app servers we can have a permanent set of > features and for test servers we can have another. there will be too > many respins but it will make it easier later on in the future when we > can just upgrade a respin to newer versions. That way we can avoid > RHEL as such and run Fedora on all systems. I dont know but i seem to > prefer Fedora over RHEL. There might still be some packages that are > proprietary.... that will be the only problem faced is it not..... > just a suggestion > Respins aren't really that useful in this context. We can easily choose what we want to install, and we can easily apply the updates either during or after install. A respin won't help us in these manners. What we don't like about Fedora is there is not really any attempt to keep a non abi changing platform, the updates are fast and loose, and the distribution releases get flushed quickly. Fedora is great for short term or developmental servers, whereas RHEL/CentOS is far more suited for long term production environments. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Jun 9 12:48:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 08:48:46 -0400 Subject: smolt and bug reports In-Reply-To: <4669CFF3.3080009@fedoraproject.org> References: <46699E33.20301@fedoraproject.org> <200706081602.08418.jkeating@redhat.com> <4669CFF3.3080009@fedoraproject.org> Message-ID: <200706090848.46896.jkeating@redhat.com> On Friday 08 June 2007 17:53:55 Rahul Sundaram wrote: > https://hosted.fedoraproject.org/projects/revisor/newticket > https://hosted.fedoraproject.org/projects/LHCP/newticket > https://hosted.fedoraproject.org/projects/mirrormanager/newticket > https://hosted.fedoraproject.org/projects/mock/newticket > https://hosted.fedoraproject.org/projects/presto/newticket > https://hosted.fedoraproject.org/projects/readahead/newticket > https://hosted.fedoraproject.org/projects/revisor/newticket > https://hosted.fedoraproject.org/projects/setroubleshoot/newticket These should all be blocked now. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Sat Jun 9 14:04:17 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 09 Jun 2007 16:04:17 +0200 Subject: smolt and bug reports In-Reply-To: <200706090848.46896.jkeating@redhat.com> References: <46699E33.20301@fedoraproject.org> <200706081602.08418.jkeating@redhat.com> <4669CFF3.3080009@fedoraproject.org> <200706090848.46896.jkeating@redhat.com> Message-ID: <466AB361.4020600@kanarip.com> Jesse Keating wrote: > On Friday 08 June 2007 17:53:55 Rahul Sundaram wrote: >> https://hosted.fedoraproject.org/projects/revisor/newticket >> https://hosted.fedoraproject.org/projects/LHCP/newticket >> https://hosted.fedoraproject.org/projects/mirrormanager/newticket >> https://hosted.fedoraproject.org/projects/mock/newticket >> https://hosted.fedoraproject.org/projects/presto/newticket >> https://hosted.fedoraproject.org/projects/readahead/newticket >> https://hosted.fedoraproject.org/projects/revisor/newticket >> https://hosted.fedoraproject.org/projects/setroubleshoot/newticket > > These should all be blocked now. > So let me get this straight. We (kinda upstream) should have users log bugs in bugzilla, although we are using the hosted.fp.org ticketing system for the work we do? How do we get bugzilla tickets into Trac? Manually? Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Sat Jun 9 16:21:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 12:21:16 -0400 Subject: smolt and bug reports In-Reply-To: <466AB361.4020600@kanarip.com> References: <46699E33.20301@fedoraproject.org> <200706090848.46896.jkeating@redhat.com> <466AB361.4020600@kanarip.com> Message-ID: <200706091221.22130.jkeating@redhat.com> On Saturday 09 June 2007 10:04:17 Jeroen van Meeuwen wrote: > Jesse Keating wrote: > > On Friday 08 June 2007 17:53:55 Rahul Sundaram wrote: > >> https://hosted.fedoraproject.org/projects/revisor/newticket > >> https://hosted.fedoraproject.org/projects/LHCP/newticket > >> https://hosted.fedoraproject.org/projects/mirrormanager/newticket > >> https://hosted.fedoraproject.org/projects/mock/newticket > >> https://hosted.fedoraproject.org/projects/presto/newticket > >> https://hosted.fedoraproject.org/projects/readahead/newticket > >> https://hosted.fedoraproject.org/projects/revisor/newticket > >> https://hosted.fedoraproject.org/projects/setroubleshoot/newticket > > > > These should all be blocked now. > > So let me get this straight. We (kinda upstream) should have users log > bugs in bugzilla, although we are using the hosted.fp.org ticketing > system for the work we do? How do we get bugzilla tickets into Trac? > Manually? > Any user with a valid Fedora account (regardless of group) can open tickets in Trac. Just like any user with a valid bugzilla account can open bugs. Hopefully at some point it'll be very easy to get a Fedora account for stuff, or be able to use an existing OpenID for stuff. However the alternative of letting any random internet user or bot spam wikis or tickets is not good. The way I treat Trac and bugzilla is as such. Bugs get filed in bugzilla for a particular component in a particular release. IE this bug effects this release. If necessary, I file a ticket in Trac, the upstream, to fix the issue. Issue gets fixed in Trac, Trac ticket gets closed. Once I've rolled that fix into an update or testing update for the Fedora product then I'd alter the bugzilla ticket. Since my Trac project could potentially be used by other distributions/users I don't want to tie everything to Fedora distribution releases. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From frosario777 at gmail.com Sat Jun 9 18:53:14 2007 From: frosario777 at gmail.com (Freddie Rosario) Date: Sat, 9 Jun 2007 11:53:14 -0700 Subject: Fedora 7 Upgrade In-Reply-To: <200706090846.11747.jkeating@redhat.com> References: <466826A3.10905@redhat.com> <20070608005229.GA3218@tomservo.rochester.rr.com> <53a863600706082348i518a9550n74f245b9f018b536@mail.gmail.com> <200706090846.11747.jkeating@redhat.com> Message-ID: I agree with Jesse. We should keep to a more stable platform with fewer updates for production servers. As far as eating our own dog food. I think this is also necessary in order to ensure that we are familiar with the same sort of problems that our users face. The happy medium here might be run Fedora 7 in a virtual machine and have that available when we want to test a feature/service for that OS, but ensure that domain 0 is run by RHEL/CentOS. Just my 2 cents. :) On 6/9/07, Jesse Keating wrote: > > On Saturday 09 June 2007 02:48:05 jose manimala wrote: > > Would'nt it be a good idea to make respins of the fedora core 7 for > > internal use. Like For app servers we can have a permanent set of > > features and for test servers we can have another. there will be too > > many respins but it will make it easier later on in the future when we > > can just upgrade a respin to newer versions. That way we can avoid > > RHEL as such and run Fedora on all systems. I dont know but i seem to > > prefer Fedora over RHEL. There might still be some packages that are > > proprietary.... that will be the only problem faced is it not..... > > just a suggestion > > > > Respins aren't really that useful in this context. We can easily choose > what > we want to install, and we can easily apply the updates either during or > after install. A respin won't help us in these manners. What we don't > like > about Fedora is there is not really any attempt to keep a non abi changing > platform, the updates are fast and loose, and the distribution releases > get > flushed quickly. > > Fedora is great for short term or developmental servers, whereas > RHEL/CentOS > is far more suited for long term production environments. > > -- > Jesse Keating > Release Engineer: Fedora > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > > -- --Freddie -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Sat Jun 9 19:47:39 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 09 Jun 2007 14:47:39 -0500 Subject: Fedora 7 Upgrade In-Reply-To: References: <466826A3.10905@redhat.com> <20070608005229.GA3218@tomservo.rochester.rr.com> <53a863600706082348i518a9550n74f245b9f018b536@mail.gmail.com> <200706090846.11747.jkeating@redhat.com> Message-ID: <466B03DB.3040107@redhat.com> Freddie Rosario wrote: > I agree with Jesse. We should keep to a more stable platform with fewer > updates for production servers. As far as eating our own dog food. I > think > this is also necessary in order to ensure that we are familiar with > the same > sort of problems that our users face. The happy medium here might be run > Fedora 7 in a virtual machine and have that available when we want to > test a > feature/service for that OS, but ensure that domain 0 is run by > RHEL/CentOS. > Just my 2 cents. :) > we really can't blanket say "RHEL" "CentOS" or "Fedora". We have to take each task off of its own merit. Though, in general, for most of our Web Apps, RHEL does a great job (for now) though I suspect in a year and a half we'll have a lot more Fedora as RHEL gets longer in the tooth :) -Mike From jkeating at redhat.com Sat Jun 9 19:47:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 15:47:43 -0400 Subject: Fedora 7 Upgrade In-Reply-To: <466B03DB.3040107@redhat.com> References: <466826A3.10905@redhat.com> <466B03DB.3040107@redhat.com> Message-ID: <200706091547.43954.jkeating@redhat.com> On Saturday 09 June 2007 15:47:39 Mike McGrath wrote: > we really can't blanket say "RHEL" "CentOS" or "Fedora". ?We have to > take each task off of its own merit. ?Though, in general, for most of > our Web Apps, RHEL does a great job (for now) ?though I suspect in a > year and a half we'll have a lot more Fedora as RHEL gets longer in the > tooth :) +1 -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 10 00:31:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 20:31:38 -0400 Subject: smolt and bug reports In-Reply-To: <200706091221.22130.jkeating@redhat.com> References: <46699E33.20301@fedoraproject.org> <466AB361.4020600@kanarip.com> <200706091221.22130.jkeating@redhat.com> Message-ID: <200706092031.38485.jkeating@redhat.com> On Saturday 09 June 2007 12:21:16 Jesse Keating wrote: > Any user with a valid Fedora account (regardless of group) can open tickets > in Trac. ?Just like any user with a valid bugzilla account can open bugs. > Hopefully at some point it'll be very easy to get a Fedora account for > stuff, or be able to use an existing OpenID for stuff. ?However the > alternative of letting any random internet user or bot spam wikis or > tickets is not good. I should note that this is just the default. Admins for projects can adjust the rights of users (authed or not) via the Admin panel. New projects (and the projects I had already created) get set to non anon content generation. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Sun Jun 10 03:08:52 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 Jun 2007 08:38:52 +0530 Subject: Web based interface for custom spins Message-ID: <466B6B44.8000203@fedoraproject.org> Hi Is anyone looking into writing a web interface that can do custom spins using pungi and livecd-tools in the background? Revisor is useful as a graphical wrapper but it requires Fedora to be installed already. Having a web interface would allow anyone to select the package groups and individual packages and get a ISO image for download. I posted to fedora-infrastructure list before but we need a web app before talking about deploying it. There is new effort launched in http://respins.org to provide a forum and encourage community respins or derivatives of Fedora and they have expressed a interest in this too. Rahul From sundaram at fedoraproject.org Sun Jun 10 03:13:50 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 Jun 2007 08:43:50 +0530 Subject: Web based interface for custom spins In-Reply-To: <466B6B44.8000203@fedoraproject.org> References: <466B6B44.8000203@fedoraproject.org> Message-ID: <466B6C6E.60205@fedoraproject.org> Rahul Sundaram wrote: > Hi > > > Is anyone looking into writing a web interface that can do custom spins > using pungi and livecd-tools in the background? Revisor is useful as a > graphical wrapper but it requires Fedora to be installed already. > > Having a web interface would allow anyone to select the package groups > and individual packages and get a ISO image for download. I posted to > fedora-infrastructure list before but we need a web app before talking > about deploying it. > > There is new effort launched in http://respins.org to provide a forum > and encourage community respins or derivatives of Fedora and they have > expressed a interest in this too. Ugh. Ignore this. Meant to post to fedora-devel. Rahul From justin.randell at gmail.com Mon Jun 11 11:28:25 2007 From: justin.randell at gmail.com (justin randell) Date: Mon, 11 Jun 2007 21:28:25 +1000 Subject: speeding up moinmoin page save operations for fp.o wiki Message-ID: <34a99ab40706110428g6c206213ge66882e72c9fcd73@mail.gmail.com> hi all, i'm looking for some feedback on speeding up moinmoin after chatting with ThomasWaldmann in #moin about speeding up page save operations: (08:36:48 PM) idioteque123: i've come to this from the point of view of ending up with a package for http://fedoraproject.org/wiki (08:37:42 PM) ThomasWaldmann: idioteque123: how to proceed depends on what you want and when (08:38:31 PM) idioteque123: there aren't any well defined goals for this in #fedora-admin just yet (08:38:58 PM) ThomasWaldmann: if you want something soon, I would suggest you work with 1.6. if you have more time, you could wait until storage api stuff gets usable. (08:39:40 PM) idioteque123: ok, well how about i start a page somewhere in the moinmoin development wiki? (08:39:44 PM) ThomasWaldmann: btw, the jabber branch introduces some event framework (08:40:10 PM) idioteque123: then get some feedback from the fedora-admin people about 1.6 vs 1.7 (08:40:21 PM) ThomasWaldmann: idioteque123: yeah, good plan. or look if there is already something, we discussed that somewhere before (maybe on wiki, maybe on irc). so, do people think i should work in the 1.6 code or the 1.7 code? i note that there is already some work in the 1.7 branch for fedora (http://fedoraproject.org/wiki/SummerOfCode/2007/VillePekkaVainio), but i'm guessing we might want some results sooner than that? also, i should create a page in the fedora wiki to track this? i'll be around in for the next infrastructure meeting to get more feedback. cheers justin From mmcgrath at redhat.com Mon Jun 11 13:22:33 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 11 Jun 2007 08:22:33 -0500 Subject: speeding up moinmoin page save operations for fp.o wiki In-Reply-To: <34a99ab40706110428g6c206213ge66882e72c9fcd73@mail.gmail.com> References: <34a99ab40706110428g6c206213ge66882e72c9fcd73@mail.gmail.com> Message-ID: <466D4C99.2020704@redhat.com> justin randell wrote: > so, do people think i should work in the 1.6 code or the 1.7 code? i > note that there is already some work in the 1.7 branch for fedora > (http://fedoraproject.org/wiki/SummerOfCode/2007/VillePekkaVainio), > but i'm guessing we might want some results sooner than that? > I wonder why they're working on the 1.7 branch already since 1.5.8 is the newest version. I'd say work on the 1.6 code. When is 1.7 set to be made available? > also, i should create a page in the fedora wiki to track this? > I wouldn't think we need a whole page for it. We basically have 2 primary needs as I seem the. 1) Faster page save times 2) Making it highly available We had a 3rd but fcgid seems to have masked that problem pretty well. We're still keeping an eye on it but so far things are looking good. -Mike From vpivaini at cs.helsinki.fi Mon Jun 11 13:52:01 2007 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Mon, 11 Jun 2007 16:52:01 +0300 Subject: speeding up moinmoin page save operations for fp.o wiki In-Reply-To: <466D4C99.2020704@redhat.com> References: <34a99ab40706110428g6c206213ge66882e72c9fcd73@mail.gmail.com> <466D4C99.2020704@redhat.com> Message-ID: <200706111652.08819.vpivaini@cs.helsinki.fi> Mike McGrath kirjoitti viestiss??n (l?hetysaika Monday, 11. June 2007 16:22:33): > justin randell wrote: > > so, do people think i should work in the 1.6 code or the 1.7 code? i > > note that there is already some work in the 1.7 branch for fedora > > (http://fedoraproject.org/wiki/SummerOfCode/2007/VillePekkaVainio), > > but i'm guessing we might want some results sooner than that? > > I wonder why they're working on the 1.7 branch already since 1.5.8 is > the newest version. I'd say work on the 1.6 code. When is 1.7 set to > be made available? The main reason is that 1.6 is already stabilizing, Moin won't accept a lot of new changes anymore. So if I did my work on 1.6, it would probably never go into mainline (unless ported to 1.7) and Fedora would have to run a branch of the code. 1.7 is also the version that the Moin GSoC students are working on. There was a discussion about this on the list last week, see https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg00078.html According to what I've heard, 1.7 would be available "this year", nothing more specific. -- Ville-Pekka Vainio vpivaini at cs.helsinki.fi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From damian.myerscough at gmail.com Mon Jun 11 14:27:15 2007 From: damian.myerscough at gmail.com (Damian Myerscough) Date: Mon, 11 Jun 2007 15:27:15 +0100 Subject: Servers - security Message-ID: <466D5BC3.2070300@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey all, I was looking performing some security patch update via RHN, anyways I noticed that four of our servers don't have any iptables implemented these include: lockbox app[4,5] cvs-int db1 I am not sure why lockbox doesn't have iptables implemented as it is the machine that contains all security logs and should be one of our most protected boxes. I reckon this should be an issue discussed at our next meeting. I also looked at the proxy[1,2] servers and the iptables implemented (could be tided up) also app[1,2,3] had some basic that could be re-written. anyways I thought this should be brought to everyones attention. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGbVvDHYsIksCfKkwRAmOfAKCRbtOl0XwTMpZPrnQxLpYM9S9+nACfUiPC LmLs/sWWvuzShWljzWmnIuE= =lvW2 -----END PGP SIGNATURE----- From jkeating at redhat.com Tue Jun 12 01:12:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 Jun 2007 21:12:19 -0400 Subject: Koji outage Message-ID: <200706112112.19602.jkeating@redhat.com> httpd on koji.fp.o got OOM killed a few minutes ago. I've stopped httpd to recover memory and started it back up again. Things seem ok now, somebody should investigate further. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From flatfender at gmail.com Tue Jun 12 02:04:36 2007 From: flatfender at gmail.com (Flatfender) Date: Mon, 11 Jun 2007 22:04:36 -0400 Subject: cacti public In-Reply-To: <463F4E8D.40204@redhat.com> References: <463E732D.104@redhat.com> <2b26c4260705070902j7e816a4apf6b56989016d17c6@mail.gmail.com> <463F4E8D.40204@redhat.com> Message-ID: Mike, Raritan may still be willing to offer up our Command Center NOC product. We will be releasing a free version soon. You can already get a node limited version for free. http://www.commandcenter-noc.com http://www.raritan.com Matt Pusateri Systems Admin Raritan On 5/7/07, Mike McGrath wrote: > Wilmer Jaramillo M. wrote: > > > > Why in instead cacti should used http://www.zenoss.com/ ? > > AFAIK, zenoss isn't in Fedora yet. > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From mmcgrath at redhat.com Tue Jun 12 03:32:47 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 11 Jun 2007 22:32:47 -0500 Subject: Koji outage In-Reply-To: <200706112112.19602.jkeating@redhat.com> References: <200706112112.19602.jkeating@redhat.com> Message-ID: <466E13DF.4000103@redhat.com> Jesse Keating wrote: > httpd on koji.fp.o got OOM killed a few minutes ago. I've stopped httpd to > recover memory and started it back up again. Things seem ok now, somebody > should investigate further. > Does it just need more ram or did something gobble it all up? -Mike From mmcgrath at redhat.com Tue Jun 12 03:33:53 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 11 Jun 2007 22:33:53 -0500 Subject: cacti public In-Reply-To: References: <463E732D.104@redhat.com> <2b26c4260705070902j7e816a4apf6b56989016d17c6@mail.gmail.com> <463F4E8D.40204@redhat.com> Message-ID: <466E1421.8040805@redhat.com> Flatfender wrote: > Mike, > > Raritan may still be willing to offer up our Command Center NOC > product. We will be releasing a free version soon. You can already > get a node limited version for free. > > http://www.commandcenter-noc.com http://www.raritan.com Thanks for the offer, we really appreciate it but we're a 100% FLOSS shop. Do you happen to offer a GPL version :) ? -Mike From flatfender at gmail.com Tue Jun 12 03:39:10 2007 From: flatfender at gmail.com (Flatfender) Date: Mon, 11 Jun 2007 23:39:10 -0400 Subject: cacti public In-Reply-To: <466E1421.8040805@redhat.com> References: <463E732D.104@redhat.com> <2b26c4260705070902j7e816a4apf6b56989016d17c6@mail.gmail.com> <463F4E8D.40204@redhat.com> <466E1421.8040805@redhat.com> Message-ID: There's no GPL version yet, but one may be in the works. I still don't really understand the difference if we donate an appliance versus someone else donating a switch or load balancer, etc. I'll keep you posted if we the decision goes through for a GPL release. Matt On 6/11/07, Mike McGrath wrote: > Flatfender wrote: > > Mike, > > > > Raritan may still be willing to offer up our Command Center NOC > > product. We will be releasing a free version soon. You can already > > get a node limited version for free. > > > > http://www.commandcenter-noc.com http://www.raritan.com > > Thanks for the offer, we really appreciate it but we're a 100% FLOSS > shop. Do you happen to offer a GPL version :) ? > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From mmcgrath at redhat.com Tue Jun 12 03:45:14 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 11 Jun 2007 22:45:14 -0500 Subject: cacti public In-Reply-To: References: <463E732D.104@redhat.com> <2b26c4260705070902j7e816a4apf6b56989016d17c6@mail.gmail.com> <463F4E8D.40204@redhat.com> <466E1421.8040805@redhat.com> Message-ID: <466E16CA.5070403@redhat.com> Flatfender wrote: > There's no GPL version yet, but one may be in the works. I still > don't really understand the difference if we donate an appliance > versus someone else donating a switch or load balancer, etc. > > I'll keep you posted if we the decision goes through for a GPL release. Its mostly just viability. I'm not aware of any great open source switches. And as far as load balancing goes much of it is done with mod_proxy_balancer these days and is included with apache. Seriously though, we do appreciate the offer. -Mike From flatfender at gmail.com Tue Jun 12 03:53:57 2007 From: flatfender at gmail.com (Flatfender) Date: Mon, 11 Jun 2007 23:53:57 -0400 Subject: cacti public In-Reply-To: <466E16CA.5070403@redhat.com> References: <463E732D.104@redhat.com> <2b26c4260705070902j7e816a4apf6b56989016d17c6@mail.gmail.com> <463F4E8D.40204@redhat.com> <466E1421.8040805@redhat.com> <466E16CA.5070403@redhat.com> Message-ID: On 6/11/07, Mike McGrath wrote: > Flatfender wrote: > > There's no GPL version yet, but one may be in the works. I still > > don't really understand the difference if we donate an appliance > > versus someone else donating a switch or load balancer, etc. > > > > I'll keep you posted if we the decision goes through for a GPL release. > > Its mostly just viability. I'm not aware of any great open source > switches. And as far as load balancing goes much of it is done with > mod_proxy_balancer these days and is included with apache. Seriously > though, we do appreciate the offer. > > -Mike OK, viability point is valid and taken. Switch/Load balancer might have been a poorer argument. But to me an appliance in my mind is a distinguishing factor over just offering a software solution. It would be more equivalent to saying you'd have to give up your Netapp disk space. Isn't that just a big disk appliance that's donated? I won't belabor the argument any more :) Matt From jkeating at redhat.com Tue Jun 12 11:15:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 12 Jun 2007 07:15:34 -0400 Subject: Koji outage In-Reply-To: <466E13DF.4000103@redhat.com> References: <200706112112.19602.jkeating@redhat.com> <466E13DF.4000103@redhat.com> Message-ID: <200706120715.37694.jkeating@redhat.com> On Monday 11 June 2007 23:32:47 Mike McGrath wrote: > Does it just need more ram or did something gobble it all up? I honestly don't know. http was chewing up all the ram when I looked, but I don't know if it was getting over worked or if one of the processes just DoSed the box. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From frosario777 at gmail.com Wed Jun 13 03:00:39 2007 From: frosario777 at gmail.com (Freddie Rosario) Date: Tue, 12 Jun 2007 20:00:39 -0700 Subject: Koji outage In-Reply-To: <200706120715.37694.jkeating@redhat.com> References: <200706112112.19602.jkeating@redhat.com> <466E13DF.4000103@redhat.com> <200706120715.37694.jkeating@redhat.com> Message-ID: Just a thought but maybe there is a memory leak somewhere? Jesse are you able to duplicate the error? On 6/12/07, Jesse Keating wrote: > > On Monday 11 June 2007 23:32:47 Mike McGrath wrote: > > Does it just need more ram or did something gobble it all up? > > I honestly don't know. http was chewing up all the ram when I looked, but > I > don't know if it was getting over worked or if one of the processes just > DoSed the box. > > -- > Jesse Keating > Release Engineer: Fedora > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > > -- --Freddie -------------- next part -------------- An HTML attachment was scrubbed... URL: From kwade at redhat.com Wed Jun 13 03:10:14 2007 From: kwade at redhat.com (Karsten Wade) Date: Tue, 12 Jun 2007 20:10:14 -0700 Subject: escalation paths and methods In-Reply-To: <46648467.9000701@fedoraproject.org> References: <46647FBA.1000206@fedoraproject.org> <4664829F.3060004@redhat.com> <46648467.9000701@fedoraproject.org> Message-ID: <1181704214.3469.780.camel@erato.phig.org> On Mon, 2007-06-04 at 23:30 +0200, Marek Mahut wrote: > In fact, and maybe with pages or cell numbers (for sms only, of course) > too. Maybe we can enable an alias (of sorts) for sysadmin paging. For example, kwade-page (at) fedoraproject.org would send to an SMS page number that I can specify in FAS. The reason is to let us set strict and harsh spamassassin rules behind those aliases. Or perhaps an SMS is not passed through the alias channel unless it is sent from an email address that is on record for a FAS account holder. Or perhaps it is an even smaller list of people who can use that SMS, a specific set of From: email addresses and SMS numbers. Personally, I want to know when infrastructure I have a stake in is having problems, but I don't want to be nagged by nagios. So, these are definitely escalation paths that need a human involved, probably one who has seen/heard of the problem and is sure it is real. Similarly, when I detect a problem that really needs intervention, I want a way to know that someone with a key and an interest knows about it. That for me was the most frustrating part of the F7 launch, when the first few days passed and problems arose, I was never sure it had anyone's attention and so stuff languished that had an easy resolution. Even volunteers have good reason to want an early and useful page. Arriving Just In Time is not only good for one's hero profile, it also helps keep five minute solutions from being three hour problems. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mmcgrath at redhat.com Wed Jun 13 04:01:38 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 12 Jun 2007 23:01:38 -0500 Subject: escalation paths and methods In-Reply-To: <1181704214.3469.780.camel@erato.phig.org> References: <46647FBA.1000206@fedoraproject.org> <4664829F.3060004@redhat.com> <46648467.9000701@fedoraproject.org> <1181704214.3469.780.camel@erato.phig.org> Message-ID: <466F6C22.9030302@redhat.com> Karsten Wade wrote: > On Mon, 2007-06-04 at 23:30 +0200, Marek Mahut wrote: > > >> In fact, and maybe with pages or cell numbers (for sms only, of course) >> too. >> > > Maybe we can enable an alias (of sorts) for sysadmin paging. For > example, kwade-page (at) fedoraproject.org would send to an SMS page > number that I can specify in FAS. > > The reason is to let us set strict and harsh spamassassin rules behind > those aliases. Or perhaps an SMS is not passed through the alias > channel unless it is sent from an email address that is on record for a > FAS account holder. Or perhaps it is an even smaller list of people who > can use that SMS, a specific set of From: email addresses and SMS > numbers. > > Personally, I want to know when infrastructure I have a stake in is > having problems, but I don't want to be nagged by nagios. So, these are > definitely escalation paths that need a human involved, probably one who > has seen/heard of the problem and is sure it is real. Similarly, when I > detect a problem that really needs intervention, I want a way to know > that someone with a key and an interest knows about it. That for me was > the most frustrating part of the F7 launch, when the first few days > passed and problems arose, I was never sure it had anyone's attention > and so stuff languished that had an easy resolution. > > Even volunteers have good reason to want an early and useful page. > Arriving Just In Time is not only good for one's hero profile, it also > helps keep five minute solutions from being three hour problems. > > I'll add whoever wants to be added. We can also work a formal tree now if need be. Don't make me regret this :-/ https://admin.fedoraproject.org/pager -Mike From paulo.banon at googlemail.com Wed Jun 13 04:06:13 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Wed, 13 Jun 2007 06:06:13 +0200 Subject: escalation paths and methods In-Reply-To: <466F6C22.9030302@redhat.com> References: <46647FBA.1000206@fedoraproject.org> <4664829F.3060004@redhat.com> <46648467.9000701@fedoraproject.org> <1181704214.3469.780.camel@erato.phig.org> <466F6C22.9030302@redhat.com> Message-ID: <7a41c4bc0706122106l74f38a68sd6243f85b59c06b@mail.gmail.com> i think it would be wise to get Auth there... Or you will be wake up by lots of spammers :/ Paulo On 6/13/07, Mike McGrath wrote: > > Karsten Wade wrote: > > On Mon, 2007-06-04 at 23:30 +0200, Marek Mahut wrote: > > > > > >> In fact, and maybe with pages or cell numbers (for sms only, of course) > >> too. > >> > > > > Maybe we can enable an alias (of sorts) for sysadmin paging. For > > example, kwade-page (at) fedoraproject.org would send to an SMS page > > number that I can specify in FAS. > > > > The reason is to let us set strict and harsh spamassassin rules behind > > those aliases. Or perhaps an SMS is not passed through the alias > > channel unless it is sent from an email address that is on record for a > > FAS account holder. Or perhaps it is an even smaller list of people who > > can use that SMS, a specific set of From: email addresses and SMS > > numbers. > > > > Personally, I want to know when infrastructure I have a stake in is > > having problems, but I don't want to be nagged by nagios. So, these are > > definitely escalation paths that need a human involved, probably one who > > has seen/heard of the problem and is sure it is real. Similarly, when I > > detect a problem that really needs intervention, I want a way to know > > that someone with a key and an interest knows about it. That for me was > > the most frustrating part of the F7 launch, when the first few days > > passed and problems arose, I was never sure it had anyone's attention > > and so stuff languished that had an easy resolution. > > > > Even volunteers have good reason to want an early and useful page. > > Arriving Just In Time is not only good for one's hero profile, it also > > helps keep five minute solutions from being three hour problems. > > > > > I'll add whoever wants to be added. We can also work a formal tree now > if need be. > > Don't make me regret this :-/ > > https://admin.fedoraproject.org/pager > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgalgoci at redhat.com Wed Jun 13 04:07:22 2007 From: mgalgoci at redhat.com (Matthew Galgoci) Date: Wed, 13 Jun 2007 00:07:22 -0400 Subject: escalation paths and methods In-Reply-To: <1181704214.3469.780.camel@erato.phig.org> References: <46647FBA.1000206@fedoraproject.org> <4664829F.3060004@redhat.com> <46648467.9000701@fedoraproject.org> <1181704214.3469.780.camel@erato.phig.org> Message-ID: > Personally, I want to know when infrastructure I have a stake in is > having problems, but I don't want to be nagged by nagios. Then read about it expo-facto like the rest of the world. -- Matthew Galgoci GIS Production Operations Red Hat, Inc 919.754.3700 x44155 From mmcgrath at redhat.com Wed Jun 13 04:12:26 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 12 Jun 2007 23:12:26 -0500 Subject: escalation paths and methods In-Reply-To: <7a41c4bc0706122106l74f38a68sd6243f85b59c06b@mail.gmail.com> References: <46647FBA.1000206@fedoraproject.org> <4664829F.3060004@redhat.com> <46648467.9000701@fedoraproject.org> <1181704214.3469.780.camel@erato.phig.org> <466F6C22.9030302@redhat.com> <7a41c4bc0706122106l74f38a68sd6243f85b59c06b@mail.gmail.com> Message-ID: <466F6EAA.1080507@redhat.com> Paulo Santos wrote: > i think it would be wise to get Auth there... > Or you will be wake up by lots of spammers :/ I'm not sure I want to add auth unless I have to because the auth system is something thats known to have issue in the past. I do want to add a time based buffer though, 1 page / minute or so. -Mike From mmcgrath at redhat.com Wed Jun 13 04:35:53 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 12 Jun 2007 23:35:53 -0500 Subject: escalation paths and methods In-Reply-To: <466F6EAA.1080507@redhat.com> References: <46647FBA.1000206@fedoraproject.org> <4664829F.3060004@redhat.com> <46648467.9000701@fedoraproject.org> <1181704214.3469.780.camel@erato.phig.org> <466F6C22.9030302@redhat.com> <7a41c4bc0706122106l74f38a68sd6243f85b59c06b@mail.gmail.com> <466F6EAA.1080507@redhat.com> Message-ID: <466F7429.1020902@redhat.com> Mike McGrath wrote: > Paulo Santos wrote: >> i think it would be wise to get Auth there... >> Or you will be wake up by lots of spammers :/ > > I'm not sure I want to add auth unless I have to because the auth > system is something thats known to have issue in the past. I do want > to add a time based buffer though, 1 page / minute or so. K, that parts added now at least :) limit one page every 2 minutes. -Mike From josemanimala at gmail.com Wed Jun 13 07:00:08 2007 From: josemanimala at gmail.com (jose manimala) Date: Wed, 13 Jun 2007 12:30:08 +0530 Subject: infrastructure approval Message-ID: <53a863600706130000s7b806b82hceb6e341677143f9@mail.gmail.com> hello, i have applied for a role in the infrastructure team. The FAS has not been approved so far. is there anything else that needs to be done... please let me know thanks -- Jose M Manimala S6 Computer science and engineering Rajagiri School Of Engineering And Technology Ph: +919846367850 http://www.jmm-blog.co.nr GPGkeyID: 98FF52D2 From bugs.michael at gmx.net Wed Jun 13 09:29:32 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 13 Jun 2007 11:29:32 +0200 Subject: 1st anniversary Message-ID: <20070613112932.a7b05c70.bugs.michael@gmx.net> Are there any infrastructure volunteers who want to fix (or get rid of) broken stuff on http://cvs.fedora.redhat.com/ that is in a desolate state for many months or more than a year, respectively? http://cvs.fedora.redhat.com/bonsai/toplevel.cgi?treeid=extras (unusable for over a year) - https://bugzilla.redhat.com/188365 http://cvs.fedora.redhat.com/webfiles/ (out-of-date since 16-Nov-2006) http://cvs.fedora.redhat.com/lxr/extras/source (out-of-date since 16-Nov-2006) From mmcgrath at redhat.com Wed Jun 13 13:27:33 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 13 Jun 2007 08:27:33 -0500 Subject: 1st anniversary In-Reply-To: <20070613112932.a7b05c70.bugs.michael@gmx.net> References: <20070613112932.a7b05c70.bugs.michael@gmx.net> Message-ID: <466FF0C5.70705@redhat.com> Michael Schwendt wrote: > Are there any infrastructure volunteers who want to fix (or get rid of) > broken stuff on http://cvs.fedora.redhat.com/ that is in a desolate > state for many months or more than a year, respectively? > Should I just redirect / to /viewcvs/ ? -Mike From mmahut at fedoraproject.org Wed Jun 13 13:29:25 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Wed, 13 Jun 2007 15:29:25 +0200 Subject: escalation paths and methods In-Reply-To: <466F6C22.9030302@redhat.com> References: <46647FBA.1000206@fedoraproject.org> <4664829F.3060004@redhat.com> <46648467.9000701@fedoraproject.org> <1181704214.3469.780.camel@erato.phig.org> <466F6C22.9030302@redhat.com> Message-ID: <466FF135.5070906@fedoraproject.org> Hey Mike, Mike McGrath wrote: > Karsten Wade wrote: >> On Mon, 2007-06-04 at 23:30 +0200, Marek Mahut wrote: >> >> >>> In fact, and maybe with pages or cell numbers (for sms only, of >>> course) too. >> >> Maybe we can enable an alias (of sorts) for sysadmin paging. For >> example, kwade-page (at) fedoraproject.org would send to an SMS page >> number that I can specify in FAS. >> >> The reason is to let us set strict and harsh spamassassin rules behind >> those aliases. Or perhaps an SMS is not passed through the alias >> channel unless it is sent from an email address that is on record for a >> FAS account holder. Or perhaps it is an even smaller list of people who >> can use that SMS, a specific set of From: email addresses and SMS >> numbers. >> >> Personally, I want to know when infrastructure I have a stake in is >> having problems, but I don't want to be nagged by nagios. So, these are >> definitely escalation paths that need a human involved, probably one who >> has seen/heard of the problem and is sure it is real. Similarly, when I >> detect a problem that really needs intervention, I want a way to know >> that someone with a key and an interest knows about it. That for me was >> the most frustrating part of the F7 launch, when the first few days >> passed and problems arose, I was never sure it had anyone's attention >> and so stuff languished that had an easy resolution. >> >> Even volunteers have good reason to want an early and useful page. >> Arriving Just In Time is not only good for one's hero profile, it also >> helps keep five minute solutions from being three hour problems. >> >> > I'll add whoever wants to be added. We can also work a formal tree now > if need be. > > Don't make me regret this :-/ It's also a good idea to mention your time zone. > https://admin.fedoraproject.org/pager -- Marek Mahut Tel.: +420-532-294-111 (ex. 826-2046) Fedora Ambassador GSM: +420-731-076-674 http://www.fedoraproject.org http://www.jamendo.com ____________________________________________________________________ From jkeating at redhat.com Wed Jun 13 13:36:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Jun 2007 09:36:27 -0400 Subject: Koji outage In-Reply-To: References: <200706112112.19602.jkeating@redhat.com> <200706120715.37694.jkeating@redhat.com> Message-ID: <200706130936.27993.jkeating@redhat.com> On Tuesday 12 June 2007 23:00:39 Freddie Rosario wrote: > Just a thought but maybe there is a memory leak somewhere? Jesse are you > able to duplicate the error? If by reproduce you mean wait for it to happen again, that's what I'm doing (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Wed Jun 13 13:41:51 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 13 Jun 2007 09:41:51 -0400 Subject: 1st anniversary In-Reply-To: <466FF0C5.70705@redhat.com> References: <20070613112932.a7b05c70.bugs.michael@gmx.net> <466FF0C5.70705@redhat.com> Message-ID: <1181742111.3989.3.camel@aglarond.local> On Wed, 2007-06-13 at 08:27 -0500, Mike McGrath wrote: > Michael Schwendt wrote: > > Are there any infrastructure volunteers who want to fix (or get rid of) > > broken stuff on http://cvs.fedora.redhat.com/ that is in a desolate > > state for many months or more than a year, respectively? > > Should I just redirect / to /viewcvs/ ? The problem is that loses the (very helpful) links of how to check things out, etc. The right thing is to probably create a page on the wiki with the (correct) information and redirect to there. Jeremy From sopwith at gmail.com Wed Jun 13 15:32:57 2007 From: sopwith at gmail.com (Elliot Lee) Date: Wed, 13 Jun 2007 11:32:57 -0400 Subject: 1st anniversary In-Reply-To: <20070613112932.a7b05c70.bugs.michael@gmx.net> References: <20070613112932.a7b05c70.bugs.michael@gmx.net> Message-ID: On 6/13/07, Michael Schwendt wrote: > Are there any infrastructure volunteers who want to fix (or get rid of) > broken stuff on http://cvs.fedora.redhat.com/ that is in a desolate > state for many months or more than a year, respectively? > > http://cvs.fedora.redhat.com/bonsai/toplevel.cgi?treeid=extras > (unusable for over a year) - https://bugzilla.redhat.com/188365 > > http://cvs.fedora.redhat.com/webfiles/ > (out-of-date since 16-Nov-2006) > > http://cvs.fedora.redhat.com/lxr/extras/source > (out-of-date since 16-Nov-2006) The Fedora Directory Server team was the one that originally wanted the Bonsai & LXR services available, with an eye towards adding Tinderbox into the mix as well. I suspect that it would help to connect with them and find out what their current needs are. /webfiles was there for a small minority of people who were having problems checking out from CVS. Anyone who used about it would have complained by now... Best, -- Elliot From fedora at leemhuis.info Wed Jun 13 15:51:36 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Jun 2007 17:51:36 +0200 Subject: 1st anniversary In-Reply-To: References: <20070613112932.a7b05c70.bugs.michael@gmx.net> Message-ID: <46701288.8020300@leemhuis.info> On 13.06.2007 17:32, Elliot Lee wrote: > On 6/13/07, Michael Schwendt wrote: > >> http://cvs.fedora.redhat.com/webfiles/ >> (out-of-date since 16-Nov-2006) >> > [...] > /webfiles was there for a small minority of people who were having > problems checking out from CVS. Anyone who used about it would have > complained by now... I'm one of those that complained (but not very loudly) I often used the CVS snapshots in the past to just get a full devel checkout when I needed one (which is not that often). That was a lot of quicker then a full CVS checkout with CVS and is likely less load for all systems involved (especially the server). So count me as one of those that would welcome daily checkouts. CU thl From mmcgrath at redhat.com Wed Jun 13 16:16:00 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 13 Jun 2007 11:16:00 -0500 Subject: 1st anniversary In-Reply-To: <46701288.8020300@leemhuis.info> References: <20070613112932.a7b05c70.bugs.michael@gmx.net> <46701288.8020300@leemhuis.info> Message-ID: <46701840.7090109@redhat.com> Thorsten Leemhuis wrote: > On 13.06.2007 17:32, Elliot Lee wrote: > >> On 6/13/07, Michael Schwendt wrote: >> >> >>> http://cvs.fedora.redhat.com/webfiles/ >>> (out-of-date since 16-Nov-2006) >>> >>> >> [...] >> /webfiles was there for a small minority of people who were having >> problems checking out from CVS. Anyone who used about it would have >> complained by now... >> > > I'm one of those that complained (but not very loudly) > > I often used the CVS snapshots in the past to just get a full devel > checkout when I needed one (which is not that often). That was a lot of > quicker then a full CVS checkout with CVS and is likely less load for > all systems involved (especially the server). > > So count me as one of those that would welcome daily checkouts. > > http://cvs.fedora.redhat.com/webfiles/ -Mike From fedora at leemhuis.info Wed Jun 13 16:26:45 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Jun 2007 18:26:45 +0200 Subject: 1st anniversary In-Reply-To: <46701840.7090109@redhat.com> References: <20070613112932.a7b05c70.bugs.michael@gmx.net> <46701288.8020300@leemhuis.info> <46701840.7090109@redhat.com> Message-ID: <46701AC5.1060003@leemhuis.info> On 13.06.2007 18:16, Mike McGrath wrote: > Thorsten Leemhuis wrote: >> On 13.06.2007 17:32, Elliot Lee wrote: >>> On 6/13/07, Michael Schwendt wrote: >>>> http://cvs.fedora.redhat.com/webfiles/ >>>> (out-of-date since 16-Nov-2006) >>>> >>>> >>> [...] >>> /webfiles was there for a small minority of people who were having >>> problems checking out from CVS. Anyone who used about it would have >>> complained by now... >>> >> I'm one of those that complained (but not very loudly) >> >> I often used the CVS snapshots in the past to just get a full devel >> checkout when I needed one (which is not that often). That was a lot of >> quicker then a full CVS checkout with CVS and is likely less load for >> all systems involved (especially the server). >> >> So count me as one of those that would welcome daily checkouts. >> >> > http://cvs.fedora.redhat.com/webfiles/ Please read the quoted text again; especially the line 5 and 6: >>>> http://cvs.fedora.redhat.com/webfiles/ >>>> (out-of-date since 16-Nov-2006) ;-) Cu thl From fedora at leemhuis.info Wed Jun 13 16:35:50 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Jun 2007 18:35:50 +0200 Subject: 1st anniversary In-Reply-To: <46701AC5.1060003@leemhuis.info> References: <20070613112932.a7b05c70.bugs.michael@gmx.net> <46701288.8020300@leemhuis.info> <46701840.7090109@redhat.com> <46701AC5.1060003@leemhuis.info> Message-ID: <46701CE6.3040809@leemhuis.info> On 13.06.2007 18:26, Thorsten Leemhuis wrote: > On 13.06.2007 18:16, Mike McGrath wrote: >> Thorsten Leemhuis wrote: >>> On 13.06.2007 17:32, Elliot Lee wrote: >>>> On 6/13/07, Michael Schwendt wrote: >>>>> http://cvs.fedora.redhat.com/webfiles/ >>>>> (out-of-date since 16-Nov-2006) >>>>> >>>>> >>>> [...] >>>> /webfiles was there for a small minority of people who were having >>>> problems checking out from CVS. Anyone who used about it would have >>>> complained by now... >>>> >>> I'm one of those that complained (but not very loudly) >>> >>> I often used the CVS snapshots in the past to just get a full devel >>> checkout when I needed one (which is not that often). That was a lot of >>> quicker then a full CVS checkout with CVS and is likely less load for >>> all systems involved (especially the server). >>> >>> So count me as one of those that would welcome daily checkouts. >>> >>> >> http://cvs.fedora.redhat.com/webfiles/ > > Please read the quoted text again; especially the line 5 and 6: > >>>>> http://cvs.fedora.redhat.com/webfiles/ >>>>> (out-of-date since 16-Nov-2006) > > ;-) He; Mike fixed it after my mail -- but my proxy still showed the old stuff when I looked at it before sending above mail. Mike, thx for fixing and all your work in general. CU thl From josemm at fedoraproject.org Thu Jun 14 04:04:13 2007 From: josemm at fedoraproject.org (jose manimala) Date: Thu, 14 Jun 2007 09:34:13 +0530 Subject: From addresses in Live Mail. Message-ID: <53a863600706132104g3d39f08av5190a14f525c957c@mail.gmail.com> the new version of hotmail(live mail) seems to support from addresses. shouldn't it be checked for compatibility with fedora emailaliases? -- Jose M Manimala S6 Computer science and engineering Rajagiri School Of Engineering And Technology Ph: +919846367850 http://www.jmm-blog.co.nr GPGkeyID: 98FF52D2 From mmcgrath at redhat.com Thu Jun 14 14:24:36 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 14 Jun 2007 09:24:36 -0500 Subject: From addresses in Live Mail. In-Reply-To: <53a863600706132104g3d39f08av5190a14f525c957c@mail.gmail.com> References: <53a863600706132104g3d39f08av5190a14f525c957c@mail.gmail.com> Message-ID: <46714FA4.4020407@redhat.com> jose manimala wrote: > the new version of hotmail(live mail) seems to support from addresses. > shouldn't it be checked for compatibility with fedora emailaliases? > Sorry, I don't follow what you are suggesting? -Mike From jeff at ocjtech.us Thu Jun 14 21:02:54 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Thu, 14 Jun 2007 16:02:54 -0500 Subject: IRC Log for Fedora Infrastructure Meeting (2007-06-14) Message-ID: <1181854974.3879.29.camel@lt21223.campus.dmacc.edu> [15:06] mmcgrath has set the subject to fedora-infrastructure meeting -- Who's here? [15:06] xDamox: Me [15:06] mmcgrath: PING ALL: who's here? [15:06] G: I'm here [15:06] mbonnet: yo [15:06] cemc has joined the group chat (n=gimre at voy.narancs.net) [15:06] G: I'm gonna have to disappear in 15-20 [15:06] jcollie: howdy! [15:06] f13: I'm here. [15:06] mmcgrath: abadger1999: you around? [15:06] abadger1999: Yep. [15:06] mmcgrath: allrighty then [15:07] * lmacken ! [15:07] * wolfy grabs a viewing seat [15:07] mmcgrath has set the subject to abadger1999 - Package Database ------------- [15:07] mmcgrath: abadger1999: whats the word? [15:07] abadger1999: We have progress [15:07] abadger1999: Script to import pkgs is written and I'm finding all sorts of problem with owners.list. [15:08] mmcgrath: thats good at least [15:08] mmcgrath: how bad is it? [15:08] abadger1999: Mostly lack of EPEL owner information for EPEL branches [15:08] lmacken: abadger1999: is there an owners API yet? If not, want some help? [15:08] abadger1999: lmacken: I'm using nottings owners.py. [15:09] lmacken: abadger1999: ah, where does that code live ? [15:09] lmacken: maybe i can stuff that into bodhi in the mean time [15:09] abadger1999: Since the pkgdb will get rid of owners.list I'm not too worried about an API. [15:09] G: abadger1999: in that case dgilmore would be the person to poke I think [15:09] glezos has joined the group chat (n=glezos at fedora/glezos) [15:09] lmacken: well, bodhi needs to know who owns what [15:09] abadger1999: cvs-int:/cvs/extras/CVSROOT/admin/owners.py [15:09] lmacken: thanks [15:09] mmcgrath: abadger1999: if you do get together a comprehensive list of stuff missing from EPEL send it my way. [15:09] abadger1999: I have a few changes to what's checked in that I'll have to add later. [15:10] abadger1999: Will do. [15:10] abadger1999: warren is going to work on koji syncing. [15:10] tibbs has left ("Konversation terminated!" (n=tibbs at fedora/tibbs)) [15:10] abadger1999: I'm going to do bugzilla sync and cvs acls sync this week. [15:10] abadger1999: G (Nigel Jones) has started looking at the code and made some changes to the way it looks. [15:11] mmcgrath: cool [15:11] G: (Minor to start with, just getting to grips with Turbogears and how it works) [15:11] abadger1999: So we're on track for next week or the week after. [15:11] mmcgrath: abadger1999: anything else? [15:11] abadger1999: That's about it. [15:11] mmcgrath: abadger1999: the package db only contacts the database, correct? Does it need any write access to a file system like koji or cvs? [15:12] MrBawb has joined the group chat (i=abob at guppy.drown.org) [15:12] abadger1999: i think cvs acls can pull from the packagedb for now instead of pkgdb pushing to cvs-int. [15:12] abadger1999: koji I'm not sure about. warren's looking into it. [15:13] mmcgrath: cool. [15:13] mmcgrath: pull is better than push for security reasons. [15:13] mmcgrath: same reason bodhi is deployed on app5 instead of in our cluster. [15:13] warren: you rather koji pull from packagedb? [15:13] mbonnet: that's not really possible [15:13] mbonnet: unless we have a cronjob that does the sync periodically [15:13] mmcgrath: warren: if its filesystem stuff, yes. if its db stuff then no. [15:14] warren: abadger1999, it is all db right? [15:14] abadger1999: mbonnet: How do you currently sync owners.list? [15:14] warren: abadger1999, see /cvs/pkgs/CVSROOT/admin/owners-sync.py [15:14] mbonnet: I believe the script is run by hand right now [15:14] f13: yes, by hand [15:15] * dgilmore is here [15:15] f13: when we make changes to owners.list we run the sync script [15:15] f13: less than ideal, but functional [15:15] mmcgrath: [15:15] abadger1999: Hmm... Is it just pushing into koji's db? [15:15] dgilmore: abadger1999: EPEL owner information is in owners.epel.list [15:16] abadger1999: if so it can be a cronjob or we can write a callback that pushes the information from the package db to koji when it's updated. [15:16] rdieter has left (Remote closed the connection (n=rdieter at sting.unl.edu)) [15:17] mmcgrath: abadger1999: we can figure it out. We should move on for the meeting though. [15:17] f13: abadger1999: it uses the koji API to do ownership adds/changes. [15:17] f13: doesn't talk to the db directly [15:17] abadger1999: f13: Sounds like it won't be a problem then. [15:17] abadger1999: mmcgrath: And won't need to write to any filesystems. [15:17] mmcgrath: abadger1999: excellent [15:17] mmcgrath: k, moving on [15:18] mmcgrath has set the subject to Config Management - mmcgrath [15:18] mmcgrath: nothing majorly new here. I'm going through and making sure our xen dom0's are setup properly. [15:18] mmcgrath: I've also started forcing some packages to uninstall and some services not to start (cups, gpm, etc) [15:18] mmcgrath has set the subject to VCS - jcollie [15:18] mmcgrath: jcollie: ping? [15:18] jcollie: yo [15:19] mmcgrath: jcollie: Are you still playing with VCS solutions? [15:19] jcollie: i think that the discussion last week on -devel and -infra was good [15:19] f13: abadger1999: it needs to be made smarter, like knowing about different owners for different tags and all that, but that's just details (: [15:19] jcollie: i just need to sit down and write up a more concrete proposal [15:19] mmcgrath: jcollie: me too, its gotten more interest this time around then 6 mo. ago or so [15:20] mmcgrath: jcollie: solid, make sure to get some good input from the jeremy's and jesse's in the world [15:20] mmcgrath: k, moving next [15:20] jcollie: i think it'll be a mix... there'll be a repository that looks a lot like we have now, but with some meta-language or -tags to pull patches out of a "exploded tree" repo [15:20] * mdomsch joins belatedly [15:20] mmcgrath has set the subject to Firewall System Rewrite - lmacken skvidal [15:20] mmcgrath: mdomsch: yo [15:21] mmcgrath: jcollie: excellent, thanks for getting that stuff together. [15:21] mmcgrath: lmacken: ping [15:21] mmcgrath: skvidal: ping? [15:21] lmacken: no updates on this from my end.. have we decided to abandon pyroman ? [15:21] mmcgrath: lmacken: Not sure, I know xDamox has some opinions on it. [15:21] mmcgrath: xDamox: ping? [15:21] xDamox: yo [15:21] mmcgrath: you had some items to discuss regarding the Firewall System? [15:21] skvidal: mmcgrath: I think we should just go with simple iptables files in /etc/sysconfig [15:21] xDamox: Yea, I updated the template we were using and neaten it up a little [15:21] mbonnet: question: does our firewall system have some kind of NAT/conntrack limit? [15:22] mmcgrath: skvidal: I agree, what about boxes that have different firewall needs though? [15:22] xDamox: I can help 100% with the iptables writing. [15:22] skvidal: mmcgrath: that's what puppet is for [15:22] lmacken: taking the strict & simple rule approach sounds good to me [15:22] mbonnet: I'm wondering exceeding that limit might be the cause of the intermittent connection drops people see connecting to koji.fp.o [15:22] skvidal: mmcgrath: distribute files out based on host [15:22] fchiulli has joined the group chat (i=824c4010 at gateway/web/cgi-irc/ircatwork.com/x-04ce31ce5397d4ea) [15:22] mmcgrath: mbonnet: Both the host based and hardware firewalls can do it but only the proxy servers actually do do it now. [15:22] mmcgrath: skvidal: ahh, yes. A puppet template would work well for that I think. [15:23] mmcgrath: mbonnet: I'll verify that we're not rate limiting in any way on the hardware firewall. [15:23] xDamox: mmcgrath, do we have an up to date list of services running on each box [15:23] xDamox: and their ports? [15:23] mmcgrath: xDamox: we're pretty close. [15:23] mmcgrath: skvidal: do you have a link to the iptables rules you'd suggested on the list? [15:24] skvidal: yes [15:24] skvidal: uno momento [15:24] skvidal: http://linux.duke.edu/~skvidal/misc/iptables-template [15:24] xDamox: Ok. If you could give me a copy, I could do a sample firewall for some boxes maybe and have skvidal and lmacken check it over? [15:24] lmacken: xDamox: sounds good to me [15:24] xDamox: that good with you too skvidal ? [15:24] skvidal: xDamox: fine - I already have those on a couple of the boxes due to the release [15:25] skvidal: iirc they're on proxy1 and 2 [15:25] mmcgrath: xDamox: remember KISS [15:25] xDamox: Ok, yep [15:25] xDamox: Ill make it a simple as possible [15:25] G: Have fun with the rest of meeting, I'm out [15:25] mmcgrath: G: later, thanks for coming [15:26] xDamox: also I am sure skvidal and lmacken will be able to simplify it more [15:26] mmcgrath: xDamox: cool, take what skvidal has at http://linux.duke.edu/~skvidal/misc/iptables-template and give it a good lookover. [15:26] mmcgrath: I'll create an erb (puppet template) out of it and see how it goes. [15:26] xDamox: yep will do [15:27] dgilmore: mbonnet: i dont know what on our firewalls as far as that goes [15:27] dgilmore: mbonnet: we dont control the nat part of it [15:28] mmcgrath: k, xDamox when you're done send'er to the list and we can get this all underway. [15:28] mmcgrath has set the subject to Server Upgrades - mmcgrath [15:28] xDamox: OK mmcgrath, [15:28] mmcgrath: So I'm trying to get some additional RAM in some of our servers. [15:28] mmcgrath: but we have more pressing issues.. .namely a lot of our newer boxes don't have warrantys. [15:29] mmcgrath: so I'm trying to figure out where money should come from to pay for that. [15:29] mmcgrath: additionally we have a lot of boxes that are reaching the end of their natural life and should be replaced. [15:29] mmcgrath: Fortunately if we stick with high capacity devices, this will allow us to use our rack more efficiently. [15:29] mmcgrath: The major limiting factor being cost, heat and power. [15:29] mmcgrath: just letting everyone know whats going on there. [15:30] mmcgrath has set the subject to Xen Conversion - mmcgrath [15:30] mmcgrath: So I've started doing some work with iscsi [15:30] dgilmore: [15:30] mmcgrath: It's actually going quite well. [15:30] * mmcgrath digs up a bonnie run [15:30] warren: what will serve iscsi? [15:30] mmcgrath: warren: the netapp already is. [15:31] mmcgrath: grr pastebin [15:31] dgilmore: mbonnet: how much storage do we have? how much did you use for iscsi? [15:31] dgilmore: mmcgrath: http://paste.ausil.us [15:32] dgilmore: mmcgrath: ^^^^^^^^^^^^^^ meant you not mbonnet [15:32] mmcgrath: dgilmore: already on it [15:32] mmcgrath: ok, here's an iscsi run on publictest9 [15:32] mmcgrath: http://paste.ausil.us/161 [15:32] mmcgrath: dgilmore: right now 500G [15:32] mmcgrath: all in all I've been quite pleased with it. [15:33] mmcgrath: I've kickstarted a few boxes with iscsi, the package install portion (about 400 packages) takes about 2 minutes. [15:33] londo: mmcgrath: random access seems slow to me [15:33] dgilmore: mmcgrath: live migration is easy to do? [15:33] mmcgrath: dgilmore: yep, so far its just worked for me. There's a brief network blip I need to work on. The box itself doesn't experience it that bad but I think there's some arp issues. [15:34] Karl_le_Rouge has joined the group chat (n=RedKarl at ALyon-257-1-149-122.w81-251.abo.wanadoo.fr) [15:35] dgilmore: awesome [15:35] mmcgrath: londo: I've seen random seek as high as 705.2. [15:35] mmcgrath: The larger the test was on iscsi the slower that got though, always a good excuse to tweak and test though [15:36] mmcgrath: All in all I think iscsi will work very well for us. We just need to watch carefully network utilization and overall netapp utilization. [15:36] londo: mmcgrath: numbers from tiobench will be nice if you can get them [15:36] mmcgrath: londo: is it in extras? [15:36] londo: mmcgrath: yeap [15:36] mmcgrath: londo: cool, I'll run it then. [15:36] mmcgrath: k, moving on [15:37] mmcgrath has set the subject to Bacula [15:37] mmcgrath: So I've been testing out bacula on xen6 and publictest[3-4] [15:37] mmcgrath: everything's been working great. [15:37] f13: hurray! [15:37] dgilmore: mmcgrath: how much total disk do we need to backup? [15:37] mmcgrath: We're just blocking on https://bugzilla.redhat.com/230344 [15:37] f13: a scary amount [15:37] f13: (if you count /mnt/koji) [15:38] mmcgrath: dgilmore: wellllll, depends, do you con't /mnt/koji or not? [15:38] dgilmore: welll we really should backup /mnt/koji [15:38] f13: mmcgrath: btw, did the new disk shelf show up in phx? [15:38] mmcgrath: dgilmore: the plan right now is to do a backup of everything on xen6's local storage which is 378G. I'm working on getting a tape backup for everything though (including koji) [15:38] * dgilmore needs a cloning machine [15:39] mmcgrath: f13: I've not heard one way or the other but I was under the impression that it should be there by now. I'll send an emil. [15:39] dgilmore: mmcgrath: ok [15:39] mmcgrath: dgilmore: I've got the tape drive as a priority2 thing after our warranty issue with the soc. [15:39] mmcgrath: all in all though, ixs says he'll have more time in the comming days for us to do a formal review. [15:40] dgilmore: mmcgrath: yeah we would probably want LT)2 or 3 with at least 10 slots [15:40] mmcgrath: For those that haven't used it Bacula is really slick. [15:40] skvidal: is it wicked slick? [15:40] londo: if you are going to move things on netapp/iscsi is it possible to do the backup there (if a tape drive is available) [15:40] mmcgrath: super wicked slick. [15:40] abadger1999: skvidal: wykd [15:40] dgilmore: i need to find time to get it reviewed [15:40] mmcgrath: londo: thats the problem, we had 3 netapps to deal with now we have 1 super netapp and I'm not comfortable with backing up to itself. [15:41] mmcgrath: londo: sorry, I missed your (if tape drive) comment. [15:41] dgilmore: mmcgrath: i agree [15:41] f13: I loved bacula when I was using it. [15:41] mmcgrath: k, moving on [15:41] mmcgrath has set the subject to Translators stuff - [15:42] f13: seriously hot stuff [15:42] mmcgrath: glezos: has been working on this. Its now at http://publictest4.fedora.redhat.com/ [15:42] mmcgrath: this will be a very big deal when we start moving stuff to it. [15:42] RedKarl has left (Connection timed out (n=RedKarl at ALyon-257-1-39-129.w90-14.abo.wanadoo.fr)) [15:42] JSchmitt has left ("Konversation terminated!" (n=s4504kr at fedora/JSchmitt)) [15:42] mmcgrath: so all keep your eyes out for it and help out because all parties involved can use it. [15:42] mmcgrath has set the subject to account system - [15:42] mmcgrath: Nothing new here. If anyone is interested in working on it with me that would be good. [15:43] mmcgrath has set the subject to Project Hosted - f13 [15:43] mmcgrath: f13: ? [15:43] f13: nothing new. Trac git plugin sucks. [15:44] mmcgrath: [15:44] f13: Oh, I created a script to create trac projects, but havne't put it in scm any where or documented it [15:44] abadger1999: f13: Could you give me access to the hosted box? [15:44] f13: sure. [15:44] abadger1999: Thanks. [15:44] f13: at some point it should be FAS'd but... [15:44] mmcgrath: [15:45] mmcgrath: next [15:45] mmcgrath has set the subject to FedoraPeople.org - skvidal [15:45] mmcgrath: skvidal: anything new? [15:45] skvidal: nothing [15:45] warren: Is that planned for shell and web? [15:45] skvidal: yes [15:45] dgilmore: mmcgrath: just thought of something ill switch off plague on June 29 for FC-5 [15:46] dgilmore: skvidal: anyidea when you will get to rebuild the box? [15:46] skvidal: dgilmore: not this week and probably not beginning of next since I'll be in orientation, etc [15:46] mmcgrath: dgilmore: [15:47] skvidal: but I'll be working again come next week [15:47] skvidal: so it's a start [15:47] skvidal: and I should be able to spend the time [15:47] mmcgrath: cool [15:48] mmcgrath has set the subject to Ibiblio Mirror - On hold [15:48] mmcgrath: The ibiblio mirror is on hold for probably about a week while we hook don up with direct I2 access to our mirror in RDU. [15:48] mdomsch: mmcgrath, pick set up the static route already [15:48] mmcgrath: mdomsch: hmm, I'll have to check with don, he was under the impression he needed to wait a bit. [15:49] mmcgrath: Ok, thats all I've got. [15:49] mmcgrath has set the subject to Open Floor ---------------- [15:49] lmacken: word [15:49] lmacken: I was wondering what you guys thought about having some sort of development environment for our webapps. [15:49] lmacken: So, there are a handfull of people that are interested in hacking on bodhi, but due it's dependencies on koji and mash, it's extremely difficult to develop it anywhere other than PHX. I've currently been doing all of my development on publictest2, which has been working out great. [15:49] lmacken: So a possibility for this is to have some Xen guest with a read-only mount of /mnt/koji and blocked out from the rest of PHX. [15:49] mdomsch: lmacken, +1; /me misses publictest7 [15:50] lmacken: yeah, and honestly.. i have no idea how to start hacking on mirrormanager, smolt, etc [15:50] lmacken: i think if we opened the doors a bit, our infrastructure could improve vastly [15:50] lmacken: mdomsch: feel free to hack on publictest2 for now [15:50] mmcgrath: lmacken: the main limiting facter on that is RAM, but we can set something up. [15:51] lmacken: mmcgrath: cool [15:51] mmcgrath: lmacken: we should probably setup more shared xen instances. [15:51] abadger1999: lmacken: +1 [15:51] dgilmore: im going to start work on enabling secondary archs if anyone wants to help feel fee to talk to me [15:52] dgilmore: mmcgrath: can we possibly get another vlan? [15:52] jcollie: mmcgrath, could i get a xen guest for testing the git/vcs stuff? [15:52] lmacken: mmcgrath: cool.. so what is the next action to getting this ready? creating a group for infrahackers and granting access on a restricted guest ? [15:52] dgilmore: mmcgrath: so we can seperate the some guestd for this kind of thing [15:52] mmcgrath: lmacken: well I'll need to find where we have RAM avaiable for the instances. Its item "Server Upgrades" on the wiki. [15:52] mmcgrath: dgilmore: we should. [15:53] wolfy has left ("When you are down and out something always turns up-and it is usually the noses of your friends." (n=lonewolf at fedora/wolfy)) [15:53] lmacken: mmcgrath: ok.. well, publictest2 has been my playground for the past few months.. any reason not to just start using that ? [15:53] mmcgrath: jcollie: I think we can setup something, it'll be a bit [15:53] mmcgrath: lmacken: not sure, I think it only has 512M ram right? [15:53] lmacken: mmcgrath: i'm not sure [15:54] dgilmore: mmcgrath: im pretty sure thats all it ahs [15:54] dgilmore: has [15:54] lmacken: mmcgrath: also, i noticed that you setup the security guest.. does bressers know about it yet ? [15:54] mmcgrath: k, I'll try to find ways to consolidate some of our lesser machines into a bigger, sort of super machine. [15:54] lmacken: mmcgrath: cool [15:54] mmcgrath: lmacken: I think dgilmore did that [15:55] lmacken: ah [15:55] lmacken: dgilmore: is the security guest ready to go ? [15:56] dgilmore: lmacken: not yet [15:56] lmacken: dgilmore: k, just checking [15:56] dgilmore: i need to add the security group to get shell access [15:58] mmcgrath: solid [15:58] mmcgrath: so anyone have anything else? If not I'll close the meeting in 30 seconds? [15:58] mmcgrath: 10 [15:59] mmcgrath has set the subject to Meeting End ----------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ssrat at ticon.net Fri Jun 15 02:46:17 2007 From: ssrat at ticon.net (David Douthitt) Date: Thu, 14 Jun 2007 21:46:17 -0500 Subject: Web Server Bug Message-ID: <4671FD79.30802@ticon.net> I'm just getting started in this, but.... I submitted my GPG key, got an account, signed the CLA, etc. Then I went to change my user details (for group membership) and put "Infrastructure" into the box on the bottom (above the dropbox that defaults to "user") and the python code blew up. I saved a copy of the web page complete (I used the Camino web browser to save it) as well as taking a JPEG picture of the web browser window with the error completely displayed within. The URL was https://admin.fedoraproject.org/accounts/userbox.cgi (error at line #307). I would have attached these files here, but being this is a mailing list.... where should I send these files? One other thing - isn't the error itself a security error? I mean, it gives me Python code, line numbers, procedure names, Python version and location, and more. Consider: The error was a type error, that is: *TypeError*: iteration over non-sequence. The error was in get_allowed_group_actions in /srv/web/accounts/website.py on line #435: my_group_info.update(ginfo) -- UNIX System Administrator Linux+, SCSA, RHCE, LPIC-1 HP-UX, Linux, Solaris, FreeBSD Books: "Advanced System Administration" and "GNU Screen: A Comprehensive Introduction" http://www.lulu.com/ssrat From mmcgrath at redhat.com Fri Jun 15 02:49:38 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 14 Jun 2007 21:49:38 -0500 Subject: Web Server Bug In-Reply-To: <4671FD79.30802@ticon.net> References: <4671FD79.30802@ticon.net> Message-ID: <4671FE42.1040500@redhat.com> David Douthitt wrote: > I'm just getting started in this, but.... > > I submitted my GPG key, got an account, signed the CLA, etc. Then I > went to change my user details (for group membership) and put > "Infrastructure" into the box on the bottom (above the dropbox that > defaults to "user") and the python code blew up. > > I saved a copy of the web page complete (I used the Camino web browser > to save it) as well as taking a JPEG picture of the web browser window > with the error completely displayed within. > > The URL was https://admin.fedoraproject.org/accounts/userbox.cgi (error > at line #307). > > I would have attached these files here, but being this is a mailing > list.... where should I send these files? > You can send attachments to this list, or just mail them to admin at fedoraproject.org -Mike From ricky at fedoraproject.org Fri Jun 15 02:59:55 2007 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 14 Jun 2007 22:59:55 -0400 Subject: Web Server Bug In-Reply-To: <4671FD79.30802@ticon.net> References: <4671FD79.30802@ticon.net> Message-ID: <467200AB.6040209@fedoraproject.org> David Douthitt wrote: > I submitted my GPG key, got an account, signed the CLA, etc. Then I > went to change my user details (for group membership) and put > "Infrastructure" into the box on the bottom (above the dropbox that > defaults to "user") and the python code blew up. As far as I can tell, this is the response when the group doesn't exist (looks like it's case sensitive- you probably wanted "infrastructure"). > One other thing - isn't the error itself a security error? I mean, it > gives me Python code, line numbers, procedure names, Python version and > location, and more. I don't think just showing code/non-sensitive debugging information is a huge security problem. Consider that the code for the accounts system is publicly viewable in CVS anyway (hooray for openness): http://cvs.fedoraproject.org/viewcvs/fedora-accounts/?root=fedora. As a side note, I think the accounts system is being rewritten so hopefully, such errors will be treated more gracefully in the future. Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From ssrat at ticon.net Fri Jun 15 03:00:53 2007 From: ssrat at ticon.net (David Douthitt) Date: Thu, 14 Jun 2007 22:00:53 -0500 Subject: Web Server Bug In-Reply-To: <4671FE42.1040500@redhat.com> References: <4671FD79.30802@ticon.net> <4671FE42.1040500@redhat.com> Message-ID: <467200E5.5030602@ticon.net> Mike McGrath wrote: > You can send attachments to this list, or just mail them to > admin at fedoraproject.org Here are the files I mentioned previously: compressed and archived. The archive contains: the complete web page (with error as generated), and the JPEG picture file of the same. -- UNIX System Administrator Linux+, SCSA, RHCE, LPIC-1 HP-UX, Linux, Solaris, FreeBSD Books: "Advanced System Administration" and "GNU Screen: A Comprehensive Introduction" http://www.lulu.com/ssrat -------------- next part -------------- A non-text attachment was scrubbed... Name: WebBug1.zip Type: application/zip Size: 194436 bytes Desc: not available URL: From josemm at fedoraproject.org Fri Jun 15 03:20:17 2007 From: josemm at fedoraproject.org (jose manimala) Date: Fri, 15 Jun 2007 08:50:17 +0530 Subject: From addresses in Live Mail. In-Reply-To: <46714FA4.4020407@redhat.com> References: <53a863600706132104g3d39f08av5190a14f525c957c@mail.gmail.com> <46714FA4.4020407@redhat.com> Message-ID: <53a863600706142020p1719d5dcv724689a17d33041a@mail.gmail.com> i'll upload a picture of what i am suggesting!! that will make more sense.... check it out i hope this will help make things clear... Jose M Manimala -------------- next part -------------- A non-text attachment was scrubbed... Name: img.doc Type: application/msword Size: 119296 bytes Desc: not available URL: From kwade at redhat.com Fri Jun 15 04:51:42 2007 From: kwade at redhat.com (Karsten Wade) Date: Thu, 14 Jun 2007 21:51:42 -0700 Subject: speeding up moinmoin page save operations for fp.o wiki In-Reply-To: <200706111652.08819.vpivaini@cs.helsinki.fi> References: <34a99ab40706110428g6c206213ge66882e72c9fcd73@mail.gmail.com> <466D4C99.2020704@redhat.com> <200706111652.08819.vpivaini@cs.helsinki.fi> Message-ID: <1181883102.3469.970.camel@erato.phig.org> On Mon, 2007-06-11 at 16:52 +0300, Ville-Pekka Vainio wrote: > According to what I've heard, 1.7 would be available "this year", nothing more > specific. We may be running an alpha of 1.7 for a while, if we want to use this work in production before then. I think that's fine, since there isn't any real risk to the content on the site, right? - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lmacken at redhat.com Fri Jun 15 06:15:57 2007 From: lmacken at redhat.com (Luke Macken) Date: Fri, 15 Jun 2007 02:15:57 -0400 Subject: TurboGears EL-5 Message-ID: <20070615061557.GC14190@tomservo.rochester.rr.com> The TurboGears stack is ready for RHEL5! Installable via `yum install TurboGears` from the EL-5 repo[0]. luke [0]: http://download.fedoraproject.org/pub/epel/5/ From oliver at linux-kernel.at Fri Jun 15 06:55:26 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 15 Jun 2007 08:55:26 +0200 Subject: Firewall (WAS: IRC Log for Fedora Infrastructure Meeting (2007-06-14)) In-Reply-To: <1181854974.3879.29.camel@lt21223.campus.dmacc.edu> References: <1181854974.3879.29.camel@lt21223.campus.dmacc.edu> Message-ID: <467237DE.7000109@linux-kernel.at> On 06/14/2007 11:02 PM, Jeffrey C. Ollie wrote: > [15:24] skvidal: uno momento > [15:24] skvidal: http://linux.duke.edu/~skvidal/misc/iptables-template Regarding this rules... Better would be to set default input policy to DROP, if you don't do any logging at the end; Or do logging :-) You should also add a rule for *auth* tcp/113. never drop that, accept it or reject it! Else any auth check will need to run into a timeout... For host-based firewalls this is not needed, but if you have hosts behind this host (eg. host acting as a gateway), you should also add rules like this for traceroute: -A INPUT -m state --state NEW -p udp -m udp --dport 33434:33524 -j ACCEPT -of From josemm at fedoraproject.org Fri Jun 15 08:11:19 2007 From: josemm at fedoraproject.org (jose manimala) Date: Fri, 15 Jun 2007 13:41:19 +0530 Subject: Emailaliases - hotmail needs updating Message-ID: <53a863600706150111i2451658dlfc3467ee5c2f3a46@mail.gmail.com> ok i am sorry about the previous mistake i made. Here is an updated email with proper images. Hotmail now allows From address and reply-to address options. the emailaliases needs to be updated. -- Jose M Manimala S6 Computer science and engineering Rajagiri School Of Engineering And Technology Ph: +919846367850 http://www.jmm-blog.co.nr GPGkeyID: 98FF52D2 -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.jpg Type: image/jpeg Size: 69647 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2.jpg Type: image/jpeg Size: 64643 bytes Desc: not available URL: From cristian at paslaru.com Fri Jun 15 10:03:37 2007 From: cristian at paslaru.com (Cristian Paslaru) Date: Fri, 15 Jun 2007 13:03:37 +0300 Subject: Emailaliases - hotmail needs updating In-Reply-To: <53a863600706150111i2451658dlfc3467ee5c2f3a46@mail.gmail.com> References: <53a863600706150111i2451658dlfc3467ee5c2f3a46@mail.gmail.com> Message-ID: <9dca7cec0706150303s3fd13e40r8deb582e96a0ae04@mail.gmail.com> It is up to you to do so in your email client / webmail interface. Not everyone on this mailing list is using as email client / webmail the Hotmail, which BTW, it is run by M$ :) On 6/15/07, jose manimala wrote: > ok i am sorry about the previous mistake i made. Here is an updated > email with proper images. Hotmail now allows From address and reply-to > address options. the emailaliases needs to be updated. > > -- > Jose M Manimala > S6 Computer science and engineering > Rajagiri School Of Engineering And Technology > Ph: +919846367850 > http://www.jmm-blog.co.nr > GPGkeyID: 98FF52D2 > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > > From josemm at fedoraproject.org Fri Jun 15 10:10:46 2007 From: josemm at fedoraproject.org (jose manimala) Date: Fri, 15 Jun 2007 15:40:46 +0530 Subject: Emailaliases - hotmail needs updating In-Reply-To: <9dca7cec0706150303s3fd13e40r8deb582e96a0ae04@mail.gmail.com> References: <53a863600706150111i2451658dlfc3467ee5c2f3a46@mail.gmail.com> <9dca7cec0706150303s3fd13e40r8deb582e96a0ae04@mail.gmail.com> Message-ID: <53a863600706150310j3ed44d99mf4b2a200c270da54@mail.gmail.com> Thats not the point..... I know it is run by M$ and i dont approve of any MS based content because i am a very ardent fan of FOSS and FLOSS. It was listed on the page emailaliases so i was wondering if it should be updated. Thats why i sent this mail to the list.... regards jose From webmaster at margo.bijoux.nom.br Fri Jun 15 10:24:45 2007 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Fri, 15 Jun 2007 07:24:45 -0300 Subject: Emailaliases - hotmail needs updating In-Reply-To: <9dca7cec0706150303s3fd13e40r8deb582e96a0ae04@mail.gmail.com> References: <53a863600706150111i2451658dlfc3467ee5c2f3a46@mail.gmail.com> <9dca7cec0706150303s3fd13e40r8deb582e96a0ae04@mail.gmail.com> Message-ID: <467268ED.1080009@margo.bijoux.nom.br> As far as I know, this setup doesn't require any modification on the MTA of the domain you're faking. However, if you decide to use that "feature", be warned that your e-mail may have an increased probability as being considered spam or being rejected. This can happen if the faked domain has a SPF record and the receiving domain uses SPF either as a mean to detect faked e-mails or as part of an antispam filter. -- Pedro Macedo Cristian Paslaru wrote: > It is up to you to do so in your email client / webmail interface. > Not everyone on this mailing list is using as email client / webmail > the Hotmail, which BTW, it is run by M$ :) > From Axel.Thimm at ATrpms.net Fri Jun 15 10:25:05 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 15 Jun 2007 12:25:05 +0200 Subject: Upgrade metrics Message-ID: <20070615102505.GB9813@neu.nirvana> Hi, is it possible to create some relative metrics of release upgrades, e.g. FC5 -> FC6, FC5 -> F7? The interesting part is to create a graph over time to answer the question whether the 13 month EOL is really paying off. And perhaps on base of that graph one could revise this decision. At the very leats it would be interesting to notice the upgrade behaviour of Fedora users. I have no idea how to do that other than marking the HTTP Agent of yum on F accordingly, as well as the HTTP Agent in anaconda's yum (noting fresh installs vs upgrades). Worth to add this for F8? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From frosario777 at gmail.com Fri Jun 15 12:35:46 2007 From: frosario777 at gmail.com (Freddie Rosario) Date: Fri, 15 Jun 2007 05:35:46 -0700 Subject: Upgrade metrics In-Reply-To: <20070615102505.GB9813@neu.nirvana> References: <20070615102505.GB9813@neu.nirvana> Message-ID: Axel, I believe that using data from smolt (http://smolt.fedoraproject.org/stats) and plugging that data into something like a round robin database( http://oss.oetiker.ch/rrdtool/) might be the solution you are looking for. On 6/15/07, Axel Thimm wrote: > > Hi, > > is it possible to create some relative metrics of release upgrades, > e.g. FC5 -> FC6, FC5 -> F7? > > The interesting part is to create a graph over time to answer the > question whether the 13 month EOL is really paying off. And perhaps on > base of that graph one could revise this decision. At the very leats > it would be interesting to notice the upgrade behaviour of Fedora > users. > > I have no idea how to do that other than marking the HTTP Agent of yum > on F accordingly, as well as the HTTP Agent in anaconda's yum > (noting fresh installs vs upgrades). Worth to add this for F8? > -- > Axel.Thimm at ATrpms.net > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > > -- --Freddie -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Fri Jun 15 13:23:06 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 15 Jun 2007 09:23:06 -0400 Subject: Upgrade metrics In-Reply-To: <20070615102505.GB9813@neu.nirvana> References: <20070615102505.GB9813@neu.nirvana> Message-ID: <20070615132306.GB6965@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > The interesting part is to create a graph over time to answer the > question whether the 13 month EOL is really paying off. And perhaps on > base of that graph one could revise this decision. At the very leats > it would be interesting to notice the upgrade behaviour of Fedora > users. > > I have no idea how to do that other than marking the HTTP Agent of yum > on F accordingly, as well as the HTTP Agent in anaconda's yum > (noting fresh installs vs upgrades). Worth to add this for F8? Well, you could have smolt update the release for a particular hw UUID, and track things that way. Bill From mmcgrath at redhat.com Fri Jun 15 13:47:34 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 15 Jun 2007 08:47:34 -0500 Subject: Emailaliases - hotmail needs updating In-Reply-To: <53a863600706150310j3ed44d99mf4b2a200c270da54@mail.gmail.com> References: <53a863600706150111i2451658dlfc3467ee5c2f3a46@mail.gmail.com> <9dca7cec0706150303s3fd13e40r8deb582e96a0ae04@mail.gmail.com> <53a863600706150310j3ed44d99mf4b2a200c270da54@mail.gmail.com> Message-ID: <46729876.6030609@redhat.com> jose manimala wrote: > Thats not the point..... I know it is run by M$ and i dont approve of > any MS based content because i am a very ardent fan of FOSS and FLOSS. > It was listed on the page emailaliases so i was wondering if it should > be updated. Thats why i sent this mail to the list.... > regards > jose > Got'cha. You're talking about: http://fedoraproject.org/wiki/EmailAliases It's a wiki so if you've got something to update/change. The general rule of thumb is change first ask questions later. -Mike From mmcgrath at redhat.com Fri Jun 15 13:54:53 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 15 Jun 2007 08:54:53 -0500 Subject: Upgrade metrics In-Reply-To: <20070615102505.GB9813@neu.nirvana> References: <20070615102505.GB9813@neu.nirvana> Message-ID: <46729A2D.1080307@redhat.com> Axel Thimm wrote: > Hi, > > is it possible to create some relative metrics of release upgrades, > e.g. FC5 -> FC6, FC5 -> F7? > > We didn't really start taking metrics until FC6. > The interesting part is to create a graph over time to answer the > question whether the 13 month EOL is really paying off. And perhaps on > base of that graph one could revise this decision. At the very leats > it would be interesting to notice the upgrade behaviour of Fedora > users. > > I have no idea how to do that other than marking the HTTP Agent of yum > on F accordingly, as well as the HTTP Agent in anaconda's yum > (noting fresh installs vs upgrades). Worth to add this for F8? > > So here's a graph of the smolt vs yum ip stuff: https://admin.fedoraproject.org/cacti/graph.php?action=view&rra_id=all&local_graph_id=253 The problem with the smolt numbers is that anyone doing kickstarts, installing via runlevel 3, yum upgrades or anaconda upgrades will never get prompted to enable smolt and there are privacy concerns just enabling it by default. So I think the only way we can do it is start to seed people now, get the word out about smolt, and start monitoring upgrades from F7 to F8 and so on. Adding a query string or changing the http agent on yum could also be useful. It did just dawn on me that I've stopped monitoring FC6 yum connections and perhaps I should re-enable it. The scary thing is I still regularly get requests regarding Fedora Core 1!! (we moved it from the primary mirror to http://archives.fedoraproject.org/fedora/linux/core/1/ and that brought some people out of the woodwork) I'm always open to suggestions for changes to smolt or our yum method. -Mike From nils at breun.nl Fri Jun 15 14:17:56 2007 From: nils at breun.nl (Nils Breunese) Date: Fri, 15 Jun 2007 16:17:56 +0200 Subject: Upgrade metrics In-Reply-To: <46729A2D.1080307@redhat.com> References: <20070615102505.GB9813@neu.nirvana> <46729A2D.1080307@redhat.com> Message-ID: Mike McGrath wrote: > It did just dawn on me that I've stopped monitoring FC6 yum > connections and perhaps I should re-enable it. The scary thing is > I still regularly get requests regarding Fedora Core 1!! (we moved > it from the primary mirror to http://archives.fedoraproject.org/ > fedora/linux/core/1/ and that brought some people out of the woodwork) I know lots of server providers are still having customers on FC1-4. Some people really don't seem to care about getting patches. I was asked to look at a server this week, but they didn't tell me exactly what it was running. So the first thing I do is 'ca /etc/redhat- release'. Yup, FC1... Nils Breunese. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Dit deel van het bericht is digitaal ondertekend URL: From blizzard at redhat.com Fri Jun 15 15:18:21 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Fri, 15 Jun 2007 11:18:21 -0400 Subject: Upgrade metrics In-Reply-To: <46729A2D.1080307@redhat.com> References: <20070615102505.GB9813@neu.nirvana> <46729A2D.1080307@redhat.com> Message-ID: <1181920701.2737.18.camel@localhost.localdomain> On Fri, 2007-06-15 at 08:54 -0500, Mike McGrath wrote: > > The problem with the smolt numbers is that anyone doing kickstarts, > installing via runlevel 3, yum upgrades or anaconda upgrades will > never > get prompted to enable smolt and there are privacy concerns just > enabling it by default. So I think the only way we can do it is > start > to seed people now, get the word out about smolt, and start > monitoring > upgrades from F7 to F8 and so on. > What happens in the case that the network stuff isn't up when smolt runs during startup? Did it end up being able to wait for the network and queue it for later? I'm a little surprised that the number of units that we have is as small as it is, and how few of them are laptops. Or maybe it's just that our support for laptops is so bad that no one is bothering anymore. :) Would be nice to move smolt out of just the firstboot and do some user surveys as well, but I guess we haven't speced that out and haven't had time to do the work to make that happen. --Chris From Axel.Thimm at ATrpms.net Fri Jun 15 15:25:36 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 15 Jun 2007 17:25:36 +0200 Subject: Upgrade metrics In-Reply-To: <46729A2D.1080307@redhat.com> References: <20070615102505.GB9813@neu.nirvana> <46729A2D.1080307@redhat.com> Message-ID: <20070615152536.GE9813@neu.nirvana> On Fri, Jun 15, 2007 at 08:54:53AM -0500, Mike McGrath wrote: > Axel Thimm wrote: > >Hi, > > > >is it possible to create some relative metrics of release upgrades, > >e.g. FC5 -> FC6, FC5 -> F7? > > > > > We didn't really start taking metrics until FC6. Yes, I know, I was just giving examples of where it would had been useful in today's context. Testing 13 month life span would probable be better done in the F8 release time, e.g. checking how many FC6 users really upgrade to F8 skipping one release (which is what the 13 month span was about). If we need FC6 to send out more info in some way (smolt, yum http agent etc) we should implant that early in both FC6 and F7, so we know in autumn what people are really doing (always in relative numbers, e.g. FC6->F8 upgrades in comparison to F7->F8 upgrades and F8 install from scratch) > >The interesting part is to create a graph over time to answer the > >question whether the 13 month EOL is really paying off. And perhaps on > >base of that graph one could revise this decision. At the very leats > >it would be interesting to notice the upgrade behaviour of Fedora > >users. > > > >I have no idea how to do that other than marking the HTTP Agent of yum > >on F accordingly, as well as the HTTP Agent in anaconda's yum > >(noting fresh installs vs upgrades). Worth to add this for F8? > > > > > So here's a graph of the smolt vs yum ip stuff: > > https://admin.fedoraproject.org/cacti/graph.php?action=view&rra_id=all&local_graph_id=253 Nice graph! This gives us an estimate of absolute numbers, but not yet upgrades vs bare metal installs. It nicely shows that smolt and yum data are coherent. > The problem with the smolt numbers is that anyone doing kickstarts, > installing via runlevel 3, yum upgrades or anaconda upgrades will never > get prompted to enable smolt and there are privacy concerns just > enabling it by default. That doesn't matter, we won't get everyone and there will be an unknown dark factor. But the numbers we get can be divided to remove that unknown constant, e.g. create relative numbers. For example: "In the first 4 weeks after the release of F8 and until EOL of FC6 we saw that: 70% did a bare metal install 20% upgraded from F7 9% upgraded from FC6 1% did something else (like upgrading from RHL9)" These are the numbers we would need to justify a 13 month EOL time including all efforts that go with it, or whether it wasn't worth it because say only 1% would make really use for FC6->F8 upgrades and we better invest that man time into something else. also if these numbers can be seen over time we can spot when the user do the bare metal installs and the upgrades. I would guess that after a release one would have a large bare-metal-install peak and some time after that the upgrades would slowly grow as well. > The scary thing is I still regularly get requests regarding Fedora > Core 1!! (we moved it from the primary mirror to > http://archives.fedoraproject.org/fedora/linux/core/1/ and that > brought some people out of the woodwork) Wow, that's really scary. FC1 should of course live forever in archives.fp.o for historical reason, but actually using it is really questionable :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Fri Jun 15 15:51:25 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 15 Jun 2007 10:51:25 -0500 Subject: Upgrade metrics In-Reply-To: <1181920701.2737.18.camel@localhost.localdomain> References: <20070615102505.GB9813@neu.nirvana> <46729A2D.1080307@redhat.com> <1181920701.2737.18.camel@localhost.localdomain> Message-ID: <4672B57D.8050509@redhat.com> Christopher Blizzard wrote: > On Fri, 2007-06-15 at 08:54 -0500, Mike McGrath wrote: > >> The problem with the smolt numbers is that anyone doing kickstarts, >> installing via runlevel 3, yum upgrades or anaconda upgrades will >> never >> get prompted to enable smolt and there are privacy concerns just >> enabling it by default. So I think the only way we can do it is >> start >> to seed people now, get the word out about smolt, and start >> monitoring >> upgrades from F7 to F8 and so on. >> >> > > What happens in the case that the network stuff isn't up when smolt runs > during startup? Did it end up being able to wait for the network and > queue it for later? I'm a little surprised that the number of units > that we have is as small as it is, and how few of them are laptops. Or > maybe it's just that our support for laptops is so bad that no one is > bothering anymore. :) > It keeps trying as best as it can until network comes up. If all that fails (say a reboot is required before network comes up) the monthly smolt checkin will start up and we'll get them a month after they install. The monthly checkin will also let us do queries on 'active' users say people that have submitted in the last 6 months or 12 months. > Would be nice to move smolt out of just the firstboot and do some user > surveys as well, but I guess we haven't speced that out and haven't had > time to do the work to make that happen. > Well we do have smoltGui available and we're working on adding a rating system for the entire profile as well as individual devices. The question is how to get people to run it. -Mike -Mike From paulo.banon at googlemail.com Fri Jun 15 16:29:49 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Fri, 15 Jun 2007 18:29:49 +0200 Subject: Upgrade metrics In-Reply-To: <4672B57D.8050509@redhat.com> References: <20070615102505.GB9813@neu.nirvana> <46729A2D.1080307@redhat.com> <1181920701.2737.18.camel@localhost.localdomain> <4672B57D.8050509@redhat.com> Message-ID: <7a41c4bc0706150929m9627460jfdba43bb8c97e300@mail.gmail.com> Wouldnt a small popup like the advise of new updates be usefull for smoltGui ? Something like: - "New survey is available" - you click in it, do the survey and send it with the profile, it would also be nice to have a checkbox to disable the announcements. Paulo On 6/15/07, Mike McGrath wrote: > > Christopher Blizzard wrote: > > On Fri, 2007-06-15 at 08:54 -0500, Mike McGrath wrote: > > > >> The problem with the smolt numbers is that anyone doing kickstarts, > >> installing via runlevel 3, yum upgrades or anaconda upgrades will > >> never > >> get prompted to enable smolt and there are privacy concerns just > >> enabling it by default. So I think the only way we can do it is > >> start > >> to seed people now, get the word out about smolt, and start > >> monitoring > >> upgrades from F7 to F8 and so on. > >> > >> > > > > What happens in the case that the network stuff isn't up when smolt runs > > during startup? Did it end up being able to wait for the network and > > queue it for later? I'm a little surprised that the number of units > > that we have is as small as it is, and how few of them are laptops. Or > > maybe it's just that our support for laptops is so bad that no one is > > bothering anymore. :) > > > It keeps trying as best as it can until network comes up. If all that > fails (say a reboot is required before network comes up) the monthly > smolt checkin will start up and we'll get them a month after they > install. The monthly checkin will also let us do queries on 'active' > users say people that have submitted in the last 6 months or 12 months. > > > Would be nice to move smolt out of just the firstboot and do some user > > surveys as well, but I guess we haven't speced that out and haven't had > > time to do the work to make that happen. > > > > Well we do have smoltGui available and we're working on adding a rating > system for the entire profile as well as individual devices. The > question is how to get people to run it. > > -Mike > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Fri Jun 15 17:36:24 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 15 Jun 2007 12:36:24 -0500 Subject: Script request Message-ID: <4672CE18.4030604@redhat.com> I've got a script request for anyone who's interested (I'm both busy and too lazy to write it myself) I'd like to count the number of 'updates-released-7' requests in our mirror logs that have happened in the last 24 hours. The script should take two files as input and return a single integer, using bash. Here's a sample log: http://mmcgrath.net/~mmcgrath/mirrors happy hacking -Mike From mmcgrath at redhat.com Fri Jun 15 17:40:21 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 15 Jun 2007 12:40:21 -0500 Subject: Upgrade metrics In-Reply-To: <20070615152536.GE9813@neu.nirvana> References: <20070615102505.GB9813@neu.nirvana> <46729A2D.1080307@redhat.com> <20070615152536.GE9813@neu.nirvana> Message-ID: <4672CF05.2020505@redhat.com> Axel Thimm wrote: >> So here's a graph of the smolt vs yum ip stuff: >> >> https://admin.fedoraproject.org/cacti/graph.php?action=view&rra_id=all&local_graph_id=253 >> > > Nice graph! This gives us an estimate of absolute numbers, but not yet > upgrades vs bare metal installs. It nicely shows that smolt and > yum data are coherent. > > How do you get this info again? I swear there was a place in lshal that used to say install source (network, cd) and install method (kickstart, upgrade) though I can't seem to find it now and I'm wondering if I made that up. -Mike From email.ahmedkamal at googlemail.com Fri Jun 15 17:47:58 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Fri, 15 Jun 2007 20:47:58 +0300 Subject: Script request In-Reply-To: <4672CE18.4030604@redhat.com> References: <4672CE18.4030604@redhat.com> Message-ID: <3da3b5b40706151047m5e87d6eeh4f29865847cc0cea@mail.gmail.com> ok, I'll write that On 6/15/07, Mike McGrath wrote: > > I've got a script request for anyone who's interested (I'm both busy and > too lazy to write it myself) > > I'd like to count the number of 'updates-released-7' requests in our > mirror logs that have happened in the last 24 hours. The script should > take two files as input and return a single integer, using bash. Here's > a sample log: > > http://mmcgrath.net/~mmcgrath/mirrors > > happy hacking > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From blizzard at redhat.com Fri Jun 15 18:34:35 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Fri, 15 Jun 2007 14:34:35 -0400 Subject: Upgrade metrics In-Reply-To: <4672B57D.8050509@redhat.com> References: <20070615102505.GB9813@neu.nirvana> <46729A2D.1080307@redhat.com> <1181920701.2737.18.camel@localhost.localdomain> <4672B57D.8050509@redhat.com> Message-ID: <1181932475.5325.9.camel@localhost.localdomain> On Fri, 2007-06-15 at 10:51 -0500, Mike McGrath wrote: > > It keeps trying as best as it can until network comes up. If all > that > fails (say a reboot is required before network comes up) the monthly > smolt checkin will start up and we'll get them a month after they > install. The monthly checkin will also let us do queries on 'active' > users say people that have submitted in the last 6 months or 12 > months. Does it do things like reload dns when the network config changes? Because, tee hee, glibc does not handle this kind of thing for you. > > Well we do have smoltGui available and we're working on adding a > rating > system for the entire profile as well as individual devices. The > question is how to get people to run it. > Who is working on that? You know, so I can stick my little nose into it. --Chris From blizzard at redhat.com Fri Jun 15 18:38:29 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Fri, 15 Jun 2007 14:38:29 -0400 Subject: Upgrade metrics In-Reply-To: <7a41c4bc0706150929m9627460jfdba43bb8c97e300@mail.gmail.com> References: <20070615102505.GB9813@neu.nirvana> <46729A2D.1080307@redhat.com> <1181920701.2737.18.camel@localhost.localdomain> <4672B57D.8050509@redhat.com> <7a41c4bc0706150929m9627460jfdba43bb8c97e300@mail.gmail.com> Message-ID: <1181932709.5325.14.camel@localhost.localdomain> On Fri, 2007-06-15 at 18:29 +0200, Paulo Santos wrote: > > Something like: > - "New survey is available" > - you click in it, do the survey and send it with the profile, it > would also be nice to have a checkbox to disable the announcements. > That's a good idea. I always worried about how to handle surveys on the client side because that's where the data is. But if you connect it to the smolt data on the server then you can measure based off that. The thing about surveys, though, is that they are connected to the current revisions of some of the software on the machine and not connected to the hardware profile. More the combination, and they change over time. What we want to be able to do is measure the experience with that combination and then measure our improvements over time. I get the impression that there's a one to one mapping from the hardware profile to UUID and that you can change the entire profile and the old data that was in there was lost. (Strangely enough when I looked up my UUID for this machine it was clearly someone else's machine. I ran smolt and stepped on it. I was a little surprised that we had a collision there.) --Chris From rayvd at bludgeon.org Fri Jun 15 18:03:53 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Fri, 15 Jun 2007 11:03:53 -0700 Subject: Script request In-Reply-To: <4672CE18.4030604@redhat.com> References: <4672CE18.4030604@redhat.com> Message-ID: <20070615180353.GA583@bludgeon.org> On Fri, Jun 15, 2007 at 12:36:24PM -0500, Mike McGrath wrote: > I've got a script request for anyone who's interested (I'm both busy and too > lazy to write it myself) > > I'd like to count the number of 'updates-released-7' requests in our mirror > logs that have happened in the last 24 hours. The script should take two > files as input and return a single integer, using bash. Here's a sample > log: > > http://mmcgrath.net/~mmcgrath/mirrors > > happy hacking Would something as simple as (see attached) work? And did you perhaps mean "updates-released-f7" instead of "updates-released-7"? Easy to change in any case. Ray -------------- next part -------------- A non-text attachment was scrubbed... Name: summary.sh Type: application/x-sh Size: 430 bytes Desc: not available URL: From ask at develooper.com Fri Jun 15 18:08:43 2007 From: ask at develooper.com (=?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Fri, 15 Jun 2007 11:08:43 -0700 Subject: Upgrade metrics In-Reply-To: <20070615152536.GE9813@neu.nirvana> References: <20070615102505.GB9813@neu.nirvana> <46729A2D.1080307@redhat.com> <20070615152536.GE9813@neu.nirvana> Message-ID: On Jun 15, 2007, at 8:25, Axel Thimm wrote: > Wow, that's really scary. FC1 should of course live forever in > archives.fp.o for historical reason, but actually using it is really > questionable :) So you wouldn't approve of my RHL7 boxes? :-) Those particular boxes are so old (both software and hardware) that we never install anything new, just slowly migrate stuff away. Even on our RHEL3 boxes we tend not to install anything new (the software is too old and annoying), but all the old stuff is Just Fine when things are already running. (Safer on RHEL3 than RHL7 obviously). - ask -- http://develooper.com/ - http://askask.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 306 bytes Desc: This is a digitally signed message part URL: From mmcgrath at redhat.com Fri Jun 15 20:41:17 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 15 Jun 2007 15:41:17 -0500 Subject: Upgrade metrics In-Reply-To: <1181932475.5325.9.camel@localhost.localdomain> References: <20070615102505.GB9813@neu.nirvana> <46729A2D.1080307@redhat.com> <1181920701.2737.18.camel@localhost.localdomain> <4672B57D.8050509@redhat.com> <1181932475.5325.9.camel@localhost.localdomain> Message-ID: <4672F96D.7060703@redhat.com> Christopher Blizzard wrote: > On Fri, 2007-06-15 at 10:51 -0500, Mike McGrath wrote: > >> It keeps trying as best as it can until network comes up. If all >> that >> fails (say a reboot is required before network comes up) the monthly >> smolt checkin will start up and we'll get them a month after they >> install. The monthly checkin will also let us do queries on 'active' >> users say people that have submitted in the last 6 months or 12 >> months. >> > > Does it do things like reload dns when the network config changes? > Because, tee hee, glibc does not handle this kind of thing for you. > > >> Well we do have smoltGui available and we're working on adding a >> rating >> system for the entire profile as well as individual devices. The >> question is how to get people to run it. >> >> > > Who is working on that? You know, so I can stick my little nose into > it. > No one right now but one of the interns has expressed interest. He's already helped me get the client running on Debian and Ubuntu. The ratings system was the next thing. Jcollie had a prototype for the client IIRC as well. If you are interested or no someone who's interested let me know. Its just been a matter of not having enough time for me to get it in. -Mike From a.badger at gmail.com Fri Jun 15 19:55:43 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 15 Jun 2007 12:55:43 -0700 Subject: Merging 'Fedora Extras' and 'Fedora Core' in owners.list Message-ID: <1181937343.28801.78.camel@localhost.localdomain> Hi all, owners.list currently contains two sections of packages, one for Fedora Extras packages and one for Fedora Core. This is reflected in bugzilla where we have two separate "products" for Core and Extras. In the near future, dkl is going to merge those products into one called "Fedora" in bugzilla and we're going to need to update owners.list to reflect that change. I've checked the attached script into CVSROOT/admin to do the job of merging. When there is only one entry for a package, the only difference will be changing the product from 'Fedora (Core|Extras)' to 'Fedora'. When there is more than one entry, the scripts merges the two together like so: Fedora Extras|ccid|Generic USB CCID smart card reader driver| ville.skytta at iki.fi|extras-qa at fedoraproject.org| ludovic.rousseau at gmail.com Fedora Core|ccid|Generic USB CCID smart card reader driver| rrelyea at redhat.com|extras-qa at fedoraproject.org| Fedora|ccid|Generic USB CCID smart card reader driver| rrelyea at redhat.com,ville.skytta at iki.fi|extras-qa at fedoraproject.org| ludovic.rousseau at gmail.com I'm also attaching a diff that shows the changes in the merge. I've already looked it over for errors but the more eyes the merrier. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: owner-merge.py Type: text/x-python Size: 4427 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: owners.list-merge.diff Type: text/x-patch Size: 36945 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ssrat at ticon.net Fri Jun 15 18:52:00 2007 From: ssrat at ticon.net (David Douthitt) Date: Fri, 15 Jun 2007 13:52:00 -0500 Subject: Web Server Bug In-Reply-To: <467200AB.6040209@fedoraproject.org> References: <4671FD79.30802@ticon.net> <467200AB.6040209@fedoraproject.org> Message-ID: <4672DFD0.1080806@ticon.net> Ricky Zhou wrote: > I don't think just showing code/non-sensitive debugging information is a > huge security problem. Consider that the code for the accounts system > is publicly viewable in CVS anyway (hooray for openness): > http://cvs.fedoraproject.org/viewcvs/fedora-accounts/?root=fedora. Having the code publically available is one matter. However, the error showed the following security-related items in any case: * Python is being used (Risk: a hacker won't try Perl, Ruby, or shell code...) * Python v2.4.3 is being used (Risk: no need to guess at which cracks will work...) * PostgreSQL is being used (Risk: no need to try mySQL hacks....) * Directory tree: /srv/web/accounts/ (Risk: no need to search out location of code...) Certainly, having the code being open is a risk but a calculated one which is offset by the benefits. In security, this is known as an "information leak." The best thing to do is *hide* all of this information (which also leads to nicer "error" pages for the user - no tech info, just a "sorry, nasty error: reported to sysadmin, thanks." or some such. -- UNIX System Administrator Linux+, SCSA, RHCE, LPIC-1 HP-UX, Linux, Solaris, FreeBSD Books: "Advanced System Administration" and "GNU Screen: A Comprehensive Introduction" http://www.lulu.com/ssrat From julianokyap at gmail.com Fri Jun 15 18:04:45 2007 From: julianokyap at gmail.com (Julian Yap) Date: Fri, 15 Jun 2007 08:04:45 -1000 Subject: 'yum update' yields an error on Fedora Core 6 Message-ID: mirros.fedoraproject.org is really a SPOF for yum and therefore Fedora as an OS. This is the 2nd time I've found an issue in the past couple of months. Some monitoring really needs to be in place because it can't afford to have any downtime. Errors below. - Julian >From the command line: $ sudo yum -y update Loading "installonlyn" plugin Setting up Update Process Setting up repositories Could not retrieve mirrorlist http://mirrors.fedoraproject.org/mirrorlist?repo=core-6&arch=i386 error was [Errno 14] HTTP Error 502: Date: Fri, 15 Jun 2007 17:59:15 GMT Content-Length: 508 Content-Type: text/html; charset=iso-8859-1 Error: Cannot find a valid baseurl for repo: core When browsing on the web: Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /mirrorlist. Reason: DNS lookup failure for: app4.fedora.phx.redhat.com Apache/2.2.3 (Red Hat) Server at mirrors.fedoraproject.org Port 80 From mmcgrath at redhat.com Fri Jun 15 20:49:08 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 15 Jun 2007 15:49:08 -0500 Subject: Script request In-Reply-To: <20070615180353.GA583@bludgeon.org> References: <4672CE18.4030604@redhat.com> <20070615180353.GA583@bludgeon.org> Message-ID: <4672FB44.9060803@redhat.com> Ray Van Dolson wrote: > On Fri, Jun 15, 2007 at 12:36:24PM -0500, Mike McGrath wrote: > >> I've got a script request for anyone who's interested (I'm both busy and too >> lazy to write it myself) >> >> I'd like to count the number of 'updates-released-7' requests in our mirror >> logs that have happened in the last 24 hours. The script should take two >> files as input and return a single integer, using bash. Here's a sample >> log: >> >> http://mmcgrath.net/~mmcgrath/mirrors >> >> happy hacking >> > > Would something as simple as (see attached) work? > > And did you perhaps mean "updates-released-f7" instead of > "updates-released-7"? Easy to change in any case. > Thanks Ray, actually that will count all instances in both files which could be as little as a 24 hour period or as much as a 48 hour period. Ahmed actually sent me a script a bit ago that I think will do just fine. Thanks for looking into it though. -Mike From jw at jhop.com Fri Jun 15 20:52:38 2007 From: jw at jhop.com (Jason Watson) Date: Fri, 15 Jun 2007 16:52:38 -0400 Subject: Script request In-Reply-To: <4672CE18.4030604@redhat.com> References: <4672CE18.4030604@redhat.com> Message-ID: <4672FC16.6060704@jhop.com> This seems too easy. Am I missing something? :) cat file1 file2 | grep 'updates-released-f7' | wc -l Or as a bash script: $ cat count-updates-rel-7.sh #!/bin/bash cat ${*} | grep 'updates-released-f7' | wc -l Jason Mike McGrath wrote: > I've got a script request for anyone who's interested (I'm both busy > and too lazy to write it myself) > > I'd like to count the number of 'updates-released-7' requests in our > mirror logs that have happened in the last 24 hours. The script > should take two files as input and return a single integer, using > bash. Here's a sample log: > > http://mmcgrath.net/~mmcgrath/mirrors > > happy hacking > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list From rayvd at bludgeon.org Fri Jun 15 20:54:15 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Fri, 15 Jun 2007 13:54:15 -0700 Subject: Script request In-Reply-To: <4672FC16.6060704@jhop.com> References: <4672CE18.4030604@redhat.com> <4672FC16.6060704@jhop.com> Message-ID: <20070615205415.GA4705@bludgeon.org> On Fri, Jun 15, 2007 at 04:52:38PM -0400, Jason Watson wrote: > > This seems too easy. Am I missing something? :) > You missed what I missed -- the 24 hour part. :) Ray From jw at jhop.com Fri Jun 15 20:55:56 2007 From: jw at jhop.com (Jason Watson) Date: Fri, 15 Jun 2007 16:55:56 -0400 Subject: Script request In-Reply-To: <4672FC16.6060704@jhop.com> References: <4672CE18.4030604@redhat.com> <4672FC16.6060704@jhop.com> Message-ID: <4672FCDC.9070604@jhop.com> Jason Watson wrote: > This seems too easy. Am I missing something? :) > I just saw your other email to Ray. Let us know if that other script doesn't work out. Move along, nothing to see here. Jason From mmcgrath at redhat.com Fri Jun 15 20:59:58 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 15 Jun 2007 15:59:58 -0500 Subject: 'yum update' yields an error on Fedora Core 6 In-Reply-To: References: Message-ID: <4672FDCE.2050007@redhat.com> Julian Yap wrote: > mirros.fedoraproject.org is really a SPOF for yum and therefore Fedora > as an OS. This is the 2nd time I've found an issue in the past couple > of months. > > Some monitoring really needs to be in place because it can't afford to > have any downtime. We discovered the issue within 3 minutes of it occuring. It was a DNS issue at our colo. If you'd like to donate space at another data center so that it's not a SPOF we'd greatly appreciate it, we've been looking for additional hosting space for a few items. Also the new mirrors system is... well new. If you find that mirrors.fp.o isn't suiting your needs I'd suggest a local mirror or picking a mirror close to you and just using it. We'll continue to harden the new system. -Mike From mmcgrath at redhat.com Fri Jun 15 21:04:19 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 15 Jun 2007 16:04:19 -0500 Subject: Web Server Bug In-Reply-To: <4672DFD0.1080806@ticon.net> References: <4671FD79.30802@ticon.net> <467200AB.6040209@fedoraproject.org> <4672DFD0.1080806@ticon.net> Message-ID: <4672FED3.3060808@redhat.com> David Douthitt wrote: > Ricky Zhou wrote: > >> I don't think just showing code/non-sensitive debugging information is a >> huge security problem. Consider that the code for the accounts system >> is publicly viewable in CVS anyway (hooray for openness): >> http://cvs.fedoraproject.org/viewcvs/fedora-accounts/?root=fedora. >> > Having the code publically available is one matter. > > However, the error showed the following security-related items in any case: > > * Python is being used (Risk: a hacker won't try Perl, Ruby, or shell > code...) > * Python v2.4.3 is being used (Risk: no need to guess at which cracks > will work...) > * PostgreSQL is being used (Risk: no need to try mySQL hacks....) > * Directory tree: /srv/web/accounts/ (Risk: no need to search out > location of code...) > > Certainly, having the code being open is a risk but a calculated one > which is offset by the benefits. > > In security, this is known as an "information leak." The best thing to > do is *hide* all of this information (which also leads to nicer "error" > pages for the user - no tech info, just a "sorry, nasty error: reported > to sysadmin, thanks." or some such. > We freely discuss all of the above items. It's a side affect of being an open organization. Someone might as well just say "hey, I'm looking at your accounts code and I'm wondering, what version of python are you using, what version of postgres is on the back end?" Yes, the code dump is ugly but the accounts system is being completely re-written so all work to fix the current system has basically been put on hold, though the complaint you have is a common one. -Mike From tchung at fedoraproject.org Fri Jun 15 22:31:50 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Fri, 15 Jun 2007 15:31:50 -0700 Subject: From addresses in Live Mail. In-Reply-To: <53a863600706132104g3d39f08av5190a14f525c957c@mail.gmail.com> References: <53a863600706132104g3d39f08av5190a14f525c957c@mail.gmail.com> Message-ID: <369bce3b0706151531l1983ada2s9feb55d7d76e9266@mail.gmail.com> On 6/13/07, jose manimala wrote: > the new version of hotmail(live mail) seems to support from addresses. > shouldn't it be checked for compatibility with fedora emailaliases? > > -- > Jose M Manimala Jose, I would suggest to post your proposal for EmailAliases[1] compatibility check to fedora-websites-list since this is content issue within Fedora Websites not an issue with Fedora Infrastructure. [1] http://fedoraproject.org/wiki/EmailAliases Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From tchung at fedoraproject.org Fri Jun 15 22:34:47 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Fri, 15 Jun 2007 15:34:47 -0700 Subject: Emailaliases - hotmail needs updating In-Reply-To: <53a863600706150111i2451658dlfc3467ee5c2f3a46@mail.gmail.com> References: <53a863600706150111i2451658dlfc3467ee5c2f3a46@mail.gmail.com> Message-ID: <369bce3b0706151534w7f5ef75cidc02a5443e4b6271@mail.gmail.com> On 6/15/07, jose manimala wrote: > ok i am sorry about the previous mistake i made. Here is an updated > email with proper images. Hotmail now allows From address and reply-to > address options. the emailaliases needs to be updated. Once again, I would suggest to post your proposal for EmailAliases[1] compatibility check to fedora-websites-list since this is content issue within Fedora Websites not an issue with Fedora Infrastructure. [1] http://fedoraproject.org/wiki/EmailAliases Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From mmcgrath at redhat.com Sat Jun 16 20:52:38 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 16 Jun 2007 15:52:38 -0500 Subject: Redirects enabled Message-ID: <46744D96.70606@redhat.com> Redirects on the wiki have been enabled: http://fedoraproject.org/wiki/InstallationGuide To view: http://fedoraproject.org/wiki/InstallationGuide?action=raw -Mike From ssrat at ticon.net Sun Jun 17 01:36:34 2007 From: ssrat at ticon.net (David Douthitt) Date: Sat, 16 Jun 2007 20:36:34 -0500 Subject: Web Server Bug In-Reply-To: <4672FED3.3060808@redhat.com> References: <4671FD79.30802@ticon.net> <467200AB.6040209@fedoraproject.org> <4672DFD0.1080806@ticon.net> <4672FED3.3060808@redhat.com> Message-ID: <46749022.3090009@ticon.net> Mike McGrath wrote: > Yes, the code dump is ugly but the accounts system is being completely > re-written so all work to fix the current system has basically been > put on hold, though the complaint you have is a common one. That's good to know - yet, this makes me think of two things. One, why not put that into a FAQ somewhere that people can look at? Another thing that comes to mind - I don't know if this is already done, or if the discussion on it has already been thrashed to death - but why not use Subversion and two different branches, one being a development branch and one a stable branch? Innumerable projects do this already, including FreeBSD, Linux, Samba, and who knows how many more..... -- UNIX System Administrator Linux+, SCSA, RHCE, LPIC-1 HP-UX, Linux, Solaris, FreeBSD Books: "Advanced System Administration" and "GNU Screen: A Comprehensive Introduction" http://www.lulu.com/ssrat From a.badger at gmail.com Mon Jun 18 01:31:34 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 17 Jun 2007 18:31:34 -0700 Subject: Web Server Bug In-Reply-To: <46749022.3090009@ticon.net> References: <4671FD79.30802@ticon.net> <467200AB.6040209@fedoraproject.org> <4672DFD0.1080806@ticon.net> <4672FED3.3060808@redhat.com> <46749022.3090009@ticon.net> Message-ID: <1182130294.13047.0.camel@localhost.localdomain> On Sat, 2007-06-16 at 20:36 -0500, David Douthitt wrote: > Mike McGrath wrote: > > Yes, the code dump is ugly but the accounts system is being completely > > re-written so all work to fix the current system has basically been > > put on hold, though the complaint you have is a common one. > That's good to know - yet, this makes me think of two things. > > One, why not put that into a FAQ somewhere that people can look at? > > Another thing that comes to mind - I don't know if this is already done, > or if the discussion on it has already been thrashed to death - but why > not use Subversion and two different branches, one being a development > branch and one a stable branch? Innumerable projects do this already, > including FreeBSD, Linux, Samba, and who knows how many more..... > Two different branches of what? The website? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ssrat at ticon.net Mon Jun 18 15:38:22 2007 From: ssrat at ticon.net (David Douthitt) Date: Mon, 18 Jun 2007 10:38:22 -0500 Subject: Web Server Bug In-Reply-To: <1182130294.13047.0.camel@localhost.localdomain> References: <4671FD79.30802@ticon.net> <467200AB.6040209@fedoraproject.org> <4672DFD0.1080806@ticon.net> <4672FED3.3060808@redhat.com> <46749022.3090009@ticon.net> <1182130294.13047.0.camel@localhost.localdomain> Message-ID: <4676A6EE.7030809@ticon.net> Toshio Kuratomi wrote: > On Sat, 2007-06-16 at 20:36 -0500, David Douthitt wrote: > >> Mike McGrath wrote: >> >>> Yes, the code dump is ugly but the accounts system is being completely >>> re-written so all work to fix the current system has basically been >>> put on hold, though the complaint you have is a common one. >>> >> Another thing that comes to mind - I don't know if this is already done, >> or if the discussion on it has already been thrashed to death - but why >> not use Subversion and two different branches, one being a development >> branch and one a stable branch? Innumerable projects do this already, >> including FreeBSD, Linux, Samba, and who knows how many more..... >> > Two different branches of what? The website? Two branches of the code being used in the web site - "the accounts system" for example. If the complaint is a common one, it would be better (I would argue) to fix the problem immediately in one branch of the software and let development continue separately. Doing this fixes the problem, reduces support questions, reduces time spent answering the same question over and over, and improves the stability and quality of the overall product while improving the user experience and perceptions at the same time. -- UNIX System Administrator Linux+, SCSA, RHCE, LPIC-1 HP-UX, Linux, Solaris, FreeBSD Books: "Advanced System Administration" and "GNU Screen: A Comprehensive Introduction" http://www.lulu.com/ssrat From mmcgrath at redhat.com Mon Jun 18 15:45:01 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 18 Jun 2007 10:45:01 -0500 Subject: Web Server Bug In-Reply-To: <4676A6EE.7030809@ticon.net> References: <4671FD79.30802@ticon.net> <467200AB.6040209@fedoraproject.org> <4672DFD0.1080806@ticon.net> <4672FED3.3060808@redhat.com> <46749022.3090009@ticon.net> <1182130294.13047.0.camel@localhost.localdomain> <4676A6EE.7030809@ticon.net> Message-ID: <4676A87D.3050603@redhat.com> David Douthitt wrote: > Toshio Kuratomi wrote: >> On Sat, 2007-06-16 at 20:36 -0500, David Douthitt wrote: >> >>> Mike McGrath wrote: >>> >>>> Yes, the code dump is ugly but the accounts system is being completely >>>> re-written so all work to fix the current system has basically been >>>> put on hold, though the complaint you have is a common one. >>> Another thing that comes to mind - I don't know if this is already >>> done, >>> or if the discussion on it has already been thrashed to death - but why >>> not use Subversion and two different branches, one being a development >>> branch and one a stable branch? Innumerable projects do this already, >>> including FreeBSD, Linux, Samba, and who knows how many more..... >>> >> Two different branches of what? The website? > Two branches of the code being used in the web site - "the accounts > system" for example. If the complaint is a common one, it would be > better (I would argue) to fix the problem immediately in one branch of > the software and let development continue separately. Doing this > fixes the problem, reduces support questions, reduces time spent > answering the same question over and over, and improves the stability > and quality of the overall product while improving the user experience > and perceptions at the same time. > Quoted from earlier: "Yes, the code dump is ugly but the accounts system is being completely re-written so all work to fix the current system has basically been put on hold, though the complaint you have is a common one." Anyone is welcome to submit a patch though I'd prefer they spend that time working on the new account system instead. -Mike From admin at arcnetworks.biz Mon Jun 18 16:37:21 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Mon, 18 Jun 2007 22:07:21 +0530 Subject: Fedora Magazine RFR Message-ID: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> Here is the link to my RFR https://fedoraproject.org/wiki/Infrastructure/RFR/FedoraMagazine -=- Also, is it ok that I created a group on the account system called magazine? Thanks, Anand Capur -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Mon Jun 18 16:44:47 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 18 Jun 2007 11:44:47 -0500 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> Message-ID: <4676B67F.4000804@redhat.com> Anand Capur wrote: > Here is the link to my RFR > https://fedoraproject.org/wiki/Infrastructure/RFR/FedoraMagazine > -=- > Also, is it ok that I created a group on the account system called > magazine? > Thanks, > Anand Capur Why would http://fedoraproject.org/wiki/FedoraMagazine not work as it does for http://fedoraproject.org/wiki/FWN ? -Mike From admin at arcnetworks.biz Mon Jun 18 17:17:50 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Mon, 18 Jun 2007 22:47:50 +0530 Subject: Fedora Magazine RFR In-Reply-To: <4676B67F.4000804@redhat.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676B67F.4000804@redhat.com> Message-ID: <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> We are going to be a real online magazine with an ISSN number with the possibility of going to a print edition in the future. I have a flash based magazine reader and many other things that could not run on the wiki. We are a totally separate idea than FWN. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Mon Jun 18 17:29:38 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 18 Jun 2007 12:29:38 -0500 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676B67F.4000804@redhat.com> <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> Message-ID: <4676C102.7020901@redhat.com> Anand Capur wrote: > We are going to be a real online magazine with an ISSN number with the > possibility of going to a print edition in the future. I have a flash > based > magazine reader and many other things that could not run on the wiki. > We are > a totally separate idea than FWN. I saw that, and as for the namespace you need a completely separate domain? fedoraproject.org/FedoraMagazine/ won't work? Also you'll be using PHP, please explain more what you'll be doing with php. We are extremely concerned about php in our environment. -Mike From admin at arcnetworks.biz Mon Jun 18 17:37:20 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Mon, 18 Jun 2007 23:07:20 +0530 Subject: Fedora Magazine RFR In-Reply-To: <4676C102.7020901@redhat.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676B67F.4000804@redhat.com> <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> <4676C102.7020901@redhat.com> Message-ID: <5d66540b0706181037w1e476057s6a08996eaf9dc1f0@mail.gmail.com> I understand, it will be for my egroupware installation, and maby joomla cms if needed. The good thing is both are quite secure when installed properly. Here is the reccomended config for egroupware. (It printed this on my home comp). And yes we need a completely separate domain. Checking required PHP version 4.3+ (recommended 5+): 4.4.7 ==> True Checking php.ini: safe_mode = Off: ini_get('safe_mode')='' = Off Checking php.ini: magic_quotes_runtime = Off: ini_get('magic_quotes_runtime')='0' = Off Checking php.ini: register_globals = Off: ini_get('register_globals')='0' = Off Checking php.ini: memory_limit >= 16M: ini_get('memory_limit')='' Checking php.ini: max_execution_time >= 30: ini_get('max_execution_time')='60' Checking php.ini: file_uploads = On: ini_get('file_uploads')='1' = On Checking php.ini: include_path contain .: ini_get('include_path')='.:/usr/lib/php:/usr/local/lib/php' Checking php.ini: mbstring.func_overload = 7: ini_get(' mbstring.func_overload')='7' Checking extension mysql is loaded or loadable: True Checking extension pgsql is loaded or loadable: False The pgsql extension is needed, if you plan to use a pgSQL database. Checking extension odbc is loaded or loadable: False The odbc extension is needed, if you plan to use a MaxDB, MsSQL or Oracle database. Checking extension oci8 is loaded or loadable: False The oci extension is needed, if you plan to use a Oracle database. Checking extension mbstring is loaded or loadable: True Checking extension session is loaded or loadable: True Checking extension imap is loaded or loadable: True Checking PEAR is installed: 1.5.4 Checking PEAR::Net_Socket is installed: 999.egw-pear Checking PEAR::Auth_SASL is installed: 1.0.2 Checking PEAR::Net_IMAP is installed: 999.egw-pear Checking PEAR::Net_Sieve is installed: 999.egw-pear Checking PEAR::HTTP_WebDAV_Server is installed: 999.egw-pear Checking PEAR::Log is installed: 999.egw-pear Checking for GD support...: True Checking file-permissions of . for not world writable: root/root drwxr-xr-x This might take a while, please wait ... Checking file-permissions of header.inc.php for not world readable: nobody/nobody -rw-r--r-- header.inc.php is world readable !!! Checking if php.ini setting session.save_path='/tmp' is writable by the webserver: root/root drwxrwxrwt Thanks, Anand -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at arcnetworks.biz Mon Jun 18 17:39:19 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Mon, 18 Jun 2007 23:09:19 +0530 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706181037w1e476057s6a08996eaf9dc1f0@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676B67F.4000804@redhat.com> <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> <4676C102.7020901@redhat.com> <5d66540b0706181037w1e476057s6a08996eaf9dc1f0@mail.gmail.com> Message-ID: <5d66540b0706181039x16006719p9b9683df5bf6da6b@mail.gmail.com> Also, it is ok that I made a group on the account system called magazine? I just want to make sure ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From cra at WPI.EDU Mon Jun 18 17:46:31 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 18 Jun 2007 13:46:31 -0400 Subject: Fedora Magazine RFR In-Reply-To: <4676C102.7020901@redhat.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676B67F.4000804@redhat.com> <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> <4676C102.7020901@redhat.com> Message-ID: <20070618174631.GS3310@angus.ind.WPI.EDU> On Mon, Jun 18, 2007 at 12:29:38PM -0500, Mike McGrath wrote: > Anand Capur wrote: > >We are going to be a real online magazine with an ISSN number with the > >possibility of going to a print edition in the future. I have a flash > >based > >magazine reader and many other things that could not run on the wiki. > >We are > >a totally separate idea than FWN. > > I saw that, and as for the namespace you need a completely separate > domain? fedoraproject.org/FedoraMagazine/ won't work? Also you'll be > using PHP, please explain more what you'll be doing with php. We are > extremely concerned about php in our environment. I'm extremely concerned that an official Fedora magazine would require the proprietary Flash plugin to view. From mmcgrath at redhat.com Mon Jun 18 17:48:47 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 18 Jun 2007 12:48:47 -0500 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706181039x16006719p9b9683df5bf6da6b@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676B67F.4000804@redhat.com> <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> <4676C102.7020901@redhat.com> <5d66540b0706181037w1e476057s6a08996eaf9dc1f0@mail.gmail.com> <5d66540b0706181039x16006719p9b9683df5bf6da6b@mail.gmail.com> Message-ID: <4676C57F.3060509@redhat.com> Anand Capur wrote: > Also, it is ok that I made a group on the account system called > magazine? I > just want to make sure ;) Don't do it yet, if we accept this proposal we'll give you a xen instance to get a proof of concept up and running. Once it goes to production you can create the group. What do you plan on using the group for? -Mike From sundaram at fedoraproject.org Mon Jun 18 17:50:29 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 18 Jun 2007 23:20:29 +0530 Subject: Fedora Magazine RFR In-Reply-To: <20070618174631.GS3310@angus.ind.WPI.EDU> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676B67F.4000804@redhat.com> <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> <4676C102.7020901@redhat.com> <20070618174631.GS3310@angus.ind.WPI.EDU> Message-ID: <4676C5E5.5030006@fedoraproject.org> Chuck Anderson wrote: > On Mon, Jun 18, 2007 at 12:29:38PM -0500, Mike McGrath wrote: >> Anand Capur wrote: >>> We are going to be a real online magazine with an ISSN number with the >>> possibility of going to a print edition in the future. I have a flash >>> based >>> magazine reader and many other things that could not run on the wiki. >>> We are >>> a totally separate idea than FWN. >> I saw that, and as for the namespace you need a completely separate >> domain? fedoraproject.org/FedoraMagazine/ won't work? Also you'll be >> using PHP, please explain more what you'll be doing with php. We are >> extremely concerned about php in our environment. > > I'm extremely concerned that an official Fedora magazine would require > the proprietary Flash plugin to view. Absolutely. I would strongly suggest you avoid flash completely or offer Ogg video or animated GIF files as alternatives. Rahul From admin at arcnetworks.biz Mon Jun 18 17:54:01 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Mon, 18 Jun 2007 23:24:01 +0530 Subject: Fedora Magazine RFR In-Reply-To: <4676C57F.3060509@redhat.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676B67F.4000804@redhat.com> <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> <4676C102.7020901@redhat.com> <5d66540b0706181037w1e476057s6a08996eaf9dc1f0@mail.gmail.com> <5d66540b0706181039x16006719p9b9683df5bf6da6b@mail.gmail.com> <4676C57F.3060509@redhat.com> Message-ID: <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> I already did, but i'd be happy to remove it (group). A xen instance sounds good (I am experienced with all the command line/ssh stuff, so I wouldn't need much help). I plan on using the group for tracking, and to ensure that the cla_done group is completed by the contributers (it is a magazine that will be under a no-copyright, so as the wiki needs we would need that agreement signed also). I will be providing it in multiple formats, not only flash. Flash would just enhance the viewing experience, but in NO way would be required!!! Thanks, Anand -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Mon Jun 18 17:58:31 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 18 Jun 2007 12:58:31 -0500 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676B67F.4000804@redhat.com> <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> <4676C102.7020901@redhat.com> <5d66540b0706181037w1e476057s6a08996eaf9dc1f0@mail.gmail.com> <5d66540b0706181039x16006719p9b9683df5bf6da6b@mail.gmail.com> <4676C57F.3060509@redhat.com> <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> Message-ID: <4676C7C7.4090000@redhat.com> Anand Capur wrote: > I already did, but i'd be happy to remove it (group). A xen instance > sounds > good (I am experienced with all the command line/ssh stuff, so I wouldn't > need much help). I plan on using the group for tracking, and to ensure > that > the cla_done group is completed by the contributers (it is a magazine > that > will be under a no-copyright, so as the wiki needs we would need that > agreement signed also). I'm extremely surprised and worried that you could create a FAS group... (not your fault). I'd like to hear what others think about this proposal. Also, right now is it just you doing the work or do you have an interested team and support group? > I will be providing it in multiple formats, not only > flash. Flash would just enhance the viewing experience, but in NO way > would > be required!!! I think many would argue that if it doesn't work with a default fedora install, we shouldn't use it. Fedora as an organization values freedom... as well as stable FireFox installs ;-) -Mike From smooge at gmail.com Mon Jun 18 18:06:39 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 18 Jun 2007 12:06:39 -0600 Subject: Fedora Magazine RFR In-Reply-To: <20070618174631.GS3310@angus.ind.WPI.EDU> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676B67F.4000804@redhat.com> <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> <4676C102.7020901@redhat.com> <20070618174631.GS3310@angus.ind.WPI.EDU> Message-ID: <80d7e4090706181106o77dfa36bpeaff480f59bd8881@mail.gmail.com> On 6/18/07, Chuck Anderson wrote: > On Mon, Jun 18, 2007 at 12:29:38PM -0500, Mike McGrath wrote: > > Anand Capur wrote: > > >We are going to be a real online magazine with an ISSN number with the > > >possibility of going to a print edition in the future. I have a flash > > >based > > >magazine reader and many other things that could not run on the wiki. > > >We are > > >a totally separate idea than FWN. > > > > I saw that, and as for the namespace you need a completely separate > > domain? fedoraproject.org/FedoraMagazine/ won't work? Also you'll be > > using PHP, please explain more what you'll be doing with php. We are > > extremely concerned about php in our environment. > > I'm extremely concerned that an official Fedora magazine would require > the proprietary Flash plugin to view. > I would like to add a +1 on this. Listen I realize that having flash will enhance how it is perceived and will allow more editorial control on layout. However, it would seem to undercut the core message of Fedora == Freedom. If you have to use propietary authoring controls to create that message... you have weakened the message. Until gnash (or something equivalnet) is shipped core in Fedora.. I would be concerned that any official Fedora product should be able to be used with only a Core product. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From skvidal at linux.duke.edu Mon Jun 18 18:08:37 2007 From: skvidal at linux.duke.edu (Seth Vidal) Date: Mon, 18 Jun 2007 14:08:37 -0400 (EDT) Subject: Fedora Magazine RFR In-Reply-To: <80d7e4090706181106o77dfa36bpeaff480f59bd8881@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676B67F.4000804@redhat.com> <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> <4676C102.7020901@redhat.com> <20070618174631.GS3310@angus.ind.WPI.EDU> <80d7e4090706181106o77dfa36bpeaff480f59bd8881@mail.gmail.com> Message-ID: On Mon, 18 Jun 2007, Stephen John Smoogen wrote: > I would like to add a +1 on this. > > Listen I realize that having flash will enhance how it is perceived > and will allow more editorial control on layout. However, it would > seem to undercut the core message of Fedora == Freedom. If you have to > use propietary authoring controls to create that message... you have > weakened the message. > > Until gnash (or something equivalnet) is shipped core in Fedora.. I > would be concerned that any official Fedora product should be able to > be used with only a Core product. +10. And let's not even START about the section 508 and flash issues. seriously, friends don't let friends use flash. -sv From jeff at ocjtech.us Mon Jun 18 18:26:04 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Mon, 18 Jun 2007 13:26:04 -0500 Subject: Fedora Magazine RFR In-Reply-To: References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676B67F.4000804@redhat.com> <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> <4676C102.7020901@redhat.com> <20070618174631.GS3310@angus.ind.WPI.EDU> <80d7e4090706181106o77dfa36bpeaff480f59bd8881@mail.gmail.com> Message-ID: <1182191164.5875.21.camel@lt21223.campus.dmacc.edu> On Mon, 2007-06-18 at 14:08 -0400, Seth Vidal wrote: > On Mon, 18 Jun 2007, Stephen John Smoogen wrote: > > > I would like to add a +1 on this. > > > > Listen I realize that having flash will enhance how it is perceived > > and will allow more editorial control on layout. However, it would > > seem to undercut the core message of Fedora == Freedom. If you have to > > use propietary authoring controls to create that message... you have > > weakened the message. > > > > Until gnash (or something equivalnet) is shipped core in Fedora.. I > > would be concerned that any official Fedora product should be able to > > be used with only a Core product. > > +10. > > And let's not even START about the section 508 and flash issues. > > seriously, friends don't let friends use flash. A lot of what Flash can do can be done in SVG if you have a modern browser (FF 1.5+, dunno about the status of IE). Recently Nicu Buculei posted a demonstration web site done entirely in SVG[1]. Not that I'd really recommend it though, but it shows the power of SVG. The Totem Mozilla plugin does an excellent job of displaying embedded video as well. Even if gnash or swfdec become part of Fedora, they will always be playing "catch up" with a proprietary standard controlled by a commercial company. [1] http://nicubunu.blogspot.com/2007/06/authoring-svg-websites-with-inkscape.html Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mmcgrath at redhat.com Mon Jun 18 18:32:27 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 18 Jun 2007 13:32:27 -0500 Subject: Iptables Solution Message-ID: <4676CFBB.9070503@redhat.com> lmacken, skvidal and xDamonx have been working together to create a simple (and predictable) set of iptables rules. They're now ready and xDamonx will be deploying them. The iptables template is done and basically all thats needed to deploy is added to the manifests file. For example, here's whats in our db group (as is in manifests/servergroups/db.pp: # firewall Rules $tcpPorts = [ 3306, 5432 ] $udpPorts = [ ] iptables { '/etc/sysconfig/iptables': content => template('/var/lib/puppet/config/system/iptables-template.conf.erb'), } service { iptables: ensure => running, hasstatus => true, } # EOF After we roll these out we can easily add things to the template like the bandwidth limiting we need on the proxy servers and adding a "$rateLimit = 1" to the manifest. -Mike From mmcgrath at redhat.com Mon Jun 18 18:57:09 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 18 Jun 2007 13:57:09 -0500 Subject: Our SCM Message-ID: <4676D585.1030706@redhat.com> So there's a great deal of discussion about the Fedora Packaging SCM its time we look at the Infrastructure SCM. We now host cvs, hg, git and svn. For our configuration management we're using for our development. For many items we've actually created hosted sites (smolt, mirror manager) seems appropriate for these project which, in theory, are useful to others. But what about some of our other development where a hosted project would be wasted? This would be like, kindofblue (our wiki theme) or a plone plugin. We're using cvs for this right now in the fedora repo. I think we should do some clean up on this repo but while we're doing its good to evaluate whether or not to move to something else or to continue using it. Thoughts? -Mike From paulo.banon at googlemail.com Mon Jun 18 19:04:08 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Mon, 18 Jun 2007 21:04:08 +0200 Subject: Our SCM In-Reply-To: <4676D585.1030706@redhat.com> References: <4676D585.1030706@redhat.com> Message-ID: <7a41c4bc0706181204j78609368vcbad61d3823d3efe@mail.gmail.com> +1 on the cleanup Regarding, changing the actually SCM, do we need anything that CVS doesnt offer ? If we do, then lets discuss options, if we dont, then let's stick with it. Paulo On 6/18/07, Mike McGrath wrote: > > So there's a great deal of discussion about the Fedora Packaging SCM its > time we look at the Infrastructure SCM. We now host cvs, hg, git and > svn. For our configuration management we're using for our development. > For many items we've actually created hosted sites (smolt, mirror > manager) seems appropriate for these project which, in theory, are > useful to others. But what about some of our other development where a > hosted project would be wasted? This would be like, kindofblue (our > wiki theme) or a plone plugin. We're using cvs for this right now in > the fedora repo. I think we should do some clean up on this repo but > while we're doing its good to evaluate whether or not to move to > something else or to continue using it. > > Thoughts? > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From katzj at redhat.com Mon Jun 18 19:09:29 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 18 Jun 2007 15:09:29 -0400 Subject: Our SCM In-Reply-To: <4676D585.1030706@redhat.com> References: <4676D585.1030706@redhat.com> Message-ID: <1182193769.16956.4.camel@erebor.boston.redhat.com> On Mon, 2007-06-18 at 13:57 -0500, Mike McGrath wrote: > So there's a great deal of discussion about the Fedora Packaging SCM its > time we look at the Infrastructure SCM. We now host cvs, hg, git and > svn. For our configuration management we're using for our development. > For many items we've actually created hosted sites (smolt, mirror > manager) seems appropriate for these project which, in theory, are > useful to others. But what about some of our other development where a > hosted project would be wasted? This would be like, kindofblue (our > wiki theme) or a plone plugin. We're using cvs for this right now in > the fedora repo. I think we should do some clean up on this repo but > while we're doing its good to evaluate whether or not to move to > something else or to continue using it. There are other things where we've set up repos (generally under the hosted space but not always) that also don't need the full "hosted" treatment. And being able to continue doing so is very valuable. And it will become even more needed as we get things moved from elvis -> fp.org. Having a "hosted" project is overkill for a lot of the things there, but they definitely need some SCM bits. Jeremy From jkeating at redhat.com Mon Jun 18 19:19:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 18 Jun 2007 15:19:11 -0400 Subject: Our SCM In-Reply-To: <1182193769.16956.4.camel@erebor.boston.redhat.com> References: <4676D585.1030706@redhat.com> <1182193769.16956.4.camel@erebor.boston.redhat.com> Message-ID: <200706181519.15348.jkeating@redhat.com> On Monday 18 June 2007 15:09:29 Jeremy Katz wrote: > There are other things where we've set up repos (generally under the > hosted space but not always) that also don't need the full "hosted" > treatment. ?And being able to continue doing so is very valuable. > > And it will become even more needed as we get things moved from elvis -> > fp.org. ?Having a "hosted" project is overkill for a lot of the things > there, but they definitely need some SCM bits. Perhaps it's worth pointing out that we can do "hosting" without a Trac space. The Hosting right now is really 2 part. SCM space and a group in FAS to manage write access to it, and a Trac instance. In the future there may be other parts like raw webspace to host http or file content (such as release tarballs...), shell accounts to manage said files, etc... We can host projects that use some or all of these services. By no means should each and every project have to make use of or even have each and every service. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Mon Jun 18 19:39:03 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 18 Jun 2007 15:39:03 -0400 Subject: Our SCM In-Reply-To: <200706181519.15348.jkeating@redhat.com> References: <4676D585.1030706@redhat.com> <1182193769.16956.4.camel@erebor.boston.redhat.com> <200706181519.15348.jkeating@redhat.com> Message-ID: <1182195543.16956.18.camel@erebor.boston.redhat.com> On Mon, 2007-06-18 at 15:19 -0400, Jesse Keating wrote: > On Monday 18 June 2007 15:09:29 Jeremy Katz wrote: > > There are other things where we've set up repos (generally under the > > hosted space but not always) that also don't need the full "hosted" > > treatment. And being able to continue doing so is very valuable. > > > > And it will become even more needed as we get things moved from elvis -> > > fp.org. Having a "hosted" project is overkill for a lot of the things > > there, but they definitely need some SCM bits. > > Perhaps it's worth pointing out that we can do "hosting" without a Trac space. > The Hosting right now is really 2 part. SCM space and a group in FAS to > manage write access to it, and a Trac instance. In the future there may be > other parts like raw webspace to host http or file content (such as release > tarballs...), shell accounts to manage said files, etc... We can host > projects that use some or all of these services. By no means should each and > every project have to make use of or even have each and every service. Yeah, that's a much better way to say what I was trying to get at :-) Jeremy From nils at breun.nl Mon Jun 18 19:53:53 2007 From: nils at breun.nl (Nils Breunese) Date: Mon, 18 Jun 2007 21:53:53 +0200 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706181037w1e476057s6a08996eaf9dc1f0@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676B67F.4000804@redhat.com> <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> <4676C102.7020901@redhat.com> <5d66540b0706181037w1e476057s6a08996eaf9dc1f0@mail.gmail.com> Message-ID: <2547608B-5C32-49EE-820A-B25742F9B816@breun.nl> Anand Capur wrote: > I understand, it will be for my egroupware installation, and maby > joomla cms if needed. The good thing is both are quite secure when > installed properly. That is not my experience with Joomla. Lots of security holes in that one (and Mambo from which it is offspring). Nils Breunese. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Dit deel van het bericht is digitaal ondertekend URL: From gerold at lugd.org Mon Jun 18 19:59:38 2007 From: gerold at lugd.org (Gerold Kassube) Date: Mon, 18 Jun 2007 21:59:38 +0200 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706181037w1e476057s6a08996eaf9dc1f0@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676B67F.4000804@redhat.com> <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> <4676C102.7020901@redhat.com> <5d66540b0706181037w1e476057s6a08996eaf9dc1f0@mail.gmail.com> Message-ID: <1182196778.3973.7.camel@Amilo-GK.homenet.local> Am Montag, den 18.06.2007, 23:07 +0530 schrieb Anand Capur: > I understand, it will be for my egroupware installation, and maby > joomla cms if needed. The good thing is both are quite secure when > installed properly. Here is the reccomended config for egroupware. (It > printed this on my home comp). And yes we need a completely separate > domain. ^^ YOUR eGroupware-Installation and maybe YOUR joomla; excuse me but we have a wiki basicly on fedoraproject? If these are your projects, why they have to be in the Fedora-Infrastructure? Just a question, nothing more ... Regards GeroldKa -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From jeff at ocjtech.us Mon Jun 18 20:07:59 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Mon, 18 Jun 2007 15:07:59 -0500 Subject: Our SCM In-Reply-To: <7a41c4bc0706181204j78609368vcbad61d3823d3efe@mail.gmail.com> References: <4676D585.1030706@redhat.com> <7a41c4bc0706181204j78609368vcbad61d3823d3efe@mail.gmail.com> Message-ID: <1182197279.7617.2.camel@lt21223.campus.dmacc.edu> On Mon, 2007-06-18 at 21:04 +0200, Paulo Santos wrote: > +1 on the cleanup > > Regarding, changing the actually SCM, do we need anything that CVS > doesnt offer ? > If we do, then lets discuss options, if we dont, then let's stick with > it. Other than the fact that CVS sucks? Git would be my preference, Mercurial I could live with. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Mon Jun 18 23:53:33 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 18 Jun 2007 16:53:33 -0700 Subject: Our SCM In-Reply-To: <4676D585.1030706@redhat.com> References: <4676D585.1030706@redhat.com> Message-ID: <1182210813.13047.106.camel@localhost.localdomain> On Mon, 2007-06-18 at 13:57 -0500, Mike McGrath wrote: > So there's a great deal of discussion about the Fedora Packaging SCM its > time we look at the Infrastructure SCM. We now host cvs, hg, git and > svn. For our configuration management we're using for our development. > For many items we've actually created hosted sites (smolt, mirror > manager) seems appropriate for these project which, in theory, are > useful to others. But what about some of our other development where a > hosted project would be wasted? This would be like, kindofblue (our > wiki theme) or a plone plugin. We're using cvs for this right now in > the fedora repo. I think we should do some clean up on this repo but > while we're doing its good to evaluate whether or not to move to > something else or to continue using it. > Can we consolidate a bunch of these into one or more hosted repositories? It's a small step better than our current situation of multiple cvs modules in multiple cvs repositories. Whatever we choose, I've come to believe that a distributed SCM would be good for anything that's not private. (and even some things that are). There are some small pieces of code that end up being worked on at the same time (for instance, the cvsadmin scripts) and having them in a distributed scm would make it easier for people to merge their changes in or merge changes from the repository into their local changes. Additionally, I've started working with people who are new to infrastructure. It's nice to be able to branch a repository and say go to town to someone rather than having them stuck trying to manage patches to the mainline until we're comfortable giving them commit access to the main tree. P.S. I like bzr because it combines the feature(s) I actually liked from svn with the distributed nature of hg, git, etc. I'm not a fan of hg but think it's mq plugin is a great feature. I abhor git :-) The main conceptual difference I've found in bzr and hg so far is that hg seems to work on a repository paradigm whereas bzr works on a branch paradigm[1]_. In hg you clone a repository. Then you end up working on one of many possible tips within your local repo. If you merge from someone else, you first import it into your repository. Then you have to merge the changes from that HEAD and resolve the conflicts in your working tree. In bzr, you branch a branch. There is a single head within that branch. You merge changes to your working copy when you want (and the history of the changes from the other branch is saved in your branch.) svn users will find this very familiar as bzr branches are a new directory tree just like svn branches. Since bzr is distributed, though, it gives you the ability to merge between these branches without having to remember what your last merge was. bzr also makes tags an attribute of a commit rather than svn's "It's a branch that you agree not to edit". [1]_: bzr has a repository format that is optimized storage for branches. You can create a repository in a directory. Then any branches you create in the directory will share storage where things are held in common. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From admin at arcnetworks.biz Tue Jun 19 01:30:22 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Tue, 19 Jun 2007 07:00:22 +0530 Subject: Fedora Magazine RFR In-Reply-To: <1182196778.3973.7.camel@Amilo-GK.homenet.local> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676B67F.4000804@redhat.com> <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> <4676C102.7020901@redhat.com> <5d66540b0706181037w1e476057s6a08996eaf9dc1f0@mail.gmail.com> <1182196778.3973.7.camel@Amilo-GK.homenet.local> Message-ID: <5d66540b0706181830s433923cfi9270e9e48bfa482d@mail.gmail.com> Yes, I can make groups, see all the users, and groups also. BUT If I try to edit a user that isn't me it just gives basic info about them. If I try to edit a group that isn't mine it shows me like I can edit it, but when I click update, save, whatever it doesn't let me complete the edit. Actually the flash was only to have it so you can turn the pages like a real magazine. If you don't want that, thats no problem it isn't required in any way. So far I have 5 people on our team. I would secure Joomla, not just a vanilla uninstall. Yes, I agree that they aren't secure from the start, but they can be. Joomla is just a possibility, but probably unlikely since we are formatting and designing the magazine offline. I simply said my because I am the one installing it. It isn't mine personally and the magazine isn't mine personally also. I'm just the EiC but it is from all the contributers, not just me. Thanks, Anand -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at arcnetworks.biz Tue Jun 19 01:38:40 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Tue, 19 Jun 2007 07:08:40 +0530 Subject: Our SCM In-Reply-To: <1182210813.13047.106.camel@localhost.localdomain> References: <4676D585.1030706@redhat.com> <1182210813.13047.106.camel@localhost.localdomain> Message-ID: <5d66540b0706181838g6a71f6d6t5bbc6c18e90c0701@mail.gmail.com> There is some nice stuff on the wiki about this https://fedoraproject.org/wiki/Infrastructure/VersionControl/ It has the pros/cons of CVS, Subversion, Mercurial, Bazaar-ng, and git, also what we need in a system. From dennis at ausil.us Tue Jun 19 02:42:56 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 18 Jun 2007 21:42:56 -0500 Subject: Fedora Magazine RFR In-Reply-To: <4676C7C7.4090000@redhat.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> <4676C7C7.4090000@redhat.com> Message-ID: <200706182142.57255.dennis@ausil.us> Once upon a time Monday 18 June 2007, Mike McGrath wrote: > Anand Capur wrote: > > I already did, but i'd be happy to remove it (group). A xen instance > > sounds > > good (I am experienced with all the command line/ssh stuff, so I wouldn't > > need much help). I plan on using the group for tracking, and to ensure > > that > > the cla_done group is completed by the contributers (it is a magazine > > that > > will be under a no-copyright, so as the wiki needs we would need that > > agreement signed also). > > I'm extremely surprised and worried that you could create a FAS group... > (not your fault). I'd like to hear what others think about this > proposal. Also, right now is it just you doing the work or do you have > an interested team and support group? As am I. Does someone have some time to look at the code for accounts system so we can better define who can create a new group. > > I will be providing it in multiple formats, not only > > flash. Flash would just enhance the viewing experience, but in NO way > > would > > be required!!! > > I think many would argue that if it doesn't work with a default fedora > install, we shouldn't use it. Fedora as an organization values > freedom... as well as stable FireFox installs ;-) I would say you cant use flash at all as we cant provide a way to view the content Dennis From admin at arcnetworks.biz Tue Jun 19 02:51:06 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Tue, 19 Jun 2007 08:21:06 +0530 Subject: Fedora Magazine RFR In-Reply-To: <200706182142.57255.dennis@ausil.us> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> <4676C7C7.4090000@redhat.com> <200706182142.57255.dennis@ausil.us> Message-ID: <5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com> I can look at the code, but I don't know where it is. Last I read it was on an internal redhat server. And I have no problem using NO FLASH! From ssrat at ticon.net Tue Jun 19 05:37:06 2007 From: ssrat at ticon.net (David Douthitt) Date: Tue, 19 Jun 2007 00:37:06 -0500 Subject: Our SCM In-Reply-To: <5d66540b0706181838g6a71f6d6t5bbc6c18e90c0701@mail.gmail.com> References: <4676D585.1030706@redhat.com> <1182210813.13047.106.camel@localhost.localdomain> <5d66540b0706181838g6a71f6d6t5bbc6c18e90c0701@mail.gmail.com> Message-ID: <46776B82.6090102@ticon.net> Anand Capur wrote: > It has the pros/cons of CVS, Subversion, Mercurial, Bazaar-ng, and > git, also what we need in a system. I vote for Subversion - just from the standpoint that many people will know how to use it, and supporting it will be easier and finding people to support it will be just as easy. One note: never saw GNU Arch suggested.... not that I can help any, but there seems to be a substantial amount of support for it from the GNU project. Minor (off-topic) rant: GIT has been the GNU Interactive Tools ( http://www.hulubei.net/tudor/git/ ) for a long time before a certain kernel maintainer decided to misappropriate the name..... But I'm no doubt spitting into the wind anyhow... (sigh). -- UNIX System Administrator Linux+, SCSA, RHCE, LPIC-1 HP-UX, Linux, Solaris, FreeBSD Books: "Advanced System Administration" and "GNU Screen: A Comprehensive Introduction" http://www.lulu.com/ssrat From kanarip at kanarip.com Tue Jun 19 10:40:52 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 19 Jun 2007 12:40:52 +0200 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706181037w1e476057s6a08996eaf9dc1f0@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676B67F.4000804@redhat.com> <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> <4676C102.7020901@redhat.com> <5d66540b0706181037w1e476057s6a08996eaf9dc1f0@mail.gmail.com> Message-ID: <4677B2B4.5040300@kanarip.com> Anand Capur wrote: > I understand, it will be for my egroupware installation, and maby joomla > cms if needed. The good thing is both are quite secure when installed > properly. Here is the reccomended config for egroupware. (It printed > this on my home comp). And yes we need a completely separate domain. eGroupware and joomla have not been packaged for Fedora, have they? Just my ? 0,02 Kind regards, Jeroen van Meeuwen -kanarip From admin at arcnetworks.biz Tue Jun 19 10:53:17 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Tue, 19 Jun 2007 16:23:17 +0530 Subject: Fedora Magazine RFR In-Reply-To: <4677B2B4.5040300@kanarip.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676B67F.4000804@redhat.com> <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> <4676C102.7020901@redhat.com> <5d66540b0706181037w1e476057s6a08996eaf9dc1f0@mail.gmail.com> <4677B2B4.5040300@kanarip.com> Message-ID: <5d66540b0706190353k785ae988xf5de304d42da7fe4@mail.gmail.com> They are PHP Scripts and don't need to be "packaged". They will run on Mac, Windows, Linux if you have a PHP interpreter. eGroupware does have a package, but that is for installation of perfect image. From jeff at ocjtech.us Tue Jun 19 12:06:51 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 19 Jun 2007 07:06:51 -0500 Subject: Our SCM In-Reply-To: <46776B82.6090102@ticon.net> References: <4676D585.1030706@redhat.com> <1182210813.13047.106.camel@localhost.localdomain> <5d66540b0706181838g6a71f6d6t5bbc6c18e90c0701@mail.gmail.com> <46776B82.6090102@ticon.net> Message-ID: <1182254811.4873.5.camel@lt21223.campus.dmacc.edu> On Tue, 2007-06-19 at 00:37 -0500, David Douthitt wrote: > Anand Capur wrote: > > It has the pros/cons of CVS, Subversion, Mercurial, Bazaar-ng, and > > git, also what we need in a system. > I vote for Subversion - just from the standpoint that many people will > know how to use it, and supporting it will be easier and finding people > to support it will be just as easy. Unfortunately, Subversion has two of the flaws that CVS has: 1) Merging is hard. 2) It's requires a centralized model of development that splits people into "committers" and everyone else. Non-committers have a much more difficult time contributing. Using a distributed SCM makes it much easier for people without write access to the main repository to contribute. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dennis at ausil.us Tue Jun 19 12:11:19 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 19 Jun 2007 07:11:19 -0500 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706190353k785ae988xf5de304d42da7fe4@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4677B2B4.5040300@kanarip.com> <5d66540b0706190353k785ae988xf5de304d42da7fe4@mail.gmail.com> Message-ID: <200706190711.20311.dennis@ausil.us> Once upon a time Tuesday 19 June 2007, Anand Capur wrote: > They are PHP Scripts and don't need to be "packaged". They will run on > Mac, Windows, Linux if you have a PHP interpreter. eGroupware does > have a package, but that is for installation of perfect image. We have a policy in Fedora that we can only use software that is packaged and in Fedora. for you to use them you would have to have them pass review first. This is to make sure that what we use is given back to the greater Fedora Community. Dennis From admin at arcnetworks.biz Tue Jun 19 12:18:44 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Tue, 19 Jun 2007 17:48:44 +0530 Subject: Fedora Magazine RFR In-Reply-To: <200706190711.20311.dennis@ausil.us> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4677B2B4.5040300@kanarip.com> <5d66540b0706190353k785ae988xf5de304d42da7fe4@mail.gmail.com> <200706190711.20311.dennis@ausil.us> Message-ID: <5d66540b0706190518k4dfa9fd8pf6fa333e9fdbd055@mail.gmail.com> So is our wiki packaged in fedora? Is our account system packaged in fedora? From couf at skynet.be Tue Jun 19 12:23:26 2007 From: couf at skynet.be (Bart Couvreur) Date: Tue, 19 Jun 2007 14:23:26 +0200 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706190518k4dfa9fd8pf6fa333e9fdbd055@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4677B2B4.5040300@kanarip.com> <5d66540b0706190353k785ae988xf5de304d42da7fe4@mail.gmail.com> <200706190711.20311.dennis@ausil.us> <5d66540b0706190518k4dfa9fd8pf6fa333e9fdbd055@mail.gmail.com> Message-ID: <1182255806.5016.2.camel@localhost.localdomain> Op dinsdag 19-06-2007 om 17:48 uur [tijdzone +0530], schreef Anand Capur: > So is our wiki packaged in fedora? Is our account system packaged in fedora? The wiki is, it's the moin package, account system not for what it's worth. But look at other PHP-stuff: gallery is packaged (along with a whole bunch of add-ons), phpMyAdmin, phpLdapAdmin, ... If you want to use, get it packaged Just my 2 ct Bart -- Bart key fingerprint: 6AAB 544D 3432 D013 776D 3602 ADB6 6B2A D93F 0F93 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dit berichtdeel is digitaal ondertekend URL: From admin at arcnetworks.biz Tue Jun 19 12:26:32 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Tue, 19 Jun 2007 17:56:32 +0530 Subject: Fedora Magazine RFR In-Reply-To: <1182255806.5016.2.camel@localhost.localdomain> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4677B2B4.5040300@kanarip.com> <5d66540b0706190353k785ae988xf5de304d42da7fe4@mail.gmail.com> <200706190711.20311.dennis@ausil.us> <5d66540b0706190518k4dfa9fd8pf6fa333e9fdbd055@mail.gmail.com> <1182255806.5016.2.camel@localhost.localdomain> Message-ID: <5d66540b0706190526l1282305dva8cac183f40da243@mail.gmail.com> Ok, well I'll get it packaged then :)! I'm only gonna use eGroupware From kanarip at kanarip.com Tue Jun 19 12:30:32 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 19 Jun 2007 14:30:32 +0200 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706190518k4dfa9fd8pf6fa333e9fdbd055@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4677B2B4.5040300@kanarip.com> <5d66540b0706190353k785ae988xf5de304d42da7fe4@mail.gmail.com> <200706190711.20311.dennis@ausil.us> <5d66540b0706190518k4dfa9fd8pf6fa333e9fdbd055@mail.gmail.com> Message-ID: <4677CC68.6070407@kanarip.com> Anand Capur wrote: > So is our wiki packaged in fedora? Is our account system packaged in > fedora? > It's kinda difficult to see what you are replying to every time you delete the previous message from your reply... Both mediawiki (simple) and moinmoin (fedoraproject.org) are packaged for Fedora. What components make up our complete account system, I don't know. Kind regards, Jeroen van Meeuwen -kanarip From dennis at ausil.us Tue Jun 19 12:55:25 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 19 Jun 2007 07:55:25 -0500 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706190518k4dfa9fd8pf6fa333e9fdbd055@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <200706190711.20311.dennis@ausil.us> <5d66540b0706190518k4dfa9fd8pf6fa333e9fdbd055@mail.gmail.com> Message-ID: <200706190755.25947.dennis@ausil.us> Once upon a time Tuesday 19 June 2007, Anand Capur wrote: > So is our wiki packaged in fedora? Is our account system packaged in > fedora? wiki is account system lives in public cvs. the account system is an exception it is some custom scripts that really are not usefull to anyone else. but if someone thinks it would be useful they are free to use it. Dennis From admin at arcnetworks.biz Tue Jun 19 13:00:53 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Tue, 19 Jun 2007 18:30:53 +0530 Subject: Fedora Magazine RFR In-Reply-To: <200706190755.25947.dennis@ausil.us> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <200706190711.20311.dennis@ausil.us> <5d66540b0706190518k4dfa9fd8pf6fa333e9fdbd055@mail.gmail.com> <200706190755.25947.dennis@ausil.us> Message-ID: <5d66540b0706190600i5378d45bub5eb65c7aa61c414@mail.gmail.com> > > So is our wiki packaged in fedora? Is our account system packaged in > > fedora? > wiki is account system lives in public cvs. the account system is an > exception it is some custom scripts that really are not usefull to anyone > else. but if someone thinks it would be useful they are free to use it. > > Dennis Ok, I'll get it packaged then use it :), where is the Account System? I read on the wiki that it was on an internal redhat cvs server. From dennis at ausil.us Tue Jun 19 13:10:15 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 19 Jun 2007 08:10:15 -0500 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706190600i5378d45bub5eb65c7aa61c414@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <200706190755.25947.dennis@ausil.us> <5d66540b0706190600i5378d45bub5eb65c7aa61c414@mail.gmail.com> Message-ID: <200706190810.15475.dennis@ausil.us> Once upon a time Tuesday 19 June 2007, Anand Capur wrote: > > > So is our wiki packaged in fedora? Is our account system packaged in > > > fedora? > > > > wiki is account system lives in public cvs. the account system is an > > exception it is some custom scripts that really are not usefull to > > anyone else. but if someone thinks it would be useful they are free to > > use it. > > > > Dennis > > Ok, I'll get it packaged then use it :), where is the Account System? > I read on the wiki that it was on an internal redhat cvs server. http://cvs.fedora.redhat.com/viewcvs/fedora-accounts/?root=fedora From admin at arcnetworks.biz Tue Jun 19 13:11:26 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Tue, 19 Jun 2007 18:41:26 +0530 Subject: Fedora Magazine RFR In-Reply-To: <200706190810.15475.dennis@ausil.us> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <200706190755.25947.dennis@ausil.us> <5d66540b0706190600i5378d45bub5eb65c7aa61c414@mail.gmail.com> <200706190810.15475.dennis@ausil.us> Message-ID: <5d66540b0706190611w7fbb22fcta447b6068c52a2ef@mail.gmail.com> > http://cvs.fedora.redhat.com/viewcvs/fedora-accounts/?root=fedora Thanks! From blizzard at redhat.com Tue Jun 19 13:30:10 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 19 Jun 2007 09:30:10 -0400 Subject: Our SCM In-Reply-To: <1182210813.13047.106.camel@localhost.localdomain> References: <4676D585.1030706@redhat.com> <1182210813.13047.106.camel@localhost.localdomain> Message-ID: <1182259811.3093.24.camel@localhost.localdomain> Before you guys descend into a discussion of specific SCMs can you talk about what the goals are for what you want to do? Mike touched on them but I think that it needs more discussion before you talk about what you love/hate about specific tools. --Chris From admin at arcnetworks.biz Tue Jun 19 13:41:41 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Tue, 19 Jun 2007 19:11:41 +0530 Subject: Our SCM In-Reply-To: <1182259811.3093.24.camel@localhost.localdomain> References: <4676D585.1030706@redhat.com> <1182210813.13047.106.camel@localhost.localdomain> <1182259811.3093.24.camel@localhost.localdomain> Message-ID: <5d66540b0706190641s33f93161k76f1d29d53c6146b@mail.gmail.com> > Before you guys descend into a discussion of specific SCMs can you talk > about what the goals are for what you want to do? Mike touched on them > but I think that it needs more discussion before you talk about what you > love/hate about specific tools. > > --Chris I'm sure mike will say more, but here. * Unix accounts or certificate based authentication * Access Control Lists of per-package per-branch granularity o Ideally this means per-directory ACL's * ACLs will allow view and commit access to select contributors. o Embargo branches should be on the same server as the normal branches. This is necessary to allow certain upstream developers to work in cooperation with Fedora maintainers. o We need to scale up to hundreds of branches per package in the long run. o Some package/branches would be read-only to most users. o Other package/branches need to be completely hidden from most users. * E-mail notification when changes occur. These notifications must be sent from the server, and it must be not possible for users to bypass. * Distributed SCM allows easy sub-collections of the distribution to be built and tested independently, then the bulk be easily merged back while minimizing effort. * Translations for core packages are right now implemented via cvs.fedora.redhat.com and tied to CVS. More longterm they might also benefit from a more modern version control system. Highly Desirable Abilities: * Ability to check out only a portion of the tree in order to work on only a package, instead of the entire tree. From a.badger at gmail.com Tue Jun 19 15:16:31 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 Jun 2007 08:16:31 -0700 Subject: Our SCM In-Reply-To: <5d66540b0706190641s33f93161k76f1d29d53c6146b@mail.gmail.com> References: <4676D585.1030706@redhat.com> <1182210813.13047.106.camel@localhost.localdomain> <1182259811.3093.24.camel@localhost.localdomain> <5d66540b0706190641s33f93161k76f1d29d53c6146b@mail.gmail.com> Message-ID: <1182266191.29855.26.camel@localhost.localdomain> On Tue, 2007-06-19 at 19:11 +0530, Anand Capur wrote: > > Before you guys descend into a discussion of specific SCMs can you talk > > about what the goals are for what you want to do? Mike touched on them > > but I think that it needs more discussion before you talk about what you > > love/hate about specific tools. > > > > --Chris > I'm sure mike will say more, but here. > * Unix accounts or certificate based authentication > * Access Control Lists of per-package per-branch granularity > o Ideally this means per-directory ACL's > * ACLs will allow view and commit access to select contributors. > o Embargo branches should be on the same server as the > normal branches. This is necessary to allow certain upstream > developers to work in cooperation with Fedora maintainers. > o We need to scale up to hundreds of branches per package in > the long run. > o Some package/branches would be read-only to most users. > o Other package/branches need to be completely hidden from > most users. > * E-mail notification when changes occur. These notifications must > be sent from the server, and it must be not possible for users to > bypass. > * Distributed SCM allows easy sub-collections of the distribution > to be built and tested independently, then the bulk be easily merged > back while minimizing effort. > * Translations for core packages are right now implemented via > cvs.fedora.redhat.com and tied to CVS. More longterm they might also > benefit from a more modern version control system. > > Highly Desirable Abilities: > > * Ability to check out only a portion of the tree in order to work > on only a package, instead of the entire tree. > Unless I totally misread Mike's initial post, this is not about the Packaging SCM but about what SCM we might want for our own projects. In particular, the small projects of a few files each that don't make sense on hosted. Notificationis a high level goal that we would want. But the rest of these goals are more specific to the packaging SCM. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mmcgrath at redhat.com Tue Jun 19 15:32:54 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 19 Jun 2007 10:32:54 -0500 Subject: Our SCM In-Reply-To: <1182266191.29855.26.camel@localhost.localdomain> References: <4676D585.1030706@redhat.com> <1182210813.13047.106.camel@localhost.localdomain> <1182259811.3093.24.camel@localhost.localdomain> <5d66540b0706190641s33f93161k76f1d29d53c6146b@mail.gmail.com> <1182266191.29855.26.camel@localhost.localdomain> Message-ID: <4677F726.3020407@redhat.com> Toshio Kuratomi wrote: > Unless I totally misread Mike's initial post, this is not about the > Packaging SCM but about what SCM we might want for our own projects. In > particular, the small projects of a few files each that don't make sense > on hosted. > > Notificationis a high level goal that we would want. But the rest of > these goals are more specific to the packaging SCM. > Yep, basically I'm looking for a replacement for /cvs/fedora/. It very well may be cvs still but discussions around this stuff is always best. I don't mind our current setup but it badly needs to be re-organized. I'd also like finer acl's. Right now there's over 70 people that have access to everything in /cvs/fedora/ AFAIK, our needs are simple. 1) Modular ACL 2) email notification 3) Tagging 4) Anonymous read/check outs Can anyone think of anything else? -Mike From jkeating at redhat.com Tue Jun 19 20:01:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 19 Jun 2007 16:01:35 -0400 Subject: Our SCM In-Reply-To: <4677F726.3020407@redhat.com> References: <4676D585.1030706@redhat.com> <1182266191.29855.26.camel@localhost.localdomain> <4677F726.3020407@redhat.com> Message-ID: <200706191601.35672.jkeating@redhat.com> On Tuesday 19 June 2007 11:32:54 Mike McGrath wrote: > 1) Modular ACL > 2) email notification > 3) Tagging > 4) Anonymous read/check outs > > > Can anyone think of anything else? 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. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeff at ocjtech.us Tue Jun 19 21:08:58 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 19 Jun 2007 16:08:58 -0500 Subject: Our SCM In-Reply-To: <200706191601.35672.jkeating@redhat.com> References: <4676D585.1030706@redhat.com> <1182266191.29855.26.camel@localhost.localdomain> <4677F726.3020407@redhat.com> <200706191601.35672.jkeating@redhat.com> Message-ID: <1182287338.3936.7.camel@lt21223.campus.dmacc.edu> On Tue, 2007-06-19 at 16:01 -0400, Jesse Keating wrote: > On Tuesday 19 June 2007 11:32:54 Mike McGrath wrote: > > 1) Modular ACL > > 2) email notification > > 3) Tagging > > 4) Anonymous read/check outs > > > > > > Can anyone think of anything else? > > 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. I'd like that as well. I've had the problem on a few occasions of wanting to submit a patch to a project, but Subversion was incapable of producing a patch that would reproduce what I wanted on the maintainer's systems. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From smooge at gmail.com Tue Jun 19 22:32:18 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 19 Jun 2007 16:32:18 -0600 Subject: Our SCM In-Reply-To: <4677F726.3020407@redhat.com> References: <4676D585.1030706@redhat.com> <1182210813.13047.106.camel@localhost.localdomain> <1182259811.3093.24.camel@localhost.localdomain> <5d66540b0706190641s33f93161k76f1d29d53c6146b@mail.gmail.com> <1182266191.29855.26.camel@localhost.localdomain> <4677F726.3020407@redhat.com> Message-ID: <80d7e4090706191532p70c42ab7lcb6b4bb275627998@mail.gmail.com> On 6/19/07, Mike McGrath wrote: > Toshio Kuratomi wrote: > > Unless I totally misread Mike's initial post, this is not about the > > Packaging SCM but about what SCM we might want for our own projects. In > > particular, the small projects of a few files each that don't make sense > > on hosted. > > > > Notificationis a high level goal that we would want. But the rest of > > these goals are more specific to the packaging SCM. > > > > Yep, basically I'm looking for a replacement for /cvs/fedora/. It very > well may be cvs still but discussions around this stuff is always best. > I don't mind our current setup but it badly needs to be re-organized. > I'd also like finer acl's. Right now there's over 70 people that have > access to everything in /cvs/fedora/ > > AFAIK, our needs are simple. > > 1) Modular ACL > 2) email notification > 3) Tagging > 4) Anonymous read/check outs > > 5) Authenticated/authorized commit access. In the case that some disgruntled person from say Black Gag Linux decides to figure out a way to take down the Fedora build system because he got a bad RPM last week. 6) Easily documentable. An SCM might be really cool and have a ton of wizz-bangs but if it cant be documented and duplicated easily by a third party.. it tends towards being a burden for systems administration versus a boon. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mmcgrath at redhat.com Tue Jun 19 23:37:07 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 19 Jun 2007 18:37:07 -0500 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> <4676C7C7.4090000@redhat.com> <200706182142.57255.dennis@ausil.us> <5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com> Message-ID: <467868A3.8070008@redhat.com> Anand Capur wrote: > I can look at the code, but I don't know where it is. Last I read it > was on an internal redhat server. And I have no problem using NO > FLASH! So it sounds like the software you'd like to use have changed quite a bit in the progress of this thread. Please update your RFR with a full list of exactly what packages you need to do this. -Mike From admin at arcnetworks.biz Wed Jun 20 03:37:09 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Wed, 20 Jun 2007 09:07:09 +0530 Subject: Fedora Magazine RFR In-Reply-To: <467868A3.8070008@redhat.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> <4676C7C7.4090000@redhat.com> <200706182142.57255.dennis@ausil.us> <5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com> <467868A3.8070008@redhat.com> Message-ID: <5d66540b0706192037p8efc208n33f82747a330f0f3@mail.gmail.com> > So it sounds like the software you'd like to use have changed quite a > bit in the progress of this thread. Please update your RFR with a full > list of exactly what packages you need to do this. > > -Mike 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 From admin at arcnetworks.biz Wed Jun 20 03:43:21 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Wed, 20 Jun 2007 09:13:21 +0530 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706192037p8efc208n33f82747a330f0f3@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> <4676C7C7.4090000@redhat.com> <200706182142.57255.dennis@ausil.us> <5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com> <467868A3.8070008@redhat.com> <5d66540b0706192037p8efc208n33f82747a330f0f3@mail.gmail.com> Message-ID: <5d66540b0706192043i22046cb7n539c30b18e88f5b1@mail.gmail.com> 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/ From mmcgrath at redhat.com Wed Jun 20 03:53:39 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 19 Jun 2007 22:53:39 -0500 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706192037p8efc208n33f82747a330f0f3@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> <4676C7C7.4090000@redhat.com> <200706182142.57255.dennis@ausil.us> <5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com> <467868A3.8070008@redhat.com> <5d66540b0706192037p8efc208n33f82747a330f0f3@mail.gmail.com> Message-ID: <4678A4C3.3050509@redhat.com> Anand Capur wrote: >> So it sounds like the software you'd like to use have changed quite a >> bit in the progress of this thread. Please update your RFR with a full >> list of exactly what packages you need to do this. >> >> -Mike > eGroupware (which I will package for Fedora if needed). You'll need to get it into Fedora. > * Web Server: Apache 2.2.4 > * PHP 5.2.2 > * Database Server: MySQL 5.0.41 Our production DB MySQL instance will be 5.0.22 that ships with RHEL5 after we upgrade it. > * Mail Server: Postfix > * DNS Server: BIND9 (chrooted) We host DNS already > * FTP Server: pureftpd We don't do ftp > * POP3/IMAP server: Dovecot We do not host email I don't mean to rain on your parade but this is a very lofty goal, I'd recommend working with the docs team and see if you can get some more support, http://fedoraproject.org/wiki/DocsProject/Magazine. If you're going to use eGroupware it'll have to be packaged and approved in Fedora before we can use it in our infrastructure. -Mike From admin at arcnetworks.biz Wed Jun 20 03:58:40 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Wed, 20 Jun 2007 09:28:40 +0530 Subject: Fedora Magazine RFR In-Reply-To: <4678A4C3.3050509@redhat.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> <4676C7C7.4090000@redhat.com> <200706182142.57255.dennis@ausil.us> <5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com> <467868A3.8070008@redhat.com> <5d66540b0706192037p8efc208n33f82747a330f0f3@mail.gmail.com> <4678A4C3.3050509@redhat.com> Message-ID: <5d66540b0706192058y1cdca601ma27b40d06e27f545@mail.gmail.com> > > eGroupware (which I will package for Fedora if needed). > You'll need to get it into Fedora. > > * Web Server: Apache 2.2.4 > > * PHP 5.2.2 > > * Database Server: MySQL 5.0.41 > Our production DB MySQL instance will be 5.0.22 that ships with RHEL5 > after we upgrade it. > > * Mail Server: Postfix > > * DNS Server: BIND9 (chrooted) > We host DNS already > > * FTP Server: pureftpd > We don't do ftp > > * POP3/IMAP server: Dovecot > We do not host email --- Ok, no email is fine, no ftp is fine (I'll use SFTP right?), MySQL 5.0.22 is also fine (it'll be a remote server?). And DNS hosting from you is also fine! From tchung at fedoraproject.org Wed Jun 20 07:25:14 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Wed, 20 Jun 2007 00:25:14 -0700 Subject: URL for Fedora Mirrors Message-ID: <369bce3b0706200025k6a1ccad5sf718c971ea363aad@mail.gmail.com> 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 From tchung at fedoraproject.org Wed Jun 20 07:30:34 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Wed, 20 Jun 2007 00:30:34 -0700 Subject: URL for Fedora Mirrors In-Reply-To: <369bce3b0706200025k6a1ccad5sf718c971ea363aad@mail.gmail.com> References: <369bce3b0706200025k6a1ccad5sf718c971ea363aad@mail.gmail.com> Message-ID: <369bce3b0706200030m3cbf1b3eg7b418bb791e2121b@mail.gmail.com> On 6/20/07, Thomas Chung 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? -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From Matt_Domsch at Dell.com Wed Jun 20 12:19:02 2007 From: Matt_Domsch at Dell.com (Matt_Domsch at Dell.com) Date: Wed, 20 Jun 2007 07:19:02 -0500 Subject: app3 mirrormanager publiclist/ pages horked Message-ID: On Wed, Jun 20, 2007 at 12:30:34AM -0700, Thomas Chung wrote: > On 6/20/07, Thomas Chung 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 From damian.myerscough at gmail.com Wed Jun 20 14:08:04 2007 From: damian.myerscough at gmail.com (Damian Myerscough) Date: Wed, 20 Jun 2007 15:08:04 +0100 Subject: app3 mirrormanager publiclist/ pages horked In-Reply-To: References: Message-ID: <8c9e56490706200708q3200f3b2h155a03da7bbfcddc@mail.gmail.com> Matt, Done. Ill do App4 On 20/06/07, Matt_Domsch at dell.com wrote: > On Wed, Jun 20, 2007 at 12:30:34AM -0700, Thomas Chung wrote: > > On 6/20/07, Thomas Chung 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 at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- Regards, Damian From skvidal at linux.duke.edu Wed Jun 20 14:11:03 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 20 Jun 2007 10:11:03 -0400 Subject: app3 mirrormanager publiclist/ pages horked In-Reply-To: <8c9e56490706200708q3200f3b2h155a03da7bbfcddc@mail.gmail.com> References: <8c9e56490706200708q3200f3b2h155a03da7bbfcddc@mail.gmail.com> Message-ID: <1182348663.4102.9.camel@hodge> 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 From kanarip at kanarip.com Wed Jun 20 16:18:30 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 20 Jun 2007 18:18:30 +0200 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706192043i22046cb7n539c30b18e88f5b1@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> <4676C7C7.4090000@redhat.com> <200706182142.57255.dennis@ausil.us> <5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com> <467868A3.8070008@redhat.com> <5d66540b0706192037p8efc208n33f82747a330f0f3@mail.gmail.com> <5d66540b0706192043i22046cb7n539c30b18e88f5b1@mail.gmail.com> Message-ID: <46795356.5080307@kanarip.com> 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 From admin at arcnetworks.biz Wed Jun 20 16:42:29 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Wed, 20 Jun 2007 22:12:29 +0530 Subject: Fedora Magazine RFR In-Reply-To: <46795356.5080307@kanarip.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> <4676C7C7.4090000@redhat.com> <200706182142.57255.dennis@ausil.us> <5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com> <467868A3.8070008@redhat.com> <5d66540b0706192037p8efc208n33f82747a330f0f3@mail.gmail.com> <5d66540b0706192043i22046cb7n539c30b18e88f5b1@mail.gmail.com> <46795356.5080307@kanarip.com> Message-ID: <5d66540b0706200942y13e4ddhfc95b401cc0b9894@mail.gmail.com> > > 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? From mmcgrath at redhat.com Wed Jun 20 16:49:37 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 20 Jun 2007 11:49:37 -0500 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706200942y13e4ddhfc95b401cc0b9894@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> <4676C7C7.4090000@redhat.com> <200706182142.57255.dennis@ausil.us> <5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com> <467868A3.8070008@redhat.com> <5d66540b0706192037p8efc208n33f82747a330f0f3@mail.gmail.com> <5d66540b0706192043i22046cb7n539c30b18e88f5b1@mail.gmail.com> <46795356.5080307@kanarip.com> <5d66540b0706200942y13e4ddhfc95b401cc0b9894@mail.gmail.com> Message-ID: <46795AA1.7090307@redhat.com> 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 From kwade at redhat.com Wed Jun 20 18:01:21 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 20 Jun 2007 11:01:21 -0700 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676B67F.4000804@redhat.com> <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> <4676C102.7020901@redhat.com> <5d66540b0706181037w1e476057s6a08996eaf9dc1f0@mail.gmail.com> <5d66540b0706181039x16006719p9b9683df5bf6da6b@mail.gmail.com> <4676C57F.3060509@redhat.com> <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> Message-ID: <1182362481.21966.445.camel@erato.phig.org> 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 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From admin at arcnetworks.biz Wed Jun 20 18:05:40 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Wed, 20 Jun 2007 23:35:40 +0530 Subject: Fedora Magazine RFR In-Reply-To: <1182362481.21966.445.camel@erato.phig.org> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676B67F.4000804@redhat.com> <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> <4676C102.7020901@redhat.com> <5d66540b0706181037w1e476057s6a08996eaf9dc1f0@mail.gmail.com> <5d66540b0706181039x16006719p9b9683df5bf6da6b@mail.gmail.com> <4676C57F.3060509@redhat.com> <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> <1182362481.21966.445.camel@erato.phig.org> Message-ID: <5d66540b0706201105h1048483bnc9d6c61bfaccd106@mail.gmail.com> On 6/20/07, Karsten Wade wrote: > > 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 > ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ I mean people are free to use, copy, etc.. the articles and since the CLA is for copyrighted stuff, I guess we wouldn't need it signed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kwade at redhat.com Wed Jun 20 18:06:57 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 20 Jun 2007 11:06:57 -0700 Subject: Fedora Magazine RFR In-Reply-To: <4678A4C3.3050509@redhat.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> <4676C7C7.4090000@redhat.com> <200706182142.57255.dennis@ausil.us> <5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com> <467868A3.8070008@redhat.com> <5d66540b0706192037p8efc208n33f82747a330f0f3@mail.gmail.com> <4678A4C3.3050509@redhat.com> Message-ID: <1182362817.21966.450.camel@erato.phig.org> On Tue, 2007-06-19 at 22:53 -0500, Mike McGrath wrote: > Anand Capur wrote: > >> So it sounds like the software you'd like to use have changed quite a > >> bit in the progress of this thread. Please update your RFR with a full > >> list of exactly what packages you need to do this. > >> > >> -Mike > > eGroupware (which I will package for Fedora if needed). What is eGroupware used for in the magazine? > You'll need to get it into Fedora. > > * Web Server: Apache 2.2.4 > > * PHP 5.2.2 We don't need Joomla or any other PHP CMS. We are using Plone for CMS, it can handle all of what the other ones can. Bonus -- you benefit from the Fedora knowledge and hacking on Plone, versus doing it all yourself. > I don't mean to rain on your parade but this is a very lofty goal, I'd > recommend working with the docs team and see if you can get some more > support, http://fedoraproject.org/wiki/DocsProject/Magazine. Anand has general support for his idea, via f-marketing-l, but he is definitely going a bit in his own direction. This is not necessarily a bad thing -- if he has the energy to grow the contributors and sustain the momentum, we'll all learn a few things. My recommendation is for Fedora Magazine to be a SIG operating within the Fedora News Project. Right now, FWN is the sole output of Fedora News, but that doesn't have to be. So, Fedora Magazine would be a peer output effort. IMHO, an effort needs at least SIG status before it should get precious Infrastructure resources. If we get to the point where Xen instances can be handed out like Halloween candy, then that changes. Right? - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Wed Jun 20 18:08:56 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 20 Jun 2007 11:08:56 -0700 Subject: Fedora Magazine RFR In-Reply-To: <4677CC68.6070407@kanarip.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4677B2B4.5040300@kanarip.com> <5d66540b0706190353k785ae988xf5de304d42da7fe4@mail.gmail.com> <200706190711.20311.dennis@ausil.us> <5d66540b0706190518k4dfa9fd8pf6fa333e9fdbd055@mail.gmail.com> <4677CC68.6070407@kanarip.com> Message-ID: <1182362936.21966.452.camel@erato.phig.org> On Tue, 2007-06-19 at 14:30 +0200, Jeroen van Meeuwen wrote: > Both mediawiki (simple) and moinmoin (fedoraproject.org) are packaged > for Fedora. What components make up our complete account system, I don't > know. FWIW, a magazine (i.e., a serious publication effort) needs a real CMS. A wiki just won't do. Thankfully we have Plone and a growing body of experts, new code, and about to be experienced users. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Wed Jun 20 18:10:33 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 20 Jun 2007 11:10:33 -0700 Subject: URL for Fedora Mirrors In-Reply-To: <369bce3b0706200030m3cbf1b3eg7b418bb791e2121b@mail.gmail.com> References: <369bce3b0706200025k6a1ccad5sf718c971ea363aad@mail.gmail.com> <369bce3b0706200030m3cbf1b3eg7b418bb791e2121b@mail.gmail.com> Message-ID: <1182363033.21966.454.camel@erato.phig.org> 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 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at linux.duke.edu Wed Jun 20 18:18:00 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 20 Jun 2007 14:18:00 -0400 Subject: URL for Fedora Mirrors In-Reply-To: <1182363033.21966.454.camel@erato.phig.org> References: <369bce3b0706200025k6a1ccad5sf718c971ea363aad@mail.gmail.com> <369bce3b0706200030m3cbf1b3eg7b418bb791e2121b@mail.gmail.com> <1182363033.21966.454.camel@erato.phig.org> Message-ID: <1182363480.4102.15.camel@hodge> 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 From kwade at redhat.com Wed Jun 20 18:22:37 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 20 Jun 2007 11:22:37 -0700 Subject: Our SCM In-Reply-To: <200706191601.35672.jkeating@redhat.com> References: <4676D585.1030706@redhat.com> <1182266191.29855.26.camel@localhost.localdomain> <4677F726.3020407@redhat.com> <200706191601.35672.jkeating@redhat.com> Message-ID: <1182363757.21966.463.camel@erato.phig.org> 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 10000x 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. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Wed Jun 20 18:34:12 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 20 Jun 2007 11:34:12 -0700 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706201105h1048483bnc9d6c61bfaccd106@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676B67F.4000804@redhat.com> <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> <4676C102.7020901@redhat.com> <5d66540b0706181037w1e476057s6a08996eaf9dc1f0@mail.gmail.com> <5d66540b0706181039x16006719p9b9683df5bf6da6b@mail.gmail.com> <4676C57F.3060509@redhat.com> <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> <1182362481.21966.445.camel@erato.phig.org> <5d66540b0706201105h1048483bnc9d6c61bfaccd106@mail.gmail.com> Message-ID: <1182364452.21966.475.camel@erato.phig.org> On Wed, 2007-06-20 at 23:35 +0530, Anand Capur wrote: > I mean people are free to use, copy, etc.. the articles and since the > CLA is for copyrighted stuff, I guess we wouldn't need it signed. Hmm. I don't want to take this too far off the path, and it's certainly off-topic for this list. Hopefully I can clear this up with a single post. There are a few things to keep in mind: * At least in the US, copyright exists the moment you create a work. This means you have to actively choose to _give_up_ your copyright. For Fedora Magazine to do that, it would have to have a legal notice that it was all public domain, etc. * Fedora cannot take contributions into anything we (re)distribute that do not come from a person who has signed the CLA. So, I can take a patch from a non-CLA person, but when that patch goes into a package, it is done by me (a CLA person). Same with a fix for content from someone who emails me that "such and so" is incorrect in a doc. These are not anywhere official yet, but they are approved by legal counsel: http://fedoraproject.org/wiki/KarstenWade/Drafts/CLAAcceptanceHierarchies If content goes into something we distribute, whether in an ISO or HTML file, it has to be under the CLA. A click-through CLA is sufficient for content that is Web-only. * The way Fedora achieves the goal you lay out for people to be "free to use, copy, etc." the content that comes from Fedora Magazine is to license that content. Same as we do with source code. Thus, Fedora Magazine would be under the OPL (most likely), but we could look into the possibility of using the CC BY-SA. Clear as mud? :) - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From admin at arcnetworks.biz Wed Jun 20 18:13:05 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Wed, 20 Jun 2007 23:43:05 +0530 Subject: Fedora Magazine RFR In-Reply-To: <1182362817.21966.450.camel@erato.phig.org> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> <4676C7C7.4090000@redhat.com> <200706182142.57255.dennis@ausil.us> <5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com> <467868A3.8070008@redhat.com> <5d66540b0706192037p8efc208n33f82747a330f0f3@mail.gmail.com> <4678A4C3.3050509@redhat.com> <1182362817.21966.450.camel@erato.phig.org> Message-ID: <5d66540b0706201113s6245a4c5sb9c3e7eefd4001de@mail.gmail.com> On 6/20/07, Karsten Wade wrote: > > On Tue, 2007-06-19 at 22:53 -0500, Mike McGrath wrote: > > Anand Capur wrote: > > >> So it sounds like the software you'd like to use have changed quite a > > >> bit in the progress of this thread. Please update your RFR with a > full > > >> list of exactly what packages you need to do this. > > >> > > >> -Mike > > > eGroupware (which I will package for Fedora if needed). > > What is eGroupware used for in the magazine? > > > You'll need to get it into Fedora. > > > * Web Server: Apache 2.2.4 > > > * PHP 5.2.2 > > We don't need Joomla or any other PHP CMS. We are using Plone for CMS, > it can handle all of what the other ones can. Bonus -- you benefit from > the Fedora knowledge and hacking on Plone, versus doing it all yourself. > > > I don't mean to rain on your parade but this is a very lofty goal, I'd > > recommend working with the docs team and see if you can get some more > > support, http://fedoraproject.org/wiki/DocsProject/Magazine. > > Anand has general support for his idea, via f-marketing-l, but he is > definitely going a bit in his own direction. This is not necessarily a > bad thing -- if he has the energy to grow the contributors and sustain > the momentum, we'll all learn a few things. > > My recommendation is for Fedora Magazine to be a SIG operating within > the Fedora News Project. Right now, FWN is the sole output of Fedora > News, but that doesn't have to be. So, Fedora Magazine would be a peer > output effort. > > IMHO, an effort needs at least SIG status before it should get precious > Infrastructure resources. If we get to the point where Xen instances > can be handed out like Halloween candy, then that changes. Right? > > - Karsten > -- > Karsten Wade, 108 Editor ^ Fedora Documentation Project > Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject > quaid.108.redhat.com | gpg key: AD0E0C41 > ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list 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.... -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at arcnetworks.biz Wed Jun 20 18:49:04 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Thu, 21 Jun 2007 00:19:04 +0530 Subject: Fedora Magazine RFR In-Reply-To: <1182364452.21966.475.camel@erato.phig.org> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <5d66540b0706181017s1152860dr90ed5f8eecbb444@mail.gmail.com> <4676C102.7020901@redhat.com> <5d66540b0706181037w1e476057s6a08996eaf9dc1f0@mail.gmail.com> <5d66540b0706181039x16006719p9b9683df5bf6da6b@mail.gmail.com> <4676C57F.3060509@redhat.com> <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> <1182362481.21966.445.camel@erato.phig.org> <5d66540b0706201105h1048483bnc9d6c61bfaccd106@mail.gmail.com> <1182364452.21966.475.camel@erato.phig.org> Message-ID: <5d66540b0706201149h36de5e62t7bd89b6713b64d04@mail.gmail.com> On 6/21/07, Karsten Wade wrote: > > On Wed, 2007-06-20 at 23:35 +0530, Anand Capur wrote: > > > I mean people are free to use, copy, etc.. the articles and since the > > CLA is for copyrighted stuff, I guess we wouldn't need it signed. > > Hmm. I don't want to take this too far off the path, and it's certainly > off-topic for this list. Hopefully I can clear this up with a single > post. > > There are a few things to keep in mind: > > * At least in the US, copyright exists the moment you create a work. > This means you have to actively choose to _give_up_ your copyright. For > Fedora Magazine to do that, it would have to have a legal notice that it > was all public domain, etc. > > * Fedora cannot take contributions into anything we (re)distribute that > do not come from a person who has signed the CLA. So, I can take a > patch from a non-CLA person, but when that patch goes into a package, it > is done by me (a CLA person). Same with a fix for content from someone > who emails me that "such and so" is incorrect in a doc. > > These are not anywhere official yet, but they are approved by legal > counsel: > > http://fedoraproject.org/wiki/KarstenWade/Drafts/CLAAcceptanceHierarchies > > If content goes into something we distribute, whether in an ISO or HTML > file, it has to be under the CLA. A click-through CLA is sufficient for > content that is Web-only. > > * The way Fedora achieves the goal you lay out for people to be "free to > use, copy, etc." the content that comes from Fedora Magazine is to > license that content. Same as we do with source code. Thus, Fedora > Magazine would be under the OPL (most likely), but we could look into > the possibility of using the CC BY-SA. > > Clear as mud? :) > > - Karsten > -- > Karsten Wade, 108 Editor ^ Fedora Documentation Project > Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject > quaid.108.redhat.com | gpg key: AD0E0C41 > ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ Heh, yep clear as mud! Ok, well OPL is fine for me. I just used CC BY-SA as a possibility. Legal issues are always confusing... -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis at ausil.us Wed Jun 20 18:52:56 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 20 Jun 2007 13:52:56 -0500 (CDT) Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706200942y13e4ddhfc95b401cc0b9894@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> <4676C7C7.4090000@redhat.com> <200706182142.57255.dennis@ausil.us> <5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com> <467868A3.8070008@redhat.com> <5d66540b0706192037p8efc208n33f82747a330f0f3@mail.gmail.com> <5d66540b0706192043i22046cb7n539c30b18e88f5b1@mail.gmail.com> <46795356.5080307@kanarip.com> <5d66540b0706200942y13e4ddhfc95b401cc0b9894@mail.gmail.com> Message-ID: <38960.12.163.52.81.1182365576.squirrel@webmail.ausil.us> >> > 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? you don't include php. but you need to make sure that files are put in the correct locations with the correct permissions. you cant just dump it all in /var/www/html/egroupware or something along those lines -- Dennis Gilmore, RHCE From admin at arcnetworks.biz Wed Jun 20 18:55:20 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Thu, 21 Jun 2007 00:25:20 +0530 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706201149h36de5e62t7bd89b6713b64d04@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676C102.7020901@redhat.com> <5d66540b0706181037w1e476057s6a08996eaf9dc1f0@mail.gmail.com> <5d66540b0706181039x16006719p9b9683df5bf6da6b@mail.gmail.com> <4676C57F.3060509@redhat.com> <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> <1182362481.21966.445.camel@erato.phig.org> <5d66540b0706201105h1048483bnc9d6c61bfaccd106@mail.gmail.com> <1182364452.21966.475.camel@erato.phig.org> <5d66540b0706201149h36de5e62t7bd89b6713b64d04@mail.gmail.com> Message-ID: <5d66540b0706201155o5ef6e7desb41252fd2f05739e@mail.gmail.com> Also, if we form a SIG, then we can't use the Fedora name? --From - http://fedoraproject.org/wiki/DefiningProjects A SIG earns official project status through successful accomplishment of objectives that warrant more prominence in the Fedora Project. If contributors request it, the parent project or the Fedora Project Boardwill evaluate the SIG's progress reports and make a determination of readiness for this stage. At this point, it may be branded with the Fedora name and promoted to the full status of a Fedora project. It can join the ranks of the most valuable initiatives currently leading the Fedora Project. -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at arcnetworks.biz Wed Jun 20 18:57:06 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Thu, 21 Jun 2007 00:27:06 +0530 Subject: Fedora Magazine RFR In-Reply-To: <38960.12.163.52.81.1182365576.squirrel@webmail.ausil.us> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676C7C7.4090000@redhat.com> <200706182142.57255.dennis@ausil.us> <5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com> <467868A3.8070008@redhat.com> <5d66540b0706192037p8efc208n33f82747a330f0f3@mail.gmail.com> <5d66540b0706192043i22046cb7n539c30b18e88f5b1@mail.gmail.com> <46795356.5080307@kanarip.com> <5d66540b0706200942y13e4ddhfc95b401cc0b9894@mail.gmail.com> <38960.12.163.52.81.1182365576.squirrel@webmail.ausil.us> Message-ID: <5d66540b0706201157i4bfde5a7ie928abb4f463c186@mail.gmail.com> On 6/21/07, Dennis Gilmore wrote: > > > >> > 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? > > you don't include php. but you need to make sure that files are put in > the correct locations with the correct permissions. you cant just dump it > all in /var/www/html/egroupware or something along those lines > > -- > Dennis Gilmore, RHCE Allright, thanks! Also, do I need to include PHP PEAR extensions that are required? -------------- next part -------------- An HTML attachment was scrubbed... URL: From blizzard at redhat.com Wed Jun 20 19:15:59 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 20 Jun 2007 15:15:59 -0400 Subject: Our SCM In-Reply-To: <1182363757.21966.463.camel@erato.phig.org> References: <4676D585.1030706@redhat.com> <1182266191.29855.26.camel@localhost.localdomain> <4677F726.3020407@redhat.com> <200706191601.35672.jkeating@redhat.com> <1182363757.21966.463.camel@erato.phig.org> Message-ID: <1182366960.3105.15.camel@localhost.localdomain> 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 10000x 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 From Matt_Domsch at dell.com Wed Jun 20 19:32:45 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 20 Jun 2007 14:32:45 -0500 Subject: Our SCM In-Reply-To: <1182366960.3105.15.camel@localhost.localdomain> References: <4676D585.1030706@redhat.com> <1182266191.29855.26.camel@localhost.localdomain> <4677F726.3020407@redhat.com> <200706191601.35672.jkeating@redhat.com> <1182363757.21966.463.camel@erato.phig.org> <1182366960.3105.15.camel@localhost.localdomain> Message-ID: <20070620193245.GA21084@auslistsprd01.us.dell.com> 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 From dennis at ausil.us Wed Jun 20 19:47:23 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 20 Jun 2007 14:47:23 -0500 (CDT) Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706201157i4bfde5a7ie928abb4f463c186@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676C7C7.4090000@redhat.com> <200706182142.57255.dennis@ausil.us> <5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com> <467868A3.8070008@redhat.com> <5d66540b0706192037p8efc208n33f82747a330f0f3@mail.gmail.com> <5d66540b0706192043i22046cb7n539c30b18e88f5b1@mail.gmail.com> <46795356.5080307@kanarip.com> <5d66540b0706200942y13e4ddhfc95b401cc0b9894@mail.gmail.com> <38960.12.163.52.81.1182365576.squirrel@webmail.ausil.us> <5d66540b0706201157i4bfde5a7ie928abb4f463c186@mail.gmail.com> Message-ID: <48503.12.163.52.81.1182368843.squirrel@webmail.ausil.us> > On 6/21/07, Dennis Gilmore 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 From skvidal at linux.duke.edu Wed Jun 20 19:52:23 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 20 Jun 2007 15:52:23 -0400 Subject: Our SCM In-Reply-To: <1182366960.3105.15.camel@localhost.localdomain> References: <4676D585.1030706@redhat.com> <1182266191.29855.26.camel@localhost.localdomain> <4677F726.3020407@redhat.com> <200706191601.35672.jkeating@redhat.com> <1182363757.21966.463.camel@erato.phig.org> <1182366960.3105.15.camel@localhost.localdomain> Message-ID: <1182369143.4102.37.camel@hodge> 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 From mmcgrath at redhat.com Wed Jun 20 19:56:28 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 20 Jun 2007 14:56:28 -0500 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706201113s6245a4c5sb9c3e7eefd4001de@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <5d66540b0706181054i60d63df2qf2a10b4de53ec77f@mail.gmail.com> <4676C7C7.4090000@redhat.com> <200706182142.57255.dennis@ausil.us> <5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com> <467868A3.8070008@redhat.com> <5d66540b0706192037p8efc208n33f82747a330f0f3@mail.gmail.com> <4678A4C3.3050509@redhat.com> <1182362817.21966.450.camel@erato.phig.org> <5d66540b0706201113s6245a4c5sb9c3e7eefd4001de@mail.gmail.com> Message-ID: <4679866C.2090908@redhat.com> 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 From mdehaan at redhat.com Wed Jun 20 20:06:52 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 20 Jun 2007 16:06:52 -0400 Subject: Our SCM In-Reply-To: <1182369143.4102.37.camel@hodge> References: <4676D585.1030706@redhat.com> <1182266191.29855.26.camel@localhost.localdomain> <4677F726.3020407@redhat.com> <200706191601.35672.jkeating@redhat.com> <1182363757.21966.463.camel@erato.phig.org> <1182366960.3105.15.camel@localhost.localdomain> <1182369143.4102.37.camel@hodge> Message-ID: <467988DC.3000709@redhat.com> 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 From skvidal at linux.duke.edu Wed Jun 20 20:13:03 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 20 Jun 2007 16:13:03 -0400 Subject: Our SCM In-Reply-To: <467988DC.3000709@redhat.com> References: <4676D585.1030706@redhat.com> <1182266191.29855.26.camel@localhost.localdomain> <4677F726.3020407@redhat.com> <200706191601.35672.jkeating@redhat.com> <1182363757.21966.463.camel@erato.phig.org> <1182366960.3105.15.camel@localhost.localdomain> <1182369143.4102.37.camel@hodge> <467988DC.3000709@redhat.com> Message-ID: <1182370383.4102.47.camel@hodge> On Wed, 2007-06-20 at 16:06 -0400, Michael DeHaan wrote: > 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. but things can go away 'forever' and we still want them around. 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. In short, we have to have everything local otherwise we'll be exchanging one set of problems for larger, more intractable ones. (ie: legal ones and general confusion-of-location) > > 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. and dangerous and possibly against 'the rules'. > 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. 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. -sv From mdehaan at redhat.com Wed Jun 20 20:29:22 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 20 Jun 2007 16:29:22 -0400 Subject: Our SCM In-Reply-To: <1182370383.4102.47.camel@hodge> References: <4676D585.1030706@redhat.com> <1182266191.29855.26.camel@localhost.localdomain> <4677F726.3020407@redhat.com> <200706191601.35672.jkeating@redhat.com> <1182363757.21966.463.camel@erato.phig.org> <1182366960.3105.15.camel@localhost.localdomain> <1182369143.4102.37.camel@hodge> <467988DC.3000709@redhat.com> <1182370383.4102.47.camel@hodge> Message-ID: <46798E22.9050602@redhat.com> 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 at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From mmcgrath at redhat.com Wed Jun 20 20:31:47 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 20 Jun 2007 15:31:47 -0500 Subject: Our SCM In-Reply-To: <1182363757.21966.463.camel@erato.phig.org> References: <4676D585.1030706@redhat.com> <1182266191.29855.26.camel@localhost.localdomain> <4677F726.3020407@redhat.com> <200706191601.35672.jkeating@redhat.com> <1182363757.21966.463.camel@erato.phig.org> Message-ID: <46798EB3.50600@redhat.com> 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 10000x 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. > > > :) I think this thread took a spin away from the Infrastructure SCM and on to something else. -Mike From smooge at gmail.com Wed Jun 20 23:40:11 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 20 Jun 2007 17:40:11 -0600 Subject: Our SCM In-Reply-To: <1182370383.4102.47.camel@hodge> References: <4676D585.1030706@redhat.com> <1182266191.29855.26.camel@localhost.localdomain> <4677F726.3020407@redhat.com> <200706191601.35672.jkeating@redhat.com> <1182363757.21966.463.camel@erato.phig.org> <1182366960.3105.15.camel@localhost.localdomain> <1182369143.4102.37.camel@hodge> <467988DC.3000709@redhat.com> <1182370383.4102.47.camel@hodge> Message-ID: <80d7e4090706201640s4f6170eamb4a7597939536c96@mail.gmail.com> On 6/20/07, seth vidal wrote: > On Wed, 2007-06-20 at 16:06 -0400, Michael DeHaan wrote: > > 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. > > but things can go away 'forever' and we still want them around. > > 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. > > In short, we have to have everything local otherwise we'll be exchanging > one set of problems for larger, more intractable ones. (ie: legal ones > and general confusion-of-location) > Yeah... I kept running into issues like: Upstream changes SCM (often) Upstream forks.. No SCM (Tarballs baby... just like our lord Volkerding wants) No sane SCM (Distributed SCCS) No open/usable SCM (Distributed SCCS using bittorrent) Legal fork issues (mp3 code, patented one-clikc method, etc :) CLA issues (there has got to be someway the CLA will get in the way somewhere :)). With a couple hundred packages this might be surmountable.. with tens of thousands of packages? Maybe we can get our new Google Overlords to solve this problem with Google Forge? -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From tchung at fedoraproject.org Thu Jun 21 00:04:52 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Wed, 20 Jun 2007 17:04:52 -0700 Subject: URL for Fedora Mirrors In-Reply-To: <1182363480.4102.15.camel@hodge> References: <369bce3b0706200025k6a1ccad5sf718c971ea363aad@mail.gmail.com> <369bce3b0706200030m3cbf1b3eg7b418bb791e2121b@mail.gmail.com> <1182363033.21966.454.camel@erato.phig.org> <1182363480.4102.15.camel@hodge> Message-ID: <369bce3b0706201704t4e98a261o2ca002019a2cf072@mail.gmail.com> On 6/20/07, seth vidal 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 From paulo.banon at googlemail.com Thu Jun 21 01:14:14 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Thu, 21 Jun 2007 03:14:14 +0200 Subject: Our SCM In-Reply-To: <46798EB3.50600@redhat.com> References: <4676D585.1030706@redhat.com> <1182266191.29855.26.camel@localhost.localdomain> <4677F726.3020407@redhat.com> <200706191601.35672.jkeating@redhat.com> <1182363757.21966.463.camel@erato.phig.org> <46798EB3.50600@redhat.com> Message-ID: <7a41c4bc0706201814x2d77f877pc44fd1c21b384a67@mail.gmail.com> 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 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 10000x 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. > > > > > > > :) 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 at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From blizzard at redhat.com Thu Jun 21 01:19:46 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 20 Jun 2007 21:19:46 -0400 Subject: Our SCM In-Reply-To: <1182369143.4102.37.camel@hodge> References: <4676D585.1030706@redhat.com> <1182266191.29855.26.camel@localhost.localdomain> <4677F726.3020407@redhat.com> <200706191601.35672.jkeating@redhat.com> <1182363757.21966.463.camel@erato.phig.org> <1182366960.3105.15.camel@localhost.localdomain> <1182369143.4102.37.camel@hodge> Message-ID: <1182388786.2826.15.camel@localhost.localdomain> 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 From blizzard at redhat.com Thu Jun 21 01:20:55 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 20 Jun 2007 21:20:55 -0400 Subject: Our SCM In-Reply-To: <467988DC.3000709@redhat.com> References: <4676D585.1030706@redhat.com> <1182266191.29855.26.camel@localhost.localdomain> <4677F726.3020407@redhat.com> <200706191601.35672.jkeating@redhat.com> <1182363757.21966.463.camel@erato.phig.org> <1182366960.3105.15.camel@localhost.localdomain> <1182369143.4102.37.camel@hodge> <467988DC.3000709@redhat.com> Message-ID: <1182388855.2826.17.camel@localhost.localdomain> 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 From jeff at ocjtech.us Thu Jun 21 02:52:26 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 20 Jun 2007 21:52:26 -0500 Subject: Our SCM In-Reply-To: <1182388855.2826.17.camel@localhost.localdomain> References: <4676D585.1030706@redhat.com> <1182266191.29855.26.camel@localhost.localdomain> <4677F726.3020407@redhat.com> <200706191601.35672.jkeating@redhat.com> <1182363757.21966.463.camel@erato.phig.org> <1182366960.3105.15.camel@localhost.localdomain> <1182369143.4102.37.camel@hodge> <467988DC.3000709@redhat.com> <1182388855.2826.17.camel@localhost.localdomain> Message-ID: <1182394346.3677.2.camel@lt21223.campus.dmacc.edu> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From admin at arcnetworks.biz Thu Jun 21 04:23:16 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Thu, 21 Jun 2007 09:53:16 +0530 Subject: Fedora Magazine RFR In-Reply-To: <4679866C.2090908@redhat.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <4676C7C7.4090000@redhat.com> <200706182142.57255.dennis@ausil.us> <5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com> <467868A3.8070008@redhat.com> <5d66540b0706192037p8efc208n33f82747a330f0f3@mail.gmail.com> <4678A4C3.3050509@redhat.com> <1182362817.21966.450.camel@erato.phig.org> <5d66540b0706201113s6245a4c5sb9c3e7eefd4001de@mail.gmail.com> <4679866C.2090908@redhat.com> Message-ID: <5d66540b0706202123i7634b041l355939b19cb25667@mail.gmail.com> On 6/21/07, Mike McGrath wrote: > > 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 I already am working with FWN and Thomas :). The plan is to include FWN articles in the magazine ;). And I'm not a "Fly by night" person, I didn't just "show" up, i've been an ambassador for a long time (at least 1-2 years). -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandon.jasper at navy.mil Thu Jun 21 19:40:46 2007 From: brandon.jasper at navy.mil (Jasper, Brandon R CTN2 NSSC BANGOR WA, NSSC Bangor N621) Date: Thu, 21 Jun 2007 12:40:46 -0700 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706202123i7634b041l355939b19cb25667@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com><4676C7C7.4090000@redhat.com> <200706182142.57255.dennis@ausil.us><5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com><467868A3.8070008@redhat.com><5d66540b0706192037p8efc208n33f82747a330f0f3@mail.gmail.com><4678A4C3.3050509@redhat.com><1182362817.21966.450.camel@erato.phig.org><5d66540b0706201113s6245a4c5sb9c3e7eefd4001de@mail.gmail.com><4679866C.2090908@redhat.com> <5d66540b0706202123i7634b041l355939b19cb25667@mail.gmail.com> Message-ID: -----Original Message----- From: fedora-infrastructure-list-bounces at redhat.com [mailto:fedora-infrastructure-list-bounces at redhat.com] On Behalf Of Anand Capur Sent: Wednesday, June 20, 2007 21:23 To: fedora-infrastructure-list at redhat.com Subject: Re: Fedora Magazine RFR On 6/21/07, Mike McGrath wrote: 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 I already am working with FWN and Thomas :). The plan is to include FWN articles in the magazine ;). And I'm not a "Fly by night" person, I didn't just "show" up, i've been an ambassador for a long time (at least 1-2 years). ------------------------------------------------------------------ Well I've had my own job to take care of but I've been keeping up with the list. I can't tell you how much of a pain it is to try to send a file update to a unit over a 2.4kbs satellite channel particularly when they can't stay at periscope depth for any period of time to download a 4mb file... Had to break it up into a lot of very small zip files. I do like the idea of a Fedora magazine but I'm afraid it could just fall into the multitude of ezines out there like some projects I've seen. It seems like the focus right now is on a dedicated infrastructure for a magazine that doesn't exist yet. I for one would worry less about that and more about the whole magazine issue itself. I don't think it's set in yet about how much work goes into producing a magazine. I think the more logical step would be to build a team and actually see if you can pull off producing a few issues and then break off to it's own website once it's established. I've seen more than a few ezine projects die after an issue or two and it seems like a huge waste in man-hours to set up everything before that. Start it off with FWN and then worry about the rest later. ------- Brandon Jasper, CTN2(SS) NSSC Bangor N621 Afloat LAN Admin. SIPRNET: brandon.jasper at navy.smil.mil -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4962 bytes Desc: not available URL: From jeff at ocjtech.us Thu Jun 21 21:04:01 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Thu, 21 Jun 2007 16:04:01 -0500 Subject: Fedora Infrastructure IRC Meeting Log from 2007-06-21 Message-ID: <1182459841.4031.53.camel@lt21223.campus.dmacc.edu> [15:01] mmcgrath has set the subject to Fedora Infrastructure -- Who's here? [15:01] mmcgrath: Alrighty everyone. Who's here? [15:01] * abadger1999 is here [15:01] * skvidal is here [15:01] * xDamox is here [15:01] abadger1999 has left ( (n=abadger1 at 136.245.4.252)) [15:01] abadger1999 has joined the group chat (n=abadger1 at 136.245.4.252) [15:02] mmcgrath: dgilmore: f13: ping? [15:02] * G is reattached [15:02] mmcgrath: Allrighty, lets get started. [15:02] jcollie: here! [15:02] mmcgrath has set the subject to Package Database -- abadger1999 [15:02] * riczho listens again. [15:02] mmcgrath: jcollie: yo [15:02] f13: here [15:02] f13: battling rawhide still [15:02] notting has joined the group chat (n=notting at redhat/notting) [15:03] abadger1999: We're close [15:03] abadger1999: I have the importer almost done. [15:03] abadger1999: Had a late feature request from jeremy that I'm working on now. [15:03] * rordway is here for once [15:03] abadger1999: bz-sync is ~ half done. [15:03] jcollie: i think that we should all pitch in to buy f13 some authentic leather chaps for when he's dealing with rawhide [15:03] * jeremy is nothing but a trouble maker [15:03] mmcgrath: abadger1999: if you get sucked into feature creep, don't forget you can say no [15:03] abadger1999: warren hasn't had a chance to work on the koji sync so I may have to pick that up. [15:04] mmcgrath: well for now anyway [15:04] mmcgrath: abadger1999: so all in all you think we're in good shape? [15:04] f13: wow. [15:04] abadger1999: And I need to work out exactly what scripts need to be ported for new packages and package branches. [15:04] abadger1999: That should be it. [15:04] mmcgrath: when do you suspect we'll be able to promote it? [15:04] f13: jcollie: between you and jwb I'm wearing pasties and leather chaps. [15:04] f13: I'm deeply frightened. [15:05] * rordway hides his eyes [15:05] jwb: gah, scary [15:05] abadger1999: I'm hoping we can deploy it for cvsadmins to use next week. [15:05] * skvidal hides his brain [15:05] abadger1999: And then let the public start self-serving afte rthat. [15:05] mmcgrath: excellent. [15:05] mmcgrath: abadger1999: did we get the python-fedora timeout issue figured out? [15:05] abadger1999: Nope. I'm still looking for it. [15:05] craigt has joined the group chat (i=hidden-u at gnat.asiscan.com) [15:06] mmcgrath: k [15:06] mmcgrath: abadger1999: anything else then? [15:06] abadger1999: I know that it's something involved with deep TurboGears stuff. [15:06] abadger1999: But beyond that [15:06] abadger1999: (Session cookie is being lost or something.) [15:06] mmcgrath: [15:06] abadger1999: That's it. [15:06] mmcgrath: cool [15:07] mmcgrath has set the subject to config management -- mmcgrath [15:07] mmcgrath: So puppet (i think) and RHN have started to conflict. [15:07] mmcgrath: I'm looking into it more. [15:07] skvidal: mmcgrath: put in some 'sleep 10' [15:07] mmcgrath: basically we're getting this - http://pastebin.ca/581690 [15:07] mmcgrath: Which I think is a 24 hour period average. [15:08] mmcgrath: something to keep an eye on though. [15:08] mmcgrath has set the subject to VCS choice -- abadger1999/jcollie [15:09] mmcgrath: So the conversation on what Infrastructure should use for its SCM kind of went crazy. Does anyone have any opinions that have not been discussed on the list? [15:09] jcollie: i think we defiitely need to go to a dscm... which one is up for debate [15:09] f13: lets do like puppet [15:09] abadger1999: What about the consolidate small projects into one hosted project idea? [15:09] f13: pick git, run with it. People will deal. [15:09] skvidal: f13: break rhn? [15:10] mmcgrath: abadger1999: thats not a bad idea really. I'd worry about Infrastructure having two homes though. [15:10] abadger1999: Hmm.. That's true. [15:10] mmcgrath: having said that, I'd be up for examining using trac's bug system as a replacement for OTRS. [15:10] * mmcgrath notes that we really haven't picked up and used OTRS. [15:10] f13: Trac does have the concept of a 'task' vs a bug [15:11] f13: well really, it has the concept of whatever kind of ticket we want to teach it [15:11] * dgilmore is here [15:11] jcollie: can trac create new tickets based upon an email? [15:11] * riczho doesn't particularly enjoy OTRS either. [15:11] mmcgrath: f13: the defaults look like "defect" "enhancement" "task" [15:12] mmcgrath: riczho: I think its just a bit of an overkill for what we need. [15:12] f13: jcollie: not sure. Maybe, may require some more advanced setup on the track host [15:12] f13: mmcgrath: yeah, the webadmin tab lets you create/remove ticket types at will. [15:12] mmcgrath: excellent, well lets discuss this then [15:12] jcollie: what about using bugzilla.redhat.com? i know it's the bugtracker we all love to hate but it'll keep things simpler [15:12] f13: or completely remove the ability to have tickets in that particular Trac instance [15:12] G: can't we just use a dumbed down version of Mantis, or a new Bugzilla 'Project'? [15:13] mmcgrath has set the subject to OTRS and a Trac home -- All [15:13] * mdomsch never saw the point of OTRS [15:13] skvidal: G: you shall not mention mantis again [15:13] skvidal: die mantis, die [15:13] fchiulli has joined the group chat (i=824c405d at gateway/web/cgi-irc/ircatwork.com/x-9bbf61f04e289ebb) [15:13] dgilmore: we use RT here [15:13] mmcgrath: mdomsch: well everyone hated bugzilla so it seemed like a good idea at the time [15:13] dgilmore: it seems ok [15:13] skvidal: mmcgrath: yes and now we hate bugzilla and otrs [15:13] G: skvidal: I actually agree, but it was the first that came to mind [15:14] f13: RT is great, until somebody cc's it, and reply-all starts spewing all kinds of duplicate tickets [15:14] mmcgrath: skvidal: the big difference is we don't ignore bugzilla well, not as bad anyway. [15:14] f13: oh and depite what it says, any change to a closed ticket re-opens the ticket, even if you explicitly mark it as stay closed. [15:14] * mmcgrath considers RT and OTRS to be identical in respect to our needs. [15:14] skvidal: I'm going to suggest something [15:14] skvidal: and I want everyone to remain calm [15:14] dgilmore: lah lah lah [15:14] G: One of the requirements is that the bugsystem can handle reports via email right? [15:15] skvidal: what if we just have a mailing list [15:15] skvidal: and if the task takes more than 10 minutes [15:15] skvidal: WE file it [15:15] skvidal: it's not like we're being inundated with requests [15:15] dgilmore: skvidal: sure but not everything in ORTS is handled by us [15:15] skvidal: at least, I don't seem to see thousands of them [15:15] skvidal: dgilmore: yes, that's why we file it for others [15:15] mmcgrath: skvidal: I'd still like to know who's working on what and such. [15:16] skvidal: mmcgrath: sure, if it is quick you email saying 'got it' [15:16] f13: I don't either. I'm not a huge fan of using a mailing list as a task tracking system, but... [15:16] mmcgrath: I think we need something, but far more light weight then OTRS. [15:16] skvidal: and you do it [15:16] skvidal: like I said - mailing list just lets us know about the problem [15:16] skvidal: and if the problem really requires a ticket then file it [15:16] f13: we'd have to allow posting by non-members [15:16] skvidal: in bugzilla or trac or whatever [15:16] f13: and then deal with the spam [15:16] skvidal: f13: as opposed to now? [15:16] f13: wereas anybody with a fedora account can create a ticket in Trac [15:17] skvidal: f13: which is vastly superior to get otrs spam [15:17] f13: skvidal: well yeah, now sucks big time. [15:17] skvidal: f13: right [15:17] riczho: We get a ton of spam in OTRS now already. [15:17] mmcgrath: riczho: actually we don't, it used to be between 10 and 20 a day. [15:17] G: doesn't KDE have a patch to bugzilla which allows it to accept bug reports filed by email? [15:17] f13: Trac would kill the spam, but lose the email handynes [15:17] mmcgrath: the sytem we have in place now isn't great but its better than it could be [15:17] riczho: mmcgrath: Woah, never mind, then. [15:17] fchiulli has left ( (i=824c405d at gateway/web/cgi-irc/ircatwork.com/x-9bbf61f04e289ebb)) [15:18] mmcgrath: we should take this to the list and see what they say. [15:18] * G thinks RH IS wouldn't be very happy though [15:18] mmcgrath: skvidal: are you saying a separate list? [15:18] abadger1999: I don't mind losing the email-to-open-ticket ability. [15:18] skvidal: mmcgrath: yes [15:18] skvidal: mmcgrath: shit-is-broken at fedoraproject.org [15:18] skvidal: (kidding, of course) [15:18] mmcgrath: skvidal: here's my question, where do I go to find what hasn't been done? [15:18] skvidal: I was thinking one of two things [15:18] mmcgrath: like, I wake up, I've got 2 hours to kill, where do I go to find a list of stuff I need to do? [15:19] mmcgrath: err a list of stuff that needs to be done. [15:19] skvidal: your inbox? [15:19] dgilmore: mmcgrath: id say we bug the shit out of legal about smtp and move forward with ORTS and spamassain sqlgrey clamav [15:19] skvidal: or if there are outstanding things you go to bugzilla/trac/etc to find what things are filed and not done [15:19] riczho has left ( (i=ricky at gateway/gpg-tor/key-0xCCAF484E)) [15:20] skvidal: mmcgrath: rather than what you do now, which is, I presume chase it down in otrs' ever-so-obvious interface [15:20] riczho has joined the group chat (i=ricky at gateway/gpg-tor/key-0xCCAF484E) [15:20] notting: we have an irc channel where peopel can leave issues, with a bot doing mail gating... [15:20] mmcgrath: we should compare a mailing list to trac, not otrs. [15:20] mmcgrath: skvidal: You have to admit, this is pretty simple - https://hosted.fedoraproject.org/projects/smolt/report/1 [15:20] G: notting: heh, not bad idea! [15:21] skvidal: mmcgrath: excluding all the unncessary crap like 'component1' [15:21] G: notting: of course, relying on another 3rd party isn't a very good situation [15:21] mmcgrath: skvidal: I'm just saying email gets very easy to ignore. [15:21] f13: yeah, why do you still have 'component1' in there? [15:21] mmcgrath: f13: I never set it up. [15:21] f13: Admin tab and edit up your components (: [15:21] mmcgrath: [15:22] f13: it's nice that we can set milestones for things like new OS rollouts and assign people tasks [15:22] f13: and as things get done the Timeline will show it [15:22] mmcgrath: Ok, so I think this should be talked about again, skvidal mind sending something to the list so we can discuss it further? [15:23] skvidal: mmcgrath: I can - but I'm not wed to this idea [15:23] skvidal: if everyone is happy with trac, I'm on board [15:23] mmcgrath: skvidal: its good to think it over again since we're talking about changing, no need to end up with another OTRS [15:23] mmcgrath: ok, for now we'll move on. [15:23] skvidal: mmcgrath: okay- email on its way soon [15:24] mmcgrath has set the subject to Firewall System Rewrite -- skvidal lmacken xDamox [15:24] mmcgrath: So AFAIK this has gone very well. [15:24] mmcgrath: few very minor bumps while implementing but a lot of our hosts are actually using the firewalls now. [15:24] mmcgrath: xDamox: what do you think? [15:24] xDamox: I am just monitoring the bulder ports and the torrent server to suggest the rules [15:24] xDamox: I am going to get the ports run by skvidal and lmacken [15:24] mmcgrath: xDamox: FYI the torrent box is also our primary DNS. [15:25] xDamox: I did a test last night but it became void due to security scans [15:25] xDamox: ok [15:25] mmcgrath: cool. [15:25] dgilmore: xDamox: i can give you the ports the builders use [15:25] mmcgrath: skvidal: lmacken: anything to add? [15:25] xDamox: within the next 24 hours we should have them fully deployed [15:25] skvidal: mmcgrath: other than 'yay' xDamox? [15:25] xDamox: dgilmore, yea that would be good [15:25] mmcgrath: [15:26] skvidal: torrent is tricky b/c of the seeder [15:26] skvidal: but I think I have the rule set I used before [15:26] xDamox: ok [15:26] mmcgrath: xDamox: If we find our template is too simple for the torrent box let me know, I can add a "custom" section to the bottom. [15:27] xDamox: Ok mmcgrath [15:27] mmcgrath: alllrighty, next item [15:27] mmcgrath has set the subject to Upgrade DB1 -- mmcgrath [15:27] xDamox: skvidal, if I email you so, can you supply the iptable for the torrent box? [15:27] skvidal: yah [15:27] xDamox: s/so/soon/ [15:27] mmcgrath: so db2 is up and so far has been working great. [15:27] xDamox: cheers [15:27] mmcgrath: abadger1999: have you had a chance to check out test2? [15:27] mmcgrath: mbonnet: ping [15:27] mbonnet: mmcgrath: yo [15:28] mmcgrath: mbonnet: any chance to take a look at db2? [15:28] abadger1999: Not yet. it's whatI'm working on now. [15:28] mbonnet: mmcgrath: crap, not yet [15:29] mmcgrath: mbonnet: want me to just keep bugging you till you get a moment? [15:29] * mmcgrath is good at bugging [15:29] mbonnet: mmcgrath: sure, please do [15:29] mmcgrath: will do. [15:29] mbonnet: I'll find a few spare moments at some point [15:29] mmcgrath: abadger1999: if you need anything with test2 let me know. [15:29] abadger1999: Will do. [15:29] mmcgrath has set the subject to Server Upgrades -- mmcgrath [15:29] agentunix has joined the group chat (n=agentuni at 66.183.197.79) [15:29] mmcgrath: So I've put in some requests to the soc. [15:30] mmcgrath: Just to remind everyone. Priority 1) Some of our servers don't have a proper warranty right now.... fix that. [15:30] mmcgrath: priority 2) Figure out how to backup koji (probably tape) [15:30] mmcgrath: 3) Server upgrades and replacements. (includes adding RAM to the boxes we have, and replacing some of our older stuff) [15:31] mmcgrath: In with this somewhere is a new disk tray thats been installed, we're just waiting for the soc to configure it and hand it over to us. [15:31] mmcgrath: Anyone have any questions about that? [15:31] dgilmore: mmcgrath: where can we host tape [15:31] jcollie: ot - what's soc? i assume it's some RH IT group? [15:31] dgilmore: and who will swap the tapes? [15:32] Sopwith has joined the group chat (n=elee at 66.193.5.50) [15:32] mmcgrath: jcollie: they're the guys that run the PHX colo (and many other colo's) [15:32] mmcgrath: dgilmore: thats the big question. [15:32] mmcgrath: dgilmore: it'd be at PHX, we could get a robot out there. I basically went to those guys, said we'd need to backup at least a T by the end of the year. [15:33] dgilmore: mmcgrath: so they would handle tape rotation? [15:33] jcollie: would the SOC guys/gals be in charge of swapping tapes then? [15:33] mmcgrath: jcollie: yep [15:33] mmcgrath: dgilmore: Not sure. [15:33] dgilmore: What kinda cost is involved in that ? [15:33] mmcgrath: dgilmore: a lot. [15:34] jcollie: what about offsite copies of the tapes? [15:34] mmcgrath: but its got to get done. [15:34] dgilmore: f13: when was power upgrade there supposed to be done [15:34] mmcgrath: jcollie: thats not even on the radar yet. [15:34] mmcgrath: jcollie: I'm working on a DR plan but thats at least a year out. [15:34] f13: dgilmore: dunno, I just have vague mentions of it being done. [15:34] dgilmore: mmcgrath: could we do it in RDU and have a RH person manage tapes? [15:34] mmcgrath: dgilmore: not efficiently. [15:34] mmcgrath: I don't think anyway. Possibly at another colo. [15:35] dgilmore: mmcgrath: stacys basement? [15:35] mmcgrath: dgilmore: try not to think of the tapes. Its a possibility, but there are many others. [15:35] mdomsch: tape libraries are your friends, if you have to use tapes at all [15:35] dgilmore: f13: it would be good to get those blades in ASAP [15:35] mmcgrath: Including another netapp provided by the soc. The issue is there's no backups at PHX right now, pretty much everything there (besides our stuff) gets replicated to there from somewhere else. [15:35] f13: dgilmore: indeed it would. [15:35] jcollie: i suppose if you had enough tapes in the robot and a short retention policy you wouldn't have to swap tapes [15:36] dgilmore: mmcgrath: can we get netapp space in Tampa or RDU? [15:36] mmcgrath: anyway, you guys can see this is an expensive and tricky thing so it'll likely take some time to implement. [15:36] f13: mmcgrath: hrm, since we're using netapps for our stuff, why couldn't the taping happen on the RDU fedora netapp? [15:36] mmcgrath: f13: because none of the other netapps are the same size as the PHX netapp. [15:36] mmcgrath: its much much larger. [15:37] mmcgrath: dgilmore: possibly. [15:37] f13: mmcgrath: oh the production one, not the mirror one. sorry [15:37] mmcgrath: I'm letting the soc figure that stuff out, we're a consumer of theirs. [15:37] mmcgrath: I've told them what we need hopefully they'll come back at me with what they can provide and what I'll have to find a budget for. [15:37] mmcgrath: anywho, thats the latest on that. [15:37] mmcgrath has set the subject to xen Conversion -- mmcgrath [15:38] mmcgrath: so I've been taking machines down and converting them to iscsi. I'll be making an SOP for this and for how our cluster works. [15:38] mmcgrath: I've also been trying to figure out some issues with mod_proxy_balancer. I think I've got them all figured out now. [15:39] mmcgrath: we've got 9 hosts running over pure iscsi now, and they've been working great. [15:39] mmcgrath: Any questions on this? [15:39] mmcgrath: or comments? [15:39] dgilmore: im glad we can do it this way [15:39] jcollie: awesome [15:39] mmcgrath: dgilmore: so far its proved to be very reliable. [15:40] mmcgrath has set the subject to Bacula -- mmcgrath [15:40] mmcgrath: So I've been evaluating bacula and dgilmore's taken a look as well. [15:40] mmcgrath: we're just waiting on ixs to release another version for review. [15:40] mmcgrath has set the subject to Translator's Compendium -- Glezos [15:41] mmcgrath: for those of you that don't know, glezos has been working on http://translate.fedoraproject.org/ [15:41] mmcgrath: Its a pretty exciting app, keep your eye out for more news with it in the future. [15:41] glezos: yay. [15:41] mmcgrath has set the subject to Project Hosting -- f13 [15:41] mmcgrath: f13: anything new on this front? [15:41] mmcgrath: the git plugin still stink? [15:41] jcollie: i thought that someone was going to do some work on the git plugin [15:42] f13: git plugin still sucks major ass. [15:42] f13: jcollie: daMaestro was talking about it [15:43] f13: mmcgrath: seeing more people asking for projects. Did 3 this week already [15:43] jcollie: f13, he get anything done? [15:43] f13: jcollie: he was waiting for a new laptop to arrive that he could use kvm with I think [15:43] jcollie: is adding a project something that can be "puppetized"? [15:43] mmcgrath: f13: its probably time we move that to the cluster until we find a permanent home for it. [15:43] mmcgrath: f13: does it have a db backend? [15:44] mmcgrath: or is it flat file? [15:44] craigt has left ("Leaving" (i=hidden-u at gnat.asiscan.com)) [15:45] f13: sqlite backend [15:45] f13: each project gets it's own sqlite db [15:45] mmcgrath: f13: is it possible to move that to mysql or postgres or is sqlite a requisite? [15:45] f13: I think we can actually make it use more robust backends but wasn't necessary for the proof of concept [15:46] mmcgrath: we can examine that then. [15:46] f13: jcollie: probably not easily puppetted [15:46] f13: jcollie: the project space is really more like content than config [15:46] mmcgrath: f13: is there an SOP for creating a new project? [15:46] f13: yeah, but not under the SOP header yet [15:47] mmcgrath: k [15:47] mmcgrath: f13: anything else there? [15:48] f13: nope. I still suck (: [15:48] mmcgrath: [15:48] mmcgrath: moving on [15:48] mmcgrath has set the subject to FedoraPeople.org -- skvidal [15:48] mmcgrath: skvidal: whats the word? [15:48] skvidal: fpserv is cleared of planet stuff [15:48] skvidal: I am going through the other aliases to it and checking them [15:48] skvidal: ex: bugs, art, legacy [15:48] skvidal: (all of which go to bugzilla, amusingly) [15:48] mmcgrath: fantastic [15:49] skvidal: once I'm happy that dns is not taking people there [15:49] tibbs has left ("Konversation terminated!" (n=tibbs at fedora/tibbs)) [15:49] skvidal: then I can nuke it [15:49] skvidal: a couple of questions on fpserv [15:49] skvidal: dns is very very not-being-used on it, right? [15:49] dgilmore: it was moved away awile ago now [15:49] mmcgrath: It shouldn't be. You can tcpdump it. [15:49] skvidal: okay, well it is still running [15:49] skvidal: [15:50] mmcgrath: skvidal: turn it off and see what happens. It shouldn't be taking any traffic anymore. [15:50] skvidal: mmcgrath: cool, just wanted to be sure [15:50] mmcgrath: and it should be way out of date with what is actually live right now [15:50] skvidal: right [15:50] skvidal: also - where are we sending logs for remote boxes? [15:50] mmcgrath: skvidal: anything else on that front? [15:50] skvidal: see above [15:50] mmcgrath: skvidal: lockbox. [15:50] skvidal: how do they get through? [15:50] skvidal: ie: via syslog [15:51] mmcgrath: http logs go via rsync and syslog go via udp except we're not pulling anything from the external boxes right now. [15:51] mmcgrath: and AFAIK ssh port forwards don't support UDP yet. [15:51] rdieter has left (Read error: 104 (Connection reset by peer) (n=rdieter at sting.unl.edu)) [15:51] skvidal: is lockbox just using sysklogd? [15:51] skvidal: b/c we can do tcp syslog using syslog-ng and stunnel the whole thing [15:51] mmcgrath: yep, I'm working on rebuilding lockbox though. [15:52] skvidal: okay, then I'll just leave it off for now on fpserv for syslog [15:52] mmcgrath: so we can re-examine that part of it. [15:52] mmcgrath: [15:52] skvidal: my other question is this [15:52] skvidal: how do you want me to do the kickstart for this box? [15:52] skvidal: b/c it can't really be installed using the same mechanisms as boxes in phx [15:52] mmcgrath: skvidal: actually it *could* be if you wanted to. [15:52] skvidal: I had planned on doing it via a kickstart and talking to the centos-5 repos [15:52] skvidal: mmcgrath: how? [15:53] mmcgrath: We could just expose the install media and kickstarts temporarely. [15:53] SmootherFrOgZ has left (Success (n=Smoother at LLamentin-151-13-32.w81-248.abo.wanadoo.fr)) [15:53] mmcgrath: or if you're using CentOS-5 we can just expose the kickstart. [15:53] mmcgrath: though our kickstart scripts are very very simple now. [15:53] SmootherFrOgZ has joined the group chat (n=Smoother at LLamentin-151-13-32.w81-248.abo.wanadoo.fr) [15:53] skvidal: mmcgrath: right, that's why I was wondering if it was worth it [15:54] mmcgrath: most of the configuration is done with puppet so as long as you get puppet on there and forward a port like what we're doing for ns1.fp.o then you're golden. [15:54] mmcgrath: skvidal: is duke backing up torrent? [15:54] JSchmitt has left ("Konversation terminated!" (n=s4504kr at fedora/JSchmitt)) [15:54] skvidal: okay, I think I can arrange something [15:54] skvidal: mmcgrath: umm lemme check [15:54] mmcgrath: k [15:54] mmcgrath: skvidal: mind if I move on? we only have a few more minutes left. [15:55] skvidal: go right ahead [15:55] mmcgrath has set the subject to Ibiblio Mirror -- mmcgrath [15:55] mmcgrath: So the ibiblio mirror is setup and syncing. I just need to test it then have others test it then work with f13 on a plan for how to use it. [15:55] f13: neat [15:55] skvidal: quick return - torrent is backed up, yes - but it's excluding the isos b/c we just don't have the space [15:55] mmcgrath: k [15:55] mmcgrath has set the subject to noc -- mmcgrath [15:56] mmcgrath: so the noc site is sort of taking shape. If anyone has something they'd like to see montiored let me knwo and I'll add it or tell you how to write your own script to add it. [15:56] mmcgrath: Here's whats there right now - http://publictest4.fedora.redhat.com/noc/list [15:56] mmcgrath: just some basic stuff. [15:57] mmcgrath has set the subject to Open Floor -- Everyone [15:57] mmcgrath: Anyone have anything else to dicsuss? we have a few more minutes. [15:57] MukulDharwadkar has joined the group chat (n=mukul at 67.121.167.34) [15:57] skvidal: yah one thing [15:57] skvidal: I'm working full time now. So if there is shit that needs doing and you think I can help, ping me [15:58] skvidal: I've been gone for the last 2 months in all serious senses [15:58] dgilmore: skvidal: what exactly is your role in RH? [15:58] skvidal: but I'm back and around now [15:58] skvidal: dgilmore: that's an interesting question [15:58] skvidal: dgilmore: max actually said the following to me "paying me to do the stuff I was doing before" [15:58] skvidal: that confused me more, but that's okay [15:58] dgilmore: skvidal: i want that gig [15:58] dgilmore: so whatever you want in Fedora space [15:58] mmcgrath: skvidal: that reminds me. If any python programmers out there want to assist me with the new account system. I really could use it. [15:58] skvidal: in my email to my manager I said that fedorapeople.org was on my short-term todo list [15:59] skvidal: mmcgrath: subtle [15:59] mmcgrath: :: wink wink nudge nudge :: [15:59] skvidal: mmcgrath: where is it? [15:59] f13: skvidal: and I could probably use a code review of pungi for proper use of yum apis [15:59] MukulDharwadkar: mmcgrath: Thanks for setting me up on fedoraproject.org [15:59] skvidal: f13: that's also on my list of things to stare at for a while [15:59] mmcgrath: http://cvs.fedora.redhat.com/viewcvs/accounts2/fas/?root=fedora [15:59] mmcgrath: MukulDharwadkar: you are welcome. [15:59] rordway: mmcgrath: I like the NOC data [16:00] mmcgrath: rordway: if you're interested email me some more things you'd like to see on there. [16:00] rordway: would be cool to get some server metrics too [16:00] rordway: k, will do [16:00] dgilmore: skvidal: ill come up with some task lists for you by the end of week [16:00] mmcgrath: Ok, we're at the top of the hour. If no one has anything else I'll close in 30 [16:00] skvidal: dgilmore: umm, thanks? [16:00] mmcgrath: 15 [16:01] mmcgrath: 5 [16:01] mmcgrath has set the subject to Meeting End -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mmcgrath at redhat.com Fri Jun 22 02:26:23 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 21 Jun 2007 21:26:23 -0500 Subject: Cleanup list Message-ID: <467B334F.8010401@redhat.com> Get the list done -Mike From mmcgrath at redhat.com Fri Jun 22 02:30:12 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 21 Jun 2007 21:30:12 -0500 Subject: Cleanup list In-Reply-To: <467B334F.8010401@redhat.com> References: <467B334F.8010401@redhat.com> Message-ID: <467B3434.1040303@redhat.com> Mike McGrath wrote: > Get the list done Wow does this not make sense without context. And I have on excuse, its not even that late. I was wanting to get a list of things together for us to do for the F8 release. Basically things like streamlining the build and release process, efficiencies in koji and mash, as well as operational things like the new nagios rollout and accounts system rollout. What would everyone on the list like to see for F8? -Mike From paulo.banon at googlemail.com Fri Jun 22 02:41:24 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Fri, 22 Jun 2007 04:41:24 +0200 Subject: Cleanup list In-Reply-To: <467B3434.1040303@redhat.com> References: <467B334F.8010401@redhat.com> <467B3434.1040303@redhat.com> Message-ID: <7a41c4bc0706211941k523d409bqdf4a9e7e74be033b@mail.gmail.com> I'll stay with easy stuff Integration between apps, and the same look and feel everywhere :) Paulo On 6/22/07, Mike McGrath wrote: > > Mike McGrath wrote: > > Get the list done > > Wow does this not make sense without context. And I have on excuse, its > not even that late. I was wanting to get a list of things together for > us to do for the F8 release. Basically things like streamlining the > build and release process, efficiencies in koji and mash, as well as > operational things like the new nagios rollout and accounts system > rollout. > > What would everyone on the list like to see for F8? > > -Mike > > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Fri Jun 22 02:51:16 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 21 Jun 2007 21:51:16 -0500 Subject: Cleanup list In-Reply-To: <7a41c4bc0706211941k523d409bqdf4a9e7e74be033b@mail.gmail.com> References: <467B334F.8010401@redhat.com> <467B3434.1040303@redhat.com> <7a41c4bc0706211941k523d409bqdf4a9e7e74be033b@mail.gmail.com> Message-ID: <467B3924.6000502@redhat.com> Paulo Santos wrote: > I'll stay with easy stuff > Integration between apps, and the same look and feel everywhere :) I'd hate to know what you think is hard :) This is a great addition to the list. -Mike From mmcgrath at redhat.com Fri Jun 22 02:59:59 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 21 Jun 2007 21:59:59 -0500 Subject: Cleanup list In-Reply-To: <467B3434.1040303@redhat.com> References: <467B334F.8010401@redhat.com> <467B3434.1040303@redhat.com> Message-ID: <467B3B2F.5010704@redhat.com> Mike McGrath wrote: > Mike McGrath wrote: >> Get the list done > > Wow does this not make sense without context. And I have on excuse, > its not even that late. I was wanting to get a list of things > together for us to do for the F8 release. Basically things like > streamlining the build and release process, efficiencies in koji and > mash, as well as operational things like the new nagios rollout and > accounts system rollout. > > What would everyone on the list like to see for F8? Perhaps it'd also be good to make a "This is painful" list. If there's stuff you just don't like, here's a good thread to bring it up in. -Mike From paulo.banon at googlemail.com Fri Jun 22 03:00:39 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Fri, 22 Jun 2007 05:00:39 +0200 Subject: Cleanup list In-Reply-To: <467B3B2F.5010704@redhat.com> References: <467B334F.8010401@redhat.com> <467B3434.1040303@redhat.com> <467B3B2F.5010704@redhat.com> Message-ID: <7a41c4bc0706212000j30754ab4uea0abab8c20a3723@mail.gmail.com> Hard stuff: VCS :) On 6/22/07, Mike McGrath wrote: > > Mike McGrath wrote: > > Mike McGrath wrote: > >> Get the list done > > > > Wow does this not make sense without context. And I have on excuse, > > its not even that late. I was wanting to get a list of things > > together for us to do for the F8 release. Basically things like > > streamlining the build and release process, efficiencies in koji and > > mash, as well as operational things like the new nagios rollout and > > accounts system rollout. > > > > What would everyone on the list like to see for F8? > > Perhaps it'd also be good to make a "This is painful" list. If there's > stuff you just don't like, here's a good thread to bring it up in. > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis at ausil.us Fri Jun 22 03:15:31 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 21 Jun 2007 22:15:31 -0500 Subject: Cleanup list In-Reply-To: <467B3434.1040303@redhat.com> References: <467B334F.8010401@redhat.com> <467B3434.1040303@redhat.com> Message-ID: <200706212215.31547.dennis@ausil.us> Once upon a time Thursday 21 June 2007, Mike McGrath wrote: > Mike McGrath wrote: > > Get the list done > > Wow does this not make sense without context. And I have on excuse, its > not even that late. I was wanting to get a list of things together for > us to do for the F8 release. Basically things like streamlining the > build and release process, efficiencies in koji and mash, as well as > operational things like the new nagios rollout and accounts system rollout. > > What would everyone on the list like to see for F8? > > -Mike get rid of download.fedora.redhat.com have just download.fedoraproject.org make sure that all aliases etc point to fedoraproject.org not fedora.redhat.com i think there are some links on cvs that point to the old zombie domain. Secondary Arch support certainly FAS2 Dennis From paulo.banon at googlemail.com Fri Jun 22 03:20:54 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Fri, 22 Jun 2007 05:20:54 +0200 Subject: Cleanup list In-Reply-To: <200706212215.31547.dennis@ausil.us> References: <467B334F.8010401@redhat.com> <467B3434.1040303@redhat.com> <200706212215.31547.dennis@ausil.us> Message-ID: <7a41c4bc0706212020q2dc63de1l258a88806469c4eb@mail.gmail.com> Do we still need fedora.redhat.com ? On 6/22/07, Dennis Gilmore wrote: > > Once upon a time Thursday 21 June 2007, Mike McGrath wrote: > > Mike McGrath wrote: > > > Get the list done > > > > Wow does this not make sense without context. And I have on excuse, its > > not even that late. I was wanting to get a list of things together for > > us to do for the F8 release. Basically things like streamlining the > > build and release process, efficiencies in koji and mash, as well as > > operational things like the new nagios rollout and accounts system > rollout. > > > > What would everyone on the list like to see for F8? > > > > -Mike > get rid of download.fedora.redhat.com have just > download.fedoraproject.org > make sure that all aliases etc point to fedoraproject.org not > fedora.redhat.com i think there are some links on cvs that point to the > old > zombie domain. > > Secondary Arch support > > certainly FAS2 > > Dennis > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at arcnetworks.biz Fri Jun 22 03:53:29 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Fri, 22 Jun 2007 09:23:29 +0530 Subject: Fedora Magazine RFR In-Reply-To: References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com> <467868A3.8070008@redhat.com> <5d66540b0706192037p8efc208n33f82747a330f0f3@mail.gmail.com> <4678A4C3.3050509@redhat.com> <1182362817.21966.450.camel@erato.phig.org> <5d66540b0706201113s6245a4c5sb9c3e7eefd4001de@mail.gmail.com> <4679866C.2090908@redhat.com> <5d66540b0706202123i7634b041l355939b19cb25667@mail.gmail.com> Message-ID: <5d66540b0706212053l524af8auf705ee7ba35c95ff@mail.gmail.com> > > Well I've had my own job to take care of but I've been keeping up with the > list. I can't tell you how much of a pain it is to try to send a file > update to a unit over a 2.4kbs satellite channel particularly when they > can't stay at periscope depth for any period of time to download a 4mb > file... Had to break it up into a lot of very small zip files. > > I do like the idea of a Fedora magazine but I'm afraid it could just fall > into the multitude of ezines out there like some projects I've seen. It > seems like the focus right now is on a dedicated infrastructure for a > magazine that doesn't exist yet. I for one would worry less about that > and > more about the whole magazine issue itself. I don't think it's set in yet > about how much work goes into producing a magazine. I think the more > logical step would be to build a team and actually see if you can pull off > producing a few issues and then break off to it's own website once it's > established. I've seen more than a few ezine projects die after an issue > or > two and it seems like a huge waste in man-hours to set up everything > before > that. Start it off with FWN and then worry about the rest later. > > ------- > Brandon Jasper, CTN2(SS) > NSSC Bangor N621 Afloat LAN Admin. > SIPRNET: brandon.jasper at navy.smil.mil > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > > I have already run a few local print newspapers, so I know the workload and how it all goes. An online magazine would be slightly easier because I don't need to worry about the printing deadlines. -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at linux.duke.edu Fri Jun 22 16:30:41 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 22 Jun 2007 12:30:41 -0400 Subject: ticket system comments Message-ID: <1182529841.2754.50.camel@hodge> Some thoughts I had yesterday about OTRS/RT/ETC for ticketing systems for us. 1. We don't get a huge number of tickets - so maybe any system is overkill 2. A good number of the tickets can be solved immediately when they arrive. 3. If they can't be solved immediately then we need a reminder about them 4. we want users to be able to send in info like this w/o jumping through any hoops. I was going to suggest we make a mailing list: admin-request at fedoraproject.org - maybe alias it to something simple. When messages come in we do the following: 1. see if we know how to solve it and have time to do it immediately 2. If you don't know how to solve it or don't have the time, open a bugzilla item about it on a product-to-be-created and thrown the bugzilla entry back to the list and the poster This way, the simple things that don't really need a ticket don't get one and the hard things that do need a ticket do get one. -sv From nils at breun.nl Fri Jun 22 16:40:54 2007 From: nils at breun.nl (Nils Breunese) Date: Fri, 22 Jun 2007 18:40:54 +0200 Subject: ticket system comments In-Reply-To: <1182529841.2754.50.camel@hodge> References: <1182529841.2754.50.camel@hodge> Message-ID: <3003E14F-EFE8-43F5-BDF8-F7E36DBC0AD6@breun.nl> seth vidal wrote: > I was going to suggest we make a mailing list: > admin-request at fedoraproject.org - maybe alias it to something simple. > When messages come in we do the following: > > 1. see if we know how to solve it and have time to do it immediately > 2. If you don't know how to solve it or don't have the time, open a > bugzilla item about it on a product-to-be-created and thrown the > bugzilla entry back to the list and the poster > > This way, the simple things that don't really need a ticket don't get > one and the hard things that do need a ticket do get one. If someone sends a request to that mailinglist, how do we make sure it gets handled (eventually)? If no one acts, what happens? Is there someone checking whether everything is either solved directly or made into a bugzilla entry? Nils Breunese. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Dit deel van het bericht is digitaal ondertekend URL: From skvidal at linux.duke.edu Fri Jun 22 16:42:12 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 22 Jun 2007 12:42:12 -0400 Subject: ticket system comments In-Reply-To: <3003E14F-EFE8-43F5-BDF8-F7E36DBC0AD6@breun.nl> References: <1182529841.2754.50.camel@hodge> <3003E14F-EFE8-43F5-BDF8-F7E36DBC0AD6@breun.nl> Message-ID: <1182530532.2754.52.camel@hodge> On Fri, 2007-06-22 at 18:40 +0200, Nils Breunese wrote: > seth vidal wrote: > > > I was going to suggest we make a mailing list: > > admin-request at fedoraproject.org - maybe alias it to something simple. > > When messages come in we do the following: > > > > 1. see if we know how to solve it and have time to do it immediately > > 2. If you don't know how to solve it or don't have the time, open a > > bugzilla item about it on a product-to-be-created and thrown the > > bugzilla entry back to the list and the poster > > > > This way, the simple things that don't really need a ticket don't get > > one and the hard things that do need a ticket do get one. > > If someone sends a request to that mailinglist, how do we make sure > it gets handled (eventually)? If no one acts, what happens? Is there > someone checking whether everything is either solved directly or made > into a bugzilla entry? Is there any guarantee of this in the ticketing system we have now? no. The only guarantee is that someone is watching their email. Same as with the ticket system, really. -sv From brandon.jasper at navy.mil Fri Jun 22 17:05:13 2007 From: brandon.jasper at navy.mil (Jasper, Brandon R CTN2 NSSC BANGOR WA, NSSC Bangor N621) Date: Fri, 22 Jun 2007 10:05:13 -0700 Subject: Fedora Magazine RFR In-Reply-To: <5d66540b0706212053l524af8auf705ee7ba35c95ff@mail.gmail.com> References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com><5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com><467868A3.8070008@redhat.com><5d66540b0706192037p8efc208n33f82747a330f0f3@mail.gmail.com><4678A4C3.3050509@redhat.com><1182362817.21966.450.camel@erato.phig.org><5d66540b0706201113s6245a4c5sb9c3e7eefd4001de@mail.gmail.com><4679866C.2090908@redhat.com><5d66540b0706202123i7634b041l355939b19cb25667@mail.gmail.com> <5d66540b0706212053l524af8auf705ee7ba35c95ff@mail.gmail.com> Message-ID: -----Original Message----- From: fedora-infrastructure-list-bounces at redhat.com [mailto:fedora-infrastructure-list-bounces at redhat.com] On Behalf Of Anand Capur Sent: Thursday, June 21, 2007 20:53 To: fedora-infrastructure-list at redhat.com Subject: Re: Fedora Magazine RFR Well I've had my own job to take care of but I've been keeping up with the list. I can't tell you how much of a pain it is to try to send a file update to a unit over a 2.4kbs satellite channel particularly when they can't stay at periscope depth for any period of time to download a 4mb file... Had to break it up into a lot of very small zip files. I do like the idea of a Fedora magazine but I'm afraid it could just fall into the multitude of ezines out there like some projects I've seen. It seems like the focus right now is on a dedicated infrastructure for a magazine that doesn't exist yet. I for one would worry less about that and more about the whole magazine issue itself. I don't think it's set in yet about how much work goes into producing a magazine. I think the more logical step would be to build a team and actually see if you can pull off producing a few issues and then break off to it's own website once it's established. I've seen more than a few ezine projects die after an issue or two and it seems like a huge waste in man-hours to set up everything before that. Start it off with FWN and then worry about the rest later. ------- Brandon Jasper, CTN2(SS) NSSC Bangor N621 Afloat LAN Admin. SIPRNET: brandon.jasper at navy.smil.mil _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list I have already run a few local print newspapers, so I know the workload and how it all goes. An online magazine would be slightly easier because I don't need to worry about the printing deadlines. -------------- I don't see how the lack of a printing deadline would make any difference as there is still a posting deadline which all things considered is still a deadline to meet. It would stand to reason that not meeting the schedule people expect things to be published by would only serve to hurt the credibility of the publication. That aside I still retain the opinion that a few issues should be published before creating the administration overhead of setting up a server for it. It's like committing to sailing around the world before you make sure your ship can float on it's own. ------- Brandon Jasper, CTN2(SS) NSSC Bangor N621 Afloat Lan Admin. SIPRNET: brandon.jasper at navy.smil.mil From nils at breun.nl Fri Jun 22 17:31:29 2007 From: nils at breun.nl (Nils Breunese) Date: Fri, 22 Jun 2007 19:31:29 +0200 Subject: ticket system comments In-Reply-To: <1182530532.2754.52.camel@hodge> References: <1182529841.2754.50.camel@hodge> <3003E14F-EFE8-43F5-BDF8-F7E36DBC0AD6@breun.nl> <1182530532.2754.52.camel@hodge> Message-ID: <44DFC97C-D1DF-4007-B080-80185C5AC99F@breun.nl> seth vidal wrote: > On Fri, 2007-06-22 at 18:40 +0200, Nils Breunese wrote: >> seth vidal wrote: >> >>> I was going to suggest we make a mailing list: >>> admin-request at fedoraproject.org - maybe alias it to something >>> simple. >>> When messages come in we do the following: >>> >>> 1. see if we know how to solve it and have time to do it immediately >>> 2. If you don't know how to solve it or don't have the time, open a >>> bugzilla item about it on a product-to-be-created and thrown the >>> bugzilla entry back to the list and the poster >>> >>> This way, the simple things that don't really need a ticket don't >>> get >>> one and the hard things that do need a ticket do get one. >> >> If someone sends a request to that mailinglist, how do we make sure >> it gets handled (eventually)? If no one acts, what happens? Is there >> someone checking whether everything is either solved directly or made >> into a bugzilla entry? > > Is there any guarantee of this in the ticketing system we have now? > > no. That's true, but a ticket system will tell you what issues are still unhandled, whereas email does not. > The only guarantee is that someone is watching their email. Same as > with > the ticket system, really. But someone could be watching either the ticket system (or the mailinglist if we go with that) and maybe notify people to make sure at least the most important issues get handled or something. I think the ticket system is currently not working for FI because nobody is/ feels responsible for what goes on in there. I don't know if the mailinglist/Bugzilla hybrid will improve this situation. Nils Breunese. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Dit deel van het bericht is digitaal ondertekend URL: From jkeating at redhat.com Fri Jun 22 18:09:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Jun 2007 14:09:54 -0400 Subject: ticket system comments In-Reply-To: <44DFC97C-D1DF-4007-B080-80185C5AC99F@breun.nl> References: <1182529841.2754.50.camel@hodge> <1182530532.2754.52.camel@hodge> <44DFC97C-D1DF-4007-B080-80185C5AC99F@breun.nl> Message-ID: <200706221409.54254.jkeating@redhat.com> On Friday 22 June 2007 13:31:29 Nils Breunese wrote: > That's true, but a ticket system will tell you what issues are still ? > unhandled, whereas email does not. As much as I don't like the mailing list idea, I think Seth is right in that it's up to the person handling the task. Whether they remark in the ticket that they are handling it, or post a quick reply to the list that they are handling it, they still have to do /something/ before the rest of us know that they're handling it. > > The only guarantee is that someone is watching their email. Same as ? > > with > > the ticket system, really. > > But someone could be watching either the ticket system (or the ? > mailinglist if we go with that) and maybe notify people to make sure ? > at least the most important issues get handled or something. I think ? > the ticket system is currently not working for FI because nobody is/ > feels responsible for what goes on in there. I don't know if the ? > mailinglist/Bugzilla hybrid will improve this situation. I don't consider our current ticketing system an option. My only suggested alternative to what Seth is proposing and what we have is to create a Trac instance for Fedora Infrastructure. Within we could use the ticketing system for a variety of purposes. Logging actual issues/bugs, requesting tasks of people, etc.. We can use milestones for tracking bigger projects like builder OS refreshes, preparing for a new release, etc.. We can just not use the wiki system as we already have fp.o/wiki, and we can still have the ticket entries go to a mailing list, we get rss feeds, and we prevent spam as only valid FAS accounts can login to create new tickets. But as Seth stats, this may be overkill for just the trouble/task ticketing. Once you view what /else/ could be done with the Trac space then it is somewhat compelling to make use of it for trouble/task ticketing too. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Fri Jun 22 18:22:37 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 22 Jun 2007 13:22:37 -0500 Subject: ticket system comments In-Reply-To: <44DFC97C-D1DF-4007-B080-80185C5AC99F@breun.nl> References: <1182529841.2754.50.camel@hodge> <3003E14F-EFE8-43F5-BDF8-F7E36DBC0AD6@breun.nl> <1182530532.2754.52.camel@hodge> <44DFC97C-D1DF-4007-B080-80185C5AC99F@breun.nl> Message-ID: <467C136D.90000@redhat.com> Nils Breunese wrote: > seth vidal wrote: > >> On Fri, 2007-06-22 at 18:40 +0200, Nils Breunese wrote: >>> seth vidal wrote: >>> >>>> I was going to suggest we make a mailing list: >>>> admin-request at fedoraproject.org - maybe alias it to something simple. >>>> When messages come in we do the following: >>>> >>>> 1. see if we know how to solve it and have time to do it immediately >>>> 2. If you don't know how to solve it or don't have the time, open a >>>> bugzilla item about it on a product-to-be-created and thrown the >>>> bugzilla entry back to the list and the poster >>>> >>>> This way, the simple things that don't really need a ticket don't get >>>> one and the hard things that do need a ticket do get one. >>> >>> If someone sends a request to that mailinglist, how do we make sure >>> it gets handled (eventually)? If no one acts, what happens? Is there >>> someone checking whether everything is either solved directly or made >>> into a bugzilla entry? >> >> Is there any guarantee of this in the ticketing system we have now? >> >> no. > > That's true, but a ticket system will tell you what issues are still > unhandled, whereas email does not. Someone also brought up using a trac instance, it'd be lighter weight then bugzilla and more customizable (for us). It would be far more light weight then OTRS but not as light weight as a mailing list. Here's the pros and cons as I see them: Mail-List - Cons: 1) Spam 2) Difficult to comment on existing threads if not subscribed 3) Stuff that takes a long time to fix may get lost 4) Difficult to know who's working on what Mail-List - Pros: 1) Very light weight 2) Hard to completely ignore 3) No registration required 4) Almost no administrative overhead Trac - Cons: 1) Requires a FAS login 2) Could just be ignored 3) Little bit of initial configuration required Trac - Pros 1) Ticket ownership is known 2) Easy to search / filter 3) Provides milestones/components I have to say in general I like Trac over a mailing list... but not by much. I'd be curious to see what the others say. Any comments? -Mike From paulo.banon at googlemail.com Fri Jun 22 18:24:59 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Fri, 22 Jun 2007 20:24:59 +0200 Subject: ticket system comments In-Reply-To: <467C136D.90000@redhat.com> References: <1182529841.2754.50.camel@hodge> <3003E14F-EFE8-43F5-BDF8-F7E36DBC0AD6@breun.nl> <1182530532.2754.52.camel@hodge> <44DFC97C-D1DF-4007-B080-80185C5AC99F@breun.nl> <467C136D.90000@redhat.com> Message-ID: <7a41c4bc0706221124q1e627f70i1fddf28324a80588@mail.gmail.com> I think that the ML has two down sides: 3) Stuff that takes a long time to fix may get lost 4) Difficult to know who's working on what Besides that i agree with Seth, its better then OTRS (at least for our needs), But my favourite option is still Trac. I think we could use Trac for our needs. Paulo On 6/22/07, Mike McGrath wrote: > > Nils Breunese wrote: > > seth vidal wrote: > > > >> On Fri, 2007-06-22 at 18:40 +0200, Nils Breunese wrote: > >>> seth vidal wrote: > >>> > >>>> I was going to suggest we make a mailing list: > >>>> admin-request at fedoraproject.org - maybe alias it to something simple. > >>>> When messages come in we do the following: > >>>> > >>>> 1. see if we know how to solve it and have time to do it immediately > >>>> 2. If you don't know how to solve it or don't have the time, open a > >>>> bugzilla item about it on a product-to-be-created and thrown the > >>>> bugzilla entry back to the list and the poster > >>>> > >>>> This way, the simple things that don't really need a ticket don't get > >>>> one and the hard things that do need a ticket do get one. > >>> > >>> If someone sends a request to that mailinglist, how do we make sure > >>> it gets handled (eventually)? If no one acts, what happens? Is there > >>> someone checking whether everything is either solved directly or made > >>> into a bugzilla entry? > >> > >> Is there any guarantee of this in the ticketing system we have now? > >> > >> no. > > > > That's true, but a ticket system will tell you what issues are still > > unhandled, whereas email does not. > > Someone also brought up using a trac instance, it'd be lighter weight > then bugzilla and more customizable (for us). It would be far more > light weight then OTRS but not as light weight as a mailing list. > Here's the pros and cons as I see them: > > Mail-List - Cons: > 1) Spam > 2) Difficult to comment on existing threads if not subscribed > 3) Stuff that takes a long time to fix may get lost > 4) Difficult to know who's working on what > Mail-List - Pros: > 1) Very light weight > 2) Hard to completely ignore > 3) No registration required > 4) Almost no administrative overhead > > Trac - Cons: > 1) Requires a FAS login > 2) Could just be ignored > 3) Little bit of initial configuration required > Trac - Pros > 1) Ticket ownership is known > 2) Easy to search / filter > 3) Provides milestones/components > > > I have to say in general I like Trac over a mailing list... but not by > much. I'd be curious to see what the others say. Any comments? > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooge at gmail.com Fri Jun 22 18:38:56 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 22 Jun 2007 12:38:56 -0600 Subject: ticket system comments In-Reply-To: <7a41c4bc0706221124q1e627f70i1fddf28324a80588@mail.gmail.com> References: <1182529841.2754.50.camel@hodge> <3003E14F-EFE8-43F5-BDF8-F7E36DBC0AD6@breun.nl> <1182530532.2754.52.camel@hodge> <44DFC97C-D1DF-4007-B080-80185C5AC99F@breun.nl> <467C136D.90000@redhat.com> <7a41c4bc0706221124q1e627f70i1fddf28324a80588@mail.gmail.com> Message-ID: <80d7e4090706221138t58f01975g441d220ac62fce1c@mail.gmail.com> On 6/22/07, Paulo Santos wrote: > I think that the ML has two down sides: > 3) Stuff that takes a long time to fix may get lost > 4) Difficult to know who's working on what > > Besides that i agree with Seth, its better then OTRS (at least for our > needs), > But my favourite option is still Trac. I think we could use Trac for our > needs. > > Paulo > Outside person.. but I thought RT was being used by the Fedora Infrastructure Team or was that RH IS? Was there a reason it wasnt looked at? The biggest issues you want in a ticketing system versus a mailling list are: 1) Accountability. 2) Memory system of common problems 3) Ability to maintain some level of Service Level 4) Ability to track problems issues better. However you have overhead for those. You need to 'classify' the problem, You need to close out tickets, and You need to go over problems regularly to see where things keep breaking. Ticketing systems that are more usable via email works better for people who are working remotely and whose 'workflows' are email centered. For other workflows it may cause more problems. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From kwade at redhat.com Fri Jun 22 18:45:26 2007 From: kwade at redhat.com (Karsten Wade) Date: Fri, 22 Jun 2007 11:45:26 -0700 Subject: Fedora Magazine RFR In-Reply-To: References: <5d66540b0706180937j601f9665mec9057a340a69837@mail.gmail.com> <5d66540b0706181951o3aafe61em399c896b32eb2277@mail.gmail.com> <467868A3.8070008@redhat.com> <5d66540b0706192037p8efc208n33f82747a330f0f3@mail.gmail.com> <4678A4C3.3050509@redhat.com><1182362817.21966.450.camel@erato.phig.org> <5d66540b0706201113s6245a4c5sb9c3e7eefd4001de@mail.gmail.com> <4679866C.2090908@redhat.com> <5d66540b0706202123i7634b041l355939b19cb25667@mail.gmail.com> <5d66540b0706212053l524af8auf705ee7ba35c95ff@mail.gmail.com> Message-ID: <1182537927.10205.223.camel@erato.phig.org> On Fri, 2007-06-22 at 10:05 -0700, Jasper, Brandon R CTN2 NSSC BANGOR WA, NSSC Bangor N621 wrote: > It's like committing to sailing around the world before you make sure > your ship can float on it's own. I've been watching/peripherally involved with Red Hat Magazine since it started, and I see that it went through many of the pains you describe/suggest avoiding. Initially, it was a print magazine, with all that entails. Then it moved online, where it went through several toolings and features. Currently, it is just about the nicest that it has been, from a reader, contributor, and staff (I reckon) perspective. It has its own domain (redhatmagazine.com) and publishes using Lyceum (http://lyceum.ibiblio.org/), that is, blog software. Quite a journey to end up 'back at basics', and some lessons to learn from. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Fri Jun 22 22:56:22 2007 From: kwade at redhat.com (Karsten Wade) Date: Fri, 22 Jun 2007 15:56:22 -0700 Subject: Our SCM In-Reply-To: <46798EB3.50600@redhat.com> References: <4676D585.1030706@redhat.com> <1182266191.29855.26.camel@localhost.localdomain> <4677F726.3020407@redhat.com> <200706191601.35672.jkeating@redhat.com> <1182363757.21966.463.camel@erato.phig.org> <46798EB3.50600@redhat.com> Message-ID: <1182552983.10205.232.camel@erato.phig.org> On Wed, 2007-06-20 at 15:31 -0500, Mike McGrath wrote: > :) I think this thread took a spin away from the Infrastructure SCM > and on to something else. Well, actually, you know, I was specifically, yes, hmm, on target, hmm? > 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. [Snip reasons why it matters to think about this strategically] My whole point was that it _did_ matter enough to have "distributed VCS" be a specific feature request. Which DVCS wasn't the point. Also, to Blizzard's other points, this is entirely a Band-Aid(tm) in the longer scheme of things. But even when you fall down on your face, as long as you fall in the direction you want to go, you are making progress. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Fri Jun 22 23:41:42 2007 From: kwade at redhat.com (Karsten Wade) Date: Fri, 22 Jun 2007 16:41:42 -0700 Subject: ticket system comments In-Reply-To: <467C136D.90000@redhat.com> References: <1182529841.2754.50.camel@hodge> <3003E14F-EFE8-43F5-BDF8-F7E36DBC0AD6@breun.nl> <1182530532.2754.52.camel@hodge> <44DFC97C-D1DF-4007-B080-80185C5AC99F@breun.nl> <467C136D.90000@redhat.com> Message-ID: <1182555702.10205.258.camel@erato.phig.org> On Fri, 2007-06-22 at 13:22 -0500, Mike McGrath wrote: > Mail-List - Cons: > 1) Spam > 2) Difficult to comment on existing threads if not subscribed In addition, for any problems that get escalated to full bugzilla reports suffer from the same tracking problem for the original person. They need i) a bugzilla account, and ii) tell you what it is somewhere along the way so you can put them in Cc: on the bug (because you can't reset reporter to them, right?) This means, in order to ... ... receive updates to the mail thread, have to subscribe to the list and all of the ensuing spam, etc. ... ... receive updates on bugzilla escalations, have to create a bz account, then have an iteration of supplying that to FI, etc. ... At least OTRS uses the FAS account, where mailing lists + bugzilla escalations require one or two new accounts to track one ticket. > 3) Stuff that takes a long time to fix may get lost > 4) Difficult to know who's working on what > Mail-List - Pros: > 1) Very light weight > 2) Hard to completely ignore > 3) No registration required > 4) Almost no administrative overhead > > Trac - Cons: > 1) Requires a FAS login This is a challenge; what if the issue being reported has to do with login or account creation? Can't get an account to file a ticket about not being able to get an account ... So, there *must* be a catch-all support at fp.o that i) goes into a mailing list, ii) all infra people get that list, and iii) the few real pieces hopefully get noticed and acted upon. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Sat Jun 23 01:38:18 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Jun 2007 21:38:18 -0400 Subject: ticket system comments In-Reply-To: <1182555702.10205.258.camel@erato.phig.org> References: <1182529841.2754.50.camel@hodge> <467C136D.90000@redhat.com> <1182555702.10205.258.camel@erato.phig.org> Message-ID: <200706222138.25213.jkeating@redhat.com> On Friday 22 June 2007 19:41:42 Karsten Wade wrote: > This is a challenge; what if the issue being reported has to do with > login or account creation? ?Can't get an account to file a ticket about > not being able to get an account ... > > So, there *must* be a catch-all support at fp.o that i) goes into a mailing > list, ii) all infra people get that list, and iii) the few real pieces > hopefully get noticed and acted upon. Well, we /could/ allow tickets from non-authed people, IE anonymous. It just lowers the barrier of entry for spam, and also makes it harder to get back to people if they don't leave proper contact info. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Sat Jun 23 02:21:16 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 22 Jun 2007 21:21:16 -0500 Subject: ticket system comments In-Reply-To: <1182555702.10205.258.camel@erato.phig.org> References: <1182529841.2754.50.camel@hodge> <3003E14F-EFE8-43F5-BDF8-F7E36DBC0AD6@breun.nl> <1182530532.2754.52.camel@hodge> <44DFC97C-D1DF-4007-B080-80185C5AC99F@breun.nl> <467C136D.90000@redhat.com> <1182555702.10205.258.camel@erato.phig.org> Message-ID: <467C839C.5030705@redhat.com> Karsten Wade wrote: > > This is a challenge; what if the issue being reported has to do with > login or account creation? Can't get an account to file a ticket about > not being able to get an account ... > > So, there *must* be a catch-all support at fp.o that i) goes into a mailing > list, ii) all infra people get that list, and iii) the few real pieces > hopefully get noticed and acted upon. > We currently have (and will continue to have) accounts at fp.o and admin at fp.o, they're both groups so people email them anonymously. -Mike From kanarip at kanarip.com Sat Jun 23 09:55:29 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 23 Jun 2007 11:55:29 +0200 Subject: Cleanup list In-Reply-To: <7a41c4bc0706212020q2dc63de1l258a88806469c4eb@mail.gmail.com> References: <467B334F.8010401@redhat.com> <467B3434.1040303@redhat.com> <200706212215.31547.dennis@ausil.us> <7a41c4bc0706212020q2dc63de1l258a88806469c4eb@mail.gmail.com> Message-ID: <467CEE11.6090405@kanarip.com> Paulo Santos wrote: > Do we still need fedora.redhat.com? Afaik the account system's (?) certificates are still issued by cvs.fedora.redhat.com, and we still commit to that same CVS, right? Kind regards, Jeroen van Meeuwen -kanarip From mmcgrath at redhat.com Sat Jun 23 14:04:29 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 23 Jun 2007 09:04:29 -0500 Subject: Test server Message-ID: <467D286D.1000503@redhat.com> So last week we discussed creating a beefier test server for many of us to share. Creating individual instances for everyone has proved to be overkill for most so I'm going to create publictest1 and contact some individual people to start migrating to it. Additionally we have another RFR from Greg that he could develop on this instance. Any comments? http://fedoraproject.org/wiki/Infrastructure/RFR/FreeMediaSystem -Mike From sundaram at fedoraproject.org Sat Jun 23 20:27:13 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 24 Jun 2007 01:57:13 +0530 Subject: smolt, hardware compatibility and package stats Message-ID: <467D8221.9010200@fedoraproject.org> Hi What do folks think of extending smolt into more of a system profiler including optionally collecting information on installed packages? What's the status of adding hardware compatibility information with smolt as blogged in http://wtogami.livejournal.com/16659.html? Rahul From mmcgrath at redhat.com Sun Jun 24 00:30:51 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 23 Jun 2007 19:30:51 -0500 Subject: smolt, hardware compatibility and package stats In-Reply-To: <467D8221.9010200@fedoraproject.org> References: <467D8221.9010200@fedoraproject.org> Message-ID: <467DBB3B.4060003@redhat.com> Rahul Sundaram wrote: > > What do folks think of extending smolt into more of a system profiler > including optionally collecting information on installed packages? > I'm on the fence about this but would put package information lower in priority then some of the ratings system stuff. Mugshot is doing some package stuff already. > What's the status of adding hardware compatibility information with > smolt as blogged in http://wtogami.livejournal.com/16659.html? AFAIK we didn't find anyone so -ENOTIME. This will sit under "wouldn't it be nice" until we get someone to do it. I have one intern doing some smolt stuff but I've not heard back from him in a while. It is on the roadmap though - https://hosted.fedoraproject.org/projects/smolt/roadmap -Mike From jan at fedoraproject.org Sun Jun 24 12:23:15 2007 From: jan at fedoraproject.org (jan birsa) Date: Sun, 24 Jun 2007 14:23:15 +0200 Subject: Problem with CLA Message-ID: <1833f76a0706240523u79d25c36x66c6634e4b5c716e@mail.gmail.com> Hello, I hope you can help me here. My friend tryed to become a Fedora ambassador, but he gets this: "With regards to "Fedora Individual Contributor License Agreement". Your message could not be processed. Reason: The signature could not be processed. The signature may have been created or attached improperly, it might not match the key ID you have registered in the Account System, or the public key may not have been found on the key server. For guidance, please see the following page: " So I decided to register him. I used my mail and I connected to his server trough SSH to make a gpg key and a id_dsa.pub(ssh key). I got a mail with licence agreement, I added his name and " I agree" and made a .asc file. I sent that AND I GET SAME MAIL ERROR. I attached all necessary files (I hope). -- jan at fedoraproject.org www.ex-planet.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: id_dsa Type: application/octet-stream Size: 736 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fedora-icla-pyrox.txt.asc URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: id_dsa.pub Type: application/octet-stream Size: 606 bytes Desc: not available URL: From bugs.michael at gmx.net Sun Jun 24 14:31:46 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 24 Jun 2007 16:31:46 +0200 Subject: Problem with CLA In-Reply-To: <1833f76a0706240523u79d25c36x66c6634e4b5c716e@mail.gmail.com> References: <1833f76a0706240523u79d25c36x66c6634e4b5c716e@mail.gmail.com> Message-ID: <20070624163146.800db909.bugs.michael@gmx.net> On Sun, 24 Jun 2007 14:23:15 +0200, jan birsa wrote: > Hello, > > I hope you can help me here. > My friend tryed to become a Fedora ambassador, but he gets this: > "With regards to "Fedora Individual Contributor License Agreement". > > Your message could not be processed. > > Reason: > > The signature could not be processed. The signature may have been created > or attached improperly, it might not match the key ID you have registered in > the Account System, or the public key may not have been found on the key > server. For guidance, please see the following page: > " > > So I decided to register him. I used my mail and I connected to his server > trough SSH to make a gpg key and a id_dsa.pub(ssh key). I got a mail with > licence agreement, I added his name and " I agree" and made a .asc file. I > sent that AND I GET SAME MAIL ERROR. > > I attached all necessary files (I hope). You've attached the _private_ DSA key, too. Don't use this key pair any longer now. Did you upload the public GPG key to a key server? $ gpg --recv-key 047B8DE9 gpg: requesting key 047B8DE9 from hkp server pgp.mit.edu gpgkeys: key 047B8DE9 not found on keyserver gpg: no valid OpenPGP data found. gpg: Total number processed: 0 From sundaram at fedoraproject.org Sun Jun 24 16:42:14 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 24 Jun 2007 22:12:14 +0530 Subject: smolt, hardware compatibility and package stats In-Reply-To: <467DBB3B.4060003@redhat.com> References: <467D8221.9010200@fedoraproject.org> <467DBB3B.4060003@redhat.com> Message-ID: <467E9EE6.50904@fedoraproject.org> Mike McGrath wrote: > Rahul Sundaram wrote: >> >> What do folks think of extending smolt into more of a system profiler >> including optionally collecting information on installed packages? >> > > I'm on the fence about this but would put package information lower in > priority then some of the ratings system stuff. Mugshot is doing some > package stuff already. True but that code is tied to mugshot (I asked) and would require users to sign up with mugshot while Smolt is in first boot and I think many end users would prefer the unobtrusive method. As long as we have it optional (ie) I should be able to send the hardware details or the packaging stats or both, it should be a useful thing to do. Rahul From jan at fedoraproject.org Sun Jun 24 19:45:11 2007 From: jan at fedoraproject.org (jan birsa) Date: Sun, 24 Jun 2007 21:45:11 +0200 Subject: Fedora-infrastructure-list Digest, Vol 13, Issue 54 In-Reply-To: <20070624160005.AA36E73185@hormel.redhat.com> References: <20070624160005.AA36E73185@hormel.redhat.com> Message-ID: <1833f76a0706241245j50b24539r92d7d0ae570b941f@mail.gmail.com> I did this: gpg --keyserver pgp.mit.edu --send-keys 047B8DE9 I hope this is the right thing. Anyway, Can I ask you to remove accounts affix and pyrox from your system. (I tryed to register him twice). I will try again. On 6/24/07, fedora-infrastructure-list-request at redhat.com < fedora-infrastructure-list-request at redhat.com> wrote: > > Send Fedora-infrastructure-list mailing list submissions to > fedora-infrastructure-list at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > or, via email, send a message with subject or body 'help' to > fedora-infrastructure-list-request at redhat.com > > You can reach the person managing the list at > fedora-infrastructure-list-owner at redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Fedora-infrastructure-list digest..." > > > Today's Topics: > > 1. smolt, hardware compatibility and package stats (Rahul Sundaram) > 2. Re: smolt, hardware compatibility and package stats (Mike McGrath) > 3. Problem with CLA (jan birsa) > 4. Re: Problem with CLA (Michael Schwendt) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 24 Jun 2007 01:57:13 +0530 > From: Rahul Sundaram > Subject: smolt, hardware compatibility and package stats > To: Fedora Infrastructure > Message-ID: <467D8221.9010200 at fedoraproject.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi > > > What do folks think of extending smolt into more of a system profiler > including optionally collecting information on installed packages? > > What's the status of adding hardware compatibility information with > smolt as blogged in http://wtogami.livejournal.com/16659.html? > > Rahul > > > > ------------------------------ > > Message: 2 > Date: Sat, 23 Jun 2007 19:30:51 -0500 > From: Mike McGrath > Subject: Re: smolt, hardware compatibility and package stats > To: fedora-infrastructure-list at redhat.com > Message-ID: <467DBB3B.4060003 at redhat.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Rahul Sundaram wrote: > > > > What do folks think of extending smolt into more of a system profiler > > including optionally collecting information on installed packages? > > > > I'm on the fence about this but would put package information lower in > priority then some of the ratings system stuff. Mugshot is doing some > package stuff already. > > > > What's the status of adding hardware compatibility information with > > smolt as blogged in http://wtogami.livejournal.com/16659.html? > AFAIK we didn't find anyone so -ENOTIME. This will sit under "wouldn't > it be nice" until we get someone to do it. I have one intern doing some > smolt stuff but I've not heard back from him in a while. It is on the > roadmap though - https://hosted.fedoraproject.org/projects/smolt/roadmap > > -Mike > > > > ------------------------------ > > Message: 3 > Date: Sun, 24 Jun 2007 14:23:15 +0200 > From: "jan birsa" > Subject: Problem with CLA > To: fedora-infrastructure-list at redhat.com > Message-ID: > <1833f76a0706240523u79d25c36x66c6634e4b5c716e at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Skipped content of type multipart/alternative-------------- next part > -------------- > A non-text attachment was scrubbed... > Name: id_dsa > Type: application/octet-stream > Size: 735 bytes > Desc: not available > Url : > https://www.redhat.com/archives/fedora-infrastructure-list/attachments/20070624/273f15da/id_dsa.obj > -------------- next part -------------- > -----BEGIN PGP MESSAGE----- > Version: GnuPG v1.4.7 (GNU/Linux) > > owG1WU1vJEkRHXbhsEZILBKcWCnVCGGL6h57PuyZ3gPbO2PvtHbGHtyeHa0Qh+yq > rO5cV1eWMqvcbtBKHLkg9sR5gTOCG+LML0CIExzgwGH/AEfEi8isj273wF4YeWba > 1ZmRES8iXkRGffKV12+99ubhyye//OKPf/bZF37z1tn066lKjJV9HWeyX6ysuR6U > 1+XJj/78NXExV+KEvxXPrflIxeWOGOeJvtJJJTPxyOSl1dOqNFY81bHKnRKjmVVq > ofJS7D56OtrbEfOyLIa3by+Xy4E/aGBVMpflIDaL25nf5W7v7Aj8uZjL/FKsTCVS > iMT/Vui8VFa5Eh+2qCN2y7nirb3wpLc3gIrC2ERZURoBo6xOVwLrWFaWYREpX1hT > KFuuRNCBpcysxJpELHU5b83TJncitWYhZL4S2OUMnSBgpS5XkTjHDlgUsYhxHg/E > bo+ePZFQJxLSiYXE2fgLnUzKugR1I7GoYNxcXikhef/nAFXg+FRnCoIk7XViqlQu > nJ7lKmEh05VQMp53hUUwP9GxLHU+E7IRCIhInQCCANgL50WozCwHwFy75lt8JMd8 > SI4BfiUMADZkoFzTW3oRS6BNX9IBneXrCADTROjSicoB2LfxUSRGOZGbkoXEiImZ > 8sFg9WyOldAZi/0js8w3HUUKwE8Gh1gWUVS2ME4NfJCNU44whhyHCJlZJZMVTs2V > cCYSRaYkxCM+8amEX8jZeqZzRE0H48YpA/ECy6eZjC+B8WXEFkHrpF9YuJ0ipVwV > yodgqRbOq0bey1kSfUGCZVlZNRAThf30rNYg6QRAaXZ23qBN64kQifi2ESHoIg7C > yK8blWU+FE/VDNqP0lRq6/wXBw/2D8QH0jrEsHhs9ZXyz89lpoBzJE6NpSyQ1mSw > PRJ3jg73D8WLwWQw8lACyVzFyjlpkQUE6kKuhFPsUIrBVMZOLzhSzbrP2bffPeg/ > PHjYP7p/r3/3aP8ep1QfqYKgCUCLIkkBQ7GqgyYxcVXjAAmBujKy7p2WVwbiufch > eRb7ELfNxlhalVZZtkKEI1Q47+kwTgtofqlUgfP50IaFrIrBKC5E0Am2i1wu1FBs > /nlfaVCImCyIQMRx/xms4VUfyfwdr23hMRgYO/PiRkkChnPDnUlsygw6BDJUmSrm > CMqh2N/fDyfXgA6Ff4BUZK274CK2FMCXcawKn16c7rUPUpMhs8lcTnZeEBtwA6fP > 0Ms9GHQT2i9aS7MABak/YGLupjOln27rBFBkDwXCZNqqd1+ZrAI1Wg2HuGq60D6/ > 14Jl7WQhvc+YGwzTOUIXu6WHkbgYAGimpV7XiN5AnNSq1BJYI61cxCcG/RbykqNh > 41wyDI5veaWz31NxTOtNFpGO9S8ZFJoiPYiV8LTKqTAhRhcmb83glb7qsKCgSBDj > NPZADHCZKs6NfJY1IHRM9AYy3XrKcz5vKP5VqnN2cSR64cBeLWKhJIhzV+/5vWap > UC4SbQl9Y9mVlkmGCqok7uVc5Ie6tQNLFzKXM89UONlVqEF1lVzOFdMeQpPPl144 > w7nUTkUdMbsauoDaURHmuiBRqU5Lrr0xl8H7+9/e4/OQwYEbmu1V6Uo4i1zo5oDQ > RUEkZE5VDiBiTVHZFU+arvl01Qb4uwMx6kQSDO5RJeQaU9eFpbGXVGHjrEo8k6wa > cE2iUy68vmtAnLIfCExQhbrWjmuyF7FW0msRPjGoEKTsDpziSILO2bSa28IRaeR1 > W0MFrJNUMZKLzE5aV1FwrjckS0of7zpSqfUKm1qq0AqxooW0pY4r9Fhr9R8/vMaZ > RZ1UtRh4nYyFnlM1l1nq1YSobhg30D8i6NeyEMD3Gjh6pGzO1gKYBclSRAjW5Dpu > 4ulK2anMGKmlpX0551+V106BTNfphWok6v2tV6EDtwwZOLj0CbkuCT+tAk0AoAbQ > 7gyORiw6FJSY8jppOEK4laPGwLcO2rkKGYYEIRpqYsAv8WARMbT+Y9O6iEZr/Alo > aiEdaiCwEu3iyjl2COJqgSC54rQxabmkM9qdmzG2HjMEjLquYVrHpMv2QJr4rEDM > mMplRLX20odjwwOgKt8M4TlYnFzG2DchRI0Gcfup2awNg14TOY8ROQiLtdhp0wgx > T1I2Cg3YAvw+bXLGczWt2FYpG2oNXXrE/A326SZ/neygCC/D2I6ICEdkqFmsjLou > 0GfrkgohYG75rAFG575VJDMcEUBIlDtrxVq8R5cY0i4oNuAuIXQFfMMhw+tesT6G > W8bNvOy4mLsMQ52QLjQCge2vA6WJEoQ4q3GDV4aNZ3blHtwGJi8UXcQiZFTe5+Bx > KOQRkU6WLFHyIuH7tELqpF8VjabWrGSGYpCiqQHnWquuTCynmeKmje8I7X2GNPbc > 1xaYAo8ouuFdfSWpfWCmc5w5RTXFZhwLW4pMrtonzXZliW0ickRW+57gaa33XeON > 9qFbZTYPf5tWRC1K0/8bSrvQm+Md4EzCnezuHgSURILd6zAxhqF2CBL4vrSQdGBF > Bps09Tdsh1teFP4FheDSwGjcDF8wWu5o03ZwNgHpcJZV5JlOYardKwvkDHU5ORDg > bCZmC5bg6q8XjRi/hQGos79m0voSQz2ozlNc2mYNRzQEuK5vRpdFE5qZxZQKY+DF > m8YRLXQJmKwjZZdzDVNIk5aY6Ps1RsMl4pr7+A0WrxGoJxbMDVzIYt/kkVz0PsrS > ZAG0xnnRRAdKcqZ8tekMWEKO3zCh7vbvDkAbyH9rYuqQxMg19zLJF+VV7Z5Sz5ra > SqOKJFoDM3jIk5GnXb1YqETjOXkSVMm9hm+JoV4R4rVDrdR7+LsEVEcLVVbUmzRR > 3GggZ5K+Z0B2m1reELSIrXGuz8Hi2bkiRPzvhInI5NJVutwjGNWML0506KuCg6vx > dj9zDsX1WoDSuQE0FrR9d9yS+qo2rI5PHjx4r9zzBE88p3wfE9Tj4ObrDjDlNizz > TUsoAtBRTs2VWk8R1ItxCGO1KDKzUnbX7XFP2s5fuqO0TovpJ2rN+THu36WqfUTI > K7clujg2Gt66aQbDBlAUuCEhTgzlryanbV5wW1rM2pyodWDzrJZBZi4lH8ShHExu > JgHrZ7yiY+QA2DyBRatrFXN1xC2OihDB88igIfOfno5qEeEu2MgOvr6/1dc869vG > PY7yz8/Jwk2liThyDWG465SqWUMcsaFtg7GBInO52xvUQraHnd3SdbE0CqMQBm3g > hyFbokq0ycwnRCPgMpv0fYrXVFc3iW2kULn1ireJHW3p0iOszbihbDqExlecVr63 > Q4FKFHWk0BN6tHlLeeTHvpxKknvjTo3zK/mhc+BG2cyQeWAMK7Z6J/j00PuUK5Gh > PprIzicqN+QJFb2CCusrwrCxRflSEaJSXTNjkAHUUlu1RaI/eiFXnSS+caJvIXiu > KlL6iE88OaXhacYitjKh88B5iYngOi96o4kYT3ri3dFkPInEy/HFk7MXF/X2l6Pz > 89Hpxfh4Is7OxaOz08fji/HZKX47EaPTD8X749PHkVCaJwlAiiY+nVsK+g/0A0nn > Jt525RwO0jM0uQVOJBrk9sF2iLjT3p+enfbHpyfn49P3jp8dn15E4tnx+aMnUHD0 > 7vjp+OJDhuJkfHF6PJmIk7PzZiYmno/OL8aPXjwdnYvnL86fn02Og7ePBmICfbKE > HYPGaM5NFHcAoWQwXfIE/L/nbmfm6rfrzTtsQzLZqnmBsb1mwUPAIl358qa2JibN > 5vzttUkeZE3I2M0s/V/p2Radm1nqax0N5ZqM9B32RnPavMb4PAm71pXevIXWhrML > 6Ho5aZqyNQ6UbRfWUNRQ/IDGwX7y+MNe8PSDkNf18BVG12+iavcE7FLJkxlUfG1x > zabxFTrSppp0LZuqmIYqnoI4UpYcTFQHSTQPvQMjc5A0YhBBcVxxndF+ZhL6qqDu > w/U5LgLQ339zIwzuOb6b4pLXmSwHOhfqStlV27B4ctsRO2uvXLpjaLf9Uh35VyW9 > sV/cY0SHIvzKwo6pPfOJkdaD+LCsO33ntZMw2Kdhy1DER3eT6f04PXxwZ//w8GGc > 3FeHabp/f3+a3E3uHR148fwGYviKgT2teAwIh+LO/v5Rf/+wf+dAHNwZ3nkwvHd/ > cHCw89Pvvf6lW/TytH7H+uZrJ3+59elP/vrGW3vf/9OXP/n3V38du8t//uHs49/f > +vRv//jdL77xr99+/Oznv/r7Nz/747e+M/jg2X8A > =o8WM > -----END PGP MESSAGE----- > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: id_dsa.pub > Type: application/octet-stream > Size: 605 bytes > Desc: not available > Url : > https://www.redhat.com/archives/fedora-infrastructure-list/attachments/20070624/273f15da/id_dsa-0001.obj > > ------------------------------ > > Message: 4 > Date: Sun, 24 Jun 2007 16:31:46 +0200 > From: Michael Schwendt > Subject: Re: Problem with CLA > To: fedora-infrastructure-list at redhat.com > Message-ID: <20070624163146.800db909.bugs.michael at gmx.net> > Content-Type: text/plain; charset=US-ASCII > > On Sun, 24 Jun 2007 14:23:15 +0200, jan birsa wrote: > > > Hello, > > > > I hope you can help me here. > > My friend tryed to become a Fedora ambassador, but he gets this: > > "With regards to "Fedora Individual Contributor License Agreement". > > > > Your message could not be processed. > > > > Reason: > > > > The signature could not be processed. The signature may have been > created > > or attached improperly, it might not match the key ID you have > registered in > > the Account System, or the public key may not have been found on the key > > server. For guidance, please see the following page: > > " > > > > So I decided to register him. I used my mail and I connected to his > server > > trough SSH to make a gpg key and a id_dsa.pub(ssh key). I got a mail > with > > licence agreement, I added his name and " I agree" and made a .asc file. > I > > sent that AND I GET SAME MAIL ERROR. > > > > I attached all necessary files (I hope). > > You've attached the _private_ DSA key, too. Don't use this key pair > any longer now. > > Did you upload the public GPG key to a key server? > > $ gpg --recv-key 047B8DE9 > gpg: requesting key 047B8DE9 from hkp server pgp.mit.edu > gpgkeys: key 047B8DE9 not found on keyserver > gpg: no valid OpenPGP data found. > gpg: Total number processed: 0 > > > > ------------------------------ > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > > End of Fedora-infrastructure-list Digest, Vol 13, Issue 54 > ********************************************************** > -- jan at fedoraproject.org www.ex-planet.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kanarip at kanarip.com Mon Jun 25 10:01:57 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 25 Jun 2007 12:01:57 +0200 Subject: public mirror list 404 Message-ID: <467F9295.4050305@kanarip.com> A heads up for anyone not online in the IRC channel, but able to maybe fix things or wake up someone: * [H]omer (n=[H]omer at kgr.gotadsl.co.uk) has joined #fedora-admin <[H]omer> Hi <[H]omer> http://mirrors.fedoraproject.org/publiclist is showing a 404! <[H]omer> Did you guys know about this? nope i guess we didn't And indeed it does show up 404's from where I'm sitting, too. Kind regards, Jeroen van Meeuwen -kanarip From blizzard at redhat.com Mon Jun 25 19:32:38 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 25 Jun 2007 15:32:38 -0400 Subject: smolt, hardware compatibility and package stats In-Reply-To: <467E9EE6.50904@fedoraproject.org> References: <467D8221.9010200@fedoraproject.org> <467DBB3B.4060003@redhat.com> <467E9EE6.50904@fedoraproject.org> Message-ID: <1182799959.1264.42.camel@localhost.localdomain> On Sun, 2007-06-24 at 22:12 +0530, Rahul Sundaram wrote: > Mike McGrath wrote: > > Rahul Sundaram wrote: > >> > >> What do folks think of extending smolt into more of a system profiler > >> including optionally collecting information on installed packages? > >> > > > > I'm on the fence about this but would put package information lower in > > priority then some of the ratings system stuff. Mugshot is doing some > > package stuff already. > > True but that code is tied to mugshot (I asked) and would require users > to sign up with mugshot while Smolt is in first boot and I think many > end users would prefer the unobtrusive method. As long as we have it > optional (ie) I should be able to send the hardware details or the > packaging stats or both, it should be a useful thing to do. I would rather leave the packaging stuff up to the mugshot guys. They will add an interesting social aspect to it. What I _am_ interested for smolt, though, is hardware compatibility surveys. I think that Mike and I have discussed that in the past and we just never figured out how it would work. i.e. "does this laptop suspend with kernel X" which is different than the data we collect now which doesn't really change with time. It's a new set of data related to hardware that we can build entries with over time and be able to measure something important: how good we do with our hardware support and specific releases. --Chris From rtlm10 at gmail.com Mon Jun 25 21:41:56 2007 From: rtlm10 at gmail.com (Russell Harrison) Date: Mon, 25 Jun 2007 17:41:56 -0400 Subject: smolt, hardware compatibility and package stats In-Reply-To: <1182799959.1264.42.camel@localhost.localdomain> References: <467D8221.9010200@fedoraproject.org> <467DBB3B.4060003@redhat.com> <467E9EE6.50904@fedoraproject.org> <1182799959.1264.42.camel@localhost.localdomain> Message-ID: <1ed4a0130706251441p4a799d3eke91ce4ecbc568d01@mail.gmail.com> On 6/25/07, Christopher Blizzard wrote: > I would rather leave the packaging stuff up to the mugshot guys. They > will add an interesting social aspect to it. What I _am_ interested for > smolt, though, is hardware compatibility surveys. I think that Mike and > I have discussed that in the past and we just never figured out how it > would work. i.e. "does this laptop suspend with kernel X" which is > different than the data we collect now which doesn't really change with > time. It's a new set of data related to hardware that we can build > entries with over time and be able to measure something important: how > good we do with our hardware support and specific releases. > Doesn't knowing what's installed help determine what could be fighting with the hardware? Seems like there are two data points to capture. What's installed (seems like a good feature for smolt) and what's actually used (which mugshot is collecting now). What people are using has a social value. What people have installed has more value for support and future planning. I'm not saying the installed packages should have a high priority for smolt, but it should be on the road map, IMO. Russell ---- Russell Harrison Systems Administrator -- Linux Desktops Cisco Systems, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Mon Jun 25 22:10:25 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 25 Jun 2007 17:10:25 -0500 Subject: Iptables Solution In-Reply-To: <4676CFBB.9070503@redhat.com> References: <4676CFBB.9070503@redhat.com> Message-ID: <46803D51.4070502@redhat.com> Mike McGrath wrote: > lmacken, skvidal and xDamonx have been working together to create a > simple (and predictable) set of iptables rules. They're now ready and > xDamonx will be deploying them. The iptables template is done and > basically all thats needed to deploy is added to the manifests file. > For example, here's whats in our db group (as is in > manifests/servergroups/db.pp: > > > # firewall Rules > $tcpPorts = [ 3306, 5432 ] > $udpPorts = [ ] I've added custom rules to this. Now you can also add: $custom = [ '-A INPUT -p tcp -m blah blah', 'Some other rule' ] To the server groups. These rules are added directly before the tcp and udp rules. -Mike From blizzard at redhat.com Tue Jun 26 00:31:37 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 25 Jun 2007 20:31:37 -0400 Subject: smolt, hardware compatibility and package stats In-Reply-To: <1ed4a0130706251441p4a799d3eke91ce4ecbc568d01@mail.gmail.com> References: <467D8221.9010200@fedoraproject.org> <467DBB3B.4060003@redhat.com> <467E9EE6.50904@fedoraproject.org> <1182799959.1264.42.camel@localhost.localdomain> <1ed4a0130706251441p4a799d3eke91ce4ecbc568d01@mail.gmail.com> Message-ID: <1182817898.20006.5.camel@localhost.localdomain> On Mon, 2007-06-25 at 17:41 -0400, Russell Harrison wrote: > > Doesn't knowing what's installed help determine what could be fighting > with the hardware? Seems like there are two data points to capture. > What's installed (seems like a good feature for smolt) and what's > actually used (which mugshot is collecting now). What people are > using has a social value. What people have installed has more value > for support and future planning. I'm not saying the installed > packages should have a high priority for smolt, but it should be on > the road map, IMO. > I actually think that we need to capture a small bit of that information. i.e. kernel, hal, pm-utils and whatnot. But catching everything? Probably not really needed for hardware compat. (Maybe other things like NM, bluez-utils, etc.) Just trying to keep the scope pretty small. :) --Chris From a.badger at gmail.com Tue Jun 26 01:42:02 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 25 Jun 2007 18:42:02 -0700 Subject: New python-fedora Message-ID: <1182822122.4173.118.camel@localhost.localdomain> I've built a new python-fedora rpm 0.2.90.10-1 I've uploaded them into the pkgdb as I know some people now using python-fedora cannot access bastion. Source and binary rpms (FC6) are located here: https://admin.fedoraproject.org/pkgdb/static/download/python-fedora-0.2.90.10-1.noarch.rpm https://admin.fedoraproject.org/pkgdb/static/download/python-fedora-0.2.90.10-1.src.rpm Changes from 0.2.90.9: - Update fas2 integration with changes from mmcgrath. - berrange has changed his email address in the account system, no longer need to special case his bugzilla address. - Fix a bug in the handling of db errors in accounts/fas. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Tue Jun 26 17:45:44 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 26 Jun 2007 23:15:44 +0530 Subject: Smolt is down and FAS account issues Message-ID: <468150C8.3020704@fedoraproject.org> Hi http://smolt.fedoraproject.org/stats The devices section has been inaccessible for a while. I tried editing the wiki page which requires my FAS account. That wouldn't login and I tried resetting the password and haven't been mailed a link yet after around half an hour. Rahul From admin at arcnetworks.biz Tue Jun 26 17:51:07 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Tue, 26 Jun 2007 13:51:07 -0400 Subject: Smolt is down and FAS account issues In-Reply-To: <468150C8.3020704@fedoraproject.org> References: <468150C8.3020704@fedoraproject.org> Message-ID: <5d66540b0706261051k1a22f373y5a3be4d379e4d588@mail.gmail.com> On 6/26/07, Rahul Sundaram wrote: > > Hi > > http://smolt.fedoraproject.org/stats > > The devices section has been inaccessible for a while. I tried editing > the wiki page which requires my FAS account. That wouldn't login and I > tried resetting the password and haven't been mailed a link yet after > around half an hour. > > Rahul > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list Ok, I can login to my account at https://admin.fedoraproject.org/accounts BUT I can't access the smolt page (/stats or /devices) It gives me an error 500 -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at linux.duke.edu Tue Jun 26 17:59:17 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 26 Jun 2007 13:59:17 -0400 Subject: fpserv heads up and final call Message-ID: <1182880757.2790.8.camel@hodge> Hi folks, I'm going to nuke all of fpserv and start it over from scratch. I want to verify that no one is using anything in any of the following dirs on fpserv: /srv/mirrorStats /srv/zope /srv/web I'm going to back up /etc and as much of anything else as I can to a hotbackup before I nuke it - but please let me know if you see anything beforehand. Thanks! -sv From mmcgrath at redhat.com Tue Jun 26 22:13:05 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 26 Jun 2007 17:13:05 -0500 Subject: publictest1.fedora.redhat.com Message-ID: <46818F71.3040406@redhat.com> Its up! sysadmin-main has access, we should probably create a test group and start putting people in it. Do what you will. The following machines should be shut down (if possible) and migrated to publictest1. I'll leave it up to the sysadmin team to do theirs (if they have one) test3 test6 test7 test8 publictest4 There could be others but these are the ones I can think of. -Mike From mmcgrath at redhat.com Tue Jun 26 22:27:53 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 26 Jun 2007 17:27:53 -0500 Subject: Smolt is down and FAS account issues In-Reply-To: <5d66540b0706261051k1a22f373y5a3be4d379e4d588@mail.gmail.com> References: <468150C8.3020704@fedoraproject.org> <5d66540b0706261051k1a22f373y5a3be4d379e4d588@mail.gmail.com> Message-ID: <468192E9.30904@redhat.com> Anand Capur wrote: > > Ok, I can login to my account at > https://admin.fedoraproject.org/accounts > BUT I can't access the smolt page (/stats or /devices) It gives me an > error > 500 This should be fixed now (except for devices) we're working on caching some of that so it comes up properly. -Mike From samuel-bizien at club-internet.fr Wed Jun 27 08:40:48 2007 From: samuel-bizien at club-internet.fr (Samuel Bizien) Date: Wed, 27 Jun 2007 10:40:48 +0200 Subject: Wiki localization: patch wiki, or work with current tools ? Message-ID: <1182933648.2891.14.camel@localhost.localdomain> Hi, I'm Samuel Bizien, from l10n/fr team, working on wiki pages. For few days now, we've been discussing the idea to improve localization in the wiki, with websites list (https://www.redhat.com/archives/fedora-websites-list/2007-June/msg00169.html). The goal is to make easier for user to find the localized version of the page he is reading (in english, most of time). We've set up a wikipage to see how we could manage it manually: http://fedoraproject.org/wiki/L10N/Wikipages But it would be quite long to manage it this way. So, is it possible to manage it automatically ? Is it easier to patch wiki or to maintain these pages ? I've heard (from Ville-Pekka Vainio) that this is a feature that may appear in next version of moinmoin wiki. Could we patch our moinmoin wiki from development version ? Thanks for your answers. Regards, Samuel. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From vpivaini at cs.helsinki.fi Wed Jun 27 09:15:06 2007 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Wed, 27 Jun 2007 12:15:06 +0300 Subject: Wiki localization: patch wiki, or work with current tools ? In-Reply-To: <1182933648.2891.14.camel@localhost.localdomain> References: <1182933648.2891.14.camel@localhost.localdomain> Message-ID: <200706271215.06557.vpivaini@cs.helsinki.fi> Samuel Bizien kirjoitti viestiss??n (l?hetysaika keskiviikko, 27. kes?kuu 2007 11:40:48): > The goal is to make easier for user to find the localized version of the > page he is reading (in english, most of time). We've set up a wikipage > to see how we could manage it manually: > http://fedoraproject.org/wiki/L10N/Wikipages > But it would be quite long to manage it this way. > > So, is it possible to manage it automatically ? Is it easier to patch > wiki or to maintain these pages ? > I've heard (from Ville-Pekka Vainio) that this is a feature that may > appear in next version of moinmoin wiki. Could we patch our moinmoin > wiki from development version ? I had a chat about this on #moin-dev yesterday evening. The Moin multilang implementation works as wikifarms, so that you have en.wiki.tld, de.wiki.tld etc. and it links the same pages in those wikis together. This also means that you need to have the same page names in all wikis, so they can't be localized. An example of Moin multilang is at http://en.test.wikiwikiweb.de/TestWiki (de, en, fr in the top menu). It seems this is not the best option for Fedora Wiki, what do you think? I actually like the examples you have set up. It seems Wikipedia uses bots to manage the lists of translations, maybe same kind of bots could be written for Moin? -- Ville-Pekka Vainio vpivaini at cs.helsinki.fi From samuel-bizien at club-internet.fr Wed Jun 27 10:39:10 2007 From: samuel-bizien at club-internet.fr (Samuel Bizien) Date: Wed, 27 Jun 2007 12:39:10 +0200 Subject: Wiki localization: patch wiki, or work with current tools ? In-Reply-To: <200706271215.06557.vpivaini@cs.helsinki.fi> References: <1182933648.2891.14.camel@localhost.localdomain> <200706271215.06557.vpivaini@cs.helsinki.fi> Message-ID: <1182940750.10623.10.camel@localhost.localdomain> Le mercredi 27 juin 2007 ? 12:15 +0300, Ville-Pekka Vainio a ?crit : > Samuel Bizien kirjoitti viestiss??n (l?hetysaika keskiviikko, 27. kes?kuu 2007 > 11:40:48): > > The goal is to make easier for user to find the localized version of the > > page he is reading (in english, most of time). We've set up a wikipage > > to see how we could manage it manually: > > http://fedoraproject.org/wiki/L10N/Wikipages > > But it would be quite long to manage it this way. > > > > So, is it possible to manage it automatically ? Is it easier to patch > > wiki or to maintain these pages ? > > I've heard (from Ville-Pekka Vainio) that this is a feature that mayBut > > appear in next version of moinmoin wiki. Could we patch our moinmoin > > wiki from development version ? > > I had a chat about this on #moin-dev yesterday evening. The Moin multilang > implementation works as wikifarms, so that you have en.wiki.tld, de.wiki.tld > etc. and it links the same pages in those wikis together. This also means > that you need to have the same page names in all wikis, so they can't be > localized. > > An example of Moin multilang is at http://en.test.wikiwikiweb.de/TestWiki (de, > en, fr in the top menu). It seems this is not the best option for Fedora > Wiki, what do you think? Well ... i don't think it's the best solution, you're right. And thanks for the exaplanation about wikifarms (i searched on internet, and found nothing yesterday). > I actually like the examples you have set up. It seems Wikipedia uses bots to > manage the lists of translations, maybe same kind of bots could be written > for Moin? Can the infrastructure do that ? Maybe it could help to know that we (in french team) include the original page name in our pages (the first line, commented). See, for example, http://fedoraproject.org/wiki/fr_FR/Infrastructure?action=raw . If this was done for each translated pages, maybe it could be a way to identify all translations of a page. And, anyway, if we decide to use bots, we can start using subpages, until bots are coded. Samuel. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Christian.Iseli at licr.org Wed Jun 27 11:34:12 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 27 Jun 2007 13:34:12 +0200 Subject: Wiki slowness Message-ID: <20070627133412.75595e0c@ludwig-alpha.unil.ch> Hi folks, Just a bit of rant that I find the wiki very slow when updating the PackageStatus pages. For example, it took longer than 15 minutes between the time I pushed the "Save Changes" button until the browser started to display the updated page in the case of the PackageMaintainers/PackageStatus/OpenBugs page... I agree the size of those pages grew quite a bit, but I don't remember things being so slow with the previous wiki... If anyone has ideas to speed things up, I'll be waiting on the corner with lolling tongue :) Cheers, Christian From rtlm10 at gmail.com Wed Jun 27 11:54:01 2007 From: rtlm10 at gmail.com (Russell Harrison) Date: Wed, 27 Jun 2007 07:54:01 -0400 Subject: smolt, hardware compatibility and package stats In-Reply-To: <1182817898.20006.5.camel@localhost.localdomain> References: <467D8221.9010200@fedoraproject.org> <467DBB3B.4060003@redhat.com> <467E9EE6.50904@fedoraproject.org> <1182799959.1264.42.camel@localhost.localdomain> <1ed4a0130706251441p4a799d3eke91ce4ecbc568d01@mail.gmail.com> <1182817898.20006.5.camel@localhost.localdomain> Message-ID: <1ed4a0130706270454y59de27d4u8b6604d28e1aa32a@mail.gmail.com> On 6/25/07, Christopher Blizzard wrote: > > I actually think that we need to capture a small bit of that > information. i.e. kernel, hal, pm-utils and whatnot. But catching > everything? Probably not really needed for hardware compat. (Maybe > other things like NM, bluez-utils, etc.) > > Just trying to keep the scope pretty small. :) Understood, it just seems to be about the same amount of codding work to record everything rather than filtering stuff out. Now when you start talking about storage required. . . that is a different story. I think the reason I said it should be on the road map is in the future smolt can help with software compatibility as well. Again not a high priority given the current scope of smolt, just one for the list. What may be very valuable from a hardware compat standpoint is a record of packages that aren't in the fedora repos, especially kernel modules. We know people are going to be installing the nvidia and fglrx drivers, but what else are they installing because the stock kernel doesn't have drivers that do what they want. Russell ---- Russell Harrison Systems Administrator -- Linux Desktops Cisco Systems, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dimitris at glezos.com Wed Jun 27 13:04:44 2007 From: dimitris at glezos.com (Dimitris Glezos) Date: Wed, 27 Jun 2007 14:04:44 +0100 Subject: Wiki localization: patch wiki, or work with current tools ? In-Reply-To: <200706271215.06557.vpivaini@cs.helsinki.fi> References: <1182933648.2891.14.camel@localhost.localdomain> <200706271215.06557.vpivaini@cs.helsinki.fi> Message-ID: <4682606C.8060404@glezos.com> O/H Ville-Pekka Vainio ??????: > I had a chat about this on #moin-dev yesterday evening. The Moin multilang > implementation works as wikifarms, so that you have en.wiki.tld, de.wiki.tld > etc. and it links the same pages in those wikis together. This also means > that you need to have the same page names in all wikis, so they can't be > localized. Is there any other way to do it besides wikifarms? For example, by putting on the header of the english page links to all others and from all others to the english one (ie choose a language as the wiki's "main" lang)? -d -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From mmcgrath at redhat.com Wed Jun 27 13:50:31 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 27 Jun 2007 08:50:31 -0500 Subject: Smolt is down and FAS account issues In-Reply-To: <468150C8.3020704@fedoraproject.org> References: <468150C8.3020704@fedoraproject.org> Message-ID: <46826B27.4070708@redhat.com> Rahul Sundaram wrote: > Hi > > http://smolt.fedoraproject.org/stats > > The devices section has been inaccessible for a while. I tried editing > the wiki page which requires my FAS account. That wouldn't login and I > tried resetting the password and haven't been mailed a link yet after > around half an hour. Red Hat actually had some mail issues yesterday preventing some @rh.c addresses from getting mail. I actually didn't get this email until this morning (even though I got the reply last night). Can you verify that you have, in fact, gotten the email by now? -Mike From admin at arcnetworks.biz Wed Jun 27 13:54:23 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Wed, 27 Jun 2007 09:54:23 -0400 Subject: Smolt is down and FAS account issues In-Reply-To: <46826B27.4070708@redhat.com> References: <468150C8.3020704@fedoraproject.org> <46826B27.4070708@redhat.com> Message-ID: <5d66540b0706270654p1ebcbbe6l918d6bdca4b2ad33@mail.gmail.com> On 6/27/07, Mike McGrath wrote: > > Rahul Sundaram wrote: > > Hi > > > > http://smolt.fedoraproject.org/stats > > > > The devices section has been inaccessible for a while. I tried editing > > the wiki page which requires my FAS account. That wouldn't login and I > > tried resetting the password and haven't been mailed a link yet after > > around half an hour. > > Red Hat actually had some mail issues yesterday preventing some @rh.c > addresses from getting mail. I actually didn't get this email until > this morning (even though I got the reply last night). Can you verify > that you have, in fact, gotten the email by now? > > -Mike Yes I got this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Wed Jun 27 13:56:32 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 27 Jun 2007 08:56:32 -0500 Subject: Wiki slowness In-Reply-To: <20070627133412.75595e0c@ludwig-alpha.unil.ch> References: <20070627133412.75595e0c@ludwig-alpha.unil.ch> Message-ID: <46826C90.5050909@redhat.com> Christian Iseli wrote: > Hi folks, > > Just a bit of rant that I find the wiki very slow when updating the > PackageStatus pages. > > For example, it took longer than 15 minutes between the time I pushed > the "Save Changes" button until the browser started to display the updated page > in the case of the PackageMaintainers/PackageStatus/OpenBugs page... > > I agree the size of those pages grew quite a bit, but I don't remember > things being so slow with the previous wiki... > > If anyone has ideas to speed things up, I'll be waiting on the corner > with lolling tongue :) > 15 minutes? Damn. I can't believe the proxies didn't time that out. I'll investigate some today. -Mike From blizzard at redhat.com Wed Jun 27 14:00:37 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 27 Jun 2007 10:00:37 -0400 Subject: smolt, hardware compatibility and package stats In-Reply-To: <1ed4a0130706270454y59de27d4u8b6604d28e1aa32a@mail.gmail.com> References: <467D8221.9010200@fedoraproject.org> <467DBB3B.4060003@redhat.com> <467E9EE6.50904@fedoraproject.org> <1182799959.1264.42.camel@localhost.localdomain> <1ed4a0130706251441p4a799d3eke91ce4ecbc568d01@mail.gmail.com> <1182817898.20006.5.camel@localhost.localdomain> <1ed4a0130706270454y59de27d4u8b6604d28e1aa32a@mail.gmail.com> Message-ID: <1182952838.2707.4.camel@localhost.localdomain> On Wed, 2007-06-27 at 07:54 -0400, Russell Harrison wrote: > > > On 6/25/07, Christopher Blizzard wrote: > I actually think that we need to capture a small bit of that > information. i.e. kernel, hal, pm-utils and whatnot. But > catching > everything? Probably not really needed for hardware > compat. (Maybe > other things like NM, bluez-utils, etc.) > > Just trying to keep the scope pretty small. :) > > Understood, it just seems to be about the same amount of codding > work to record everything rather than filtering stuff out. Now when > you start talking about storage required. . . that is a different > story. I think the reason I said it should be on the road map is in > the future smolt can help with software compatibility as well. Again > not a high priority given the current scope of smolt, just one for the > list. Right. > > What may be very valuable from a hardware compat standpoint is a > record of packages that aren't in the fedora repos, especially kernel > modules. We know people are going to be installing the nvidia and > fglrx drivers, but what else are they installing because the stock > kernel doesn't have drivers that do what they want. > I actually think that "loaded kernel modules" is one of the things we want to capture for hardware compatibility questions. You could ask questions like "show me all the common modules for laptops that don't suspend" and you might learn a lot from the query about which modules may or may not be bad. At least it's a decent set of data to query. --Chris From sundaram at fedoraproject.org Wed Jun 27 15:57:21 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 27 Jun 2007 21:27:21 +0530 Subject: Smolt is down and FAS account issues In-Reply-To: <46826B27.4070708@redhat.com> References: <468150C8.3020704@fedoraproject.org> <46826B27.4070708@redhat.com> Message-ID: <468288E1.4050409@fedoraproject.org> Mike McGrath wrote: > Rahul Sundaram wrote: >> Hi >> >> http://smolt.fedoraproject.org/stats >> >> The devices section has been inaccessible for a while. I tried editing >> the wiki page which requires my FAS account. That wouldn't login and I >> tried resetting the password and haven't been mailed a link yet after >> around half an hour. > > Red Hat actually had some mail issues yesterday preventing some @rh.c > addresses from getting mail. I actually didn't get this email until > this morning (even though I got the reply last night). Can you verify > that you have, in fact, gotten the email by now? I have not. Rahul From mmcgrath at redhat.com Wed Jun 27 17:00:13 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 27 Jun 2007 12:00:13 -0500 Subject: Smolt is down and FAS account issues In-Reply-To: <468288E1.4050409@fedoraproject.org> References: <468150C8.3020704@fedoraproject.org> <46826B27.4070708@redhat.com> <468288E1.4050409@fedoraproject.org> Message-ID: <4682979D.7090502@redhat.com> Rahul Sundaram wrote: > Mike McGrath wrote: >> Red Hat actually had some mail issues yesterday preventing some @rh.c >> addresses from getting mail. I actually didn't get this email until >> this morning (even though I got the reply last night). Can you >> verify that you have, in fact, gotten the email by now? > > I have not. Check your junk/bulk mail, I can see that the email left our servers. -Mike From mmcgrath at redhat.com Wed Jun 27 21:24:39 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 27 Jun 2007 16:24:39 -0500 Subject: Test group and accounts cleanup Message-ID: <4682D597.5000503@redhat.com> I'm adding a test group for publictest1. I'm debating whether or not to have the test servers connect to a test instance of the accounts db... I think maybe as we mature it would be useful but right now will add more overhead (open to thoughts on this). There will be a test accounts db on publictest1... I'm not sure what content will be in it. Item 2: I'm going to be cleaning up some groups in the account system (for infrastructure) and will probably remove a group or two. If you feel you've been wrongly removed from a group, just let me know. We'll get you set back up. -Mike From santosp at fedoraproject.org Thu Jun 28 07:45:15 2007 From: santosp at fedoraproject.org (Paulo Santos) Date: Thu, 28 Jun 2007 09:45:15 +0200 Subject: Wiki localization: patch wiki, or work with current tools ? In-Reply-To: <4682606C.8060404@glezos.com> References: <1182933648.2891.14.camel@localhost.localdomain> <200706271215.06557.vpivaini@cs.helsinki.fi> <4682606C.8060404@glezos.com> Message-ID: <7a41c4bc0706280045w77867f35g9180bf82444e5ff2@mail.gmail.com> Here is my suggestion for the time being... We will need to add this for each language that its fully translated in the wiki RewriteCond %{HTTP:Accept-Language} ^fr.* RewriteRule ^/wiki/(.*)$ /wiki/$1_FR [R,L] So mainly, if any request is done by a browser that accepts FR language, rewrite the url to whatever it was + the language termination that we want. The only downside is that we needed to manually add the languages... What do you guys think ?! Paulo On 6/27/07, Dimitris Glezos wrote: > > O/H Ville-Pekka Vainio ??????: > > I had a chat about this on #moin-dev yesterday evening. The Moin > multilang > > implementation works as wikifarms, so that you have en.wiki.tld, > de.wiki.tld > > etc. and it links the same pages in those wikis together. This also > means > > that you need to have the same page names in all wikis, so they can't be > > localized. > > Is there any other way to do it besides wikifarms? For example, by putting > on > the header of the english page links to all others and from all others to > the > english one (ie choose a language as the wiki's "main" lang)? > > -d > > > -- > Dimitris Glezos > Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B > http://dimitris.glezos.com/ > > "He who gives up functionality for ease of use > loses both and deserves neither." (Anonymous) > -- > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dimitris at glezos.com Thu Jun 28 10:32:31 2007 From: dimitris at glezos.com (Dimitris Glezos) Date: Thu, 28 Jun 2007 11:32:31 +0100 Subject: Wiki localization: patch wiki, or work with current tools ? In-Reply-To: <7a41c4bc0706280045w77867f35g9180bf82444e5ff2@mail.gmail.com> References: <1182933648.2891.14.camel@localhost.localdomain> <200706271215.06557.vpivaini@cs.helsinki.fi> <4682606C.8060404@glezos.com> <7a41c4bc0706280045w77867f35g9180bf82444e5ff2@mail.gmail.com> Message-ID: <46838E3F.8060905@glezos.com> O/H Paulo Santos ??????: > Here is my suggestion for the time being... > We will need to add this for each language that its fully translated in > the wiki FWIW, our wiki *does* support localization through simple Language dictionaries. See: http://fedoraproject.org/wiki/FrenchDict At a point you can spot: FedoraMain :: fr_FR/FedoraPrincipal That line is used to automatically redirect a french browser to the french main page of the wiki. Our concern is how to present a language box for each page, showing links to the other versions of the same page. This is somewhat the opposite of the above language-based method, and would require for each page reload to scan all language dictionaries and present only those that have the dictionary entry for the particular page. -d -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From samuel-bizien at club-internet.fr Thu Jun 28 11:56:45 2007 From: samuel-bizien at club-internet.fr (Samuel Bizien) Date: Thu, 28 Jun 2007 13:56:45 +0200 Subject: Wiki localization: patch wiki, or work with current tools ? In-Reply-To: <7a41c4bc0706280045w77867f35g9180bf82444e5ff2@mail.gmail.com> References: <1182933648.2891.14.camel@localhost.localdomain> <200706271215.06557.vpivaini@cs.helsinki.fi> <4682606C.8060404@glezos.com> <7a41c4bc0706280045w77867f35g9180bf82444e5ff2@mail.gmail.com> Message-ID: <1183031806.2882.13.camel@localhost.localdomain> Le jeudi 28 juin 2007 ? 09:45 +0200, Paulo Santos a ?crit : > Here is my suggestion for the time being... > We will need to add this for each language that its fully translated > in the wiki > > RewriteCond %{HTTP:Accept-Language} ^fr.* > RewriteRule ^/wiki/(.*)$ /wiki/$1_FR [R,L] > > So mainly, if any request is done by a browser that accepts FR > language, rewrite the url to whatever it was + the language > termination that we want. > > The only downside is that we needed to manually add the languages... > What do you guys think ?! Well ... I don't think it would work well. Because: 1. For the moment, even the name of wikipages are localized (Join becomes fr_FR/RejoindreFedora in French, de_DE/Beitreten in german ...). But we could decide to use english name everywhere, if this was needed. 2. The wiki will never be fully localized (because there is changes every hour). As Dimitris, I think language boxes are better for localization, because user can come back to localized version of wiki easily, when some pages he asked for are not translated. And bots could, then, help us a lot. About *Dict pages, do they work ? Some pages that are in FrenchDict does not redirect me automatically to localized page. Regards, Samuel. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From sundaram at fedoraproject.org Thu Jun 28 14:37:36 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 28 Jun 2007 20:07:36 +0530 Subject: Smolt is down and FAS account issues In-Reply-To: <4682979D.7090502@redhat.com> References: <468150C8.3020704@fedoraproject.org> <46826B27.4070708@redhat.com> <468288E1.4050409@fedoraproject.org> <4682979D.7090502@redhat.com> Message-ID: <4683C7B0.2010303@fedoraproject.org> Mike McGrath wrote: > Rahul Sundaram wrote: >> Mike McGrath wrote: >>> Red Hat actually had some mail issues yesterday preventing some @rh.c >>> addresses from getting mail. I actually didn't get this email until >>> this morning (even though I got the reply last night). Can you >>> verify that you have, in fact, gotten the email by now? >> >> I have not. > > Check your junk/bulk mail, I can see that the email left our servers. Requested again and got the link. I have edited the smolt wiki page in hosted.fp.o to correct the Smolt scope definition. Thanks, Rahul From sundaram at fedoraproject.org Thu Jun 28 14:39:07 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 28 Jun 2007 20:09:07 +0530 Subject: Fedora 7 Update Informatin for general users In-Reply-To: <369bce3b0706022328m2f2fe419hd62a447b97c05d98@mail.gmail.com> References: <369bce3b0706022328m2f2fe419hd62a447b97c05d98@mail.gmail.com> Message-ID: <4683C80B.3090502@fedoraproject.org> Thomas Chung wrote: > First all, thank you for Fedora Update System. > It's wonderful to see that we finally have something we always wanted. > > While looking at the list of Stable Updates for Fedora 7[1], it gives > me an idea that this could replace our static Fedora Security > Advisories and Package Updates for Fedora 7[1] on our project wiki. > > What do you think? Could we open this system up so any general users > can see this information anonymously without logging-in with Fedora > Account System? > Can anyone kindly answer this? It would save a lot of manual effort. Thanks. Rahul From jkeating at redhat.com Thu Jun 28 14:41:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Jun 2007 10:41:21 -0400 Subject: Fedora 7 Update Informatin for general users In-Reply-To: <4683C80B.3090502@fedoraproject.org> References: <369bce3b0706022328m2f2fe419hd62a447b97c05d98@mail.gmail.com> <4683C80B.3090502@fedoraproject.org> Message-ID: <200706281041.21716.jkeating@redhat.com> On Thursday 28 June 2007 10:39:07 Rahul Sundaram wrote: > Thomas Chung wrote: > > First all, thank you for Fedora Update System. > > It's wonderful to see that we finally have something we always wanted. > > > > While looking at the list of Stable Updates for Fedora 7[1], it gives > > me an idea that this could replace our static Fedora Security > > Advisories and Package Updates for Fedora 7[1] on our project wiki. > > > > What do you think? Could we open this system up so any general users > > can see this information anonymously without logging-in with Fedora > > Account System? > > Can anyone kindly answer this? It would save a lot of manual effort. > Thanks. > > Rahul > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list Filing an RFE in Trac is better than in a mailing list. I don't think anybody sees anything wrong with an anonymous view of the updates system, there is just a lot more important stuff to get done first. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Thu Jun 28 16:29:44 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 28 Jun 2007 11:29:44 -0500 Subject: Meeting today Message-ID: <4683E1F8.3040509@redhat.com> Just a reminder there's a meeting today in #fedora-meeting on irc.freenode.net. http://fedoraproject.org/wiki/Infrastructure/Meetings. We'll be following http://fedoraproject.org/wiki/Infrastructure/Schedule as usual. I want to talk about the whole OTRS vs Mail vs Hosted site first. We'll probably be voting so if you have an opinion, show up and vote. -Mike From paulo.banon at googlemail.com Thu Jun 28 16:30:41 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Thu, 28 Jun 2007 18:30:41 +0200 Subject: Meeting today In-Reply-To: <4683E1F8.3040509@redhat.com> References: <4683E1F8.3040509@redhat.com> Message-ID: <7a41c4bc0706280930t2d2cea5m24fd60e0f62ad3a8@mail.gmail.com> I'm back from US, so i'll definitly be there :) Paulo On 6/28/07, Mike McGrath wrote: > > Just a reminder there's a meeting today in #fedora-meeting on > irc.freenode.net. > http://fedoraproject.org/wiki/Infrastructure/Meetings. We'll be > following http://fedoraproject.org/wiki/Infrastructure/Schedule as usual. > > I want to talk about the whole OTRS vs Mail vs Hosted site first. We'll > probably be voting so if you have an opinion, show up and vote. > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmacken at redhat.com Thu Jun 28 18:19:32 2007 From: lmacken at redhat.com (Luke Macken) Date: Thu, 28 Jun 2007 14:19:32 -0400 Subject: Fedora 7 Update Informatin for general users In-Reply-To: <200706281041.21716.jkeating@redhat.com> References: <369bce3b0706022328m2f2fe419hd62a447b97c05d98@mail.gmail.com> <4683C80B.3090502@fedoraproject.org> <200706281041.21716.jkeating@redhat.com> Message-ID: <20070628181932.GE2703@tomservo.rochester.rr.com> On Thu, Jun 28, 2007 at 10:41:21AM -0400, Jesse Keating wrote: > On Thursday 28 June 2007 10:39:07 Rahul Sundaram wrote: > > Thomas Chung wrote: > > > First all, thank you for Fedora Update System. > > > It's wonderful to see that we finally have something we always wanted. > > > > > > While looking at the list of Stable Updates for Fedora 7[1], it gives > > > me an idea that this could replace our static Fedora Security > > > Advisories and Package Updates for Fedora 7[1] on our project wiki. > > > > > > What do you think? Could we open this system up so any general users > > > can see this information anonymously without logging-in with Fedora > > > Account System? > > > > Can anyone kindly answer this? It would save a lot of manual effort. > > Thanks. > > > > Rahul > > Filing an RFE in Trac is better than in a mailing list. I don't think anybody > sees anything wrong with an anonymous view of the updates system, there is > just a lot more important stuff to get done first. https://hosted.fedoraproject.org/projects/bodhi/ticket/43 Shouldn't be very hard to implement; I think we can probably get away with simply wrapping the update actions and sidebar with
I've been trying to get a huge bodhi upgrade out the door, but keep finding myself just trying to squeeze in "just one more feature". I'll get RSS feeds and anonymous access working after I get this other stuff released. luke From rayvd at bludgeon.org Thu Jun 28 19:48:02 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Thu, 28 Jun 2007 12:48:02 -0700 Subject: Streamlining Account Signup Process Message-ID: <20070628194801.GA20206@bludgeon.org> This question stems from a post on the CentOS mailing list -- a fellow wanted to add a couple items to the EPEL Wishlist but wasn't sure how. I suggested he get a Wiki account and add it himself (probably should have just added it for him, but...). In any case, here's his rant: http://lists.centos.org/pipermail/centos/2007-June/083203.html I think I agree with him in spirit that getting a Wiki / FAS account set up is a bit of a daunting process. I pointed him here: http://fedoraproject.org/wiki/WikiEditing#head-3d4b8815f923a8f137fb466901ca2cf1b567cf0f Which has links pointing to other lists of tasks to do -- it can get rather spaghetti like, especially when you don't understand why you're generating all these SSH keys and GPG keys, etc :) My questions are as follows: 1. Is this the appropriate list to discuss this issue on? 2. Do you guys agree that the signup process is overly complex? Or does the process partially serve to ensure that the candidate is sufficiently motivated and persistent? :) 3. If so, can we discuss a way to simplify it? Alternately... 4. Would maybe reorganizing the documentation for getting an account be the most helpful in the short-term? Also, maybe just a blurb on the EPEL wish list describing an easier way to request package additions there would be helpful. Even if it's just "join the mailing list and ask" or "ask on IRC". This is like a question for epel-devel however. I know one of your guys' overall goals has always been to get more community involvement, so I figured this was a worthwhile question to ask. I know I almost decided that it wasn't worth the effort to join the FP after seeing all those steps for signup when I just wanted to contribute one package initially (I'm happy I didn't bail btw)... I imagine many others feel the same way. Ray PS: I know I haven't proposed any solutions. Still trying to wrap my head around what those might be, but wanted to throw this out there. From mmcgrath at redhat.com Thu Jun 28 19:57:31 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 28 Jun 2007 14:57:31 -0500 Subject: Streamlining Account Signup Process In-Reply-To: <20070628194801.GA20206@bludgeon.org> References: <20070628194801.GA20206@bludgeon.org> Message-ID: <468412AB.1050903@redhat.com> Ray Van Dolson wrote: > This question stems from a post on the CentOS mailing list -- a fellow > wanted to add a couple items to the EPEL Wishlist but wasn't sure how. > > I suggested he get a Wiki account and add it himself (probably should > have just added it for him, but...). In any case, here's his rant: > > http://lists.centos.org/pipermail/centos/2007-June/083203.html > > I think I agree with him in spirit that getting a Wiki / FAS account > set up is a bit of a daunting process. > > I pointed him here: > > http://fedoraproject.org/wiki/WikiEditing#head-3d4b8815f923a8f137fb466901ca2cf1b567cf0f > > Which has links pointing to other lists of tasks to do -- it can get > rather spaghetti like, especially when you don't understand why you're > generating all these SSH keys and GPG keys, etc :) > > FAS2 won't have this requirement for a generic account. > My questions are as follows: > > 1. Is this the appropriate list to discuss this issue on? > absolutely. > 2. Do you guys agree that the signup process is overly complex? Or > does the process partially serve to ensure that the candidate is > sufficiently motivated and persistent? :) > It was a legal constraint > 3. If so, can we discuss a way to simplify it? > A simpler wiki setup is actually on its way. quaid, paulobanon: care to comment further? -Mike From sundaram at fedoraproject.org Thu Jun 28 20:02:51 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 Jun 2007 01:32:51 +0530 Subject: Streamlining Account Signup Process In-Reply-To: <468412AB.1050903@redhat.com> References: <20070628194801.GA20206@bludgeon.org> <468412AB.1050903@redhat.com> Message-ID: <468413EB.70208@fedoraproject.org> Mike McGrath wrote: > > A simpler wiki setup is actually on its way. quaid, paulobanon: care to > comment further? > They are waiting on infrastructure team to enable click through signup on the wiki. Karsten Wade (quaid) posted a request here with no response. That would be the best fix within the legal constraints for this (known) problem. Rahul From rayvd at bludgeon.org Thu Jun 28 20:16:46 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Thu, 28 Jun 2007 13:16:46 -0700 Subject: Streamlining Account Signup Process In-Reply-To: <468413EB.70208@fedoraproject.org> References: <20070628194801.GA20206@bludgeon.org> <468412AB.1050903@redhat.com> <468413EB.70208@fedoraproject.org> Message-ID: <20070628201646.GA20914@bludgeon.org> On Fri, Jun 29, 2007 at 01:32:51AM +0530, Rahul Sundaram wrote: > Mike McGrath wrote: > > > A simpler wiki setup is actually on its way. quaid, paulobanon: care to > > comment further? > > They are waiting on infrastructure team to enable click through signup on > the wiki. Karsten Wade (quaid) posted a request here with no response. That > would be the best fix within the legal constraints for this (known) problem. Sounds good. No point then in discussing further until the new system is in place. Apologies for the noise and thanks for clarifying. I'll take a look at the project's wiki page and see if I can assist... (devs holler if you need anything specific! I can test, program, document, whatever). Ray From sundaram at fedoraproject.org Thu Jun 28 20:19:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 Jun 2007 01:49:55 +0530 Subject: Streamlining Account Signup Process In-Reply-To: <20070628194801.GA20206@bludgeon.org> References: <20070628194801.GA20206@bludgeon.org> Message-ID: <468417EB.9020209@fedoraproject.org> Ray Van Dolson wrote: > > Also, maybe just a blurb on the EPEL wish list describing an easier way > to request package additions there would be helpful. Even if it's just > "join the mailing list and ask" or "ask on IRC". This is like a > question for epel-devel however. Yep but fixed anyway. See http://fedoraproject.org/wiki/EPEL/WishList > I know one of your guys' overall goals has always been to get more > community involvement, so I figured this was a worthwhile question to > ask. I know I almost decided that it wasn't worth the effort to join > the FP after seeing all those steps for signup when I just wanted to > contribute one package initially (I'm happy I didn't bail btw)... I > imagine many others feel the same way. So why didn't you bail out and what are you happy with? Not rhetoric. I am genuinely interested to know. Thanks for the feedback. We know that editing the wiki for someone not in the edit group is way too complicated than necessary. The underlying problem required legal clarification which we have got recently. The wiki contributors can just require a click through signup but that requires some infrastructure work that hasn't done yet but it is something that needs to be fixed asap. Rahul From rayvd at bludgeon.org Thu Jun 28 20:35:09 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Thu, 28 Jun 2007 13:35:09 -0700 Subject: Streamlining Account Signup Process In-Reply-To: <468417EB.9020209@fedoraproject.org> References: <20070628194801.GA20206@bludgeon.org> <468417EB.9020209@fedoraproject.org> Message-ID: <20070628203509.GA21321@bludgeon.org> On Fri, Jun 29, 2007 at 01:49:55AM +0530, Rahul Sundaram wrote: > So why didn't you bail out and what are you happy with? Not rhetoric. I am > genuinely interested to know. I started lurking on some of the #fedora channels and jumped on a bunch of the mailing lists. In the end, listening to a lot of the discussions finally concvinced me that I wanted to be part of the project, so I just went ahead and signed up and contributed my package. I am trying to get my work to use RHEL/CentOS more and more, and so getting the packages in place in an "official" repo (EPEL) is somewhat important to that. In this case I had the power to make it happen myself and so it was worth signing up and I'm glad I did. > Thanks for the feedback. We know that editing the wiki for someone not in > the edit group is way too complicated than necessary. The underlying problem > required legal clarification which we have got recently. The wiki > contributors can just require a click through signup but that requires some > infrastructure work that hasn't done yet but it is something that needs to > be fixed asap. Appreciate all the work you guys do. Ray From mmcgrath at redhat.com Thu Jun 28 20:36:39 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 28 Jun 2007 15:36:39 -0500 Subject: Streamlining Account Signup Process In-Reply-To: <468413EB.70208@fedoraproject.org> References: <20070628194801.GA20206@bludgeon.org> <468412AB.1050903@redhat.com> <468413EB.70208@fedoraproject.org> Message-ID: <46841BD7.30908@redhat.com> Rahul Sundaram wrote: > Mike McGrath wrote: > >> >> A simpler wiki setup is actually on its way. quaid, paulobanon: care >> to comment further? >> > > They are waiting on infrastructure team to enable click through signup > on the wiki. Karsten Wade (quaid) posted a request here with no > response. That would be the best fix within the legal constraints for > this (known) problem. paulobanon is the infrastructure team member working on it with quaid. -Mike From tchung at fedoraproject.org Thu Jun 28 20:39:49 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Thu, 28 Jun 2007 13:39:49 -0700 Subject: Fedora 7 Update Informatin for general users In-Reply-To: <20070628181932.GE2703@tomservo.rochester.rr.com> References: <369bce3b0706022328m2f2fe419hd62a447b97c05d98@mail.gmail.com> <4683C80B.3090502@fedoraproject.org> <200706281041.21716.jkeating@redhat.com> <20070628181932.GE2703@tomservo.rochester.rr.com> Message-ID: <369bce3b0706281339t634168fasdd6430936a409d19@mail.gmail.com> On 6/28/07, Luke Macken wrote: > https://hosted.fedoraproject.org/projects/bodhi/ticket/43 > > Shouldn't be very hard to implement; I think we can probably get away > with simply wrapping the update actions and sidebar with > >
> > I've been trying to get a huge bodhi upgrade out the door, but keep > finding myself just trying to squeeze in "just one more feature". > > I'll get RSS feeds and anonymous access working after I get this other > stuff released. > > luke Thank you Luke, I really appreciated. Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From jeff at ocjtech.us Thu Jun 28 21:01:25 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Thu, 28 Jun 2007 16:01:25 -0500 Subject: Fedora Infrastructure IRC Meeting Log from 2007-06-28 Message-ID: <1183064485.3809.21.camel@lt21223.campus.dmacc.edu> [15:01] mmcgrath has set the subject to Fedora Infrastructure -- Who's here [15:01] mmcgrath: ping all, who's here? [15:01] * skvidal is here [15:02] * xDamox is here [15:02] * Bob-Laptop is not here but does not really count yet [15:02] mmcgrath: paulobanon, dgilmore, mbonnet__, mbonnet, abadger1999, f13: ping [15:02] * paulobanon is here [15:03] notting has joined the group chat (n=notting at redhat/notting) [15:03] * abadger1999 is here [15:03] mmcgrath: allright [15:04] mmcgrath has set the subject to Fedora Infrastructure -- Ticketing System [15:04] mmcgrath: Lets talk about this and try to come to a conclusion today. [15:04] * mmcgrath notes the schedule - http://fedoraproject.org/wiki/Infrastructure/Schedule [15:04] mmcgrath: So here's my current concern. [15:04] mmcgrath: I'm getting a lot of emails for requests for stuff that anyone in the team could do. [15:05] mmcgrath: So as we discussed on the list the options are moving to a mailing list or trac. [15:05] mmcgrath: What do you guys think? (you don't have to be in the Infrastructure team to have a comment on this) [15:05] paulobanon: trac for me [15:06] skvidal: I can adapt to either - I think a list is easy - but if there's an rss feed for trac I'll accept that [15:06] mmcgrath: skvidal: good question. [15:06] mmcgrath: f13: does track have an rss feeder? [15:07] * mmcgrath thinks f13 is away. [15:07] skvidal: Indeed [15:07] abadger1999: trac has an rss feed for timeline. Not sure if tickets show up in timeline or not. [15:07] paulobanon: http://trac.edgewall.org/wiki/TracRss [15:07] mmcgrath: abadger1999: are you a trac fan or a mail list fan? [15:08] paulobanon: yes it support tickets [15:08] abadger1999: We need to have both a ml and ticketing system. [15:09] mmcgrath: k, so I'll work on getting a trac system setup and properly configured with Infrastructure for us to take a look at. We can decide to keep it and announce it hopefully next week. [15:09] paulobanon: sounds good [15:10] mmcgrath: ok, moving on. [15:10] mmcgrath has set the subject to Fedora Infrastructure -- Package Database [15:10] mmcgrath: abadger1999: how are you and G doing? [15:11] G: I've been a little bit on hold, I've got next week off, so I hope to dedicate a bit of time to it [15:11] mmcgrath: G: cool. [15:11] mmcgrath: G: where are you two currently running tests from? [15:12] G: Toshio created a hosted instance though (http://hosted.fedoraproject.org/projects/packagedb [15:12] G: err. test3 I think [15:12] mmcgrath: test3, k. [15:12] mmcgrath: k, moving on. [15:13] mmcgrath: Nothing new in configuration managemnt. [15:13] mmcgrath has set the subject to Fedora Infrastructure -- VCS choice [15:13] mmcgrath: jcollie: ping [15:13] jcollie: mmcgrath, wassup? [15:13] jcollie: oops [15:14] mmcgrath: I'm going to have some publictest1 space for you soon for http://fedoraproject.org/wiki/Infrastructure/RFR/GitPackageVCS [15:14] jcollie: on a phone call, but no progress since last week [15:14] jcollie: mmcgrath, thanks! [15:14] mmcgrath: jcollie: k, can you apply for the sysadmin-test group when you get a mment? [15:14] jcollie: sure [15:14] * mmcgrath will continue [15:15] mmcgrath has set the subject to Fedora Infrastructure -- Firewall system rewrite [15:15] mmcgrath: xDamox: how's all that going? [15:15] mmcgrath: and the new custom rules? [15:15] xDamox: mmcgrath, just got to get skvidal to check over this torrent policy [15:15] skvidal: xDamox: I did check it over [15:15] skvidal: is there a new one? [15:15] xDamox: the one in my home dir? [15:16] xDamox: on lockbox [15:16] abadger1991 has joined the group chat (n=abadger1 at 068.187-78-65.ftth.swbr.surewest.net) [15:16] riel has joined the group chat (n=riel at bree.surriel.com) [15:16] skvidal: did you tell me about those before today? [15:16] skvidal: I looked at what we talked about before [15:16] xDamox: nope [15:16] skvidal: oh, okay [15:16] xDamox: I was going to email you tonight [15:17] MrBawb has joined the group chat (i=abob at guppy.drown.org) [15:17] skvidal: yes, continue with that plan [15:17] skvidal: [15:17] skvidal: thank you [15:17] mmcgrath: [15:17] xDamox: if your happy I can check them in to puppet and firewall will be done [15:17] * dgilmore is here [15:17] * abadger1991 back [15:18] mmcgrath: xDamox: excellent. [15:18] skvidal: cool-mo-dee [15:18] xDamox: [15:18] mmcgrath: xDamox: anything else? [15:18] xDamox: do you want any firewall rules applied to xen? [15:19] JSchmitt has joined the group chat (n=s4504kr at p54B1127B.dip0.t-ipconnect.de) [15:19] xDamox: XEN are the only hosts without firewall rules [15:19] dgilmore: xDamox: yes but we need to work out what [15:19] xDamox: yea not a problem [15:19] mmcgrath: ahhh yes. [15:19] mmcgrath: So here's the problems to overcome. [15:19] mmcgrath: We'd like to be able to block traffic from the xen guests at the xen host. [15:19] dgilmore: xDamox: we have some guests we want almost no access to others inside the colo [15:20] mmcgrath: Note, the xen guests will move around so its probably smart to have the same rules on all xen hosts. [15:20] dgilmore: probbaly need to use ebtables on the xen bridge [15:20] xDamox: Ok [15:20] mmcgrath: and 2) the interface name might change when migrating around so rules based off of interface won't work. [15:20] mmcgrath: ip rules off of IP are easy to circumvent [15:20] mmcgrath: ip rules off of mac may be spoofable (but could be our best bet) [15:21] mmcgrath: Any suggestions there? [15:21] xDamox: I would go with MAC addresses [15:21] dgilmore: mac address absed rules on the bridges [15:21] xDamox: that would be the best bet [15:22] mmcgrath: dgilmore: ahh, very true. [15:22] fchiulli has left ("CGI:IRC (Ping timeout)" (i=824c400f at gateway/web/cgi-irc/ircatwork.com/x-63cc1cf3a5d2721f)) [15:22] warren: The guests cannot change their MAC [15:22] warren: ? [15:22] mmcgrath: ok, so we can work on those when the time comes. [15:22] mmcgrath: warren: the guest can probably change it but the host won't honor it. [15:22] warren: ah [15:22] mmcgrath: at least in theory, we'll have to test that. [15:22] warren: sounds like a plan [15:23] warren: You might not need to use ebtables though [15:23] warren: I've used iptables MAC module before [15:23] fchiulli has joined the group chat (i=824c400f at gateway/web/cgi-irc/ircatwork.com/x-1f7399ce8f2ba354) [15:23] dgilmore: warren: ona bridge? SmootherFrOgZ_id is now known as SmootherFrOgZ [15:23] warren: dgilmore, oh, good question. [15:23] warren: It is worth trying though [15:24] warren: If it works, that's one less additional thing to track [15:24] mmcgrath: we should take this to the list. [15:24] warren: agreed [15:24] dgilmore: mmcgrath: quite possibly we could do rules for known macs we want to allow access then deny everything else [15:25] abadger1999 has left (No route to host (n=abadger1 at 068.187-78-65.ftth.swbr.surewest.net)) [15:25] mmcgrath: dgilmore: thats true, its good to know we have options. We'll just have to find the solution thats best for our environment. [15:25] dgilmore: so if they change mac and its honored we still drop [15:25] mmcgrath: [15:25] mmcgrath: I skipped one item [15:25] paulobanon: +1 [15:25] mmcgrath has set the subject to Fedora Infrastructure -- DB1 upgrade [15:25] mmcgrath: mbonnet__: ping? [15:25] mmcgrath: mbonnet: ? [15:25] lennert: iptables can filter on --mac-source on input/forward, anything more fancy needs ebtables abadger1991 is now known as abadger1999 [15:25] mmcgrath: Right now we're just waiting on the ok from mbonnet to make sure the new postfix version will support koji. [15:26] mbonnet__: mmcgrath: sorry, in a meeting [15:26] mmcgrath: mbonnet__: no worries, I'll just move to the next item. [15:26] mmcgrath: but thats where db1 is at right now. [15:26] mmcgrath has set the subject to Fedora Infrastructure -- Server Upgrades [15:26] abadger1999: s/postfix/postgres/ [15:26] warren: mmcgrath, what about postfix doesn't support koji? [15:26] mmcgrath: abadger1999: err yes [15:26] warren: oh [15:26] warren: =) [15:26] * mmcgrath has post on the mind [15:27] mmcgrath: So I'm working with the soc on some items with the server upgrade. [15:27] dgilmore: mmcgrath: for what its worth my koji install has a FC-6 based postgres [15:27] paulobanon: i think everyone got confused with that one [15:27] mmcgrath: dgilmore: excellent. [15:27] mmcgrath: The new disk tray for our builders came in and is now in use. [15:27] dgilmore: running on sparc but its FC-6 [15:27] dgilmore: [15:27] mmcgrath: 2.0T 691G 1.3T 35% /mnt/ntap-fedora1/fedora [15:27] dgilmore: f13: dont fill it [15:27] warren: sparc? [15:28] dgilmore: warren: yes sparc [15:28] mmcgrath: I think there's some koji work to enable better garbage collection. Keep in mind whats in our 691G of space right now. [15:28] mmcgrath: Just Fedora 7. [15:28] mmcgrath: well and some other stuff. [15:29] dgilmore: mmcgrath: rawhide also [15:29] mmcgrath: Also I'm working with the soc to get some warranty stuff figured out. There's some server's I need to double check. [15:29] mmcgrath: rawhide. [15:29] mmcgrath: which right now is basically F7 [15:29] mmcgrath has set the subject to Fedora Infrastruture -- Xen Conversions [15:29] mmcgrath: I've converted a few more boxes to the iscsi share. We're up to... [15:30] mmcgrath: 12 hosts at present. [15:30] mmcgrath: many of them test, a few of them are production. [15:30] paulobanon: how many left _ [15:30] paulobanon: ? [15:31] mmcgrath: paulobanon: depends, I don't have a final count right now but by the time we get the server upgrades the target number will change drastically. [15:31] paulobanon: k k [15:31] mmcgrath: thats all the priority 1 stuff [15:31] mmcgrath: Nothing new on bacula [15:31] mmcgrath: translators stuff is still going well [15:31] mmcgrath: nothing new on accoutns [15:32] skvidal: did everyone look to make sure they had all their stuff off of fpserv? [15:32] mmcgrath: f13 isn't around but I suspect nothing terribly new on hosted. [15:32] skvidal: I emailed about it but didn't get any response [15:32] mmcgrath has set the subject to Fedora Infrastruture -- FedoraPeople.org [15:32] mmcgrath: skvidal: everything I have on there should be vanishable [15:33] skvidal: okie doke [15:33] skvidal: I'll take that as definitive [15:33] mmcgrath: heh [15:33] paulobanon: kill fpserv! [15:33] paulobanon: [15:33] mmcgrath has set the subject to Fedora Infrastructure -- Ibiblio Mirror [15:33] skvidal: thank you [15:33] mmcgrath: I've been laxed on this, I just need to test that they have everything exported correctly. [15:34] mmcgrath: then find some testers. [15:34] mmcgrath: So thats all the stuff on the schedule. [15:34] mmcgrath has set the subject to Fedora Infrastructure -- Open Floor [15:34] mmcgrath: Anyone have anything they'd like to discuss? [15:34] dgilmore: skvidal: i had nothing on fpserv [15:34] skvidal: dgilmore: cool [15:34] mmcgrath: notting: ping [15:34] skvidal: dgilmore: I just wanted to be sure [15:35] notting: mmcgrath: yes? [15:36] paulobanon: whats with all priority 3 stuff ? is it something that we even want to have there and move it to a thinking about it section ?! [15:36] paulobanon: s/and/or [15:36] mmcgrath: notting: do you have a moment to discuss the signing server? [15:37] mmcgrath: paulobanon: I don't know what is with that stuff. [15:37] mmcgrath: paulobanon: that reminds me though can you add the wiki cla stuff you're doing with quaid to the list in priority 2? [15:37] paulobanon: yup [15:37] notting: mmcgrath: sure [15:38] mmcgrath: notting: just give us a quick overview of what you guys are doing, what you'll need and what problem it solves. [15:39] notting: ok [15:39] notting: first of all, lots of info at http://fedoraproject.org/wiki/JesseKeating/SigningServerSpecDraft [15:39] mmcgrath: ohhh, very nice. [15:40] notting: the idea is that instead of just handing out gpg keys and passphrases, we use a signing server to sign packages [15:40] * warren yay! [15:40] notting: this server will have lists of what people (FAS accounts) are allowed to sign with what keys [15:40] notting: there is some code that RH has [15:40] notting: however, to use a) FAS b) koji it's going to take a lot of hacking. might just need redone [15:41] notting: what we need: a locked down box with very limited access [15:41] notting: as the box will need to have private keys on it [15:41] warren: So outside of the normal FI authentication [15:42] warren: sysadmin-main shouldn't be able to login as root [15:42] rdieter has joined the group chat (n=rdieter at ip68-110-20-4.om.om.cox.net) [15:42] paulobanon: notting: its the RFR/FedoraCertificateSystem right ?! [15:42] mmcgrath: warren: Doesn't have to be. We don't have to include sysadmin-main [15:42] notting: probably not jwb is now known as jwb_gone [15:42] mmcgrath: warren: oh, nm, I think we're talking about the same thing [15:42] dgilmore: warren: no one should log in as root on any box unless its to fix something broken [15:42] warren: dgilmore, true couf is now known as couf_afk [15:43] warren: mmcgrath, I mean... regular sysadmins or people who could mess with the account system shouldn't be able to grant access to the signing server. [15:43] mmcgrath: notting: we can work on that part. I've also considered looking into something like two factor authentication for the signers. [15:43] notting: yeah, it's sort of up in the air how much auth we want from the signers w.r.t FAS (ssh key + fas user/pw? more?) [15:43] mmcgrath: notting: will the private keys been encrypted? [15:44] paulobanon: SELinux it hard [15:44] notting: mmcgrath: as much as any gpg private keys are [15:44] mmcgrath: k, so we'll just have to discuss and find what solution works best for us. [15:44] notting: the box does *not* need to be public facing, but it will need to be accessible from the colo so people can request sigs [15:44] mmcgrath: notting: do you guys have a time frame on any of this yet? [15:44] notting: wait, strike that [15:44] warren: signing server shouldn't be connected or depend on FAS at all [15:45] JSchmitt_ has joined the group chat (n=s4504kr at p54B11AD8.dip0.t-ipconnect.de) [15:45] notting: if we want people to sign who don't have some sort of bastion access, i suppose it does need to be public [15:45] mmcgrath: notting: going through bastion won't be an issue. [15:45] fab has left (Read error: 104 (Connection reset by peer) (n=bellet at bellet.info)) [15:45] fab_ has left (Read error: 104 (Connection reset by peer) (n=bellet at bellet.info)) [15:45] notting: mmcgrath: considering we don't have server code yet, no. [15:45] tibbs has left ("Konversation terminated!" (i=tibbs at fedora/tibbs)) [15:45] warren: notting, we could abstract access through koji or something. [15:45] warren: notting, koji keeps track of what wants signing [15:46] notting: warren: koji has click-through cert auth. makes it *TRIVIAL* to impersonate someone with merely phyiscal access to their box [15:46] warren: notting, oh, I meant requesting signs, not actual signing. [15:46] mmcgrath: notting: we'll keep it on our radar for now. let us know when it becomes more... imminent [15:46] warren: notting, isn't it safe to assume that someone trusted to do actual signing should have bastion access? [15:47] mmcgrath: notting: we could look at physical key requirements as well. How many signers do you suspect we'll have? [15:47] notting: warren: in that they're trusted enough to have bastion access, yes, however, it's entirely possible that they wouldn't have needed it for anything else [15:48] notting: mmcgrath: dunno. more than 2, less than 10. [15:48] mmcgrath: [15:48] mmcgrath: notting: thanks, we'll keep our eyes out for it. [15:48] mmcgrath: In the meantime does anyone have anything else they'd like to discuss? [15:48] mmcgrath: paulobanon: you had something? [15:48] mmcgrath: oh the priority 3 stuff [15:48] warren: ssh with pubkey -> somehost, where they don't see a shell, it asks for a passphrase that is private for each signer. [15:49] paulobanon: cant we take a quick tour on that and on the not implemented RFRs [15:49] paulobanon: and see what can or not be done [15:49] mmcgrath: sure, so a lot of those things are just sort of on hold. [15:49] mmcgrath: the priority 3 stuff. [15:49] paulobanon: cause for someone not on the list for long, it looks like we do nothing [15:49] paulobanon: since that never changes [15:49] mmcgrath: I can confirm that postfix, finoc, mailman and speeding up the wiki are on hold or blocking on other people. [15:50] mmcgrath: lmacken: ping? [15:50] fab has joined the group chat (n=bellet at bellet.info) [15:50] mmcgrath: rhlinux.redhat.com migration is the same thing as the elvis stuff. thats going on. [15:50] paulobanon: FedoraPasteBin - everyone uses pastebin, we still interested in having our one ? [15:50] mmcgrath: the look and feel stuff ricky is working on (though not aorund) [15:50] mmcgrath: yeah, I think it would be good to have our own. Just have to install it I suppose. [15:51] mmcgrath: and these are the RFR's - http://fedoraproject.org/wiki/Infrastructure/Schedule?action=fullsearch&context=180&value=Infrastructure%2FRFR&titlesearch=Titles [15:51] paulobanon: no need for that big url [15:51] paulobanon: just go for /RFR/ [15:51] paulobanon: you have all if you scroll down [15:51] paulobanon: i added all of them there [15:52] paulobanon: until 2 weeks ago i think [15:52] mmcgrath: paulobanon: but some are missing. [15:52] mmcgrath: [15:52] paulobanon: ill update it later then [15:52] paulobanon: requesters should add the link there [15:52] mmcgrath: so those are the rfr's. Some are taken, some aren't. Most are just waiting for worker bees. [15:52] paulobanon: lazy guys [15:53] mmcgrath: paulobanon: I actually skipped doing the list that way just because its so easy to do a search for "Infrastructure/RFR" [15:53] paulobanon: where do u want the pastebin ? i can talk with lmacken to have it deployed [15:53] mmcgrath: paulobanon: go ahead and contact luke. see what he says. [15:53] dgilmore: paulobanon: we were going to integrate it waith fas [15:53] paulobanon: will do [15:53] warren: dgilmore, cool, limit spam. [15:54] mmcgrath: dgilmore: we can let apache do that if we want, should be pretty easy. [15:54] dgilmore: paulobanon: i think thats the main reason it stalled [15:54] dgilmore: mmcgrath: yeah i think skvidal has some turbogears app he wanted to use [15:54] * mmcgrath seems to remember some of that. [15:54] skvidal: dgilmore: a loooooooong time ago [15:54] warren: dgilmore, I saw other pastebins without auth used by random people as a way to store links to warez [15:54] dgilmore: mmcgrath: abadger1999's fedora-python stuff should help [15:55] dgilmore: warren: sure [15:55] mmcgrath: yep, the fedora-python stuff is beautiful. And very easy to use. [15:55] paulobanon: cant we limit access the same way we limit access to teh cgi's in the admin site ? [15:55] mmcgrath: Ok, we've got a couple of minutes left. Anyone else have anything they'd like to discuss? [15:55] dgilmore: skvidal: so now your a RHer you can get er done [15:55] skvidal: dgilmore: heh, I'll put it on my list [15:56] * dgilmore has nothing [15:56] skvidal: just not ultra-highpriority, ok? [15:56] dgilmore: skvidal: sure [15:56] abadger1999: mmcgrath: People have been getting interested in FAS2 recently. But the instance on the test servers is down and we need to have a list of FAS tasks they can jump in to work on. [15:56] mmcgrath: abadger1999: I haven't had anyone contact me with help. The fas link should be back up in a bit actually. [15:57] abadger1999: Cool. [15:57] paulobanon: should we create a Tasks list like the other SIGs have ?! [15:57] paulobanon: instead of having everything in the schedule [15:58] paulobanon: if we are gonna test trac, we could convert the current schedule in tasks, and get a proper schedule with milestones in Trac [15:58] mmcgrath: paulobanon: We'll have to see more when we get into Trac. [15:58] mmcgrath: The thing about schedules is that its always been around and we've always used it, when OTRS came around we just ignored it. [15:59] mmcgrath: I guess we'll just have to set it up and see if we can get our team to actually use it. [15:59] paulobanon: true [15:59] mmcgrath: Ok, we're about to run over time. [15:59] mmcgrath: If no one has anything pressing I'll close the meeting in 30 [15:59] mmcgrath: 10 [15:59] mmcgrath: [15:59] fchiulli has left ( (i=824c400f at gateway/web/cgi-irc/ircatwork.com/x-1f7399ce8f2ba354)) [16:00] mmcgrath has set the subject to Meeting closed [16:00] mmcgrath: thanks for coming guys. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From santosp at fedoraproject.org Thu Jun 28 21:06:06 2007 From: santosp at fedoraproject.org (Paulo Santos) Date: Thu, 28 Jun 2007 22:06:06 +0100 Subject: Streamlining Account Signup Process In-Reply-To: <46841BD7.30908@redhat.com> References: <20070628194801.GA20206@bludgeon.org> <468412AB.1050903@redhat.com> <468413EB.70208@fedoraproject.org> <46841BD7.30908@redhat.com> Message-ID: <7a41c4bc0706281406y53433348te0b25d32fb9c4dbd@mail.gmail.com> And we did reply it, on IRC though :) Quaid is aware of the situation, and it will be addressed with the new Moin version 1.6 Basically the CreateLogin and UserPreferences will be two different pages, and we will paste the CLA in the top of CreateLogin page, with something like "if you create a login in Fedoraproject wiki, you accept the CLA" and anyone that wants to create an account will just need to read it (or at least scroll down) and create the login. This pretty much summarizes what Karsten wanted. Paulo On 6/28/07, Mike McGrath wrote: > > Rahul Sundaram wrote: > > Mike McGrath wrote: > > > >> > >> A simpler wiki setup is actually on its way. quaid, paulobanon: care > >> to comment further? > >> > > > > They are waiting on infrastructure team to enable click through signup > > on the wiki. Karsten Wade (quaid) posted a request here with no > > response. That would be the best fix within the legal constraints for > > this (known) problem. > > paulobanon is the infrastructure team member working on it with quaid. > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Thu Jun 28 21:30:51 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 28 Jun 2007 15:30:51 -0600 Subject: koji errors Message-ID: <4684288B.70207@cora.nwra.com> I'm getting the following frequently while using koji: Mod_python error: "PythonHandler mod_python.publisher" Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch result = object(req) File "/usr/lib/python2.4/site-packages/mod_python/publisher.py", line 213, in handler published = publish_object(req, object) File "/usr/lib/python2.4/site-packages/mod_python/publisher.py", line 412, in publish_object return publish_object(req,util.apply_fs_data(object, req.form, req=req)) File "/usr/lib/python2.4/site-packages/mod_python/util.py", line 439, in apply_fs_data return object(**args) File "/usr/share/koji-web/scripts/index.py", line 798, in buildinfo rpms = server.listBuildRPMs(build['id']) File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1075, in __call__ return self.__func(self.__name,args,opts) File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1300, in _callMethod return proxy.__getattr__(name)(*args) File "/usr/lib/python2.4/xmlrpclib.py", line 1096, in __call__ return self.__send(self.__name, args) File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request verbose=self.__verbose File "/usr/lib/python2.4/xmlrpclib.py", line 1137, in request headers ProtocolError: Clears eventually after enough retries. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From sundaram at fedoraproject.org Thu Jun 28 22:15:43 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 Jun 2007 03:45:43 +0530 Subject: Firefox Search Plugin In-Reply-To: <7874d9dd0706052151w68433fdcm7457f3bd073ed5cc@mail.gmail.com> References: <7874d9dd0706052151w68433fdcm7457f3bd073ed5cc@mail.gmail.com> Message-ID: <4684330F.30203@fedoraproject.org> Michael Stahnke wrote: > I was looking for a firefox search plugin for the Fedora Wiki. I > checked google/mycroft and didn't find one already existed, so I built > my own. > > http://www.stahnkage.com/fedora should get you to it. > > If it doesn't work or needs updates, let me know. If it stinks (and > it probably does) let me know too. (Tested on F6/ FF 1.5) > You should file a RFE against firefox in Red Hat bugzilla to include this by default. This is pretty handy. Rahul From sundaram at fedoraproject.org Thu Jun 28 22:17:57 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 Jun 2007 03:47:57 +0530 Subject: boot.iso folder location In-Reply-To: <200706020948.32010.jkeating@redhat.com> References: <46615192.3020608@fedoraproject.org> <200706020941.05290.jkeating@redhat.com> <4661756A.30400@fedoraproject.org> <200706020948.32010.jkeating@redhat.com> Message-ID: <46843395.9030709@fedoraproject.org> Jesse Keating wrote: > On Saturday 02 June 2007 09:49:30 Rahul Sundaram wrote: >> If they are not willing to change the location for some reason please >> consider providing a symlink. IIRC the RFE I filed around FC5 time is >> still open on this. > > With a renamed rescue image, that should be what we recommend people use. > Having multiple "small" isos in there to start network installs is just > confusing. boot.iso could go away all together perhaps. Any decisions on this? Rahul From jkeating at redhat.com Fri Jun 29 00:29:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Jun 2007 20:29:55 -0400 Subject: boot.iso folder location In-Reply-To: <46843395.9030709@fedoraproject.org> References: <46615192.3020608@fedoraproject.org> <200706020948.32010.jkeating@redhat.com> <46843395.9030709@fedoraproject.org> Message-ID: <200706282029.55922.jkeating@redhat.com> On Thursday 28 June 2007 18:17:57 Rahul Sundaram wrote: > Jesse Keating wrote: > > On Saturday 02 June 2007 09:49:30 Rahul Sundaram wrote: > >> If they are not willing to change the location for some reason please > >> consider providing a symlink. IIRC the RFE I filed around FC5 time is > >> still open on this. > > > > With a renamed rescue image, that should be what we recommend people use. > > Having multiple "small" isos in there to start network installs is just > > confusing. boot.iso could go away all together perhaps. > > Any decisions on this? > Not as of yet. Frying other fish. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Jun 29 01:35:11 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 Jun 2007 07:05:11 +0530 Subject: Streamlining Account Signup Process In-Reply-To: <7a41c4bc0706281406y53433348te0b25d32fb9c4dbd@mail.gmail.com> References: <20070628194801.GA20206@bludgeon.org> <468412AB.1050903@redhat.com> <468413EB.70208@fedoraproject.org> <46841BD7.30908@redhat.com> <7a41c4bc0706281406y53433348te0b25d32fb9c4dbd@mail.gmail.com> Message-ID: <468461CF.20500@fedoraproject.org> Paulo Santos wrote: > And we did reply it, on IRC though :) > That's better than getting no response but I would consider it more useful if the responses are given on the mailing list if the questions were asked in them. For one thing, the discussions are archived and I can read about asynchronously and refer other people to them easily. There are more people interested in the progress on this besides Karsten Wade and I would appreciate knowing the status too. Thanks. Rahul From ssrat at ticon.net Fri Jun 29 03:56:51 2007 From: ssrat at ticon.net (David Douthitt) Date: Thu, 28 Jun 2007 22:56:51 -0500 Subject: IRC Meeting Text Formatter.... Message-ID: <46848303.8010208@ticon.net> I've been trying to keep up with reading the IRC logs, but they aren't the easiest to read. So.... I turned to scripting and created a much easier to read format based on the original text. The new format separates the text by subject, tallies the attendees and reports on these at the end. The script (called "irc") is in Ruby and is attached - it writes out a file "irc.{mo}.{day}". -- UNIX System Administrator Linux+, SCSA, RHCE, LPIC-1 HP-UX, Linux, Solaris, FreeBSD Books: "Advanced System Administration" and "GNU Screen: A Comprehensive Introduction" http://www.lulu.com/ssrat -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: irc URL: From skvidal at fedoraproject.org Fri Jun 29 16:19:38 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 29 Jun 2007 12:19:38 -0400 Subject: xen guests on fpserv Message-ID: <1183133978.8449.7.camel@cutter> Hi folks, I'm setting up the two xen instances we talked about running on fpserv: planet - for the planet.fedoraproject.org site and for the infofeed (along w/whatever else we come up with needing that on people - for the fedorapeople.org domain and all the subdomains for fedora accounts Now - my questions are these: 1. what naming convention should I use for the xen guests on fpserv? I was planning on using planetserv.fedoraproject.org and peopleserv.fedoraproject.org is that okay or should these be xen1/2/3? 2. I was going to set it up such that planet had a small but manageable amount of disk space and people had everything else - which is about 260GB. Does that good to y'all? Is there anything else I should be planning for? thanks, -sv From mmcgrath at redhat.com Fri Jun 29 16:39:10 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 29 Jun 2007 11:39:10 -0500 Subject: xen guests on fpserv In-Reply-To: <1183133978.8449.7.camel@cutter> References: <1183133978.8449.7.camel@cutter> Message-ID: <468535AE.8080203@redhat.com> seth vidal wrote: > Now - my questions are these: > 1. what naming convention should I use for the xen guests on fpserv? > I was planning on using planetserv.fedoraproject.org and > peopleserv.fedoraproject.org is that okay or should these be xen1/2/3? > > planet[1-2], people[1-2] would be perfect. xen[1-x] is for the actual xen hosts. Which should be considered more like appliances :) > 2. I was going to set it up such that planet had a small but > manageable amount of disk space and people had everything else - which > is about 260GB. Does that good to y'all? Is there anything else I should > be planning for? > Solid -Mike From damian.myerscough at gmail.com Fri Jun 29 16:48:05 2007 From: damian.myerscough at gmail.com (Damian Myerscough) Date: Fri, 29 Jun 2007 17:48:05 +0100 Subject: xen guests on fpserv In-Reply-To: <468535AE.8080203@redhat.com> References: <1183133978.8449.7.camel@cutter> <468535AE.8080203@redhat.com> Message-ID: <8c9e56490706290948m23753614nf1f1f1c5062e840a@mail.gmail.com> Sounds Good :) On 29/06/07, Mike McGrath wrote: > seth vidal wrote: > > Now - my questions are these: > > 1. what naming convention should I use for the xen guests on fpserv? > > I was planning on using planetserv.fedoraproject.org and > > peopleserv.fedoraproject.org is that okay or should these be xen1/2/3? > > > > > planet[1-2], people[1-2] would be perfect. xen[1-x] is for the actual > xen hosts. Which should be considered more like appliances :) > > 2. I was going to set it up such that planet had a small but > > manageable amount of disk space and people had everything else - which > > is about 260GB. Does that good to y'all? Is there anything else I should > > be planning for? > > > Solid > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- Regards, Damian From Axel.Thimm at ATrpms.net Sat Jun 30 08:15:14 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 30 Jun 2007 10:15:14 +0200 Subject: You need to create a bugzilla account for Axel.Thimm@ATrpms.net In-Reply-To: <200706300508.l5U58cJd010169@cutlet.install.boston.redhat.com> References: <200706300508.l5U58cJd010169@cutlet.install.boston.redhat.com> Message-ID: <20070630081514.GA28899@puariko.nirvana> As the mail admits this is amazingly stupid, unless someone wiped my bugzilla account ... On Sat, Jun 30, 2007 at 01:08:37AM -0400, accounts at fedora.redhat.com wrote: > > In order to make bugzilla components for Fedora-related programs, we need to have an existing bugzilla account for > the listed owner. You (Axel.Thimm at ATrpms.net) do not have a bugzilla account, but are listed as the owner for the following components: > Fedora (apt) > > Please create a bugzilla account for Axel.Thimm at ATrpms.net immediately, because this amazingly stupid cron job will keep sending you an > e-mail every hour until you do :) > > - The management -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dev at nigelj.com Sat Jun 30 08:29:03 2007 From: dev at nigelj.com (Nigel Jones) Date: Sat, 30 Jun 2007 20:29:03 +1200 Subject: You need to create a bugzilla account for Axel.Thimm@ATrpms.net In-Reply-To: <20070630081514.GA28899@puariko.nirvana> References: <200706300508.l5U58cJd010169@cutlet.install.boston.redhat.com> <20070630081514.GA28899@puariko.nirvana> Message-ID: <4686144F.50601@nigelj.com> Axel Thimm wrote: > As the mail admits this is amazingly stupid, unless someone wiped my > bugzilla account ... Heh > > On Sat, Jun 30, 2007 at 01:08:37AM -0400, accounts at fedora.redhat.com wrote: >> In order to make bugzilla components for Fedora-related programs, we need to have an existing bugzilla account for >> the listed owner. You (Axel.Thimm at ATrpms.net) do not have a bugzilla account, but are listed as the owner for the following components: >> Fedora (apt) >> >> Please create a bugzilla account for Axel.Thimm at ATrpms.net immediately, because this amazingly stupid cron job will keep sending you an >> e-mail every hour until you do :) 1. Can you still login to Bugzilla 2. Are you getting the email hourly? I suspect this may be due to the maintenance that took place today. N.J. From Axel.Thimm at ATrpms.net Sat Jun 30 08:37:06 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 30 Jun 2007 10:37:06 +0200 Subject: Error processing Fedora Account System email In-Reply-To: <200706300815.l5U8FZa4002915@bastion.fedora.phx.redhat.com> References: <200706300815.l5U8FZa4002915@bastion.fedora.phx.redhat.com> Message-ID: <20070630083706.GC28899@puariko.nirvana> ??? On Sat, Jun 30, 2007 at 01:15:34AM -0700, Fedora Account System wrote: > With regards to "Re: You need to create a bugzilla account for Axel.Thimm at ATrpms.net". > > Your message could not be processed. > > Reason: > > The signature could not be processed. The signature may have been created or attached improperly, it might not match the key ID you have registered in the Account System, or the public key may not have been found on the key server. For guidance, please see the following page: > > http://fedoraproject.org/wiki/Infrastructure/AccountSystem/CLAHowTo -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Jun 30 08:41:34 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 30 Jun 2007 10:41:34 +0200 Subject: You need to create a bugzilla account for Axel.Thimm@ATrpms.net In-Reply-To: <4686144F.50601@nigelj.com> References: <200706300508.l5U58cJd010169@cutlet.install.boston.redhat.com> <20070630081514.GA28899@puariko.nirvana> <4686144F.50601@nigelj.com> Message-ID: <20070630084134.GD28899@puariko.nirvana> On Sat, Jun 30, 2007 at 08:29:03PM +1200, Nigel Jones wrote: > Axel Thimm wrote: > > As the mail admits this is amazingly stupid, unless someone wiped my > > bugzilla account ... > Heh > > > > On Sat, Jun 30, 2007 at 01:08:37AM -0400, accounts at fedora.redhat.com wrote: > >> In order to make bugzilla components for Fedora-related programs, we need to have an existing bugzilla account for > >> the listed owner. You (Axel.Thimm at ATrpms.net) do not have a bugzilla account, but are listed as the owner for the following components: > >> Fedora (apt) > >> > >> Please create a bugzilla account for Axel.Thimm at ATrpms.net immediately, because this amazingly stupid cron job will keep sending you an > >> e-mail every hour until you do :) > 1. Can you still login to Bugzilla Yes (wiping the sweat of the forehead ;). > 2. Are you getting the email hourly? Hourly? Even if the script were not detecting false positives, would it make sense to spam up such a user's mailbox that way? Especially on a weekend? Are you sure this was going to be hourly and not say daily/weekly? > I suspect this may be due to the maintenance that took place today. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tchung at fedoraproject.org Sat Jun 30 09:17:11 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Sat, 30 Jun 2007 02:17:11 -0700 Subject: Error processing Fedora Account System email In-Reply-To: <20070630083706.GC28899@puariko.nirvana> References: <200706300815.l5U8FZa4002915@bastion.fedora.phx.redhat.com> <20070630083706.GC28899@puariko.nirvana> Message-ID: <369bce3b0706300217y1d1c9bc5kf4207bffa4b18937@mail.gmail.com> On 6/30/07, Axel Thimm wrote: > ??? > > On Sat, Jun 30, 2007 at 01:15:34AM -0700, Fedora Account System wrote: > > With regards to "Re: You need to create a bugzilla account for Axel.Thimm at ATrpms.net". > > > > Your message could not be processed. > > > > Reason: > > > > The signature could not be processed. The signature may have been created or attached improperly, it might not match the key ID you have registered in the Account System, or the public key may not have been found on the key server. For guidance, please see the following page: > > > > http://fedoraproject.org/wiki/Infrastructure/AccountSystem/CLAHowTo > > -- > Axel.Thimm at ATrpms.net I see "cla_done" in your Fedora Account[1] already. Are you trying to request another CLA? [1] http://fedoraproject.org/wiki/Infrastructure/AccountSystem/QueryAccount Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From Axel.Thimm at ATrpms.net Sat Jun 30 09:47:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 30 Jun 2007 11:47:40 +0200 Subject: Error processing Fedora Account System email In-Reply-To: <369bce3b0706300217y1d1c9bc5kf4207bffa4b18937@mail.gmail.com> References: <200706300815.l5U8FZa4002915@bastion.fedora.phx.redhat.com> <20070630083706.GC28899@puariko.nirvana> <369bce3b0706300217y1d1c9bc5kf4207bffa4b18937@mail.gmail.com> Message-ID: <20070630094740.GH28899@puariko.nirvana> On Sat, Jun 30, 2007 at 02:17:11AM -0700, Thomas Chung wrote: > On 6/30/07, Axel Thimm wrote: > >??? > > > >On Sat, Jun 30, 2007 at 01:15:34AM -0700, Fedora Account System wrote: > >> With regards to "Re: You need to create a bugzilla account for > >Axel.Thimm at ATrpms.net". > >> > >> Your message could not be processed. > >> > >> Reason: > >> > >> The signature could not be processed. The signature may have been > >created or attached improperly, it might not match the key ID you have > >registered in the Account System, or the public key may not have been > >found on the key server. For guidance, please see the following page: > >> > >> http://fedoraproject.org/wiki/Infrastructure/AccountSystem/CLAHowTo > > > > I see "cla_done" in your Fedora Account[1] already. > Are you trying to request another CLA? > > [1] http://fedoraproject.org/wiki/Infrastructure/AccountSystem/QueryAccount > > Regards, No, I just replied to the self-proclaimed amazingly stupid mail I received about not having a bugzilla account anymore. So now I have to shiver in agony whether both my bugzilla account *and* cla_done bit are scheduled for erasure? Not. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dev at nigelj.com Sat Jun 30 10:25:42 2007 From: dev at nigelj.com (Nigel Jones) Date: Sat, 30 Jun 2007 22:25:42 +1200 Subject: Error processing Fedora Account System email In-Reply-To: <20070630094740.GH28899@puariko.nirvana> References: <200706300815.l5U8FZa4002915@bastion.fedora.phx.redhat.com> <20070630083706.GC28899@puariko.nirvana> <369bce3b0706300217y1d1c9bc5kf4207bffa4b18937@mail.gmail.com> <20070630094740.GH28899@puariko.nirvana> Message-ID: <46862FA6.9050205@nigelj.com> Axel Thimm wrote: > On Sat, Jun 30, 2007 at 02:17:11AM -0700, Thomas Chung wrote: >> On 6/30/07, Axel Thimm wrote: >>> ??? >>> >>> On Sat, Jun 30, 2007 at 01:15:34AM -0700, Fedora Account System wrote: >>>> With regards to "Re: You need to create a bugzilla account for >>> Axel.Thimm at ATrpms.net". >>>> Your message could not be processed. >>>> >>>> Reason: >>>> >>>> The signature could not be processed. The signature may have been >>>> created or attached improperly, it might not match the key ID you have >>>> registered in the Account System, or the public key may not have been >>>> found on the key server. For guidance, please see the following page: >>>> http://fedoraproject.org/wiki/Infrastructure/AccountSystem/CLAHowTo >> I see "cla_done" in your Fedora Account[1] already. >> Are you trying to request another CLA? >> >> [1] http://fedoraproject.org/wiki/Infrastructure/AccountSystem/QueryAccount >> >> Regards, > > No, I just replied to the self-proclaimed amazingly stupid mail I > received about not having a bugzilla account anymore. So now I have to > shiver in agony whether both my bugzilla account *and* cla_done bit > are scheduled for erasure? Not. > According to the error message you forwarded, it is due to the fact that your email was not signed with the GPG key in FAS ("it might not match the key ID you have registered in the Account System, or the public key may not have been found on the key server.") N.J. > > ------------------------------------------------------------------------ > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list From Axel.Thimm at ATrpms.net Sat Jun 30 12:07:47 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 30 Jun 2007 14:07:47 +0200 Subject: Error processing Fedora Account System email In-Reply-To: <46862FA6.9050205@nigelj.com> References: <200706300815.l5U8FZa4002915@bastion.fedora.phx.redhat.com> <20070630083706.GC28899@puariko.nirvana> <369bce3b0706300217y1d1c9bc5kf4207bffa4b18937@mail.gmail.com> <20070630094740.GH28899@puariko.nirvana> <46862FA6.9050205@nigelj.com> Message-ID: <20070630120747.GS28899@puariko.nirvana> On Sat, Jun 30, 2007 at 10:25:42PM +1200, Nigel Jones wrote: > Axel Thimm wrote: > > On Sat, Jun 30, 2007 at 02:17:11AM -0700, Thomas Chung wrote: > >> On 6/30/07, Axel Thimm wrote: > >>> ??? > >>> > >>> On Sat, Jun 30, 2007 at 01:15:34AM -0700, Fedora Account System wrote: > >>>> With regards to "Re: You need to create a bugzilla account for > >>> Axel.Thimm at ATrpms.net". > >>>> Your message could not be processed. > >>>> > >>>> Reason: > >>>> > >>>> The signature could not be processed. The signature may have been > >>>> created or attached improperly, it might not match the key ID you have > >>>> registered in the Account System, or the public key may not have been > >>>> found on the key server. For guidance, please see the following page: > >>>> http://fedoraproject.org/wiki/Infrastructure/AccountSystem/CLAHowTo > >> I see "cla_done" in your Fedora Account[1] already. > >> Are you trying to request another CLA? > >> > >> [1] http://fedoraproject.org/wiki/Infrastructure/AccountSystem/QueryAccount > >> > >> Regards, > > > > No, I just replied to the self-proclaimed amazingly stupid mail I > > received about not having a bugzilla account anymore. So now I have to > > shiver in agony whether both my bugzilla account *and* cla_done bit > > are scheduled for erasure? Not. > > > According to the error message you forwarded, it is due to the fact that > your email was not signed with the GPG key in FAS ("it might not match > the key ID you have registered in the Account System, or the public key > may not have been found on the key server.") I know, there are two bugs here: a) I replied to the "amazingly stupid" mail I received and got the above reply, at the very least the From/Reply-To was broken. b) I did sign the mail and the gpg key is actually the one registred at FAS, I just checked my FAS details. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Sat Jun 30 13:56:10 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 30 Jun 2007 08:56:10 -0500 Subject: You need to create a bugzilla account for Axel.Thimm@ATrpms.net In-Reply-To: <20070630084134.GD28899@puariko.nirvana> References: <200706300508.l5U58cJd010169@cutlet.install.boston.redhat.com> <20070630081514.GA28899@puariko.nirvana> <4686144F.50601@nigelj.com> <20070630084134.GD28899@puariko.nirvana> Message-ID: <468660FA.7040702@redhat.com> Axel Thimm wrote: > > Hourly? Even if the script were not detecting false positives, would > it make sense to spam up such a user's mailbox that way? Especially on > a weekend? > > Are you sure this was going to be hourly and not say daily/weekly? > > You got one of these or many of these and continue to get them? -Mike From Axel.Thimm at ATrpms.net Sat Jun 30 14:03:16 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 30 Jun 2007 16:03:16 +0200 Subject: You need to create a bugzilla account for Axel.Thimm@ATrpms.net In-Reply-To: <468660FA.7040702@redhat.com> References: <200706300508.l5U58cJd010169@cutlet.install.boston.redhat.com> <20070630081514.GA28899@puariko.nirvana> <4686144F.50601@nigelj.com> <20070630084134.GD28899@puariko.nirvana> <468660FA.7040702@redhat.com> Message-ID: <20070630140316.GC5412@puariko.nirvana> On Sat, Jun 30, 2007 at 08:56:10AM -0500, Mike McGrath wrote: > Axel Thimm wrote: > > > >Hourly? Even if the script were not detecting false positives, would > >it make sense to spam up such a user's mailbox that way? Especially on > >a weekend? > > > >Are you sure this was going to be hourly and not say daily/weekly? > > > > > > You got one of these or many of these and continue to get them? One only From dennis at ausil.us Sat Jun 30 14:15:17 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 30 Jun 2007 09:15:17 -0500 Subject: Error processing Fedora Account System email In-Reply-To: <20070630120747.GS28899@puariko.nirvana> References: <200706300815.l5U8FZa4002915@bastion.fedora.phx.redhat.com> <46862FA6.9050205@nigelj.com> <20070630120747.GS28899@puariko.nirvana> Message-ID: <200706300915.22562.dennis@ausil.us> Once upon a time Saturday 30 June 2007, Axel Thimm wrote: > a) I replied to the "amazingly stupid" mail I received and got the > above reply, at the very least the From/Reply-To was broken. > > b) I did sign the mail and the gpg key is actually the one registred > at FAS, I just checked my FAS details. Axel, on every email you send i get "Message was signed by Axel.Thimm at physik.fu-berlin.de (Key ID: 0x401552D4639A99F1). Warning: The signature is bad." perhaps thats what happened. any way its not something that should have happened and we will have to try and determine why you got emailed in the first place. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From Axel.Thimm at ATrpms.net Sat Jun 30 14:47:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 30 Jun 2007 16:47:40 +0200 Subject: Error processing Fedora Account System email In-Reply-To: <200706300915.22562.dennis@ausil.us> References: <200706300815.l5U8FZa4002915@bastion.fedora.phx.redhat.com> <46862FA6.9050205@nigelj.com> <20070630120747.GS28899@puariko.nirvana> <200706300915.22562.dennis@ausil.us> Message-ID: <20070630144740.GD5412@puariko.nirvana> On Sat, Jun 30, 2007 at 09:15:17AM -0500, Dennis Gilmore wrote: > Once upon a time Saturday 30 June 2007, Axel Thimm wrote: > > > a) I replied to the "amazingly stupid" mail I received and got the > > above reply, at the very least the From/Reply-To was broken. > > > > b) I did sign the mail and the gpg key is actually the one registred > > at FAS, I just checked my FAS details. > > Axel, > > on every email you send i get "Message was signed by > Axel.Thimm at physik.fu-berlin.de (Key ID: 0x401552D4639A99F1). > Warning: The signature is bad." perhaps thats what happened. Hm, you either never refresh the public key cache, or your MUA/the gpg checking script can't cope with multiple uids in a key (unlikely, but has happened in rpm code before, so it's always worth checking). Try gpg --refresh-keys and see what happens. I bet at least your MUA will get back to senses. > any way its not something that should have happened and we will have > to try and determine why you got emailed in the first place. But let me add c) why on earth is my reply to the broken cron job being gpg checked at the first place? Let me recapitulate: o Some scripts decides that I don't have a bufgzilla account and sends me instructiosn to setup a bugzilla account under the name of my already exiting bugzilla acount. OK, a bug in the script with a false positive. o Replying to the mail applies some gpg checking to it (???). I would expect the destination of automated mail to be either noreply or if not to reach some person that can fix it. But somehow the destination is a gpg checking script, perhaps a mismatch of addresses (in the orginal script-mail) and the mail was sent to the CLS checking script ... o Finally the gpg check fails on a valid signature. Perhaps because the public gpg cache was filled with my key ages ago, perhaps because it now fails to detect multiple uids in the key (which was the same when I signed the CLA, so it would be a regression). Now three bugs in one? Why, am I a lucky bastard. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Sat Jun 30 16:42:04 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 30 Jun 2007 11:42:04 -0500 Subject: Where's that guest? Message-ID: <468687DC.4090500@redhat.com> I've created a script (now on bastion) that will scan all of our xen hosts and list what guests are on it. Just a reminder that we should be naming guests at this point on by hostname. More scripts and monitoring are on the way. from bastion run: scanXen.sh -Mike