infrastructure January 2008

infrastructure@lists.fedoraproject.org

53 participants
47 discussions

integration of LTSP 5 in fedora
by subhodip biswas 04 Jan '08

04 Jan '08

hi all ! is anybody looking toward the integration of LTSP 5 in fedora . all i found is a bugid ##234048 . i can help if needed . -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas

2 2

Looking for Volunteer Writers for Fedora Weekly News
by Thomas Chung 04 Jan '08

04 Jan '08

RE: Looking for Volunteer Writers for Fedora Weekly News Hello, We have an open position for volunteer writer who can cover fedora-infrastructure-list for Fedora Weekly News. If you're interested in this position, please contact me off-list. Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung

1 0

Introduction
by Dapid Candra 03 Jan '08

03 Jan '08

Dear all, I just joined this list and I am interested to help in fedora development. I have been using Linux (mainly RedHat since version 4 up to 6.2, and RHEL 3 and up). I want to help in infrastructure since I think my best experiences are in system administration, networking and security. Please let me know what should I learn to start helping. Thank you and regards, Dapid Candra

2 2

Meeting Log - 2008-01-03
by Ricky Zhou 03 Jan '08

03 Jan '08

15:01 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 15:01 * jima 15:01 * f13 15:01 -!- mether [n=ask@fedora/mether] has joined #fedora-meeting 15:01 < jima> (for now, at least) 15:01 * lmacken 15:02 < mmcgrath> dgilmore ricky skvidal paulobanon anyone I'm forgetting ping 15:02 < skvidal> pong 15:02 * skvidal is here 15:03 * poelcat lurking 15:03 * nirik is in the peanut gallery waiting for his olpc to charge up. 15:03 < mmcgrath> then lets get started 15:03 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Tickets 15:03 * iWolf thinks his day meeting was canceled 15:03 * dgilmore is here 15:03 < mmcgrath> .ticket 192 15:03 < zodbot> mmcgrath: #192 (Netapp low on free space) - Fedora Infrastructure - Trac - https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/192 15:04 < mmcgrath> I've not heard back since RH got off break but I believe this has been ordered and is in transit. I'll follow up after the meeting and find out for sure. 15:04 < skvidal> can we just make the ticket come up automatically? :) 15:04 < skvidal> mmcgrath: do we have power/rackspace for it? 15:05 < mmcgrath> skvidal: No one in GIT has given me any estimates of space or power though I've been told yes, we do have space for these. 15:05 < skvidal> okie doke 15:05 < mmcgrath> worst case scenario we've got 3U of boxes to get rid of and potentially another box to make room for the storage. 15:05 < mmcgrath> any other questions on that? 15:06 < mmcgrath> .ticket 270 15:06 < zodbot> mmcgrath: #270 (Fedora Wiki allows editing raw HTML) - Fedora Infrastructure - Trac - https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/270 15:07 < mmcgrath> This one's a bit interesting. 15:07 < mmcgrath> quaid: ping 15:07 < mmcgrath> stickster: ping 15:07 < skvidal> w/o the html editing the front wiki page doesn't work, does it? 15:07 < mmcgrath> we'd have to re-do it and many other pages actually 15:08 < skvidal> <nod> 15:08 < mmcgrath> though the /wiki/ landing page isn't as important as it once was so I suspect that won't be too difficult. 15:08 < skvidal> disabling the html translator is easy 15:08 < loupgaroublond> can you disable it on a per page basis? 15:08 < skvidal> no 15:08 < skvidal> I believe it is for the whole site or not at all 15:08 < mmcgrath> what I am worried about (and I'd like to contact the docs guys to verify) is that removing html editing might completely disrupt the way the docs teams workflow happens. 15:09 < mmcgrath> Since we're worried about a specific set of commands, I think mod_security may be an easy fix for now. 15:09 * mmcgrath curses wiki 15:09 < mmcgrath> it is a 4 letter word. 15:10 < skvidal> mike is too 15:10 < skvidal> and seth :) 15:10 < mmcgrath> heh 15:10 < dgilmore> good think Dennis is not :) 15:10 < mmcgrath> regardless we're going to have to take a closer look and see exactly what impact we'll have if we disable html or if mod_security is the way to go. 15:10 < poelcat> would that affect existing pages where raw html is used? 15:10 * mmcgrath doesn't think ricky/paulobanon are around to discuss 15:11 < skvidal> poelcat: in the wiki, yes 15:11 < skvidal> poelcat: they would stop working 15:11 < poelcat> that would break all meeting summaries i've posted for releng :) 15:11 < skvidal> b/c the wiki wouldn't know how to parse them to format them 15:11 < skvidal> good times 15:11 < mmcgrath> it'd just look ugly. 15:11 < poelcat> and other "pretty" irc logs 15:11 < mmcgrath> The other thing is we're looking at 1.6 but I'll bring that up later. 15:12 < mmcgrath> Anyone have anything else regarding 270? 15:13 < mmcgrath> .ticket 302 15:13 < zodbot> mmcgrath: #302 (Moin patches) - Fedora Infrastructure - Trac - https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/302 15:13 < mmcgrath> .fas abob 15:13 * mmcgrath doesn't think abob typically hangs out on IRC. 15:13 < zodbot> mmcgrath: abob 'Daniel Drown' <dan(a)drown.org> 15:14 * mmcgrath tries to ping mrbawb in #fedora-admin 15:15 < mmcgrath> We'll skip that for now. 15:15 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Moin 1.6 upgrade. 15:15 < mmcgrath> so the Moin guys have released a new version. meanwhile we've been doing a lot of work on Moin. 15:15 < mmcgrath> I'm not sure that any of our patches have made it into 1.6. 15:15 < dgilmore> how badly have we forked moin? 15:15 < mmcgrath> well as it stands with what is in production, not a terrible amount. 15:16 < mmcgrath> AFAIK just the ACL patch and mdomsch's forking patch. 15:16 < mmcgrath> abadger1999 might have applied another one (he mentioned he might be late, had a quick emergency to take care of) 15:16 < mmcgrath> but there's other work thats been going on that we've been intending to apply to fix some of our issues. 15:16 < dgilmore> that should be able to be ported to 1.6 easily then 15:17 < mmcgrath> we may have to put this off till abadger1999 or MrBawb get back. there's been some discussions on the list but its not clear how far they've gotten with each part. 15:17 < mmcgrath> I know MrBawb has been working to get his patches into upstream. 15:18 < mmcgrath> Anyone have anything to add to that? 15:18 < mmcgrath> a great deal of our time is consumed by the wiki right now, which is quite unfortunate. 15:19 -!- fchiulli [n=824c4010(a)gateway/web/cgi-irc/ircatwork.com/x-7881b9a46fcf2aaa] has joined #fedora-meeting 15:19 < mmcgrath> alrighty, moving on 15:19 < mmcgrath> fchiulli: howdy 15:20 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Schedule 15:20 < mmcgrath> http://fedoraproject.org/wiki/Infrastructure/Schedule 15:20 < mmcgrath> Nothing new with the sponsorship, there's really not been much going on because of the holidays. 15:21 < mmcgrath> Nothing new with docs though expect more docs to come soon. 15:21 < mmcgrath> no new SOP's and no new sponsors. 15:21 < skvidal> alright good times 15:21 < mmcgrath> very good 15:21 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Voting 15:21 -!- ClausReheis [n=ClausReh@fedora/ClausReheis] has quit "Leaving." 15:21 < mmcgrath> Did everyone have a chance to read over - http://fedoraproject.org/wiki/MikeMcGrath/Voting ? 15:22 < mmcgrath> There's nothing terribly ground breaking there except maybe the fact that some people have more of a vote then others and that everyone can vote. 15:22 * ricky appears. 15:22 < mmcgrath> Both of those aspects make this unique over other teams in Fedora 15:22 < mmcgrath> ricky: yo 15:23 < loupgaroublond> i wanted to ask about the postpone criteria 15:23 < mmcgrath> Does anyone oppose a more strict voting guideline like this? Anyone particularly for it? 15:23 -!- petreu [n=peter@fedora/Standby] has quit "( www.nnscript.de :: NoNameScript 4.02 :: www.XLhost.de )" 15:23 < f13> I don't oppose. I haven't looked it over closely, but I trust your judgement 15:24 < skvidal> mmcgrath: curiousity 15:24 < loupgaroublond> it's hard to predict in advance what percentage of the votes that are *p mean it actually should be postponed, compared to just simple +/-N 15:24 < skvidal> what's the plus? 15:24 < skvidal> and what keeps it working? 15:24 < mmcgrath> skvidal: the main one is a firm decision making process. 15:25 < skvidal> as opposed to what? 15:25 < mmcgrath> as opposed to the way it is now which we sort of talk about it and then we talk about it on the list, some people say yes some people say no and then something just sort of happens. 15:26 < mmcgrath> We do ok with it but I see lots of teams unable to actually make a decision and I want to make sure we avoid that. 15:26 < stickster> mmcgrath: pong 15:26 < skvidal> okay - I wasn't clear that the way things are is a big problem 15:27 < skvidal> and I was worried that we're adding complexity and rigor where it isn't needed 15:27 * mmcgrath worries about that too. 15:27 < skvidal> which creates something else a new contributor would need to learn to effectively contribute 15:27 < mmcgrath> but, for example, the monotone discussion a few weeks back made me re-think it. 15:27 < loupgaroublond> mmcgrath: i'm wondering if having postpone be part of the vote is a good idea, or if it's better to have a pre-vote vote 15:27 < mmcgrath> stickster: you going to be around for a bit? 15:27 < stickster> mmcgrath: yes 15:27 < mmcgrath> stickster: thanks. 15:27 < stickster> mmcgrath: I didn't realize we made "heavy" use of raw HTML 15:28 < stickster> I think the only place I've used it is personal pages IIRC 15:28 < stickster> And if it's disabled on the wiki, meh. 15:28 < mmcgrath> stickster: so docs doesn't use html much in their process? 15:28 < stickster> mmcgrath: You're talking about using {{{#!html ...}}} in the wiki, right? 15:28 < ricky> Yup. 15:28 < stickster> Then no. 15:29 < stickster> In fact, I don't think rely on that for anything. 15:29 < stickster> s/rely/we rely/ 15:29 < mmcgrath> stickster: I had seen you mention - 15:29 < mmcgrath> <p class="content.para">This is a paragraph of text that 15:29 < mmcgrath> has lots of good info for <span class="emphasis">you</span>!</p> 15:29 < mmcgrath> in an email, was that for something else or for the wiki? 15:29 * mmcgrath just wanted to clear it up. 15:31 < mmcgrath> loupgaroublond: not ignoring you, we'll get back to voting in a moment. 15:31 < stickster> mmcgrath: Oh sorry. 15:31 < stickster> mmcgrath: I was trying there to make the point that in some future content management system, being able to set up the use of attributes on XHTML makes it more useful and portable back and forth with good content markup systems like DocBook 15:31 < stickster> Has nothing to do with moin, though, don't worry 15:31 < mmcgrath> solid. 15:32 * mmcgrath really needs to go through the docs process once :) 15:32 < ricky> As a side note, I'm not sure that mod_security can do great filtering on form submissions. 15:32 < stickster> mmcgrath: We'll get into this at FUDCon, mmkay? 15:32 < stickster> Ouch 15:32 < mmcgrath> stickster: will do, thanks. 15:32 < loupgaroublond> mmcgrath: np 15:32 < ricky> I wouldn't even call it XSS, because people are explicitly allowed to insert their own HTML. 15:32 < stickster> That sounded like "Don't worry your li'l head about it"... not meant badly, I assure you! 15:32 * stickster shuts up now 15:32 < mmcgrath> ricky: it should be able to filter that stuff just fine. For example we could disallow people from submiting a <script 15:33 < mmcgrath> having said that though I've never actually used mod_security for that type of thing specifically. 15:33 < mmcgrath> perhaps we should set up a proof of concept and find out. 15:33 < ricky> Oh, cool, then. It'd be good to have something like that as a transition while we try to replace things with more macros. 15:33 < mmcgrath> <nod> 15:34 < mmcgrath> do we know if moin 1.6 has anything even close to the protection we're wanting? (I suspect no but hasn't actually looked) 15:34 < ricky> In terms of filtering HTML? 15:35 < mmcgrath> yeah 15:35 < ricky> We're currently using a plugin that specifically lets user control the exact text that's outputted, I think 15:35 < mmcgrath> <nod> 15:35 < ricky> There might be a way to do some parsing/filtering at that stage as well. 15:36 < mmcgrath> ricky: anything else on that? 15:36 < ricky> Nope - I'll try to look out for some common use cases and look into writing macros. 15:36 < mmcgrath> solid, thanks! 15:36 < mmcgrath> ok back to voting :) 15:36 < mmcgrath> loupgaroublond: what were you saying about pre-voting? 15:37 < loupgaroublond> mmcgrath: i'm saying, the details about wether a vote is +, -, or postpone is a bit vague 15:37 < mmcgrath> I'll add some additional details 15:38 < loupgaroublond> the simple solution is that either 33% P votes, or 50% P votes means a postpone, but i'mo not sure how well that takes into account the severity of needing to postpone the vote 15:38 < loupgaroublond> another option i can think of is to 'pre-vote' aka 'are we ready to vote on this' 15:38 < loupgaroublond> that makes things more complex though 15:38 < mmcgrath> I just worry that a pre-vote for every vote will be too tedious. 15:39 < mmcgrath> the +p would be rare but, interestingly, the first vote we've done in a while about a month ago was a vote to postpone :) 15:39 < ricky> Hopefully, the sponsorship requirement could help a bit with common sense cases. 15:39 < mmcgrath> ricky: I sure hope so :) 15:39 < mdomsch> feels like overkill to me 15:39 < mmcgrath> Either way we don't have any pressing issues to be voted on so we can alter that page a bit. I suppose we should vote on it next week :) 15:40 < mdomsch> most things are operated w/o a vote by concensus 15:40 < mdomsch> and I'm ok with that 15:40 < mmcgrath> mdomsch: I'm hoping very few things will need to be voted on but I do get people, Rahul for example, that requests these things. 15:40 < loupgaroublond> sure, i'm just slightly in favour of 33% in any case 15:40 * ricky wonders if there's any sort of absentee-type thing for people that can't necessarily make meetings on time. 15:40 < mmcgrath> And there are things like the monotone case from a few weeks ago where I think a vote whent splendly. 15:41 < mmcgrath> ricky: we might be able to add that. I was thinking KISS for that. 15:41 < mdomsch> rahul likes to see progress being made 15:41 < ricky> Yeah, I'm afraid of complexity as well. 15:42 < loupgaroublond> what if those things that did need votes were done by a web page? 15:42 < mmcgrath> loupgaroublond: why not just a ticket? 15:42 < loupgaroublond> that seems like the lowest level barrier of entry to handle absentee votes 15:42 < ricky> Yeah, I was thinking the ticket as well. 15:42 < mmcgrath> the lowest level would be a ticket, doens't require the CLA. A wiki page would. 15:43 < loupgaroublond> mmcgrath: sure, i was thinking that it gives us the option to have an anonymous vote, but tickets are good 15:43 < mmcgrath> lets think about it a bit and discuss more next week. We may decide not to do it at all. 15:43 < mmcgrath> alrighty, with that 15:44 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 15:44 < ricky> I'm most afraid that this kind of process becomes a common thing. If we can avoid that situation, it sounds great. 15:44 < mmcgrath> ricky: I'm hoping it will only come up for larger cases. Like "do we get rid of moin?" 15:44 < mmcgrath> K, open floor. 15:44 < mmcgrath> anyone have anything they'd like to discuss? 15:45 < f13> I may have missed it, but was there any update regarding the new colo? 15:45 < loupgaroublond> well, i hope everyone had a nice holiday and vacation 15:45 < mmcgrath> f13: the new colo as in the second colo in PHX or the new servers in Germany? 15:45 < f13> PHX 15:45 < f13> for the blade center 15:45 < mmcgrath> no word yet. I've heard we will be moved there and that we won't. 15:46 < f13> *sigh* 15:46 < mmcgrath> Last I heard from the blade center was mid january, I'll be replying to that email probably around FUDCon time. 15:46 < mmcgrath> very *sigh* 15:46 -!- knurd is now known as knurd_afk 15:46 < mmcgrath> I'll be in meetings with people in RH during the week before and after FUDCon and I expect things like the blade center to come up regularly. 15:46 < f13> k 15:47 < mmcgrath> Anyone have anything else? If not we'll close up in 30. 15:48 -!- No5251 [n=No5251(a)dslb-084-057-221-245.pools.arcor-ip.net] has joined #fedora-meeting 15:48 < mmcgrath> alllrighty 15:48 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting Closed 15:48 < mmcgrath> Thanks for coming everyone!

1 0

Request to remove infofeed
by Mike McGrath 03 Jan '08

03 Jan '08

There's been a request to remove infofeed in favor of bodhi's interface as they now duplicate information. Is anyone against doing this? https://fedorahosted.org/fedora-infrastructure/ticket/248 -Mike

5 8

RFC: Infrastructure Voting
by Mike McGrath 03 Jan '08

03 Jan '08

I'd like to propose a formalized system for the Infrastructure team to vote. http://fedoraproject.org/wiki/MikeMcGrath/Voting I think this will make decision making a bit easier. It's possible I'm trying to fix something that isn't broken but it would still be nice to be able to tell people why things are the way they are and that a vote took place. While I take a great deal of pride in how transparent and open our team is I do, from time to time, hear complaints about us making decisions behind closed doors. I think this is mostly an educational gap but some of it is the ambiguous way we make decisions which is just kind of "ehh?" "ehh!" then stuff changes :) Thought? Comments? -Mike

3 2

patch for kojid to prevent noarch build failures
by Jesse Keating 02 Jan '08

02 Jan '08

Today a number of builds were failing on xenbuilder2/4. They were perl noarch builds. The failure output was like: + '%{_fixperms}' /var/tmp/perl-Module-ExtractUse-0.22-1.fc8-root-/usr /var/tmp/rpm-tmp.90217: line 32: fg: no job control I investigated a failed buildroot and discovered that _fixperms was not being evaluated and translated in the rpm script as it should have been. _fixperms is an arch specific macro, and that led me to do some testing with how the mock rebuild is being called in noarch cases. Turns out, this is something I already fixed in upstream koji. Koji was unnecessarily calling mock with --arch noarch in the noarch build cases. I hadn't realized this was going to cause builds to fail so I hadn't done an upstream release with this fix yet. However since this is failing builds, I'm going to patch the builders manually. Here is the fix: https://fedorahosted.org/koji/changeset/a023693e32d663ab7ad4f4fc85912c987e2… diff --git a/builder/kojid b/builder/kojid index ae4be90..5cf10a2 100755 --- a/builder/kojid +++ b/builder/kojid @@ -457,7 +457,7 @@ class BuildRoot(object): # run build session.host.setBuildRootState(self.id,'BUILDING') args = ['--no-clean'] - if arch: + if arch and arch != 'noarch': args.extend(['--arch', arch]) args.extend(['--rebuild', srpm]) rv = self.mock(args) I'm providing this here should something happen and the builders get reverted before I do the next koji upstream release. -- Jesse Keating Fedora -- All my bits are free, are yours?

1 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure January 2008