From huzaifas at redhat.com Tue Sep 2 11:01:28 2008 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Tue, 02 Sep 2008 16:31:28 +0530 Subject: Can someone approve me? Message-ID: <48BD1D08.40208@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, I have been hanging around the infrastructure team for a year now, I am also your friendly neighborhood beat writer for FWN, can some one please approve me in the sysadmin group? Thanks. - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFIvR0IzHDc8tpb2uURAv+mAJ9Ayl0xFDlQBjpM0JkqxgTNPhjO/wCeKU3n /YuFbWAUloyCsc7crWiLzn4= =czHm -----END PGP SIGNATURE----- From wtogami at redhat.com Tue Sep 2 17:30:46 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 02 Sep 2008 13:30:46 -0400 Subject: New Key Repo Locations v2 Message-ID: <48BD7846.4010006@redhat.com> Slight correction. Paths have not changed, but I have changed the repo names so debuginfo and source are always at the end. http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html How these will be used is written here. Release Before (no yum repo file) http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Fedora/$basearch/os/ Release After (no yum repo file) http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Fedora/$basearch/os.newkey/ fedora http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/ fedora-newkey http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/os.newkey/ fedora-debuginfo http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/debug/ fedora-newkey-debuginfo http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/debug.newkey/ fedora-source http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/source/SRPMS/ fedora-newkey-source http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/source/SRPMS.newkey/ updates http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/$basearch/ updates-newkey http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/$basearch.newkey/ updates-debuginfo http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/$basearch/debug/ updates-newkey-debuginfo http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/$basearch.newkey/debug/ updates-source http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/SRPMS/ updates-newkey-source http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/SRPMS.newkey/ updates-testing http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/$basearch/ updates-newkey-testing http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/$basearch.newkey/ updates-testing-debuginfo http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/$basearch/debug/ updates-testing-newkey-debuginfo http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/$basearch.newkey/debug/ updates-testing-source http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/SRPMS/ updates-testing-newkey-source http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/SRPMS.newkey/ From mmcgrath at redhat.com Tue Sep 2 17:48:11 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 2 Sep 2008 12:48:11 -0500 (CDT) Subject: Can someone approve me? In-Reply-To: <48BD1D08.40208@redhat.com> References: <48BD1D08.40208@redhat.com> Message-ID: On Tue, 2 Sep 2008, Huzaifa Sidhpurwala wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi All, > I have been hanging around the infrastructure team for a year now, I am > also your friendly neighborhood beat writer for FWN, can some one please > approve me in the sysadmin group? > approved! Thanks for keeping FWN informed of our goings on. -Mike From Matt_Domsch at dell.com Tue Sep 2 20:28:39 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 2 Sep 2008 15:28:39 -0500 Subject: New Key Repo Locations v2 In-Reply-To: <48BD7846.4010006@redhat.com> References: <48BD7846.4010006@redhat.com> Message-ID: <20080902202839.GA12917@auslistsprd01.us.dell.com> On Tue, Sep 02, 2008 at 01:30:46PM -0400, Warren Togami wrote: > Slight correction. Paths have not changed, but I have changed the repo > names so debuginfo and source are always at the end. > > http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html > How these will be used is written here. > > Release Before (no yum repo file) > http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Fedora/$basearch/os/ > Release After (no yum repo file) > http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Fedora/$basearch/os.newkey/ > > fedora > http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/ > fedora-newkey > http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/os.newkey/ What are the mirrorlist strings you're going to use? MM doesn't care what you put as the repo name [fedora] or [fedora-newkey], but it cares very much what you put as mirrorlist?repo=fedora-9.newkey. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From pvangundy at gmail.com Wed Sep 3 14:57:19 2008 From: pvangundy at gmail.com (Paul VanGundy) Date: Wed, 3 Sep 2008 10:57:19 -0400 Subject: Paul VanGundy - Introduction Message-ID: Hello List! :) My name is Paul VanGundy and this is my introduction to the list. No worries as I will make this short and sweet and if there are questions or people want to know more about me they can email me or the list. I have eight years experience in Linux systems administration in many different parallels (government, education, enterprise) with which I am currently serving in enterprise. Nutshelling, I have worked with many different flavors of Linux but mainly Red Hat, CentOS and Fedora in the enterprise market. I have done everything from managing large email farms running on Red Hat (my stints at WebEx and Cisco), running CentOS (both physical and virtual) in development environments (WebEx, Cisco, Bradford Networks) to helping school districts reach there educational potentional by using open source projects such as LTSP (of which I have written a pdf doc that is used world over but a little outdated... see wiki.ltsp.org). I have many other skills, abilities and experience that I will not list as I want to keep this short and sweet. I do welcome questions and am very eager to help the Fedora Project and utilize my skills to give back to those that have given to me. I look forward to working with all of you! Cheers!! /paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From bretm at redhat.com Wed Sep 3 15:23:53 2008 From: bretm at redhat.com (Bret McMillan) Date: Wed, 03 Sep 2008 11:23:53 -0400 Subject: a quick self-introduction Message-ID: <48BEAC09.20705@redhat.com> Hey folks, I've been lurking in the infrastructure area for awhile, but just recently joined the list. jonrob & mmcgrath have been kind enough to work w/ me on blog stuff for news.fp.org, etc. I've been an RH employee for a number of years, mostly in RHN engineering, but now recently in IT working on collaborative applications. I'd classify myself as a marginal SA, but always willing to learn and help out :) Current interests: * blogs (wordpress-mu) * wikis * mobile devices * CDN's * opening RH's IT tooling & methods to be more open and in alignment w/ what the community is doing cheers, --Bret From mmcgrath at redhat.com Wed Sep 3 15:37:24 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 3 Sep 2008 10:37:24 -0500 (CDT) Subject: Paul VanGundy - Introduction In-Reply-To: References: Message-ID: On Wed, 3 Sep 2008, Paul VanGundy wrote: > Hello List! :) > > My name is Paul VanGundy and this is my introduction to the list. No worries as I will make this short and sweet and > if there are questions or people want to know more about me they can email me or the list. > > I have eight years experience in Linux systems administration in many different parallels (government, education, > enterprise) with which I am currently serving in enterprise. Nutshelling, I have worked with many different flavors of > Linux but mainly Red Hat, CentOS and Fedora in the enterprise market. I have done everything from managing large email > farms running on Red Hat (my stints at WebEx and Cisco), running CentOS (both physical and virtual) in development > environments (WebEx, Cisco, Bradford Networks) to helping school districts reach there educational potentional by > using open source projects such as LTSP (of which I have written a pdf doc that is used world over but a little > outdated... see wiki.ltsp.org). I have many other skills, abilities and experience that I will not list as I want to > keep this short and sweet. > > I do welcome questions and am very eager to help the Fedora Project and utilize my skills to give back to those that > have given to me. I look forward to working with all of you! > > Cheers!! Welcome Paul! I've seen you've already found #fedora-admin also make sure to try to attend our weekly meetings. -Mike From mmcgrath at redhat.com Wed Sep 3 15:37:56 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 3 Sep 2008 10:37:56 -0500 (CDT) Subject: a quick self-introduction In-Reply-To: <48BEAC09.20705@redhat.com> References: <48BEAC09.20705@redhat.com> Message-ID: On Wed, 3 Sep 2008, Bret McMillan wrote: > Hey folks, > > I've been lurking in the infrastructure area for awhile, but just recently > joined the list. jonrob & mmcgrath have been kind enough to work w/ me on > blog stuff for news.fp.org, etc. I've been an RH employee for a number of > years, mostly in RHN engineering, but now recently in IT working on > collaborative applications. I'd classify myself as a marginal SA, but always > willing to learn and help out :) > > Current interests: > * blogs (wordpress-mu) > * wikis > * mobile devices > * CDN's > * opening RH's IT tooling & methods to be more open and in alignment w/ what > the community is doing > Hey Bret, good to see you've finally sent this :) People will really like the new sites. -Mike From bretm at redhat.com Wed Sep 3 15:43:28 2008 From: bretm at redhat.com (Bret McMillan) Date: Wed, 03 Sep 2008 11:43:28 -0400 Subject: a quick self-introduction In-Reply-To: References: <48BEAC09.20705@redhat.com> Message-ID: <48BEB0A0.5060003@redhat.com> Mike McGrath wrote: > On Wed, 3 Sep 2008, Bret McMillan wrote: > > Hey Bret, good to see you've finally sent this :) People will really like > the new sites. Yeah, sorry I'm such the slacker :) --Bret From aphukan.fedora at gmail.com Thu Sep 4 06:03:39 2008 From: aphukan.fedora at gmail.com (Amitakhya Phukan) Date: Thu, 04 Sep 2008 11:33:39 +0530 Subject: need approval Message-ID: <48BF7A3B.30206@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I am interested in joining the Fedora Infrastructure team. I am interested in general sysadmin, sysadmin-test and sysadmin-hosted groups. Can anyone sponsor me ? Regards, Amit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAki/ejgACgkQisV6fTFpwA2q6gCfSKBiIHW7DdQIxykaLuXGjc7c Q/AAnjgT8MhfNGL2BPUuPYWQUQkxhwen =oDSZ -----END PGP SIGNATURE----- From aphukan.fedora at gmail.com Thu Sep 4 06:48:32 2008 From: aphukan.fedora at gmail.com (Amitakhya Phukan) Date: Thu, 04 Sep 2008 12:18:32 +0530 Subject: need approval In-Reply-To: <48BF7A3B.30206@gmail.com> References: <48BF7A3B.30206@gmail.com> Message-ID: <48BF84C0.30205@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Amitakhya Phukan wrote: > Hi, > > I am interested in joining the Fedora Infrastructure team. I am > interested in general sysadmin, sysadmin-test and sysadmin-hosted > groups. Can anyone sponsor me ? > > Regards, Amit. hi, I am approved for sysadmin group .. I want to join the sysadmin-test and sysadmin-hosted groups. Can anyone sponsor me there ? Regards, Amit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAki/hMAACgkQisV6fTFpwA202ACeOcnLvEtigF9EXB0QC64aoHSI wREAnROejQvefombEagOBFJYNpyGR8Dm =uBlU -----END PGP SIGNATURE----- From mmcgrath at redhat.com Thu Sep 4 13:24:42 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 4 Sep 2008 08:24:42 -0500 (CDT) Subject: need approval In-Reply-To: <48BF84C0.30205@gmail.com> References: <48BF7A3B.30206@gmail.com> <48BF84C0.30205@gmail.com> Message-ID: On Thu, 4 Sep 2008, Amitakhya Phukan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Amitakhya Phukan wrote: > > Hi, > > > > I am interested in joining the Fedora Infrastructure team. I am > > interested in general sysadmin, sysadmin-test and sysadmin-hosted > > groups. Can anyone sponsor me ? > > > > Regards, Amit. > hi, > > I am approved for sysadmin group .. I want to join the sysadmin-test > and sysadmin-hosted groups. Can anyone sponsor me there ? > When looking for sponsorship its best to say specifically what you are looking to do. Is there a ticket or specific project you're interested in working on? -Mike From aphukan.fedora at gmail.com Thu Sep 4 14:50:48 2008 From: aphukan.fedora at gmail.com (Amitakhya Phukan) Date: Thu, 04 Sep 2008 20:20:48 +0530 Subject: need approval In-Reply-To: References: <48BF7A3B.30206@gmail.com> <48BF84C0.30205@gmail.com> Message-ID: <48BFF5C8.4040702@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike McGrath wrote: > On Thu, 4 Sep 2008, Amitakhya Phukan wrote: > >> hi, >> >> I am approved for sysadmin group .. I want to join the >> sysadmin-test and sysadmin-hosted groups. Can anyone sponsor me >> there ? >> > > When looking for sponsorship its best to say specifically what you > are looking to do. Is there a ticket or specific project you're > interested in working on? > > -Mike Hi Mike, Did you mean this : https://fedorahosted.org/fedora-infrastructure/report Well, I have been looking at this page and I don't understand the differences between the different colored areas. Since I am interested in sysadmin-test and sysadmin-hosted, which of those should I be studying before coming up with any ideas ? One ticket assigned to "nobody" is Ticket #629. Another is Ticket #396. But they are in different colored areas. Can you give me some guide where and what I should be looking for ? Regards, Amit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAki/9cUACgkQisV6fTFpwA3fNwCfadrxV8suJYQJ0d+xdhxt2/xI H5IAnAgUqxXdLWoTFfbFPELfVKbSmeFu =3Ptg -----END PGP SIGNATURE----- From mmcgrath at redhat.com Thu Sep 4 15:05:32 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 4 Sep 2008 10:05:32 -0500 (CDT) Subject: need approval In-Reply-To: <48BFF5C8.4040702@gmail.com> References: <48BF7A3B.30206@gmail.com> <48BF84C0.30205@gmail.com> <48BFF5C8.4040702@gmail.com> Message-ID: On Thu, 4 Sep 2008, Amitakhya Phukan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Mike McGrath wrote: > > On Thu, 4 Sep 2008, Amitakhya Phukan wrote: > > > >> hi, > >> > >> I am approved for sysadmin group .. I want to join the > >> sysadmin-test and sysadmin-hosted groups. Can anyone sponsor me > >> there ? > >> > > > > When looking for sponsorship its best to say specifically what you > > are looking to do. Is there a ticket or specific project you're > > interested in working on? > > > > -Mike > > Hi Mike, > > Did you mean this : https://fedorahosted.org/fedora-infrastructure/report > > Well, I have been looking at this page and I don't understand the > differences between the different colored areas. Since I am interested > in sysadmin-test and sysadmin-hosted, which of those should I be > studying before coming up with any ideas ? > > One ticket assigned to "nobody" is Ticket #629. Another is Ticket > #396. But they are in different colored areas. Can you give me some > guide where and what I should be looking for ? > Its important to focus on what you want to do. Neither one of the tickets above involve sysadmin-test or sysadmin-hosted really. 629 could use sysadmin-test but it would probably be better to get it up and running on your workstation first. As far as what to look for, mostly pick things that you're good at or interested in. If you have python experience you could get working on 629 and submit a patch. The code is at: http://git.fedoraproject.org/git/fedora-web.git/ -Mike From mmcgrath at redhat.com Thu Sep 4 15:08:43 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 4 Sep 2008 10:08:43 -0500 (CDT) Subject: need approval In-Reply-To: References: <48BF7A3B.30206@gmail.com> <48BF84C0.30205@gmail.com> <48BFF5C8.4040702@gmail.com> Message-ID: On Thu, 4 Sep 2008, Mike McGrath wrote: > On Thu, 4 Sep 2008, Amitakhya Phukan wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Mike McGrath wrote: > > > On Thu, 4 Sep 2008, Amitakhya Phukan wrote: > > > > > >> hi, > > >> > > >> I am approved for sysadmin group .. I want to join the > > >> sysadmin-test and sysadmin-hosted groups. Can anyone sponsor me > > >> there ? > > >> > > > > > > When looking for sponsorship its best to say specifically what you > > > are looking to do. Is there a ticket or specific project you're > > > interested in working on? > > > > > > -Mike > > > > Hi Mike, > > > > Did you mean this : https://fedorahosted.org/fedora-infrastructure/report > > > > Well, I have been looking at this page and I don't understand the > > differences between the different colored areas. Since I am interested > > in sysadmin-test and sysadmin-hosted, which of those should I be > > studying before coming up with any ideas ? > > > > One ticket assigned to "nobody" is Ticket #629. Another is Ticket > > #396. But they are in different colored areas. Can you give me some > > guide where and what I should be looking for ? > > > > Its important to focus on what you want to do. Neither one of the tickets > above involve sysadmin-test or sysadmin-hosted really. 629 could use > sysadmin-test but it would probably be better to get it up and running on > your workstation first. > > As far as what to look for, mostly pick things that you're good at or > interested in. If you have python experience you could get working on 629 > and submit a patch. The code is at: > > http://git.fedorahosted.org/git/fedora-web.git/ > Sorry, ticket 396 can be done at that site. ticket 629 could be tested on your workstation just by using yum to install mediawiki. -Mike From tjdavisbz at gmail.com Thu Sep 4 15:10:32 2008 From: tjdavisbz at gmail.com (TJ Davis) Date: Thu, 4 Sep 2008 09:10:32 -0600 Subject: Introduction Message-ID: <64677a960809040810g48ad84cflb9661115b41620ca@mail.gmail.com> Hi All, I have been watching this email list for awhile and decided to finally introduce myself. I am TJ Davis from West Texas but I currently live in Belize. I am an independent software consultant for several universities. I mostly do database consulting on MSSQL but have about 10 years of experience with LAMP and Linux administration. I have not managed enterprise level systems but have managed 6 Linux servers doing various tasks for a university for 10 years. I also have a good amount of experience with OpenVPN as well as SpamAssassin/Amavis/Maia/Clamv. I will start reading over tickets soon and try to pick some once I have been accepted. But, in the mean time, if anyone knows where I might fit in best give me a shout. I will be on #fedora-admin as tjdavisbz as much as possible. Tj From aphukan.fedora at gmail.com Thu Sep 4 15:26:46 2008 From: aphukan.fedora at gmail.com (Amitakhya Phukan) Date: Thu, 04 Sep 2008 20:56:46 +0530 Subject: need approval In-Reply-To: References: <48BF7A3B.30206@gmail.com> <48BF84C0.30205@gmail.com> <48BFF5C8.4040702@gmail.com> Message-ID: <48BFFE36.5090802@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike McGrath wrote: > On Thu, 4 Sep 2008, Mike McGrath wrote: > >> On Thu, 4 Sep 2008, Amitakhya Phukan wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> Mike McGrath wrote: >>>> On Thu, 4 Sep 2008, Amitakhya Phukan wrote: >>>> >>>>> hi, >>>>> >>>>> I am approved for sysadmin group .. I want to join the >>>>> sysadmin-test and sysadmin-hosted groups. Can anyone >>>>> sponsor me there ? >>>>> >>>> When looking for sponsorship its best to say specifically >>>> what you are looking to do. Is there a ticket or specific >>>> project you're interested in working on? >>>> >>>> -Mike >>> Hi Mike, >>> >>> Did you mean this : >>> https://fedorahosted.org/fedora-infrastructure/report >>> >>> Well, I have been looking at this page and I don't understand >>> the differences between the different colored areas. Since I am >>> interested in sysadmin-test and sysadmin-hosted, which of those >>> should I be studying before coming up with any ideas ? >>> >>> One ticket assigned to "nobody" is Ticket #629. Another is >>> Ticket #396. But they are in different colored areas. Can you >>> give me some guide where and what I should be looking for ? >>> >> Its important to focus on what you want to do. Neither one of >> the tickets above involve sysadmin-test or sysadmin-hosted >> really. 629 could use sysadmin-test but it would probably be >> better to get it up and running on your workstation first. >> >> As far as what to look for, mostly pick things that you're good >> at or interested in. If you have python experience you could get >> working on 629 and submit a patch. The code is at: >> >> http://git.fedorahosted.org/git/fedora-web.git/ >> > > Sorry, ticket 396 can be done at that site. ticket 629 could be > tested on your workstation just by using yum to install mediawiki. > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list ok lemme install Fedora on my test station and will ping you tomorrow. thanks, amit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAki//jUACgkQisV6fTFpwA12yACgss2/aygGaOMy/AYySq065ZVq hAoAoKjNr+lI0BlCQwWN5GoFGLKwhM88 =iwYg -----END PGP SIGNATURE----- From mmcgrath at redhat.com Thu Sep 4 16:40:13 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 4 Sep 2008 11:40:13 -0500 (CDT) Subject: Introduction In-Reply-To: <64677a960809040810g48ad84cflb9661115b41620ca@mail.gmail.com> References: <64677a960809040810g48ad84cflb9661115b41620ca@mail.gmail.com> Message-ID: On Thu, 4 Sep 2008, TJ Davis wrote: > Hi All, > > I have been watching this email list for awhile and decided to finally > introduce myself. I am TJ Davis from West Texas but I currently live > in Belize. I am an independent software consultant for several > universities. I mostly do database consulting on MSSQL but have about > 10 years of experience with LAMP and Linux administration. I have not > managed enterprise level systems but have managed 6 Linux servers > doing various tasks for a university for 10 years. I also have a good > amount of experience with OpenVPN as well as OpenVPN ehh? I'll be pinging you about that soon :) In the meantime please do try to attend our weekly meetings: http://fedoraproject.org/wiki/Infrastructure/Meetings -Mike From dev at nigelj.com Thu Sep 4 20:07:04 2008 From: dev at nigelj.com (Nigel Jones) Date: Fri, 05 Sep 2008 08:07:04 +1200 Subject: need approval In-Reply-To: <48BFFE36.5090802@gmail.com> References: <48BF7A3B.30206@gmail.com> <48BF84C0.30205@gmail.com> <48BFF5C8.4040702@gmail.com> <48BFFE36.5090802@gmail.com> Message-ID: <1220558824.3791.2.camel@fantail.jnet.net.nz> On Thu, 2008-09-04 at 20:56 +0530, Amitakhya Phukan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Mike McGrath wrote: > > On Thu, 4 Sep 2008, Mike McGrath wrote: > > > >> On Thu, 4 Sep 2008, Amitakhya Phukan wrote: > >> > >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >>> > >>> Mike McGrath wrote: > >>>> On Thu, 4 Sep 2008, Amitakhya Phukan wrote: > >>>> > >>>>> hi, > >>>>> > >>>>> I am approved for sysadmin group .. I want to join the > >>>>> sysadmin-test and sysadmin-hosted groups. Can anyone > >>>>> sponsor me there ? > >>>>> > >>>> When looking for sponsorship its best to say specifically > >>>> what you are looking to do. Is there a ticket or specific > >>>> project you're interested in working on? > >>>> > >>>> -Mike > >>> Hi Mike, > >>> > >>> Did you mean this : > >>> https://fedorahosted.org/fedora-infrastructure/report > >>> > >>> Well, I have been looking at this page and I don't understand > >>> the differences between the different colored areas. Since I am > >>> interested in sysadmin-test and sysadmin-hosted, which of those > >>> should I be studying before coming up with any ideas ? > >>> > >>> One ticket assigned to "nobody" is Ticket #629. Another is > >>> Ticket #396. But they are in different colored areas. Can you > >>> give me some guide where and what I should be looking for ? > >>> > >> Its important to focus on what you want to do. Neither one of > >> the tickets above involve sysadmin-test or sysadmin-hosted > >> really. 629 could use sysadmin-test but it would probably be > >> better to get it up and running on your workstation first. > >> > >> As far as what to look for, mostly pick things that you're good > >> at or interested in. If you have python experience you could get > >> working on 629 and submit a patch. The code is at: > >> > >> http://git.fedorahosted.org/git/fedora-web.git/ > >> > > > > Sorry, ticket 396 can be done at that site. ticket 629 could be > > tested on your workstation just by using yum to install mediawiki. Argh, apologies everyone, but the fix is actually in the Fedora package review queue already. I forgot to check what tickets were in trac first. (It'll basically add the footnotes function to Mediawiki). - Nigel > > > > -Mike > > > > _______________________________________________ > > Fedora-infrastructure-list mailing list > > Fedora-infrastructure-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > ok > lemme install Fedora on my test station and will ping you tomorrow. > > thanks, > amit. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAki//jUACgkQisV6fTFpwA12yACgss2/aygGaOMy/AYySq065ZVq > hAoAoKjNr+lI0BlCQwWN5GoFGLKwhM88 > =iwYg > -----END PGP SIGNATURE----- > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- Nigel Jones From aphukan.fedora at gmail.com Fri Sep 5 04:41:38 2008 From: aphukan.fedora at gmail.com (Amitakhya Phukan) Date: Fri, 05 Sep 2008 10:11:38 +0530 Subject: need approval In-Reply-To: <1220558824.3791.2.camel@fantail.jnet.net.nz> References: <48BF7A3B.30206@gmail.com> <48BF84C0.30205@gmail.com> <48BFF5C8.4040702@gmail.com> <48BFFE36.5090802@gmail.com> <1220558824.3791.2.camel@fantail.jnet.net.nz> Message-ID: <48C0B882.5010004@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nigel Jones wrote: > On Thu, 2008-09-04 at 20:56 +0530, Amitakhya Phukan wrote: > >> Argh, apologies everyone, but the fix is actually in the Fedora > package >> review queue already. I forgot to check what tickets were in >> trac first. > >> (It'll basically add the footnotes function to Mediawiki). > >> - Nigel hmm.. so this one's gone from the list. ok, i will hunt for more. regards, amit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjAuH8ACgkQisV6fTFpwA0ryACgqL34jfpd20L1fE1Sfr0UYNLb T94AoLh/v8RrbGa46xmv/ws9dXVrHiY8 =cvx5 -----END PGP SIGNATURE----- From sujansunil at gmail.com Fri Sep 5 06:50:31 2008 From: sujansunil at gmail.com (sujan sunil pilli) Date: Fri, 5 Sep 2008 12:20:31 +0530 Subject: (no subject) Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From huzaifas at redhat.com Fri Sep 5 07:04:04 2008 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Fri, 05 Sep 2008 12:34:04 +0530 Subject: Interested in doing some fedora cvs work Message-ID: <48C0D9E4.1040004@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, Now that i am in the sysadmin group. I have taken a thorough look at all the other FIGS which are listed. I have also taken a look at the kind of work the people in the FIGS do and i would like to get involved with the cvs group. I have a good amount of technical experience with cvs and svn, so that should not be a barrier. Can Mike, Bill or Dennis, sponsor me to this group please? Thanks a lot. - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFIwNnkzHDc8tpb2uURApOKAJ95P7ND8Wt68Xm+1FuPd45gIYLT3ACePwEe UotTlcg06khaN2pjWpK/isI= =eHs6 -----END PGP SIGNATURE----- From orion at cora.nwra.com Fri Sep 5 18:49:24 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 05 Sep 2008 12:49:24 -0600 Subject: Strange build error for classpathx-mail Message-ID: <48C17F34.2010207@cora.nwra.com> Starting looking into updating classpathx-mail to version 1.1.2 (anyone know of a reason not to?). Got a really weird internal compiler error on the ppc64 build: [javac] 1. ERROR in /builddir/build/BUILD/mail-1.1.2/inetlib-1.1.1/source/org/jpackage/mail/inet/imap/IMAPConnection.java (at line 0) [javac] /* [javac] ^ [javac] Internal compiler error [javac] java.lang.NullPointerException [javac] at org.eclipse.jdt.internal.compiler.looku [javac] p.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:262) [javac] at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:719) [javac] at org.eclipse.jdt.i [javac] nternal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:699) [javac] at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:294) [javac] at org.eclipse.jdt.internal.com [javac] piler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:128) [javac] at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:179) [javac] at org.eclipse.jdt.inte [javac] rnal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:456) [javac] at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:510) [javac] at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:359) [javac] at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(Compi [javac] lationUnitScope.java:435) [javac] at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:736) [javac] at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137) [javac] at java.lang.Thread.run(libgcj.so.9) Other arches seemed okay but got cancelled. See: http://koji.fedoraproject.org/koji/taskinfo?taskID=809142 This was on ppc7. Resubmitted and it built okay (or at least got past this point). This time on ppc2 http://koji.fedoraproject.org/koji/taskinfo?taskID=809169 Fully successful build (if anyone wants to take a look at the package): http://koji.fedoraproject.org/koji/taskinfo?taskID=809200 -- 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 mmcgrath at redhat.com Fri Sep 5 19:16:03 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 5 Sep 2008 14:16:03 -0500 (CDT) Subject: staging environment discussion Message-ID: So as many of you have seen in the commits lists, the staging environment is coming along and getting built. I've hit a policy issue and so I thought instead of just doing this in a black hole. I'd discuss it. The way I see it there are two ways to do staging environments. For those of you unfamiliar with staging the general idea is to have an environment as close to production as feasible. 1) use identical configs with only minor changes and use /etc/hosts to fake things to point where you need them. Not always possible but generally good where you can do it. 2) use different configs in production and staging. The differences being able to redirect things, using different usernames, passwords, hostnames, etc. Each has pros and cons. Right now I'd like to do 1) but I don't think its possible. 2) is going to require a lot of focus. For example... we won't be able to just git merge from staging to production as we could with 1). Security's only an issue in that we don't want people making changes to production data from staging and vise versa. The same people will have the same access to both of these environments without exception. I'm going to continue to think about this. I've had staging environments in the past. Both went with option 2). But still. I'd like to hold this discussion so discuss. -Mike From smooge at gmail.com Fri Sep 5 19:58:20 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 5 Sep 2008 13:58:20 -0600 Subject: staging environment discussion In-Reply-To: References: Message-ID: <80d7e4090809051258y3b3db191y98bfce10d3bb0523@mail.gmail.com> On Fri, Sep 5, 2008 at 1:16 PM, Mike McGrath wrote: > So as many of you have seen in the commits lists, the staging environment > is coming along and getting built. I've hit a policy issue and so I > thought instead of just doing this in a black hole. I'd discuss it. > > The way I see it there are two ways to do staging environments. For those > of you unfamiliar with staging the general idea is to have an environment > as close to production as feasible. > > 1) use identical configs with only minor changes and use /etc/hosts to > fake things to point where you need them. Not always possible but > generally good where you can do it. > > 2) use different configs in production and staging. The differences being > able to redirect things, using different usernames, passwords, hostnames, > etc. > > > Each has pros and cons. Right now I'd like to do 1) but I don't think its > possible. 2) is going to require a lot of focus. For example... we won't > be able to just git merge from staging to production as we could with 1). > there is also a combination of #1 and #2. Basically you have to create 3-4 separate network topologies (this is where you have different configs), and maybe have your bastion/proxy systems different. Name Network Network A: Development -- 10.10.0.0/21 Servers -- 10.10.0.0/22 NFS -- 10.10.4.0/22 Network B: QA -- 10.10.8.0/21 Servers -- 10.10.8.0/22 NFS -- 10.10.12.0/22 Network C: Staging -- 10.10.16.0/21 Servers -- 10.10.16.0/22 NFS -- 10.10.20.0/22 Network D: Production -- 10.10.24.0/21 Servers -- 10.10.24.0/22 NFS -- 10.10.28.0/22 Network E: Management -- 10.10.32.0/20 Puppet -- 10.10.32.0/21 Drac/Serial -- 10.10.48.0/21 Network F: Bastion Network [Ok I would love to have done this when I was at RH... but didn't really see it in action til later.] Basically a box would have 3-4 network connections. The puppet and drac/serial networks are on all systems so have to be extra protected as that is where an attacker could walk from system to system. The bastion network is basically the front end that would do rewrites and other layers so that configs are the same. And yes, this might be overkill and probably has holes in it.. I am doing it from memory on how a site seemed to be set up and had basically little downtime for critical HR services. > Security's only an issue in that we don't want people making changes to > production data from staging and vise versa. The same people will have > the same access to both of these environments without exception. > > I'm going to continue to think about this. I've had staging environments > in the past. Both went with option 2). But still. I'd like to hold this > discussion so discuss. > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From orion at cora.nwra.com Fri Sep 5 20:23:47 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 05 Sep 2008 14:23:47 -0600 Subject: [fedora-java] Strange build error for classpathx-mail In-Reply-To: <48C1811F.4090003@redhat.com> References: <48C17F34.2010207@cora.nwra.com> <48C1811F.4090003@redhat.com> Message-ID: <48C19553.9050401@cora.nwra.com> Andrew Haley wrote: > > This is probably https://bugzilla.redhat.com/show_bug.cgi?id=459129 > > Jakub has a patch and we're waiting for gcj to be respun into a new RPM. > > Andrew. Indeed. Thanks. -- 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 mmcgrath at redhat.com Fri Sep 5 21:47:51 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 5 Sep 2008 16:47:51 -0500 (CDT) Subject: staging environment discussion In-Reply-To: <80d7e4090809051258y3b3db191y98bfce10d3bb0523@mail.gmail.com> References: <80d7e4090809051258y3b3db191y98bfce10d3bb0523@mail.gmail.com> Message-ID: On Fri, 5 Sep 2008, Stephen John Smoogen wrote: > there is also a combination of #1 and #2. Basically you have to create > 3-4 separate network topologies (this is where you have different > configs), and maybe have your bastion/proxy systems different. > > Name Network > Network A: Development -- 10.10.0.0/21 > Servers -- 10.10.0.0/22 > NFS -- 10.10.4.0/22 > Network B: QA -- 10.10.8.0/21 > Servers -- 10.10.8.0/22 > NFS -- 10.10.12.0/22 > Network C: Staging -- 10.10.16.0/21 > Servers -- 10.10.16.0/22 > NFS -- 10.10.20.0/22 > Network D: Production -- 10.10.24.0/21 > Servers -- 10.10.24.0/22 > NFS -- 10.10.28.0/22 > Network E: Management -- 10.10.32.0/20 > Puppet -- 10.10.32.0/21 > Drac/Serial -- 10.10.48.0/21 > Network F: Bastion Network > > [Ok I would love to have done this when I was at RH... but didn't > really see it in action til later.] > > Basically a box would have 3-4 network connections. The puppet and > drac/serial networks are on all systems so have to be extra protected > as that is where an attacker could walk from system to system. The > bastion network is basically the front end that would do rewrites and > other layers so that configs are the same. > > And yes, this might be overkill and probably has holes in it.. I am > doing it from memory on how a site seemed to be set up and had > basically little downtime for critical HR services. > We are actually looking to get more network separation in place but right now thats slow and is going to involve the buildsystem first. But at some point in the not too distant future I would like to separate stg and production environments. -Mike From dan-fedora-i at drown.org Sat Sep 6 01:23:12 2008 From: dan-fedora-i at drown.org (Daniel Drown) Date: Sat, 6 Sep 2008 01:23:12 +0000 Subject: staging environment discussion In-Reply-To: References: Message-ID: <20080906012312.GB32053@vps.drown.org> On Fri, 05 Sep 2008, Mike McGrath wrote: > So as many of you have seen in the commits lists, the staging environment > is coming along and getting built. I've hit a policy issue and so I > thought instead of just doing this in a black hole. I'd discuss it. > > The way I see it there are two ways to do staging environments. For those > of you unfamiliar with staging the general idea is to have an environment > as close to production as feasible. > > 1) use identical configs with only minor changes and use /etc/hosts to > fake things to point where you need them. Not always possible but > generally good where you can do it. > > 2) use different configs in production and staging. The differences being > able to redirect things, using different usernames, passwords, hostnames, > etc. > > Each has pros and cons. Right now I'd like to do 1) but I don't think its > possible. 2) is going to require a lot of focus. For example... we won't > be able to just git merge from staging to production as we could with 1). > > Security's only an issue in that we don't want people making changes to > production data from staging and vise versa. The same people will have > the same access to both of these environments without exception. > > I'm going to continue to think about this. I've had staging environments > in the past. Both went with option 2). But still. I'd like to hold this > discussion so discuss. What I've done is #2, but with software that accepts a second config file that overrides the first. The first config is the same between production and staging, and the staging specific config is in the second file. That way you can keep your staging settings from accidently getting migrated to production. This works best if you only have a small amount of changes between staging and production and if your software supports it. Maybe puppet templates for all the config files that differ would be the best way to handle f-i's needs? From sujansunil at gmail.com Sat Sep 6 03:24:25 2008 From: sujansunil at gmail.com (sujan sunil pilli) Date: Sat, 6 Sep 2008 08:54:25 +0530 Subject: need approval Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtogami at redhat.com Sat Sep 6 07:36:52 2008 From: wtogami at redhat.com (Warren Togami) Date: Sat, 06 Sep 2008 03:36:52 -0400 Subject: Test fedora-release packages for F8 and F9 Message-ID: <48C23314.9040101@redhat.com> http://togami.com/~warren/fedora/fedora-release-8-5.transitiontest1.noarch.rpm http://togami.com/~warren/fedora/fedora-release-9-3.transitiontest1.noarch.rpm Test fedora-release packages pointing at the newkey update repos. Attached are sha1sums GPG clearsigned by my personal GPG keyid 54A2ACF1. Some cursory tests have indicated that no typos are in these new .repo files. Please test these and report if you see any errors. The F9 version seems to work fine with yum, but unfortunately it exposes one or more nasty bugs in PackageKit so we likely need more work before updates can go live. http://lists.fedoraproject.org/pipermail/rel-eng/2008-September/001702.html http://lists.fedoraproject.org/pipermail/rel-eng/2008-September/001704.html Discussion ensues about our options for the F9 PackageKit problem... http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html These packages are drafts the first fedora-release of the newrepo process. After this has settled in we will push another fedora-release in the newrepo signed by the newkey in order to complete the transition and eliminate the old repos from the user's system. Warren Togami wtogami at redhat.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fedora-release-test-sha1sums.txt URL: From Matt_Domsch at dell.com Sat Sep 6 12:48:59 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 6 Sep 2008 07:48:59 -0500 Subject: archives on secondary1 Message-ID: <20080906124859.GA24018@auslistsprd01.us.dell.com> quick sanity check. archives.fp.o is on secondary1.fp.o, right? There are 2 separate rsyncd.conf files in puppet, one for archives, one for secondary. Given they land at the same place on the same machine, only the one for secondary is actually in effect. If they're going to be on the same machine, we need to merge them. yes? Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mmcgrath at redhat.com Sat Sep 6 15:05:05 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 6 Sep 2008 10:05:05 -0500 (CDT) Subject: archives on secondary1 In-Reply-To: <20080906124859.GA24018@auslistsprd01.us.dell.com> References: <20080906124859.GA24018@auslistsprd01.us.dell.com> Message-ID: On Sat, 6 Sep 2008, Matt Domsch wrote: > quick sanity check. archives.fp.o is on secondary1.fp.o, right? > > There are 2 separate rsyncd.conf files in puppet, one for archives, > one for secondary. Given they land at the same place on the same > machine, only the one for secondary is actually in effect. If they're > going to be on the same machine, we need to merge them. > > yes? > Correct. I only copied the files from the old archives box to the new one and forgot to merge the configs. -Mike From Matt_Domsch at dell.com Sat Sep 6 21:53:45 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 6 Sep 2008 16:53:45 -0500 Subject: archives on secondary1 In-Reply-To: References: <20080906124859.GA24018@auslistsprd01.us.dell.com> Message-ID: <20080906215345.GB9759@auslistsprd01.us.dell.com> On Sat, Sep 06, 2008 at 10:05:05AM -0500, Mike McGrath wrote: > On Sat, 6 Sep 2008, Matt Domsch wrote: > > > quick sanity check. archives.fp.o is on secondary1.fp.o, right? > > > > There are 2 separate rsyncd.conf files in puppet, one for archives, > > one for secondary. Given they land at the same place on the same > > machine, only the one for secondary is actually in effect. If they're > > going to be on the same machine, we need to merge them. > > > > yes? > > > > Correct. I only copied the files from the old archives box to the new one > and forgot to merge the configs. no worries, it's done now. They're all in secondary's config. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mmcgrath at redhat.com Mon Sep 8 13:56:48 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 8 Sep 2008 08:56:48 -0500 (CDT) Subject: Last week Message-ID: Strange week last week, many of you noticed a bunch of nagios outages so I thought I'd send a roundup of what happened. 1) The big one was what seems to be a corrupt database table. For some reason running a vacuum on a table (which was only 66M large) was taking a long time and even after it would finish the disks would thrash for sometimes 10 minutes after. This caused outages of lots of our systems like the account system, to which other systems depend. The job was hourly so thats why it kept happening. We were able to reproduce this on another host and never quite figured out what was going on but a dump, drop, restore fixed the issue and so far we haven't had time to revisit what was going on, just that it hasn't happened since. 2) Strange network issues towards the end of the week. Seems our round time to server beach went up causing nagios to flag some hosts as dead. I've also not yet had time to look into this. The network seems and I don't think we're seeing any functional issues from it but it was different. 3) pkgdb's home page started taking longer to load causing our balancer to start flagging it dead causing it to throw 503's. We only recently moved it to haproxy so this could be a normal behavior that we just didn't see. I've moved response time of the front page up to 5 seconds from 2. -Mike From mmcgrath at redhat.com Mon Sep 8 15:16:28 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 8 Sep 2008 10:16:28 -0500 (CDT) Subject: More puppet training! Message-ID: So I'm going to hold a couple more training seminars for Puppet in Fedora's Infrastructure. I was hoping you guys could also throw some questions together so i make sure I don't miss anything. -Mike From smooge at gmail.com Mon Sep 8 15:19:29 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 8 Sep 2008 09:19:29 -0600 Subject: More puppet training! In-Reply-To: References: Message-ID: <80d7e4090809080819ma2888c9u59910db7ec862516@mail.gmail.com> On Mon, Sep 8, 2008 at 9:16 AM, Mike McGrath wrote: > So I'm going to hold a couple more training seminars for Puppet in > Fedora's Infrastructure. I was hoping you guys could also throw some > questions together so i make sure I don't miss anything. > Are the old seminars up somewhere? My whole look at puppet is from 30k. I know more about cfengine .. which has made me look at some of the 'limitations' of puppet as 'huh?' versus purposeful design decisions. Heck I don't even know how to make a root password across a cluster :). -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From tjdavisbz at gmail.com Mon Sep 8 15:20:00 2008 From: tjdavisbz at gmail.com (TJ Davis) Date: Mon, 8 Sep 2008 09:20:00 -0600 Subject: Introduction In-Reply-To: References: <64677a960809040810g48ad84cflb9661115b41620ca@mail.gmail.com> Message-ID: <64677a960809080820w3e91531coc7154446578bd64e@mail.gmail.com> Sounds good. I will definitely start attending meetings. Let me know when you are ready to chat about OpenVPN. I am anxious to help in any way. On Thu, Sep 4, 2008 at 10:40 AM, Mike McGrath wrote: > On Thu, 4 Sep 2008, TJ Davis wrote: > >> Hi All, >> >> I have been watching this email list for awhile and decided to finally >> introduce myself. I am TJ Davis from West Texas but I currently live >> in Belize. I am an independent software consultant for several >> universities. I mostly do database consulting on MSSQL but have about >> 10 years of experience with LAMP and Linux administration. I have not >> managed enterprise level systems but have managed 6 Linux servers >> doing various tasks for a university for 10 years. I also have a good >> amount of experience with OpenVPN as well as > > OpenVPN ehh? I'll be pinging you about that soon :) In the meantime > please do try to attend our weekly meetings: > > http://fedoraproject.org/wiki/Infrastructure/Meetings > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From skvidal at fedoraproject.org Mon Sep 8 15:33:57 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 08 Sep 2008 11:33:57 -0400 Subject: More puppet training! In-Reply-To: <80d7e4090809080819ma2888c9u59910db7ec862516@mail.gmail.com> References: <80d7e4090809080819ma2888c9u59910db7ec862516@mail.gmail.com> Message-ID: <1220888037.987.19.camel@rosebud> On Mon, 2008-09-08 at 09:19 -0600, Stephen John Smoogen wrote: > On Mon, Sep 8, 2008 at 9:16 AM, Mike McGrath wrote: > > So I'm going to hold a couple more training seminars for Puppet in > > Fedora's Infrastructure. I was hoping you guys could also throw some > > questions together so i make sure I don't miss anything. > > > > Are the old seminars up somewhere? My whole look at puppet is from > 30k. I know more about cfengine .. which has made me look at some of > the 'limitations' of puppet as 'huh?' versus purposeful design > decisions. Heck I don't even know how to make a root password across a > cluster :). don't feel bad, no one else does, either. Not without leaving the crypted password all over the logs. Well, to be fair, there's a way to do it, it's just hurky and feels silly. -sv From jkeating at redhat.com Mon Sep 8 15:33:57 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 08 Sep 2008 08:33:57 -0700 Subject: Last week In-Reply-To: References: Message-ID: <1220888037.17700.11.camel@luminos.localdomain> On Mon, 2008-09-08 at 08:56 -0500, Mike McGrath wrote: > > Strange week last week, many of you noticed a bunch of nagios outages so I > thought I'd send a roundup of what happened. Any ideas what has been making releng2 flap? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Sep 8 15:35:43 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 08 Sep 2008 08:35:43 -0700 Subject: More puppet training! In-Reply-To: References: Message-ID: <1220888143.17700.13.camel@luminos.localdomain> On Mon, 2008-09-08 at 10:16 -0500, Mike McGrath wrote: > So I'm going to hold a couple more training seminars for Puppet in > Fedora's Infrastructure. I was hoping you guys could also throw some > questions together so i make sure I don't miss anything. The "standard" way to define users, packages, directories, files, cron jobs, and using variables or host specific definitions within a shared class file. I think our current files have multiple ways of doing all the above and I'd like to see the current thought of standard practice (and then maybe an effort to convert the current setup to the standards). -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dennis at ausil.us Mon Sep 8 15:39:19 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 8 Sep 2008 10:39:19 -0500 Subject: More puppet training! In-Reply-To: References: Message-ID: <200809081039.24281.dennis@ausil.us> On Monday 08 September 2008 10:16:28 am Mike McGrath wrote: > So I'm going to hold a couple more training seminars for Puppet in > Fedora's Infrastructure. I was hoping you guys could also throw some > questions together so i make sure I don't miss anything. Id like to know where should i put a script in the puppet tree. where should I put config files etc. what if its something needed on 2 systems that have different purposes should i create a new class? or just add it to each of the two groups?. but a shared group. that kind of thing. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From mmcgrath at redhat.com Mon Sep 8 16:49:31 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 8 Sep 2008 11:49:31 -0500 (CDT) Subject: More puppet training! In-Reply-To: <1220888037.987.19.camel@rosebud> References: <80d7e4090809080819ma2888c9u59910db7ec862516@mail.gmail.com> <1220888037.987.19.camel@rosebud> Message-ID: On Mon, 8 Sep 2008, Seth Vidal wrote: > On Mon, 2008-09-08 at 09:19 -0600, Stephen John Smoogen wrote: > > On Mon, Sep 8, 2008 at 9:16 AM, Mike McGrath wrote: > > > So I'm going to hold a couple more training seminars for Puppet in > > > Fedora's Infrastructure. I was hoping you guys could also throw some > > > questions together so i make sure I don't miss anything. > > > > > > > Are the old seminars up somewhere? My whole look at puppet is from > > 30k. I know more about cfengine .. which has made me look at some of > > the 'limitations' of puppet as 'huh?' versus purposeful design > > decisions. Heck I don't even know how to make a root password across a > > cluster :). > > > don't feel bad, no one else does, either. > > Not without leaving the crypted password all over the logs. > > Well, to be fair, there's a way to do it, it's just hurky and feels > silly. > I was kind of irked about that too. I'm going to file a ticket to make sure this gets handled. Really I guess it'd be nice to have a logDiff => false option where it'd at least let you know something happened but not what if it was explicitly listed. There's other uses for this besides just root passwords. Ticket: http://reductivelabs.com/redmine/issues/show/1566 -Mike From mmcgrath at redhat.com Mon Sep 8 16:50:06 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 8 Sep 2008 11:50:06 -0500 (CDT) Subject: Last week In-Reply-To: <1220888037.17700.11.camel@luminos.localdomain> References: <1220888037.17700.11.camel@luminos.localdomain> Message-ID: On Mon, 8 Sep 2008, Jesse Keating wrote: > On Mon, 2008-09-08 at 08:56 -0500, Mike McGrath wrote: > > > > Strange week last week, many of you noticed a bunch of nagios outages so I > > thought I'd send a roundup of what happened. > > Any ideas what has been making releng2 flap? > I was away this weekend but did see the notice that releng2 rebooted again. I take it that was not intended? I'll ping you on irc. -Mike From skvidal at fedoraproject.org Mon Sep 8 16:52:24 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 08 Sep 2008 12:52:24 -0400 Subject: More puppet training! In-Reply-To: References: <80d7e4090809080819ma2888c9u59910db7ec862516@mail.gmail.com> <1220888037.987.19.camel@rosebud> Message-ID: <1220892744.987.43.camel@rosebud> On Mon, 2008-09-08 at 11:49 -0500, Mike McGrath wrote: > On Mon, 8 Sep 2008, Seth Vidal wrote: > > > On Mon, 2008-09-08 at 09:19 -0600, Stephen John Smoogen wrote: > > > On Mon, Sep 8, 2008 at 9:16 AM, Mike McGrath wrote: > > > > So I'm going to hold a couple more training seminars for Puppet in > > > > Fedora's Infrastructure. I was hoping you guys could also throw some > > > > questions together so i make sure I don't miss anything. > > > > > > > > > > Are the old seminars up somewhere? My whole look at puppet is from > > > 30k. I know more about cfengine .. which has made me look at some of > > > the 'limitations' of puppet as 'huh?' versus purposeful design > > > decisions. Heck I don't even know how to make a root password across a > > > cluster :). > > > > > > don't feel bad, no one else does, either. > > > > Not without leaving the crypted password all over the logs. > > > > Well, to be fair, there's a way to do it, it's just hurky and feels > > silly. > > > > I was kind of irked about that too. I'm going to file a ticket to make > sure this gets handled. Really I guess it'd be nice to have a > > logDiff => false > > option where it'd at least let you know something happened but not what if > it was explicitly listed. There's other uses for this besides just root > passwords. > The way I worked out to do it is a bit silly but you put the crypted password in a file somewhere in /etc or /root and you just have that file in config_files or private (or as a template) and then a cron job goes through and takes that value and sets it in /etc/shadow using lpasswd or chpasswd not pretty but it will keep the crypted pw from showing up in a log -sv From smooge at gmail.com Mon Sep 8 18:44:41 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 8 Sep 2008 12:44:41 -0600 Subject: More puppet training! In-Reply-To: <1220892744.987.43.camel@rosebud> References: <80d7e4090809080819ma2888c9u59910db7ec862516@mail.gmail.com> <1220888037.987.19.camel@rosebud> <1220892744.987.43.camel@rosebud> Message-ID: <80d7e4090809081144p7dd8ff3bv7726f6cd3b4ec94d@mail.gmail.com> On Mon, Sep 8, 2008 at 10:52 AM, Seth Vidal wrote: > On Mon, 2008-09-08 at 11:49 -0500, Mike McGrath wrote: >> On Mon, 8 Sep 2008, Seth Vidal wrote: >> >> > On Mon, 2008-09-08 at 09:19 -0600, Stephen John Smoogen wrote: >> > > On Mon, Sep 8, 2008 at 9:16 AM, Mike McGrath wrote: >> > > > So I'm going to hold a couple more training seminars for Puppet in >> > > > Fedora's Infrastructure. I was hoping you guys could also throw some >> > > > questions together so i make sure I don't miss anything. >> > > > >> > > >> > > Are the old seminars up somewhere? My whole look at puppet is from >> > > 30k. I know more about cfengine .. which has made me look at some of >> > > the 'limitations' of puppet as 'huh?' versus purposeful design >> > > decisions. Heck I don't even know how to make a root password across a >> > > cluster :). >> > >> > >> > don't feel bad, no one else does, either. >> > >> > Not without leaving the crypted password all over the logs. >> > >> > Well, to be fair, there's a way to do it, it's just hurky and feels >> > silly. >> > >> >> I was kind of irked about that too. I'm going to file a ticket to make >> sure this gets handled. Really I guess it'd be nice to have a >> >> logDiff => false >> >> option where it'd at least let you know something happened but not what if >> it was explicitly listed. There's other uses for this besides just root >> passwords. >> > > The way I worked out to do it is a bit silly but you put the crypted > password in a file somewhere in /etc or /root > > and you just have that file in config_files or private (or as a > template) and then a cron job goes through and takes that value and sets > it in /etc/shadow using lpasswd or chpasswd > > not pretty but it will keep the crypted pw from showing up in a log > -sv > Ugh. Is there a way to integrate this with augeus or something? Having to assume you can protect a second file for root or having secure file diff's logged sounds like a long term nightmare. However thats outside of probably the class :). -- Stephen J Smoogen. -- BSD/GNU/Linux 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 Mon Sep 8 19:07:01 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 8 Sep 2008 14:07:01 -0500 (CDT) Subject: Environments Doc Message-ID: So I'm slowly getting more architecture docs put together. This is now in our repo: http://mmcgrath.fedorapeople.org/Environments.pdf When we're in a freeze or a pre-freeze here's the rules. If the host is listen in the $FREEZE_TYPE list. Then its frozen. You'll notice that, for example, app[1-5] are listed in both the normal full freeze as well as the pre-release freeze. That's because we have applications that exist in each environment. Until we move those services somewhere else. Those servers are frozen during prefreezes. The actual environment names are: * Buildsystem * Distribution * Support * Virtualization * Staging * Testing * Value Added -Mike From wakko666 at gmail.com Mon Sep 8 19:09:29 2008 From: wakko666 at gmail.com (Brett Lentz) Date: Mon, 8 Sep 2008 12:09:29 -0700 Subject: More puppet training! In-Reply-To: <200809081039.24281.dennis@ausil.us> References: <200809081039.24281.dennis@ausil.us> Message-ID: <001801c911e6$6e45fac0$4ad1f040$@com> > -----Original Message----- > From: fedora-infrastructure-list-bounces at redhat.com [mailto:fedora- > infrastructure-list-bounces at redhat.com] On Behalf Of Dennis Gilmore > Sent: Monday, September 08, 2008 8:39 AM > To: Fedora Infrastructure > Subject: Re: More puppet training! > > On Monday 08 September 2008 10:16:28 am Mike McGrath wrote: > > So I'm going to hold a couple more training seminars for Puppet in > > Fedora's Infrastructure. I was hoping you guys could also throw some > > questions together so i make sure I don't miss anything. > > Id like to know where should i put a script in the puppet tree. where > should I put config files etc. A script to be pushed to the clients, then executed, should be in the directories declared by the fileserver directives (/var/lib/puppet/config, I believe). A script run on the server-side (e.g. an external node classifier, etc.) should live in /usr/local/bin on the puppetmaster. > > what if its something needed on 2 systems that have different purposes > should i create a new class? or just add it to each of the two > groups?. but a shared group. that kind of thing. > Yep. My rule of thumb tends to be to create purpose-specific classes, so that any node or server group that needs singular bits can include or inherit them (and override any conflicting values). > > Dennis ---Brett. From bretm at redhat.com Mon Sep 8 22:20:40 2008 From: bretm at redhat.com (Bret McMillan) Date: Mon, 08 Sep 2008 18:20:40 -0400 Subject: Environments Doc In-Reply-To: References: Message-ID: <48C5A538.1050406@redhat.com> Mike McGrath wrote: > So I'm slowly getting more architecture docs put together. This is now in > our repo: > > http://mmcgrath.fedorapeople.org/Environments.pdf > Awesome, needed an overview like this. > The actual environment names are: > > * Buildsystem > * Distribution > * Support > * Virtualization > * Staging > * Testing > * Value Added Quick question, what does collab1 do (listed under Value Added)? We're about to spin up a collab tools project, would be helpful to know what things are going on out there to draw upon / pool resources. --Bret From mmcgrath at redhat.com Mon Sep 8 22:34:46 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 8 Sep 2008 17:34:46 -0500 (CDT) Subject: Environments Doc In-Reply-To: <48C5A538.1050406@redhat.com> References: <48C5A538.1050406@redhat.com> Message-ID: On Mon, 8 Sep 2008, Bret McMillan wrote: > Mike McGrath wrote: > > So I'm slowly getting more architecture docs put together. This is now in > > our repo: > > > > http://mmcgrath.fedorapeople.org/Environments.pdf > > > > Awesome, needed an overview like this. > > > The actual environment names are: > > > > * Buildsystem > > * Distribution > > * Support > > * Virtualization > > * Staging > > * Testing > > * Value Added > > Quick question, what does collab1 do (listed under Value Added)? We're about > to spin up a collab tools project, would be helpful to know what things are > going on out there to draw upon / pool resources. > Collab1 is a server focused around our collaboration tools. Right now it has some mailing lists and a sobby server. It will probably also have our pastebin in the future once it gets ready. -Mike From bretm at redhat.com Tue Sep 9 13:56:26 2008 From: bretm at redhat.com (Bret McMillan) Date: Tue, 09 Sep 2008 09:56:26 -0400 Subject: Environments Doc In-Reply-To: References: <48C5A538.1050406@redhat.com> Message-ID: <48C6808A.5050104@redhat.com> Mike McGrath wrote: > > Collab1 is a server focused around our collaboration tools. Right now it > has some mailing lists and a sobby server. It will probably also have our > pastebin in the future once it gets ready. Cool, definitely sounds like I need to ping you more online about this. Next thing I'm probably going to be looking at is shindig, might be useful. Gotta run to some meetings first though :/ --Bret From thinklinux.ssh at gmail.com Tue Sep 9 15:03:18 2008 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Tue, 9 Sep 2008 20:33:18 +0530 Subject: Removal of old projects from fedorahosted. Message-ID: Hi, This is w.r.t to ticket #714[1]. As explained by mmcgrath, Fedora has a policy to remove _any_ hosted projects that are not altered or updated for last six months. Here is the list of projects, which falls into this category and they will soon be removed. -------------------------------------------------------------------------------------------------------------------- These directories have not been altered for 6 months /srv/svn/hardlink group: svnhardlink /srv/svn/package-jitsu group: svnpackage-jitsu /srv/svn/repoview group: svnrepoview /srv/svn/ols group: svnols /srv/svn/setarch group: svnsetarch /srv/svn/authd group: svnauthd /srv/svn/system-config-keyboard.old group: svnsystem-config-keyboard /srv/hg/camelus group: hgcamelus /srv/hg/passwd group: hgpasswd /srv/hg/bodhi.old group: gitbodhi /srv/hg/guest-account group: hgguest-account /srv/hg/timeconfig group: hgtimeconfig /srv/hg/LHCP group: hgLHCP /srv/hg/virt-manager group: hgvirt-manager /srv/hg/pam-redhat group: hgpam-redhat /srv/hg/tmpwatch group: hgtmpwatch /srv/git/splatbind.git group: gitsplatbind /srv/git/system-config-securitylevel.git group: gitsystem-config-securitylevel If you have any update with respect to this, and don't want any/some project(s) be removed, please let us know. Thanks. [1]https://fedorahosted.org/fedora-infrastructure/ticket/714 -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= From mmcgrath at redhat.com Tue Sep 9 15:40:30 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 9 Sep 2008 10:40:30 -0500 (CDT) Subject: Removal of old projects from fedorahosted. In-Reply-To: References: Message-ID: On Tue, 9 Sep 2008, susmit shannigrahi wrote: > Hi, > > This is w.r.t to ticket #714[1]. > > As explained by mmcgrath, Fedora has a policy to remove _any_ hosted > projects that are > not altered or updated for last six months. > > Here is the list of projects, which falls into this category and they > will soon be removed. > > -------------------------------------------------------------------------------------------------------------------- > These directories have not been altered for 6 months > /srv/svn/hardlink group: svnhardlink > /srv/svn/package-jitsu group: svnpackage-jitsu > /srv/svn/repoview group: svnrepoview > /srv/svn/ols group: svnols > /srv/svn/setarch group: svnsetarch > /srv/svn/authd group: svnauthd > /srv/svn/system-config-keyboard.old group: svnsystem-config-keyboard > > > /srv/hg/camelus group: hgcamelus > /srv/hg/passwd group: hgpasswd > /srv/hg/bodhi.old group: gitbodhi > /srv/hg/guest-account group: hgguest-account > /srv/hg/timeconfig group: hgtimeconfig > /srv/hg/LHCP group: hgLHCP > /srv/hg/virt-manager group: hgvirt-manager > /srv/hg/pam-redhat group: hgpam-redhat > /srv/hg/tmpwatch group: hgtmpwatch > > > /srv/git/splatbind.git group: gitsplatbind > /srv/git/system-config-securitylevel.git group: gitsystem-config-securitylevel > > > If you have any update with respect to this, and don't want any/some > project(s) be removed, please > let us know. > > > [1]https://fedorahosted.org/fedora-infrastructure/ticket/714 > So I guess the best thing from here is to send an email to each group notifying them of what has happened and why we'd like to remove their project. tell them how to get the code off if they still want it, etc, etc. Lots of people on this list use hosted projects, what do you think? -Mike From notting at redhat.com Tue Sep 9 16:00:20 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 9 Sep 2008 12:00:20 -0400 Subject: Removal of old projects from fedorahosted. In-Reply-To: References: Message-ID: <20080909160020.GA13140@nostromo.devel.redhat.com> Mike McGrath (mmcgrath at redhat.com) said: > > [1]https://fedorahosted.org/fedora-infrastructure/ticket/714 > > So I guess the best thing from here is to send an email to each group > notifying them of what has happened and why we'd like to remove their > project. tell them how to get the code off if they still want it, etc, > etc. > > Lots of people on this list use hosted projects, what do you think? I'm leery of having a hard and fast 6-month-rule; especially for projects which aren't translated, it's possible to have a decent period without code changes. Maybe review-at-six-months? Bill From katzj at redhat.com Tue Sep 9 16:02:04 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 09 Sep 2008 12:02:04 -0400 Subject: Removal of old projects from fedorahosted. In-Reply-To: References: Message-ID: <1220976124.5554.184.camel@aglarond.local> On Tue, 2008-09-09 at 20:33 +0530, susmit shannigrahi wrote: > As explained by mmcgrath, Fedora has a policy to remove _any_ hosted > projects that are > not altered or updated for last six months. Hmmm -- this seems a little problematic. It's definitely possible to have a "mature" project which doesn't see a lot of changes. Not that all of these necessarily fall into that case, but some of them definitely do Jeremy From mmcgrath at redhat.com Tue Sep 9 16:13:40 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 9 Sep 2008 11:13:40 -0500 (CDT) Subject: Removal of old projects from fedorahosted. In-Reply-To: <1220976124.5554.184.camel@aglarond.local> References: <1220976124.5554.184.camel@aglarond.local> Message-ID: On Tue, 9 Sep 2008, Jeremy Katz wrote: > On Tue, 2008-09-09 at 20:33 +0530, susmit shannigrahi wrote: > > As explained by mmcgrath, Fedora has a policy to remove _any_ hosted > > projects that are > > not altered or updated for last six months. > > Hmmm -- this seems a little problematic. It's definitely possible to > have a "mature" project which doesn't see a lot of changes. Not that > all of these necessarily fall into that case, but some of them > definitely do > It's not actually a hard and fast rule. The wording is: https://fedorahosted.org/web/terms "The Fedora Project reserves the right to remove any project from our system that does not meet the following criteria: 1. Code contained in the project does not meet our license requirements 2. No significant changes have been committed or applied for at least six (6) months " -Mike From debarshi.ray at gmail.com Tue Sep 9 16:50:25 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Tue, 9 Sep 2008 22:20:25 +0530 Subject: Removal of old projects from fedorahosted. In-Reply-To: References: Message-ID: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> > As explained by mmcgrath, Fedora has a policy to remove _any_ hosted > projects that are > not altered or updated for last six months. I am pleasantly suprised to see that Opyum is not in that list. :-) The thing with Opyum is that its functionality has been very nicely ported to PackageKit by one of my friends during this year's Google Summer of Code. Fedora 8 still caries Opyum, but its useless for Fedora 9 and onwards. I just want to wait till Fedora 8 is EOLed after which I would not want it to hog resources on fedorahosted.org any more. Happy hacking, Debarshi From Matt_Domsch at dell.com Tue Sep 9 19:35:56 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 9 Sep 2008 14:35:56 -0500 Subject: Removal of old projects from fedorahosted. In-Reply-To: <1220976124.5554.184.camel@aglarond.local> References: <1220976124.5554.184.camel@aglarond.local> Message-ID: <20080909193556.GB16300@auslistsprd01.us.dell.com> On Tue, Sep 09, 2008 at 12:02:04PM -0400, Jeremy Katz wrote: > On Tue, 2008-09-09 at 20:33 +0530, susmit shannigrahi wrote: > > As explained by mmcgrath, Fedora has a policy to remove _any_ hosted > > projects that are > > not altered or updated for last six months. > > Hmmm -- this seems a little problematic. It's definitely possible to > have a "mature" project which doesn't see a lot of changes. Not that > all of these necessarily fall into that case, but some of them > definitely do yeah, like setarch. Isn't likely to change much... -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From ianweller at gmail.com Tue Sep 9 20:23:34 2008 From: ianweller at gmail.com (Ian Weller) Date: Tue, 9 Sep 2008 15:23:34 -0500 Subject: Removal of old projects from fedorahosted. In-Reply-To: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> Message-ID: <20080909202323.GA14625@gmail.com> On Tue, Sep 09, 2008 at 10:20:25PM +0530, Debarshi Ray wrote: > The thing with Opyum is that its functionality has been very nicely > ported to PackageKit by one of my friends during this year's Google > Summer of Code. Fedora 8 still caries Opyum, but its useless for > Fedora 9 and onwards. I just want to wait till Fedora 8 is EOLed after > which I would not want it to hog resources on fedorahosted.org any > more. > SourceForge.net (gah! I know) has a policy that not only prevents projects from being automatically removed simply for the sake of being idle, but that prevents most projects from being removed at all, even at the developer's request; this policy is for the contingency of source code, making it still available to people who still want it, even though the project may be dead. If there's no way to retrieve the source code for a project that has been removed from Fedora Hosted, is the project not gone forever -- and more importantly, do we want that? -- Ian Weller http://ianweller.org GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 "Technology is a word that describes something that doesn't work yet." ~ Douglas Adams -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mmcgrath at redhat.com Tue Sep 9 20:35:41 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 9 Sep 2008 15:35:41 -0500 (CDT) Subject: Removal of old projects from fedorahosted. In-Reply-To: <20080909202323.GA14625@gmail.com> References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> Message-ID: On Tue, 9 Sep 2008, Ian Weller wrote: > On Tue, Sep 09, 2008 at 10:20:25PM +0530, Debarshi Ray wrote: > > The thing with Opyum is that its functionality has been very nicely > > ported to PackageKit by one of my friends during this year's Google > > Summer of Code. Fedora 8 still caries Opyum, but its useless for > > Fedora 9 and onwards. I just want to wait till Fedora 8 is EOLed after > > which I would not want it to hog resources on fedorahosted.org any > > more. > > > SourceForge.net (gah! I know) has a policy that not only prevents > projects from being automatically removed simply for the sake of being > idle, but that prevents most projects from being removed at all, even at > the developer's request; this policy is for the contingency of source > code, making it still available to people who still want it, even though > the project may be dead. > This is one of the things we're hoping to prevent with fedorahosted. The hope is that the fedorahosted brand will be known for good, active projects. Not vaporware. > If there's no way to retrieve the source code for a project that has > been removed from Fedora Hosted, is the project not gone forever -- and > more importantly, do we want that? > Depends. We'll certainly be contacting the project members and let them know whats up giving them the option to grab the raw source tree (already available via rsync) and the trac install. In general from the infrastructure side I'd say we want to keep the barrier to enter low but the quality high. Certainly there's projects that don't need to be updated every 6 months but we can identify those and deal accordingly. -Mike From ianweller at gmail.com Tue Sep 9 20:55:14 2008 From: ianweller at gmail.com (Ian Weller) Date: Tue, 9 Sep 2008 15:55:14 -0500 Subject: Removal of old projects from fedorahosted. In-Reply-To: References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> Message-ID: <20080909205514.GC14625@gmail.com> On Tue, Sep 09, 2008 at 03:35:41PM -0500, Mike McGrath wrote: > This is one of the things we're hoping to prevent with fedorahosted. The > hope is that the fedorahosted brand will be known for good, active > projects. Not vaporware. > > We'll certainly be contacting the project members and let them > know whats up giving them the option to grab the raw source tree (already > available via rsync) and the trac install. > > In general from the infrastructure side I'd say we want to keep the > barrier to enter low but the quality high. Certainly there's projects > that don't need to be updated every 6 months but we can identify those and > deal accordingly. > None of this seems to agree with the open source philosophy. From what I understand, one should always be able to access code, whether dead, buggy, or release candidate, or whatever. I understand the idea of keeping a code center clean and newish, but I think it would turn away more projects than dead codebases would. -- Ian Weller http://ianweller.org GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 "Technology is a word that describes something that doesn't work yet." ~ Douglas Adams -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mmcgrath at redhat.com Tue Sep 9 21:05:39 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 9 Sep 2008 16:05:39 -0500 (CDT) Subject: Removal of old projects from fedorahosted. In-Reply-To: <20080909205514.GC14625@gmail.com> References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> <20080909205514.GC14625@gmail.com> Message-ID: On Tue, 9 Sep 2008, Ian Weller wrote: > On Tue, Sep 09, 2008 at 03:35:41PM -0500, Mike McGrath wrote: > > This is one of the things we're hoping to prevent with fedorahosted. The > > hope is that the fedorahosted brand will be known for good, active > > projects. Not vaporware. > > > > We'll certainly be contacting the project members and let them > > know whats up giving them the option to grab the raw source tree (already > > available via rsync) and the trac install. > > > > In general from the infrastructure side I'd say we want to keep the > > barrier to enter low but the quality high. Certainly there's projects > > that don't need to be updated every 6 months but we can identify those and > > deal accordingly. > > > None of this seems to agree with the open source philosophy. From what I > understand, one should always be able to access code, whether dead, > buggy, or release candidate, or whatever. I understand the idea of > keeping a code center clean and newish, but I think it would turn away > more projects than dead codebases would. > Let me know when you get archives.fedorahosted.org up, I'll make sure to send all this unused code your way ;-) We're not trying to be the end all hosting for everyone. If that turns people away, there are plenty of alternatives. We're looking for people who have active and interesting projects. -Mike From kzak at redhat.com Tue Sep 9 21:20:26 2008 From: kzak at redhat.com (Karel Zak) Date: Tue, 9 Sep 2008 23:20:26 +0200 Subject: Removal of old projects from fedorahosted. In-Reply-To: <20080909193556.GB16300@auslistsprd01.us.dell.com> References: <1220976124.5554.184.camel@aglarond.local> <20080909193556.GB16300@auslistsprd01.us.dell.com> Message-ID: <20080909212026.GC2943@nb.net.home> On Tue, Sep 09, 2008 at 02:35:56PM -0500, Matt Domsch wrote: > On Tue, Sep 09, 2008 at 12:02:04PM -0400, Jeremy Katz wrote: > > On Tue, 2008-09-09 at 20:33 +0530, susmit shannigrahi wrote: > > > As explained by mmcgrath, Fedora has a policy to remove _any_ hosted > > > projects that are > > > not altered or updated for last six months. > > > > Hmmm -- this seems a little problematic. It's definitely possible to > > have a "mature" project which doesn't see a lot of changes. Not that > > all of these necessarily fall into that case, but some of them > > definitely do good point. > yeah, like setarch. Isn't likely to change much... Bad example. setarch(1) was merged into util-linux-ng one year ago. Karel -- Karel Zak From robin.norwood at gmail.com Wed Sep 10 01:11:02 2008 From: robin.norwood at gmail.com (Robin Norwood) Date: Tue, 9 Sep 2008 21:11:02 -0400 Subject: Removal of old projects from fedorahosted. In-Reply-To: References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> Message-ID: On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath wrote: > In general from the infrastructure side I'd say we want to keep the > barrier to enter low but the quality high. Certainly there's projects > that don't need to be updated every 6 months but we can identify those and > deal accordingly. How about 'delisting' instead of deleting? I'm operating under the assumption that the infrastructure burden of hosting the project isn't the problem you're trying to solve, and that keeping the projects at fedora hosted relevant is. A delisted project simply wouldn't appear on the main fedora hosted list of projects, but would still be available via direct link. That way, nothing is lost, but the clutter vanishes. You could even have yet another category for projects that are known to be abandoned. -RN -- Robin Norwood "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From wakko666 at gmail.com Wed Sep 10 01:23:55 2008 From: wakko666 at gmail.com (Brett Lentz) Date: Tue, 9 Sep 2008 18:23:55 -0700 Subject: Removal of old projects from fedorahosted. In-Reply-To: References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> Message-ID: <005201c912e3$e5a5bc10$b0f13430$@com> > -----Original Message----- > From: fedora-infrastructure-list-bounces at redhat.com [mailto:fedora- > infrastructure-list-bounces at redhat.com] On Behalf Of Robin Norwood > Sent: Tuesday, September 09, 2008 6:11 PM > To: Fedora Infrastructure > Subject: Re: Removal of old projects from fedorahosted. > > On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath > wrote: > > In general from the infrastructure side I'd say we want to keep the > > barrier to enter low but the quality high. Certainly there's > projects > > that don't need to be updated every 6 months but we can identify > those and > > deal accordingly. > > How about 'delisting' instead of deleting? I'm operating under the > assumption that the infrastructure burden of hosting the project isn't > the problem you're trying to solve, and that keeping the projects at > fedora hosted relevant is. > > A delisted project simply wouldn't appear on the main fedora hosted > list of projects, but would still be available via direct link. That > way, nothing is lost, but the clutter vanishes. > > You could even have yet another category for projects that are known > to be abandoned. > What about using a Sourceforge-style project classification scheme? Allow projects to self-identify their status (Alpha, Beta, Stable, Abandoned, etc.). That would allow us to craft policies around project updates that are more in line with their current development status. It would also allow us to filter the main project page according to development status. For example: maybe alpha projects need to be updated at least every 3-6 months, but stable projects would only need a minimum of a yearly or bi-yearly update to be considered "actively maintained." ---Brett. From mmcgrath at redhat.com Wed Sep 10 01:34:47 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 9 Sep 2008 20:34:47 -0500 (CDT) Subject: Removal of old projects from fedorahosted. In-Reply-To: References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> Message-ID: On Tue, 9 Sep 2008, Robin Norwood wrote: > On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath wrote: > > In general from the infrastructure side I'd say we want to keep the > > barrier to enter low but the quality high. Certainly there's projects > > that don't need to be updated every 6 months but we can identify those and > > deal accordingly. > > How about 'delisting' instead of deleting? I'm operating under the > assumption that the infrastructure burden of hosting the project isn't > the problem you're trying to solve, and that keeping the projects at > fedora hosted relevant is. > > A delisted project simply wouldn't appear on the main fedora hosted > list of projects, but would still be available via direct link. That > way, nothing is lost, but the clutter vanishes. > > You could even have yet another category for projects that are known > to be abandoned. > Nope, the terms of use are already pretty clear. And no one has provided a compelling reason to keep these projects around, just lots of suggestions on how to keep them around. Deleted is what we want, not delisted or saved forever or anything like that. We're not going to commit any resources to a project that choosed not to use this free service. -Mike From mmcgrath at redhat.com Wed Sep 10 01:37:04 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 9 Sep 2008 20:37:04 -0500 (CDT) Subject: Removal of old projects from fedorahosted. In-Reply-To: <005201c912e3$e5a5bc10$b0f13430$@com> References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> <005201c912e3$e5a5bc10$b0f13430$@com> Message-ID: On Tue, 9 Sep 2008, Brett Lentz wrote: > > -----Original Message----- > > From: fedora-infrastructure-list-bounces at redhat.com [mailto:fedora- > > infrastructure-list-bounces at redhat.com] On Behalf Of Robin Norwood > > Sent: Tuesday, September 09, 2008 6:11 PM > > To: Fedora Infrastructure > > Subject: Re: Removal of old projects from fedorahosted. > > > > On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath > > wrote: > > > In general from the infrastructure side I'd say we want to keep the > > > barrier to enter low but the quality high. Certainly there's > > projects > > > that don't need to be updated every 6 months but we can identify > > those and > > > deal accordingly. > > > > How about 'delisting' instead of deleting? I'm operating under the > > assumption that the infrastructure burden of hosting the project isn't > > the problem you're trying to solve, and that keeping the projects at > > fedora hosted relevant is. > > > > A delisted project simply wouldn't appear on the main fedora hosted > > list of projects, but would still be available via direct link. That > > way, nothing is lost, but the clutter vanishes. > > > > You could even have yet another category for projects that are known > > to be abandoned. > > > > What about using a Sourceforge-style project classification scheme? Allow > projects to self-identify their status (Alpha, Beta, Stable, Abandoned, > etc.). That would allow us to craft policies around project updates that are > more in line with their current development status. It would also allow us > to filter the main project page according to development status. > > For example: maybe alpha projects need to be updated at least every 3-6 > months, but stable projects would only need a minimum of a yearly or > bi-yearly update to be considered "actively maintained." > Why? -Mike From mmcgrath at redhat.com Wed Sep 10 01:40:09 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 9 Sep 2008 20:40:09 -0500 (CDT) Subject: Removal of old projects from fedorahosted. In-Reply-To: <005201c912e3$e5a5bc10$b0f13430$@com> References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> <005201c912e3$e5a5bc10$b0f13430$@com> Message-ID: On Tue, 9 Sep 2008, Brett Lentz wrote: > > -----Original Message----- > > From: fedora-infrastructure-list-bounces at redhat.com [mailto:fedora- > > infrastructure-list-bounces at redhat.com] On Behalf Of Robin Norwood > > Sent: Tuesday, September 09, 2008 6:11 PM > > To: Fedora Infrastructure > > Subject: Re: Removal of old projects from fedorahosted. > > > > On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath > > wrote: > > > In general from the infrastructure side I'd say we want to keep the > > > barrier to enter low but the quality high. Certainly there's > > projects > > > that don't need to be updated every 6 months but we can identify > > those and > > > deal accordingly. > > > > How about 'delisting' instead of deleting? I'm operating under the > > assumption that the infrastructure burden of hosting the project isn't > > the problem you're trying to solve, and that keeping the projects at > > fedora hosted relevant is. > > > > A delisted project simply wouldn't appear on the main fedora hosted > > list of projects, but would still be available via direct link. That > > way, nothing is lost, but the clutter vanishes. > > > > You could even have yet another category for projects that are known > > to be abandoned. > > > > What about using a Sourceforge-style project classification scheme? Allow > projects to self-identify their status (Alpha, Beta, Stable, Abandoned, > etc.). That would allow us to craft policies around project updates that are > more in line with their current development status. It would also allow us > to filter the main project page according to development status. > > For example: maybe alpha projects need to be updated at least every 3-6 > months, but stable projects would only need a minimum of a yearly or > bi-yearly update to be considered "actively maintained." > Actually re-reading this I think people are confused about my intent. We're going to contact the individuals to let them know their options. If they really want to keep the repo around and they have a good reason, it'll probably stay around. not all repos are active every 6 months but they are still important projects. However there are probably lots of projects that don't fit into this category, and they're more then welcome to host their projects elsewhere. As I explained earlier its not a hard and fast rule, we just reserve the right to remove it. -Mike From robin.norwood at gmail.com Wed Sep 10 01:43:25 2008 From: robin.norwood at gmail.com (Robin Norwood) Date: Tue, 9 Sep 2008 21:43:25 -0400 Subject: Removal of old projects from fedorahosted. In-Reply-To: References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> Message-ID: On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath wrote: > Nope, the terms of use are already pretty clear. And no one has provided > a compelling reason to keep these projects around, just lots of > suggestions on how to keep them around. Deleted is what we want, not > delisted or saved forever or anything like that. We're not going to > commit any resources to a project that choosed not to use this free > service. Well, because sooner or later, you'll delete a project that someone didn't want deleted, and they'll be ticked off. Maybe they'll open a ticket and convince the infra. team to restore the data from a backup, or maybe they'll just be ticked off and rant about how much Fedora sucks for deleting this thing they didn't want deleted. Again, I'm assuming the per-project maintenence cost is near zero (ie, a little bit of disk space). If not, then maybe I could see a case for automatically deleting old projects. -RN -- Robin Norwood "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From wakko666 at gmail.com Wed Sep 10 01:57:38 2008 From: wakko666 at gmail.com (Brett Lentz) Date: Tue, 9 Sep 2008 18:57:38 -0700 Subject: Removal of old projects from fedorahosted. In-Reply-To: References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> <005201c912e3$e5a5bc10$b0f13430$@com> Message-ID: <005301c912e8$9b289310$d179b930$@com> > -----Original Message----- > From: fedora-infrastructure-list-bounces at redhat.com [mailto:fedora- > infrastructure-list-bounces at redhat.com] On Behalf Of Mike McGrath > Sent: Tuesday, September 09, 2008 6:37 PM > To: Fedora Infrastructure > Subject: RE: Removal of old projects from fedorahosted. > > On Tue, 9 Sep 2008, Brett Lentz wrote: > > > > -----Original Message----- > > > From: fedora-infrastructure-list-bounces at redhat.com [mailto:fedora- > > > infrastructure-list-bounces at redhat.com] On Behalf Of Robin Norwood > > > Sent: Tuesday, September 09, 2008 6:11 PM > > > To: Fedora Infrastructure > > > Subject: Re: Removal of old projects from fedorahosted. > > > > > > On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath > > > wrote: > > > > In general from the infrastructure side I'd say we want to keep > the > > > > barrier to enter low but the quality high. Certainly there's > > > projects > > > > that don't need to be updated every 6 months but we can identify > > > those and > > > > deal accordingly. > > > > > > How about 'delisting' instead of deleting? I'm operating under the > > > assumption that the infrastructure burden of hosting the project > isn't > > > the problem you're trying to solve, and that keeping the projects > at > > > fedora hosted relevant is. > > > > > > A delisted project simply wouldn't appear on the main fedora hosted > > > list of projects, but would still be available via direct link. > That > > > way, nothing is lost, but the clutter vanishes. > > > > > > You could even have yet another category for projects that are > known > > > to be abandoned. > > > > > > > What about using a Sourceforge-style project classification scheme? > Allow > > projects to self-identify their status (Alpha, Beta, Stable, > Abandoned, > > etc.). That would allow us to craft policies around project updates > that are > > more in line with their current development status. It would also > allow us > > to filter the main project page according to development status. > > > > For example: maybe alpha projects need to be updated at least every > 3-6 > > months, but stable projects would only need a minimum of a yearly or > > bi-yearly update to be considered "actively maintained." > > > > Why? > This would help prevent having more stable projects up on the chopping block every six months simply because they haven't done anything recently. Obviously, each time this comes up, fedora-admin will gradually collect this information anyway just by virtue of having the discussion of whom to delete. However, it doesn't make sense to me to discard this information each time the current discussion ends. It also doesn't makes sense to continually rehash this same discussion over the same projects every six months if everyone suddenly forgets that the foo project is a stable app that doesn't see many updates because it "just works." Or, more plausibly, whenever we have a new member that asks "what about project foo? Why doesn't it get deleted?" It seems like it would be better to just have a more robust process and encourage project state information to be better documented for future discussions and future admins. It's also entirely possible that I'm over-thinking the issue. :-) ---Brett. From mmcgrath at redhat.com Wed Sep 10 02:02:26 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 9 Sep 2008 21:02:26 -0500 (CDT) Subject: Removal of old projects from fedorahosted. In-Reply-To: References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> Message-ID: On Tue, 9 Sep 2008, Robin Norwood wrote: > On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath wrote: > > Nope, the terms of use are already pretty clear. And no one has provided > > a compelling reason to keep these projects around, just lots of > > suggestions on how to keep them around. Deleted is what we want, not > > delisted or saved forever or anything like that. We're not going to > > commit any resources to a project that choosed not to use this free > > service. > > Well, because sooner or later, you'll delete a project that someone > didn't want deleted, and they'll be ticked off. Maybe they'll open a > ticket and convince the infra. team to restore the data from a backup, > or maybe they'll just be ticked off and rant about how much Fedora > sucks for deleting this thing they didn't want deleted. > I'm fine with that. Its well documented. and its not like we're going to rm -rf the thing. We'll keep it around for a while but no promises. > Again, I'm assuming the per-project maintenence cost is near zero (ie, > a little bit of disk space). If not, then maybe I could see a case > for automatically deleting old projects. > Ah, thats an incorrect assumption. -Mike From katzj at redhat.com Wed Sep 10 02:11:48 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 09 Sep 2008 22:11:48 -0400 Subject: Removal of old projects from fedorahosted. In-Reply-To: References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> Message-ID: <1221012708.5554.195.camel@aglarond.local> On Tue, 2008-09-09 at 20:34 -0500, Mike McGrath wrote: > On Tue, 9 Sep 2008, Robin Norwood wrote: > > On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath wrote: > > > In general from the infrastructure side I'd say we want to keep the > > > barrier to enter low but the quality high. Certainly there's projects > > > that don't need to be updated every 6 months but we can identify those and > > > deal accordingly. > > > > How about 'delisting' instead of deleting? I'm operating under the > > assumption that the infrastructure burden of hosting the project isn't > > the problem you're trying to solve, and that keeping the projects at > > fedora hosted relevant is. > > > > A delisted project simply wouldn't appear on the main fedora hosted > > list of projects, but would still be available via direct link. That > > way, nothing is lost, but the clutter vanishes. > > > > You could even have yet another category for projects that are known > > to be abandoned. > > Nope, the terms of use are already pretty clear. And no one has provided > a compelling reason to keep these projects around, just lots of > suggestions on how to keep them around. Deleted is what we want, not > delisted or saved forever or anything like that. We're not going to > commit any resources to a project that choosed not to use this free > service. Compelling reason: application is in Fedora today, maintained in fedorahosted and ends up in RHEL. A year after RHEL release, the app is obsoleted by something else in Fedora. Thus, the app in hosted basically gets very little in the way of updates. But keeping the source repository available is very important for any updates later needed for RHEL. Jeremy From mmcgrath at redhat.com Wed Sep 10 02:20:11 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 9 Sep 2008 21:20:11 -0500 (CDT) Subject: Removal of old projects from fedorahosted. In-Reply-To: <1221012708.5554.195.camel@aglarond.local> References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> <1221012708.5554.195.camel@aglarond.local> Message-ID: On Tue, 9 Sep 2008, Jeremy Katz wrote: > On Tue, 2008-09-09 at 20:34 -0500, Mike McGrath wrote: > > On Tue, 9 Sep 2008, Robin Norwood wrote: > > > On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath wrote: > > > > In general from the infrastructure side I'd say we want to keep the > > > > barrier to enter low but the quality high. Certainly there's projects > > > > that don't need to be updated every 6 months but we can identify those and > > > > deal accordingly. > > > > > > How about 'delisting' instead of deleting? I'm operating under the > > > assumption that the infrastructure burden of hosting the project isn't > > > the problem you're trying to solve, and that keeping the projects at > > > fedora hosted relevant is. > > > > > > A delisted project simply wouldn't appear on the main fedora hosted > > > list of projects, but would still be available via direct link. That > > > way, nothing is lost, but the clutter vanishes. > > > > > > You could even have yet another category for projects that are known > > > to be abandoned. > > > > Nope, the terms of use are already pretty clear. And no one has provided > > a compelling reason to keep these projects around, just lots of > > suggestions on how to keep them around. Deleted is what we want, not > > delisted or saved forever or anything like that. We're not going to > > commit any resources to a project that choosed not to use this free > > service. > > Compelling reason: application is in Fedora today, maintained in > fedorahosted and ends up in RHEL. A year after RHEL release, the app is > obsoleted by something else in Fedora. Thus, the app in hosted > basically gets very little in the way of updates. But keeping the > source repository available is very important for any updates later > needed for RHEL. > I don't see why that project would get removed. I really think I'm getting misunderstood here. 1) we send an email to the group members explaining their project is stale and asking to remove it. 2) they respond saying they'd like to not have it removed. (it stays) 3) they respond saying its no longer used and it can be removed (we remove it or they move it elsewhere) 4) no one responds (it gets removed) -Mike From dev at nigelj.com Wed Sep 10 02:21:24 2008 From: dev at nigelj.com (Nigel Jones) Date: Wed, 10 Sep 2008 14:21:24 +1200 Subject: Removal of old projects from fedorahosted. In-Reply-To: <1221012708.5554.195.camel@aglarond.local> References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> <1221012708.5554.195.camel@aglarond.local> Message-ID: <1221013284.3398.8.camel@fantail.jnet.net.nz> On Tue, 2008-09-09 at 22:11 -0400, Jeremy Katz wrote: > On Tue, 2008-09-09 at 20:34 -0500, Mike McGrath wrote: > > On Tue, 9 Sep 2008, Robin Norwood wrote: > > > On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath wrote: > > > > In general from the infrastructure side I'd say we want to keep the > > > > barrier to enter low but the quality high. Certainly there's projects > > > > that don't need to be updated every 6 months but we can identify those and > > > > deal accordingly. > > > > > > How about 'delisting' instead of deleting? I'm operating under the > > > assumption that the infrastructure burden of hosting the project isn't > > > the problem you're trying to solve, and that keeping the projects at > > > fedora hosted relevant is. > > > > > > A delisted project simply wouldn't appear on the main fedora hosted > > > list of projects, but would still be available via direct link. That > > > way, nothing is lost, but the clutter vanishes. > > > > > > You could even have yet another category for projects that are known > > > to be abandoned. > > > > Nope, the terms of use are already pretty clear. And no one has provided > > a compelling reason to keep these projects around, just lots of > > suggestions on how to keep them around. Deleted is what we want, not > > delisted or saved forever or anything like that. We're not going to > > commit any resources to a project that choosed not to use this free > > service. > > Compelling reason: application is in Fedora today, maintained in > fedorahosted and ends up in RHEL. A year after RHEL release, the app is > obsoleted by something else in Fedora. Thus, the app in hosted > basically gets very little in the way of updates. But keeping the > source repository available is very important for any updates later > needed for RHEL. Also, isn't there something in the GPL about keeping everything around for (at least) three years? I think delisting is better than removing, I'd even be prepared to say "delisting+read only" is an even better choice (think: disappears off main fh.o and the commit group gets "disabled" or set to "inactive" (i.e. shell access isn't given as part of that group)), after three years, then by all means. Six months just seems short (that's my only thought). - Nigel > > Jeremy > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- Nigel Jones From stickster at gmail.com Wed Sep 10 02:24:43 2008 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 10 Sep 2008 02:24:43 +0000 Subject: Removal of old projects from fedorahosted. In-Reply-To: References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> Message-ID: <1221013483.1362.106.camel@localhost.localdomain> On Tue, 2008-09-09 at 21:02 -0500, Mike McGrath wrote: > On Tue, 9 Sep 2008, Robin Norwood wrote: > > > On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath wrote: > > > Nope, the terms of use are already pretty clear. And no one has provided > > > a compelling reason to keep these projects around, just lots of > > > suggestions on how to keep them around. Deleted is what we want, not > > > delisted or saved forever or anything like that. We're not going to > > > commit any resources to a project that choosed not to use this free > > > service. > > > > Well, because sooner or later, you'll delete a project that someone > > didn't want deleted, and they'll be ticked off. Maybe they'll open a > > ticket and convince the infra. team to restore the data from a backup, > > or maybe they'll just be ticked off and rant about how much Fedora > > sucks for deleting this thing they didn't want deleted. > > > > I'm fine with that. Its well documented. and its not like we're going to > rm -rf the thing. We'll keep it around for a while but no promises. > > > Again, I'm assuming the per-project maintenence cost is near zero (ie, > > a little bit of disk space). If not, then maybe I could see a case > > for automatically deleting old projects. > > > > Ah, thats an incorrect assumption. Is there a way to balance deactivating the greater project needs with the value of the source code as a useful historical artifact? In other words, if we reduced (for example) an active git-based project to just the .git stuff, and made it available for download only, then the cost really is just disk space, right? I wouldn't want to see Infrastructure roped into committing lots of resources to carry a ton of dead projects. If there's a significant per-project maintenance cost, even if it just adds up to something significant over hundreds of projects, the work has to be justified somehow. Is there a way to keep the source around but not induce the maintenance cost? Am I being naive about this? -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 Sep 10 02:33:50 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 9 Sep 2008 21:33:50 -0500 (CDT) Subject: Removal of old projects from fedorahosted. In-Reply-To: <1221013483.1362.106.camel@localhost.localdomain> References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> <1221013483.1362.106.camel@localhost.localdomain> Message-ID: On Wed, 10 Sep 2008, Paul W. Frields wrote: > On Tue, 2008-09-09 at 21:02 -0500, Mike McGrath wrote: > > On Tue, 9 Sep 2008, Robin Norwood wrote: > > > > > On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath wrote: > > > > Nope, the terms of use are already pretty clear. And no one has provided > > > > a compelling reason to keep these projects around, just lots of > > > > suggestions on how to keep them around. Deleted is what we want, not > > > > delisted or saved forever or anything like that. We're not going to > > > > commit any resources to a project that choosed not to use this free > > > > service. > > > > > > Well, because sooner or later, you'll delete a project that someone > > > didn't want deleted, and they'll be ticked off. Maybe they'll open a > > > ticket and convince the infra. team to restore the data from a backup, > > > or maybe they'll just be ticked off and rant about how much Fedora > > > sucks for deleting this thing they didn't want deleted. > > > > > > > I'm fine with that. Its well documented. and its not like we're going to > > rm -rf the thing. We'll keep it around for a while but no promises. > > > > > Again, I'm assuming the per-project maintenence cost is near zero (ie, > > > a little bit of disk space). If not, then maybe I could see a case > > > for automatically deleting old projects. > > > > > > > Ah, thats an incorrect assumption. > > Is there a way to balance deactivating the greater project needs with > the value of the source code as a useful historical artifact? In other > words, if we reduced (for example) an active git-based project to just > the .git stuff, and made it available for download only, then the cost > really is just disk space, right? > Nope not just disk space. > I wouldn't want to see Infrastructure roped into committing lots of > resources to carry a ton of dead projects. If there's a significant > per-project maintenance cost, even if it just adds up to something > significant over hundreds of projects, the work has to be justified > somehow. Is there a way to keep the source around but not induce the > maintenance cost? Am I being naive about this? > Backups, time to maintain, bandwidth for the backups, testing when we make changes, people to notify should our Infrastructure get compromised again, etc, the unknown. Its all those little things that people don't think about that I worries me. What's the benefit of keeping them around? I mean, I can commit to saying "we'll remove a project and keep it offline for a year if someone complains we'll give it to them". I guess I'm just putting my foot down on this since almost all the support for "keep everything around forever" has come from people that don't have to deal with the consequences of that decision. This isn't a file being kept on someones desktop... -Mike From katzj at redhat.com Wed Sep 10 02:42:06 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 09 Sep 2008 22:42:06 -0400 Subject: Removal of old projects from fedorahosted. In-Reply-To: References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> <1221012708.5554.195.camel@aglarond.local> Message-ID: <1221014526.5554.199.camel@aglarond.local> On Tue, 2008-09-09 at 21:20 -0500, Mike McGrath wrote: > I don't see why that project would get removed. I really think I'm > getting misunderstood here. I think that part of the misunderstanding is that I don't see "six months" as equivalent to "stale". We're not even to the seven year point of RHEL 2.1. And there are definitely things that I personally migrated from elvis -> fedorahosted that, while not relevant with "current" distros still are for older RHEL. > 1) we send an email to the group members explaining their project is stale > and asking to remove it. > 2) they respond saying they'd like to not have it removed. (it stays) It stays for how long? If we look at the set of what's being talked about here, I can already tell you that the vast majority are going to fall into the "wanting to be kept" category. Which means that we're doing a lot of administrative overhead for how much gain? > 3) they respond saying its no longer used and it can be removed (we remove > it or they move it elsewhere) > 4) no one responds (it gets removed) Within what time period? And if it later becomes relevant/needed again we just hope that someone has a backup? Jeremy From katzj at redhat.com Wed Sep 10 02:45:51 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 09 Sep 2008 22:45:51 -0400 Subject: Removal of old projects from fedorahosted. In-Reply-To: References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> <1221013483.1362.106.camel@localhost.localdomain> Message-ID: <1221014751.5554.203.camel@aglarond.local> On Tue, 2008-09-09 at 21:33 -0500, Mike McGrath wrote: > On Wed, 10 Sep 2008, Paul W. Frields wrote: > > On Tue, 2008-09-09 at 21:02 -0500, Mike McGrath wrote: > > > On Tue, 9 Sep 2008, Robin Norwood wrote: > > > > > > > On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath wrote: > > > > > Nope, the terms of use are already pretty clear. And no one has provided > > > > > a compelling reason to keep these projects around, just lots of > > > > > suggestions on how to keep them around. Deleted is what we want, not > > > > > delisted or saved forever or anything like that. We're not going to > > > > > commit any resources to a project that choosed not to use this free > > > > > service. > > > > > > > > Well, because sooner or later, you'll delete a project that someone > > > > didn't want deleted, and they'll be ticked off. Maybe they'll open a > > > > ticket and convince the infra. team to restore the data from a backup, > > > > or maybe they'll just be ticked off and rant about how much Fedora > > > > sucks for deleting this thing they didn't want deleted. > > > > > > > > > > I'm fine with that. Its well documented. and its not like we're going to > > > rm -rf the thing. We'll keep it around for a while but no promises. > > > > > > > Again, I'm assuming the per-project maintenence cost is near zero (ie, > > > > a little bit of disk space). If not, then maybe I could see a case > > > > for automatically deleting old projects. > > > > > > > > > > Ah, thats an incorrect assumption. > > > > Is there a way to balance deactivating the greater project needs with > > the value of the source code as a useful historical artifact? In other > > words, if we reduced (for example) an active git-based project to just > > the .git stuff, and made it available for download only, then the cost > > really is just disk space, right? > > > > Nope not just disk space. > > > I wouldn't want to see Infrastructure roped into committing lots of > > resources to carry a ton of dead projects. If there's a significant > > per-project maintenance cost, even if it just adds up to something > > significant over hundreds of projects, the work has to be justified > > somehow. Is there a way to keep the source around but not induce the > > maintenance cost? Am I being naive about this? > > > > Backups, time to maintain, bandwidth for the backups, testing when we make > changes, people to notify should our Infrastructure get compromised again, > etc, the unknown. Backups really are equivalent to disk space. Testing for changes -- maybe. But if it's really that inactive, then a change is unlikely to break it. And if it does, then when someone notices, they'll holler. As for the people to notify bit, I liked Nigel's idea of delist +read-only -- then you don't have to worry about notifying, but at the same time, it's easy to have access restored if it becomes relevant. > Its all those little things that people don't think about that I worries > me. What's the benefit of keeping them around? I mean, I can commit > to saying "we'll remove a project and keep it offline for a year if someone > complains we'll give it to them". The benefit of keeping them around is the same as the benefit for why we don't prune historical src.rpms or tarballs from distcvs. Or why we don't prune the history of source repos in general. Yes, it may be ancient history, but it's still history. And there's a lot that can be learned from history. Just ask the people that have done things like importing _all_ kernel history since the dawn of time (that at least they can find tarballs for). Or ajax and his "X since the dawn of time" archive. > I guess I'm just putting my foot down on this since almost all the support > for "keep everything around forever" has come from people that don't have > to deal with the consequences of that decision. This isn't a file being > kept on someones desktop... You're right, it's not a file that's being kept on someone's desktop. It's something far more important -- it's the DNA of the evolution of open source. Jeremy From mmcgrath at redhat.com Wed Sep 10 02:52:52 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 9 Sep 2008 21:52:52 -0500 (CDT) Subject: Removal of old projects from fedorahosted. In-Reply-To: <1221014526.5554.199.camel@aglarond.local> References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> <1221012708.5554.195.camel@aglarond.local> <1221014526.5554.199.camel@aglarond.local> Message-ID: On Tue, 9 Sep 2008, Jeremy Katz wrote: > On Tue, 2008-09-09 at 21:20 -0500, Mike McGrath wrote: > > I don't see why that project would get removed. I really think I'm > > getting misunderstood here. > > I think that part of the misunderstanding is that I don't see "six > months" as equivalent to "stale". We're not even to the seven year > point of RHEL 2.1. And there are definitely things that I personally > migrated from elvis -> fedorahosted that, while not relevant with > "current" distros still are for older RHEL. > > > 1) we send an email to the group members explaining their project is stale > > and asking to remove it. > > 2) they respond saying they'd like to not have it removed. (it stays) > > It stays for how long? If we look at the set of what's being talked > about here, I can already tell you that the vast majority are going to > fall into the "wanting to be kept" category. Which means that we're > doing a lot of administrative overhead for how much gain? > Till they say otherwise or until the board says to take it down. > > 3) they respond saying its no longer used and it can be removed (we remove > > it or they move it elsewhere) > > 4) no one responds (it gets removed) > > Within what time period? And if it later becomes relevant/needed again > we just hope that someone has a backup? > Yep, its well documented and if thats not ok for them, there's other offerings out there. I will not let our offering become another sourceforge and become the butt of every packagers jokes. Bottom line, hosting isn't what _WE_ do. its a value added service and I'm keeping that well in mind. As far as administrative overhead. I've spent far more time on sending emails about it then it took for us to run the scripts and contact the hosts. fedorahosted != elvis fedorahosted != sourceforge If you want elvis, you can put your stuff there. -Mike From mmcgrath at redhat.com Wed Sep 10 02:54:58 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 9 Sep 2008 21:54:58 -0500 (CDT) Subject: Removal of old projects from fedorahosted. In-Reply-To: <1221014751.5554.203.camel@aglarond.local> References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> <1221013483.1362.106.camel@localhost.localdomain> <1221014751.5554.203.camel@aglarond.local> Message-ID: On Tue, 9 Sep 2008, Jeremy Katz wrote: > > > > Backups, time to maintain, bandwidth for the backups, testing when we make > > changes, people to notify should our Infrastructure get compromised again, > > etc, the unknown. > > Backups really are equivalent to disk space. Testing for changes -- > maybe. But if it's really that inactive, then a change is unlikely to > break it. And if it does, then when someone notices, they'll holler. > yeah, when you backup to disk over a LAN, neither of which we do. > Yes, it may be ancient history, but it's still history. And there's a > lot that can be learned from history. Just ask the people that have > done things like importing _all_ kernel history since the dawn of time > (that at least they can find tarballs for). Or ajax and his "X since > the dawn of time" archive. > > > I guess I'm just putting my foot down on this since almost all the support > > for "keep everything around forever" has come from people that don't have > > to deal with the consequences of that decision. This isn't a file being > > kept on someones desktop... > > You're right, it's not a file that's being kept on someone's desktop. > It's something far more important -- it's the DNA of the evolution of > open source. > Then they can keep their DNA somewhere else. -Mike From mmcgrath at redhat.com Wed Sep 10 02:57:42 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 9 Sep 2008 21:57:42 -0500 (CDT) Subject: Removal of old projects from fedorahosted. In-Reply-To: References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> <1221013483.1362.106.camel@localhost.localdomain> <1221014751.5554.203.camel@aglarond.local> Message-ID: On Tue, 9 Sep 2008, Mike McGrath wrote: > On Tue, 9 Sep 2008, Jeremy Katz wrote: > > > > > > Backups, time to maintain, bandwidth for the backups, testing when we make > > > changes, people to notify should our Infrastructure get compromised again, > > > etc, the unknown. > > > > Backups really are equivalent to disk space. Testing for changes -- > > maybe. But if it's really that inactive, then a change is unlikely to > > break it. And if it does, then when someone notices, they'll holler. > > > > yeah, when you backup to disk over a LAN, neither of which we do. > Actually this isn't true, we do local backup to remote disk over a LAN via a sync, we also do a remote backup to tape. -Mike From mmcgrath at redhat.com Wed Sep 10 03:44:31 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 9 Sep 2008 22:44:31 -0500 (CDT) Subject: Removal of old projects from fedorahosted. In-Reply-To: <1221014751.5554.203.camel@aglarond.local> References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> <1221013483.1362.106.camel@localhost.localdomain> <1221014751.5554.203.camel@aglarond.local> Message-ID: On Tue, 9 Sep 2008, Jeremy Katz wrote: > On Tue, 2008-09-09 at 21:33 -0500, Mike McGrath wrote: > > On Wed, 10 Sep 2008, Paul W. Frields wrote: > > > On Tue, 2008-09-09 at 21:02 -0500, Mike McGrath wrote: > > > > On Tue, 9 Sep 2008, Robin Norwood wrote: > > > > > > > > > On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath wrote: > > > > > > Nope, the terms of use are already pretty clear. And no one has provided > > > > > > a compelling reason to keep these projects around, just lots of > > > > > > suggestions on how to keep them around. Deleted is what we want, not > > > > > > delisted or saved forever or anything like that. We're not going to > > > > > > commit any resources to a project that choosed not to use this free > > > > > > service. > > > > > > > > > > Well, because sooner or later, you'll delete a project that someone > > > > > didn't want deleted, and they'll be ticked off. Maybe they'll open a > > > > > ticket and convince the infra. team to restore the data from a backup, > > > > > or maybe they'll just be ticked off and rant about how much Fedora > > > > > sucks for deleting this thing they didn't want deleted. > > > > > > > > > > > > > I'm fine with that. Its well documented. and its not like we're going to > > > > rm -rf the thing. We'll keep it around for a while but no promises. > > > > > > > > > Again, I'm assuming the per-project maintenence cost is near zero (ie, > > > > > a little bit of disk space). If not, then maybe I could see a case > > > > > for automatically deleting old projects. > > > > > > > > > > > > > Ah, thats an incorrect assumption. > > > > > > Is there a way to balance deactivating the greater project needs with > > > the value of the source code as a useful historical artifact? In other > > > words, if we reduced (for example) an active git-based project to just > > > the .git stuff, and made it available for download only, then the cost > > > really is just disk space, right? > > > > > > > Nope not just disk space. > > > > > I wouldn't want to see Infrastructure roped into committing lots of > > > resources to carry a ton of dead projects. If there's a significant > > > per-project maintenance cost, even if it just adds up to something > > > significant over hundreds of projects, the work has to be justified > > > somehow. Is there a way to keep the source around but not induce the > > > maintenance cost? Am I being naive about this? > > > > > > > Backups, time to maintain, bandwidth for the backups, testing when we make > > changes, people to notify should our Infrastructure get compromised again, > > etc, the unknown. > > Backups really are equivalent to disk space. Testing for changes -- > maybe. But if it's really that inactive, then a change is unlikely to > break it. And if it does, then when someone notices, they'll holler. > > As for the people to notify bit, I liked Nigel's idea of delist > +read-only -- then you don't have to worry about notifying, but at the > same time, it's easy to have access restored if it becomes relevant. > So it seems I'm alone here, if we have to keep everything forever, thats what it'll be. I'll just have to see to it we have the resources and backup materials in the future when that time comes. I have a question and a suggestion for people. 1) What do we do with projects to which no owner or responsible party can be found? This caused major headaches during the elvis move... headaches we still have today. What would you have us do? 2) Right before we start removing projects is _not_ the time to discuss the policy. When the policy is put in place... thats the time to discuss it. -Mike From katzj at redhat.com Wed Sep 10 14:22:06 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 10 Sep 2008 10:22:06 -0400 Subject: Removal of old projects from fedorahosted. In-Reply-To: References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> <1221013483.1362.106.camel@localhost.localdomain> <1221014751.5554.203.camel@aglarond.local> Message-ID: <1221056526.18710.76.camel@aglarond.local> On Tue, 2008-09-09 at 22:44 -0500, Mike McGrath wrote: > So it seems I'm alone here, if we have to keep everything forever, thats > what it'll be. I'll just have to see to it we have the resources and > backup materials in the future when that time comes. I have a question > and a suggestion for people. > > 1) What do we do with projects to which no owner or responsible party can > be found? This caused major headaches during the elvis move... headaches > we still have today. What would you have us do? I think the idea of making them read-only/owned by an "admin" type group seems reasonable at first blush. It doesn't get rid of all of the problems, but it does help with a number of them > 2) Right before we start removing projects is _not_ the time to discuss > the policy. When the policy is put in place... thats the time to discuss > it. I don't disagree at all. I must have missed the initial discussion in my sea of mail or I would have chimed in then :-/ Jeremy From mmcgrath at redhat.com Wed Sep 10 14:57:44 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 10 Sep 2008 09:57:44 -0500 (CDT) Subject: Removal of old projects from fedorahosted. In-Reply-To: <1221056526.18710.76.camel@aglarond.local> References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> <1221013483.1362.106.camel@localhost.localdomain> <1221014751.5554.203.camel@aglarond.local> <1221056526.18710.76.camel@aglarond.local> Message-ID: On Wed, 10 Sep 2008, Jeremy Katz wrote: > On Tue, 2008-09-09 at 22:44 -0500, Mike McGrath wrote: > > So it seems I'm alone here, if we have to keep everything forever, thats > > what it'll be. I'll just have to see to it we have the resources and > > backup materials in the future when that time comes. I have a question > > and a suggestion for people. > > > > 1) What do we do with projects to which no owner or responsible party can > > be found? This caused major headaches during the elvis move... headaches > > we still have today. What would you have us do? > > I think the idea of making them read-only/owned by an "admin" type group > seems reasonable at first blush. It doesn't get rid of all of the > problems, but it does help with a number of them > > > 2) Right before we start removing projects is _not_ the time to discuss > > the policy. When the policy is put in place... thats the time to discuss > > it. > > I don't disagree at all. I must have missed the initial discussion in > my sea of mail or I would have chimed in then :-/ > no worries, I can admit to blowing my top last night, long day. We'll figure something out. Taking a step back my core concerns are code to which no one is responsible and what to do about that code. _especially_ if its still in use somewhere. It actually complicated the move away from elvis quite a bit and I want to make sure that doesn't happen again. We can look at that philosophically and practically. -Mike From stickster at gmail.com Wed Sep 10 15:40:50 2008 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 10 Sep 2008 15:40:50 +0000 Subject: Removal of old projects from fedorahosted. In-Reply-To: References: <3170f42f0809090950t6acb478aq77c5bd3117220f4f@mail.gmail.com> <20080909202323.GA14625@gmail.com> <1221013483.1362.106.camel@localhost.localdomain> <1221014751.5554.203.camel@aglarond.local> <1221056526.18710.76.camel@aglarond.local> Message-ID: <1221061250.14078.61.camel@localhost.localdomain> On Wed, 2008-09-10 at 09:57 -0500, Mike McGrath wrote: > On Wed, 10 Sep 2008, Jeremy Katz wrote: > > > On Tue, 2008-09-09 at 22:44 -0500, Mike McGrath wrote: > > > So it seems I'm alone here, if we have to keep everything forever, thats > > > what it'll be. I'll just have to see to it we have the resources and > > > backup materials in the future when that time comes. I have a question > > > and a suggestion for people. > > > > > > 1) What do we do with projects to which no owner or responsible party can > > > be found? This caused major headaches during the elvis move... headaches > > > we still have today. What would you have us do? > > > > I think the idea of making them read-only/owned by an "admin" type group > > seems reasonable at first blush. It doesn't get rid of all of the > > problems, but it does help with a number of them > > > > > 2) Right before we start removing projects is _not_ the time to discuss > > > the policy. When the policy is put in place... thats the time to discuss > > > it. > > > > I don't disagree at all. I must have missed the initial discussion in > > my sea of mail or I would have chimed in then :-/ > > > > no worries, I can admit to blowing my top last night, long day. We'll > figure something out. Taking a step back my core concerns are code to > which no one is responsible and what to do about that code. _especially_ > if its still in use somewhere. It actually complicated the move away from > elvis quite a bit and I want to make sure that doesn't happen again. > > We can look at that philosophically and practically. I think your concerns are really rational and well-placed. Hope we didn't get too irksome, and thanks for "deconfusifying" (a favorite made-up word) the scenarios about how FI would approach de-listing. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 Wed Sep 10 17:11:07 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 10 Sep 2008 12:11:07 -0500 Subject: Outage Notification - 2008-09-13 01:00 UTC Message-ID: <200809101211.12685.dennis@ausil.us> There will be an outage starting at Y2008-09-13 01:00 UTC, which will last approximately 1 hour. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2008-09-13 01:00 UTC' Affected Services: Buildsystem Unaffected Services: Websites Database CVS / Source Control DNS Mail Torrent Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/830 Reason for Outage: update koji to 1.2.6. it will enable us to turn garbage collection back on. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From mmcgrath at redhat.com Wed Sep 10 18:37:41 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 10 Sep 2008 13:37:41 -0500 (CDT) Subject: Orientation page Message-ID: Hey guys I threw together a standard orientation page for new members. Take a look and let me know what pieces you think are missing and fix whatever problems you find. http://fedoraproject.org/wiki/Infrastructure/SOP/Orientation -Mike From thinklinux.ssh at gmail.com Wed Sep 10 18:53:05 2008 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Thu, 11 Sep 2008 00:23:05 +0530 Subject: Orientation page In-Reply-To: References: Message-ID: > Take a look and let me know what pieces you think are missing and fix > whatever problems you find. mailing list address is not mentioned :) -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= From tjdavisbz at gmail.com Wed Sep 10 18:57:40 2008 From: tjdavisbz at gmail.com (TJ Davis) Date: Wed, 10 Sep 2008 12:57:40 -0600 Subject: Orientation page In-Reply-To: References: Message-ID: <64677a960809101157i458a2793p57097451ae0684cd@mail.gmail.com> Perhaps the standard meeting day/time could be included? Tj On Wed, Sep 10, 2008 at 12:37 PM, Mike McGrath wrote: > Hey guys I threw together a standard orientation page for new members. > Take a look and let me know what pieces you think are missing and fix > whatever problems you find. > > http://fedoraproject.org/wiki/Infrastructure/SOP/Orientation > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From lmacken at redhat.com Wed Sep 10 21:33:30 2008 From: lmacken at redhat.com (Luke Macken) Date: Wed, 10 Sep 2008 17:33:30 -0400 Subject: SELinux status update Message-ID: <20080910213330.GF4048@x300> Over the past few months, I've been working closley with Dan Walsh and Mike McGrath to solidify our SELinux deployment. We're not yet to the point where we can flip every system into enforcing mode, but we're getting close. We're at the point now where we can pretty much do everything we need to do via our puppet configuration, and we've created a handful of constructs that can be used to configure various aspects of SELinux, for example: == Setting custom context semanage_fcontext { '/var/tmp/l10n-data(/.*)?': type => 'httpd_sys_content_t' } == Toggling booleans selinux_bool { 'httpd_can_network_connect_db': bool => 'on' } == Allowing ports semanage_port { '8081-8089': type => 'http_port_t', proto => 'tcp' } == Deploying custom policy semodule { 'fedora': } I created a custom 'fedora' selinux module that is loaded on all systems (that are configured with 'include selinux'). This module exists to fix various issues custom to our environment, and to cover up minor annoyances such as leaky file descriptors. So, now it's just a matter of hunting down the existing issues, and fixing them in puppet or in the SELinux policy. I've been keeping our infrastructure ahead of the RHEL5 selinux-policy, as Dan has fixed a lot of our issues in his rpms. I threw together a basic SOP for our SELinux configuration here: https://fedoraproject.org/wiki/Infrastructure/SOP/SELinux You can keep up to date on our SELinux deployment status here: https://fedorahosted.org/fedora-infrastructure/ticket/230 Cheers, luke -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From lmacken at redhat.com Wed Sep 10 22:10:42 2008 From: lmacken at redhat.com (Luke Macken) Date: Wed, 10 Sep 2008 18:10:42 -0400 Subject: Intrusion Detection System Message-ID: <20080910221042.GG4048@x300> Hey all, A couple of weeks ago I did an initial deployment of an Intrusion Detection System in our infrastructure. It utilizes the prelude stack, and is currently powered by auditd and prelude-lml events. Audit gives us a ridiculous amount of power with regarding to monitoring everything that happens on a system. Prelude-lml, out of the box using it's pcre plugin, is able to watch a large variety of service logs, including many things we are running (asterisk, mod_security, nagios, cacti, PAM, postfix, sendmail, selinux, shadowutils, sshd, sudo). Prewikka is the web-based frontend (https://admin.fedoraproject.org/prewikka). I created a new 'prelude' puppet module that contains the configuration for audit, auditsp-plugins, libprelude, prelude-manager, prewikka, prelude-correlator, and prelude-lml. Turning a node/servergroup into a sensor entails adding the following to your class definition: 'include prelude::sensor::audisp' My initial deployment entailed setting up the prelude-manager and correlator on a single box, and hooking up a single sensor (bastion). So, we're now at the point where we can fine tune our audit rules before we further deploy this infrastructure. Some things we want to consider: - Creating specific security policies for each servergroup - Define what files/directories/activities we want to monitor on which machines. - What events to we want to escalate ? I opened an infrastructure ticket to track this deployment here: https://fedorahosted.org/fedora-infrastructure/ticket/833 Suggestions, comments, and ideas are welcome. Cheers, luke -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From smooge at gmail.com Thu Sep 11 00:26:55 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 10 Sep 2008 18:26:55 -0600 Subject: SELinux status update In-Reply-To: <20080910213330.GF4048@x300> References: <20080910213330.GF4048@x300> Message-ID: <80d7e4090809101726x365ab021u106d46d9fd9fc2db@mail.gmail.com> 2008/9/10 Luke Macken : > Over the past few months, I've been working closley with Dan Walsh and > Mike McGrath to solidify our SELinux deployment. We're not yet to the > point where we can flip every system into enforcing mode, but we're > getting close. > Very very very cool. I look forward to reading through all the puppet side of things. -- Stephen J Smoogen. -- BSD/GNU/Linux 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 Thu Sep 11 00:29:38 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 10 Sep 2008 18:29:38 -0600 Subject: Intrusion Detection System In-Reply-To: <20080910221042.GG4048@x300> References: <20080910221042.GG4048@x300> Message-ID: <80d7e4090809101729j797c8d5k292ad6a42e02f6e1@mail.gmail.com> 2008/9/10 Luke Macken : > Hey all, > > A couple of weeks ago I did an initial deployment of an Intrusion > Detection System in our infrastructure. It utilizes the prelude stack, > and is currently powered by auditd and prelude-lml events. Audit gives > us a ridiculous amount of power with regarding to monitoring > everything that happens on a system. Prelude-lml, out of the box > using it's pcre plugin, is able to watch a large variety of service > logs, including many things we are running (asterisk, mod_security, > nagios, cacti, PAM, postfix, sendmail, selinux, shadowutils, sshd, > sudo). Prewikka is the web-based frontend > (https://admin.fedoraproject.org/prewikka). > for the EL-5 systems.. did you need to update audit from what is provided by RHEL-5.2? It looked like it would be needed when I talked with Steve Grubb because it required stuff that had not been ported to EL-5. I would be interested in helping you test/document this? Where can I start? -- Stephen J Smoogen. -- BSD/GNU/Linux 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 Thu Sep 11 00:40:34 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 10 Sep 2008 18:40:34 -0600 Subject: Intrusion Detection System In-Reply-To: <20080910221042.GG4048@x300> References: <20080910221042.GG4048@x300> Message-ID: <80d7e4090809101740g254d220dj72b8259a92dd29ab@mail.gmail.com> 2008/9/10 Luke Macken : > Hey all, > > A couple of weeks ago I did an initial deployment of an Intrusion > Detection System in our infrastructure. It utilizes the prelude stack, > and is currently powered by auditd and prelude-lml events. Audit gives > us a ridiculous amount of power with regarding to monitoring > everything that happens on a system. Prelude-lml, out of the box > using it's pcre plugin, is able to watch a large variety of service > logs, including many things we are running (asterisk, mod_security, > nagios, cacti, PAM, postfix, sendmail, selinux, shadowutils, sshd, > sudo). Prewikka is the web-based frontend > (https://admin.fedoraproject.org/prewikka). > for the EL-5 systems.. did you need to update audit from what is provided by RHEL-5.2? It looked like it would be needed when I talked with Steve Grubb because it required stuff that had not been ported to EL-5. I would be interested in helping you test/document this? Where can I start? -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From lmacken at redhat.com Thu Sep 11 01:12:17 2008 From: lmacken at redhat.com (Luke Macken) Date: Wed, 10 Sep 2008 21:12:17 -0400 Subject: Intrusion Detection System In-Reply-To: <80d7e4090809101729j797c8d5k292ad6a42e02f6e1@mail.gmail.com> References: <20080910221042.GG4048@x300> <80d7e4090809101729j797c8d5k292ad6a42e02f6e1@mail.gmail.com> Message-ID: <20080911011217.GA18733@x300> On Wed, Sep 10, 2008 at 06:29:38PM -0600, Stephen John Smoogen wrote: > 2008/9/10 Luke Macken : > > Hey all, > > > > A couple of weeks ago I did an initial deployment of an Intrusion > > Detection System in our infrastructure. It utilizes the prelude stack, > > and is currently powered by auditd and prelude-lml events. Audit gives > > us a ridiculous amount of power with regarding to monitoring > > everything that happens on a system. Prelude-lml, out of the box > > using it's pcre plugin, is able to watch a large variety of service > > logs, including many things we are running (asterisk, mod_security, > > nagios, cacti, PAM, postfix, sendmail, selinux, shadowutils, sshd, > > sudo). Prewikka is the web-based frontend > > (https://admin.fedoraproject.org/prewikka). > > > > for the EL-5 systems.. did you need to update audit from what is > provided by RHEL-5.2? It looked like it would be needed when I talked > with Steve Grubb because it required stuff that had not been ported to > EL-5. I would be interested in helping you test/document this? Where > can I start? Yep, RHEL's audit is not compiled with '--enable-prelude', so I respun F-9's. I also built rawhide's prelude stack. All of these packages are in the fedora-infrastructure repo. As far as testing goes, I recommend setting up the stack on your home network to get familar with it (http://people.redhat.com/sgrubb/audit/prelude.txt). As for documentation, we definitely need to throw together a SOP, and maybe some sort of audit policy for all of our various server groups. Before we start tweaking out our audit rules, we should probably start by defining security policies for our various systems so we can turn them into audit rules and selinux policy. luke From bretm at redhat.com Thu Sep 11 14:13:52 2008 From: bretm at redhat.com (Bret McMillan) Date: Thu, 11 Sep 2008 10:13:52 -0400 Subject: Intrusion Detection System In-Reply-To: <20080910221042.GG4048@x300> References: <20080910221042.GG4048@x300> Message-ID: <48C927A0.7090306@redhat.com> Luke Macken wrote: > Hey all, > > A couple of weeks ago I did an initial deployment of an Intrusion > Detection System in our infrastructure. It utilizes the prelude stack, > and is currently powered by auditd and prelude-lml events. Audit gives > us a ridiculous amount of power with regarding to monitoring > everything that happens on a system. Prelude-lml, out of the box > using it's pcre plugin, is able to watch a large variety of service > logs, including many things we are running (asterisk, mod_security, > nagios, cacti, PAM, postfix, sendmail, selinux, shadowutils, sshd, > sudo). Prewikka is the web-based frontend > (https://admin.fedoraproject.org/prewikka). Permission denied post-login :) But looking forward to seeing this in action :) --Bret From ricky at fedoraproject.org Thu Sep 11 21:21:51 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 11 Sep 2008 17:21:51 -0400 Subject: Meeting Log - 2008-09-11 Message-ID: <20080911212151.GD10748@sphe.res.cmu.edu> 20:00 -!- dgilmore changed the topic of #fedora-meeting to: infra meeting prep 20:00 * abadger1999 stretches 20:00 < dgilmore> hey all meetingtime 20:00 * ValHolla walks in 20:00 < SmootherFrOgZ> hello guys 20:00 < abadger1999> Hey ValHolla! 20:01 < abadger1999> Hello SmootherFrOgZ 20:01 < brothers> EHLO 20:01 < ValHolla> Hello 20:01 * wakko666 lurks. 20:01 < dgilmore> we will start with https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=~Meeting&order=priority 20:01 < dgilmore> the tickets :) 20:01 * fchiulli is observing 20:01 * mmcgrath notes G said he won't be around and sends his best. 20:01 < dgilmore> .ticket 753 20:01 < zodbot> dgilmore: #753 (Mini-freeze for Fedora 10 beta) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/753 20:01 * ricky 20:01 * nokia3510 says hello 20:02 < dgilmore> we need to plan infra freeze for F-10 release 20:02 < dgilmore> and a mini one for beta 20:02 < dgilmore> f13: when is beta. what would you like frozen? 20:04 < dgilmore> mmcgrath: thanks :) 20:04 < f13> mmcgrath write up a chart that showed what would be frozen and what wouldn't. THe beta freeze is supposed to be today 20:04 -!- skvidal [n=nnnnnnsk at fedora/skvidal] has joined #fedora-meeting 20:04 < mmcgrath> f13: ah, k. I wasn't sure about the dates. given the fas issues that are going on, mind if we start the freeze tomorrow? 20:05 < dgilmore> f13: i have a koji outage scheduled for tomorrow 20:05 < dgilmore> i guess we should have talked about this last week 20:05 -!- kital [n=Joerg_Si at fedora/kital] has quit Remote closed the connection 20:06 < mmcgrath> yeah, its the first time we've really done a beta freeze, I wasn't sure when it was going to start either. 20:06 < mmcgrath> f13: so next time we'll be more careful, mind if we start the freeze on the 13th? 20:06 < f13> this beta is looking like a rolling wreck anyway, so sure, why not 20:06 < mmcgrath> hahahah 20:06 < dgilmore> f13: :) 20:06 < abadger1999> As long as it's rolling :-) 20:06 < mmcgrath> on the f13th 20:06 < f13> so it goes. 20:07 < dgilmore> so that means all changes need to be sent to infra list first and acked by one other? 20:07 < mmcgrath> yeah. I'll send a note out after the meeting similar to the last one. I should update the release SOP as well. 20:08 < dgilmore> do we roll from mini freeze to full freeze? or do we unfrezze once beta is out and frezze again for test and final? 20:09 < dgilmore> lets talk this over on the list 20:09 < dgilmore> .ticket 395 20:09 < zodbot> dgilmore: #395 (Audio Streaming of Fedora Board Conference Calls) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/395 20:09 < dgilmore> jcollie: ping 20:09 < jcollie> dgilmore: ping 20:09 < dgilmore> any update 20:09 < f13> I'm fine with unfreeze/refreeze later 20:09 < SmootherFrOgZ> dgilmore: mail says on Saturnday 13 for the outage 20:09 < dgilmore> SmootherFrOgZ: 1:00am UTC which is 8pm friday my time 20:10 < jcollie> dgilmore: nope, been busy with other stuff :( 20:10 < dgilmore> jcollie: :) it happens 20:10 -!- cassmodiah [n=cass at p54AB3DC0.dip.t-dialin.net] has quit Remote closed the connection 20:10 < SmootherFrOgZ> dgilmore: k 20:10 < dgilmore> .ticket 446 20:10 < zodbot> dgilmore: #446 (Possibility to add external links on spins page) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/446 20:10 < dgilmore> this is me 20:10 < dgilmore> i fail 20:10 < dgilmore> .ticket 740 20:11 < zodbot> dgilmore: #740 (Loaning out system time to OLPC participants) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/740 20:11 < dgilmore> so I got from OLPC what it is they wanted 20:11 < dgilmore> as i suspected its a machine where people can log in. have cvs, koji, mock, etc access 20:12 < dgilmore> so they can do test builds. package management etc 20:12 -!- kital [n=Joerg_Si at fedora/kital] has joined #fedora-meeting 20:13 < dgilmore> there is quite a few people at OLPC who don't use fedora and are not familiar with fedora and how it works 20:13 < dgilmore> so part of what they want is also help to train people on how to work with fedora. how to maintain packages. 20:14 < dgilmore> mock is packaged and works on debian 20:14 < dgilmore> koji is not packaged 20:15 < dgilmore> so does anyone have ideas on what we can do to help 20:15 < nokia3510> I don't get it why they need a machine in this case. 20:15 < f13> I really don't understand why they can't supply this themselves 20:15 < f13> it's not very hard to put up a RHEL or Fedora host and install those packages 20:16 < f13> or is the thing they really want help with account management, in the form of FAS logins? 20:16 < dgilmore> nokia3510: so that people who dont use fedora can get access to it 20:16 < dgilmore> f13: some of it is fas 20:16 < dgilmore> and account management 20:17 < dgilmore> When i was there i was pushing to get fas in place. and i think it will happen over time 20:17 < f13> so tell them if they host a quadg5 system, we'll let them use fas to log in on it (: 20:18 < ValHolla> The reply from OLPC sounds to me like they are looking for a "tutor" ... someone to teach the non Fedora folks 20:18 < dgilmore> some of it is trying to get it closer to fedora. so that fedora developers could help train olpc's developers in fedora 20:18 < dgilmore> f13: :) 20:18 < f13> er, why does it matter where the box lives for that? 20:18 * f13 is seriously confused by the folks over there. 20:19 < dgilmore> it really doesnt 20:19 < dgilmore> they currently have a box they give out accounts on 20:19 < f13> and really, all they have to do is *ask* 20:19 < f13> but we've seen evidence of where that just doesn't happen 20:19 < dgilmore> but there are concerns its not as secure as it could be 20:19 * ValHolla wonders if it wouldn't be a good Idea to create #fedora-OLPC and try to have some of us in there for the OLPC to ask questions to 20:20 < dgilmore> ValHolla: it exists already 20:20 < dgilmore> well #fedora-olpc 20:21 < dgilmore> they are doing a better job of asking for help, than has been the case in the past 20:21 < ValHolla> dgilmore: ok, well a specific channel the OLPC folks know they can go to for a quick answer/tutorial on what they are doing? 20:21 < ValHolla> if they get stuck using mock, koji etc... 20:21 < wakko666> ValHolla: like #fedora, or #koji, or #fedora-admin? 20:21 < dgilmore> ValHolla: they usually come to me and I point them in the right direction. 20:22 < dgilmore> #fedora-devel 20:22 < dgilmore> there are quite a few olpc folks in #fedora-devel 20:22 < ValHolla> yes like those.... but there are so many different places to go. 20:22 < dgilmore> perhaps what we can do is help them with kickstart files, FAS help, etc 20:23 < dgilmore> help get an environment setup where they could rebuild the box that is used by people to test builds and play with things on a regular basis 20:24 -!- stickster_afk is now known as stickster 20:24 < dgilmore> help them to understand fas 20:24 < ValHolla> roughly how large an image do they use? will it all fit on a single dvd? 20:24 < dgilmore> and help get it implemented 20:24 < ValHolla> make them a "Live CD on steroids" 20:24 < dgilmore> ValHolla: image for what? 20:25 < ValHolla> kickstart image 20:25 * ValHolla is throwing solaris terms around ... sorry 20:25 < dgilmore> ValHolla: well it would need to be a developer spin of sorts 20:26 < nokia3510> I'd ask where Fedora-related stuff ends and strict OLPC particularities appear 20:26 < dgilmore> having fedora-packager gcc rpm-build etc installed 20:26 < nokia3510> because it seems to be a big overlap 20:26 -!- warren [n=warren at redhat/wombat/warren] has quit "Leaving" 20:26 < dgilmore> nokia3510: there are a few things in OLPC that can not be in fedora 20:26 < dgilmore> but most of it really should be built in fedora 20:27 -!- TopoMorto [n=TopoMort at 151.61.153.118] has quit "Sto andando via" 20:27 < dgilmore> anyways. lets move on 20:27 < nokia3510> ok 20:28 < dgilmore> feel free to make comments in the ticket with ideas 20:28 -!- dgilmore changed the topic of #fedora-meeting to: Fedora Infrastructure - Open Floor 20:28 < dgilmore> anyone have anything they would like to bring up? 20:29 < SmootherFrOgZ> what about hosting request ? 20:29 < dgilmore> SmootherFrOgZ: which hosting request? 20:29 -!- LetoTo1 [n=paul at 76-10-173-74.dsl.teksavvy.com] has joined #fedora-meeting 20:29 < dgilmore> SmootherFrOgZ: OLPC's? 20:29 < SmootherFrOgZ> nope 20:30 < SmootherFrOgZ> seth ask few weeks ago, that fp.o was looking for more hosting place 20:30 < dgilmore> skvidal: ^^^ 20:30 < skvidal> we're always looking for more hosting locations 20:31 < skvidal> we found some new space w/ibiblio 20:31 < skvidal> very kindly of them 20:31 < ricky> So torrent server there? 20:31 -!- dwmw2_gone is now known as dwmw2_HIO 20:31 < skvidal> ricky: xen host there 20:31 < skvidal> torrent will be on it 20:31 < SmootherFrOgZ> :), skvidal can you draft me details about what fp.o is looking for 20:31 < ricky> Niice 20:31 < skvidal> SmootherFrOgZ: mmcgrath has a better background in what's needed 20:31 < skvidal> ricky: iirc the box has been ordered 20:32 < SmootherFrOgZ> actually, our hosting sevice need more details to reply on that 20:32 < SmootherFrOgZ> service* 20:32 < ricky> Coolnsess 20:32 < skvidal> SmootherFrOgZ: but the gist is 1-2U +power +network 20:32 < ricky> **Coolness 20:32 < skvidal> SmootherFrOgZ: ideally, a serial console and the ability to power off/on the machine 20:32 < skvidal> SmootherFrOgZ: though we're willing to work with various amount of other things 20:32 < dgilmore> SmootherFrOgZ: or an easy way to get it handled 20:32 < ricky> Non-blocked ports are usually good 20:33 < SmootherFrOgZ> k 20:33 < skvidal> ricky: +1 :) 20:33 < dgilmore> disk is good to 20:33 < skvidal> dgilmore: well, normally we can provide the box 20:33 < skvidal> if we can get the space 20:33 < dgilmore> skvidal: true. 20:34 < dgilmore> we have some hosting that is rack space+power+network. we provide servers. we also have some where servers are provided 20:34 < dgilmore> depends on whats on offere 20:34 < dgilmore> offer 20:35 < skvidal> nod 20:35 < skvidal> SmootherFrOgZ: does that help? 20:36 -!- JSchmitt [n=s4504kr at fedora/JSchmitt] has quit "Konversation terminated!" 20:36 < SmootherFrOgZ> yep, thanks 20:37 < dgilmore> moving on 20:37 < abadger1999> I'm going to be at a memorial service tomorrow. Out all day. I'll probably be *very* spotty on the weekend as well with all the relatives in town. 20:37 -!- stickster is now known as stickster_afk 20:37 -!- stickster_afk is now known as stickster 20:37 < dgilmore> abadger1999: :) ok 20:37 * dgilmore will be updating koji to 1.2.6 20:38 -!- bzbot is now known as buggbot 20:38 < ricky> Any thoughts about upgrading postgres on db2? 20:38 < dgilmore> so we will need to look and see if we start hitting bugs. 20:38 < dgilmore> abadger1999: ^ 20:38 < dgilmore> ricky: im for it. 20:38 < abadger1999> I'd like to do it ASAP. 20:38 < SmootherFrOgZ> :) 20:38 < skvidal> abadger1999: :( 20:38 < abadger1999> mmcgrath: Thoughts on when we can do that? 20:38 < dgilmore> from my use of 8.3 its much better than 8.1 20:38 < ricky> No rush or anything, just wondering when it can go down (did we ever end up scheduling an outage for it?) 20:39 < ricky> dgilmore: That's really good to hear :-) 20:39 < mmcgrath> abadger1999: just need someone to do it. I can try to do it next week sometime 20:39 < SmootherFrOgZ> mmcgrath: i can give you a hand on that 20:39 < abadger1999> mmcgrath: k. I can help with the data manipulation. It's just dumping the data on one box and loading on another. 20:40 -!- mbacovsk_ [n=mbacovsk at nat/redhat/x-574ae97d3509588a] has joined #fedora-meeting 20:40 < mmcgrath> SmootherFrOgZ: thanks. I'm hoping it will be pretty straight forward but I'll make sure you can be around the night of. 20:40 < mmcgrath> we have a staging box now too so hopefully that will make things nice and clean :) 20:40 < ricky> abadger1999: Does it necessarily need to be on different boxes? 20:40 < abadger1999> ricky: Could be the same box even. 20:40 < nokia3510> can I help too ? 20:40 < ricky> Actually, I guess it could be good to test the postgres 8.3 manifest as well 20:40 < abadger1999> It's easier for reverting if they're separate boxes. 20:40 < ricky> And there's waay less data to transfer each time, I forgot 20:41 < SmootherFrOgZ> mmcgrath: no pb 20:41 < ricky> mmcgrath: So how will staging play into this? 20:42 < mmcgrath> ricky: we'll run it there first, if it works fine we'll run it in production 20:42 < ricky> Cool. 20:43 < ricky> Also, any update on the mod_wsgi mirrorlist? 20:43 < ricky> Is it close to ready? 20:43 < abadger1999> I think mdomsch just wanted people to test his new code. 20:43 -!- greenlion [n=greenlio at 93-80-108-19.broadband.corbina.ru] has quit Remote closed the connection 20:44 < abadger1999> lmacken: If you're still around, did you get a chance to do that? 20:44 < ricky> Ah, so it's fully running on staging right now? 20:44 < ricky> Anybody have a URL handy? 20:44 < ricky> Ah, I guess http://mirrors.stg.fedoraproject.org/mirrorlist 20:45 < lmacken> abadger1999: nope, I haven't had time to do anything other than a basic sanity check on it 20:45 -!- mbacovsk__ [n=mbacovsk at okr2fw.topnet.cz] has quit Read error: 104 (Connection reset by peer) 20:46 < abadger1999> ricky: In the same vein, I heard you switched trac over to mod_wsgi? 20:46 < ricky> I haven't yet, actually 20:46 < abadger1999> Okay. 20:46 < ricky> I only did moin, but I want to look into trac soon 20:46 < abadger1999> Cool. 20:46 < dgilmore> mmcgrath: want to give an update on staging? 20:46 < ricky> I'll hopefully have a bit to look at it tonight or tomorrow night 20:46 < abadger1999> I want to convert the bzr web viewer to loggerhead... the new version is a wsgi app so when trac switches I try to deploy that. 20:47 < mmcgrath> dgilmore: sure, I can give a quick one. 20:47 < ricky> Nice 20:47 < abadger1999> (And then the code will actually be maintained upstream :-) 20:47 < mmcgrath> right now we have an app1.stg, app2.stg, proxy1.stg and db1.stg. The staging environment can't contact any production hardware except for /accounts/ and the infrastructure repo. 20:47 < mmcgrath> Matt is giving it a try for some actual work, I'm going to continue documenting it and will hold training at some point in the future (separate from the puppet training) 20:48 < dgilmore> :) 20:48 < lmacken> excellent 20:48 -!- mbacovsk__ [n=mbacovsk at okr2fw.topnet.cz] has joined #fedora-meeting 20:48 < dgilmore> when is puppet training again? 20:48 < mmcgrath> haven't schedule it yet. 20:48 < mmcgrath> its coming though 20:48 < dgilmore> ok 20:49 < dgilmore> If somoene wants to help with some things. I wantto design a way to load balance koji 20:49 < SmootherFrOgZ> dgilmore: go on 20:50 < ricky> As in kojihub? 20:50 * ricky wonders what kind of locking would need to happen 20:50 < dgilmore> ricky: locking is all in the db 20:50 < ricky> Oh, cool. 20:51 < dgilmore> SmootherFrOgZ: either setting up haproxy, pound, or something like that to do load balancing 20:51 -!- warren [n=warren at redhat/wombat/warren] has joined #fedora-meeting 20:51 < ricky> Oh, so it's 100% doing the balancing (as in, the code doesn't really need to change?) 20:51 < dgilmore> so we can do pretty much all maintainence without koji going down. coping with spikes. taking a box off to test something etc 20:52 < ricky> So would we build a separate proxy box just for koji and put it in front of koji1 and koji2 then? 20:52 < dgilmore> ricky: yeah. 20:52 < SmootherFrOgZ> dgilmore: interesting, haproxy is pretty good 20:52 < dgilmore> ricky: or pound would need two boxes 20:53 < ricky> So both pound and haproxy would handle SSL stuff easily, right? 20:53 < dgilmore> ricky: it should. we would need to test it first. 20:53 < ricky> Yeah. 20:54 < SmootherFrOgZ> yeah haproxy handle that well 20:54 < ricky> I wonder if we'd want koji + a builder in staging 20:54 < dgilmore> ricky: we should. 20:54 < ricky> But that sounds really complicated to setup 20:54 < dgilmore> i do my testing of koji on sparc.koji.fedoraproject.org 20:55 < dgilmore> mostly i want to remove the spof in the buildsys 20:55 < dgilmore> so i dont know how well haproxy would help 20:55 < ricky> Hm. 20:55 < dgilmore> since it would replace the spof 20:56 < dgilmore> pound having two boxes. one active, one passive would do it 20:56 < dgilmore> but it needs thought and testing 20:56 -!- wfp [n=wfp5p at viridian.itc.Virginia.EDU] has quit "Leaving" 20:56 < dgilmore> also something that I need help with is dogtag 20:57 < dgilmore> getting it to build in mock. so we can look at migrating the CA to it 20:57 < dgilmore> thats going to need alot of testing. 20:57 < ricky> Yeah, I'll try to ping you about that when I have some more itme 20:57 < ricky> **time 20:57 < mmcgrath> dgilmore: if we're going to load balance it we should probably just put them behind the hardware firewall we have at RH, if not maybe just do heartbeat. 20:57 < dgilmore> when we switch we have to do some funkyness to migrate from the existing CA 20:58 < dgilmore> mmcgrath: id be ok with either 20:58 < mmcgrath> I'm not sure we want to put koji behind our proxy farm thats shared with the other webservers, and doing a dedicated frontend would take our koji server from 1 to 4 (2 koji, 2 proxy) which we could do but I think its probably easier just to use the balancer thats there. 20:58 < dgilmore> mmcgrath: though id kinda prefer load balancing 20:58 * ValHolla wonders if you use pound the setup could be used for more then just koji 20:59 -!- mccann [n=jmccann at 66.187.234.199] has quit "See ya" 20:59 < dgilmore> ValHolla: we try and keep buildsys seperate from everything else 20:59 < ricky> I guess we don't have very much control over the load balancer between fedoraproject.org and proxy1/2? 20:59 < mmcgrath> dgilmore: yeah, use the front end load balancer then. we'll have two backend servers and the balancer on front. 20:59 < mmcgrath> ricky: yeah its all by request 20:59 < dgilmore> mmcgrath: works for me 21:00 < mmcgrath> really though its been pretty solid so I haven't complained about it. 21:00 < ValHolla> digilmore: yeah I guess that is a good idea:/ 21:00 -!- ldimaggi___ [n=ldimaggi at nat/redhat/x-6a2313ae23860d09] has quit "Leaving" 21:00 < dgilmore> so thats some things for thought 21:00 < dgilmore> Anyone have anything else to talk about? 21:00 -!- mbacovsk_ [n=mbacovsk at nat/redhat/x-574ae97d3509588a] has quit Connection timed out 21:00 < dgilmore> if not ill wrap up in 30 21:01 < dgilmore> 20 21:01 < dgilmore> 10 21:01 -!- brothers [n=brothers at 66-234-43-147.nyc.cable.nyct.net] has left #fedora-meeting [] 21:01 < dgilmore> --meeting wrap-- thanks all -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mmcgrath at redhat.com Fri Sep 12 16:13:49 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 12 Sep 2008 11:13:49 -0500 (CDT) Subject: Beta Freeze Message-ID: Hey guys the beta freeze is going into affect tomorrow. It will end on 2008-09-24. This is the first pre-release freeze type we've had here's a link: http://fedoraproject.org/wiki/Infrastructure/SOP/Release#Change_Freeze Just a reminder... DON'T go making changes to machines that are on that list after tomorrow. -Mike From henriquecsj at gmail.com Fri Sep 12 16:40:36 2008 From: henriquecsj at gmail.com (Henrique Junior) Date: Fri, 12 Sep 2008 09:40:36 -0700 (PDT) Subject: About the recent invasion Message-ID: <601448.82999.qm@web45513.mail.sp1.yahoo.com> Hello, guys I'm sorry if this list is not the right place to post this question but I can't figure a better place. As a Fedora ambassador (in Brazil) I've been asked by a lot of people about the recent invasion in our servers. The question I've been asked yesterday was ?how it happened?? I'd like to explain here exactly what happened to make our users more comfortable and confident. Please excuse my bad english. Thanks Henrique "LonelySpooky" Junior ________________________________ "In a world without walls and fences, who needs windows and gates?!" Novos endere?os, o Yahoo! que voc? conhece. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com. http://br.new.mail.yahoo.com/addresses From stickster at gmail.com Fri Sep 12 16:59:43 2008 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 12 Sep 2008 16:59:43 +0000 Subject: About the recent invasion In-Reply-To: <601448.82999.qm@web45513.mail.sp1.yahoo.com> References: <601448.82999.qm@web45513.mail.sp1.yahoo.com> Message-ID: <1221238783.10226.163.camel@localhost.localdomain> On Fri, 2008-09-12 at 09:40 -0700, Henrique Junior wrote: > Hello, guys > I'm sorry if this list > is not the right place to post this question but I can't figure a > better place. > As a Fedora ambassador > (in Brazil) I've been asked by a lot of people about the recent > invasion in our servers. The question I've been asked yesterday was > ?how it happened?? > I'd like to explain > here exactly what happened to make our users more comfortable and confident. > Please excuse my bad english. Hello Henrique. You can refer to the following announcement for the most recent update: http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012.html This is an ongoing investigation, and we'll provide another update as soon as more information is available. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 henriquecsj at gmail.com Fri Sep 12 17:15:19 2008 From: henriquecsj at gmail.com (Henrique Junior) Date: Fri, 12 Sep 2008 10:15:19 -0700 (PDT) Subject: Res: About the recent invasion Message-ID: <311404.99426.qm@web45509.mail.sp1.yahoo.com> Thank you, paul. I'll spread the announcement. Henrique "LonelySpooky" Junior ________________________________ "In a world without walls and fences, who needs windows and gates?!" ----- Mensagem original ---- > De: Paul W. Frields > Para: Fedora Infrastructure > Enviadas: Sexta-feira, 12 de Setembro de 2008 13:59:43 > Assunto: Re: About the recent invasion > > On Fri, 2008-09-12 at 09:40 -0700, Henrique Junior wrote: > > Hello, guys > > I'm sorry if this list > > is not the right place to post this question but I can't figure a > > better place. > > As a Fedora ambassador > > (in Brazil) I've been asked by a lot of people about the recent > > invasion in our servers. The question I've been asked yesterday was > > ?how it happened?? > > I'd like to explain > > here exactly what happened to make our users more comfortable and confident. > > Please excuse my bad english. > > Hello Henrique. You can refer to the following announcement for the > most recent update: > http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012.html > > This is an ongoing investigation, and we'll provide another update as > soon as more information is available. > > -- > Paul W.. Frields > gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 > http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ > irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug Novos endere?os, o Yahoo! que voc? conhece.. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com. http://br.new.mail.yahoo.com/addresses From dennis at ausil.us Sat Sep 13 02:28:12 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 12 Sep 2008 21:28:12 -0500 Subject: Outage Notification - 2008-09-13 01:00 UTC In-Reply-To: <200809101211.12685.dennis@ausil.us> References: <200809101211.12685.dennis@ausil.us> Message-ID: <200809122128.19013.dennis@ausil.us> On Wednesday 10 September 2008 12:11:07 pm Dennis Gilmore wrote: > There will be an outage starting at Y2008-09-13 01:00 UTC, which will > last approximately 1 hour. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/Infrastructure/UTCHowto > or run: > > date -d '2008-09-13 01:00 UTC' > > Affected Services: > Buildsystem > > Unaffected Services: > Websites > Database > CVS / Source Control > DNS > Mail > Torrent > > > Ticket Link: > https://fedorahosted.org/fedora-infrastructure/ticket/830 > > Reason for Outage: > update koji to 1.2.6. it will enable us to turn garbage collection back > on. > > Contact Information: > > Please join #fedora-admin in irc.freenode.net or respond to this email > to track > the status of this outage. This work has been completed, all build services restored. Please report any unusual things that you see. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From ivazqueznet at gmail.com Sat Sep 13 10:57:18 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sat, 13 Sep 2008 06:57:18 -0400 Subject: [Fwd: download.fedoraproject.org mirrors problem] Message-ID: <1221303438.27183.145.camel@ignacio.lan> For your consideration. -------- Forwarded Message -------- From: George Billios To: webmaster at fedoraproject.org Subject: download.fedoraproject.org mirrors problem Date: Sat, 13 Sep 2008 09:12:29 +0300 Hello, During the last week I noticed that when trying to access directly download.fedoraproject.org I get automatically redirected to ftp.ntua.gr mirror of fedoraproject, probably accordingly to my ip. The problem is that this mirror is not updated, for example the repo for fedora 9 with the new key was only updated yesterday and as you can see here: http://ftp.ntua.gr/pub/linux/fedora/linux/updates/testing/ there is nothing under testing. Therefore it would be best to disable this redirecting until the repo is up to date. Thank you -------------- 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 Sat Sep 13 15:36:09 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 13 Sep 2008 10:36:09 -0500 Subject: Emergency update to kojiweb.conf Message-ID: <200809131036.16632.dennis@ausil.us> I just made a minor change to kojiweb.conf RewriteRule ^/koji/login$ https://koji.fedoraproject.org/koji/login koji-1.2.6 only allows you to use ssl when logged in. by rewriting the login you end up using https without the change a user would need to go to https before trying to login or they would get a traceback trying to login. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From dennis at ausil.us Sat Sep 13 17:48:14 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 13 Sep 2008 12:48:14 -0500 Subject: Outage Notification - 2008-09-13 01:00 UTC In-Reply-To: <200809122128.19013.dennis@ausil.us> References: <200809101211.12685.dennis@ausil.us> <200809122128.19013.dennis@ausil.us> Message-ID: <200809131248.14678.dennis@ausil.us> On Friday 12 September 2008 09:28:12 pm Dennis Gilmore wrote: > On Wednesday 10 September 2008 12:11:07 pm Dennis Gilmore wrote: > > > > Reason for Outage: > > update koji to 1.2.6. it will enable us to turn garbage collection back > > on. ok as a follow up there are a few quirks/bugs to be looked into. * browsing via ssl without a cert - you can only access https:// if you have a user cert installed in your browser. it would be nice for those that want to use ssl to be able to do so even if they are not a fedora contributor. * fixing it so that construct_url calls will work - the mod_python we have does not have the construct_url function , at the moment it means that the rss feed is broken. as well as login if you directly enter the login url. if you click login/logout it does work. * fixing so you dont get asked over and over for your user cert - while browsing you will be asked frequently to authenticate with your user cert. this has happened for awhile now if you browse using ssl. 1.2.6 now forces ssl browsing while logged in. so its much more obvious. Dennis From ricky at fedoraproject.org Sat Sep 13 20:09:12 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Sat, 13 Sep 2008 16:09:12 -0400 Subject: modules/plague/templates/sync-committers.sh.erb Change Message-ID: <20080913200912.GA15531@sphe.res.cmu.edu> Sorry, I completely forgot we were in a change freeze now. I just pushed a change (diff below) to make the sync-committers script not fail. Should I revert this, or does it look all right? diff --git a/modules/plague/templates/sync-committers.sh.erb b/modules/plague/templates/sync-committers.sh.erb index d3c8e63..4e51d44 100644 --- a/modules/plague/templates/sync-committers.sh.erb +++ b/modules/plague/templates/sync-committers.sh.erb @@ -12,7 +12,7 @@ fi for user in `cat ${users}|cut -d, -f2` do - plague-user-manager.py ${userdb} add $user own_jobs > $cruft 2>&1 + /usr/bin/plague-user-manager ${userdb} add $user own_jobs > $cruft 2>&1 if [ $? != 0 ]; then if ! grep -qi 'already exists' $cruft; then echo "Error adding user $user was:" Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mmcgrath at redhat.com Sat Sep 13 23:18:00 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 13 Sep 2008 18:18:00 -0500 (CDT) Subject: modules/plague/templates/sync-committers.sh.erb Change In-Reply-To: <20080913200912.GA15531@sphe.res.cmu.edu> References: <20080913200912.GA15531@sphe.res.cmu.edu> Message-ID: On Sat, 13 Sep 2008, Ricky Zhou wrote: > Sorry, I completely forgot we were in a change freeze now. I just > pushed a change (diff below) to make the sync-committers script not > fail. Should I revert this, or does it look all right? > > diff --git a/modules/plague/templates/sync-committers.sh.erb b/modules/plague/templates/sync-committers.sh.erb > index d3c8e63..4e51d44 100644 > --- a/modules/plague/templates/sync-committers.sh.erb > +++ b/modules/plague/templates/sync-committers.sh.erb > @@ -12,7 +12,7 @@ fi > > for user in `cat ${users}|cut -d, -f2` > do > - plague-user-manager.py ${userdb} add $user own_jobs > $cruft 2>&1 > + /usr/bin/plague-user-manager ${userdb} add $user own_jobs > $cruft 2>&1 > if [ $? != 0 ]; then > if ! grep -qi 'already exists' $cruft; then > echo "Error adding user $user was:" > I'll +1 it just in case. This could be considered an outage so I think no harm done. -Mike From ricky at fedoraproject.org Sun Sep 14 09:13:10 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Sun, 14 Sep 2008 05:13:10 -0400 Subject: sb2/3 reboot again and weird newkey.newkey directories Message-ID: <20080914091310.GB15531@sphe.res.cmu.edu> sb2/3 randomly rebooted again tonight (the nagios alert about ns1). Sorry, but I never got around to sending a ticket about it. I'll try to get a list of dates/times where this happened together soon. Also, just so this doesn't get lost in the backlog: 09:03:57 < yaneti> http://download.fedora.redhat.com/pub/fedora/linux/updates/8/ 09:04:04 < yaneti> newkey.newkey ? Weird stuff. Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From laxathom at fedoraproject.org Sun Sep 14 09:27:40 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Sun, 14 Sep 2008 11:27:40 +0200 Subject: sb2/3 reboot again and weird newkey.newkey directories In-Reply-To: <20080914091310.GB15531@sphe.res.cmu.edu> References: <20080914091310.GB15531@sphe.res.cmu.edu> Message-ID: <62bc09df0809140227s2c5ebbe3i59fb263728a6b1be@mail.gmail.com> 2008/9/14 Ricky Zhou : > sb2/3 randomly rebooted again tonight (the nagios alert about ns1). > Sorry, but I never got around to sending a ticket about it. I'll try to > get a list of dates/times where this happened together soon. > > Also, just so this doesn't get lost in the backlog: > > 09:03:57 < yaneti> http://download.fedora.redhat.com/pub/fedora/linux/updates/8/ > 09:04:04 < yaneti> newkey.newkey ? > Hm... does this came from the rebuild repo script which rebuild repo trees from previous present dir by adding prefix newkeys ? I also noticed that the css seems broken. -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB From asgeirf at redhat.com Mon Sep 15 06:09:22 2008 From: asgeirf at redhat.com (Asgeir Frimannsson) Date: Mon, 15 Sep 2008 16:09:22 +1000 Subject: Planning a future L10N infrastructure (including Fedora) Message-ID: <200809151609.22916.asgeirf@redhat.com> Hi infrastructure wranglers, (cc transifex-devel) Over the last few months, a few of us involved in Red Hat L10N engineering have discussed how to best ensure we have Localisation Infrastructure and Tools that can serve the needs of Red Hat, JBoss, Fedora and 'upstream' communities in years to come. Let me first describe some of the background and requirements behind this project: Up until now, we have managed translations through version control systems such as CVS, Svn and Git. This has ensured that all contributions are pushed upstream, as we always store translations within the upstream repositories and projects. 'Damned Lies' further gave us a tool to view language-specific translation statistics for modules, branches and releases, as well as convenient information about people, teams and projects. This has been a great help for translators in their work. Dimitris' (and others) work on Transifex has in addition given the translation community a way to submit translations upstream without ever touching a developer-centric version control system, which has been of great help to translators. Some of the immediate needs that could be addressed within the existing framework (some of which are on the Transifex roadmap) are: - Consolidation of Damned Lies and Transifex, allowing retrieving and submitting translations through the same interface - Allowing retrieving and submitting multiple-files at once (e.g. for translating a publican document with many PO files) - Simple workflow on top of Transifex (porting features from Vertimus) - Better usability and easier user registration process (Fedora specific) Transifex is gaining some traction upstream (e.g. within Gnome), and we hope development will continue strong, serving Fedora and potentially other upstream communities. Looking at the bigger picture, some of the core requirements we have identified for Red Hat and community L10N going forward are: - Customizable Translation Workflows and integration with e.g. Content Authoring Workflows - Infrastructure easily adaptable to support new File formats and project types (e.g. OpenOffice formats, CMS formats, DTP formats, Wiki, Dita, Java formats), rather than relying on 'upstream' projects to fit a certain L10N infrastructure. - Managing the life-cycle of a translation project across releases and iterations - Translation Reuse and Terminology Management across projects and iterations - Job management, scoping, tracking and resourcing - Managing and/or Tracking upstream translation projects, pushing changes back upstream. These requirements require a system where the translation lifecycle would be managed within 'Translation Repositories' (similar to e.g. Pootle or Launchpad Translations), rather than directly through e.g. upstream version control systems. With a repository-based approach, we would be able to track and manage changes to a project on a translation unit level, and manage e.g. translation reuse and terminology within and across projects. We could still retain a link with upstream repositories (like with Transifex/Damned Lies). However, this would not be the 'core datamodel', but on a different layer through plug-ins. This link to external repositories could also go beyond traditional version control systems, communicating with external sources like wikis and CMSs. We have evaluated a number of existing open source L10N frameworks and systems, but haven't found any (yet) that stands out or satisfies our needs or requirements as a development platform. Technology-wise, we are aiming to develop a Java-based(!) system, using technology such as JBoss Seam, Hibernate, jBPM and RichFaces. A java based platform will enable us to make best use of internal expertise in these technologies, as well as making use of technology we are developing (as open source) through collaboration with partners in the L10N industry. We hope some of these requirements and ideas will excite some of you, and ultimately lead to something that can be of use to open source communities. While we have certain requirements and goals for this internally within the company, there is no need for this to be an 'internal' Red Hat project, and most of the requirements and needs overlap with those of community projects like Fedora. In other words, by developing this in collaboration with the community from a very early stage, we are more likely to develop something that may be of use to the greater community. Thoughts and comments, all sorts of comments, are very welcome. cheers, asgeir frimannsson (Senior Software Engineer, I18N Engineering, Red Hat APAC) From aph at redhat.com Fri Sep 5 18:57:35 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 05 Sep 2008 19:57:35 +0100 Subject: [fedora-java] Strange build error for classpathx-mail In-Reply-To: <48C17F34.2010207@cora.nwra.com> References: <48C17F34.2010207@cora.nwra.com> Message-ID: <48C1811F.4090003@redhat.com> Orion Poplawski wrote: > Starting looking into updating classpathx-mail to version 1.1.2 (anyone > know of a reason not to?). > > Got a really weird internal compiler error on the ppc64 build: > > > [javac] 1. ERROR in > /builddir/build/BUILD/mail-1.1.2/inetlib-1.1.1/source/org/jpackage/mail/inet/imap/IMAPConnection.java > (at line 0) > [javac] /* > [javac] ^ > [javac] Internal compiler error > [javac] java.lang.NullPointerException > [javac] at org.eclipse.jdt.internal.compiler.looku > [javac] p.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:262) > [javac] at > org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:719) > > [javac] at org.eclipse.jdt.i > [javac] > nternal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:699) > > [javac] at > org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:294) > [javac] at org.eclipse.jdt.internal.com > [javac] > piler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:128) > [javac] at > org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:179) > > [javac] at org.eclipse.jdt.inte > [javac] > rnal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:456) > > [javac] at > org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:510) > > [javac] at > org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:359) > > [javac] at > org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(Compi > > [javac] lationUnitScope.java:435) > [javac] at > org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:736) > [javac] at > org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137) > > [javac] at java.lang.Thread.run(libgcj.so.9) > > > Other arches seemed okay but got cancelled. See: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=809142 > > This was on ppc7. > > > Resubmitted and it built okay (or at least got past this point). This > time on ppc2 > > http://koji.fedoraproject.org/koji/taskinfo?taskID=809169 > > > Fully successful build (if anyone wants to take a look at the package): > > http://koji.fedoraproject.org/koji/taskinfo?taskID=809200 This is probably https://bugzilla.redhat.com/show_bug.cgi?id=459129 Jakub has a patch and we're waiting for gcj to be respun into a new RPM. Andrew. From douglas.furlong at gmail.com Mon Sep 8 20:11:38 2008 From: douglas.furlong at gmail.com (Douglas Furlong) Date: Mon, 8 Sep 2008 21:11:38 +0100 Subject: More puppet training! In-Reply-To: <001801c911e6$6e45fac0$4ad1f040$@com> References: <200809081039.24281.dennis@ausil.us> <001801c911e6$6e45fac0$4ad1f040$@com> Message-ID: <9d9d35230809081311n55cce2cbm8d1839c2a396d988@mail.gmail.com> This is possibly in appropriate. But each time I've read this subject line I keep on seeing "More muppet training", and it's only on the second look I see puppet. It's given me a giggle so I thought I'd share. Sorry for the noise. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From itamar at ispbrasil.com.br Mon Sep 15 22:19:09 2008 From: itamar at ispbrasil.com.br (Itamar - IspBrasil) Date: Mon, 15 Sep 2008 19:19:09 -0300 Subject: About the recent invasion In-Reply-To: <601448.82999.qm@web45513.mail.sp1.yahoo.com> References: <601448.82999.qm@web45513.mail.sp1.yahoo.com> Message-ID: <48CEDF5D.7050506@ispbrasil.com.br> aparentemente foi causado por uma falha no ssh, onde o atacante conseguiu assinar alguns pacotes com as chave's do fedora. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4752 http://lists.centos.org/pipermail/centos-announce/2008-August/015195.html http://rhn.redhat.com/errata/RHSA-2008-0855.html http://www.redhat.com/security/data/openssh-blacklist.html On 9/12/2008 1:40 PM, Henrique Junior wrote: > > Hello, guys > I'm sorry if this list > is not the right place to post this question but I can't figure a > better place. > As a Fedora ambassador > (in Brazil) I've been asked by a lot of people about the recent > invasion in our servers. The question I've been asked yesterday was > ?how it happened?? > I'd like to explain > here exactly what happened to make our users more comfortable and confident. > Please excuse my bad english. > > > Thanks > > Henrique "LonelySpooky" Junior > ________________________________ > "In a world without walls and fences, who needs windows and gates?!" > > > Novos endere?os, o Yahoo! que voc? conhece. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com. > http://br.new.mail.yahoo.com/addresses > > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > > From lmacken at redhat.com Tue Sep 16 00:00:32 2008 From: lmacken at redhat.com (Luke Macken) Date: Mon, 15 Sep 2008 20:00:32 -0400 Subject: sb2/3 reboot again and weird newkey.newkey directories In-Reply-To: <20080914091310.GB15531@sphe.res.cmu.edu> References: <20080914091310.GB15531@sphe.res.cmu.edu> Message-ID: <20080916000032.GF10695@x300> On Sun, Sep 14, 2008 at 05:13:10AM -0400, Ricky Zhou wrote: > sb2/3 randomly rebooted again tonight (the nagios alert about ns1). > Sorry, but I never got around to sending a ticket about it. I'll try to > get a list of dates/times where this happened together soon. > > Also, just so this doesn't get lost in the backlog: > > 09:03:57 < yaneti> http://download.fedora.redhat.com/pub/fedora/linux/updates/8/ > 09:04:04 < yaneti> newkey.newkey ? > > Weird stuff. Yeah, this was caused by a bug in bodhi's dot newkey hack and has been fixed with a patch from Ricky. luke From mmcgrath at redhat.com Tue Sep 16 03:16:06 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 15 Sep 2008 22:16:06 -0500 (CDT) Subject: Planning a future L10N infrastructure (including Fedora) In-Reply-To: <200809151609.22916.asgeirf@redhat.com> References: <200809151609.22916.asgeirf@redhat.com> Message-ID: On Mon, 15 Sep 2008, Asgeir Frimannsson wrote: > Hi infrastructure wranglers, > > (cc transifex-devel) > > Over the last few months, a few of us involved in Red Hat L10N engineering > have discussed how to best ensure we have Localisation Infrastructure and > Tools that can serve the needs of Red Hat, JBoss, Fedora and 'upstream' > communities in years to come. Let me first describe some of the background and > requirements behind this project: > > Up until now, we have managed translations through version control systems > such as CVS, Svn and Git. This has ensured that all contributions are pushed > upstream, as we always store translations within the upstream repositories and > projects. 'Damned Lies' further gave us a tool to view language-specific > translation statistics for modules, branches and releases, as well as > convenient information about people, teams and projects. This has been a great > help for translators in their work. Dimitris' (and others) work on Transifex > has in addition given the translation community a way to submit translations > upstream without ever touching a developer-centric version control system, > which has been of great help to translators. > > Some of the immediate needs that could be addressed within the existing > framework (some of which are on the Transifex roadmap) are: > - Consolidation of Damned Lies and Transifex, allowing retrieving and > submitting translations through the same interface > - Allowing retrieving and submitting multiple-files at once (e.g. for > translating a publican document with many PO files) > - Simple workflow on top of Transifex (porting features from Vertimus) > - Better usability and easier user registration process (Fedora specific) > > Transifex is gaining some traction upstream (e.g. within Gnome), and we hope > development will continue strong, serving Fedora and potentially other > upstream communities. > > Looking at the bigger picture, some of the core requirements we have identified > for Red Hat and community L10N going forward are: > - Customizable Translation Workflows and integration with e.g. Content > Authoring Workflows > - Infrastructure easily adaptable to support new File formats and project > types (e.g. OpenOffice formats, CMS formats, DTP formats, Wiki, Dita, Java > formats), rather than relying on 'upstream' projects to fit a certain L10N > infrastructure. > - Managing the life-cycle of a translation project across releases and > iterations > - Translation Reuse and Terminology Management across projects and iterations > - Job management, scoping, tracking and resourcing > - Managing and/or Tracking upstream translation projects, pushing changes back > upstream. > > These requirements require a system where the translation lifecycle would be > managed within 'Translation Repositories' (similar to e.g. Pootle or Launchpad > Translations), rather than directly through e.g. upstream version control > systems. With a repository-based approach, we would be able to track and > manage changes to a project on a translation unit level, and manage e.g. > translation reuse and terminology within and across projects. We could still > retain a link with upstream repositories (like with Transifex/Damned Lies). > However, this would not be the 'core datamodel', but on a different layer > through plug-ins. This link to external repositories could also go beyond > traditional version control systems, communicating with external sources like > wikis and CMSs. > I'd think much of what you're looking to do could be done in transifex farily easily. I think some of it is already done and being done. > We have evaluated a number of existing open source L10N frameworks and > systems, but haven't found any (yet) that stands out or satisfies our needs or > requirements as a development platform. Technology-wise, we are aiming to > develop a Java-based(!) system, using technology such as JBoss Seam, > Hibernate, jBPM and RichFaces. A java based platform will enable us to make > best use of internal expertise in these technologies, as well as making use of > technology we are developing (as open source) through collaboration with > partners in the L10N industry. > > We hope some of these requirements and ideas will excite some of you, and > ultimately lead to something that can be of use to open source communities. > While we have certain requirements and goals for this internally within the > company, there is no need for this to be an 'internal' Red Hat project, and > most of the requirements and needs overlap with those of community projects > like Fedora. In other words, by developing this in collaboration with the > community from a very early stage, we are more likely to develop something > that may be of use to the greater community. > > Thoughts and comments, all sorts of comments, are very welcome. > Please correct me if I'm reading this wrong but I see "transifex is great or close to it" and "here's how we're going to build our own solution anyway" ? -Mike From ricky at fedoraproject.org Tue Sep 16 04:01:15 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Tue, 16 Sep 2008 00:01:15 -0400 Subject: Change Request: Fix /wikiold/ (r/o moin) Message-ID: <20080916040115.GD11767@sphe.res.cmu.edu> Hi, Rahul reported that /wikiold/ is currently broken, so it looks like we missed some stuff during the rebuild. I wasn't sure if this is considered under the change freeze, so here's the puppet patch I'd like to apply (also, can somebody confirm that the mount for /srv/web/wiki is correct?): Thanks, Ricky From 7a4f9b64fe100dd4eb7de9ad57c98338bf0dd7f7 Mon Sep 17 00:00:00 2001 From: Ricky Zhou Date: Tue, 16 Sep 2008 03:56:43 +0000 Subject: [PATCH] Fix up old moin setup. --- configs/web/applications/moin.wsgi | 11 +++++++++-- manifests/services/fedoraproject.org.pp | 23 ++++++++++++++--------- 2 files changed, 23 insertions(+), 11 deletions(-) diff --git a/configs/web/applications/moin.wsgi b/configs/web/applications/moin.wsgi index 5bd3772..bfd0d86 100644 --- a/configs/web/applications/moin.wsgi +++ b/configs/web/applications/moin.wsgi @@ -1,7 +1,14 @@ -#!/usr/bin/python import sys sys.path.insert(0, '/srv/web/wiki') -from MoinMoin.server.wsgi import moinmoinApp +import logging + +from MoinMoin.server.server_wsgi import WsgiConfig, moinmoinApp + +class Config(WsgiConfig): + logPath = 'moin.log' + +config = Config() application = moinmoinApp + diff --git a/manifests/services/fedoraproject.org.pp b/manifests/services/fedoraproject.org.pp index 5981bf8..80bf50e 100644 --- a/manifests/services/fedoraproject.org.pp +++ b/manifests/services/fedoraproject.org.pp @@ -1,14 +1,5 @@ # Config files for http://fedoraproject.org/ -class fedoraproject-moin-slave { - symlink { '/srv/web/wiki/': - ensure => "/fedora/wiki/" - } - package { 'PyXML': - ensure => present, - } -} - class fedoraproject-moin inherits httpd { include mod_wsgi-package @@ -28,6 +19,20 @@ class fedoraproject-moin inherits httpd { package { 'PyXML': ensure => present, } + + folder { '/srv/web/wiki/': + source => 'blank/', + require => Folder['/srv/web/'], + } + + mount { "/srv/web/wiki": + device => "ntap-fedora1.fedora.phx.redhat.com:/vol/fedora/app/wiki", + fstype => "nfs", + ensure => "mounted", + options => "defaults", + atboot => true + } + } class fedoraproject-proxy inherits httpd { -- 1.5.5.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From a.badger at gmail.com Tue Sep 16 04:45:06 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 15 Sep 2008 21:45:06 -0700 Subject: Change Request: Fix /wikiold/ (r/o moin) In-Reply-To: <20080916040115.GD11767@sphe.res.cmu.edu> References: <20080916040115.GD11767@sphe.res.cmu.edu> Message-ID: <48CF39D2.30400@gmail.com> Ricky Zhou wrote: > Hi, Rahul reported that /wikiold/ is currently broken, so it looks like > we missed some stuff during the rebuild. I wasn't sure if this is > considered under the change freeze, so here's the puppet patch I'd like > to apply (also, can somebody confirm that the mount for /srv/web/wiki is correct?): > > Thanks, > Ricky > +1 I think wikiold falls under Support (which we'd freeze for a final release but not now) or Value Added (it's not something anyone should need but is something they could need.) -Toshio > > From 7a4f9b64fe100dd4eb7de9ad57c98338bf0dd7f7 Mon Sep 17 00:00:00 2001 > From: Ricky Zhou > Date: Tue, 16 Sep 2008 03:56:43 +0000 > Subject: [PATCH] Fix up old moin setup. > > --- > configs/web/applications/moin.wsgi | 11 +++++++++-- > manifests/services/fedoraproject.org.pp | 23 ++++++++++++++--------- > 2 files changed, 23 insertions(+), 11 deletions(-) > > diff --git a/configs/web/applications/moin.wsgi b/configs/web/applications/moin.wsgi > index 5bd3772..bfd0d86 100644 > --- a/configs/web/applications/moin.wsgi > +++ b/configs/web/applications/moin.wsgi > @@ -1,7 +1,14 @@ > -#!/usr/bin/python > import sys > sys.path.insert(0, '/srv/web/wiki') > > -from MoinMoin.server.wsgi import moinmoinApp > +import logging > + > +from MoinMoin.server.server_wsgi import WsgiConfig, moinmoinApp > + > +class Config(WsgiConfig): > + logPath = 'moin.log' > + > +config = Config() > > application = moinmoinApp > + > diff --git a/manifests/services/fedoraproject.org.pp b/manifests/services/fedoraproject.org.pp > index 5981bf8..80bf50e 100644 > --- a/manifests/services/fedoraproject.org.pp > +++ b/manifests/services/fedoraproject.org.pp > @@ -1,14 +1,5 @@ > # Config files for http://fedoraproject.org/ > > -class fedoraproject-moin-slave { > - symlink { '/srv/web/wiki/': > - ensure => "/fedora/wiki/" > - } > - package { 'PyXML': > - ensure => present, > - } > -} > - > class fedoraproject-moin inherits httpd { > include mod_wsgi-package > > @@ -28,6 +19,20 @@ class fedoraproject-moin inherits httpd { > package { 'PyXML': > ensure => present, > } > + > + folder { '/srv/web/wiki/': > + source => 'blank/', > + require => Folder['/srv/web/'], > + } > + > + mount { "/srv/web/wiki": > + device => "ntap-fedora1.fedora.phx.redhat.com:/vol/fedora/app/wiki", > + fstype => "nfs", > + ensure => "mounted", > + options => "defaults", > + atboot => true > + } > + > } > > class fedoraproject-proxy inherits httpd { > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From asgeirf at redhat.com Tue Sep 16 06:16:42 2008 From: asgeirf at redhat.com (Asgeir Frimannsson) Date: Tue, 16 Sep 2008 16:16:42 +1000 Subject: Planning a future L10N infrastructure (including Fedora) In-Reply-To: <200809151609.22916.asgeirf@redhat.com> References: <200809151609.22916.asgeirf@redhat.com> Message-ID: <200809161616.42495.asgeirf@redhat.com> On Mon, Sep 15, 2008 at 10:48 PM, "Sankarshan (????????)" wrote: > > Asgeir Frimannsson wrote: > > > Some of the immediate needs that could be addressed within the existing > > framework (some of which are on the Transifex roadmap) are: > > - Consolidation of Damned Lies and Transifex, allowing retrieving and > > submitting translations through the same interface > > - Allowing retrieving and submitting multiple-files at once (e.g. for > > translating a publican document with many PO files) > > - Simple workflow on top of Transifex (porting features from Vertimus) > > - Better usability and easier user registration process (Fedora specific) > > Which ones are not on Tx roadmap ? And, how are those elements proposed > to be met ? Background: http://groups.google.com/group/transifex- devel/browse_thread/thread/a637310e8ff63555 http://transifex.org/wiki/Development/Roadmap http://transifex.org/roadmap Dimitris is a better person to answer this, but I believe we already have basic statistics support finished in Transifex upstream. Also, I know St?phane Raimbault is involved in integrating the concepts found in Vertimus into Transifex. What the future regarding integration of Damned Lies concepts such as Teams and Releases is, I am not sure. > > Looking at the bigger picture, some of the core requirements we have identified > > for Red Hat and community L10N going forward are: > > - Customizable Translation Workflows and integration with e.g. Content > > Authoring Workflows > > - Infrastructure easily adaptable to support new File formats and project > > types (e.g. OpenOffice formats, CMS formats, DTP formats, Wiki, Dita, Java > > formats), rather than relying on 'upstream' projects to fit a certain L10N > > infrastructure. > > - Managing the life-cycle of a translation project across releases and > > iterations > > - Translation Reuse and Terminology Management across projects and iterations > > - Job management, scoping, tracking and resourcing > > - Managing and/or Tracking upstream translation projects, pushing changes back > > upstream. > > Since Tx is gaining traction with other communities as well, is it > prudent to open the net wider and ask about the requirements from such > communities ? Yes. I would however add that this project is not directly linked with Tx at this point. Dimitris has done a great job in networking with other communities, and have a plan for Tx that goes way beyond Fedora. > > These requirements require a system where the translation lifecycle would be > > managed within 'Translation Repositories' (similar to e.g. Pootle or Launchpad > > Translations), rather than directly through e.g. upstream version control > > systems. With a repository-based approach, we would be able to track and > > manage changes to a project on a translation unit level, and manage e.g. > > translation reuse and terminology within and across projects. We could still > > retain a link with upstream repositories (like with Transifex/Damned Lies). > > However, this would not be the 'core datamodel', but on a different layer > > through plug-ins. This link to external repositories could also go beyond > > traditional version control systems, communicating with external sources like > > wikis and CMSs. > > Does Transifex allow such a set of 'plug-ins' ? If yes, how would one go > about integrating them within the plans of Transifex ? If not, how does > the integration happen ? The existing Transifex handles very different concepts than what is described here, and writing this on top of transifex would be hard. Take for example the 'submission' page, this page is centered around submitting a file to a repository (or to bugzilla, email as a result of Christos' SoC work). In a Repository-model, the 'submit' action would be more about updating the internal state of a project within a repository. To achieve the same 'workflow' as Transifex, an external plugin could then 'listen' to these changes and transparently submit changes upstream (even by interacting with Transifex?). In this sense, the project we are proposing could use the submission logic of Tx, but handle that in the background. There will be little reuse of actual code from Transifex (most of which is UI-Model interaction which is linked with file submission). It is also important to note that the internal format of the repository will not be PO, but a much richer format more similar to e.g. XLIFF, that accommodates features such as change tracking and terminology-annotations within translation units. PO would still be supported as an input format, as well as an intermediate format that is sent to translators using existing PO tools. However, in the long term, we aim to provide translators with richer tools that can make use of the additional meta-data that is part of the repository. Dimitris mentioned on IRC the other day that the concept of a Translation Repository similar to e.g. Pootle had been briefly discussed, and could be part of Transifex in the future. This is exciting news, utilizing Translate Toolkit more is something that could take Tx to the next level quickly. I think Transifex with its existing Roadmap serves a very useful purpose, and we are not trying to 'hijack' that project in any way. In fact, I am also pushing towards putting more resources into transifex development (read between the lines whatever you want here). What we are about to develop is a new way of doing localisation repositories and workflow, more similar to what happens in many commercial tools than what we see in open source communities. I feel a bit 'uneasy' about pushing that onto the Tx roadmap at this stage, and also uneasy about developing such a 'workflow system' in Turbogears. > > We have evaluated a number of existing open source L10N frameworks and > > systems, but haven't found any (yet) that stands out or satisfies our needs or > > requirements as a development platform. Technology-wise, we are aiming to > > develop a Java-based(!) system, using technology such as JBoss Seam, > > Hibernate, jBPM and RichFaces. A java based platform will enable us to make > > best use of internal expertise in these technologies, as well as making use of > > technology we are developing (as open source) through collaboration with > > partners in the L10N industry. > > Can the results of the evaluation be shared ? So the alternatives would be Pootle (Translate Toolkit), and Transifex (Tx+DL+Vertimus), pootle clearly being the more mature from a resource- management perspective. Pootle works with PO, XLIFF and many other formats. Still, it is very limited in its use of e.g. workflow support and translation memory management. One of the main architectural limitations of Translate Toolkit is it's inheritance hierarchy, where all resource-formats (e.g. PO, Properties, XLIFF, TMX) inherit from a base resource class. A 'pivot' format (similar to e.g. XLIFF) with converters to and from the native format is what we're looking for. Nevertheless, Translate Toolkit (and even Damned Lies) has a lot of knowledge vested in it in how to handle specific project types (intltool, gnome-doc-utils, firefox, openoffice). This is reusable across solutions. Feature-wise, it is much more interesting to compare with e.g. Idiom WorldServer and Lionbridge Freeway, which are commercial solutions in the L10N space. cheers, asgeir From asgeirf at redhat.com Tue Sep 16 07:15:17 2008 From: asgeirf at redhat.com (Asgeir Frimannsson) Date: Tue, 16 Sep 2008 17:15:17 +1000 Subject: Planning a future L10N infrastructure (including Fedora) In-Reply-To: <200809161616.42495.asgeirf@redhat.com> References: <200809151609.22916.asgeirf@redhat.com> <200809161616.42495.asgeirf@redhat.com> Message-ID: <200809161715.17314.asgeirf@redhat.com> On Tue, Sep 16, 2008 at 4:32 PM, "Sankarshan (????????)" wrote: > > Thanks for the reasonably detailed response. > > Asgeir Frimannsson wrote: > >> What we are about to develop is a new way of doing localisation repositories >> and workflow, more similar to what happens in many commercial tools than what >> we see in open source communities. I feel a bit 'uneasy' about pushing that >> onto the Tx roadmap at this stage, and also uneasy about developing such a >> 'workflow system' in Turbogears. > > Since this mail was on Tx-devel, for a moment I assumed it alluded to > enhancing or, extending the functionality of Tx. > > Now that you mention that this is a separate effort, I guess the context > is somewhat clear. > >> Feature-wise, it is much more interesting to compare with e.g. Idiom >> WorldServer and Lionbridge Freeway, which are commercial solutions in the L10N >> space. > > Yes, but what you write is a summary. The query I had was - is the > result of the evaluation of the current state-of-the-nation projected on > a future-proposed-state-of-the-nation available for read. A detail > evaluation/assessment report that is. This is knowledge we have acquired internally by members of our team over a long period of time, rather than a requirements-based systematic evaluation of these projects. I for one have e.g. been monitoring e.g. how Translate Toolkit as well as Gnome, KDE, Mozilla and OO.org L10N communities have evolved over the last 3-4 years. Seeing the increasing 'gap' between state-of-the art in this area and current practices, it was not a rocket-science decision (now that we finally have the resources to do something about it). But I fully see your point, a document or white-paper outlining this would be very useful, and something I will investigate if we could provide as the plans go further. cheers, asgeir From asgeirf at redhat.com Tue Sep 16 07:30:58 2008 From: asgeirf at redhat.com (Asgeir Frimannsson) Date: Tue, 16 Sep 2008 17:30:58 +1000 Subject: Planning a future L10N infrastructure (including Fedora) In-Reply-To: References: <200809151609.22916.asgeirf@redhat.com> Message-ID: <200809161730.58581.asgeirf@redhat.com> On Tuesday 16 September 2008 13:16:06 Mike McGrath wrote: > On Mon, 15 Sep 2008, Asgeir Frimannsson wrote: > > Hi infrastructure wranglers, > > > > (cc transifex-devel) > > > > Over the last few months, a few of us involved in Red Hat L10N > > engineering have discussed how to best ensure we have Localisation > > Infrastructure and Tools that can serve the needs of Red Hat, JBoss, > > Fedora and 'upstream' communities in years to come. Let me first > > describe some of the background and requirements behind this project: > > > > Up until now, we have managed translations through version control > > systems such as CVS, Svn and Git. This has ensured that all contributions > > are pushed upstream, as we always store translations within the upstream > > repositories and projects. 'Damned Lies' further gave us a tool to view > > language-specific translation statistics for modules, branches and > > releases, as well as convenient information about people, teams and > > projects. This has been a great help for translators in their work. > > Dimitris' (and others) work on Transifex has in addition given the > > translation community a way to submit translations upstream without ever > > touching a developer-centric version control system, which has been of > > great help to translators. > > > > Some of the immediate needs that could be addressed within the existing > > framework (some of which are on the Transifex roadmap) are: > > - Consolidation of Damned Lies and Transifex, allowing retrieving and > > submitting translations through the same interface > > - Allowing retrieving and submitting multiple-files at once (e.g. for > > translating a publican document with many PO files) > > - Simple workflow on top of Transifex (porting features from Vertimus) > > - Better usability and easier user registration process (Fedora specific) > > > > Transifex is gaining some traction upstream (e.g. within Gnome), and we > > hope development will continue strong, serving Fedora and potentially > > other upstream communities. > > > > Looking at the bigger picture, some of the core requirements we have > > identified for Red Hat and community L10N going forward are: > > - Customizable Translation Workflows and integration with e.g. Content > > Authoring Workflows > > - Infrastructure easily adaptable to support new File formats and project > > types (e.g. OpenOffice formats, CMS formats, DTP formats, Wiki, Dita, > > Java formats), rather than relying on 'upstream' projects to fit a > > certain L10N infrastructure. > > - Managing the life-cycle of a translation project across releases and > > iterations > > - Translation Reuse and Terminology Management across projects and > > iterations - Job management, scoping, tracking and resourcing > > - Managing and/or Tracking upstream translation projects, pushing changes > > back upstream. > > > > These requirements require a system where the translation lifecycle would > > be managed within 'Translation Repositories' (similar to e.g. Pootle or > > Launchpad Translations), rather than directly through e.g. upstream > > version control systems. With a repository-based approach, we would be > > able to track and manage changes to a project on a translation unit > > level, and manage e.g. translation reuse and terminology within and > > across projects. We could still retain a link with upstream repositories > > (like with Transifex/Damned Lies). However, this would not be the 'core > > datamodel', but on a different layer through plug-ins. This link to > > external repositories could also go beyond traditional version control > > systems, communicating with external sources like wikis and CMSs. > > I'd think much of what you're looking to do could be done in transifex > farily easily. I think some of it is already done and being done. > > > We have evaluated a number of existing open source L10N frameworks and > > systems, but haven't found any (yet) that stands out or satisfies our > > needs or requirements as a development platform. Technology-wise, we are > > aiming to develop a Java-based(!) system, using technology such as JBoss > > Seam, Hibernate, jBPM and RichFaces. A java based platform will enable us > > to make best use of internal expertise in these technologies, as well as > > making use of technology we are developing (as open source) through > > collaboration with partners in the L10N industry. > > > > We hope some of these requirements and ideas will excite some of you, and > > ultimately lead to something that can be of use to open source > > communities. While we have certain requirements and goals for this > > internally within the company, there is no need for this to be an > > 'internal' Red Hat project, and most of the requirements and needs > > overlap with those of community projects like Fedora. In other words, by > > developing this in collaboration with the community from a very early > > stage, we are more likely to develop something that may be of use to the > > greater community. > > > > Thoughts and comments, all sorts of comments, are very welcome. > > Please correct me if I'm reading this wrong but I see "transifex is great > or close to it" and "here's how we're going to build our own solution > anyway" ? Yes, "Transifex is great and will continue to serve us". BUT: If you look at the state of the art in L10N outside the typical Linux projects where PO and Gettext rule, you'll notice we are very short on areas like: - Translation Reuse - Terminology Management - Translation Workflow and Project Management - Integration with CMSs. - Richer Translation Tools This is an effort in narrowing that gap, and I can't see that effort work by evolving an existing tool from this 'cultural background'. Yes, we can get some of the way by developing custom solutions for e.g. linking wikis to Transifex for CMS integration, or using e.g. Pootle for web-based translation. But we would still be limited to the core architecture of the intent of the original developers, which is something that would radically slow the project down. That said, I am not talking down Transifex, and the fact that someone in the community has sacrificed a lot and done a great job in getting us this far within Fedora. cheers, asgeir From Pablo.Iranzo at redhat.com Tue Sep 16 10:39:15 2008 From: Pablo.Iranzo at redhat.com (Pablo Iranzo =?ISO-8859-1?Q?G=F3mez?=) Date: Tue, 16 Sep 2008 12:39:15 +0200 Subject: About the recent invasion In-Reply-To: <48CEDF5D.7050506@ispbrasil.com.br> References: <601448.82999.qm@web45513.mail.sp1.yahoo.com> <48CEDF5D.7050506@ispbrasil.com.br> Message-ID: <1221561555.6234.1.camel@iranzo.users.redhat.com> Ola The update came because it seems that 'atacker' was able to sign some openssh packages. This update, as stated is provided just in case there is someone not using RHN to get updated packages. Customers using RHN to get updates were not afected. The errata also states that there's an ongoing investigation. Regards Pablo El lun, 15-09-2008 a las 19:19 -0300, Itamar - IspBrasil escribi?: > aparentemente foi causado por uma falha no ssh, onde o atacante > conseguiu assinar alguns pacotes com as chave's do fedora. > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4752 > > http://lists.centos.org/pipermail/centos-announce/2008-August/015195.html > > http://rhn.redhat.com/errata/RHSA-2008-0855.html > > http://www.redhat.com/security/data/openssh-blacklist.html > > On 9/12/2008 1:40 PM, Henrique Junior wrote: > > > > Hello, guys > > I'm sorry if this list > > is not the right place to post this question but I can't figure a > > better place. > > As a Fedora ambassador > > (in Brazil) I've been asked by a lot of people about the recent > > invasion in our servers. The question I've been asked yesterday was > > ?how it happened?? > > I'd like to explain > > here exactly what happened to make our users more comfortable and confident. > > Please excuse my bad english. > > > > > > Thanks > > > > Henrique "LonelySpooky" Junior > > ________________________________ > > "In a world without walls and fences, who needs windows and gates?!" > > > > > > Novos endere?os, o Yahoo! que voc? conhece. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com. > > http://br.new.mail.yahoo.com/addresses > > > > > > _______________________________________________ > > Fedora-infrastructure-list mailing list > > Fedora-infrastructure-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > > > > > > > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list -- Pablo Iranzo G?mez (Pablo.Iranzo at redhat.com) RHCE/RHCSP/RHCSS Global Profesional Services Consultant Spain Phone: +34 645 01 01 49 (CET/CEST) GnuPG KeyID: 0xFAD3CF0D -- Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B-82 65 79 41 Directores: Michael Cunningham, Charlie Peters y David Owens Direcci?n Registrada: Red Hat S.L., C/ Velazquez 63, Madrid 28001, Espa?a Direcci?n contacto: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, Planta 3?D, 28016 Madrid, Spain -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From itamar at ispbrasil.com.br Tue Sep 16 10:48:30 2008 From: itamar at ispbrasil.com.br (Itamar - IspBrasil) Date: Tue, 16 Sep 2008 07:48:30 -0300 Subject: About the recent invasion In-Reply-To: <1221561555.6234.1.camel@iranzo.users.redhat.com> References: <601448.82999.qm@web45513.mail.sp1.yahoo.com> <48CEDF5D.7050506@ispbrasil.com.br> <1221561555.6234.1.camel@iranzo.users.redhat.com> Message-ID: <48CF8EFE.7050902@ispbrasil.com.br> ele esta dizendo que o atacante conseguiu assinar alguns pacotes do ssh, se estes pacotes fossem colocados na internet em algum mirror qualquer e alguem fizesse um update e instalasse um destes pacotes a maquina estaria hackeada. :-) On 9/16/2008 7:39 AM, Pablo Iranzo G?mez wrote: > Ola > The update came because it seems that 'atacker' was able to sign some > openssh packages. This update, as stated is provided just in case there > is someone not using RHN to get updated packages. Customers using RHN to > get updates were not afected. The errata also states that there's an > ongoing investigation. > > Regards > Pablo > From Pablo.Iranzo at redhat.com Tue Sep 16 11:17:59 2008 From: Pablo.Iranzo at redhat.com (Pablo Iranzo =?ISO-8859-1?Q?G=F3mez?=) Date: Tue, 16 Sep 2008 13:17:59 +0200 Subject: About the recent invasion In-Reply-To: <48CF8EFE.7050902@ispbrasil.com.br> References: <601448.82999.qm@web45513.mail.sp1.yahoo.com> <48CEDF5D.7050506@ispbrasil.com.br> <1221561555.6234.1.camel@iranzo.users.redhat.com> <48CF8EFE.7050902@ispbrasil.com.br> Message-ID: <1221563879.6234.3.camel@iranzo.users.redhat.com> Yes, but not that they 'attacked' Fedora infrastructure using a 'ssh package' signed... there's still no info on how and who ;), just 'what' :) Regards Pablo El mar, 16-09-2008 a las 07:48 -0300, Itamar - IspBrasil escribi?: > ele esta dizendo que o atacante conseguiu assinar alguns pacotes do ssh, > se estes pacotes fossem colocados na internet em algum mirror qualquer e > alguem fizesse um update e instalasse um destes pacotes a maquina > estaria hackeada. > > :-) > > > > On 9/16/2008 7:39 AM, Pablo Iranzo G?mez wrote: > > Ola > > The update came because it seems that 'atacker' was able to sign some > > openssh packages. This update, as stated is provided just in case there > > is someone not using RHN to get updated packages. Customers using RHN to > > get updates were not afected. The errata also states that there's an > > ongoing investigation. > > > > Regards > > Pablo > > > > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list -- Pablo Iranzo G?mez (Pablo.Iranzo at redhat.com) RHCE/RHCSP/RHCSS Global Profesional Services Consultant Spain Phone: +34 645 01 01 49 (CET/CEST) GnuPG KeyID: 0xFAD3CF0D -- Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B-82 65 79 41 Directores: Michael Cunningham, Charlie Peters y David Owens Direcci?n Registrada: Red Hat S.L., C/ Velazquez 63, Madrid 28001, Espa?a Direcci?n contacto: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, Planta 3?D, 28016 Madrid, Spain -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From mmcgrath at redhat.com Tue Sep 16 13:27:27 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 16 Sep 2008 08:27:27 -0500 (CDT) Subject: Change Request: Fix /wikiold/ (r/o moin) In-Reply-To: <48CF39D2.30400@gmail.com> References: <20080916040115.GD11767@sphe.res.cmu.edu> <48CF39D2.30400@gmail.com> Message-ID: On Mon, 15 Sep 2008, Toshio Kuratomi wrote: > Ricky Zhou wrote: > > Hi, Rahul reported that /wikiold/ is currently broken, so it looks like > > we missed some stuff during the rebuild. I wasn't sure if this is > > considered under the change freeze, so here's the puppet patch I'd like > > to apply (also, can somebody confirm that the mount for /srv/web/wiki is correct?): > > > > Thanks, > > Ricky > > > +1 > > I think wikiold falls under Support (which we'd freeze for a final > release but not now) or Value Added (it's not something anyone should > need but is something they could need.) > +1 from me as well, low risk, and it is just a pre-release freeze. -Mike From mmcgrath at redhat.com Tue Sep 16 13:29:32 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 16 Sep 2008 08:29:32 -0500 (CDT) Subject: Planning a future L10N infrastructure (including Fedora) In-Reply-To: <200809161730.58581.asgeirf@redhat.com> References: <200809151609.22916.asgeirf@redhat.com> <200809161730.58581.asgeirf@redhat.com> Message-ID: On Tue, 16 Sep 2008, Asgeir Frimannsson wrote: > > > > > > Thoughts and comments, all sorts of comments, are very welcome. > > > > Please correct me if I'm reading this wrong but I see "transifex is great > > or close to it" and "here's how we're going to build our own solution > > anyway" ? > > Yes, "Transifex is great and will continue to serve us". > > BUT: > > If you look at the state of the art in L10N outside the typical Linux projects > where PO and Gettext rule, you'll notice we are very short on areas like: > - Translation Reuse > - Terminology Management > - Translation Workflow and Project Management > - Integration with CMSs. > - Richer Translation Tools > > This is an effort in narrowing that gap, and I can't see that effort work by > evolving an existing tool from this 'cultural background'. Yes, we can get > some of the way by developing custom solutions for e.g. linking wikis to > Transifex for CMS integration, or using e.g. Pootle for web-based translation. > But we would still be limited to the core architecture of the intent of the > original developers, which is something that would radically slow the project > down. > > That said, I am not talking down Transifex, and the fact that someone in the > community has sacrificed a lot and done a great job in getting us this far > within Fedora. > Correct me if I'm wrong though, instead of forking or adapting or working with upstream, you are talking about doing your own thing right? -Mike From mmcgrath at redhat.com Tue Sep 16 20:17:42 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 16 Sep 2008 15:17:42 -0500 (CDT) Subject: Puppet training Message-ID: Hey guys, i think I'd like to hold puppet training next week on Wed sometime. Which would work best for you guys: 1:00 pm Chicago time 4:00 pm Chicago time. The live training will be identical to this training: http://mmcgrath.fedorapeople.org/puppet/ But will allow for Q and A. The training at that links includes an ogg and takes about a half hour to complete at full speed though if you're new to puppet its worth it to stop in the middle and review some of the topics. If you have any questions or comments about it please let me know. The slideshow is made with openoffice and I made the ogg with audacity. My throat hurts now so I'm going to get some tea :) -Mike From ricky at fedoraproject.org Tue Sep 16 20:50:23 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Tue, 16 Sep 2008 16:50:23 -0400 Subject: Puppet training In-Reply-To: References: Message-ID: <20080916205023.GE11767@sphe.res.cmu.edu> On 2008-09-16 03:17:42 PM, Mike McGrath wrote: > Hey guys, i think I'd like to hold puppet training next week on Wed > sometime. Which would work best for you guys: > > 1:00 pm Chicago time > 4:00 pm Chicago time. 4:00 PM Chicago time for me. Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From pvangundy at gmail.com Tue Sep 16 21:02:03 2008 From: pvangundy at gmail.com (Paul VanGundy) Date: Tue, 16 Sep 2008 17:02:03 -0400 Subject: Puppet training In-Reply-To: <20080916205023.GE11767@sphe.res.cmu.edu> References: <20080916205023.GE11767@sphe.res.cmu.edu> Message-ID: 2008/9/16 Ricky Zhou > On 2008-09-16 03:17:42 PM, Mike McGrath wrote: > > Hey guys, i think I'd like to hold puppet training next week on Wed > > sometime. Which would work best for you guys: > > > > 1:00 pm Chicago time > > 4:00 pm Chicago time. > 4:00 PM Chicago time for me. > > Thanks, > Ricky > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > 4PM Chicago time for me as well. /paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at arcnetworks.biz Tue Sep 16 20:18:54 2008 From: admin at arcnetworks.biz (Anand Capur) Date: Tue, 16 Sep 2008 16:18:54 -0400 Subject: Puppet training In-Reply-To: References: Message-ID: <5d66540b0809161318y34a8729em36715671c29c4138@mail.gmail.com> On Tue, Sep 16, 2008 at 4:17 PM, Mike McGrath wrote: > Hey guys, i think I'd like to hold puppet training next week on Wed > sometime. Which would work best for you guys: > > 1:00 pm Chicago time > 4:00 pm Chicago time. > 4pm chicago time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bretm at redhat.com Tue Sep 16 21:05:37 2008 From: bretm at redhat.com (Bret McMillan) Date: Tue, 16 Sep 2008 17:05:37 -0400 Subject: Puppet training In-Reply-To: References: Message-ID: <48D01FA1.50100@redhat.com> Mike McGrath wrote: > Hey guys, i think I'd like to hold puppet training next week on Wed > sometime. Which would work best for you guys: > > 1:00 pm Chicago time > 4:00 pm Chicago time. > > The live training will be identical to this training: > > http://mmcgrath.fedorapeople.org/puppet/ > > But will allow for Q and A. The training at that links includes an ogg > and takes about a half hour to complete at full speed though if you're new > to puppet its worth it to stop in the middle and review some of the > topics. If you have any questions or comments about it please let me > know. The slideshow is made with openoffice and I made the ogg with > audacity. My throat hurts now so I'm going to get some tea :) I'll tackle the ogg asap, I'm pretty bogged down and won't be able to attend the live sessions :/ --Bret From asgeirf at redhat.com Tue Sep 16 23:23:42 2008 From: asgeirf at redhat.com (Asgeir Frimannsson) Date: Wed, 17 Sep 2008 09:23:42 +1000 Subject: Planning a future L10N infrastructure (including Fedora) In-Reply-To: References: <200809151609.22916.asgeirf@redhat.com> <200809161730.58581.asgeirf@redhat.com> Message-ID: <200809170923.43088.asgeirf@redhat.com> On Tuesday 16 September 2008 23:29:32 Mike McGrath wrote: > On Tue, 16 Sep 2008, Asgeir Frimannsson wrote: > > > > Thoughts and comments, all sorts of comments, are very welcome. > > > > > > Please correct me if I'm reading this wrong but I see "transifex is > > > great or close to it" and "here's how we're going to build our own > > > solution anyway" ? > > > > Yes, "Transifex is great and will continue to serve us". > > > > BUT: > > > > If you look at the state of the art in L10N outside the typical Linux > > projects where PO and Gettext rule, you'll notice we are very short on > > areas like: - Translation Reuse > > - Terminology Management > > - Translation Workflow and Project Management > > - Integration with CMSs. > > - Richer Translation Tools > > > > This is an effort in narrowing that gap, and I can't see that effort work > > by evolving an existing tool from this 'cultural background'. Yes, we can > > get some of the way by developing custom solutions for e.g. linking wikis > > to Transifex for CMS integration, or using e.g. Pootle for web-based > > translation. But we would still be limited to the core architecture of > > the intent of the original developers, which is something that would > > radically slow the project down. > > > > That said, I am not talking down Transifex, and the fact that someone in > > the community has sacrificed a lot and done a great job in getting us > > this far within Fedora. > > Correct me if I'm wrong though, instead of forking or adapting or working > with upstream, you are talking about doing your own thing right? We have a goal of where we want to see L10N infrastructure go, to enable us in the future to provide internal (translators paid by Red Hat) and community translators with tools to increase their productivity as well as better tools to manage the overall L10N process. If there is an 'upstream' that provides this, or a platform on to which we could develop this, then yes, we would consider 'working with upstream' or (in a worst-case-scenario) forking upstream. So to answer your question bluntly, YES - after 4 years involvement in industry and community L10N processes - I believe we can do better. But holding that thought, remember that this is in many ways 'middleware', and making use of e.g. the vast amount of knowledge invested in Translate Toolkit (file format conversions, build tools, QA) makes sense, and I'm not saying 'forget about all that we have invested in tools so far'. In addition, we are pulling in resources from other communities on this (JBoss, people in the L10N industry and academia), so we're not talking about or attempting to pull attention away from Transifex. (If so, we'd at least consider doing it in Python!). Still, we find it very important to develop this in the open and accept ideas and contributions from the wider community, including people in the Fedora infrastructure. Regarding building on top of Transifex, I think it is much better that these two projects 'compliment' each other in the near future. Someone with Dimitris' caliber, character, passion and vision is very rare (only flaw I can see in him is I think he's a Gnome guy, rather than a KDE guy - but I can see beyond that ;) ), and I honestly think it would be both wrong and counter- productive to attempt to 'hijack', fork or radically change core direction and architecture of a project that seems to finally gain traction way beyond the Fedora-circle. cheers, asgeir From asgeirf at redhat.com Tue Sep 16 23:29:04 2008 From: asgeirf at redhat.com (Asgeir Frimannsson) Date: Wed, 17 Sep 2008 09:29:04 +1000 Subject: Planning a future L10N infrastructure (including Fedora) In-Reply-To: References: <200809151609.22916.asgeirf@redhat.com> <200809161730.58581.asgeirf@redhat.com> Message-ID: <200809170929.04765.asgeirf@redhat.com> (forgot to cc tx-devel) On Tuesday 16 September 2008 23:29:32 Mike McGrath wrote: > On Tue, 16 Sep 2008, Asgeir Frimannsson wrote: > > > > Thoughts and comments, all sorts of comments, are very welcome. > > > > > > Please correct me if I'm reading this wrong but I see "transifex is > > > great or close to it" and "here's how we're going to build our own > > > solution anyway" ? > > > > Yes, "Transifex is great and will continue to serve us". > > > > BUT: > > > > If you look at the state of the art in L10N outside the typical Linux > > projects where PO and Gettext rule, you'll notice we are very short on > > areas like: - Translation Reuse > > - Terminology Management > > - Translation Workflow and Project Management > > - Integration with CMSs. > > - Richer Translation Tools > > > > This is an effort in narrowing that gap, and I can't see that effort work > > by evolving an existing tool from this 'cultural background'. Yes, we can > > get some of the way by developing custom solutions for e.g. linking wikis > > to Transifex for CMS integration, or using e.g. Pootle for web-based > > translation. But we would still be limited to the core architecture of > > the intent of the original developers, which is something that would > > radically slow the project down. > > > > That said, I am not talking down Transifex, and the fact that someone in > > the community has sacrificed a lot and done a great job in getting us > > this far within Fedora. > > Correct me if I'm wrong though, instead of forking or adapting or working > with upstream, you are talking about doing your own thing right? We have a goal of where we want to see L10N infrastructure go, to enable us in the future to provide internal (translators paid by Red Hat) and community translators with tools to increase their productivity as well as better tools to manage the overall L10N process. If there is an 'upstream' that provides this, or a platform on to which we could develop this, then yes, we would consider 'working with upstream' or (in a worst-case-scenario) forking upstream. So to answer your question bluntly, YES - after 4 years involvement in industry and community L10N processes - I believe we can do better. But holding that thought, remember that this is in many ways 'middleware', and making use of e.g. the vast amount of knowledge invested in Translate Toolkit (file format conversions, build tools, QA) makes sense, and I'm not saying 'forget about all that we have invested in tools so far'. In addition, we are pulling in resources from other communities on this (JBoss, people in the L10N industry and academia), so we're not talking about or attempting to pull attention away from Transifex. (If so, we'd at least consider doing it in Python!). Still, we find it very important to develop this in the open and accept ideas and contributions from the wider community, including people in the Fedora infrastructure. Regarding building on top of Transifex, I think it is much better that these two projects 'compliment' each other in the near future. Someone with Dimitris' caliber, character, passion and vision is very rare (only flaw I can see in him is I think he's a Gnome guy, rather than a KDE guy - but I can see beyond that ;) ), and I honestly think it would be both wrong and counter- productive to attempt to 'hijack', fork or radically change core direction and architecture of a project that seems to finally gain traction way beyond the Fedora-circle. cheers, asgeir From ianweller at gmail.com Wed Sep 17 02:16:07 2008 From: ianweller at gmail.com (Ian Weller) Date: Tue, 16 Sep 2008 21:16:07 -0500 Subject: Puppet training In-Reply-To: References: Message-ID: <20080917021607.GE27150@gmail.com> On Tue, Sep 16, 2008 at 03:17:42PM -0500, Mike McGrath wrote: > 4:00 pm Chicago time. > Definitely 4:00pm. Of course, I still might not be available at that time though ;) We'll see. -- Ian Weller http://ianweller.org GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 "Technology is a word that describes something that doesn't work yet." ~ Douglas Adams -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From a.badger at gmail.com Wed Sep 17 04:49:56 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 16 Sep 2008 21:49:56 -0700 Subject: Puppet training In-Reply-To: References: Message-ID: <48D08C74.40906@gmail.com> Mike McGrath wrote: > Hey guys, i think I'd like to hold puppet training next week on Wed > sometime. Which would work best for you guys: > > 1:00 pm Chicago time > 4:00 pm Chicago time. > > The live training will be identical to this training: > > http://mmcgrath.fedorapeople.org/puppet/ > > But will allow for Q and A. The training at that links includes an ogg > and takes about a half hour to complete at full speed though if you're new > to puppet its worth it to stop in the middle and review some of the > topics. If you have any questions or comments about it please let me > know. The slideshow is made with openoffice and I made the ogg with > audacity. My throat hurts now so I'm going to get some tea :) > I'll go with the crowd and say 4:00PM but either works for me :-) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From lmacken at redhat.com Wed Sep 17 18:29:12 2008 From: lmacken at redhat.com (Luke Macken) Date: Wed, 17 Sep 2008 14:29:12 -0400 Subject: Puppet training In-Reply-To: <48D08C74.40906@gmail.com> References: <48D08C74.40906@gmail.com> Message-ID: <20080917182912.GF6117@x300.bos.redhat.com> On Tue, Sep 16, 2008 at 09:49:56PM -0700, Toshio Kuratomi wrote: > Mike McGrath wrote: > > Hey guys, i think I'd like to hold puppet training next week on Wed > > sometime. Which would work best for you guys: > > > > 1:00 pm Chicago time > > 4:00 pm Chicago time. > > > > The live training will be identical to this training: > > > > http://mmcgrath.fedorapeople.org/puppet/ > > > > But will allow for Q and A. The training at that links includes an ogg > > and takes about a half hour to complete at full speed though if you're new > > to puppet its worth it to stop in the middle and review some of the > > topics. If you have any questions or comments about it please let me > > know. The slideshow is made with openoffice and I made the ogg with > > audacity. My throat hurts now so I'm going to get some tea :) > > > I'll go with the crowd and say 4:00PM but either works for me :-) Ditto. luke From poelstra at redhat.com Wed Sep 17 19:39:03 2008 From: poelstra at redhat.com (John Poelstra) Date: Wed, 17 Sep 2008 12:39:03 -0700 Subject: [Fwd: bugzilla.redhat.com, hardware.redhat.com Planned Outage | 09-17-2008 - 1700 EDT (-0400)] Message-ID: <48D15CD7.1060203@redhat.com> -------- Original Message -------- Subject: bugzilla.redhat.com, hardware.redhat.com Planned Outage | 09-17-2008 - 1700 EDT (-0400) Date: Wed, 17 Sep 2008 15:00:29 -0400 From: Matthew Schick O U T A G E R E Q U E S T F O R M ===================================== Severity: Severity One (Urgent) Scheduled Date: 09-17-2008 Scheduled Time: 1700 EDT (-0400) Estimated Time Required: 30 minutes Performed By: Engineering Operations People/Groups Impacted: Bugzilla users Site/Services Affected: bugzilla.redhat.com, hardware.redhat.com Impact: Bugzilla and Hardware will be offline briefly. Description: New perl package will be installed to address performance concerns. Mysql servers will be upgraded for bugfixes. From poelstra at redhat.com Thu Sep 18 03:38:38 2008 From: poelstra at redhat.com (John Poelstra) Date: Wed, 17 Sep 2008 20:38:38 -0700 Subject: Fedora 10 Beta Release Planning Meeting Message-ID: <48D1CD3E.4030305@redhat.com> Fedora 10 Beta Release Planning Meeting 2008-09-17 == Invitees == Jonathan Roberts -- Marketing Karsten Wade -- Docs Jesse Keating -- Rel Eng (present) Paul Frields -- FPL (present) Spot Callaway -- FEM (present) John Poelstra -- Organizer (present) Mike McGrath -- Infrastructure (present) Dimitris Glezos -- Translation (present) M?ir?n Duffy -- Art (present) Will Woods -- QA James Laska -- QA (present) Ricky Zhou -- Websites (present) Bill Nottingham -- Development == Meeting Goals == o not intended to be a lengthy meeting o opportunity to quickly go around the "virtual room" to make sure we are all ready for Beta release day o make it easier for us to communicate in real-time across teams on the telephone o John Poelstra also trying to flush out the taskjuggler schedules to reflect the reality of what needs to get done so that future schedules are tighter o Invited a representative from each Fedora group with a role in getting the release out the door == Meeting Notes == === Release Engineering === o Release Engineering is expecting the following on release day 1) announcement with link to page with information about the beta 2) landing zone to drive all the users to --Mike M notes that this page http://get.fedoraproject.org should be used going forward for all releases o All tasks and content for the beta release (for all teams) should be ready the day before release--Monday, September 22, 2008 --need to do a dry run or validate that things (links, content, etc.) are in working order before announcing --meet 1 hour before release and try things out o Future release cycles could be smoother with a buffer between feature freeze and beta freeze --considering during Fedora 11 planning o Consider proposing a set of earlier dates for core packages in the distro to solidify the release earlier. For example: anaconda, yum, rpm, etc. o Consider moving feature freeze to one week before beta freeze so that features don't crash land on the beta freeze date === Documentation === o docs team responsible for content of releases notes o single page release notes --do not get translated o will assist release engineering to help with release announcement o Docs team will need more community participation and help to get the installation guide ready --past contributors will not be able to be as involved this release cycle --waiting for git repo to get online; Mike will help coordinate as needed o https://fedoraproject.org/wiki/Releases/10/Beta/ReleaseNotes === Art Team === o Art team to create banner to point to beta o Art team is still deciding on a final theme and content will not be ready in time to package for the beta --in the future we will target getting new artwork ready and packaged by feature freeze o Art team will work on a count-down timer to be ready at the release of the Preview Release ==== Web Sites Team === o websites team responsible for presentation of get.fedoraproject.org === Marketing & PR === o Paul is working with RHT PR to create press release blog o Also need to do coordination with Jonathan Roberts and the Fedora marketing team === Translation === o Translation deadline pulled in by one week to provide one week between the translation deadline and the final development freeze o Translation of the release notes starts with the preview release o Dimitris is trying to get Red Hat to commit internal resources to help translate release notes for languages that RHT supports --15 languages now supported by Fedora could increase to 30 or 35 o Considered how we could make sure that translations are repacked before before final devel freeze? --use tracker bugs? --Spot is willing to help patrol and look for things that are missing == Next Meeting == o Prepare for Preview Release o Wednesday, October 22, 2008 o 17:00 UTC From sundaram at fedoraproject.org Thu Sep 18 12:50:06 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 18 Sep 2008 18:20:06 +0530 Subject: Fedora 10 Beta Release Planning Meeting In-Reply-To: <48D1CD3E.4030305@redhat.com> References: <48D1CD3E.4030305@redhat.com> Message-ID: <48D24E7E.1050909@fedoraproject.org> John Poelstra wrote: > Fedora 10 Beta Release Planning Meeting > 2008-09-17 > > == Invitees == > Jonathan Roberts -- Marketing > Karsten Wade -- Docs > Jesse Keating -- Rel Eng (present) > Paul Frields -- FPL (present) > Spot Callaway -- FEM (present) > John Poelstra -- Organizer (present) > Mike McGrath -- Infrastructure (present) > Dimitris Glezos -- Translation (present) > M?ir?n Duffy -- Art (present) > Will Woods -- QA > James Laska -- QA (present) > Ricky Zhou -- Websites (present) > Bill Nottingham -- Development Wouldn't it be useful to invite more than person as part of the different groups? Currently it seems a number of people have not attended which leaves that group voice unheard. Rahul From jkeating at redhat.com Thu Sep 18 15:48:09 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 18 Sep 2008 08:48:09 -0700 Subject: Fedora 10 Beta Release Planning Meeting In-Reply-To: <48D24E7E.1050909@fedoraproject.org> References: <48D1CD3E.4030305@redhat.com> <48D24E7E.1050909@fedoraproject.org> Message-ID: <1221752889.14439.28.camel@luminos.localdomain> On Thu, 2008-09-18 at 18:20 +0530, Rahul Sundaram wrote: > > Wouldn't it be useful to invite more than person as part of the > different groups? Currently it seems a number of people have not > attended which leaves that group voice unheard. These are supposed to be representatives from the various groups, who should have had release meetings on their own already and just reporting information back to the other groups. Having a 50 person meeting doesn't work very well. Is this just speculation on your part, or is there an actual issue to talk about? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Thu Sep 18 16:57:26 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 18 Sep 2008 09:57:26 -0700 Subject: Fedora 10 Beta Release Planning Meeting In-Reply-To: <48D24E7E.1050909@fedoraproject.org> References: <48D1CD3E.4030305@redhat.com> <48D24E7E.1050909@fedoraproject.org> Message-ID: <1221757046.14439.34.camel@luminos.localdomain> On Thu, 2008-09-18 at 18:20 +0530, Rahul Sundaram wrote: > Wouldn't it be useful to invite more than person as part of the > different groups? Currently it seems a number of people have not > attended which leaves that group voice unheard. These are supposed to be representatives from the various groups, who should have had release meetings on their own already and just reporting information back to the other groups. Having a 50 person meeting doesn't work very well. Is this just speculation on your part, or is there an actual issue to talk about? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mmcgrath at redhat.com Thu Sep 18 19:38:58 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 18 Sep 2008 14:38:58 -0500 (CDT) Subject: Fedora 10 Beta Release Planning Meeting In-Reply-To: <1221757046.14439.34.camel@luminos.localdomain> References: <48D1CD3E.4030305@redhat.com> <48D24E7E.1050909@fedoraproject.org> <1221757046.14439.34.camel@luminos.localdomain> Message-ID: On Thu, 18 Sep 2008, Jesse Keating wrote: > On Thu, 2008-09-18 at 18:20 +0530, Rahul Sundaram wrote: > > Wouldn't it be useful to invite more than person as part of the > > different groups? Currently it seems a number of people have not > > attended which leaves that group voice unheard. > > These are supposed to be representatives from the various groups, who > should have had release meetings on their own already and just reporting > information back to the other groups. Having a 50 person meeting > doesn't work very well. > > Is this just speculation on your part, or is there an actual issue to > talk about? > Also this wasn't a "direction of Fedora" type meeting its a "Ok art team, we need a banner for the release". "Ok releng, we need to make sure that we use get.fedoraproject.org in the release announcement as the primary location to direct people to" type thing. Mostly we go down the checklist that John's been keeping over the last many releases and we make sure that stuff is getting done and that people aren't wrongfully assuming certain tasks are getting done. -Mike From stickster at gmail.com Fri Sep 19 00:46:13 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 18 Sep 2008 20:46:13 -0400 Subject: Infrastructure update notice Message-ID: <1221785173.6988.7.camel@localhost.localdomain> http://www.redhat.com/archives/fedora-announce-list/2008-September/msg00009.html This notice was slightly delayed for a number of reasons, so I apologize. The return of all our services was more contemporaneous when I drafted it. I wanted to make sure there was a canonical record that we are back to all systems go for infrastructure, websites, and so forth. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 huzaifas at redhat.com Fri Sep 19 02:57:31 2008 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Fri, 19 Sep 2008 08:27:31 +0530 Subject: Puppet training In-Reply-To: References: Message-ID: <48D3151B.6010706@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike McGrath wrote: > Hey guys, i think I'd like to hold puppet training next week on Wed > sometime. Which would work best for you guys: > > 1:00 pm Chicago time > 4:00 pm Chicago time. > wow!. That is midnight for me in APAC, I will go with the ogg instead :) > The live training will be identical to this training: > > http://mmcgrath.fedorapeople.org/puppet/ > > But will allow for Q and A. The training at that links includes an ogg > and takes about a half hour to complete at full speed though if you're new > to puppet its worth it to stop in the middle and review some of the > topics. If you have any questions or comments about it please let me > know. The slideshow is made with openoffice and I made the ogg with > audacity. My throat hurts now so I'm going to get some tea :) > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFI0xUbzHDc8tpb2uURAnooAJwIs9zQ6TMoYtZSecHjgwTZZZgLMQCggh6z tWGAuY0AT3ub5reOf7dFIC8= =yQqS -----END PGP SIGNATURE----- From thinklinux.ssh at gmail.com Fri Sep 19 05:52:57 2008 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Fri, 19 Sep 2008 11:22:57 +0530 Subject: Puppet training In-Reply-To: <48D3151B.6010706@redhat.com> References: <48D3151B.6010706@redhat.com> Message-ID: Sigh!!! I would be out of station talking at a Fedora event. I have to manage from the odp and ogg. :( Thanks for them. -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= From mmcgrath at redhat.com Fri Sep 19 15:36:56 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 19 Sep 2008 10:36:56 -0500 (CDT) Subject: Change request, log compression Message-ID: I'd like to add the 'compress' term to logrotate for http logs on the app servers. App2 is low on disk space right now and it would free up some space. -Mike From sundaram at fedoraproject.org Fri Sep 19 15:37:16 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 19 Sep 2008 21:07:16 +0530 Subject: Fedora 10 Beta Release Planning Meeting In-Reply-To: <20080918130922.GA3802@yoda.jdub.homelinux.org> References: <48D1CD3E.4030305@redhat.com> <48D24E7E.1050909@fedoraproject.org> <20080918130922.GA3802@yoda.jdub.homelinux.org> Message-ID: <48D3C72C.7010600@fedoraproject.org> Josh Boyer wrote: > On Thu, Sep 18, 2008 at 06:20:06PM +0530, Rahul Sundaram wrote: >> John Poelstra wrote: >>> Fedora 10 Beta Release Planning Meeting >>> 2008-09-17 >>> >>> == Invitees == >>> Jonathan Roberts -- Marketing >>> Karsten Wade -- Docs >>> Jesse Keating -- Rel Eng (present) >>> Paul Frields -- FPL (present) >>> Spot Callaway -- FEM (present) >>> John Poelstra -- Organizer (present) >>> Mike McGrath -- Infrastructure (present) >>> Dimitris Glezos -- Translation (present) >>> M?ir?n Duffy -- Art (present) >>> Will Woods -- QA >>> James Laska -- QA (present) >>> Ricky Zhou -- Websites (present) >>> Bill Nottingham -- Development >> Wouldn't it be useful to invite more than person as part of the >> different groups? Currently it seems a number of people have not >> attended which leaves that group voice unheard. > > I'm pretty sure the meeting was public. Was the invitation public? Rahul From mmcgrath at redhat.com Fri Sep 19 15:43:04 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 19 Sep 2008 10:43:04 -0500 (CDT) Subject: Change request, log compression In-Reply-To: References: Message-ID: On Fri, 19 Sep 2008, Mike McGrath wrote: > I'd like to add the 'compress' term to logrotate for http logs on the app > servers. App2 is low on disk space right now and it would free up some > space. > Two other things, I'd like to blow away a directory on app2: /var/tmp/l10n-data/scratchdir/hg/virt-mem.tip and run a cron job as apache cd /srv/web/translation/; make > /dev/null; /usr/bin/python \ update-stats.py >> /var/log/fedora-l10n/update-stats.`date +\%F`.log 2>&1; \ /usr/sbin/tmpwatch --mtime 168 /var/log/fedora-l10n/ can I get two +1's on these 3 things? -Mike From sundaram at fedoraproject.org Fri Sep 19 15:42:16 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 19 Sep 2008 21:12:16 +0530 Subject: Fedora 10 Beta Release Planning Meeting In-Reply-To: <1221757046.14439.34.camel@luminos.localdomain> References: <48D1CD3E.4030305@redhat.com> <48D24E7E.1050909@fedoraproject.org> <1221757046.14439.34.camel@luminos.localdomain> Message-ID: <48D3C858.6080007@fedoraproject.org> Jesse Keating wrote: > On Thu, 2008-09-18 at 18:20 +0530, Rahul Sundaram wrote: >> Wouldn't it be useful to invite more than person as part of the >> different groups? Currently it seems a number of people have not >> attended which leaves that group voice unheard. > > These are supposed to be representatives from the various groups, who > should have had release meetings on their own already and just reporting > information back to the other groups. Having a 50 person meeting > doesn't work very well. > > Is this just speculation on your part, or is there an actual issue to > talk about? I don't see a speculation. I didn't knew about a meeting since the invitation to the meeting doesn't seem to have been made publicly. The meeting minutes show that a few people representative of the groups have not attended. I would have liked to be see someone represent marketing for instance and probably would have attended. If you had send a public invitation and I missed it, please point it out to me? Rahul From Matt_Domsch at dell.com Fri Sep 19 15:48:20 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 19 Sep 2008 10:48:20 -0500 Subject: Change request, log compression In-Reply-To: References: Message-ID: <20080919154820.GC26013@auslistsprd01.us.dell.com> On Fri, Sep 19, 2008 at 10:36:56AM -0500, Mike McGrath wrote: > I'd like to add the 'compress' term to logrotate for http logs on the app > servers. App2 is low on disk space right now and it would free up some > space. +1 -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From skvidal at fedoraproject.org Fri Sep 19 15:45:49 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 19 Sep 2008 11:45:49 -0400 Subject: Change request, log compression In-Reply-To: References: Message-ID: <1221839149.7388.8.camel@rosebud> On Fri, 2008-09-19 at 10:43 -0500, Mike McGrath wrote: > On Fri, 19 Sep 2008, Mike McGrath wrote: > > > I'd like to add the 'compress' term to logrotate for http logs on the app > > servers. App2 is low on disk space right now and it would free up some > > space. > > > +1 to compress (though it concerns me that it might suck more cpu to do it) > Two other things, I'd like to blow away a directory on app2: > > /var/tmp/l10n-data/scratchdir/hg/virt-mem.tip > > and run a cron job as apache > > cd /srv/web/translation/; make > /dev/null; /usr/bin/python \ > update-stats.py >> /var/log/fedora-l10n/update-stats.`date +\%F`.log 2>&1; \ > /usr/sbin/tmpwatch --mtime 168 /var/log/fedora-l10n/ > > can I get two +1's on these 3 things? Has this one been tested? -sv From mmcgrath at redhat.com Fri Sep 19 16:17:59 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 19 Sep 2008 11:17:59 -0500 (CDT) Subject: Change request, log compression In-Reply-To: <1221839149.7388.8.camel@rosebud> References: <1221839149.7388.8.camel@rosebud> Message-ID: On Fri, 19 Sep 2008, Seth Vidal wrote: > On Fri, 2008-09-19 at 10:43 -0500, Mike McGrath wrote: > > On Fri, 19 Sep 2008, Mike McGrath wrote: > > > > > I'd like to add the 'compress' term to logrotate for http logs on the app > > > servers. App2 is low on disk space right now and it would free up some > > > space. > > > > > > > +1 to compress (though it concerns me that it might suck more cpu to do > it) > > > Two other things, I'd like to blow away a directory on app2: > > > > /var/tmp/l10n-data/scratchdir/hg/virt-mem.tip > > > > and run a cron job as apache > > > > cd /srv/web/translation/; make > /dev/null; /usr/bin/python \ > > update-stats.py >> /var/log/fedora-l10n/update-stats.`date +\%F`.log 2>&1; \ > > /usr/sbin/tmpwatch --mtime 168 /var/log/fedora-l10n/ > > > > can I get two +1's on these 3 things? > > Has this one been tested? > The cron job runs pretty regularly anyway, it just needs an update after the hg dir is gone. the virt-mem tip has over a G of kernel images in it from the upstream repo for some reason. -Mike From ricky at fedoraproject.org Fri Sep 19 16:40:22 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Fri, 19 Sep 2008 12:40:22 -0400 Subject: Change request, log compression In-Reply-To: References: Message-ID: <20080919164022.GF30221@sphe.res.cmu.edu> On 2008-09-19 10:43:04 AM, Mike McGrath wrote: > > I'd like to add the 'compress' term to logrotate for http logs on the app > > servers. App2 is low on disk space right now and it would free up some > > space. +1 > Two other things, I'd like to blow away a directory on app2: > > /var/tmp/l10n-data/scratchdir/hg/virt-mem.tip > > and run a cron job as apache > > cd /srv/web/translation/; make > /dev/null; /usr/bin/python \ > update-stats.py >> /var/log/fedora-l10n/update-stats.`date +\%F`.log 2>&1; \ > /usr/sbin/tmpwatch --mtime 168 /var/log/fedora-l10n/ +1 Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Sep 19 16:43:32 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 19 Sep 2008 22:13:32 +0530 Subject: Fedora 10 Beta Release Planning Meeting In-Reply-To: <20080919163455.GA4492@yoda.jdub.homelinux.org> References: <48D1CD3E.4030305@redhat.com> <48D24E7E.1050909@fedoraproject.org> <20080918130922.GA3802@yoda.jdub.homelinux.org> <48D3C72C.7010600@fedoraproject.org> <20080919163455.GA4492@yoda.jdub.homelinux.org> Message-ID: <48D3D6B4.1070408@fedoraproject.org> Josh Boyer wrote: > On Fri, Sep 19, 2008 at 09:07:16PM +0530, Rahul Sundaram wrote: >>>> Wouldn't it be useful to invite more than person as part of the >>>> different groups? Currently it seems a number of people have not >>>> attended which leaves that group voice unheard. >>> I'm pretty sure the meeting was public. >> Was the invitation public? > > I don't know. It doesn't really matter though. See the part of my email > that you cut off in your reply. I think it does matter. If new meetings for Fedora is being organized, invitations MUST be send publicly. I would want to know who is organizing it, where it was held, which date and time, whether others are attending etc. If it is a IRC meeting, where are the logs? You said you are sure the meeting was public. Why do you think that? Rahul From jkeating at redhat.com Fri Sep 19 17:31:16 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 19 Sep 2008 10:31:16 -0700 Subject: Fedora 10 Beta Release Planning Meeting In-Reply-To: <20080919165310.GC4492@yoda.jdub.homelinux.org> References: <48D1CD3E.4030305@redhat.com> <48D24E7E.1050909@fedoraproject.org> <20080918130922.GA3802@yoda.jdub.homelinux.org> <48D3C72C.7010600@fedoraproject.org> <20080919163455.GA4492@yoda.jdub.homelinux.org> <48D3D6B4.1070408@fedoraproject.org> <20080919165310.GC4492@yoda.jdub.homelinux.org> Message-ID: <1221845476.14439.73.camel@luminos.localdomain> On Fri, 2008-09-19 at 12:53 -0400, Josh Boyer wrote: > I was wrong in thinking it was public. It was a phone call, not an IRC > meeting. Just for more fun and confusion, a meeting doesn't have to be on IRC for it to be "public". While this meeting wasn't announced on one of the major lists (for good reason), it was somewhat assumed that if a leader for a group couldn't make it that they would have somebody else go in their steed. Perhaps we'll call that out a bit more clearly next time. These people were sent mail multiple times leading up to the meeting so there was plenty of chance to find an alternative. The release readiness meetings are designed to be very high bandwith information exchanges between the various groups involved with doing releases. Obviously the later releases (preview, final) are more important and have more people involved than the earlier (alpha, beta) ones. It's an exchange of information that each group should already have through through and discussed in lower bandwith higher visibility meetings within each group. The readiness meeting is just like a mini mission control meeting to ensure things go off without a hitch and that those leading the groups and responsible for the functions are aware of whats going on. If nobody from your group showed up, I'm sorry, but we gave them ample time to find a replacement. You can be prepared as these meetings will come up for each major milestone during our development cycle. If you want, we can probably embed this information into the schedule pages that John creates, it's not like those aren't busy enough as they are (: -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Fri Sep 19 18:45:46 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 20 Sep 2008 00:15:46 +0530 Subject: Fedora 10 Beta Release Planning Meeting In-Reply-To: <20080919165310.GC4492@yoda.jdub.homelinux.org> References: <48D1CD3E.4030305@redhat.com> <48D24E7E.1050909@fedoraproject.org> <20080918130922.GA3802@yoda.jdub.homelinux.org> <48D3C72C.7010600@fedoraproject.org> <20080919163455.GA4492@yoda.jdub.homelinux.org> <48D3D6B4.1070408@fedoraproject.org> <20080919165310.GC4492@yoda.jdub.homelinux.org> Message-ID: <48D3F35A.5070600@fedoraproject.org> Josh Boyer wrote: > On Fri, Sep 19, 2008 at 10:13:32PM +0530, Rahul Sundaram wrote: >> Josh Boyer wrote: >>> On Fri, Sep 19, 2008 at 09:07:16PM +0530, Rahul Sundaram wrote: >>>>>> Wouldn't it be useful to invite more than person as part of the >>>>>> different groups? Currently it seems a number of people have not >>>>>> attended which leaves that group voice unheard. >>>>> I'm pretty sure the meeting was public. >>>> Was the invitation public? >>> I don't know. It doesn't really matter though. See the part of my email >>> that you cut off in your reply. >> I think it does matter. If new meetings for Fedora is being organized, >> invitations MUST be send publicly. I would want to know who is >> organizing it, where it was held, which date and time, whether others >> are attending etc. If it is a IRC meeting, where are the logs? You said >> you are sure the meeting was public. Why do you think that? > > I was wrong in thinking it was public. It was a phone call, not an IRC > meeting. Still does not matter, and you still apparently haven't read the > second part of my original reply. I have. My point still stands. If a new Fedora meeting is being held, it should not planned and organized as a secret. It should be announced ahead of time in public so interested people can participate. Even if you don't want others to participate, you can still organize it publicly. The fact that the people someone decided to pick on their own in private, can pull in others doesn't change this. Rahul From sundaram at fedoraproject.org Fri Sep 19 19:16:28 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 20 Sep 2008 00:46:28 +0530 Subject: Fedora 10 Beta Release Planning Meeting In-Reply-To: <20080919185109.GB4545@yoda.jdub.homelinux.org> References: <48D1CD3E.4030305@redhat.com> <48D24E7E.1050909@fedoraproject.org> <20080918130922.GA3802@yoda.jdub.homelinux.org> <48D3C72C.7010600@fedoraproject.org> <20080919163455.GA4492@yoda.jdub.homelinux.org> <48D3D6B4.1070408@fedoraproject.org> <20080919165310.GC4492@yoda.jdub.homelinux.org> <48D3F35A.5070600@fedoraproject.org> <20080919185109.GB4545@yoda.jdub.homelinux.org> Message-ID: <48D3FA8C.1060406@fedoraproject.org> Josh Boyer wrote: > On Sat, Sep 20, 2008 at 12:15:46AM +0530, Rahul Sundaram wrote: >> I have. My point still stands. If a new Fedora meeting is being held, it >> should not planned and organized as a secret. It should be announced > > So those Red Hat budget meetings that control the financial fate of Fedora... > those should be planned in public too right? No but the meeting minutes are not published publicly for such meetings either. The Fedora specific budget details are however published at https://fedoraproject.org/wiki/Accounting https://fedoraproject.org/wiki/CommunityArchitecture/Expenses This I consider to be a very good thing. Or the meetings that were held > to discuss the outage crisis? Here there might have been reasons for secrecy and it would better to let people know that such a meeting is being held even then. I don't see any such requirement for release planning. Should Paul publish his work calendar, given > that he's the Fedora project lead and has Fedora meetings all the time? Since all the other public Fedora meetings are well known, I don't need his work calender. > Seriously, everything is not black and white. You're making entirely too > big of a deal about this because you didn't get invited and someone pissed > in your lemondade Whether I get invited or not is irrelevant and I don't drink lemondate much ;-) I never said I should be invited even once. There is no need to be so petty. You might want to read about what I said completely. My issue is with the way in this meeting is organized and planned in secret and just that. Rahul From mmcgrath at redhat.com Sat Sep 20 02:50:08 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 19 Sep 2008 21:50:08 -0500 (CDT) Subject: app2 disk space Message-ID: Some of you have seen the disk alerts on app2, Looking more closely it seems the host was not built with enough disk space (like was app1). So after the freeze is over I'll rebuild it. It does raise a point about storage for transifex though. Basically each host running transifex (or damned lies, I can't quite remember which) keeps a local copy of every scm as part of its usage. For performance reasons I don't think that will change but its something we'll want to figure out long term. I haven't done the research but in my brain it seems like running something like git/hg/svn/bzr over nfs will cause problems. On the other hand, these aren't upstream repos but local cache so I'm also curious what the harm would be, if they get borked one could just delete the cache and it would repopulate. Thoughts? -Mike From a.badger at gmail.com Sat Sep 20 06:06:37 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 19 Sep 2008 23:06:37 -0700 Subject: app2 disk space In-Reply-To: References: Message-ID: <48D492ED.1050909@gmail.com> Mike McGrath wrote: > Some of you have seen the disk alerts on app2, Looking more closely it > seems the host was not built with enough disk space (like was app1). So > after the freeze is over I'll rebuild it. > > It does raise a point about storage for transifex though. Basically each > host running transifex (or damned lies, I can't quite remember which) > keeps a local copy of every scm as part of its usage. For performance > reasons I don't think that will change but its something we'll want to > figure out long term. I haven't done the research but in my brain it > seems like running something like git/hg/svn/bzr over nfs will cause > problems. > I think the major thing is how the scms do locking. I know that bzr does its own locking in the pack-0.92 format and beyond that does not rely on os level locking (pack-0.92 is the default format in our currently deployed bzr). transifex should only be using subversion working trees which should be fine (although the documentation recomends to turn off subtree checking.) cvs, I'd imagine, would be similar to subversion. git and hg are unknown to me. > On the other hand, these aren't upstream repos but local cache so I'm also > curious what the harm would be, if they get borked one could just delete > the cache and it would repopulate. Thoughts? > I'll leave glezos to answer this. I think the problem area would be if a repository got into some sort of locked state that required us to manually remove it. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From dev at nigelj.com Sat Sep 20 06:45:25 2008 From: dev at nigelj.com (Nigel Jones) Date: Sat, 20 Sep 2008 18:45:25 +1200 Subject: app2 disk space In-Reply-To: References: Message-ID: <1221893125.3433.14.camel@fantail.jnet.net.nz> On Fri, 2008-09-19 at 21:50 -0500, Mike McGrath wrote: > Some of you have seen the disk alerts on app2, Looking more closely it > seems the host was not built with enough disk space (like was app1). So > after the freeze is over I'll rebuild it. > > It does raise a point about storage for transifex though. Basically each > host running transifex (or damned lies, I can't quite remember which) > keeps a local copy of every scm as part of its usage. For performance > reasons I don't think that will change but its something we'll want to > figure out long term. I haven't done the research but in my brain it > seems like running something like git/hg/svn/bzr over nfs will cause > problems. > > On the other hand, these aren't upstream repos but local cache so I'm also > curious what the harm would be, if they get borked one could just delete > the cache and it would repopulate. Thoughts? -1 I'd like to propose a different strategy... Based upon your original e-mail, this is Damned Lies at fault, not Transifex, now I remember a similar issue to this with the initial rebuild of the app servers, Damned Lies wasn't working because the SQLite database didn't exist etc. My problem is that we have at least two copies of the database, SO... I've said this a couple of times before, BUT it'd REALLY be 'nice' to have a machine in PHX that is dedicated for non public facing, yet mission critical tasks (things that happen in the background). This would be Damned Lies checkouts, and Mirror Manager crawls to name a couple. The database could then be shared by NFS (or rsynced) to the app servers to keep it up-to-date. On the other hand, for Damned Lies, it appears we can use mysql as the backend instead of SQLite (at least it's not postgres :)) This way we can hopefully reduce some of our RAM etc needs and also some of our bandwidth needs (one lot of regular checkouts vs two). - Nigel -- Nigel Jones From dimitris at glezos.com Sat Sep 20 22:11:42 2008 From: dimitris at glezos.com (Dimitris Glezos) Date: Sun, 21 Sep 2008 01:11:42 +0300 Subject: Planning a future L10N infrastructure (including Fedora) In-Reply-To: <200809170923.43088.asgeirf@redhat.com> References: <200809151609.22916.asgeirf@redhat.com> <200809161730.58581.asgeirf@redhat.com> <200809170923.43088.asgeirf@redhat.com> Message-ID: <6d4237680809201511o2776eecfv6322b723cedfd7b9@mail.gmail.com> 2008/9/17 Asgeir Frimannsson : > On Tuesday 16 September 2008 23:29:32 Mike McGrath wrote: >> > > >> > > Please correct me if I'm reading this wrong but I see "transifex is >> > > great or close to it" and "here's how we're going to build our own >> > > solution anyway" ? >> > >> > Yes, "Transifex is great and will continue to serve us". >> > >> > BUT: >> > >> > If you look at the state of the art in L10N outside the typical Linux >> > projects where PO and Gettext rule, you'll notice we are very short on >> > areas like: - Translation Reuse >> > - Terminology Management >> > - Translation Workflow and Project Management >> > - Integration with CMSs. >> > - Richer Translation Tools >> > >> > This is an effort in narrowing that gap, and I can't see that effort work >> > by evolving an existing tool from this 'cultural background'. Yes, we can >> > get some of the way by developing custom solutions for e.g. linking wikis >> > to Transifex for CMS integration, or using e.g. Pootle for web-based >> > translation. But we would still be limited to the core architecture of >> > the intent of the original developers, which is something that would >> > radically slow the project down. For the record, I believe these are some fine ideas, which I would like to see added to Transifex as features (eg. through plugins). I have been discussing most of them with people around conferences for the past year. An example: Tx already downloaded all the translation files from upstream projects, so if someone requests a translation file, why not be able to pre-populate it using existing translations from all the other projects (translation reuse)? Also, I should mention that Transifex isn't (and will never be) specific to a particular translation file format (eg. PO) or any translation repository. I'd like to support translation of both PO and XLIFF files. And also support not only VCSs, but CMSs, wiki pages and even arbitrary chunks of text. Transifex's goal is to be a platform to help you manage your translations. >> Correct me if I'm wrong though, instead of forking or adapting or working >> with upstream, you are talking about doing your own thing right? > > We have a goal of where we want to see L10N infrastructure go, to enable us in > the future to provide internal (translators paid by Red Hat) and community > translators with tools to increase their productivity as well as better tools > to manage the overall L10N process. If there is an 'upstream' that provides > this, or a platform on to which we could develop this, then yes, we would > consider 'working with upstream' or (in a worst-case-scenario) forking > upstream. The Translate Toolkit folks are a very friendly bunch, actively maintaining and extending the rich library, and always open to suggestions. Maybe some (if not all) of the features could be done in TT, and the rest that might not fit there, as Python libraries to maximize interoperability and community involvement. I also think that Transifex could serve as the "UI" for a lot of translation-specific tasks. If there's a library that does X, that would help people manage their translations or leverage Transifex's strong points of "I read a lot of repositories" and "I write to some repositories", then we could provide a web wrapper around it. (eg. search for string "X" in all translation files of language "Y", or "mark file as a downstream of and send me an msgmerged file whenever changes". > So to answer your question bluntly, YES - after 4 years involvement in > industry and community L10N processes - I believe we can do better. But > holding that thought, remember that this is in many ways 'middleware', and > making use of e.g. the vast amount of knowledge invested in Translate Toolkit > (file format conversions, build tools, QA) makes sense, and I'm not saying > 'forget about all that we have invested in tools so far'. It might be my poor English or the fact that I usually read long mails at night, but despite the lengthy descriptions I still don't have a clear picture of exactly what problem you'd like to solve, and the reasoning behind the decisions being made. Don't take me wrong -- I think there are some good ideas. But I feel it would be too bad if you guys didn't invest on top of existing tools (TT for file formats, Transifex for file operations and UI, OmegaT for translation memory) or just isolate specific solutionsthat don't fit into other projects in well-defined libraries (do one thing, to it right). Sure, it takes a lot more effort to work *with* other people, but it is usually worth it. :-) -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 smooge at gmail.com Sat Sep 20 23:41:22 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Sat, 20 Sep 2008 17:41:22 -0600 Subject: app2 disk space In-Reply-To: References: Message-ID: <80d7e4090809201641r684a54f3y3612b66b33c343f2@mail.gmail.com> On Fri, Sep 19, 2008 at 8:50 PM, Mike McGrath wrote: > Some of you have seen the disk alerts on app2, Looking more closely it > seems the host was not built with enough disk space (like was app1). So > after the freeze is over I'll rebuild it. > Newbie questions from the peanut gallery :) Do we have standard kickstarts for systems or are they done by hand? How are systems provisioned to be built? Do we use cobbler? Would we be interested in doing so? What is the flight speed of an unladen swallow? > It does raise a point about storage for transifex though. Basically each > host running transifex (or damned lies, I can't quite remember which) > keeps a local copy of every scm as part of its usage. For performance > reasons I don't think that will change but its something we'll want to > figure out long term. I haven't done the research but in my brain it > seems like running something like git/hg/svn/bzr over nfs will cause > problems. > > On the other hand, these aren't upstream repos but local cache so I'm also > curious what the harm would be, if they get borked one could just delete > the cache and it would repopulate. Thoughts? > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From ricky at fedoraproject.org Sun Sep 21 00:18:12 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Sat, 20 Sep 2008 20:18:12 -0400 Subject: app2 disk space In-Reply-To: <80d7e4090809201641r684a54f3y3612b66b33c343f2@mail.gmail.com> References: <80d7e4090809201641r684a54f3y3612b66b33c343f2@mail.gmail.com> Message-ID: <20080921001812.GA5750@sphe.res.cmu.edu> On 2008-09-20 05:41:22 PM, Stephen John Smoogen wrote: > Do we have standard kickstarts for systems or are they done by hand? Yup, we pretty much do a kickstart install, edit /etc/hosts and other networking configs, then run puppet to build a box. Our SOP for doing all of this is publicly available at http://fedoraproject.org/wiki/Infrastructure/SOP/kickstart. > How are systems provisioned to be built? I'm not completely sure what this means - I guess we just look for xen hosts with available resources and build there. > Do we use cobbler? Would we be interested in doing so? I don't think we are now, and I have no idea what kind of interest there is in using it. > What is the flight speed of an unladen swallow? Hehe: http://www.style.org/unladenswallow/ Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mmcgrath at redhat.com Sun Sep 21 05:35:59 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 21 Sep 2008 00:35:59 -0500 (CDT) Subject: app2 disk space In-Reply-To: <20080921001812.GA5750@sphe.res.cmu.edu> References: <80d7e4090809201641r684a54f3y3612b66b33c343f2@mail.gmail.com> <20080921001812.GA5750@sphe.res.cmu.edu> Message-ID: On Sat, 20 Sep 2008, Ricky Zhou wrote: > On 2008-09-20 05:41:22 PM, Stephen John Smoogen wrote: > > Do we have standard kickstarts for systems or are they done by hand? > Yup, we pretty much do a kickstart install, edit /etc/hosts and other > networking configs, then run puppet to build a box. Our SOP for doing > all of this is publicly available at > http://fedoraproject.org/wiki/Infrastructure/SOP/kickstart. > > > How are systems provisioned to be built? > I'm not completely sure what this means - I guess we just look for xen > hosts with available resources and build there. > In our case we have hosts all over the place so it can be different from host to host but the SOP/kickstart mostly handles both virtual guests (the bulk of our kickstarting) as well as the physical hosts. We've got a pxe environment in PHX. > > Do we use cobbler? Would we be interested in doing so? > I don't think we are now, and I have no idea what kind of interest there > is in using it. > Yeah, we don't use cobbler yet. Mostly because of time and need. I'd like to support that project and use it no doubt. But in our case we have very few kickstart files and they're all incredibly basic. As ricky said they do the base install, check to see if any special hosts entries are needed. Then yum update, then yum install puppet, reboot. -Mike From varun.patial at yahoo.com Sun Sep 21 17:17:27 2008 From: varun.patial at yahoo.com (varun patial) Date: Sun, 21 Sep 2008 22:47:27 +0530 (IST) Subject: SFD@NIT Hamirpur In-Reply-To: <6d4237680809201511o2776eecfv6322b723cedfd7b9@mail.gmail.com> Message-ID: <554990.95545.qm@web94612.mail.in2.yahoo.com> Hi All, Yesterday we celebrated software freedom day(SFD) in our college. We didn't expected many people since it being a holiday and also people were off to their home just after periodical exams. even we put the notice just one day before as everyone was busy in periodical. The event consisted of 1. Introduction to glug-nith and campus ambassador program sarted by SunMicrosystem in our college. 2. A detailed step by step installation of fedora 9 and opensolaris build 79. 3. Distibution of opensolaris dvd to everyone. We started at 4:30 in the evening with some 45 people, mostly new faces from 1st year. We started the session with the introduction to glug-nith and the ideology behind it, the opensouce concept and its learn and share philosophy! We had plans of warping up everything within one hour, but people kept pouring in and within half an hour some 65 people were their in the seminar hall! infact three of us had to stand throughout the session as their was no chair left. Student were quite interested and they did come up with lots of basic but interesting question! We covered the the installation of fedora and opensolaris. After that we covered the benefit of linux or rather open source over propitery OS. We have also told them to join glug-nith mailing list In the end we distributed the dvd of opensolaris . It all took more than 2 hours but needless to say it was really great and much more than what we expected. Regards Varun Patial Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/ From asgeirf at redhat.com Mon Sep 22 01:16:20 2008 From: asgeirf at redhat.com (Asgeir Frimannsson) Date: Sun, 21 Sep 2008 21:16:20 -0400 (EDT) Subject: Planning a future L10N infrastructure (including Fedora) In-Reply-To: <26912070.601222045171841.JavaMail.asgeirf@localhost.localdomain> Message-ID: <11204850.621222046051745.JavaMail.asgeirf@localhost.localdomain> Hi Dimitris, Thanks for your comments. ----- "Dimitris Glezos" wrote: > 2008/9/17 Asgeir Frimannsson : > > On Tuesday 16 September 2008 23:29:32 Mike McGrath wrote: > >> > > > >> > > Please correct me if I'm reading this wrong but I see > "transifex is > >> > > great or close to it" and "here's how we're going to build our > own > >> > > solution anyway" ? > >> > > >> > Yes, "Transifex is great and will continue to serve us". > >> > > >> > BUT: > >> > > >> > If you look at the state of the art in L10N outside the typical > Linux > >> > projects where PO and Gettext rule, you'll notice we are very > short on > >> > areas like: - Translation Reuse > >> > - Terminology Management > >> > - Translation Workflow and Project Management > >> > - Integration with CMSs. > >> > - Richer Translation Tools > >> > > >> > This is an effort in narrowing that gap, and I can't see that > effort work > >> > by evolving an existing tool from this 'cultural background'. > Yes, we can > >> > get some of the way by developing custom solutions for e.g. > linking wikis > >> > to Transifex for CMS integration, or using e.g. Pootle for > web-based > >> > translation. But we would still be limited to the core > architecture of > >> > the intent of the original developers, which is something that > would > >> > radically slow the project down. > > For the record, I believe these are some fine ideas, which I would > like to see added to Transifex as features (eg. through plugins). I > have been discussing most of them with people around conferences for > the past year. An example: Tx already downloaded all the translation > files from upstream projects, so if someone requests a translation > file, why not be able to pre-populate it using existing translations > from all the other projects (translation reuse)? > > Also, I should mention that Transifex isn't (and will never be) > specific to a particular translation file format (eg. PO) or any > translation repository. I'd like to support translation of both PO > and > XLIFF files. And also support not only VCSs, but CMSs, wiki pages and > even arbitrary chunks of text. Transifex's goal is to be a platform > to > help you manage your translations. For the record (since XLIFF is mentioned and since I'm part of the Oasis XLIFF Technical Committee), I am not aiming to design anything around XLIFF in this project, other than perhaps support XLIFF is an import/export format for resources in the same way as we support PO (we do have the odd XLIFF file coming through for translation). I don't think XLIFF (1.2) is mature enough yet as a L10N resource format. I know there are some big ideas in transifex. In fact, when transifex is mentioned, often people refer to the *goal/idea* of transifex, rather the actual current implementation. Take for example plugins, transifex doesn't currently have a plugin system, neither does it have workflow, project management, or any concept of translation resources internally. Transifex today is a simple 'file submission system' with a growing community aiming to build it into something more. With this in mind, 'building on top of transifex' really means redefining what transifex really is. For example, 'file submission' should really be a plugin, not a core feature. That means all of transifex today (excluding maybe the login UI), should really be plugins to a core model of projects, people, etc, that currently doesn't exist. Defining this 'model' of a repository doesn't really depend much on the implementation, and in fact many implementations might help push this faster and ensure a better solution (if it was on the tx roadmap in the first place). And it's not like it is impossible for e.g. a java based repository to communicate with Transifex for file submissions, isn't that exactly what the remote-interface of TX (on the roadmap) is supposed to provide? What I'm hearing is "Don't build something new, continue building on the python/tg/transifex architecture", which is fully understandable. However, considering the cost of developing this on top of tx (re-architecture, convincing all that it is the right path to go, immaturity/stability of libraries for e.g. ajax, limited workflow support), I honestly think it's better with two projects that 'compliment' each other. There are more than enough tasks for everyone in the existing Tx roadmap, and the idea is bigger than what a combined development team could accomplish. Diversifying and pulling in good people from e.g. the java-side of things might even help speed things up. > >> Correct me if I'm wrong though, instead of forking or adapting or > working > >> with upstream, you are talking about doing your own thing right? > > > > We have a goal of where we want to see L10N infrastructure go, to > enable us in > > the future to provide internal (translators paid by Red Hat) and > community > > translators with tools to increase their productivity as well as > better tools > > to manage the overall L10N process. If there is an 'upstream' that > provides > > this, or a platform on to which we could develop this, then yes, we > would > > consider 'working with upstream' or (in a worst-case-scenario) > forking > > upstream. > > The Translate Toolkit folks are a very friendly bunch, actively > maintaining and extending the rich library, and always open to > suggestions. Maybe some (if not all) of the features could be done in > TT, and the rest that might not fit there, as Python libraries to > maximize interoperability and community involvement. Yes, I know TT very well, and have discussed the library with Dwayne Bailey (the main visionary behind the project) in the past, even before tx was born. In fact, a django-migration of Pootle (built on top of the TT) has been on the agenda for a while, and combining forces with TT is one of the other options I have been strongly considering for a repository (TT e.g. has a file submission library, and there is a lot of duplication between tt and tx). Looking at the svn activity of TT (in my rss reader), it is definetly a project with a 'dangerous' future. > I also think that Transifex could serve as the "UI" for a lot of > translation-specific tasks. If there's a library that does X, that > would help people manage their translations or leverage Transifex's > strong points of "I read a lot of repositories" and "I write to some > repositories", then we could provide a web wrapper around it. (eg. > search for string "X" in all translation files of language "Y", or > "mark file as a downstream of and send me an msgmerged > file whenever changes". > > > So to answer your question bluntly, YES - after 4 years involvement > in > > industry and community L10N processes - I believe we can do better. > But > > holding that thought, remember that this is in many ways > 'middleware', and > > making use of e.g. the vast amount of knowledge invested in > Translate Toolkit > > (file format conversions, build tools, QA) makes sense, and I'm not > saying > > 'forget about all that we have invested in tools so far'. > > It might be my poor English or the fact that I usually read long > mails > at night, but despite the lengthy descriptions I still don't have a > clear picture of exactly what problem you'd like to solve, and the > reasoning behind the decisions being made. I do understand there is a 'semantic gap' here, and that we do need to provide a better description and demonstration of why a new project is necessary. I do believe everything is theoretically possible to build on top of python/tg and through reuse of concepts in e.g. tx and TT, but I honestly believe if we are going to manage and drive the development effort in this, it is more worthwhile to expand beyond the fedora/python community, and use tools that the core developers would be more comfortable and productive with. This is not a 'we think you guys should develop this' request, we are taking ownership of the project, as well as inviting anyone that is interested in the community to participate and take ownership. > Don't take me wrong -- I think there are some good ideas. But I feel > it would be too bad if you guys didn't invest on top of existing > tools > (TT for file formats, Transifex for file operations and UI, OmegaT > for > translation memory) or just isolate specific solutionsthat don't fit > into other projects in well-defined libraries (do one thing, to it > right). Sure, it takes a lot more effort to work *with* other people, > but it is usually worth it. :-) This is *not* about an effort to avoid working with people. It is an effort to get more people working on this. I know more people in the Java community that is or might be interested in a open source solution for these problems than in the Python/Fedora/TG community. And of course adding to this a portion of my natural bias towards Java, and the fact that the people that would be working on this would initially be much more productive in Java than in Python (TG2 or django). With the fact that we throw this idea out to the fedora/tx community early, please take that as a sign that we are trying to work with the community, rather than simply developing something on our own. And I for one will continue being involved with Tx to some degree, and help out where I can. L10N is an area with a lot of space for improvement, and an area that has sadly been to some extent 'neglected' except for Dimitris' recent work. We still have a long way to go before we have what I would call a L10N infrastructure that serves translators well. cheers, asgeir From dev at nigelj.com Mon Sep 22 13:08:20 2008 From: dev at nigelj.com (Nigel Jones) Date: Tue, 23 Sep 2008 01:08:20 +1200 Subject: Change Request - Elections Message-ID: <1222088900.3367.1.camel@fantail.jnet.net.nz> Technically not directly covered in the Beta Freeze, but it's only running on app4 at the moment and the settings it's on now is okay for the infrequent use of casual browsing, but the Art team want to use it for the next 36 or so hours. Can I get a +1 to bump to the resources used during the FESCo/Board votes? Thanks - Nigel -- Nigel Jones From skvidal at fedoraproject.org Mon Sep 22 13:25:39 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 22 Sep 2008 09:25:39 -0400 Subject: Change Request - Elections In-Reply-To: <1222088900.3367.1.camel@fantail.jnet.net.nz> References: <1222088900.3367.1.camel@fantail.jnet.net.nz> Message-ID: <1222089939.12513.31.camel@rosebud> On Tue, 2008-09-23 at 01:08 +1200, Nigel Jones wrote: > Technically not directly covered in the Beta Freeze, but it's only > running on app4 at the moment and the settings it's on now is okay for > the infrequent use of casual browsing, but the Art team want to use it > for the next 36 or so hours. > > Can I get a +1 to bump to the resources used during the FESCo/Board > votes? Bump them to what? -sv From dev at nigelj.com Mon Sep 22 13:32:23 2008 From: dev at nigelj.com (Nigel Jones) Date: Tue, 23 Sep 2008 01:32:23 +1200 Subject: Change Request - Elections In-Reply-To: <1222089939.12513.31.camel@rosebud> References: <1222088900.3367.1.camel@fantail.jnet.net.nz> <1222089939.12513.31.camel@rosebud> Message-ID: <1222090343.3367.3.camel@fantail.jnet.net.nz> On Mon, 2008-09-22 at 09:25 -0400, Seth Vidal wrote: > On Tue, 2008-09-23 at 01:08 +1200, Nigel Jones wrote: > > Technically not directly covered in the Beta Freeze, but it's only > > running on app4 at the moment and the settings it's on now is okay for > > the infrequent use of casual browsing, but the Art team want to use it > > for the next 36 or so hours. > > > > Can I get a +1 to bump to the resources used during the FESCo/Board > > votes? > > Bump them to what? Err yeah, I boo-booed and forgot to include the diff. diff --git a/configs/web/applications/elections.conf b/configs/web/applications/elections.conf index 387f01f..4a11549 100644 --- a/configs/web/applications/elections.conf +++ b/configs/web/applications/elections.conf @@ -10,8 +10,8 @@ WSGIPythonOptimize 2 # To save resources during periods of no-elections (quite often - ~75% of the time) # We can run less threads and processes. -#WSGIDaemonProcess elections threads=2 processes=4 user=apache display-name=elections -WSGIDaemonProcess elections threads=1 processes=1 user=apache display-name=elections +WSGIDaemonProcess elections threads=2 processes=4 user=apache display-name=elections +#WSGIDaemonProcess elections threads=1 processes=1 user=apache display-name=elections To be fair, it'd most likely be okay running at threads=2 processes=2, but I'm trying to stick with what I've used in the past with the freeze etc. -NJ > > -sv > > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- Nigel Jones From mmcgrath at redhat.com Mon Sep 22 14:26:45 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 22 Sep 2008 09:26:45 -0500 (CDT) Subject: Change Request - Elections In-Reply-To: <1222090343.3367.3.camel@fantail.jnet.net.nz> References: <1222088900.3367.1.camel@fantail.jnet.net.nz> <1222089939.12513.31.camel@rosebud> <1222090343.3367.3.camel@fantail.jnet.net.nz> Message-ID: On Tue, 23 Sep 2008, Nigel Jones wrote: > On Mon, 2008-09-22 at 09:25 -0400, Seth Vidal wrote: > > On Tue, 2008-09-23 at 01:08 +1200, Nigel Jones wrote: > > > Technically not directly covered in the Beta Freeze, but it's only > > > running on app4 at the moment and the settings it's on now is okay for > > > the infrequent use of casual browsing, but the Art team want to use it > > > for the next 36 or so hours. > > > > > > Can I get a +1 to bump to the resources used during the FESCo/Board > > > votes? > > > > Bump them to what? > > Err yeah, I boo-booed and forgot to include the diff. > > diff --git a/configs/web/applications/elections.conf > b/configs/web/applications/elections.conf > index 387f01f..4a11549 100644 > --- a/configs/web/applications/elections.conf > +++ b/configs/web/applications/elections.conf > @@ -10,8 +10,8 @@ WSGIPythonOptimize 2 > > # To save resources during periods of no-elections (quite often - ~75% > of the time) > # We can run less threads and processes. > -#WSGIDaemonProcess elections threads=2 processes=4 user=apache > display-name=elections > -WSGIDaemonProcess elections threads=1 processes=1 user=apache > display-name=elections > +WSGIDaemonProcess elections threads=2 processes=4 user=apache > display-name=elections > +#WSGIDaemonProcess elections threads=1 processes=1 user=apache > display-name=elections > > To be fair, it'd most likely be okay running at threads=2 processes=2, > but I'm trying to stick with what I've used in the past with the freeze > etc. +1 from me. -Mike From lmacken at redhat.com Mon Sep 22 14:35:00 2008 From: lmacken at redhat.com (Luke Macken) Date: Mon, 22 Sep 2008 10:35:00 -0400 Subject: Change Request - Elections In-Reply-To: <1222090343.3367.3.camel@fantail.jnet.net.nz> References: <1222088900.3367.1.camel@fantail.jnet.net.nz> <1222089939.12513.31.camel@rosebud> <1222090343.3367.3.camel@fantail.jnet.net.nz> Message-ID: <20080922143500.GC20649@x300> On Tue, Sep 23, 2008 at 01:32:23AM +1200, Nigel Jones wrote: > On Mon, 2008-09-22 at 09:25 -0400, Seth Vidal wrote: > > On Tue, 2008-09-23 at 01:08 +1200, Nigel Jones wrote: > > > Technically not directly covered in the Beta Freeze, but it's only > > > running on app4 at the moment and the settings it's on now is okay for > > > the infrequent use of casual browsing, but the Art team want to use it > > > for the next 36 or so hours. > > > > > > Can I get a +1 to bump to the resources used during the FESCo/Board > > > votes? > > > > Bump them to what? > > Err yeah, I boo-booed and forgot to include the diff. > > diff --git a/configs/web/applications/elections.conf > b/configs/web/applications/elections.conf > index 387f01f..4a11549 100644 > --- a/configs/web/applications/elections.conf > +++ b/configs/web/applications/elections.conf > @@ -10,8 +10,8 @@ WSGIPythonOptimize 2 > > # To save resources during periods of no-elections (quite often - ~75% > of the time) > # We can run less threads and processes. > -#WSGIDaemonProcess elections threads=2 processes=4 user=apache > display-name=elections > -WSGIDaemonProcess elections threads=1 processes=1 user=apache > display-name=elections > +WSGIDaemonProcess elections threads=2 processes=4 user=apache > display-name=elections > +#WSGIDaemonProcess elections threads=1 processes=1 user=apache > display-name=elections > > To be fair, it'd most likely be okay running at threads=2 processes=2, > but I'm trying to stick with what I've used in the past with the freeze > etc. +1. Looks like a harmless optimization. We may want also want to set a 'maximum-requests' on the WSGIDaemonProcess, as to help mitigate any memory leaks within the stack (as opposed to having to use our restart-memhogs cronjob). Bodhi's is currently set to 1000, but we should probably agree on a sane number and make it consistent throughout our infrastructure. Our TurboGears SOP also needs to be updated to reflect our new WSGI deployments as well. luke From mmcgrath at redhat.com Mon Sep 22 17:00:18 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 22 Sep 2008 12:00:18 -0500 (CDT) Subject: haproxy SOP Message-ID: https://fedoraproject.org/wiki/Infrastructure/SOP/haproxy As most of you know we're slowly migrating from mod_proxy_balancer to haproxy. Just doing an app at a time. here's the haproxy SOP. -Mike From a.badger at gmail.com Mon Sep 22 17:52:13 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 22 Sep 2008 10:52:13 -0700 Subject: Change request: bugfix for packagedb-bzsync Message-ID: <48D7DB4D.2040900@gmail.com> We've got a pair of problems with the packagedb-bugzilla sync script that is keeping bugzilla from being updated with new information that I'd like to deploy. Both are extremely simple (so easy to back out) and both are causing bugzilla to not update. 1) config change. The debug flag was left on when we deployed a new version of the script a few weeks ago. Unfortunately, for this script, debug implies dry_run. So no updates occur while debug is on. 2) one line bugfix. The script was attempting to change a variable containing a fas username into a bugzilla email address twice. This failed on the second attempt since the email address couldn't be found in the username field. This change affects app5 (where the scripts run) and bugzilla. Since the script was hitting pkgdb before (just not updating bugzilla), it shouldn't affect the pkgdb. Can I get two +1's ? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From ricky at fedoraproject.org Mon Sep 22 17:58:54 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Mon, 22 Sep 2008 13:58:54 -0400 Subject: Change request: bugfix for packagedb-bzsync In-Reply-To: <48D7DB4D.2040900@gmail.com> References: <48D7DB4D.2040900@gmail.com> Message-ID: <20080922175854.GA22428@sphe.res.cmu.edu> On 2008-09-22 10:52:13 AM, Toshio Kuratomi wrote: > We've got a pair of problems with the packagedb-bugzilla sync script > that is keeping bugzilla from being updated with new information that > I'd like to deploy. Both are extremely simple (so easy to back out) and > both are causing bugzilla to not update. > > 1) config change. The debug flag was left on when we deployed a new > version of the script a few weeks ago. Unfortunately, for this script, > debug implies dry_run. So no updates occur while debug is on. +1 > 2) one line bugfix. The script was attempting to change a variable > containing a fas username into a bugzilla email address twice. This > failed on the second attempt since the email address couldn't be found > in the username field. +1 Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mmcgrath at redhat.com Mon Sep 22 18:02:05 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 22 Sep 2008 13:02:05 -0500 (CDT) Subject: Change request: bugfix for packagedb-bzsync In-Reply-To: <48D7DB4D.2040900@gmail.com> References: <48D7DB4D.2040900@gmail.com> Message-ID: On Mon, 22 Sep 2008, Toshio Kuratomi wrote: > We've got a pair of problems with the packagedb-bugzilla sync script > that is keeping bugzilla from being updated with new information that > I'd like to deploy. Both are extremely simple (so easy to back out) and > both are causing bugzilla to not update. > > 1) config change. The debug flag was left on when we deployed a new > version of the script a few weeks ago. Unfortunately, for this script, > debug implies dry_run. So no updates occur while debug is on. > +1 > 2) one line bugfix. The script was attempting to change a variable > containing a fas username into a bugzilla email address twice. This > failed on the second attempt since the email address couldn't be found > in the username field. > > This change affects app5 (where the scripts run) and bugzilla. Since > the script was hitting pkgdb before (just not updating bugzilla), it > shouldn't affect the pkgdb. > +1 -Mike From a.badger at gmail.com Mon Sep 22 18:04:49 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 22 Sep 2008 11:04:49 -0700 Subject: Change Request - Elections In-Reply-To: <20080922143500.GC20649@x300> References: <1222088900.3367.1.camel@fantail.jnet.net.nz> <1222089939.12513.31.camel@rosebud> <1222090343.3367.3.camel@fantail.jnet.net.nz> <20080922143500.GC20649@x300> Message-ID: <48D7DE41.4050002@gmail.com> Luke Macken wrote: > On Tue, Sep 23, 2008 at 01:32:23AM +1200, Nigel Jones wrote: >> On Mon, 2008-09-22 at 09:25 -0400, Seth Vidal wrote: >>> On Tue, 2008-09-23 at 01:08 +1200, Nigel Jones wrote: >>>> Technically not directly covered in the Beta Freeze, but it's only >>>> running on app4 at the moment and the settings it's on now is okay for >>>> the infrequent use of casual browsing, but the Art team want to use it >>>> for the next 36 or so hours. >>>> >>>> Can I get a +1 to bump to the resources used during the FESCo/Board >>>> votes? >>> Bump them to what? >> Err yeah, I boo-booed and forgot to include the diff. >> >> diff --git a/configs/web/applications/elections.conf >> b/configs/web/applications/elections.conf >> index 387f01f..4a11549 100644 >> --- a/configs/web/applications/elections.conf >> +++ b/configs/web/applications/elections.conf >> @@ -10,8 +10,8 @@ WSGIPythonOptimize 2 >> >> # To save resources during periods of no-elections (quite often - ~75% >> of the time) >> # We can run less threads and processes. >> -#WSGIDaemonProcess elections threads=2 processes=4 user=apache >> display-name=elections >> -WSGIDaemonProcess elections threads=1 processes=1 user=apache >> display-name=elections >> +WSGIDaemonProcess elections threads=2 processes=4 user=apache >> display-name=elections >> +#WSGIDaemonProcess elections threads=1 processes=1 user=apache >> display-name=elections >> >> To be fair, it'd most likely be okay running at threads=2 processes=2, >> but I'm trying to stick with what I've used in the past with the freeze >> etc. > > +1. Looks like a harmless optimization. > > We may want also want to set a 'maximum-requests' on the > WSGIDaemonProcess, as to help mitigate any memory leaks within the stack > (as opposed to having to use our restart-memhogs cronjob). Bodhi's is > currently set to 1000, but we should probably agree on a sane number and > make it consistent throughout our infrastructure. Our TurboGears SOP > also needs to be updated to reflect our new WSGI deployments as well. > Note: restart-memhogs wasn't written with WSGI processes in mind. It will only work with supervisor controlled applications at the moment. additional note:: in configs/web/applications/elections.conf: WSGIScriptAlias /voting /etc/elections.wsgi/voting Alias /voting/static /usr/share/elections/elections/static This application will probably suffer from the same mod_wsgi bug we saw with fas where WSGIScriptAlias and Directory have to point at the same directory otherwise processes and threads will be ignored in WSGIDaemonProcess. If we start getting db connection issues, this is likely to be the problem that we need to correct. I'm guessing, though, that usage of the election app for the art team to vote on the theme will be low enough that we won't notice this. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From ivazqueznet at gmail.com Mon Sep 22 21:06:18 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 22 Sep 2008 17:06:18 -0400 Subject: [Fwd: How to become a public mirror] Message-ID: <1222117578.3433.144.camel@ignacio.lan> For your consideration. -------- Forwarded Message -------- From: Truong Anh. Tuan To: webmaster at fedoraproject.org Subject: [SPAM] How to become a public mirror Date: Tue, 23 Sep 2008 00:40:05 +0700 (ICT) Dear sir/madam, We are the HanoiLUG, the largest Linux User Group and FOSS community in Vietnam. Currently, we have got a server contributed by Intel and Internet connection contributed by NetNam for mirroring Linux distibutions as well as FOSS in Vietnam (we call it Virror project). Honestly, I can not find how to become a Fedora public mirror, even, after read this Wiki article: http://fedoraproject.org/wiki/Infrastructure/Mirroring Could you please tell us more about this. Thanks, Tuan TRUONG A HanoiLUG member -------------- 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 Sep 23 02:53:56 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 23 Sep 2008 08:23:56 +0530 Subject: Big thank you to the Fedora infrastructure team Message-ID: <48D85A44.1070302@fedoraproject.org> Hi, Just passing on the message, http://forums.fedoraforum.org/forum/showthread.php?t=199590 Rahul From huzaifas at redhat.com Tue Sep 23 06:43:28 2008 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Tue, 23 Sep 2008 12:13:28 +0530 Subject: Some doubts for creation of new projects in fedorahosted Message-ID: <48D89010.7010406@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, I was doing a ticket on creating new projects on fedorahosted today and found certain anomalies in the documentation [1]. Since this is my first ticket on creating new projects on fedorahosted, I am not sure if my methods are correct, hence this email. The ticket in question is [2] 1. When a create a new git repo and do a git clone, exactly following the instructions on the wiki, i get a "headers does not exist message" I resolved it by doing cd /git/libaio.git; sudo git init This worked dont know if it is correct though 2. When running the script to create a new project, It seems that the trac enviroment was correctly created however adding a user to TRAC_ADMIN group gave the following error: "Command failed: columns username, action are not unique" However the user does get added to TRAC_ADMIN Group. Also the script already has step 6 [1] incorporated so i dont think that is needed. I would really appreciate if someone with a more experience can help me out a bit. Thanks a lot in advance. :) [1] https://fedoraproject.org/wiki/Infrastructure/ProjectHosting/RepositorySetup http://fedoraproject.org/wiki/Infrastructure/ProjectHosting/CreateNewProject [2] https://fedorahosted.org/fedora-infrastructure/ticket/837 - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFI2JAQzHDc8tpb2uURAnKZAJ9bLQDyOAl9o10snMUDDQx9gnmB7QCfUkR5 wt2/QjUOVGvsS0JvMkOB8hw= =Rj3g -----END PGP SIGNATURE----- From mmcgrath at redhat.com Tue Sep 23 13:36:23 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 23 Sep 2008 08:36:23 -0500 (CDT) Subject: Some doubts for creation of new projects in fedorahosted In-Reply-To: <48D89010.7010406@redhat.com> References: <48D89010.7010406@redhat.com> Message-ID: On Tue, 23 Sep 2008, Huzaifa Sidhpurwala wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi All, > I was doing a ticket on creating new projects on fedorahosted today and > found certain anomalies in the documentation [1]. > Since this is my first ticket on creating new projects on fedorahosted, > I am not sure if my methods are correct, hence this email. > The ticket in question is [2] > > > 1. When a create a new git repo and do a git clone, exactly following > the instructions on the wiki, i get a "headers does not exist message" > I resolved it by doing > cd /git/libaio.git; sudo git init > This worked dont know if it is correct though > This looks correct. There's an 'a' file in there, not sure where that came from :) > 2. When running the script to create a new project, It seems that the > trac enviroment was correctly created however adding a user to > TRAC_ADMIN group gave the following error: > > "Command failed: columns username, action are not unique" > However the user does get added to TRAC_ADMIN Group. > > Also the script already has step 6 [1] incorporated so i dont think that > is needed. > > I would really appreciate if someone with a more experience can help me > out a bit. Thanks a lot in advance. :) I have a hunch our script had a section in it to fix a bug in a previous version of trac that has now been fixed. Its probably safe to ignore but I'll take a closer look. -Mike From mmcgrath at redhat.com Tue Sep 23 18:58:58 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 23 Sep 2008 13:58:58 -0500 (CDT) Subject: Stale Fedora Hosted Projects (revisited) Message-ID: Getting back to this. What should we do with code to which no one claims ownership or the owner cannot be found? -Mike From kanarip at kanarip.com Tue Sep 23 20:48:14 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 23 Sep 2008 22:48:14 +0200 Subject: Stale Fedora Hosted Projects (revisited) In-Reply-To: References: Message-ID: <48D9560E.20605@kanarip.com> Mike McGrath wrote: > Getting back to this. What should we do with code to which no one claims > ownership or the owner cannot be found? > Has something like an AWOL procedure been considered? -Jeroen From mmcgrath at redhat.com Tue Sep 23 21:53:18 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 23 Sep 2008 16:53:18 -0500 (CDT) Subject: Stale Fedora Hosted Projects (revisited) In-Reply-To: <48D9560E.20605@kanarip.com> References: <48D9560E.20605@kanarip.com> Message-ID: On Tue, 23 Sep 2008, Jeroen van Meeuwen wrote: > Mike McGrath wrote: > > Getting back to this. What should we do with code to which no one claims > > ownership or the owner cannot be found? > > > > Has something like an AWOL procedure been considered? > Not really, thats kind of what I'm probing about. People didn't like the 6 month rule so I'm fine getting rid of that. But someone needs to be accountable for the code itself at all times and I'm hoping to have some policy in place that clearly states it. -Mike From Kevin.Cadieux at USherbrooke.ca Tue Sep 23 22:28:01 2008 From: Kevin.Cadieux at USherbrooke.ca (Kevin Cadieux) Date: Tue, 23 Sep 2008 18:28:01 -0400 Subject: A new member... Message-ID: <1222208881.48d96d7112166@www.usherbrooke.ca> Hello everyone, My name is Kevin, and I just recently created my account to be a member of the Fedora Project. I was interested in getting involved, so I looked at the different sub-projects on the wiki. I found that the Infrastructure sub-project was the one that suited best my experience and interests. So here I am now, writing to you all to introduce myself :) I am a Computer Engineering student at the University of Sherbrooke in Quebec, Canada. I am very organized with my school work so I can easily manage to get 10 to 20 hours of "Fedora" time per week. I am still in the process of reading the different documents on the wiki in order to get up to speed with Fedora and the Infrastructure group. So, if you have any advice as to what would be the best thing to start with, feel free to let me know. It would be greatly appreciated. In the meantime, I'll continue my reading and let you all know when I feel ready to roll. Thanks a lot, Kevin From wakko666 at gmail.com Tue Sep 23 22:56:27 2008 From: wakko666 at gmail.com (Brett Lentz) Date: Tue, 23 Sep 2008 15:56:27 -0700 Subject: Stale Fedora Hosted Projects (revisited) In-Reply-To: References: <48D9560E.20605@kanarip.com> Message-ID: <1222210587.25931.21.camel@brett.lentz> On Tue, 2008-09-23 at 16:53 -0500, Mike McGrath wrote: > On Tue, 23 Sep 2008, Jeroen van Meeuwen wrote: > > > Mike McGrath wrote: > > > Getting back to this. What should we do with code to which no one claims > > > ownership or the owner cannot be found? > > > > > > > Has something like an AWOL procedure been considered? > > > > Not really, thats kind of what I'm probing about. People didn't like the > 6 month rule so I'm fine getting rid of that. But someone needs to be > accountable for the code itself at all times and I'm hoping to have some > policy in place that clearly states it. > > -Mike I'd prefer to not see orphaned projects go away completely, if there is some way to keep them around in a stripped down, minimalist format. The process I'd like to see would be: 1. Do the usual 6 month project no-activity process. 2. If there is no response in N days, or mail to the project admin bounces in a fatal way (i.e. "no such user" vs. "mailbox full"), we call out to the general fedora-devel community to see if anyone wants to adopt the project and become its new maintainer. 3. If no new maintainer is found, we would then migrate the project to a central repository for orphaned projects. The central repository would contain a bare minimum of the project's files: * a tar.bz2 of the last revision of all files, with no revision history. * an archive of any documentation, such as the trac wiki pages. (again, just the text, with no need to preserve revision history) This way, we can preserve a stripped down version of the project's files for a (hopefully) lower infrastructure cost. Would something like this be possible/desired? ---Brett. Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln From mmcgrath at redhat.com Tue Sep 23 23:14:40 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 23 Sep 2008 18:14:40 -0500 (CDT) Subject: Stale Fedora Hosted Projects (revisited) In-Reply-To: <1222210587.25931.21.camel@brett.lentz> References: <48D9560E.20605@kanarip.com> <1222210587.25931.21.camel@brett.lentz> Message-ID: On Tue, 23 Sep 2008, Brett Lentz wrote: > On Tue, 2008-09-23 at 16:53 -0500, Mike McGrath wrote: > > On Tue, 23 Sep 2008, Jeroen van Meeuwen wrote: > > > > > Mike McGrath wrote: > > > > Getting back to this. What should we do with code to which no one claims > > > > ownership or the owner cannot be found? > > > > > > > > > > Has something like an AWOL procedure been considered? > > > > > > > Not really, thats kind of what I'm probing about. People didn't like the > > 6 month rule so I'm fine getting rid of that. But someone needs to be > > accountable for the code itself at all times and I'm hoping to have some > > policy in place that clearly states it. > > > > -Mike > > > I'd prefer to not see orphaned projects go away completely, if there is > some way to keep them around in a stripped down, minimalist format. > > The process I'd like to see would be: > > 1. Do the usual 6 month project no-activity process. > 2. If there is no response in N days, or mail to the project admin > bounces in a fatal way (i.e. "no such user" vs. "mailbox full"), we call > out to the general fedora-devel community to see if anyone wants to > adopt the project and become its new maintainer. > 3. If no new maintainer is found, we would then migrate the project to a > central repository for orphaned projects. > For how long would 3) happen? -Mike From dev at nigelj.com Tue Sep 23 23:32:31 2008 From: dev at nigelj.com (Nigel Jones) Date: Wed, 24 Sep 2008 11:32:31 +1200 Subject: Stale Fedora Hosted Projects (revisited) In-Reply-To: References: Message-ID: <1222212751.3367.86.camel@fantail.jnet.net.nz> On Tue, 2008-09-23 at 13:58 -0500, Mike McGrath wrote: > Getting back to this. What should we do with code to which no one claims > ownership or the owner cannot be found? * Make Trac Read Only (maybe static content too, in old.fedorahosted.org/projectname/) * Disable commit group in FAS (in particular to get rid of cla+1 entitlements if the commit group is their only group) * Chown SCM dir to remove write access - Nigel From mmcgrath at redhat.com Tue Sep 23 23:43:16 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 23 Sep 2008 18:43:16 -0500 (CDT) Subject: Stale Fedora Hosted Projects (revisited) In-Reply-To: <1222212751.3367.86.camel@fantail.jnet.net.nz> References: <1222212751.3367.86.camel@fantail.jnet.net.nz> Message-ID: On Wed, 24 Sep 2008, Nigel Jones wrote: > On Tue, 2008-09-23 at 13:58 -0500, Mike McGrath wrote: > > Getting back to this. What should we do with code to which no one claims > > ownership or the owner cannot be found? > * Make Trac Read Only (maybe static content too, in > old.fedorahosted.org/projectname/) > * Disable commit group in FAS (in particular to get rid of cla+1 > entitlements if the commit group is their only group) > * Chown SCM dir to remove write access > For how long? Here's the concern. At some point between now and the end of time decisions are going to have to be made about these projects. I'm trying to have us learn a lesson from the elvis move as well trying to make sure other's lack of planning doesn't become Infrastructures problem. Something has to happen with bits that belong to no one, so far no one has put a time limit on any of these things. -Mike From wakko666 at gmail.com Tue Sep 23 23:50:39 2008 From: wakko666 at gmail.com (Brett Lentz) Date: Tue, 23 Sep 2008 16:50:39 -0700 Subject: Stale Fedora Hosted Projects (revisited) In-Reply-To: References: <48D9560E.20605@kanarip.com> <1222210587.25931.21.camel@brett.lentz> Message-ID: <1222213839.25931.41.camel@brett.lentz> On Tue, 2008-09-23 at 18:14 -0500, Mike McGrath wrote: > On Tue, 23 Sep 2008, Brett Lentz wrote: > > > On Tue, 2008-09-23 at 16:53 -0500, Mike McGrath wrote: > > > On Tue, 23 Sep 2008, Jeroen van Meeuwen wrote: > > > > > > > Mike McGrath wrote: > > > > > Getting back to this. What should we do with code to which no one claims > > > > > ownership or the owner cannot be found? > > > > > > > > > > > > > Has something like an AWOL procedure been considered? > > > > > > > > > > Not really, thats kind of what I'm probing about. People didn't like the > > > 6 month rule so I'm fine getting rid of that. But someone needs to be > > > accountable for the code itself at all times and I'm hoping to have some > > > policy in place that clearly states it. > > > > > > -Mike > > > > > > I'd prefer to not see orphaned projects go away completely, if there is > > some way to keep them around in a stripped down, minimalist format. > > > > The process I'd like to see would be: > > > > 1. Do the usual 6 month project no-activity process. > > 2. If there is no response in N days, or mail to the project admin > > bounces in a fatal way (i.e. "no such user" vs. "mailbox full"), we call > > out to the general fedora-devel community to see if anyone wants to > > adopt the project and become its new maintainer. > > 3. If no new maintainer is found, we would then migrate the project to a > > central repository for orphaned projects. > > > > For how long would 3) happen? > > -Mike I think that it depends on our constraints. Perhaps we could measure our rate of growth, and strike a balance between maintaining an orphaned projects archive and our available resources? As this is one of those "nice to have" type of deals, I would expect these archived files to be first on the chopping block if we need to free up infrastructure resources for something that's more actively maintained. If you want to set a more firm SLA, how does 2 years (one RHEL release cycle) sound? -- ---Brett. From dev at nigelj.com Tue Sep 23 23:53:56 2008 From: dev at nigelj.com (Nigel Jones) Date: Wed, 24 Sep 2008 11:53:56 +1200 Subject: Stale Fedora Hosted Projects (revisited) In-Reply-To: References: <1222212751.3367.86.camel@fantail.jnet.net.nz> Message-ID: <1222214036.3367.88.camel@fantail.jnet.net.nz> On Tue, 2008-09-23 at 18:43 -0500, Mike McGrath wrote: > On Wed, 24 Sep 2008, Nigel Jones wrote: > > > On Tue, 2008-09-23 at 13:58 -0500, Mike McGrath wrote: > > > Getting back to this. What should we do with code to which no one claims > > > ownership or the owner cannot be found? > > * Make Trac Read Only (maybe static content too, in > > old.fedorahosted.org/projectname/) > > * Disable commit group in FAS (in particular to get rid of cla+1 > > entitlements if the commit group is their only group) > > * Chown SCM dir to remove write access > > > > For how long? Here's the concern. At some point between now and the end > of time decisions are going to have to be made about these projects. I'm > trying to have us learn a lesson from the elvis move as well trying to > make sure other's lack of planning doesn't become Infrastructures problem. > Something has to happen with bits that belong to no one, so far no one has > put a time limit on any of these things. IIRC the GPL at least requires that the code be kept for 3 years (hence why we can't clean the look-a-side cache from memory). We could do this a variety of ways, tarball a SCM dump and throw it on archives.fp.o for instance. - Nigel From kanarip at kanarip.com Tue Sep 23 23:59:47 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 24 Sep 2008 01:59:47 +0200 Subject: Stale Fedora Hosted Projects (revisited) In-Reply-To: <1222214036.3367.88.camel@fantail.jnet.net.nz> References: <1222212751.3367.86.camel@fantail.jnet.net.nz> <1222214036.3367.88.camel@fantail.jnet.net.nz> Message-ID: <48D982F3.6040200@kanarip.com> Nigel Jones wrote: > IIRC the GPL at least requires that the code be kept for 3 years (hence > why we can't clean the look-a-side cache from memory). > AFAIK that only goes to /distribution/ under GPLv2 section 3b, not the "upstream" SCM, but then again I'm not sure and it may be worthwhile looking into the requirements of the Licenses of the software in these SCMs. -Jeroen From kanarip at kanarip.com Wed Sep 24 00:02:31 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 24 Sep 2008 02:02:31 +0200 Subject: Stale Fedora Hosted Projects (revisited) In-Reply-To: References: <1222212751.3367.86.camel@fantail.jnet.net.nz> Message-ID: <48D98397.9000903@kanarip.com> Mike McGrath wrote: > For how long? Here's the concern. At some point between now and the end > of time decisions are going to have to be made about these projects. I'm > trying to have us learn a lesson from the elvis move as well trying to > make sure other's lack of planning doesn't become Infrastructures problem. > Something has to happen with bits that belong to no one, so far no one has > put a time limit on any of these things. > So what I was thinking is we have several processes in place in case this happens with a package, right? One can orphan a package in which case it get's removed almost instantaneously, or start AWOL for unresponsive maintainers, and (...), so maybe what we're looking for has already been thought of -it has just not been mixed up and stirred and applied to the specific case of an upstream SCM yet. -Jeroen From dev at nigelj.com Wed Sep 24 00:14:30 2008 From: dev at nigelj.com (Nigel Jones) Date: Wed, 24 Sep 2008 12:14:30 +1200 Subject: Stale Fedora Hosted Projects (revisited) In-Reply-To: <48D982F3.6040200@kanarip.com> References: <1222212751.3367.86.camel@fantail.jnet.net.nz> <1222214036.3367.88.camel@fantail.jnet.net.nz> <48D982F3.6040200@kanarip.com> Message-ID: <1222215270.3367.90.camel@fantail.jnet.net.nz> On Wed, 2008-09-24 at 01:59 +0200, Jeroen van Meeuwen wrote: > Nigel Jones wrote: > > IIRC the GPL at least requires that the code be kept for 3 years (hence > > why we can't clean the look-a-side cache from memory). > > > > AFAIK that only goes to /distribution/ under GPLv2 section 3b, not the > "upstream" SCM, but then again I'm not sure and it may be worthwhile > looking into the requirements of the Licenses of the software in these SCMs. Distribution is very loose in my terms. Technically by distributing the source code, we are errr acting as a distribution point. IANAL but that's my view. > > -Jeroen > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- Nigel Jones From a.badger at gmail.com Wed Sep 24 00:31:23 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 23 Sep 2008 17:31:23 -0700 Subject: Stale Fedora Hosted Projects (revisited) In-Reply-To: <1222215270.3367.90.camel@fantail.jnet.net.nz> References: <1222212751.3367.86.camel@fantail.jnet.net.nz> <1222214036.3367.88.camel@fantail.jnet.net.nz> <48D982F3.6040200@kanarip.com> <1222215270.3367.90.camel@fantail.jnet.net.nz> Message-ID: <48D98A5B.2010408@gmail.com> Nigel Jones wrote: > On Wed, 2008-09-24 at 01:59 +0200, Jeroen van Meeuwen wrote: >> Nigel Jones wrote: >>> IIRC the GPL at least requires that the code be kept for 3 years (hence >>> why we can't clean the look-a-side cache from memory). >>> >> AFAIK that only goes to /distribution/ under GPLv2 section 3b, not the >> "upstream" SCM, but then again I'm not sure and it may be worthwhile >> looking into the requirements of the Licenses of the software in these SCMs. > Distribution is very loose in my terms. > > Technically by distributing the source code, we are errr acting as a > distribution point. IANAL but that's my view. Perhaps. But the GPLv2 portion that has the three year clause deals with distributing binaries. Upstream SCM would be releasing source, so that doesn't apply. If the upstream on fedorahosted was releasing binary tarballs then it might be a little greyer. Although one would hope they were releasing both binary tarballs and source tarballs. Then it would fall under a different clause with no timeframe. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From a.badger at gmail.com Wed Sep 24 00:38:16 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 23 Sep 2008 17:38:16 -0700 Subject: A new member... In-Reply-To: <1222208881.48d96d7112166@www.usherbrooke.ca> References: <1222208881.48d96d7112166@www.usherbrooke.ca> Message-ID: <48D98BF8.3070003@gmail.com> Kevin Cadieux wrote: > Hello everyone, > > My name is Kevin, and I just recently created my account to be a member of the > Fedora Project. I was interested in getting involved, so I looked at the > different sub-projects on the wiki. I found that the Infrastructure sub-project > was the one that suited best my experience and interests. So here I am now, > writing to you all to introduce myself :) > > I am a Computer Engineering student at the University of Sherbrooke in Quebec, > Canada. I am very organized with my school work so I can easily manage to get > 10 to 20 hours of "Fedora" time per week. I am still in the process of reading > the different documents on the wiki in order to get up to speed with Fedora and > the Infrastructure group. So, if you have any advice as to what would be the > best thing to start with, feel free to let me know. It would be greatly > appreciated. In the meantime, I'll continue my reading and let you all know > when I feel ready to roll. > Welcome! It really depends on what your interests and skills are. The first question to ask is do you want to start off with programming or system administration? Many of us cross the boundaries into both sides of that but in terms of getting started on a first project and finding a mentor to show you the ropes, it's good to have some focus on one or the other at first. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From iamyuliang at gmail.com Wed Sep 24 01:45:28 2008 From: iamyuliang at gmail.com (liang yu) Date: Wed, 24 Sep 2008 09:45:28 +0800 Subject: My first mail Message-ID: Hi all: I am a new member of the Fedora Infrastructure team.My name is Yuliang from China.I have plenty of spare time to contribute and wish to involve the team. I like programming Any suggestion or mentorship from the team is important to me.I want to work with you qucikly. Best Regards Yuliang -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kevin.Cadieux at USherbrooke.ca Wed Sep 24 05:19:26 2008 From: Kevin.Cadieux at USherbrooke.ca (Kevin Cadieux) Date: Wed, 24 Sep 2008 01:19:26 -0400 Subject: A new member... In-Reply-To: <48D98BF8.3070003@gmail.com> References: <1222208881.48d96d7112166@www.usherbrooke.ca> <48D98BF8.3070003@gmail.com> Message-ID: <1222233566.48d9cddee06da@www.usherbrooke.ca> Quoting Toshio Kuratomi : > Kevin Cadieux wrote: > > Hello everyone, > > > > My name is Kevin, and I just recently created my account to be a member of > the > > Fedora Project. I was interested in getting involved, so I looked at the > > different sub-projects on the wiki. I found that the Infrastructure > sub-project > > was the one that suited best my experience and interests. So here I am now, > > writing to you all to introduce myself :) > > > > I am a Computer Engineering student at the University of Sherbrooke in > Quebec, > > Canada. I am very organized with my school work so I can easily manage to > get > > 10 to 20 hours of "Fedora" time per week. I am still in the process of > reading > > the different documents on the wiki in order to get up to speed with Fedora > and > > the Infrastructure group. So, if you have any advice as to what would be > the > > best thing to start with, feel free to let me know. It would be greatly > > appreciated. In the meantime, I'll continue my reading and let you all know > > when I feel ready to roll. > > > Welcome! > > It really depends on what your interests and skills are. The first > question to ask is do you want to start off with programming or system > administration? Many of us cross the boundaries into both sides of that > but in terms of getting started on a first project and finding a mentor > to show you the ropes, it's good to have some focus on one or the other > at first. > > -Toshio > > Hi, Thanks for your reply! To answer your question, I would feel more comfortable with programming for now since most of my experience is tied to that field. I have completed a 3 year Computer Science program at CEGEP (a kind of college in Quebec). I then started a Bachelor's degree in Computer Engineering, for which I am at my second year now. In between my education, I have accumulated about 2 years of hands-on experience by working at various companies in Montreal. I have been doing Web development for 1 year, using technologies such as XHTML, CSS, JavaScript, AJAX, PHP, JSP, MySQL, and MSSQL. Then, for 6 months, I filled a programmer position doing mostly VB.NET, Java, and MSSQL. I passed the last four months at Electronic Arts working on the new Skate game coming out for the Wii. In this project, I worked on adapting the various audio technologies for the Wii, wrote the music system for the game and contributed in the development of the speech playback system. The technologies used there were mostly C++, Visual Studio.NET, Perforce, and Nant. I don't have that much experience with Fedora or Linux, but that's one of the reasons I want to get involve: to learn. Given my background, I assume sysadmin-devel would be the most appropriate? Or do you have any suggestions? I already applied to sysadmin, for a start :) Cheers, Kevin From kanarip at kanarip.com Wed Sep 24 09:59:11 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 24 Sep 2008 11:59:11 +0200 Subject: Stale Fedora Hosted Projects (revisited) In-Reply-To: <48D98A5B.2010408@gmail.com> References: <1222212751.3367.86.camel@fantail.jnet.net.nz> <1222214036.3367.88.camel@fantail.jnet.net.nz> <48D982F3.6040200@kanarip.com> <1222215270.3367.90.camel@fantail.jnet.net.nz> <48D98A5B.2010408@gmail.com> Message-ID: <48DA0F6F.5030206@kanarip.com> Toshio Kuratomi wrote: > Nigel Jones wrote: >> On Wed, 2008-09-24 at 01:59 +0200, Jeroen van Meeuwen wrote: >>> Nigel Jones wrote: >>>> IIRC the GPL at least requires that the code be kept for 3 years (hence >>>> why we can't clean the look-a-side cache from memory). >>>> >>> AFAIK that only goes to /distribution/ under GPLv2 section 3b, not the >>> "upstream" SCM, but then again I'm not sure and it may be worthwhile >>> looking into the requirements of the Licenses of the software in these SCMs. >> Distribution is very loose in my terms. >> >> Technically by distributing the source code, we are errr acting as a >> distribution point. IANAL but that's my view. > > Perhaps. But the GPLv2 portion that has the three year clause deals > with distributing binaries. Upstream SCM would be releasing source, so > that doesn't apply. If the upstream on fedorahosted was releasing > binary tarballs then it might be a little greyer. Although one would > hope they were releasing both binary tarballs and source tarballs. Then > it would fall under a different clause with no timeframe. > Given that we alone can think of a couple of arguments for or against GPL distribution for 3 years or not, and there's other licenses as well, this might be more appropriately handled by the legally literate people (no offense to you, I just know I certainly am not) -Jeroen From a.badger at gmail.com Wed Sep 24 16:43:29 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 24 Sep 2008 09:43:29 -0700 Subject: Stale Fedora Hosted Projects (revisited) In-Reply-To: <48DA0F6F.5030206@kanarip.com> References: <1222212751.3367.86.camel@fantail.jnet.net.nz> <1222214036.3367.88.camel@fantail.jnet.net.nz> <48D982F3.6040200@kanarip.com> <1222215270.3367.90.camel@fantail.jnet.net.nz> <48D98A5B.2010408@gmail.com> <48DA0F6F.5030206@kanarip.com> Message-ID: <48DA6E31.80303@gmail.com> Jeroen van Meeuwen wrote: > > Given that we alone can think of a couple of arguments for or against > GPL distribution for 3 years or not, and there's other licenses as well, > this might be more appropriately handled by the legally literate people > (no offense to you, I just know I certainly am not) > Definitely. Especially since the base question isn't answered: Is fedorahosted responsible for satisfying the GPL clauses or is the upstream author who is responsible for the project hosted on fedorahosted responsible. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From mmcgrath at redhat.com Wed Sep 24 17:29:33 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 24 Sep 2008 12:29:33 -0500 (CDT) Subject: oVirt and xen6 Message-ID: Hey guys, I'm going to convert xen6 to F9 soon to do some ovirt/kvm testing. xen6 is almost dedicated to staging now, it will be before I start (need to move fas2 somewhere else). -Mike From mmcgrath at redhat.com Wed Sep 24 18:52:06 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 24 Sep 2008 13:52:06 -0500 (CDT) Subject: Stale Fedora Hosted Projects (revisited) In-Reply-To: <48DA6E31.80303@gmail.com> References: <1222212751.3367.86.camel@fantail.jnet.net.nz> <1222214036.3367.88.camel@fantail.jnet.net.nz> <48D982F3.6040200@kanarip.com> <1222215270.3367.90.camel@fantail.jnet.net.nz> <48D98A5B.2010408@gmail.com> <48DA0F6F.5030206@kanarip.com> <48DA6E31.80303@gmail.com> Message-ID: On Wed, 24 Sep 2008, Toshio Kuratomi wrote: > Jeroen van Meeuwen wrote: > > > > Given that we alone can think of a couple of arguments for or against > > GPL distribution for 3 years or not, and there's other licenses as well, > > this might be more appropriately handled by the legally literate people > > (no offense to you, I just know I certainly am not) > > > Definitely. Especially since the base question isn't answered: Is > fedorahosted responsible for satisfying the GPL clauses or is the > upstream author who is responsible for the project hosted on > fedorahosted responsible. > The note I got back from legal says that as long as our policy has been clearly stated all along (and it has) we only have that as a legal obligation which is 6 months with no changes. -Mike From skvidal at fedoraproject.org Wed Sep 24 17:34:54 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 24 Sep 2008 13:34:54 -0400 Subject: oVirt and xen6 In-Reply-To: References: Message-ID: <1222277694.4144.87.camel@rosebud> On Wed, 2008-09-24 at 12:29 -0500, Mike McGrath wrote: > Hey guys, I'm going to convert xen6 to F9 soon to do some ovirt/kvm > testing. xen6 is almost dedicated to staging now, it will be before I > start (need to move fas2 somewhere else). Does moving fas2 need a +1 to get out of the freeze? :) -sv From mmcgrath at redhat.com Wed Sep 24 19:00:43 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 24 Sep 2008 14:00:43 -0500 (CDT) Subject: oVirt and xen6 In-Reply-To: <1222277694.4144.87.camel@rosebud> References: <1222277694.4144.87.camel@rosebud> Message-ID: On Wed, 24 Sep 2008, seth vidal wrote: > On Wed, 2008-09-24 at 12:29 -0500, Mike McGrath wrote: > > Hey guys, I'm going to convert xen6 to F9 soon to do some ovirt/kvm > > testing. xen6 is almost dedicated to staging now, it will be before I > > start (need to move fas2 somewhere else). > > Does moving fas2 need a +1 to get out of the freeze? :) > Not covered by the freeze :) -Mike From Matt_Domsch at dell.com Wed Sep 24 18:36:50 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 24 Sep 2008 13:36:50 -0500 Subject: Stale Fedora Hosted Projects (revisited) In-Reply-To: <48DA6E31.80303@gmail.com> References: <1222212751.3367.86.camel@fantail.jnet.net.nz> <1222214036.3367.88.camel@fantail.jnet.net.nz> <48D982F3.6040200@kanarip.com> <1222215270.3367.90.camel@fantail.jnet.net.nz> <48D98A5B.2010408@gmail.com> <48DA0F6F.5030206@kanarip.com> <48DA6E31.80303@gmail.com> Message-ID: <20080924183650.GA24380@auslistsprd01.us.dell.com> On Wed, Sep 24, 2008 at 09:43:29AM -0700, Toshio Kuratomi wrote: > Jeroen van Meeuwen wrote: > > > > Given that we alone can think of a couple of arguments for or against > > GPL distribution for 3 years or not, and there's other licenses as well, > > this might be more appropriately handled by the legally literate people > > (no offense to you, I just know I certainly am not) > > > Definitely. Especially since the base question isn't answered: Is > fedorahosted responsible for satisfying the GPL clauses or is the > upstream author who is responsible for the project hosted on > fedorahosted responsible. IANAL, but... Whomever distributes the binaries is responsible for ensuring source is available, either concurrently (ideally)(such as GPLv2 3a), or via offer-to-provide-source-on-media (GPLv2 3b). If binaries are not distributed from fedorahosted, then fedorahosted is not responsible for providing source for any length of time. If binaries _are_ distributed from fedorahosted, e.g. compiled bits put into releases/, then I would expect fedorahosted to concurrently carry the source code used to build those binaries. Yes, this should be fedorahosted policy. It keeps us 100% out of the GPLv2 3b time bomb. I would not want to see us take on any obligation on behalf of another party to keep source available for an undetermined length of time without explicit intention to do so. fedorahosted is for source. If someone downloads that source, distributes a binary to someone and claims GPLv2 3c means that fedorahosted has to provide the source for them for 3 years, they're wrong. The three year clock is a crock. If you don't know when the last time you distributed binary under GPLv2 3b, then you can't know when the clock starts, so you can't know when the clock ends. Stay away from it. Seriously. -Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From jkeating at redhat.com Wed Sep 24 21:56:02 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 24 Sep 2008 14:56:02 -0700 Subject: Stale Fedora Hosted Projects (revisited) In-Reply-To: <20080924183650.GA24380@auslistsprd01.us.dell.com> References: <1222212751.3367.86.camel@fantail.jnet.net.nz> <1222214036.3367.88.camel@fantail.jnet.net.nz> <48D982F3.6040200@kanarip.com> <1222215270.3367.90.camel@fantail.jnet.net.nz> <48D98A5B.2010408@gmail.com> <48DA0F6F.5030206@kanarip.com> <48DA6E31.80303@gmail.com> <20080924183650.GA24380@auslistsprd01.us.dell.com> Message-ID: <1222293362.16026.4.camel@luminos.localdomain> On Wed, 2008-09-24 at 13:36 -0500, Matt Domsch wrote: > Whomever distributes the binaries is responsible for ensuring source > is available, either concurrently (ideally)(such as GPLv2 3a), or via > offer-to-provide-source-on-media (GPLv2 3b). > > If binaries are not distributed from fedorahosted, then fedorahosted > is not responsible for providing source for any length of time. > > If binaries _are_ distributed from fedorahosted, e.g. compiled bits > put into releases/, then I would expect fedorahosted to concurrently > carry the source code used to build those binaries. Yes, this should > be fedorahosted policy. It keeps us 100% out of the GPLv2 3b time > bomb. I would think of Fedorahosted just as i would think of a paid colo facility. Just because I may have offered software for download via the colo facility, and then I terminate my account (either due to ending a contract, or breach of contract) doesn't put the colo facility on the legal hook for software I may have hosted there. Same goes for Fedorahosted. We can have a clear agreement as to what would breach one's "contract" with Fedorahosted, and that Fedorahosted is not responsible for any legal obligations regarding source availability. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mmcgrath at redhat.com Wed Sep 24 22:04:05 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 24 Sep 2008 17:04:05 -0500 (CDT) Subject: Puppet training In-Reply-To: <20080917182912.GF6117@x300.bos.redhat.com> References: <48D08C74.40906@gmail.com> <20080917182912.GF6117@x300.bos.redhat.com> Message-ID: Well crap guys, my bad. I never finalized this and the time has come and gone.. Will next week on wed at 4:00 work for everyone still? -Mike On Wed, 17 Sep 2008, Luke Macken wrote: > On Tue, Sep 16, 2008 at 09:49:56PM -0700, Toshio Kuratomi wrote: > > Mike McGrath wrote: > > > Hey guys, i think I'd like to hold puppet training next week on Wed > > > sometime. Which would work best for you guys: > > > > > > 1:00 pm Chicago time > > > 4:00 pm Chicago time. > > > > > > The live training will be identical to this training: > > > > > > http://mmcgrath.fedorapeople.org/puppet/ > > > > > > But will allow for Q and A. The training at that links includes an ogg > > > and takes about a half hour to complete at full speed though if you're new > > > to puppet its worth it to stop in the middle and review some of the > > > topics. If you have any questions or comments about it please let me > > > know. The slideshow is made with openoffice and I made the ogg with > > > audacity. My throat hurts now so I'm going to get some tea :) > > > > > I'll go with the crowd and say 4:00PM but either works for me :-) > > Ditto. > > luke > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From laxathom at fedoraproject.org Wed Sep 24 22:07:58 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Thu, 25 Sep 2008 00:07:58 +0200 Subject: oVirt and xen6 In-Reply-To: References: Message-ID: <62bc09df0809241507s56bbbeecxf71ab5924ffc07b6@mail.gmail.com> On Wed, Sep 24, 2008 at 7:29 PM, Mike McGrath wrote: > Hey guys, I'm going to convert xen6 to F9 soon to do some ovirt/kvm > testing. xen6 is almost dedicated to staging now, it will be before I > start (need to move fas2 somewhere else). hm... i'm interested by your ovirt testing. Will you use the ovirt repo for that ? -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB From laxathom at fedoraproject.org Wed Sep 24 22:13:10 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Thu, 25 Sep 2008 00:13:10 +0200 Subject: Puppet training In-Reply-To: References: <48D08C74.40906@gmail.com> <20080917182912.GF6117@x300.bos.redhat.com> Message-ID: <62bc09df0809241513wc4fc5a5u7dfa576c3d3e2393@mail.gmail.com> On Thu, Sep 25, 2008 at 12:04 AM, Mike McGrath wrote: > Well crap guys, my bad. I never finalized this and the time has come and > gone.. Will next week on wed at 4:00 work for everyone still? > Is still your local time or UTC ? My try: 4:00pm UTC --> 6:00pm (my local time) half-OK 4:00pm (your local time) --> 10:00pm (my local time) OK -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB From ricky at fedoraproject.org Wed Sep 24 22:26:18 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Wed, 24 Sep 2008 18:26:18 -0400 Subject: Puppet training In-Reply-To: References: <48D08C74.40906@gmail.com> <20080917182912.GF6117@x300.bos.redhat.com> Message-ID: <20080924222618.GD17249@sphe.res.cmu.edu> On 2008-09-24 05:04:05 PM, Mike McGrath wrote: > Well crap guys, my bad. I never finalized this and the time has come and > gone.. Will next week on wed at 4:00 work for everyone still? Sounds good, and I hopefully won't have a bunch of tests this time around :-) Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From a.badger at gmail.com Wed Sep 24 22:35:29 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 24 Sep 2008 15:35:29 -0700 Subject: Puppet training In-Reply-To: References: <48D08C74.40906@gmail.com> <20080917182912.GF6117@x300.bos.redhat.com> Message-ID: <48DAC0B1.7000002@gmail.com> Mike McGrath wrote: > Well crap guys, my bad. I never finalized this and the time has come and > gone.. Will next week on wed at 4:00 work for everyone still? > wfm. And this time when I think my alarm goes off an hour early, I'll remember that Chicago is two hours ahead of me, not one :-) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From pvangundy at gmail.com Wed Sep 24 22:44:13 2008 From: pvangundy at gmail.com (Paul VanGundy) Date: Wed, 24 Sep 2008 18:44:13 -0400 Subject: Puppet training In-Reply-To: References: <48D08C74.40906@gmail.com> <20080917182912.GF6117@x300.bos.redhat.com> Message-ID: > Well crap guys, my bad. I never finalized this and the time has > come and > gone.. Will next week on wed at 4:00 work for everyone still? > > -Mike > Sounds good. /paul > On Wed, 17 Sep 2008, Luke Macken wrote: > >> On Tue, Sep 16, 2008 at 09:49:56PM -0700, Toshio Kuratomi wrote: >>> Mike McGrath wrote: >>>> Hey guys, i think I'd like to hold puppet training next week on Wed >>>> sometime. Which would work best for you guys: >>>> >>>> 1:00 pm Chicago time >>>> 4:00 pm Chicago time. >>>> >>>> The live training will be identical to this training: >>>> >>>> http://mmcgrath.fedorapeople.org/puppet/ >>>> >>>> But will allow for Q and A. The training at that links includes >>>> an ogg >>>> and takes about a half hour to complete at full speed though if >>>> you're new >>>> to puppet its worth it to stop in the middle and review some of the >>>> topics. If you have any questions or comments about it please >>>> let me >>>> know. The slideshow is made with openoffice and I made the ogg >>>> with >>>> audacity. My throat hurts now so I'm going to get some tea :) >>>> >>> I'll go with the crowd and say 4:00PM but either works for me :-) >> >> Ditto. >> >> luke >> >> _______________________________________________ >> Fedora-infrastructure-list mailing list >> Fedora-infrastructure-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list >> > > _______________________________________________ > 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 Sep 24 23:21:16 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 24 Sep 2008 18:21:16 -0500 (CDT) Subject: oVirt and xen6 In-Reply-To: <62bc09df0809241507s56bbbeecxf71ab5924ffc07b6@mail.gmail.com> References: <62bc09df0809241507s56bbbeecxf71ab5924ffc07b6@mail.gmail.com> Message-ID: On Thu, 25 Sep 2008, Xavier Lamien wrote: > On Wed, Sep 24, 2008 at 7:29 PM, Mike McGrath wrote: > > Hey guys, I'm going to convert xen6 to F9 soon to do some ovirt/kvm > > testing. xen6 is almost dedicated to staging now, it will be before I > > start (need to move fas2 somewhere else). > > hm... i'm interested by your ovirt testing. > Will you use the ovirt repo for that ? > Yeah, I was talking to those guys and for right now they suggest just doing whats listed on the ovirt.org site. -Mike From mmcgrath at redhat.com Wed Sep 24 23:30:02 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 24 Sep 2008 18:30:02 -0500 (CDT) Subject: Puppet training In-Reply-To: <62bc09df0809241513wc4fc5a5u7dfa576c3d3e2393@mail.gmail.com> References: <48D08C74.40906@gmail.com> <20080917182912.GF6117@x300.bos.redhat.com> <62bc09df0809241513wc4fc5a5u7dfa576c3d3e2393@mail.gmail.com> Message-ID: On Thu, 25 Sep 2008, Xavier Lamien wrote: > On Thu, Sep 25, 2008 at 12:04 AM, Mike McGrath wrote: > > Well crap guys, my bad. I never finalized this and the time has come and > > gone.. Will next week on wed at 4:00 work for everyone still? > > > > Is still your local time or UTC ? > My local time. I should have listed it UTC... -Mike From laxathom at fedoraproject.org Wed Sep 24 23:42:19 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Thu, 25 Sep 2008 01:42:19 +0200 Subject: oVirt and xen6 In-Reply-To: <62bc09df0809241632s65d890d9u12711470ed44d233@mail.gmail.com> References: <62bc09df0809241507s56bbbeecxf71ab5924ffc07b6@mail.gmail.com> <62bc09df0809241632s65d890d9u12711470ed44d233@mail.gmail.com> Message-ID: <62bc09df0809241642l3b442df7of553aa05fec7feff@mail.gmail.com> On Thu, Sep 25, 2008 at 1:32 AM, Xavier Lamien wrote: > On Thu, Sep 25, 2008 at 1:21 AM, Mike McGrath wrote: >> On Thu, 25 Sep 2008, Xavier Lamien wrote: >> >>> On Wed, Sep 24, 2008 at 7:29 PM, Mike McGrath wrote: >>> > Hey guys, I'm going to convert xen6 to F9 soon to do some ovirt/kvm >>> > testing. xen6 is almost dedicated to staging now, it will be before I >>> > start (need to move fas2 somewhere else). >>> >>> hm... i'm interested by your ovirt testing. >>> Will you use the ovirt repo for that ? >>> >> >> Yeah, I was talking to those guys and for right now they suggest just >> doing whats listed on the ovirt.org site. > > Ok, so feel free to reach if you have question. > I already checked out their work and perform a couple of ovirt install > for some intern project. Nota: Also installed on Fedora-rawhide (x86_64) with fedora packages instead of ovirt one (except for virt-viewer-plugin) and it's still works well. Only F-9 packages are available from ovirt.repo > > -- > Xavier.t Lamien > -- > http://fedoraproject.org/wiki/XavierLamien > GPG-Key ID: F3903DEB > Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB > -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB From laxathom at fedoraproject.org Wed Sep 24 23:32:21 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Thu, 25 Sep 2008 01:32:21 +0200 Subject: oVirt and xen6 In-Reply-To: References: <62bc09df0809241507s56bbbeecxf71ab5924ffc07b6@mail.gmail.com> Message-ID: <62bc09df0809241632s65d890d9u12711470ed44d233@mail.gmail.com> On Thu, Sep 25, 2008 at 1:21 AM, Mike McGrath wrote: > On Thu, 25 Sep 2008, Xavier Lamien wrote: > >> On Wed, Sep 24, 2008 at 7:29 PM, Mike McGrath wrote: >> > Hey guys, I'm going to convert xen6 to F9 soon to do some ovirt/kvm >> > testing. xen6 is almost dedicated to staging now, it will be before I >> > start (need to move fas2 somewhere else). >> >> hm... i'm interested by your ovirt testing. >> Will you use the ovirt repo for that ? >> > > Yeah, I was talking to those guys and for right now they suggest just > doing whats listed on the ovirt.org site. Ok, so feel free to reach if you have question. I already checked out their work and perform a couple of ovirt install for some intern project. -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB From ianweller at gmail.com Thu Sep 25 01:54:27 2008 From: ianweller at gmail.com (Ian Weller) Date: Wed, 24 Sep 2008 20:54:27 -0500 Subject: change request: [[MediaWiki:Common.css]] Message-ID: <20080925015427.GA2734@gmail.com> (cc docs) Request to change https://fedoraproject.org/wiki/MediaWiki:Common.css to the following: ===== .messagebox.wikicleanup { background-image: url("/w/uploads/7/72/Wiki-cleanup-background.png"); background-repeat: repeat; } ===== Reason: to allow for [[Template:Wiki cleanup]] (a new admonition to replace using {{admon/note}} in {{move}}, {{delete}}, etc) to stand out from other admonitions as not being alerting to the user, but rather to wiki gardeners. The reason this can't be done right in the template is because MediaWiki is very, very careful about external images (even though this one is technically "internal"). Effect on remainder of wiki/website/world: Little to none. An error should have no effect on the rest of the style of the wiki, except for user styles. I do not believe there to be an error in the above. Why I'm asking: I have to wield my sysop powers on the wiki to do this, and I just wanted to make sure it was cool (especially since we're in a change freeze). Why I'm asking now: I'll forget later. -- Ian Weller http://ianweller.org GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 "Technology is a word that describes something that doesn't work yet." ~ Douglas Adams -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ricky at fedoraproject.org Thu Sep 25 21:14:05 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 25 Sep 2008 17:14:05 -0400 Subject: Meeting Log - 2008-09-25 Message-ID: <20080925211405.GA3195@sphe.res.cmu.edu> 20:00 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 20:00 * ricky 20:01 -!- cassmodiah [n=cass at fedora/cassmodiah] has quit "???????" 20:01 * mmcgrath wonders if anyone else is 20:01 < fchiulli> fchiulli is lurking 20:02 < mmcgrath> abadger1999 dgilmore f13 fchiulli G jcollie lmacken marek ping? 20:02 < brothers> hi 20:02 < mmcgrath> brothers: yo 20:02 < dgilmore> gday mates 20:02 * lmacken 20:02 < fchiulli> mmcgrath: pong 20:02 < abadger1999> hola 20:02 < mmcgrath> yo 20:02 < mmcgrath> ok, lets get started 20:02 -!- skvidal [n=nnnnnnsk at fedora/skvidal] has joined #fedora-meeting 20:03 * jcollie will lurk a bit... got some $DAYJOB stuff to do in the background 20:03 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Tickets 20:03 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority 20:03 < zodbot> mmcgrath: http://tinyurl.com/2hyyz6 20:03 < mmcgrath> .ticket 753 20:03 < zodbot> mmcgrath: #753 (Mini-freeze for Fedora 10 beta) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/753 20:03 < mmcgrath> So the freeze is still on until... 20:03 -!- balor [n=balor at gimili.plus.com] has quit Remote closed the connection 20:03 < mmcgrath> 2008-09-30 20:04 < mmcgrath> nothing extrodinary there. 20:04 < mmcgrath> Does anyone have work thats blocking on that release? 20:04 < mmcgrath> I know domsch might have some MM stuff, not totally sure though 20:04 < mmcgrath> k, I'll move on then 20:04 < mmcgrath> .ticket 395 20:04 < zodbot> mmcgrath: #395 (Audio Streaming of Fedora Board Conference Calls) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/395 20:04 < abadger1999> bunch of little stuff. I'm working on other stuff until then 20:05 < mmcgrath> 20:05 < mmcgrath> jcollie: anything new on this front? 20:05 < jcollie> nope 20:05 < mmcgrath> k 20:05 < mmcgrath> .ticket 446 20:05 < zodbot> mmcgrath: #446 (Possibility to add external links on spins page) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/446 20:05 < mmcgrath> dgilmore: ^^^ 20:05 < dgilmore> nope i think it should be closed 20:06 < mmcgrath> k, if you're ready to close it have at it. 20:06 * nokia3510 says hello 20:06 < mmcgrath> .ticket 740 20:06 < zodbot> mmcgrath: #740 (Loaning out system time to OLPC participants) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/740 20:06 * mmcgrath looks at ticket to see if anything new is there. 20:06 < dgilmore> here i really dont know if we can provide what they want 20:07 < mmcgrath> so my last question there never really got answered. 20:07 < mmcgrath> gregdek: ping 20:07 < gregdek> mmcgrath: pong 20:07 < mmcgrath> dgilmore: do you know if their end goal is education or if their end goal is packages 20:07 < gregdek> Oh, trac ticket. 20:07 -!- mdomsch [n=Matt_Dom at cpe-70-124-62-55.austin.res.rr.com] has joined #fedora-meeting 20:07 < mmcgrath> gregdek: we're talkinga bout https://fedorahosted.org/fedora-infrastructure/ticket/740 20:07 < dgilmore> mmcgrath: not really sure. i think both 20:07 < mmcgrath> k 20:08 < mmcgrath> dgilmore: do you think we could point them to SuSE's open buildsystem? 20:08 < mmcgrath> I have a reasonably good relationship with those guys, not sure if they'd be interested or not. 20:08 < gregdek> aiui, the biggest problem is they've got participants who are being asked to build packages for OLPC, but they don't have Fedora systems, only Debian systems. And they end up doing weird stuff to get packages built. 20:09 < mmcgrath> and OLPC builds packages now, do we just need the koji client in debian? 20:09 < dgilmore> mmcgrath: not really. 20:09 < dgilmore> mmcgrath: honestly i think having koji in debian/ubuntu would go a long way to helping 20:09 < dgilmore> since mock is tehre and works 20:10 < mmcgrath> I guess I'm still confused by what is there, what they want and what they would suggest Fedora's role in that should be. 20:10 < mmcgrath> gregdek says they have people who are being asked to build packages, is this like OLPC extras or something? 20:10 < mmcgrath> OLPC.us? 20:10 < mmcgrath> :) 20:10 < ricky> Hehe 20:11 < gregdek> You know, I'm unsure. 20:11 < dgilmore> mmcgrath: most of it is dealling with fedora packages. 20:11 < dgilmore> mmcgrath: a tiny amount is packages not in fedora 20:11 < mmcgrath> so getting fedora packages into OLPC? 20:11 < dgilmore> but thats really tiny 20:11 < dgilmore> yeah 20:11 < mmcgrath> so they're worried about the tiny portion not in Fedora? 20:11 < mmcgrath> or the portion that is in Fedora? 20:11 < mmcgrath> if so, are we just talking about another distribution of Fedora similar to what EPEL is now? 20:12 < dgilmore> dealling with testing builds in mock. i.e. for new packages. dealing with submitting builds to koji 20:12 < mmcgrath> and the requirements are that this work on debian? 20:12 < dgilmore> thats the main hurdle 20:12 -!- jmtaylor [n=jason at fedora/jmtaylor] has joined #fedora-meeting 20:13 < mmcgrath> so there's potentially two parts to this 20:13 < mmcgrath> 1) is getting the koji client into debian, mock already is. 20:13 < mmcgrath> dgilmore: does mock build olpc packages just fine? what does it build against? 20:13 -!- fbijlsma [n=fbijlsma at p4FDC4F8C.dip.t-dialin.net] has joined #fedora-meeting 20:13 < dgilmore> mmcgrath: most people use the fedora release that there targeting against 20:13 < mmcgrath> k 20:14 < dgilmore> mmcgrath: though i have a mock config that uses olpc specfic packages also 20:14 < mmcgrath> and thast something that could be done on debian today? 20:14 < dgilmore> yes 20:14 < dgilmore> really whats missing is koji 20:14 < dgilmore> and maybe fedora-packager 20:15 < mmcgrath> so the thing the OLPC debian guys can't do is actually submit builds to koji so I'd think really we need to get one of those debian guys to get koji into debian. 20:15 < mmcgrath> or one of our guys to do it, I have no idea what the process is there. 20:15 < dgilmore> yeah i think one of them would be best 20:16 < mmcgrath> dgilmore: gregdek: do either of you know who we could assign this ticket to in debian world? 20:16 -!- JSchmitt [n=s4504kr at fedora/JSchmitt] has quit "Konversation terminated!" 20:16 < dgilmore> mmcgrath: ill ask them to provide someone 20:16 < mmcgrath> k 20:16 < dgilmore> lets move on 20:16 < mmcgrath> k 20:16 < mmcgrath> Thats the last of the tickets 20:16 -!- kulll [i=d318e24a at gateway/web/ajax/mibbit.com/x-d4dfe58a02d08d2a] has joined #fedora-meeting 20:17 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- puppet training 20:17 < mmcgrath> I dropped the ball on that puppet training. It'll happen next week I swear! 20:17 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- oVirt 20:18 < mmcgrath> I've been working to get xen6 rebuilt with oVirt. It is now dedicated to just the staging environment. there's a couple of potential uses there and possibly some upcomming projects as well. 20:18 -!- c_scott [n=cscott at schoolserver.laptop.org] has joined #fedora-meeting 20:18 -!- m_stone [n=mstone at dhcp-47-72.media.mit.edu] has joined #fedora-meeting 20:18 < m_stone> dgilmore: howdy. what can I do for you? 20:18 < mmcgrath> But I (and hopefully the rest of us) will be able to get our hands dirty with ovirt and help the developers harden it and get it ready. 20:18 < mmcgrath> dgilmore: I'll switch the topic back 20:18 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Tickets 20:18 < mmcgrath> .ticket 740 20:18 < zodbot> mmcgrath: #740 (Loaning out system time to OLPC participants) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/740 20:19 < mmcgrath> m_stone: we were looking at that ticket and from what we understand, we just need to get the koji client into debian but we don't know how to do that. 20:19 < m_stone> mmcgrath: that would certainly be a good first step. 20:19 < mmcgrath> m_stone: do you know any debian guys who can package it and get it in? 20:19 < m_stone> I can probably scare some up. 20:20 < m_stone> (though not this week!) :) 20:20 -!- DemonJester [n=DemonJes at fedora/DemonJester] has quit "leaving" 20:20 < smooge> quick question... mediawiki .. do we need to update to something furhter on upstream? I am looking at the source now 20:20 < mmcgrath> dgilmore tells me mock is already in debian so it should have everything we need to 1) test mock builds on debian workstations and 2) ultimately submit those builds to koji to be built. 20:20 < dgilmore> m_stone: what kind of educational assistance do you think fedora could offer? 20:20 < m_stone> mmcgrath: the difficulty is that, as of the last time I tested it, mock's usage of yum on debian was failing. 20:20 < dgilmore> m_stone: what are the ultimate end goals your hopping we can provide? 20:20 -!- marcopg_ [n=marco at host162-118-dynamic.9-87-r.retail.telecomitalia.it] has joined #fedora-meeting 20:20 < m_stone> so it was unable to initialize chroots. 20:20 < c_scott> m_stone: no, mock WorksForMe 20:20 < m_stone> c_scott: glad to hear it! 20:21 < c_scott> a koji port would be very nice, though 20:21 < m_stone> I'll retry it myself then. 20:21 < c_scott> i'd like to see the olpc repo configurations make it into mock upstream, though 20:21 < dgilmore> m_stone: i know mock worked for me when testing 20:21 < m_stone> (or else teach mock to be able to pull form urls) 20:21 < abadger1999> That would be nice from my perspective as well. 20:21 < m_stone> i.e. to pull configurations from, say, http urls 20:21 < dgilmore> m_stone: was it just ubuntu that was having issues? i used plain debian 20:22 * abadger1999 needs olpc repo's for the package database. 20:22 < nirik> smooge: it still needs to be built for epel... ianweller or you or whoever should do that if it's ready to be used. ;) 20:22 < m_stone> dgilmore: it was plain debian too. 20:22 < c_scott> dgilmore: yes, i use plain debian, too. 20:22 < m_stone> dgilmore: I last tested this March 7 though. 20:22 < m_stone> so it has been a while. 20:22 < m_stone> dgilmore: anyway, returning to your questions about educational assistance and goals... 20:22 < dgilmore> c_scott: there a few extra configs that need to get into mock 20:23 < m_stone> http://wiki.laptop.org/go/Developer/Fedora should give you some idea of the audience we're targetting. 20:23 < m_stone> however, if you glance at the 'outside reading' section... 20:24 < m_stone> you'll see that the tutorials/guidelines for actually writing specfiles which are listed are all severely out of date.. 20:24 < mdomsch> c_scott, if the olpc configs exist, adding them to mock should be trivial 20:24 < c_scott> mdomsch: dgilmore's got 'em 20:24 < m_stone> either the Maximum-RPM snapshot or the draft 'creating rpms' chapter. 20:25 < m_stone> dgilmore: consequently, I'm interested in three basic things. 20:26 < m_stone> dgilmore: 1) ability to use A Single Program for basic specfile maintenance tasks. this could be the common Makefile if it were easily adapted by newbies to new packages, it could be my Makefiles, etc. 20:26 -!- Gaaruto [n=Gaaruto at fedora/Gaaruto] has joined #fedora-meeting 20:26 < m_stone> having to immediately learn the individual command lines for git, cvs, rpmbuild, rpmlint, mock, and koji simultaneously doesn't work real well, in my experience. 20:27 < mmcgrath> m_stone: it doesn't work well even one at a time :) 20:27 < dgilmore> m_stone: you mean for getting packages ready for review? 20:27 < m_stone> 2) some authoritative written documentation on how to deal with specfiles. 20:27 < m_stone> dgilmore: for that, and also for bumpspec, changelog update from VCS logs, simplified error detection for %files problems, ... 20:27 < m_stone> that sort of thing. 20:27 < abadger1999> m_stone: Are we mostly talking new packages or maintaining old packages? 20:28 < m_stone> abadger1999: a mix of both. the documentation I wrote was geared at tweaking existing packages. 20:29 < m_stone> abadger1999: on the other hand, requests for new packages come up frequently. since FUDCON Boston, though, it's been a lot easier to get help from folks like mether on the new-requests packaging. 20:29 < c_scott> also, i'd rather like some tools to help manage forked packages -- starting with basic notifications when there's a new (say) f9 release of a package with an olpc3 fork 20:29 < m_stone> dgilmore: similarly, a source-code browser for the patched contents of SRPMs. -- I've started on this myself and may eventually finish it, but this ought to be useful for Fedora too. 20:29 < c_scott> and, if I get ambitious, a way of automatically applying patches to (say) f9 packages to get a corresponding olpc3 package 20:30 < m_stone> dgilmore: anyway, moving into the rest of the education problem. 20:30 < abadger1999> m_stone: #fedora-devel is the best resource for tweaking existing packages as it's likely to be one-off questions. 20:30 < m_stone> dgilmore: I benefitted greatly from hands-on tutoring on making rpms from bernie, from dcbw, and from you. 20:31 < m_stone> dgilmore: however, in order to be able to benefit from that tutoring, I needed both a fedora machine and access to the tutor. 20:31 < abadger1999> New packages would benefit from having someone mentor. 20:31 < m_stone> dgilmore: lots of people who I've tutored since then simply do not have easy access to a fedora development machine. 20:31 < m_stone> conceivably they could use a livecd, but in practice, it's still a real pain. 20:31 < abadger1999> The mingw people have started building a script that can help with forked packages... although we'dwant to reduce forking in olpc's case if possible. 20:31 < m_stone> and they still have to figure out where to find a mentor and how to give the mentor access to the build environment, etc... 20:32 < dgilmore> m_stone: so with the approriate tools on whatever distro they use they should be able to do thinks ok. 20:32 < dgilmore> m_stone: and they would have an XO to actually test things on 20:32 < c_scott> abadger1999: the goal is actually to help distinguishing (a) what packages are currently forked, (b) what the patch is that requires them to be forked 20:32 < c_scott> abadger1999: both help long term in ensuring changes are merged upstream to mitigate future need for the fork 20:33 -!- stickster_afk is now known as stickster 20:33 < abadger1999> c_scott: I think the mingw script does the opposite. 20:33 < c_scott> abadger1999: ? 20:33 < abadger1999> But maybe you could run it with the branches switched. 20:33 < m_stone> dgilmore: it's possible that you're right; it just makes more sense to me think of it as a Fedora-based 'newbie's sandbox' in koji. 20:34 < f13> sorry, I was busy 20:34 < m_stone> dgilmore: for example, you can imagine wanting to build up a browsable library of spec-file corrections made by experienced folks to newbie specfiles. 20:34 < abadger1999> Basically, it was designed so the mingw people could have a cross-compiled version of a Fedora package. then they can run the script to tell them what has changed in the Fedora-native package. 20:34 < m_stone> dgilmore: so that new folks have a wide variety of materials to browse to try to bootstrap themselves into knowledge. 20:34 < c_scott> abadger1999: ok, i see 20:35 < c_scott> abadger1999: but that tends to perpetuate the fork ;-) 20:35 < c_scott> i want to base all our packages on an f9 package, and just apply a patch to them automatically 20:35 < abadger1999> c_scott: yeah. In their case, the fork is permanent (the crosscompiled package is always going to be separate even if the source is all the same). 20:36 < abadger1999> 20:36 < dgilmore> m_stone: we have cvs history :). i can think of a few improvements for fedora-packager from this. 20:36 < m_stone> dgilmore: how is cvs history browsable? 20:37 < dgilmore> m_stone: cvsweb 20:37 < abadger1999> You want to say I have one olpc-specific patch and two that I submitted upstream (Fedora). New Fedora version is out, what patches can I drop, what patch do I need to rebase to the new version. 20:37 < m_stone> dgilmore: and how can diff between the upstream sources? 20:37 -!- ldimaggi_ [n=ldimaggi at nat/redhat/x-ce1910205342fe50] has quit "Leaving" 20:37 < m_stone> dgilmore: remember that a lot of folks are both the upstream and the packager for us. 20:37 < m_stone> and it's particularly confusing for them since the fedora docs mainly assume that packagers are not upstream. 20:37 < dgilmore> http://cvs.fedoraproject.org/viewvc/rpms/ however not easily searchable 20:38 < abadger1999> m_stone: Not that they aren't... just that they separate their roles. 20:39 < dgilmore> m_stone: it would be great if you could add some comments to that ticket. 20:39 < m_stone> dgilmore: okay, I can do that. 20:39 < m_stone> poke me again when it's not release week. :) 20:39 < dgilmore> :) will do 20:39 < m_stone> also, thanks for being so open to these suggestions. 20:40 < mmcgrath> we like openess :) 20:40 < m_stone> as I said before, I'm happy to take a crack at some of this myself; I just wanted to make sure you were aware of what I was aiming for. 20:40 < mmcgrath> dgilmore: m_stone: anything else for now or can we move on to the next meeting item? 20:40 < mmcgrath> m_stone: FYI, you can almost always find us in #fedora-admin should you have questions or ideas concerning this (or anything else for that matter) 20:40 < m_stone> mmcgrath: I'll follow up w/ dgilmore again in future weeks, then we can see where we stand. 20:40 < m_stone> good? 20:40 < mmcgrath> sounds good, m_stone please do make notes in the ticket so we don't forget - https://fedorahosted.org/fedora-infrastructure/ticket/740 20:40 < m_stone> mmcgrath: will do. 20:41 < mmcgrath> You'll need a fedora account for that, but not a CLA - https://admin.fedoraproject.org/accounts/ 20:41 < mmcgrath> Ok, if there's nothing else I'll move on to the next item. 20:41 -!- bryan_kearney [n=bkearney at nat/redhat/x-ff8ab0eafb7c82fd] has left #fedora-meeting ["Jar Jar Binks is my co-pilot"] 20:41 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- oVirt 20:41 < mmcgrath> K, so the oVirt team (ovirt.org) is working on some stuff and I think it'd be good for our team to adopt it. 20:42 < ricky> I looked at the website a tiny bit. Is it an appliance "take-over-the-machine" type thing, or just a package that you install? 20:42 < mmcgrath> We can't blanket move our infrastructure to it because we're almost entirely paravirt right now and not all of our hardware suports hardware virt. 20:42 < mmcgrath> ricky: both. 20:42 < SmootherFrOgZ> ricky: it's an appliance 20:42 < mmcgrath> But right now they just have an image for you to use and install. 20:42 < ricky> Aw :-( 20:43 < mmcgrath> ricky: my understanding is this is still very early. 20:43 < mmcgrath> the good thing about us getting involved now is we can make sure and make suggestions to help suit our needs and what we think others needs will be. 20:43 < ricky> OK. Hopefully, that will be one of the things 20:44 < SmootherFrOgZ> mmcgrath: what is the goal ? use the image appliance or make all service up and running for fedora-infra ? 20:44 < mmcgrath> well, in our case there's a couple of goals. 20:44 < mmcgrath> the primary goal is to look at whether or not we think ovirt will be the future of virtualization in the RH stack of virtualization. 20:45 < mmcgrath> I don't think we really have a say in it, but as fedora goes, it typically follows that RHEL goes. 20:45 < dgilmore> mmcgrath: having a base appserver appliance proxyserver applaince etc? 20:45 < mmcgrath> And managment tools in the open source space are horrible right now. 20:45 < mmcgrath> dgilmore: well, the ovirt stack's primary win is its management piece, and really thats the appliance. 20:45 < mmcgrath> so, in theory, we can 'convert' our current images to use to ovirt stack. 20:45 < mmcgrath> which, AFAIK, will just work. 20:45 < dgilmore> mmcgrath: ok 20:45 < SmootherFrOgZ> mmcgrath: correct 20:46 < mmcgrath> SmootherFrOgZ: did you do any conversions or was all your stuff fresh? 20:46 < lmacken> mmcgrath: how come we can't just start using it on everything? It uses libvirt, which supports xen and kvm, no ? 20:46 < SmootherFrOgZ> some conversions from xen host, yeah 20:46 * lmacken knows nothing about oVirt though, other than it is a rails app 20:46 < mmcgrath> lmacken: well, it uses libvirt's api, and libvirts api supports xen and kvm, but ovirt doesn't yet. 20:46 < mmcgrath> I get the feeling that we are VERY early adopters of ovirt. 20:46 < lmacken> odd, ok. 20:47 < mmcgrath> SmootherFrOgZ: were your xen host images actual disk images or were they partition images? 20:47 -!- Sonar_Guy [n=Who_Know at fedora/sonarguy] has joined #fedora-meeting 20:47 < lmacken> Sounds good to me though, I'm all for it. Do we have any kvm guests yet ? 20:47 < mmcgrath> not a single one yet. 20:47 * ricky didn't know about the rails part :-) 20:47 < mmcgrath> though hopefully some of our staging environment will be. 20:48 < dgilmore> mmcgrath: we were very early adopters of xen also 20:48 * SmootherFrOgZ only use partition images, but i did some tries with disk image 20:48 < lmacken> dgilmore: and TurboGears ;) 20:48 -!- mdomsch [n=Matt_Dom at cpe-70-124-62-55.austin.res.rr.com] has quit Remote closed the connection 20:48 < mmcgrath> dgilmore: yep, and I miss all that pain :) 20:48 < mmcgrath> SmootherFrOgZ: k 20:49 < mmcgrath> So yeah, I'm hoping FI can get a good working relationship with the oVirt guys so if you see them poking around at what we're doing, spend some time talking to them, ask questions and answer theirs. 20:49 < SmootherFrOgZ> i think we should add closer look on all services that ovirt requires also 20:49 -!- nman64 [n=n-man at fedora/nman64] has quit Remote closed the connection 20:49 < ricky> #ovirt and #ovirt-devel, I assume? 20:50 < mmcgrath> Considering that RH bought Qumranet it seems likely to me that they'll be pushing harder for KVM, especially since its already in the kernel and some how xen has still managed to fail at that 20:50 < mmcgrath> 20:50 < ricky> Er, not #ovirt-devel, #ovirt on OFTC, apparently 20:50 < mmcgrath> I don't really have a view into that virtualization stack stuff yet but maybe this will be a better way to see what RH's roadmap is for all of that. 20:50 < dgilmore> ricky: the virt guys seem to like oftc 20:51 < ricky> Heh. 20:51 < mmcgrath> I have to figure there will be a seemless way to convert from xen to kvm by RHEL6 but I guess we'll have to see. 20:51 < dgilmore> #virt there is for libvirt 20:51 < mmcgrath> :) 20:51 < mmcgrath> So anywho, anyone have any questions on that? 20:51 * dgilmore has none 20:51 < ricky> Is this something that'd be hard to setup at home? 20:51 < mmcgrath> ricky: you'd need hardware virt support. 20:51 < SmootherFrOgZ> ricky: not 20:51 < mmcgrath> I actually don't have a single box here at home that has that. 20:52 < ricky> But it won't take over the machine with appliance-y stuff, right? 20:52 < mmcgrath> other then that though, I don't think it'd be difficult. 20:52 < mmcgrath> ricky: the appliance is an actual image that you'd run in KVM. 20:52 < SmootherFrOgZ> ricky: but you will also need to have a lot of memory for the image appliance 20:52 < mmcgrath> so its like a 500M download or something then you run it. 20:52 < ricky> OK 20:53 < SmootherFrOgZ> ricky: fedora packages seem to work well just like ovirt repo btw 20:53 < mmcgrath> Ok, anyone have anything else on that? If not I'll open the floor. (we're running out of time) 20:53 < dgilmore> nothing more from me 20:53 -!- fbijlsma [n=fbijlsma at p4FDC4F8C.dip.t-dialin.net] has quit Read error: 113 (No route to host) 20:53 < mmcgrath> k 20:53 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 20:53 < mmcgrath> Anyone have anything they want to talk about? 20:53 * mmcgrath wants to mention he'll be missing for a chunk of tomorrow afternoon. 20:53 < SmootherFrOgZ> just a quick question 20:54 < mmcgrath> SmootherFrOgZ: sure thing. 20:54 < SmootherFrOgZ> there is a cron tack on buildsys (for koji) which actually does nothing 20:54 < SmootherFrOgZ> s/tack/task 20:54 < mmcgrath> which one? 20:54 < dgilmore> SmootherFrOgZ: what one 20:54 < mmcgrath> its on buildsys.fedoraproject.org or koji.fedoraproject.org ? 20:55 < SmootherFrOgZ> this cron deamon on koji.fp.o 20:56 < SmootherFrOgZ> Cron $SCRIPT --action=prune 20:56 < dgilmore> abadger1999: thats for koji-gc 20:56 < dgilmore> SmootherFrOgZ: ^ 20:56 < SmootherFrOgZ> there a couple of 20:56 < SmootherFrOgZ> delete, purge, etc 20:56 < mmcgrath> dgilmore: are we gc'ing again? 20:56 < dgilmore> SmootherFrOgZ: it needs to be fixed i was waiting for infra freeze to be over to fix it 20:56 < dgilmore> mmcgrath: no 20:57 < dgilmore> mmcgrath: auth is not right 20:57 < dgilmore> I can fix it now 20:57 -!- rdieter is now known as rdieter_away 20:57 < SmootherFrOgZ> here is the lil' log 20:57 < dgilmore> but was going to wait for freeze to be done 20:57 < dgilmore> SmootherFrOgZ: i know exactly what it is 20:57 < SmootherFrOgZ> Error: unable to log in, no authentication methods available 20:57 < dgilmore> SmootherFrOgZ: for now ignore it 20:57 < SmootherFrOgZ> dgilmore: ok ;) 20:58 < mmcgrath> dgilmore: yeah, lets fix it after the freeze. 20:58 < mmcgrath> Ok, anyone have anything else to discuss? If not I'll close the meeting in 30 20:58 < ricky> If we're have any thoughts about which CA we're planning to use, I'd be willing to test it out at home 20:58 < dgilmore> ricky: dogtag 20:59 < ricky> Cool, I'll start playing around with it and seeing how FAS can talk to it, etc. 20:59 < dgilmore> ricky: i have some feedback from the devs on what we will need to do to migrate from what we have now 20:59 < mmcgrath> 15 20:59 < mmcgrath> :) 20:59 < ricky> Worst case, I'll start a fresh setup with it just to test FAS against it 20:59 < ricky> That's all I had :-) 20:59 < mmcgrath> K 20:59 < mmcgrath> with that 21:00 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting Closed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From kwade at redhat.com Fri Sep 26 00:49:39 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Thu, 25 Sep 2008 17:49:39 -0700 Subject: change request: [[MediaWiki:Common.css]] In-Reply-To: <20080925015427.GA2734@gmail.com> References: <20080925015427.GA2734@gmail.com> Message-ID: <1222390179.3003.93.camel@calliope.phig.org> +1 from me :) On Wed, 2008-09-24 at 20:54 -0500, Ian Weller wrote: > (cc docs) > > Request to change https://fedoraproject.org/wiki/MediaWiki:Common.css to > the following: > > ===== > .messagebox.wikicleanup { > background-image: url("/w/uploads/7/72/Wiki-cleanup-background.png"); > background-repeat: repeat; > } > ===== > > Reason: to allow for [[Template:Wiki cleanup]] (a new admonition to > replace using {{admon/note}} in {{move}}, {{delete}}, etc) to stand out > from other admonitions as not being alerting to the user, but rather to > wiki gardeners. > > The reason this can't be done right in the template is because MediaWiki > is very, very careful about external images (even though this one is > technically "internal"). > > Effect on remainder of wiki/website/world: Little to none. An error > should have no effect on the rest of the style of the wiki, except for > user styles. I do not believe there to be an error in the above. > > Why I'm asking: I have to wield my sysop powers on the wiki to do this, > and I just wanted to make sure it was cool (especially since we're in a > change freeze). Why I'm asking now: I'll forget later. > > -- > fedora-docs-list mailing list > fedora-docs-list at redhat.com > To unsubscribe: > https://www.redhat.com/mailman/listinfo/fedora-docs-list -- Karsten Wade, Community Gardener Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org 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 Fri Sep 26 01:12:51 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 25 Sep 2008 20:12:51 -0500 (CDT) Subject: change request: [[MediaWiki:Common.css]] In-Reply-To: <1222390179.3003.93.camel@calliope.phig.org> References: <20080925015427.GA2734@gmail.com> <1222390179.3003.93.camel@calliope.phig.org> Message-ID: On Thu, 25 Sep 2008, Karsten 'quaid' Wade wrote: > +1 from me :) > On Wed, 2008-09-24 at 20:54 -0500, Ian Weller wrote: > > (cc docs) > > > > Request to change https://fedoraproject.org/wiki/MediaWiki:Common.css to > > the following: > > > > ===== > > .messagebox.wikicleanup { > > background-image: url("/w/uploads/7/72/Wiki-cleanup-background.png"); > > background-repeat: repeat; > > } +1 -Mike From ianweller at gmail.com Fri Sep 26 02:39:04 2008 From: ianweller at gmail.com (Ian Weller) Date: Thu, 25 Sep 2008 21:39:04 -0500 Subject: change request: [[MediaWiki:Common.css]] In-Reply-To: References: <20080925015427.GA2734@gmail.com> <1222390179.3003.93.camel@calliope.phig.org> Message-ID: <20080926023904.GA5503@gmail.com> On Thu, Sep 25, 2008 at 08:12:51PM -0500, Mike McGrath wrote: > On Thu, 25 Sep 2008, Karsten 'quaid' Wade wrote: > > > +1 from me :) > > +1 > Change made. :) https://fedoraproject.org/wiki/Template:Wiki_cleanup -- Ian Weller http://ianweller.org GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 "Technology is a word that describes something that doesn't work yet." ~ Douglas Adams -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mmcgrath at redhat.com Fri Sep 26 18:44:22 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 26 Sep 2008 13:44:22 -0500 (CDT) Subject: Just made a global change Message-ID: Hey guys, I accidental broke the freeze just now and didn't realize it till after I'd done it. I made a change to the puppetd.conf file thinking it'd only go to the puppet master but its gone out everywhere. I'll be more careful about that in the future. Let me know if it has any adverse affects (it shouldn't) -Mike From mmcgrath at redhat.com Sun Sep 28 22:29:14 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 28 Sep 2008 17:29:14 -0500 (CDT) Subject: func logrotate fix Message-ID: I'd like to implement the following global fix (its generating cron spam) in /etc/logrotate.d/func_rotate I'd like to change line 8 from /etc/init.d/funcd condrestart to /etc/init.d/funcd condrestart > /dev/null Can I get 2 +1's? -Mike From dennis at ausil.us Sun Sep 28 22:38:30 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 28 Sep 2008 17:38:30 -0500 Subject: func logrotate fix In-Reply-To: References: Message-ID: <200809281738.30727.dennis@ausil.us> On Sunday 28 September 2008 05:29:14 pm Mike McGrath wrote: > I'd like to implement the following global fix (its generating cron spam) > > in /etc/logrotate.d/func_rotate I'd like to change line 8 from > > /etc/init.d/funcd condrestart > > to > > /etc/init.d/funcd condrestart > /dev/null > > Can I get 2 +1's? +1 reducing un-needed spam is good Dennis From kanarip at kanarip.com Sun Sep 28 22:44:07 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 29 Sep 2008 00:44:07 +0200 Subject: func logrotate fix In-Reply-To: References: Message-ID: <48E008B7.20901@kanarip.com> Mike McGrath wrote: > I'd like to implement the following global fix (its generating cron spam) > > in /etc/logrotate.d/func_rotate I'd like to change line 8 from > > /etc/init.d/funcd condrestart > > to > > /etc/init.d/funcd condrestart > /dev/null > > Can I get 2 +1's? Sounds reasonable to me, +1. -Jeroen From ricky at fedoraproject.org Sun Sep 28 23:02:18 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Sun, 28 Sep 2008 19:02:18 -0400 Subject: func logrotate fix In-Reply-To: References: Message-ID: <20080928230218.GB14444@sphe.res.cmu.edu> On 2008-09-28 05:29:14 PM, Mike McGrath wrote: > I'd like to implement the following global fix (its generating cron spam) > > in /etc/logrotate.d/func_rotate I'd like to change line 8 from > > /etc/init.d/funcd condrestart > > to > > /etc/init.d/funcd condrestart > /dev/null > > Can I get 2 +1's? +1 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From laxathom at fedoraproject.org Sun Sep 28 23:10:41 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Mon, 29 Sep 2008 01:10:41 +0200 Subject: func logrotate fix In-Reply-To: References: Message-ID: <62bc09df0809281610u4012bc19uaac67a5580d809fc@mail.gmail.com> On Mon, Sep 29, 2008 at 12:29 AM, Mike McGrath wrote: > I'd like to implement the following global fix (its generating cron spam) > > in /etc/logrotate.d/func_rotate I'd like to change line 8 from > > /etc/init.d/funcd condrestart > > to > > /etc/init.d/funcd condrestart > /dev/null > > Can I get 2 +1's? +1 -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB From jonstanley at gmail.com Sun Sep 28 23:28:44 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Sun, 28 Sep 2008 19:28:44 -0400 Subject: func logrotate fix In-Reply-To: <62bc09df0809281610u4012bc19uaac67a5580d809fc@mail.gmail.com> References: <62bc09df0809281610u4012bc19uaac67a5580d809fc@mail.gmail.com> Message-ID: I'll throw a -1 in here (not that my vote matters for anything :) ). Not because of any risk in the change, but rather it violates the concept of a change freeze. It doesn't affect service, so if I went to our change management meeting at work with something like this during a change freeze I'd be laughed out of the room and told to wait. In my mind, we either have change freezes and stick to them, or we just forgo the charade. On 9/28/08, Xavier Lamien wrote: > On Mon, Sep 29, 2008 at 12:29 AM, Mike McGrath wrote: >> I'd like to implement the following global fix (its generating cron spam) >> >> in /etc/logrotate.d/func_rotate I'd like to change line 8 from >> >> /etc/init.d/funcd condrestart >> >> to >> >> /etc/init.d/funcd condrestart > /dev/null >> >> Can I get 2 +1's? > > +1 > > -- > Xavier.t Lamien > -- > http://fedoraproject.org/wiki/XavierLamien > GPG-Key ID: F3903DEB > Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- Sent from my mobile device Jon Stanley Fedora Bug Wrangler jstanley at fedoraproject.org From mmcgrath at redhat.com Sun Sep 28 23:38:49 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 28 Sep 2008 18:38:49 -0500 (CDT) Subject: func logrotate fix In-Reply-To: References: <62bc09df0809281610u4012bc19uaac67a5580d809fc@mail.gmail.com> Message-ID: On Sun, 28 Sep 2008, Jon Stanley wrote: > I'll throw a -1 in here (not that my vote matters for anything :) ). > Not because of any risk in the change, but rather it violates the > concept of a change freeze. It doesn't affect service, so if I went to > our change management meeting at work with something like this during > a change freeze I'd be laughed out of the room and told to wait. > > In my mind, we either have change freezes and stick to them, or we > just forgo the charade. > Next time you get laughed at tell those laughing that they should work to design a more flexable environment where risks are properly evaulated instead of blindly feared. Having control over your environment is important, when your environment has control over you, you've done it wrong :) -Mike > On 9/28/08, Xavier Lamien wrote: > > On Mon, Sep 29, 2008 at 12:29 AM, Mike McGrath wrote: > >> I'd like to implement the following global fix (its generating cron spam) > >> > >> in /etc/logrotate.d/func_rotate I'd like to change line 8 from > >> > >> /etc/init.d/funcd condrestart > >> > >> to > >> > >> /etc/init.d/funcd condrestart > /dev/null > >> > >> Can I get 2 +1's? > > > > +1 > > > > -- > > Xavier.t Lamien > > -- > > http://fedoraproject.org/wiki/XavierLamien > > GPG-Key ID: F3903DEB > > Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB > > > > _______________________________________________ > > Fedora-infrastructure-list mailing list > > Fedora-infrastructure-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > > > -- > Sent from my mobile device > > Jon Stanley > Fedora Bug Wrangler > jstanley at fedoraproject.org > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From kanarip at kanarip.com Sun Sep 28 23:43:47 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 29 Sep 2008 01:43:47 +0200 Subject: func logrotate fix In-Reply-To: References: <62bc09df0809281610u4012bc19uaac67a5580d809fc@mail.gmail.com> Message-ID: <48E016B3.1000309@kanarip.com> Jon Stanley wrote: > I'll throw a -1 in here (not that my vote matters for anything :) ). > Not because of any risk in the change, but rather it violates the > concept of a change freeze. It doesn't affect service, so if I went to > our change management meeting at work with something like this during > a change freeze I'd be laughed out of the room and told to wait. > When such a thing happens, and it does, I wait for the big outage I can't recover from without changing stuff during a change freeze, and drag their sorry asses back in the conference room. First thing on the agenda of course is appending "> /dev/null" to the condrestart of some logrotate file, not the outage. -Jeroen From loupgaroublond at gmail.com Mon Sep 29 16:04:34 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 29 Sep 2008 12:04:34 -0400 Subject: func logrotate fix In-Reply-To: References: <62bc09df0809281610u4012bc19uaac67a5580d809fc@mail.gmail.com> Message-ID: <7f692fec0809290904i6ec3a67ese4d8ff336254dd2b@mail.gmail.com> On Sun, Sep 28, 2008 at 7:28 PM, Jon Stanley wrote: > I'll throw a -1 in here (not that my vote matters for anything :) ). > Not because of any risk in the change, but rather it violates the > concept of a change freeze. It doesn't affect service, so if I went to > our change management meeting at work with something like this during > a change freeze I'd be laughed out of the room and told to wait. > > In my mind, we either have change freezes and stick to them, or we > just forgo the charade. I thought the point of a change freeze is so that we are more cautious about changes we have to make. Since everyone seems to approve the idea of making such a change during the change freeze, it seems acceptable to do so. -Yaakov > > On 9/28/08, Xavier Lamien wrote: >> On Mon, Sep 29, 2008 at 12:29 AM, Mike McGrath wrote: >>> I'd like to implement the following global fix (its generating cron spam) >>> >>> in /etc/logrotate.d/func_rotate I'd like to change line 8 from >>> >>> /etc/init.d/funcd condrestart >>> >>> to >>> >>> /etc/init.d/funcd condrestart > /dev/null >>> >>> Can I get 2 +1's? >> >> +1 From loupgaroublond at gmail.com Mon Sep 29 16:10:03 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 29 Sep 2008 12:10:03 -0400 Subject: fas/auth.py fas/json_request.py In-Reply-To: <20080929023241.C8C8612030A@lists.fedorahosted.org> References: <20080929023241.C8C8612030A@lists.fedorahosted.org> Message-ID: <7f692fec0809290910p1e8e6dc6j9e2c372aabe0fc34@mail.gmail.com> I actually like this code. Just issue a revert patch to my code, or, i'll do it myself. I suggest we name the function something more generic though. I like 'group_list' like we have 'email_list', but anything goes. -Yaakov On Sun, Sep 28, 2008 at 10:32 PM, Ricky Zhou (???) wrote: > fas/auth.py | 2 +- > fas/json_request.py | 14 ++++++++++++++ > 2 files changed, 15 insertions(+), 1 deletion(-) > > New commits: > commit cc20015bb73b0e18b91632dc452af0d8f614ab5a > Author: Ricky Zhou > Date: Sun Sep 28 22:32:37 2008 -0400 > > Initial fas_client method. > > diff --git a/fas/auth.py b/fas/auth.py > index 070259a..087ef2a 100644 > --- a/fas/auth.py > +++ b/fas/auth.py > @@ -89,7 +89,7 @@ def CLADone(person): > ''' > Returns True if the user has completed the CLA > ''' > - cla_done_group =config.get('cla_done_group') > + cla_done_group = config.get('cla_done_group') > try: > if person.group_roles[cla_done_group].role_status == 'approved': > return True > diff --git a/fas/json_request.py b/fas/json_request.py > index d762ed4..e56bfc3 100644 > --- a/fas/json_request.py > +++ b/fas/json_request.py > @@ -27,6 +27,7 @@ import sqlalchemy > > from fas.model import People > from fas.model import Groups > +from fas.model import PersonRoles > > class JsonRequest(controllers.Controller): > def __init__(self): > @@ -57,6 +58,19 @@ class JsonRequest(controllers.Controller): > > @identity.require(turbogears.identity.not_anonymous()) > @expose("json", allow_json=True) > + def fas_client(self): > + output = []; > + try: > + roles = PersonRoles.query.all() > + for role in roles: > + role.member.filter_private() > + output.append((role.member, role.role_type, role.group.name)) > + return dict(success=True, output=output) > + except InvalidRequestError: > + return dict(success=False) > + > + @identity.require(turbogears.identity.not_anonymous()) > + @expose("json", allow_json=True) > def person_by_username(self, username): > try: > person = People.by_username(username) > > > From stickster at gmail.com Tue Sep 30 00:35:16 2008 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 29 Sep 2008 20:35:16 -0400 Subject: a Beta announcement to use In-Reply-To: <1222728102.23360.31.camel@luminos.localdomain> References: <1222726605.745.126.camel@calliope.phig.org> <1222728102.23360.31.camel@luminos.localdomain> Message-ID: <20080930003516.GI13015@victoria-eth.internal.frields.org> On Mon, Sep 29, 2008 at 03:41:42PM -0700, Jesse Keating wrote: > On Mon, 2008-09-29 at 15:16 -0700, Karsten 'quaid' Wade wrote: > > In light of trying to pump up the marketing and the bug reporting, here > > is a Beta release announcement: > > This looks good to me. Are the links within validated with > Infrastructure to handle the load, and valid content? In answering that question, I believe there is an Infrastructure SOP for release that has the links automatically load balanced and expected by our intrepid sysadmins. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From roland at redhat.com Tue Sep 30 06:47:47 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 29 Sep 2008 23:47:47 -0700 (PDT) Subject: [MAILER-DAEMON@redhat.com: Returned mail: see transcript for details] Message-ID: <20080930064747.4D0D51544B4@magilla.localdomain> I had this bounce to my (new) fedorahosted.org mailing list. A few minutes later, I sent a test message and it got through fine. Then I sent this same message again, and it got through fine. I hope there isn't regularly some little window in which lists.fedorahosted.org's mailing lists are unknown to its MTA. Thanks, Roland -------------- next part -------------- An embedded message was scrubbed... From: Mail Delivery Subsystem Subject: Returned mail: see transcript for details Date: Tue, 30 Sep 2008 02:39:02 -0400 Size: 4993 URL: From jkeating at redhat.com Tue Sep 30 16:27:50 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 30 Sep 2008 09:27:50 -0700 Subject: Beta freeze lift Message-ID: <1222792070.3985.13.camel@luminos.localdomain> Since beta went out this morning, I'm +1 to lift the change freeze. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Tue Sep 30 21:40:30 2008 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 30 Sep 2008 17:40:30 -0400 Subject: F10 Beta release Message-ID: <20080930214030.GL22245@victoria-eth.internal.frields.org> Great job with the release this morning, guys. I know there were some gremlins in a torrent or two, but overall very painless and you guys made it look easy (as always). Hurrah, another milestone on the path to Cambridge! If anyone has any issues, we could plant them on a page for the next release day planning group call. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From poelstra at redhat.com Tue Sep 30 21:59:40 2008 From: poelstra at redhat.com (John Poelstra) Date: Tue, 30 Sep 2008 14:59:40 -0700 Subject: F10 Beta release In-Reply-To: <20080930214030.GL22245@victoria-eth.internal.frields.org> References: <20080930214030.GL22245@victoria-eth.internal.frields.org> Message-ID: <48E2A14C.8030809@redhat.com> Paul W. Frields said the following on 09/30/2008 02:40 PM Pacific Time: > Great job with the release this morning, guys. I know there were some > gremlins in a torrent or two, but overall very painless and you guys > made it look easy (as always). Hurrah, another milestone on the path > to Cambridge! > > If anyone has any issues, we could plant them on a page for the next > release day planning group call. > One idea I had... could we be very explicit when we tell people where to file bugs by giving them a full URL to rawhide so they don't have navigate the bugzilla gauntlet? Does anyone know how to format the URL so it goes straight to "new bug for rawhide?" John From mmcgrath at redhat.com Tue Sep 30 22:23:18 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 30 Sep 2008 17:23:18 -0500 (CDT) Subject: F10 Beta release In-Reply-To: <20080930214030.GL22245@victoria-eth.internal.frields.org> References: <20080930214030.GL22245@victoria-eth.internal.frields.org> Message-ID: On Tue, 30 Sep 2008, Paul W. Frields wrote: > Great job with the release this morning, guys. I know there were some > gremlins in a torrent or two, but overall very painless and you guys > made it look easy (as always). Hurrah, another milestone on the path > to Cambridge! > > If anyone has any issues, we could plant them on a page for the next > release day planning group call. > I'd like to give a shout out to Seth Vidal and the guys at ibiblio for getting the new torrent server installed and ready in a very short time span. Also, unrelated to torrent, I'd like to point out some other metrics I've been putting together for release days: https://admin.fedoraproject.org/zabbix/charts.php?fullscreen=0&groupid=0&hostid=10071&graphid=380 and https://admin.fedoraproject.org/zabbix/charts.php?fullscreen=0&groupid=0&hostid=10071&graphid=379 Those are updated every 30 seconds (right now at least) and give a view of hits / second for mirrors and the wiki. This is something we can watch on release day instead of sitting around saying things like "are they here yet?" :) In the future it may also help diagnose problems. -Mike From opensource at till.name Tue Sep 30 22:22:26 2008 From: opensource at till.name (Till Maas) Date: Wed, 01 Oct 2008 00:22:26 +0200 Subject: F10 Beta release In-Reply-To: <48E2A14C.8030809@redhat.com> References: <20080930214030.GL22245@victoria-eth.internal.frields.org> <48E2A14C.8030809@redhat.com> Message-ID: <200810010022.35163.opensource@till.name> On Tuesday 30 September 2008 23:59:40 John Poelstra wrote: > One idea I had... could we be very explicit when we tell people where to > file bugs by giving them a full URL to rawhide so they don't have > navigate the bugzilla gauntlet? > > Does anyone know how to format the URL so it goes straight to "new bug > for rawhide?" How about this URL? https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=rawhide You can also go to "create new bug report", select Fedora and then notice the "remember values and create bookmarkable template" button to preselect more. Regards, TIll -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: