Introduction
by Dapid Candra
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
16 years, 3 months
Meeting Log - 2008-01-03
by Ricky Zhou
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!
16 years, 3 months
RFC: Infrastructure Voting
by Mike McGrath
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
16 years, 3 months
patch for kojid to prevent noarch build failures
by Jesse Keating
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/a023693e32d663ab7ad4f4fc85912c987...
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?
16 years, 3 months
