meetingminutes June 2012

meetingminutes@lists.fedoraproject.org

24 participants
51 discussions

FAmNA Meeting (20 June 2012)
by inode0 20 Jun '12

20 Jun '12

====================== #fedora-meeting: FAmNA ====================== Meeting started by inode0 at 01:00:06 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-06-20/famna.2012-06-20… . Meeting summary --------------- * Roll Call (inode0, 01:00:22) * Announcements (inode0, 01:01:45) * Tickets (inode0, 01:06:11) * #37 (Proposal for distributing Fedora swag outside of conferences/events) â€“ FAmNA general trac - https://fedorahosted.org/famna/ticket/37 (inode0, 01:07:16) * Proposal for distributing Fedora swag outside of conferences/events (inode0, 01:07:30) * #22 (Red Hat Summit / JBossWorld 2012, Jun 26-29, Boston, MA) â€“ FAmNA general trac - https://fedorahosted.org/famna/ticket/22 (inode0, 01:26:58) * Red Hat Summit / JBossWorld 2012 (inode0, 01:27:14) * LINK: https://fedoraproject.org/wiki/Red_Hat_Summit_2012 (graphite6, 01:28:51) * Open Floor (inode0, 01:41:30) * LINK: http://www.amazon.com/Cow-Head-Party-Hat-Adult/dp/B002PBLL32 (suehle, 01:49:04) Meeting ended at 02:05:30 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * rbergeron (83) * inode0 (56) * ianweller (41) * nb (33) * suehle (31) * graphite6 (21) * award3535 (21) * MarkDude (20) * chanchito (12) * kk4ewt (11) * dan408 (8) * zodbot (7) * inode1 (4) John

1 0

Summary/Minutes from today's FESCo Meeting (2012-06-18)
by Kevin Fenzi 18 Jun '12

18 Jun '12

=================================== #fedora-meeting: FESCO (2012-06-18) =================================== Meeting started by nirik at 17:00:00 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-06-18/fesco.2012-06-18… . Meeting summary --------------- * init process (nirik, 17:00:01) * ticket 861 - Cleanup of maintainers with bugzilla account (nirik, 17:03:15) * AGREED: nirik will mail a list of affected maintainers to the devel list asking for anyone to contact them. nirik will mail them directly to their fas account again today. Then we wait and process any that didn't fix things by july 2nd on july 2nd. (nirik, 17:17:19) * ticket 857 F18 Feature: Initial Experience - https://fedoraproject.org/wiki/Features/InitialExperience .fesco 857 (nirik, 17:17:38) * AGREED: Feature is approved. (+8/0) (nirik, 17:31:30) * ticket 863 F18 Feature: Clojure - https://fedoraproject.org/wiki/Features/Clojure (nirik, 17:31:40) * AGREED: Feature is approved (+9/0) (nirik, 17:43:35) * ticket 864 F18 Feature: DNF - https://fedoraproject.org/wiki/Features/DNF (nirik, 17:44:17) * AGREED: Feature is approved (+8/0) (nirik, 17:56:59) * ticket 867 F18 Feature: Hawkey - https://fedoraproject.org/wiki/Features/Hawkey (nirik, 17:57:07) * AGREED: Feature is approved, please merge it with the DNF feature. (nirik, 18:00:38) * ticket 865 F18 Feature: DragonEgg - https://fedoraproject.org/wiki/Features/DragonEgg (nirik, 18:00:53) * AGREED: Feature is approved (+7/0) (nirik, 18:13:03) * ticket 866 F18 Feature: Dwarf Compressor - https://fedoraproject.org/wiki/Features/DwarfCompressor (nirik, 18:13:20) * AGREED: Feature is approved (+9/0) (nirik, 18:21:28) * ticket 868 F18 Feature: MiniDebugInfo - https://fedoraproject.org/wiki/Features/MiniDebugInfo (nirik, 18:23:37) * AGREED: Feature is approved. (+7/-1/0) (nirik, 18:26:57) * ticket 869 F18 Feature: Offline Updates using systemd and packagekit - https://fedoraproject.org/wiki/Features/OfflineSystemUpdates (nirik, 18:27:56) * AGREED: Feature is approved (+6/-1/0) (nirik, 18:41:44) * ticket 870 F18 Feature: SELinux Booleans Rename - https://fedoraproject.org/wiki/Features/SELinuxBooleansRename (nirik, 18:41:59) * AGREED: Feature is approved (+7/0) (nirik, 18:45:18) * ticket 871 F18 Feature: SysV to systemd - https://fedoraproject.org/wiki/Features/SysVtoSystemd (nirik, 18:45:30) * AGREED: Feature is approved (+6/-1/0) (nirik, 18:52:43) * ticket 872 F18 Feature: systemd unit cleanup and enhancement - https://fedoraproject.org/wiki/Features/Systemd-unit-cleanup (nirik, 18:52:52) * AGREED: Feature is not approved at this time. (-7/0) (nirik, 19:04:36) * Next week Chair (nirik, 19:05:33) * mitr to chair 2012-06-25 meeting. (nirik, 19:06:36) * Open Floor (nirik, 19:06:53) Meeting ended at 19:09:38 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (164) * mitr (69) * limburgher (57) * jwb (51) * hughsie (44) * mjg59 (42) * t8m (40) * pjones (39) * mezcalero (34) * notting (31) * _jakub_ (31) * hircus (27) * zodbot (16) * brouhaha (15) * Viking-Ice (12) * tibbs|w (7) * abadger1999 (5) * kushal (4) * alexlarsson (4) * gholms (3) * cwickert (2) * Rombobeorn (2) * JSchmitt (1) * drago01 (1) * mmaslano (0) -- 17:00:00 <nirik> #startmeeting FESCO (2012-06-18) 17:00:00 <zodbot> Meeting started Mon Jun 18 17:00:00 2012 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:01 <nirik> #meetingname fesco 17:00:01 <nirik> #chair notting nirik mjg59 mmaslano t8m pjones jwb mitr limburgher 17:00:01 <nirik> #topic init process 17:00:01 <zodbot> The meeting name has been set to 'fesco' 17:00:01 <zodbot> Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m 17:00:06 <mjg59> Hi 17:00:14 <jwb> hello. i am present. 17:00:26 <pjones> hi. 17:00:53 * limburgher present 17:01:16 <mitr> Hello 17:01:45 * hughsie present, but unsure of whether to just jump in on stuff, or just reply to questions... 17:02:27 <nirik> hughsie: feel free to jump in, but if it's about your feature, wait until we get to that topic? 17:02:32 * kushal is also here 17:02:34 <t8m> hello 17:02:37 <hughsie> nirik, understood, thanks. 17:03:00 <nirik> ok, lets go ahead and get started, we have a lot of features today. ;) 17:03:15 <nirik> #topic ticket 861 - Cleanup of maintainers with bugzilla account 17:03:15 <nirik> .fesco 861 17:03:15 * notting is here now. sorry about that 17:03:18 <zodbot> nirik: #861 (Cleanup of maintainers with bugzilla account issues) – FESCo - https://fedorahosted.org/fesco/ticket/861 17:03:29 <nirik> so, there was some back and forth in the ticket over the weekend on this. 17:03:37 * hircus present 17:03:42 <nirik> I'm happy to wait longer to take any action (although I don't think it will matter). 17:04:02 <limburgher> What's the current packager/package list at this time? 17:04:09 <jwb> i don't think it will either, but it can't really hurt to wait i guess 17:04:11 <notting> mmcgrath? someone should hit him with a fish or something. 17:04:41 * nirik notes he's going on vacation starting thursday, so I could happily wait until after I get back 17:05:06 <limburgher> nirik: Seems rational. 17:05:08 <t8m> I agree that it won't hurt if we wait for a few days more 17:05:27 <t8m> nirik, will you use the regular orphan process? 17:05:43 <nirik> in the last run, there were 97 issues. Down from about 197 a few weeks ago. 17:05:46 <t8m> I mean the non-responsive maintainer process 17:06:23 <nirik> t8m: well, I can, but thats a bunch of overhead for this number of packages... 17:07:00 <nirik> many of these issues could well have been happening for a long long time. 17:07:01 <t8m> nirik, ok can it be followed at least partially to avoid the overhead 17:07:49 <limburgher> And you're emailing both the FAS email and BZ email for each user, correct? 17:07:50 <nirik> t8m: well, what would you suggest? 17:08:10 <nirik> the policy asks that I file a bug against each package. 17:08:18 <nirik> I can do that, but it seems a massive waste of time and energy. 17:08:20 <mitr> nirik: http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers#… 17:08:24 <abadger1999> limburgher: How would we know what hte bz email for a user is? 17:08:32 <nirik> limburgher: no, because we have no idea what their bz email is. 17:08:47 <mitr> nirik: If I understand correctly, it's down to 7 maintainers, isn't it? 17:08:51 <notting> you can look it up in bz if you have admin privs for that table. that i don't have. 17:09:07 <notting> we could pester the bz maintainer to find that, but don't know if that's a good scalable process 17:09:18 <nirik> mitr: sure, but because of this script failing, they would Never in fact see the bug. 17:09:20 <limburgher> abadger1999, nirik: If there are open bugs against packages they own and they are assigned to them, it'll be there. 17:09:54 <abadger1999> notting: ahhh... you mean, look up the component and check the email addresses there to see if there's an address that could be the person in quesetion? 17:09:56 <nirik> limburgher: it could be. Or it could be some older maintainer thats not them 17:09:58 <limburgher> And if that's the case, those users are a bigger problem than the ones for which there are no open bugs. :) 17:10:10 * abadger1999 could probably do that as a one-off. 17:10:15 <limburgher> nirik: True. 17:10:17 <notting> abadger1999: no, i mean do a bz search of the accounts table for a name 17:10:18 <nirik> the problem here is that bugzilla is out of sync, so using bugzilla to report it seems... not ideal 17:10:38 <t8m> nirik, so I'd at least announce it on fedora-devel and give them a few more days to respond 17:10:43 <abadger1999> notting: k. that would be trickier. 17:10:59 <limburgher> nirik: True, but two bad addresses has a better chance of finding the person than one bad address. 17:11:26 <Rombobeorn> I think sending email to the FAS address can count as equivalent to filing bugs in Bugzilla when there isn't a specific problem with a package. I'm more interested in seeing a mail on the devel list so that anyone who might know other ways of contacting these packagers will notice. 17:11:29 <t8m> actually filling a bug against component they own would reveal the current address 17:12:11 <nirik> ok, how about this: proposal: nirik will mail a list of affected maintainers to the devel list asking for anyone to contact them. nirik will mail them directly to their fas account again today. Then we wait and process any that didn't fix things by july 2nd on july 2nd. 17:12:20 <limburgher> t8m: True. because it uses the real BZ address, not foo-owner(a)fp.org. 17:12:31 <brouhaha> Sounds similar to the "Fast Track procedure" for unresponsive maintainers. 17:12:36 <jwb> nirik, sounds excellent 17:12:46 <nirik> t8m: unless it was owned before by someone else, or that address no longer exists, or... ;) 17:13:27 <t8m> nirik, even for bugs newly filled? 17:13:50 <nirik> t8m: this script is the thing that sets that in bugzilla. :) 17:14:07 <t8m> nirik, ah ok 17:14:12 <nirik> so, user foo has address foo(a)bar.com in fas, it tries to set that in bugzilla so bugs filed against packages they own go to foo(a)bar.com. 17:14:23 <nirik> it's not working because there is no foo(a)bar.com bugzilla account. 17:14:26 <notting> nirik: sounds good. then again, i suspect we could find mmcgrath if we wanted to 17:14:43 <nirik> so, whats on the component could be anything... we don't know. Old maintainer, old address they used to have, etc. 17:14:47 <t8m> nirik, never mind, so +1 to the proposal 17:15:02 <nirik> notting: yeah, I can ping him. 17:15:06 * abadger1999 thinks mmcgrath might not own any packages in Fedora anymore 17:15:13 <nirik> abadger1999: he does. ;) 17:15:36 <nirik> the mission critical ytalk. ;) 17:16:13 <nirik> anyhow, votes? counter proposals? 17:16:30 <limburgher> +1 to proposal. 17:16:39 <mjg59> +1 17:16:43 <pjones> sure, +1 17:16:43 <mitr> +1 17:17:15 <jwb> i think i already said it sounds good 17:17:19 <nirik> #agreed nirik will mail a list of affected maintainers to the devel list asking for anyone to contact them. nirik will mail them directly to their fas account again today. Then we wait and process any that didn't fix things by july 2nd on july 2nd. 17:17:27 <nirik> ok, moving on unless there's anything else on this. 17:17:38 <nirik> #topic ticket 857 F18 Feature: Initial Experience - https://fedoraproject.org/wiki/Features/InitialExperience .fesco 857 17:17:48 <nirik> .fesco 857 17:17:49 <zodbot> nirik: #857 (F18 Feature: Initial Experience - https://fedoraproject.org/wiki/Features/InitialExperience) – FESCo - https://fedorahosted.org/fesco/ticket/857 17:17:51 <Rombobeorn> It's good to see that due process works in Fedora. :-) 17:18:14 <nirik> Rombobeorn: hopefully folks filing bugs against those components are understanding as well. ;) 17:18:33 <mitr> #857 probably demonstrates most things that could go wrong in the feature process :( 17:18:52 <jwb> i'm not sure why you say that 17:19:19 <mitr> The ticket was deferred two times to gather more information, and we still managed to discover more interested parties 17:19:41 <mitr> I have sent an email on friday, but it's probably stuck in moderation queues 17:19:45 <jwb> is trac throwing 500 errors for anyone else? 17:19:50 <mjg59> jwb: Yes 17:19:52 <brouhaha> jwb: yes 17:19:55 <nirik> jwb: something odd going on, being looked at. 17:19:57 <jwb> ok :\ 17:20:04 <pjones> yep 17:20:20 <jwb> mitr, sounds like the process is working fine then 17:20:41 <jwb> responsible parties are making sure it doesn't get a rubber stamp without proper discussion, etc 17:21:22 <limburgher> my understanding was that at the current moment, we'd determined that this would not impact spins not using it, correct? 17:21:35 <nirik> limburgher: yes, thats my understanding. just desktop spin. 17:21:36 <t8m> limburgher, that's not sure 17:21:36 <mitr> jwb: AFAICT the anaconda interaction was discoverred pretty much by a random act of luck 17:21:53 <jwb> mitr, pretty sure notting has repeatedly said that wasn't the case 17:21:56 <mitr> limburgher: It collides with anaconda's plans for sharing dialogs between anaconda and firstboot, so, not sure 17:21:58 <limburgher> t8m: What is your understanding of the current overlap? 17:22:07 <limburgher> mitr: Ah. 17:22:10 <mjg59> If only we had an Anaconda developer on fesco 17:22:18 <nirik> so, where do we go here? try and get interested parties all talking and revisit? 17:22:20 <t8m> limburgher, what mitr said 17:22:29 * nirik notes trac should be back 17:23:21 <pjones> mjg59: ppphbbbt. 17:24:22 <nirik> so, the question is: will anaconda+firstboot integration be messed up by this feature being in the desktop spin? or ? 17:25:09 <limburgher> My understanding was that this feature simply skipped firstboot, wouldn't that mean that anaconda would still use firstboot dialogs if need be? 17:25:14 <mitr> nirik: I think the worst case is asking the user for the same things twice 17:25:55 <limburgher> mitr: Which isn't great. I'd think the spin could feed anaconda options that it knows this feature would handle. Couldn' it? 17:25:56 <limburgher> t 17:26:11 <pjones> limburgher: yeah, that should be right 17:26:11 <jwb> the desktop spin isn't _using_ anaconda 17:26:25 <limburgher> <blink> 17:26:27 <mjg59> I think having a conversation about code that we haven't read while arguing positions for people who aren't here is unhelpful 17:26:36 <pjones> jwb: uh, liveinst is still anaconda I'm pretty sure. 17:26:39 <nirik> jwb: ? how does it install? 17:26:51 <limburgher> So if it's only using this, and not firstboot or anaconda, then there should be no issue. 17:26:53 <jwb> pjones, i thought it was still just basically a DD of the live image to a hard drive? 17:27:01 <t8m> serious hailstorm here just now 17:27:03 <mjg59> jwb: Yes, but it's Anaconda that does the setup 17:27:07 <mitr> limburgher: Yes, as long as the relevant parties agree on a mechanism. 17:27:09 <limburgher> mjg59: No, but it's fun. 17:27:26 <jwb> mjg59, but does it go through all the same setup stuff as a DVD install? 17:27:29 <jwb> i should just go try it 17:27:32 <nirik> t8m: stay safe. :) 17:27:32 <mjg59> jwb: Yes 17:27:38 <jwb> well i'm being dumb then 17:27:56 <t8m> nirik, not dangerous but cars parking outside might be damaged 17:28:13 <nirik> so, how about we delegate some of our number to go talk to anaconda and firstboot and initialexperence folks (possibly in the same place/time) and report back? 17:28:17 <limburgher> t8m: It'd still advice a helmet. 17:28:20 <pjones> Anyway at this point it really doesn't sound like the anaconda interaction is something fesco needs to be directly concerned with 17:28:30 <mjg59> So how about we just +1 it with the obvious assumption that if it's not well integrated it doesn't reach 100%? 17:28:45 <pjones> nirik: I don't know why we even need that, tbh. 17:28:46 <mjg59> We don't need to micromanage collaboration 17:29:00 <pjones> mjg59: I'm +1 to your proposal there. 17:29:10 <limburgher> mjg59, pjones: +1. If it's not, it will blow up, and we'll know. 17:29:20 <pjones> yeah 17:29:22 <nirik> sure, I'm ok with that too... I'd urge them to all communicate tho so we don't end up asking people things twice, or never. 17:29:42 <jwb> maybe even use the devel@ list as a place to discuss... development 17:29:50 <nirik> that would be novel 17:30:01 <pjones> Is that a thing we do now? 17:30:06 <limburgher> jump back. 17:30:09 <jwb> there's always a first time! 17:30:10 <t8m> well given the recent churn on devel it might not be too productive 17:30:33 <nirik> so, I see +3 ? 17:30:40 <mitr> +1 to proposal... my mail has reached the feature owners, at least, so people will hopefully handle this 17:30:42 <jwb> i am for pjones' proposal 17:30:45 <notting> i am +1 to this 17:30:45 <limburgher> t8m: +5 eyeroll :) 17:31:11 <t8m> ok +1 as well to the mjg59 proposal 17:31:15 <mjg59> I'm +1, obv 17:31:30 <nirik> #agreed Feature is approved. (+8/0) 17:31:40 <nirik> #topic ticket 863 F18 Feature: Clojure - https://fedoraproject.org/wiki/Features/Clojure 17:31:40 <nirik> .fesco 863 17:31:41 <zodbot> nirik: #863 (F18 Feature: Clojure - https://fedoraproject.org/wiki/Features/Clojure) – FESCo - https://fedorahosted.org/fesco/ticket/863 17:31:50 <nirik> +1, seems fine to me. 17:32:00 <limburgher> +1 17:32:05 <mitr> +1 17:32:12 <t8m> +1 17:32:34 * jwb gives in to the +1-isms 17:32:35 <jwb> +1 17:32:37 <mjg59> +1 17:32:42 <notting> how would the building & packaging with rpm-ified clojure packages work with people used to working with it beforehand? 17:33:24 <hircus> notting: eventually the goal is to use Leiningen the same way Maven work for Java packages 17:33:40 <hircus> i.e. provide an RPM offline mode that doesn't check versions, and the normal operational mode 17:34:06 <notting> so if you run it to grab your deps, it grabs some from packages, and some from <random upstream source>? 17:34:49 <hircus> well, with Maven, if you run it in online mode, it's more likely to pull most from the main Maven repos, given that pom files over-specify versions, normally 17:34:57 * pjones +1 17:36:20 <nirik> mmaslano was +1 in ticket. 17:36:35 <nirik> notting: more info, or vote? 17:36:55 <notting> hircus: so, to use the system deps packaged this way, you'd need to install them out-of-band (via su, authed package kit, whatever)? 17:37:37 <hircus> notting: two separate goals - one, to be able to have some Clojure apps (e.g. Pallet, a DevOps tool) available as RPMs 17:38:11 <hircus> the other one - to have the tools Clojure devs expect to have (e.g. Leiningen) available, but they'd use it just as they normally do (with standard repos). 17:38:39 <hircus> Debian's packaging is more #2 at the moment. we're hoping to package more eventually 17:38:56 <notting> essentially, i'm trying to compare&contrast with how rake/bundler/rubygems work 17:39:20 <hircus> ah, yes. not too familiar with how that works, is that mostly identical to Python eggs? 17:39:36 <limburgher> I think they're more like CPAN. 17:39:37 <notting> there there is no integration at the moment... it all goes to rubygems.org (AIUI) 17:40:05 <kushal> hircus, like pip and eggs 17:40:28 <hircus> at the moment, no, we've not had time to tweak Leiningen. once it goes in (dependent on deps being reviewed and some Maven bugfixes) then we'd make sure it picks up packages registered in /usr/share/maven-poms 17:40:53 <notting> but getting them registered there while you're developing as a user is outside the scope of this? ok. 17:40:55 <hircus> kushal: yes, Python eggs would be the ideal result 17:42:14 <hircus> right, as a user you won't be installing things into the system-wide repo 17:43:17 <notting> i mean, +1 in that it's not wrong to include it. i'm a bit concerned about the unclear usage case around an app developer trying to use leiningen with system-provided packages, but we have that problem with lots of languages 17:43:35 <nirik> #agreed Feature is approved (+9/0) 17:43:39 <nirik> yeah, we do. ;( 17:43:54 <limburgher> FutureFeature: Fix all languages. 17:44:13 <kushal> limburgher, :) 17:44:14 <hircus> yeah. I have that concern myself, though I think by F18 we can get Leiningen to at least source packages from the system repo properly 17:44:17 <nirik> #topic ticket 864 F18 Feature: DNF - https://fedoraproject.org/wiki/Features/DNF 17:44:17 <nirik> .fesco 864 17:44:19 <zodbot> nirik: #864 (F18 Feature: DNF - https://fedoraproject.org/wiki/Features/DNF) – FESCo - https://fedorahosted.org/fesco/ticket/864 17:44:34 <jwb> out of curiosity, what does DNF stand for? 17:44:36 <t8m> limburgher, some languages' feature is that they're not fixable 17:44:44 <notting> jwb: hey, at least it's not named DTF 17:44:49 <nirik> mmaslano is +1 in ticket. 17:44:52 <limburgher> t8m: Don't. Get. Me. Started. :) 17:44:53 <hircus> t8m: like luarocks :p 17:45:05 <nirik> Duke Nuken Forever! :) 17:45:09 <t8m> +1 to DNF 17:45:11 <jwb> notting, i dunno. DNF is commonly Did Not Finish. not a great expansion for a package manager 17:45:13 <hircus> upstream actively rejected python eggs-type integration 17:45:31 <mitr> +1 to DNF, as well 17:45:32 <limburgher> So, for DNF. . .this is just to get it in, not to replace yum? 17:45:34 <mjg59> jwb: Ticket says it's meaningless 17:45:41 <mjg59> Er, discussion page 17:45:50 <mjg59> I think it'd be nice to know what future plans are 17:45:51 <t8m> limburgher, sure 17:46:08 <mjg59> Is this intended to prototype functionality that'll head back to yum? 17:46:08 <jwb> mjg59, ah 17:46:23 <mjg59> Or is it going to sit there as an alternative and some time later we'll have a contentious argument about defaults? 17:46:24 <limburgher> I'm just curious what about yum in perceived as broken. 17:46:24 <jwb> mjg59, i think it is actually positioned as an eventual replacement for yum 17:46:25 <notting> i am curious "why fork", as well 17:46:32 * hughsie is wondering how the non-yum-compatible-depsolver issue is going to be worked out after the zif fiasco... :) 17:46:40 <mjg59> notting: I think this is probably one of the best answers to "why fork" 17:46:46 <limburgher> hughsie: Jinx. 17:47:05 <mjg59> hughsie: Presumably in an ideal world we all consolidate on libsolve 17:47:14 <mitr> notting: breaking plugin compatibility, I think 17:47:30 <hughsie> mjg59, fwiw, i'm planning to port Zif to the hawkey thing, which uses libsolv 17:47:48 <pjones> yeah, not inclined to vote for this thing until those questions are answered. 17:47:50 <mjg59> hughsie: Yeah. If DNF ends up being folded back into yum then I think everyone wins 17:48:00 <nirik> limburgher: yes, a preview/early picture, etc. 17:48:01 <nirik> +1 here provided this is being coordinated with yum maintainers, which I think it is. 17:48:04 <mjg59> Also, if we're advertising it as a feature, then I'd expect pk integration 17:48:05 <limburgher> mjg59: Agreed. 17:48:12 * nirik sees +4 so far 17:48:27 <mjg59> hughsie: Heard anything about that? 17:48:49 <hughsie> mjg59, well, from looking at hawkey and dnf, i don't see it yum compatible at all 17:48:53 <mitr> mjg59: I think this is "we added a package, please come and play with it" kind of feature, not "this is a change for everybody" kind of feature 17:49:16 <hughsie> mitr, i think that's the spirit, yes 17:49:44 <mjg59> mitr: I agree, but I think any package manager we advertise should integrate with the existing package management interface 17:49:53 <mitr> So, PK integration will eventually be required, but is not a prerequisite for adding that line to release notes 17:49:59 <t8m> mjg59, this is definitely not a replacement for anything (yet) so integration with pk is futurefeature 17:50:08 <hughsie> mjg59, dnf is missing a lot of features PK needs 17:50:15 <mjg59> I've no objection to it being in an archive, but I don't think it's a feature until it has at least rough functional equivalence 17:50:16 <jwb> then why would we bill this as a Feature? 17:50:21 <hughsie> by a lot, i mean, 80% 17:50:30 <hughsie> jwb, i agree 17:50:37 <jwb> this seems to be no more a feature than, say, adding apt 17:50:50 <nirik> I think they were seeing press in order to get people trying it out, reporting bugs, contibuting. 17:50:56 <nirik> seeking 17:51:29 <t8m> we are regularly +1 features that are nothing more than advertisements 17:51:50 <jwb> honestly, i think this is going to boil down to our very muddy definition of a feature and what everyone believes that to be 17:51:55 <t8m> it seems to me a double standard if we don't accept this one 17:52:03 <mitr> jwb: I think it falls under 3. and 5. in http://fedoraproject.org/wiki/Features/Policy/Definitions#Definition_of_a_F… 17:52:04 <limburgher> +1. 17:52:14 * nirik notes we also have the related Hawkey feature. 17:53:15 <notting> we do have alternative package managers, but some are barely supported at all in some regards. (smart, apt) 17:53:16 <jwb> mitr, yet in the checklist, it only matches 5 17:53:22 <notting> i assume this will be more so, even if it's a tech preview? 17:53:43 <nirik> I would hope the plan is to replace yum or merge changes back to it... 17:53:51 <nirik> we could defer and ask for that info? 17:53:53 <notting> in any case, it's reasonable by feature standards assuming the maintainers are willing to deal with the onslaught of people trying it and breaking it, so ... +1 17:53:57 <mitr> notting: IIUC at least one person is working on it full-time 17:54:00 <nirik> or just approve as it has +6 now. 17:54:33 <limburgher> I certainly need to see a list of "what's broken in yum and why it can't be fixed" before voting to replace it, but sure, put it in the distro. 17:54:34 <jwb> i guess i'm +1 if it's clearly labeled as a tech preview (or the fedora equivalent of such) 17:54:46 * hughsie assumed dnf was going to obsolete yum long term... 17:54:59 <hughsie> the emphasis on "long". 17:55:05 <t8m> I think so 17:55:53 <nirik> ok, so thats +7 ? /me recounts. 17:55:56 * hircus wondering if anyone knows what dnf is supposed to stand for 17:56:05 <hughsie> hircus, supposedly, nothing 17:56:07 <mjg59> Welcome to the start of this conversation 17:56:13 <gholms> It's too many syllables. :( 17:56:13 <mjg59> Well ok +1 then 17:56:18 <t8m> hircus, nothing - its on the talk page of the feature 17:56:22 <hircus> aha, ok 17:56:23 <limburgher> domain name fystem? 17:56:34 <nirik> pjones: vote? 17:56:35 <pjones> gholms: just pronounce it like it's an eastern european word and "n' is the vowel. 17:56:43 <pjones> nirik: vaguely +0. 17:56:44 <gholms> Heh 17:56:59 <nirik> #agreed Feature is approved (+8/0) 17:57:07 <nirik> #topic ticket 867 F18 Feature: Hawkey - https://fedoraproject.org/wiki/Features/Hawkey 17:57:07 <nirik> .fesco 867 17:57:11 <zodbot> nirik: #867 (F18 Feature: Hawkey - https://fedoraproject.org/wiki/Features/Hawkey) – FESCo - https://fedorahosted.org/fesco/ticket/867 17:57:16 <nirik> same thing here? I'm +1 17:57:30 <limburgher> Yeah. +1 17:57:33 * nirik wonders if both these couldn't be folded into one feature. 17:57:36 <pjones> I don't really see why this should be a separate feature 17:57:41 <mitr> I'm not sure why the two should be separate 17:57:49 <mitr> But it doesn't matter one bit, in the end.... so +1 17:57:49 <notting> yeah, i'd merge this into DNF 17:58:01 <jwb> i would agree with merging with DNF 17:58:06 <limburgher> I think the only make sense together, sort of pointless if one got in and not the other. 17:58:11 <nirik> +1 to merge into DNF. 17:58:14 <notting> proposal: merge into DNF 17:58:19 <mjg59> +1 17:58:19 * pjones +1 to notting's proposal 17:58:22 <limburgher> +1 to merge 17:58:27 <mitr> limburgher: Well, hawkey could end up testable and dnf broken 17:58:45 <limburgher> mitr: True. 17:59:03 <hughsie> mitr, zif kinda will depend on hawkey, not dnf, so i think it's seporate 17:59:31 <nirik> well, if thats the case just before feature freeze, scope could be adjusted to no longer include dnf? 17:59:49 <t8m> I'm fine either way - merging or separate feature 17:59:55 <mitr> but merging is fine with me as well, cuts down on the process. 18:00:05 * hughsie agrees 18:00:12 * mitr counts +5 to merge 18:00:38 <nirik> #agreed Feature is approved, please merge it with the DNF feature. 18:00:53 <nirik> #topic ticket 865 F18 Feature: DragonEgg - https://fedoraproject.org/wiki/Features/DragonEgg 18:00:53 <nirik> .fesco 865 18:00:55 <zodbot> nirik: #865 (F18 Feature: DragonEgg - https://fedoraproject.org/wiki/Features/DragonEgg) – FESCo - https://fedorahosted.org/fesco/ticket/865 18:01:09 <notting> hm a feature which our guidelines say you cannot use in packages 18:01:10 <nirik> +1, but I wonder if there's a llvm guideline, do you want one on this as well? 18:01:13 <brouhaha> This is another one for publicity (criteria 3 and 5) 18:01:18 <t8m> +1 18:01:25 <brouhaha> MinGW is also not usable to build Fedora packages 18:01:33 <drago01> it is 18:01:36 <jwb> notting, in fedora packages, yes. but you can use it for whatever you want to build 18:01:40 <brouhaha> This is a feature for developers, but not for development of Fedora. 18:01:42 <limburgher> +1 18:01:45 <mitr> nirik: There was a recent guideline against using LLVM where GCC is suported, it would probably apply here as well 18:01:48 <mitr> +1 to feature 18:01:54 <limburgher> mitr: Indeed it would. 18:02:21 <_jakub_> if it adds yet another hard gcc = %{version}-%{release} dependency, won't make me very happy on any gcc upgrades, especially if the maintainer won't be able to have quick turnaround 18:02:34 * nirik still doesn't think that's needed, but that ship has sailed. ;) 18:02:35 <brouhaha> I will try to do turnaround quickly. 18:02:51 <_jakub_> and I don't see much point for the distro about using LLVM optimizers with GCC FE, but can live with it 18:02:58 * hircus notes that the clang hard dependency is lifted in 3.0 18:03:03 <mitr> _jakub_: Has that historically caused problems? 18:03:04 <nirik> brouhaha: perhaps you could add _jakub_ as a co-maintainer? 18:03:15 <brouhaha> _jakub_, also useful for cross development, e.g., x86 to ARM 18:03:18 <limburgher> nirik: That sounds like an excellent idea. 18:03:22 <hircus> dragonegg might make LLVM more useful for C++ -- since clang++ lags behind in supporting the latest C++0x features 18:03:34 <brouhaha> nirik, I'd be happy to add _jakub_ as co-maintainer, if he's willing. 18:03:38 <pjones> I think maybe it's worth asking _jakub_ if he would want to be comaintainer or if that's just going to give him more work :) 18:03:52 <hircus> brouhaha: speaking of comaintenance -- want to comaintain LLVM :) 18:03:54 <_jakub_> mitr: yes, currently there is gcc-python-plugin which is constantly broken deps in rawhide and releases up until close to release 18:04:01 <nirik> pjones: sure, I didn't want to cause more work, just wanted to open the possiblity of fixing it if easy/desired. 18:04:37 <brouhaha> hircus: I'm open to the idea. I'm not at C++ expert level yet, but I'm getting better. 18:04:45 <_jakub_> and that one is actually useful 18:04:48 <mitr> _jakub_: does that affect only rawhide users that have gcc-python-plugin installed? Or is it making your work more dificult? 18:05:25 <_jakub_> mitr: it is mainly an issue when doing released distro updates, I then have to make sure all plugins (and libtool usually) are rebuilt as well 18:05:50 <brouhaha> Is there an easy way that I can get automatic notifications of new gcc builds in rawhide, to ensure that I know to update dragonegg quickly? 18:06:17 <brouhaha> (and in releases also!) 18:06:21 <notting> you can subscribe to koji notifications 18:06:26 <_jakub_> but I think clang is now requiring gcc version-release or at least version too, so that is already not fun 18:06:30 <brouhaha> notting: OK, I'll do that. 18:07:11 <nirik> if these things are just simple rebuilds, do consider adding more comaintainers that are around to do them more quickly. 18:07:20 <t8m> _jakub_, is the plugin ABI really broken by each rebuild? 18:07:23 <hircus> _jakub_: ah, my bad. yes, it still does, they just made it saner in the way it picks up the GCC version 18:07:45 <_jakub_> t8m: potentially broken, the ABI is simply not stable yet 18:07:46 <hircus> it depends on libstdc++, really, but that's in lockstep as GCC 18:07:59 <nirik> anyhow, back to the feature, I see +4. 18:08:14 <mjg59> +1 18:08:19 <_jakub_> t8m: I think dmalcolm is working on some stable ABI, but it is not there yet 18:08:22 <hircus> _jakub_: how hard would it be to maintain a separate, frozen version of libstdc++ ? that'd fix a lot of the clang-caused breakages 18:08:43 * t8m wonders if that version-release dependency should really be so exact 18:09:08 <hircus> version-only would suffice, actually. note to self: take a look tomorrow 18:09:39 <_jakub_> hircus: libstdc++ doesn't change that much after releases, but from time to time 18:10:08 <nirik> ok, thats +5... any other votes? 18:10:12 <hircus> _jakub_: right. but sometimes (as in F-16) GCC gets a major update, and that's what breaks clang 18:10:27 <hircus> anyway, back on topic 18:10:50 <jwb> nirik, +1 18:11:05 <_jakub_> hircus: I'm definitely not against a dependency on GCC major.minor, the problem is on major.minor.patchlevel or even release 18:11:32 <brouhaha> _jakub_, do you think plugin ABI typically changes on patchlevel? 18:11:51 <brouhaha> _jakub_: I can certainly relax the dependency to major.minor, if you think that's reasonable. 18:12:03 <hircus> _jakub_: the .patchlevel is an upstream problem, alas. the release is a packaging error on my part, I just blindly followed the guideline 18:12:26 <_jakub_> brouhaha: patchlevel is uninteresting, it is just a time when we package it up each few months 18:12:47 <pjones> nirik: yeah, +1 18:13:03 <nirik> #agreed Feature is approved (+7/0) 18:13:09 <_jakub_> brouhaha: but, some fixes might actually affect the plugin ABI at any time, though not very likely (but, we really don't know, because the plugin ABI is essentially all GCC headers) 18:13:20 <nirik> #topic ticket 866 F18 Feature: Dwarf Compressor - https://fedoraproject.org/wiki/Features/DwarfCompressor 18:13:20 <nirik> .fesco 866 18:13:22 <zodbot> nirik: #866 (F18 Feature: Dwarf Compressor - https://fedoraproject.org/wiki/Features/DwarfCompressor) – FESCo - https://fedorahosted.org/fesco/ticket/866 18:13:37 <brouhaha> _jakub_: I'll try to do my own retest with each new GCC build. 18:13:38 <nirik> mmaslano is +1 in ticket 18:14:04 <notting> how much will this add to build time, out of curiousity? 18:14:06 <jwb> i asked about how this interacted with the minidebuginfo proposal, if at all 18:14:13 <nirik> I'm +1, we will need to coordinate mass rebuilding. 18:14:22 <t8m> +1 18:14:43 <mjg59> +1 18:14:50 <_jakub_> notting: on a mid speed AMD box all of debuginfos took roughly 6 hours to compress or so 18:14:53 * pjones is +1 here 18:15:17 <limburgher> +1 18:15:29 <_jakub_> there are two parameters that will need to be carefully chosen on each arch depending on build box RAM amount/speed 18:15:33 <notting> _jakub_: split across all packages that's.... negligible? (if i didn't screw up the math) 18:15:57 <mitr> notting, _jakub_: are times for kernel (and libreoffice?) particularly high? 18:15:59 <_jakub_> notting: on libreoffice it can be like 5 minutes or so, but that is the slowest one 18:16:07 <nirik> _jakub_: are those hard coded? or dynamic according to the build machine? 18:16:12 <mitr> That's good :) 18:16:21 <mitr> +1 18:16:39 <notting> +1. although the linguistic implications of compressing dwarves is amusing 18:16:46 <pjones> indeed. 18:16:47 <hughsie> heh 18:16:52 <kushal> :) 18:17:01 <_jakub_> nirik: those should be hardcoded in redhat-rpm-config IMHO, it would be very weird if size of debuginfo differed depending on how much RAM the build box had at that day 18:17:04 <mitr> _jakub_: Hm, are there any packaging implications from the multifile copmression support? 18:17:26 <mitr> IOW, where is the shared file placed? 18:17:26 <nirik> _jakub_: not all our builders have the exact same memory... 18:17:30 <_jakub_> mitr: we should handle everything transparently from find-debuginfo.sh, which will need to be changed 18:17:36 * nirik wonders what the answer to jwb's question was. 18:17:43 <jwb> nirik, me too1 18:17:46 <mitr> _jakub_: great 18:17:58 <_jakub_> mitr: my proposal is to put the shared file as /usr/lib/debug/.dwz/%{name}-%{version}-%{release}.%{arch}.debug 18:18:18 <notting> minidebuginfo is, AIUI, a separate section. whether it's compressed or not is entirely up to minidebuginfo 18:18:43 <_jakub_> mitr: the *.debug files will contain relative path from those *.debug file directories to the picked up shared filename 18:18:46 <jwb> notting, but does compressed dwarf render minidebuginfo's benefits moot? does it make them better? etc 18:19:23 <_jakub_> minidebuginfo is about .symtab/.strtab, so has nothing to do with dwz 18:19:34 <pjones> yeah, they really aren't related 18:19:37 <_jakub_> dwz doesn't touch those sections at all 18:19:41 <notting> my understanding is that compressed dwarf is sitll Too Big to include by default 18:19:49 <_jakub_> yeah 18:20:10 <nirik> ok. 18:20:26 <_jakub_> I'd like to use -g3 by default though, to improve debugging and e.g. security checking (for -D_FORTIFY_SOURCE etc.) 18:20:44 <nirik> jwb: vote? or more info? 18:20:45 <_jakub_> with dwz -m the -g3 cost should be really very small 18:20:57 <notting> _jakub_: any reason -g can't be aliased to -g3? 18:20:57 <jwb> nirik, no, i'm fine. +1 18:21:27 <_jakub_> notting: 1) it would be confusing 2) would break gcc testsuite badly (all the assembly scanning etc.) 18:21:28 <nirik> #agreed Feature is approved (+9/0) 18:21:56 <mitr> _jakub_: How does -g3 affect _FORTIFY_SOURCE? That sounds kind of unexpected 18:22:20 <_jakub_> mitr: from .debug_macro you can verify if things have been built with that macro or not 18:22:47 <mitr> Ah, ok 18:22:51 <_jakub_> mitr: thus automation can be added to catch e.g. the recent libreoffice building with -O0 and thus without fortification 18:23:20 <pjones> One more thing I'll have to change in all my 'doesn't run in linux' packages. 18:23:37 <nirik> #topic ticket 868 F18 Feature: MiniDebugInfo - https://fedoraproject.org/wiki/Features/MiniDebugInfo 18:23:37 <nirik> .fesco 868 18:23:42 <zodbot> nirik: #868 (F18 Feature: MiniDebugInfo - https://fedoraproject.org/wiki/Features/MiniDebugInfo) – FESCo - https://fedorahosted.org/fesco/ticket/868 18:24:03 <nirik> mmaslano was 0 in ticket. 18:24:24 <nirik> I'm -1. 18:24:28 <limburgher> Seemed. . .mildly contentious. . . 18:24:34 <mitr> I think the only technical objection was that spins won't fit on a CD, but when repeatedly asked nobody came up with an example user/ambassador saying that CDs are needed 18:24:54 <mezcalero> nirik: out of curiosity, why do you say -1? 18:25:17 <notting> i am +1. obviously would need to be coordinated with any dmz -related rebuilding 18:25:21 * pjones is also +1 18:25:33 <nirik> I don't think the extra size is worth the gain. I think we can/should work on making abrt better. 18:25:34 <hughsie> i don't know if i should comment, but from my role as an upstream maintainer, this would be *really* useful for real life debugging from end users... 18:25:44 <limburgher> mitr: Would dwarf compression help that? 18:25:48 <jwb> i'm marginally +1 18:25:55 <pjones> limburgher: no - different set of fields 18:25:56 <mitr> limburgher: _jakub_ said above that it is orthogonal 18:25:57 <t8m> as long as it does not replace full backtraces reported in ABRT I'm ok with it so marginally +1 18:26:11 <mitr> AFAICS this "only" benefits developers and reading crashes in unexpected components, but given Fedora's target arudence, +21 18:26:14 <mitr> +1 that is 18:26:16 <limburgher> mitr, pjones: Missed that, thanks. 18:26:22 <limburgher> Ok. +1 18:26:24 <mjg59> I lean +1 18:26:43 <mitr> nirik: My best guess is that abrt will just ignore this. 18:26:57 <nirik> #agreed Feature is approved. (+7/-1/0) 18:27:01 <_jakub_> I don't see what minidebuginfo gives us as advantage for bugreporting, in theory all you need is addresses (relative to start of DSOs) and their build-ids, everything can be recomputed from that 18:27:03 <limburgher> I wish spins could stay on CDs, but then I still want CD and floppy install media. <stares wistfully into the past> 18:27:13 <nirik> This also needs mass rebuild? 18:27:14 <jwb> i was hoping it would light a proverbial fire under abrt's arse 18:27:27 <gholms> Heh 18:27:31 <mitr> nirik: yes 18:27:37 <jwb> _jakub_, mostly it's that nobody has gotten around to doing that yet. 18:27:40 <notting> apologies, i have to go. (will leave window open for reading later) 18:27:43 <nirik> ok. 18:27:52 <nirik> have a good one notting... 18:27:56 <nirik> #topic ticket 869 F18 Feature: Offline Updates using systemd and packagekit - https://fedoraproject.org/wiki/Features/OfflineSystemUpdates 18:27:57 <nirik> .fesco 869 18:27:58 <zodbot> nirik: #869 (F18 Feature: Offline Updates using systemd and packagekit - https://fedoraproject.org/wiki/Features/OfflineSystemUpdates) – FESCo - https://fedorahosted.org/fesco/ticket/869 18:28:12 <_jakub_> jwb: I thought the abrt server is capable of doing such textual replacement, just nothing generates such backtraces yet 18:28:18 * hughsie pings mezcalero 18:28:18 <mitr> _jakub_: I think it is primarily helpful when not reporting a bug, but wanting to diagnose a crash locally quickly (without waiting on a debuginfo download) 18:28:42 <_jakub_> anyway, when would be the mass rebuild planned for? 18:28:52 <nirik> sure, +1 here I guess, as long as it only affects desktop machines/etc... I don't think it's ideal, but I understand the reasoning. 18:29:06 <nirik> _jakub_: we need to coordinate with dgilmore on that. 18:29:10 <nirik> _jakub_: I'll file a rel-eng ticket to track it. 18:29:10 <mezcalero> hughsie: pong 18:29:24 <hughsie> mezcalero, see title. :) 18:29:24 <mitr> Hm. In general controlled updates are probably the right tradeoff, but yum/rpm maintainers wanted a discussion about doing this in a different layer 18:29:33 <_jakub_> if possible I'd like to see the dwz changes in rawhide for a fortnight or so before rebuilding everything 18:29:44 <mezcalero> hughsie: yupp, i am following ;-) 18:29:44 <limburgher> _jakub_: +1 18:29:51 <hughsie> mitr, i'm aiming this to be for all distros, not just Fedora 18:29:58 <hughsie> it's a GNOME3 feature, afterall 18:30:19 <mitr> hughsie: That's a concern for Fedora, but should not be the primary concern. 18:30:20 <nirik> _jakub_: when would that be ready to land? 18:30:35 <limburgher> hughsie: I'm a user, I understand the benefits, how do I turn it on and off? 18:30:43 <hughsie> limburgher, gpk-prefs 18:30:44 <mitr> hughsie: From what I've read so far, desktop-level sounds right, but I haven't seen any arguments for the lower levels so far 18:31:19 <hughsie> limburgher, the "automatically install" combo becomes "automatically download" 18:31:30 <limburgher> hughies: So if I don't have PK installed, it's a NOOP? What about upgrades? Will my f17 start doing this once I upgrade to f18? 18:31:32 <hughsie> if stuff is never autodownloaded, then there's never any new ui shown 18:31:43 <cwickert> hughsie: just to be clear about this: will I still be able to update "OS components" with gpk-update-viewer and without reboot? 18:31:58 <mjg59> hughsie: This doesn't seem entirely clear from the description - would all packages be updated in the offline mode, or only a subset? 18:31:59 <hughsie> limburgher, it's a noop for non-PK sure. Upgrades would have to be handled i guess. 18:32:08 <mjg59> hughsie: Ie, would some set of packages still be installed at runtime? 18:32:12 <hughsie> mjg59, just the ones that were idle-downloaded 18:32:18 <t8m> I partially agree with the argument that this encourages proliferation of applications that are broken if running during upgrades. 18:32:24 <hughsie> mjg59, only runtime would be applications that are not currently running 18:32:24 <limburgher> hughsie: Right. If I don't have PK, I don't want to upgrade and find that I now have it. 18:32:34 <hughsie> limburgher, sure, agree 18:32:51 <hircus> hughsie: it'd pull in packages that are dependent on specific versions of system packages that get updated, right? 18:32:52 <cwickert> mjg59: the definition of "application" is "whatever has a desktop file and shows up in the menu". these apps can still be updated 18:32:53 <mjg59> hughsie: If I'm running firefox and an update gets downloaded then it won't update, but if I'm not running firefox it will? 18:32:58 <hughsie> t8m, i think we're deluding ourselves if we think live-updating is working now... 18:33:03 <nirik> _jakub_: https://fedorahosted.org/rel-eng/ticket/5222 if you want to cc/add your scheduling. 18:33:17 <hughsie> mjg59, the live update stuff is only done by user action 18:33:26 <hughsie> i.e. in the updater GUI 18:33:27 <t8m> hughsie, sure it does not work perfectly but at least sometimes does 18:33:35 <mjg59> hughsie: Not following you now 18:33:46 <mjg59> hughsie: Ah, ok, I see 18:33:49 <hughsie> t8m, the time it breaks, i get to sort out the bugzilla 18:34:05 <mitr> t8m: I think if we want updates without reboots to work reliably, it would be necessary to start from the other end: figure out a heuristic for _reliably_ identifying things that can be updated without reboot - and then gradually expand that heuristic to handle larger and larger shares packages. _If_ someone is interested enough to do that. 18:34:15 <mjg59> hughsie: Is it possible for a package to indicate that it can support in-place updates? 18:34:44 <hughsie> mjg59, at the moment, no, but we're planning to add extra metadata to desktop files in the future for the Application installer, so it's easy to do that then 18:35:03 <hughsie> we just have to specify stuff like how to shut the app down saving state and how to bring it back up restoring state 18:35:18 <hughsie> assuming not everything uses GtkApplication 18:35:22 <mjg59> hughsie: Ok, so the assumption will be "Packages must opt-in to automatic runtime updates", and never "Packages must opt-out"? 18:35:22 <hughsie> that's F19+ tho 18:35:28 <hughsie> right 18:35:32 <mjg59> Ok 18:35:38 <mjg59> Well I look forward to that glorious future 18:35:47 <mjg59> It does sound more workable than what we have today 18:36:02 <hughsie> you and me both. For the GtkApplication stuff we can do a lot of stuff automatically -- i.e. send signals 18:36:17 <hughsie> for stuff like openoffice and firefox it'll be harder 18:36:26 <hughsie> so that's not part of this feature 18:36:39 <mjg59> Ok, so I'm +1 18:36:42 <mezcalero> tbh i doubt we could ever flag more than documentation packages as "don't need offline upgrade", simply because the many indirections of our stack 18:37:20 <hughsie> also, restarting firefox again is kinda hard when it's running for two different users on the same machine 18:37:20 * nirik checks for votes... I see +2? 18:38:05 * mitr isn't sure what to do about the yum/rpm developers concerns 18:38:22 <mitr> I'm leaning towards +1, given that there's little specific to go on... 18:38:37 <hughsie> panu was pretty clear he didn't want process parsing stuff in rpm, has that changed? 18:38:45 <nirik> mitr: well, I think the thought is that they could setup something like this is they wished? 18:39:04 <nirik> well, in yum... perhaps a plugin? yum-apply-updates-reboot ? 18:39:16 <hughsie> nirik, you need a session component too 18:39:29 <nirik> true... 18:39:34 <mitr> nirik: Having two different mechanisms queue the same set of updates sounds risky 18:39:37 <nirik> in any case thats beyond the scope of this feature? 18:39:41 <hughsie> right 18:40:15 <jwb> +1 18:40:16 * nirik is still +1 18:40:33 <nirik> so, thats +4? more votes? 18:40:35 <pjones> yeah, weak +1 18:40:49 <mitr> weak +1 as well, I suppose. 18:41:10 <mitr> (For the record, the snapshot/restore idea doesn't sound at all practical, but that's not a current concern.) 18:41:33 <t8m> +0 for historical and cultural reasons :) 18:41:44 <nirik> #agreed Feature is approved (+6/-1/0) 18:41:59 <nirik> #topic ticket 870 F18 Feature: SELinux Booleans Rename - https://fedoraproject.org/wiki/Features/SELinuxBooleansRename 18:42:00 <nirik> .fesco 870 18:42:02 <zodbot> nirik: #870 (F18 Feature: SELinux Booleans Rename - https://fedoraproject.org/wiki/Features/SELinuxBooleansRename) – FESCo - https://fedorahosted.org/fesco/ticket/870 18:42:07 <mezcalero> mitr: i'd probably make use of the snapshot stuff right from day 1 on actually. i.e. do a rwahide upgrade, see if it boots, if not, revert 18:42:28 <nirik> mmaslano is +1 in ticket on this one. 18:42:32 <jwb> so is this something that just needs to happen, or is there a PR component that would make it a feature? 18:42:33 <nirik> I'm +1 as well. 18:42:40 <t8m> +1 18:42:40 <mitr> mezcalero: losing log file contents, state (especially clustered/replicated databases would be fun), ...? 18:42:46 * pjones +1 18:42:52 <nirik> jwb: yeah, more noise to let users know that it's changed... etc. 18:43:03 <hughsie> mezcalero, surely that implies btrfs on / by default? 18:43:04 <mezcalero> mitr: sure, for my rawhide upgrades, i'd be totally happy! 18:43:04 <pjones> jwb: I think it's just a matter of keeping people using sebool informed 18:43:05 <mitr> +1 18:43:16 <jwb> i don't see why this can't just be a ticket with the docs people 18:43:20 <jwb> but whatever. +1 18:43:23 <mitr> mezcalero: right, it makes much more sense for rawhide 18:43:34 <mezcalero> mitr: in fact i currently do this with qemu -snapshot all the time 18:43:45 <mezcalero> mitr: i, test boot a qemu VM, and drop all changes 18:44:04 <mezcalero> mitr: with btrfs snapshots in the loop i could actually test boot the real hw the same way! 18:44:38 <mezcalero> hughsie: well, this was mostly referring to my own use, but yes, sooner or later i hop for btrfs on / for everybody by default... 18:45:06 <limburgher> +1 18:45:18 <nirik> #agreed Feature is approved (+7/0) 18:45:30 <nirik> #topic ticket 871 F18 Feature: SysV to systemd - https://fedoraproject.org/wiki/Features/SysVtoSystemd 18:45:30 <nirik> .fesco 871 18:45:41 <zodbot> nirik: #871 (F18 Feature: SysV to systemd - https://fedoraproject.org/wiki/Features/SysVtoSystemd) – FESCo - https://fedorahosted.org/fesco/ticket/871 18:45:58 <nirik> mmaslano is +1 in ticket 18:46:23 <nirik> This is a continuation of this feature since f15 I guess... 18:46:29 <limburgher> +1 publicity 18:46:36 * nirik is +1 here, hope we someday finish 18:46:39 <tibbs|w> Still says "Fedora 17" in one place. 18:46:41 <mitr> +1 18:46:45 <pjones> I'm sorry, I fell asleep. 18:46:47 <jwb> -1 18:47:14 <pjones> I really don't see any reason this needs to be a "Feature". Again. 18:47:18 <jwb> exactly 18:47:20 <nirik> jwb: for lack of featureyness? 18:47:32 <jwb> yes. also, for it being submitted since f15 and still not done 18:47:39 <t8m> +1 18:47:42 <tibbs|w> Note that packaging guidelines do not forbid the use of old-style initscripts. 18:47:43 <jwb> i mean, the work is great and needed but damn 18:47:50 * mezcalero is mildly surprised that his name is on the feature page, but is not opposed ;-) 18:48:04 <Viking-Ice> last relese cycle nirik requested this to be submitted again for the feature process hence I did it yet again 18:48:33 <nirik> Viking-Ice: do you think it's helped get people assisting to be a feature? or hasn't mattered? 18:49:14 <Viking-Ice> it helps having this as a feature but with regards to man power not so much 18:50:14 <nirik> how does having it a feature help? if it does I'm happy to approve it again... if it doesn't, perhaps we shouldn't bother? 18:50:42 <Viking-Ice> mezcalero, you agreed to be on that feature in f15 and this is the same page s/15/16 etc.. I can remove you from it if you so wish 18:51:03 <mezcalero> Viking-Ice: no, leave me on it! 18:51:11 <mezcalero> Viking-Ice: i am am a fan of this, totally 18:51:24 <mezcalero> Viking-Ice: in fact i wished i had more time (could fork() myself) to spend more time on this, too 18:51:30 <Viking-Ice> nirik, it helps being backed by fesco from maintainers perspective 18:51:48 <nirik> ok, I'm happy to still be +1 then. 18:52:01 <nirik> so, thats +5/-1 ? 18:52:04 <mjg59> +1 18:52:04 <nirik> any other votes? 18:52:08 <Viking-Ice> btw we are at "m" http://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd-F17 18:52:26 <pjones> I'm still not really seeing the utility, so I'll stick with +0 since it's going to pass anyway. 18:52:43 <nirik> #agreed Feature is approved (+6/-1/0) 18:52:52 <nirik> #topic ticket 872 F18 Feature: systemd unit cleanup and enhancement - https://fedoraproject.org/wiki/Features/Systemd-unit-cleanup 18:52:53 <nirik> .fesco 872 18:52:58 <zodbot> nirik: #872 (F18 Feature: systemd unit cleanup and enhancement - https://fedoraproject.org/wiki/Features/Systemd-unit-cleanup) – FESCo - https://fedorahosted.org/fesco/ticket/872 18:53:17 <nirik> mmaslano was -1 in the ticket. 18:53:53 <t8m> I am also not convinced here -1 18:53:58 <mitr> -1 as well - removing /etc/sysconfig/* files is an anti-feature 18:54:22 <nirik> is there a replacement for the /etc/sysconfig files? just that the application/package needs to handle things better? 18:54:24 <mezcalero> removing /etc/sysconfig/ needs support from upstream i guess 18:54:27 <pjones> I don't see the featuryness here, and also those problems. 18:54:30 <limburgher> I'm -1. I see no point in breaking sysconfig. I'd like to see it gone, and don't want packages which don't use it to start, but removing it now is premature unless you're willing to patch the daemons involced. 18:54:46 <mezcalero> i.e. the individual packages need to support proper config files upstream, before we can drop support for the sysconfig hacks 18:55:01 <mezcalero> but otherwise i am all in favour of Viking-Ice's feature! 18:55:05 <tibbs|w> The replacement for sysconfig is editing a copy of the unit file copied to /etc. 18:55:30 <Viking-Ice> well arguably those files should be placed in their own directory under /etc 18:55:36 <nirik> tibbs|w: with specific env stuff added? 18:55:53 <tibbs|w> That's what I did for the packages of mine I converted to not have sysconfig files. 18:56:00 <Viking-Ice> relevant to their package and we point the environment file reference to that directory instead 18:56:10 * nirik is sort of 0 on this... it's stuff that would be great to do, but not sure it's really a feature. 18:56:10 <mitr> tibbs|w: Ironically, creating such a copy with /env has high risk of negating the other aspects of the feature (because whatever is changed in /lib will not be propagated into /etc) 18:56:25 <tibbs|w> Yep. 18:56:41 <alexlarsson> Sorry I got here a bit late, but since I'm the MiniDebugInfo guy, please direct any questions you have to me 18:56:52 <mezcalero> alexlarsson: your feature got accepted! yay! 18:56:58 <alexlarsson> yay! 18:57:20 <nirik> more votes, or comment on this feature? I see -4/0 so far. 18:57:22 <mezcalero> hmm, so the people who voted -1 on Systemd-unit-cleanup so far, is this only because of the sysconfig thing? 18:57:34 <alexlarsson> I guess i can continue taping plastic over my car window that got smashed :( 18:57:44 <mezcalero> i'd propose that the sysconfig bit is removed then, and would like to ask for another vote 18:58:00 <nirik> alexlarsson: also, see https://fedorahosted.org/rel-eng/ticket/5222 for scheduling on mass rebuilding. 18:58:12 <mezcalero> alexlarsson: btw, the feature was pretty nicely accepted +6, -1 18:58:43 <mezcalero> alexlarsson: i'd read that as clear support from fesco ;-) 18:58:43 <alexlarsson> Is the dwarf compressor also accepted? 18:58:48 <jwb> alexlarsson, yes 18:58:54 <mitr> mezcalero: Well, having a "cleanup systemd files" feature when "convert to systemd" has not even finished is kind of strange - I wouldn't want a "change all systemd unit files" to become a regular feature - but yes, removing the sysconfig bit would make it acceptable to me 18:58:55 <pjones> mezcalero: also because of lack of featuryness. 18:59:10 <limburgher> mitr: Me as well. 18:59:52 <mitr> mezcalero: At least with the understanding that the feature owner will find people interested enough to do the work. I don't think it's beneficial enough to require every developer to do this for their own packages. 18:59:56 <t8m> I think any changes of systemd units should be handled through package guidelines changes and not through feature process 18:59:57 <mezcalero> Viking-Ice: but, anyway, you are in charge, i'd remove the sysconfig bit for now though, this really needs more support from upstream in most cases i guess 18:59:59 <limburgher> pjones: Exactly. It's good work to do, great in fact, but it's more incremental than "Oooh, neat, look what f18 gives us that f17 didn't" 19:00:03 <mezcalero> Viking-Ice: and thanks for proposing this! 19:00:09 <mitr> t8m: That's a good point as well. 19:00:27 <nirik> so, -2, +2, 0 currently? any vote changes or more votes? 19:00:37 <jwb> i find the fact that this feature is getting -1 votes and the one before it didn't to be hilarious 19:00:42 * pjones is -1 , which he counts at -4 including himself 19:00:45 <mitr> The original systemd unit guidelines bypassed the FPC, let's not make a habit out of this 19:00:46 <jwb> -1 19:00:51 <nirik> jwb: yeah 19:00:53 <Viking-Ice> well we need to do this clean-up anyway to get units in sync with upstream systemd changes but arguably as mitr points out this should be done *after* we have migrated all units 19:00:59 <mjg59> I think -1 19:01:07 <pjones> so far I see t8m, mitr, limburgher, jwb, pjones, mjg59 as -1 19:01:21 <pjones> and mmaslano of course 19:01:40 <mitr> Viking-Ice: I am primarily pointing out that it should not be necessary to "get units in sync". There should be compatibility etc. 19:01:47 <nirik> pjones: mitr and limburgher were +1 after the dropping of /etc/sysconfig? or was that too stong a reading of vote change? 19:02:08 <Viking-Ice> mezcalero, but this is work ofcourse that could be combined with the preset feature should you decide to submit that for this release cycle 19:02:16 <mitr> pjones: I'd be +1 1) without /etc/sysconfig, and 2) after FPC accpets to change the guidelines 19:02:16 <pjones> nirik: I guess we'll have to ask them. 19:02:27 * nirik nods. waits. 19:02:27 <pjones> mitr: so that means you're -1 right now? :) 19:02:33 <mezcalero> Viking-Ice: preset was declined by fesco once, and i actually can understand why fesco did that 19:02:34 <limburgher> nirik: +1 to mitr's 1 and 2. 19:02:49 <mezcalero> Viking-Ice: and i need to do my homework on preset first, too, and get that through FPC 19:02:52 <mitr> pjones: well, 2) is a blocking condition, but not a prerequisite to me voting +1 19:02:56 <mezcalero> Viking-Ice: so my path for preset is FPC, not FESCO 19:03:14 <nirik> ok, so thats -8/0? 19:03:15 <Viking-Ice> mitr, it's better to clean unnecessary bits from the ( early ) submitted units 19:04:02 <mitr> mezcalero: Did you (or anyone else) follow up on the smarter RPM scriptlets (categories?collections) in connection to presets? 19:04:09 <t8m> Viking-Ice, but do you need a feature for that? 19:04:36 <nirik> #agreed Feature is not approved at this time. (-7/0) 19:04:51 <tibbs|w> FPC can fix up the guidelines quickly if someone gives us a draft. 19:05:00 <mezcalero> mitr: well, i haven't put together any new scriptlets yet, i need to do that 19:05:06 <Viking-Ice> t8m, for the /etc/sysconfig/foo files removal I believe so without it not so much 19:05:10 <mezcalero> mitr: which i will then submit to FPC 19:05:33 <nirik> #topic Next week Chair 19:05:39 <tibbs|w> Not sure how RPM collections gets wrapped up with that, though. 19:05:39 <mezcalero> Viking-Ice: btw, as I saw FPC now has adopted changes already to outlaw After=syslog and StandardOutput=error 19:05:49 <nirik> who wants to chair next week? 19:05:49 <Viking-Ice> we also need to fix file permissions on the submitted units ( some of them are wrong ) 19:05:51 <mezcalero> Viking-Ice: so the FPC bits on that already got accepted 19:06:03 <mitr> I can chair next week 19:06:17 <nirik> note: I will be gone next meeting, and the meeting after. I might vote in tickets if I can get net, we will see. ;) 19:06:29 <t8m> Viking-Ice, also maybe you could merge cleanup of old and finishing up new units to one feature 19:06:31 <mezcalero> Viking-Ice: we should probably file a but to FPC to add the Documentation= suggestion to the packaging guidelines, but we should probably discuss that outside of this channel ;-) 19:06:36 <nirik> #info mitr to chair 2012-06-25 meeting. 19:06:37 <mezcalero> s/but/bug 19:06:39 <nirik> thanks mitr 19:06:53 <nirik> #topic Open Floor 19:07:09 <nirik> any business for open floor? 19:07:13 <mitr> mezcalero: _rpm_, not _FPC_. See the logs from the meating ~5 months ago that has rejected the presets feature 19:07:44 <mezcalero> mitr: hmm, what was that about? 19:08:52 <mitr> mezcalero: Not doing per-package scripts at all 19:09:00 <jwb> proposal: end the meeting 19:09:06 <nirik> :) 19:09:14 <nirik> if nothing else will close out in a minute. 19:09:25 <JSchmitt> poweroff 19:09:32 <pjones> that's the spirit. 19:09:38 <nirik> #endmeeting

1 0

FAmSco meeting 2012-06-18 minutes
by Christoph Wickert 18 Jun '12

18 Jun '12

My fellow ambassadors, the newly elected FAmSCo just held it's very first meeting. Sorry I did not send out a reminder earlier, but I was a bit confused about the new meeting time myself. We have now settled for Monday at 17:00 UTC in #fedora-meeting-2. And believe it or not, all 7 FAmSCo members were present and we had a very productive meeting. I was re-elected as FAmSCo chair and appointed Daniel Bruno as vice-chair. I am looking forward to work with the new FAmSCo and I hope we can keep up the pace and attendance. Minutes: http://meetbot.fedoraproject.org/fedora-meeting-2/2012-06-18/famsco.2012-06… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-2/2012-06-18/famsco.2012-06… Log: http://meetbot.fedoraproject.org/fedora-meeting-2/2012-06-18/famsco.2012-06… Meet you again next week Monday June 25th at 17:00 UTC in #fedora-meeting-2! Regards, Christoph ==================================== #fedora-meeting-2: FAmSCo 2012-06-18 ==================================== Meeting started by cwickert at 17:01:26 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-2/2012-06-18/famsco.2012-06… . Meeting summary --------------- * Roll Call (cwickert, 17:01:45) * Announcements (cwickert, 17:08:13) * We have a new FAmSCo: Christoph Wickert, Jiri Eischmann, Clint Savage, Nick Bebout, Alejandro Perez, Daniel Bruno, Buddhika Chandradeepa Kurera (cwickert, 17:09:06) * Fedora Board Runoff Election is open till tomorrow, vote either nb or evilbob at https://admin.fedoraproject.org/voting/about/runoffboardf18 (cwickert, 17:10:06) * AGREED: new FAMSCo meeting time is Monday at 17:00 UTC (cwickert, 17:14:49) * new FAMSCo meeting time is Monday at 17:00 UTC (cwickert, 17:14:54) * Election of the FAmSCo Chairs (cwickert, 17:19:44) * LINK: https://fedoraproject.org/wiki/FAmSCo_election_rules (cwickert, 17:19:50) * AGREED: cwickert is the old and new FAmSCo chair (cwickert, 17:24:00) * danielbruno is new FAmSCo vice-chair (cwickert, 17:31:25) * Funding for fvollero for EuroPython (cwickert, 17:33:37) * #297 can be closed, fvollero receives funding from his employer (cwickert, 17:34:51) * Funding for jreznik for LinuxTag 2012 (cwickert, 17:35:18) * AGREED: #292 is approved (cwickert, 17:37:13) * Budget review guidelines (cwickert, 17:37:33) * ACTION: aeperezt to ask for feedback about #281 on the LATAM mailing list (cwickert, 17:51:50) * ACTION: all FAmSCo members to discuss #281 with their local communities and provide feedback in the trac ticket (cwickert, 17:52:52) * AGREED: : for now we go with 4 levels (0-499, 500-1999, 2000-5000, 5000+) and allow the regions to make their own rules. 5 ambassadors should be rule of thumb for regional meetings, but exceptions may be granted per region (cwickert, 17:54:20) * Funding for fvollero for EuroPython (redux) (cwickert, 18:08:44) * AGREED: #297 is approved, fvollero receives full funding for accommodation at EuroPython, that is 425 EUR (cwickert, 18:15:38) * Open Floor (cwickert, 18:15:52) Meeting ended at 18:24:23 UTC. Action Items ------------ * aeperezt to ask for feedback about #281 on the LATAM mailing list * all FAmSCo members to discuss #281 with their local communities and provide feedback in the trac ticket Action Items, by person ----------------------- * aeperezt * aeperezt to ask for feedback about #281 on the LATAM mailing list * **UNASSIGNED** * all FAmSCo members to discuss #281 with their local communities and provide feedback in the trac ticket

1 0

Docs meeting summary -- 18 June 2012
by Ben Cotton 18 Jun '12

18 Jun '12

Meeting summary --------------- * Roll Call (bcotton, 14:00:28) * Follow up on last week's action items (bcotton, 14:04:04) * ACTION: bcotton to draft QA Wrangler role description (bcotton, 14:04:21) * ACTION: Sparks to follow up to mailing list about using koji to publish docs.fp.o (bcotton, 14:06:04) * ACTION: Sparks to file the ticket re: publishing with koji (bcotton, 14:06:14) * ACTION: Sparks to take man page website to mailing list (bcotton, 14:06:36) * Sparks has completed to file the ticket re: publishing with koj (bcotton, 14:07:21) * Using koji to publish docs.fp.o (bcotton, 14:07:38) * Publish man pages (bcotton, 14:25:32) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=828669 (bcotton, 14:28:02) * QA recap (bcotton, 14:29:24) * LINK: https://fedoraproject.org/wiki/Docs_QA_Procedure (bcotton, 14:29:44) * Open floor discussion (bcotton, 14:52:01) Meeting ended at 14:58:24 UTC. Action Items ------------ * bcotton to draft QA Wrangler role description * Sparks to follow up to mailing list about using koji to publish docs.fp.o * Sparks to take man page website to mailing list Action Items, by person ----------------------- * bcotton * bcotton to draft QA Wrangler role description * Sparks * Sparks to follow up to mailing list about using koji to publish docs.fp.o * Sparks to take man page website to mailing list * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * bcotton (53) * Sparks (24) * lnovich1 (13) * mprpic (10) * lnovich (7) * daydrim (5) * pkovar (5) * sgordon (3) * zodbot (3) * jhradilek (3) * _logan (1) * ianweller (1) * jjmcd (1) * jsmith (1) Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2012-06-18/fedora_docs.2012… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2012-06-18/fedora_docs.2012… Log: http://meetbot.fedoraproject.org/fedora-meeting/2012-06-18/fedora_docs.2012… -- Ben Cotton Fedora Docs Leader

1 0

Cloud SIG Meeting Minutes :: 2012-06-15
by Robyn Bergeron 15 Jun '12

15 Jun '12

Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2012-06-15/cloud_sig.2012-0… Logs: http://meetbot.fedoraproject.org/fedora-meeting/2012-06-15/cloud_sig.2012-0… ========================== #fedora-meeting: Cloud SIG ========================== Meeting started by rbergeron at 19:00:13 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-06-15/cloud_sig.2012-0… . Meeting summary --------------- * Roll Call, yo! (rbergeron, 19:00:28) * gholms, tdawson, mdomsch, jzb, mrunge (if you're here for cloud, if not, Hi!) present (rbergeron, 19:03:05) * Features! Who's got em (rbergeron, 19:04:36) * Feature submission deadline is 2012-07-24; Feature Freeze is 2012-08-07 (rbergeron, 19:05:31) * Euca will be shooting for F18 (rbergeron, 19:05:58) * hoping for CS as well. (rbergeron, 19:07:14) * LINK: https://fedoraproject.org/wiki/Features/OpenShift_Origin (rbergeron, 19:09:10) * rubygem-passenger review stalled on licensing questions (gholms, 19:10:11) * but OSO is still optimistic about F18 :) which is good! (rbergeron, 19:12:42) * russellb mentions that pbrady has said that he was going to start work on a folsom feature page for F18 (rbergeron, 19:14:57) * Cloud SIG FAD (rbergeron, 19:16:19) * Cloud Interop FAD is the idea - taking things like openstack, eucalyptus, etc. that are in or going to be in fedora, and then also things like plans to have openshift in fedora (rbergeron, 19:26:05) * and then combining the two (rbergeron, 19:26:17) * LINK: http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Clo… (rbergeron, 19:49:10) * Open Floor (rbergeron, 19:52:52) Meeting ended at 19:57:55 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * rbergeron (157) * gholms (61) * tdawson (24) * jzb (13) * ke4qqq (7) * agrimm (6) * russellb (4) * zodbot (4) * jsmith (3) * mrunge (2) * mdomsch (1) * apevec (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Summary/Minutes from todays EPEL sig meeting (2012-06-15)
by Kevin Fenzi 15 Jun '12

15 Jun '12

================================== #fedora-meeting: EPEL (2012-06-15) ================================== Meeting started by nirik at 16:00:08 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-06-15/epel.2012-06-15-… . Meeting summary --------------- * init process/agenda (nirik, 16:00:08) * broken deps script for epel6 that needs to be cleaned up: http://fedorapeople.org/~kevin/epel-deps/spam-o-matic-el6 (nirik, 16:03:45) * Overlapping with RHEL (part 10) (nirik, 16:04:34) * LINK: http://vault.centos.org/6.2/os/Source/SPackages/ (Jeff_S, 16:25:09) * LINK: http://www.redhat.com/products/enterprise-linux-add-ons/ (abadger1999, 16:32:22) * LINK: http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages ). (nirik, 16:35:04) * Open Floor (nirik, 16:42:14) Meeting ended at 16:45:47 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (66) * Jeff_S (24) * abadger1999 (18) * smooge (14) * rbergeron (8) * zodbot (4) * dgilmore (2) * jzb (1) * tremble (0) -- 16:00:08 <nirik> #startmeeting EPEL (2012-06-15) 16:00:08 <zodbot> Meeting started Fri Jun 15 16:00:08 2012 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:08 <nirik> #meetingname epel 16:00:08 <zodbot> The meeting name has been set to 'epel' 16:00:08 <nirik> #topic init process/agenda 16:00:08 <nirik> #chair smooge tremble dgilmore 16:00:08 <nirik> EPEL meeting ping abadger1999 rsc stahnma tremble dgilmore smooge nb maxamillion tremble Jeff_S HackMan 16:00:08 <zodbot> Current chairs: dgilmore nirik smooge tremble 16:00:12 <smooge> here 16:00:19 <nirik> who all is around for a epel meeting? :) 16:00:59 <Jeff_S> . 16:01:10 <Jeff_S> I'd like to be a table since we have four chairs already 16:02:08 <nirik> ha 16:02:19 * abadger1999 here 16:03:12 <nirik> who all has topics? I assume we will poke more at the overlap issue as we always do. ;) 16:03:31 <Jeff_S> nothing else here... 16:03:45 <nirik> #info broken deps script for epel6 that needs to be cleaned up: http://fedorapeople.org/~kevin/epel-deps/spam-o-matic-el6 16:04:34 <nirik> #topic Overlapping with RHEL (part 10) 16:04:51 <nirik> so, where were we on this? abadger1999 sent a proposal to the list... 16:05:21 <nirik> there was a bunch of discussion. 16:05:56 <nirik> much of it was from what is a 'basic subscription. 16:06:52 <abadger1999> I think people on list disputed what went into "Basic Subscription", whether there's additional cost involved with addons, and whether we could/should split on Addons vs channels instead of basic subscription. 16:06:59 <nirik> and some was things that seemed to go much more high level and just confused me. ;) 16:07:05 <nirik> yeah 16:07:57 <nirik> perhaps we could try and answer those questions via talking with Red Hat support folks. 16:08:17 <smooge> I think we keep it simple and say we have /en/os and we added two extra channels. If people have a problem iwth that then EPEL is not the project for them. 16:09:37 * nirik re-reads thread 16:11:12 <nirik> smooge: I agree that would be easiest. 16:12:29 <nirik> so, I think the 'base subscription' thing is just not going to help us any... perhaps we should drop trying to use that. 16:12:50 <smooge> yeah. It looks like it depends on when, who and what was bought. 16:13:28 <abadger1999> <nod> 16:14:15 <nirik> dgilmore: any more luck finding channel owners? or thats all unknown still? 16:14:18 <rbergeron> (is this still loosely about the puppet thing?) 16:14:25 <nirik> rbergeron: somewhat. 16:14:27 <Jeff_S> and centos includes more than "/en/os and we added two extra channels."? 16:14:30 <dgilmore> nirik: still unknown 16:14:36 * rbergeron is happy to help run people down 16:14:37 <rbergeron> or chase down 16:14:44 <rbergeron> i suppose running down sounds pretty bad :) 16:14:44 <nirik> rbergeron: it's about what epel will allow in it's repo. 16:14:51 <rbergeron> nirik: yeah, i got that part :) 16:14:52 * Jeff_S pictures rbergeron in her car running down channel owners 16:15:14 <nirik> the problem is we can't just say "nothing thats in RHEL' 16:15:24 <nirik> because there are eleventy gillion channels. 16:15:45 <smooge> Jeff_S, well what is in CentOS these days not counting Extras and such 16:16:25 <Jeff_S> smooge: not counting extras, correct. I think it's important to consider centos users as well. IMO more important than RHEL (yes, I said that!) 16:16:25 <rbergeron> is there a list of specific owners you're looking for or just "general list, whateve ryou can find" 16:17:40 <nirik> rbergeron: one of the thoughts was that we do 'nothing in base os/optional/lb/ha and if a channel owner of another channel requested it, we could add their channel packages to the list of 'don't ship these'' 16:18:07 <nirik> but for that to work channel owners would need to communicate with us and say "please don't ship channel-foobar packages in epel' 16:18:36 <rbergeron> okay 16:18:51 <rbergeron> dgilmore: is your list at 0 or started? 16:19:49 <nirik> this would mean channel owners could be disruptive if they started shipping a bunch of stuff epel users use and then asked us to stop shipping them, but I would hope they would be reasonable. 16:20:33 <dgilmore> rbergeron: ive been talking to stickster_afk 16:20:46 <Jeff_S> nirik: I don't think we could have a policy that puts channel owners in charge of what we ship. But we surely should consider their requests when reasonable 16:21:12 <nirik> Jeff_S: sure. I guess I was thinking case by case... 16:21:18 <Jeff_S> +1 16:21:20 <nirik> I don't think anyone wants to cause problems for others... 16:21:26 <Jeff_S> nirik: maybe just some people ;) 16:21:41 <nirik> at least I hope we can minimize problems caused by epel for both rhel and other distros. 16:22:12 <smooge> Jeff_S, my question was what is in Centos Core for 6 and how does it overlap with RHEL .. eg is it built out of just /en/os or does it pull in other channels. 16:22:49 <nirik> so, how about this: we rephrase the proposed thing to drop mentions of 'base subscription' and ask on list if anyone has better proposals if they don't like that one. 16:22:59 <Jeff_S> smooge: it's built out of everything that's shared publicly on ftp.redhat AFAIK. let me see if I can get a better definition 16:23:14 <nirik> Jeff_S: that would include a number of channels then... 16:23:19 <Jeff_S> indeed 16:23:38 <nirik> and things like puppet, mongodb, etc that are shipped by epel too. ;) 16:23:46 <Jeff_S> do we have numbers on what part of our user and/or developer base are using centos vs. rhel? 16:23:47 <abadger1999> I'd be interested in knowing if there's any thought about Addons vs other channels inside of RH. Are addons more stable/won't conflict with each other/have other characteristics that other channels don't? 16:23:50 * Jeff_S thinks not 16:23:51 <smooge> and stuff that conflicts within those channels :) 16:23:55 * nirik again wonders why there's been no complaints over the last year if overlaps are so common. 16:24:22 <nirik> abadger1999: I know some of the add ons ship the same packages... so they do overlap 16:24:29 <smooge> Jeff_S, no we don't. Unless CentOS starts shipping smolt or something :) 16:24:41 <Jeff_S> smooge: god(s) help us 16:24:47 <abadger1999> <nod> -- did we figure out if those are presently all the same versions, though? 16:25:09 <Jeff_S> http://vault.centos.org/6.2/os/Source/SPackages/ 16:25:11 <nirik> abadger1999: the one case I saw they were. 16:25:19 <Jeff_S> nirik: no mongo there for example 16:25:22 <nirik> but not sure if that was deliberate or not. 16:25:33 <abadger1999> <nod> 16:25:42 <nirik> Jeff_S: yeah, so I wonder if it's not just base + optional 16:25:52 <Jeff_S> nirik: I'll verify that and post to the list 16:25:59 <nirik> cool. that would be great 16:26:50 <nirik> abadger1999: would you be willing to try another proposal post? or would you like me to try? 16:26:59 <abadger1999> rpm --changelog might tell us. 16:27:16 <Jeff_S> abadger1999: hmm? 16:27:35 <abadger1999> (at leaset, if those packages in different addons had separate maintainers or not.) 16:28:30 <abadger1999> nirik: You can if you like. 16:28:38 <Jeff_S> :) 16:28:39 <nirik> sure, can try. 16:28:46 <abadger1999> I'd be okay with smooge's proposal. 16:29:10 <abadger1999> I'd be okay trying to s/Basic Subscription/Addons/ 16:29:40 <abadger1999> and see if people point out that Addons won't work either :-) 16:30:46 <smooge> well there are too many addons now.. 16:30:48 <nirik> yeah, it seemed it was unclear who got addons. 16:30:57 <nirik> and the addons confict with each other 16:31:15 <abadger1999> There's 6 addons listed on that page. 16:32:15 <Jeff_S> abadger1999: which page? 16:32:22 <abadger1999> http://www.redhat.com/products/enterprise-linux-add-ons/ 16:32:32 <Jeff_S> thanks 16:32:42 * abadger1999 not counting the extended lifecycle ones 16:34:19 <Jeff_S> all the marketing hurts my eyes 16:34:56 <nirik> ok, hows this: 16:34:58 <jzb> Jeff_S: it's sort of like an eclipse, you're not supposed to look directly at it. 16:35:02 <Jeff_S> lol 16:35:02 <nirik> "EPEL6 will not normally ship packages that are shipped already in the 16:35:03 <nirik> following RHEL channels: os, optional, lb, and ha. Any overlapping 16:35:03 <nirik> packages must be to provide binary packages on arches not provided by 16:35:03 <nirik> RHEL ( following: 16:35:04 <nirik> http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages ). 16:35:06 <nirik> Additional channels may be added to the above list on a case by case 16:35:08 <nirik> basis. " 16:35:58 <Jeff_S> seems like a reasonable start to me 16:36:01 <abadger1999> I'm not in love with it because there's no expectation of what may or may not be added in that. 16:36:16 <nirik> yeah, thats true. 16:36:26 <abadger1999> But I'd be okay with it since it basically starts us with what we want to do now. 16:36:55 <nirik> we could drop the last sentence, and just continue to discuss adding critera. 16:38:11 <nirik> or change it to "additional channels could be added based on a critera we have yet to decide." :) 16:38:53 <abadger1999> +1 to the second wording. 16:39:16 <nirik> at least then people know it's still being discussed and they could provide input on the method. ;) 16:41:19 <nirik> ok, I can send that out for more comment. 16:41:25 <nirik> anything else on this? 16:42:00 <smooge> not from me. 16:42:14 <nirik> #topic Open Floor 16:42:20 <nirik> anything for open floor? 16:42:22 <smooge> I just want to get done with this and move back to making packages versus argueing over the color and floorsize of my bikeshed 16:42:33 <smooge> I will have mediawiki119 out this weekend I hope 16:42:45 <smooge> I will also be end of lifing all mediawiki's before then 16:43:02 <nirik> smooge: cool. ;) 16:43:33 <nirik> oh, another FYI, I will be not here for the next two meetings... someone else could run them, or we could just skip them. Either way is fine with me. ;) 16:44:19 <smooge> I can run them 16:44:43 <nirik> smooge: cool. 16:44:43 <smooge> if we miss one we may never start again :) 16:44:56 <nirik> yeah, we are bad about that. ;) 16:45:03 <nirik> ok, if nothing else will close out the meeting in a minute. 16:45:44 <nirik> thanks for coming everyone 16:45:47 <nirik> #endmeeting

1 0

Summary/Minutes from today's Fedora infrastructure meeting (2012-06-14 at 18UTC)
by Kevin Fenzi 14 Jun '12

14 Jun '12

============================================ #fedora-meeting: Infrastructure (2012-06-14) ============================================ Meeting started by nirik at 18:00:00 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-06-14/infrastructure.2… . Meeting summary --------------- * Good morning Fedora (nirik, 18:00:01) * New folks introductions and Apprentice tasks. (nirik, 18:01:34) * LINK: http://fedoraproject.org/easyfix/ (nirik, 18:03:58) * Applications status / discussion (nirik, 18:07:20) * Sysadmin status / discussion (nirik, 18:14:05) * LINK: https:// doesnt work well on port 80 (dgilmore, 18:14:26) * assistance with s3 mirroring welcome. (nirik, 18:25:26) * help welcome to track down managed-keys dns warnings (nirik, 18:27:11) * epylog named module welcome to parse named logs. (nirik, 18:29:22) * FAD ? (nirik, 18:29:53) * ACTION: nirik will make a web page to collect possible attendees, flight costs and location / time prefs. (nirik, 18:37:54) * Upcoming Tasks/Items (nirik, 18:38:14) * Upcoming Tasks/Items (nirik, 18:38:23) * 2012-06-18 remove people with pkgdb bugzilla issues. (nirik, 18:38:24) * 2012-06-21 to 2012-07-04 Kevin is off on trains and boats. (nirik, 18:38:24) * 2012-06-26 Fedora 15 end of life. (nirik, 18:38:24) * 2012-06-28 Seth at jury duty. (nirik, 18:38:24) * 2012-07-05 nag fi-apprentices (nirik, 18:38:24) * 2012-07-12 drop inactive apprentices. (nirik, 18:38:26) * 2012-08-07 to 2012-08-21 F18 Alpha Freeze (nirik, 18:38:28) * 2012-08-21 F18 Alpha release. (nirik, 18:38:30) * Upcoming Tasks/Items (nirik, 18:39:30) * 2012-06-18 remove people with pkgdb bugzilla issues. (nirik, 18:39:30) * 2012-06-21 to 2012-07-04 Kevin is off on trains and boats. (nirik, 18:39:30) * 2012-06-26 Fedora 15 end of life. (nirik, 18:39:30) * 2012-06-28 Seth at jury duty. (nirik, 18:39:30) * 2012-07-05 nag fi-apprentices (nirik, 18:39:30) * 2012-07-12 drop inactive apprentices. (nirik, 18:39:32) * 2012-08-07 to 2012-08-21 F18 Alpha Freeze (nirik, 18:39:34) * 2012-08-21 F18 Alpha release. (nirik, 18:39:36) * Open Floor (nirik, 18:45:16) * cgit? (nirik, 18:50:42) * http::websites (nirik, 18:57:51) * iptables folks welcome to help with iptables revamp (nirik, 19:07:20) * Open Floor (^2) (nirik, 19:07:37) Meeting ended at 19:12:09 UTC. Action Items ------------ * nirik will make a web page to collect possible attendees, flight costs and location / time prefs. Action Items, by person ----------------------- * nirik * nirik will make a web page to collect possible attendees, flight costs and location / time prefs. * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (154) * skvidal (114) * mdomsch (28) * abadger1999 (13) * pingou (13) * ingm4r (12) * sdrfed17 (9) * relrod (5) * zodbot (4) * dgilmore (4) * lmacken (3) * sumitrai (2) * misc (2) * rossdylan (2) * threebean (1) * striker|rh (1) * smooge (0) * ricky (0) * CodeBlock (0) -- 18:00:00 <nirik> #startmeeting Infrastructure (2012-06-14) 18:00:00 <zodbot> Meeting started Thu Jun 14 18:00:00 2012 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:01 <nirik> #meetingname infrastructure 18:00:01 <zodbot> The meeting name has been set to 'infrastructure' 18:00:01 <nirik> #topic Good morning Fedora 18:00:01 <nirik> #chair smooge skvidal CodeBlock ricky nirik abadger1999 lmacken dgilmore mdomsch threebean 18:00:01 <zodbot> Current chairs: CodeBlock abadger1999 dgilmore lmacken mdomsch nirik ricky skvidal smooge threebean 18:00:11 * mdomsch is here 18:00:20 <nirik> who all is around for a exciting, thrilling, wonderous, fedora infrastructure meeting? 18:00:21 * skvidal is 18:00:23 * lmacken 18:00:27 * rossdylan is here 18:00:28 * ingm4r is 18:00:31 * threebean is here 18:00:48 <sdrfed17> Hi Team. I am Sudhir Menon from India (irc:sdrfed17). with 3yrs of experience in Linux Sys Administration and QA. Would like to contribute to Infrastructure Group. 18:01:02 <nirik> welcome sdrfed17 18:01:28 * ingm4r would like to join the team, too 18:01:33 <sdrfed17> thankyou nirik 18:01:34 <nirik> #topic New folks introductions and Apprentice tasks. 18:01:35 <nirik> If any new folks want to give a quick one line bio or any apprentices 18:01:35 <nirik> would like to ask general questions, they can do so now. Anyone? 18:01:56 <sumitrai> Hi everone I am sumit rai from India, (irc: sumitrai), I have RHCSA, and I would love to be a part of fedora community 18:01:57 <nirik> sdrfed17 / ingm4r: were you more interested in sysadmin tasks? or application development? 18:02:16 <sdrfed17> sysadmin task niik 18:02:41 <ingm4r> Short Line from me: My name is Ingmar (I'm from Germany), I'm working as a Sysadmin since ~5 years 18:02:55 <nirik> excellent. Lots of new folks today. ;) 18:03:02 <ingm4r> so I\m interested in sysadmin tasks, too :) 18:03:02 <sdrfed17> sysadmin task is the thing that i am more interested in, would also like to have my hands on application development as well 18:03:23 <sumitrai> I am interested in sysadmin task too. 18:03:26 <nirik> For the sysadmin side of things, take a look at https://fedoraproject.org/wiki/Infrastructure_Apprentice and if that sounds of interest to you, I can set you up after the meeting (see me in #fedora-admin) 18:03:49 <nirik> for application development, we have a number of apps we work on, and there's a list of easyfix items to look at: 18:03:58 <nirik> http://fedoraproject.org/easyfix/ 18:04:58 <nirik> so, we can get you all setup after the meeting. ;) 18:05:06 <nirik> any general questions right now? 18:05:15 <ingm4r> will do nirik 18:05:21 <ingm4r> not yet :) 18:05:40 <sdrfed17> looks good to me the apprentice part 18:05:42 <sdrfed17> nirik 18:06:27 <nirik> great. I can get you setup after the meeting. ;) 18:06:41 <ingm4r> that would be fine. 18:06:41 <nirik> do chime in with questions and comments as they come to you, and again welcome. 18:07:15 <sdrfed17> thank you we will be joining you @ fedora-admin after this meeting 18:07:20 <nirik> #topic Applications status / discussion 18:07:36 <nirik> abadger1999 / threebean / lmacken / pingou / relrod: any application news this week? 18:08:05 <abadger1999> nirik: Sorta sysadminy -- we're about to retire app01.dev :-) 18:08:06 <lmacken> nothing exciting 18:08:17 <nirik> abadger1999: hurray. 18:08:19 <abadger1999> the apps that were being tested on it have moved to pkgdb01.dev and fas01.dev 18:08:46 <nirik> is everyone happy with how staging works these days? is it better than when we had a staging branch? 18:08:46 <abadger1999> in the process, I updated them to use passwordless sudo and made the login/sudo group the commit group for the applications 18:09:05 <abadger1999> which were things we'd talked about migrating our dev boxes to do. 18:09:09 <abadger1999> Seems to be working out fine. 18:09:28 <pingou> worked a bit on HK and our student seems to make some progress as well 18:09:34 <nirik> we did have a upgrade to koji this week. ;) 18:09:46 <pingou> nirik: btw, what about python-bz ? any news ? 18:09:48 <nirik> pingou: cool. 18:09:57 <abadger1999> I think lmacken hit his first stg-was-nonintuitive issue this week (or last week) 18:10:17 <dgilmore> nirik: i have found one bug in koji i need to get fixed 18:10:31 <abadger1999> someone else had added an explicit stg module for something and then we couldn't figure out why committing to master wasn't showing up on stg. 18:10:40 <abadger1999> (in the modules/ directory) 18:10:47 <lmacken> abadger1999: yup, that was confusing at first. 18:10:59 <nirik> pingou: there is a 0.7.0 version. We should retest our stuff with it. 18:11:01 <abadger1999> Not sure if we can do anything about that except remember to check for that. 18:11:09 <nirik> abadger1999: ah yeah. I wonder if there's anything we can do about that... . 18:11:39 <pingou> nirik: release? 18:11:41 <pingou> in testing ? 18:12:06 <nirik> pingou: packages in fedora updates-testing. Looks like it's not been built for epel yet. 18:12:14 <pingou> ok 18:12:21 * pingou notes this on his todo 18:12:22 <nirik> I can do a scratch build if anyone wants 18:13:00 <nirik> ok, cool. 18:13:10 <nirik> dgilmore: what was the bug? in login? 18:14:05 <nirik> #topic Sysadmin status / discussion 18:14:06 <dgilmore> nirik: yeah the web login issue 18:14:15 <dgilmore> its adding a :80 to the url 18:14:24 <nirik> I thought I'd add a section about what sysadminy things we have done over the last week too. 18:14:26 <dgilmore> https:// doesnt work well on port 80 18:14:29 <nirik> dgilmore: ah, bummer. ;( 18:14:43 <nirik> we just finished last night a mass reboot... so everything should be up to date. 18:15:05 <nirik> skvidal revamped out dns this week. :) Please read the readme in the dns repo 18:15:26 <skvidal> if anyone wants to updats our dns SOP 18:15:28 <mdomsch> skvidal: that's huge 18:15:37 <skvidal> to point to the readme in the dns git repo 18:15:38 <mdomsch> thanks for your effort there 18:15:40 <skvidal> please feel free 18:15:52 <skvidal> mdomsch: thanks for that - I hope it will make us all less pained when it comes to proxy time 18:15:54 * nirik can do that. 18:15:59 <skvidal> s/proxy/proxy rotation/ 18:16:04 <nirik> yeah, I think it's less error prone for proxys. 18:16:10 <nirik> thanks for working on it skvidal 18:16:13 <skvidal> and it should be less error prone in general 18:16:21 <skvidal> it is VERY hard to get an invalid zone file past it 18:16:36 <skvidal> I hope 18:16:37 <skvidal> :) 18:16:41 <nirik> we also wiped out community01.dev and made a packages01.stg, which I think is mostly working now. 18:16:52 <mdomsch> I've got the S3 mirrors functional in 3 zones now (us-east-1, us-west-1, and us-west-2) 18:16:55 <nirik> yeah, which is something that had happened to us in the past. ;( 18:17:11 <mdomsch> and spent another few nights trying to beat hardlink handling into s3cmd sync 18:17:38 <nirik> mdomsch: any luck with that? 18:17:41 <mdomsch> once that's working, need to parallelize it on 2 dimensions: 1) multiple uploads per upload target 18:17:56 <mdomsch> 2) scan the local file system once, then multiple upload targets in parallel 18:18:06 <mdomsch> as it stands, we're beating the crap out of the netapps on every sync 18:18:18 <mdomsch> as it calculates md5sums on each file before checking in with S3 to see if it has it 18:18:46 <mdomsch> which is the last thing it needs right now - local tree md5sum caching 18:18:53 <nirik> perhaps we could pregenerate that? or get it from the repodata? 18:19:02 <nirik> does it have to be md5? 18:19:20 <mdomsch> unfortunately, yes, md5 only. S3 returns that as the ETAG 18:19:35 <skvidal> mdomsch: can you generate an md5sum file and go off of datestamp? 18:19:49 <skvidal> mdomsch: b/c datestamp should be a simple stat() hit and not a full file read like md5sum 18:19:54 <mdomsch> though I did just add stashing the md5 in the S3 per-file metadata, so could conceivably add another hash type 18:20:18 <skvidal> mdomsch: then you can assume the md5sum is the same, if the datestamp on the file is older than the last time you ran 18:20:33 <skvidal> (unless someone intentionally set the file mtime/ctime back) 18:21:01 <mdomsch> maybe.... 18:21:11 <mdomsch> definitely open to ideas to speed things up 18:21:39 <mdomsch> problem is, mtime/ctime is an easy stat() call locally, but it requires a full HTTP HEAD call for each target remote 18:21:48 <skvidal> mdomsch: you don't need to compare it to remote 18:21:48 <mdomsch> to get it out of the metadata 18:21:54 <skvidal> mdomsch: you just compare it to the last time you ran 18:21:57 <mdomsch> MD5 we get "for free" from the bucket list command 18:22:12 <skvidal> any file with a timestamp > than the last time you ran 18:22:15 <skvidal> you take an md5 of 18:22:25 <skvidal> s/file/local file/ 18:22:31 <skvidal> that way you're not hitting EVERY file on the netapp 18:22:38 <skvidal> only those newer than the last execution of your script 18:22:40 <mdomsch> skvidal: ah, yes 18:22:45 <skvidal> and when you're done 18:22:50 <skvidal> you store the md5sum of that file 18:22:56 <skvidal> so - if you need it for any reason 18:22:58 <skvidal> you have it 18:23:05 <mdomsch> yes, that's completely feasible 18:23:05 <skvidal> w/o rereading it from the file itself 18:23:47 <nirik> yeah 18:23:52 <mdomsch> that's exactly in line with what I was thinking 18:24:30 <skvidal> cool 18:24:31 <nirik> cool. Sounds like a number of optimizations possible... 18:24:40 <nirik> ok, moving on? 18:24:46 <mdomsch> so, if there are any new folks 18:24:49 <mdomsch> apprentices etc 18:24:59 <mdomsch> who know python and have time to monkey with it 18:25:06 <mdomsch> I'm very open to the help... 18:25:13 <nirik> excellent. 18:25:26 <nirik> #info assistance with s3 mirroring welcome. 18:25:39 <nirik> any other sysadmin stuff to note from this last week? 18:26:18 <skvidal> the bind managed-keys crap? 18:26:27 <skvidal> if anyone is familiar with named and dnssec 18:26:47 <skvidal> and can figure out why on every startup named belches out that it cannot find some managed-keys in dynamic/<long string> 18:26:55 <skvidal> i would be OVERJOYED to see a solution 18:27:11 <nirik> #info help welcome to track down managed-keys dns warnings 18:27:11 <skvidal> grep for managed-keys in the messages log of any of the nameservers 18:27:13 <skvidal> and you can see 18:27:49 <nirik> yeah, it's an odd one. ;( 18:28:34 <skvidal> an named epylog module 18:28:37 <skvidal> if anyone wants to write one 18:28:47 <skvidal> I'm sure we'd be happy to be a tester of it 18:29:22 <nirik> #info epylog named module welcome to parse named logs. 18:29:33 * nirik should file some of these for apprentice folks. ;) 18:29:53 <nirik> #topic FAD ? 18:30:18 <nirik> So, I sent out an email the other day to judge interest in holding a FAD (Fedora Activity Day). 18:30:27 <nirik> sounds like there is some interest. 18:30:38 <nirik> we need to try and isolate place and time and see who all can make it. 18:30:40 <pingou> I bet there is :) 18:31:08 <nirik> so, what I might do is make a wiki page, and ask people to sign up there and note their place/time prefs. 18:31:24 <nirik> and possibly ballpark costs of flying them to place X or something. 18:31:46 <skvidal> nirik: you know - fudcon in paris - we could colocate a fad w/that 18:31:51 <nirik> anyone have any further thoughts/ideas on this? is security a good topic? 18:31:56 <pingou> skvidal: +1 18:31:56 <skvidal> nirik: I'm sure I could convince eunice that we need to go to paris in the fall. 18:32:07 <nirik> skvidal: ha. yeah! 18:32:16 <pingou> but we should still be able to do one before if we like 18:33:06 <pingou> we should be able to get a room there 18:33:10 <nirik> If folks know of spaces that would be very low cost/free for us to gather at, we could consider them too. 18:33:13 <mdomsch> doubtful I could attend or be of much value for a security-focused FAD 18:33:23 <skvidal> mdomsch: you're always useful 18:33:53 <mdomsch> I think security is too broad though. I'd like to see a "we will accomplish 1, 2, and with a lot of luck, 3, in 2 days" 18:34:05 <nirik> mdomsch: you're always welcome. ;) 18:34:06 <nirik> yeah... 18:34:10 <mdomsch> I love the ideas on the list so far 18:34:31 <mdomsch> just trim it down to something achievable with a few people who can Get It Done 18:34:53 * pingou wonders about a webapp component 18:34:53 <nirik> yeah, I listed a bunch of possible things... 18:34:58 <pingou> but then it would be 2 groups 18:35:07 <nirik> I think the list is too long to get done all at once there. 18:35:16 <abadger1999> nirik: Smooge had the idea of just getting two-factor auth done. 18:35:30 <abadger1999> That seemed like it was a good focus for a FAD. 18:35:34 <pingou> imho 2 factor should have the priority 18:35:43 <nirik> we might want to focus on things that we could either a) be confident of getting done, b) need to discuss in person more to come up with a plan. 18:35:47 <nirik> abadger1999: yeah. 18:37:06 <nirik> well, I will see about whipping up a web page where we can collect costs and time/place prefs. 18:37:16 <nirik> and we can narrow scope down 18:37:54 <nirik> #action nirik will make a web page to collect possible attendees, flight costs and location / time prefs. 18:38:14 <nirik> #topic Upcoming Tasks/Items 18:38:23 <nirik> #topic Upcoming Tasks/Items 18:38:24 <nirik> #topic 2012-06-18 remove people with pkgdb bugzilla issues. 18:38:24 <nirik> #topic 2012-06-21 to 2012-07-04 Kevin is off on trains and boats. 18:38:24 <nirik> #topic 2012-06-26 Fedora 15 end of life. 18:38:24 <nirik> #topic 2012-06-28 Seth at jury duty. 18:38:24 <nirik> #topic 2012-07-05 nag fi-apprentices 18:38:26 <nirik> #topic 2012-07-12 drop inactive apprentices. 18:38:28 <nirik> #topic 2012-08-07 to 2012-08-21 F18 Alpha Freeze 18:38:30 <nirik> #topic 2012-08-21 F18 Alpha release. 18:38:32 <nirik> ugh. 18:38:34 <nirik> misskey 18:38:36 <nirik> oh well. 18:38:38 <nirik> lots of topics. ;) 18:38:43 <nirik> (those were supposed to be infos) 18:38:49 <striker|rh> holy cow 18:39:01 <ingm4r> DOS...to get back into security :) 18:39:30 <nirik> #topic Upcoming Tasks/Items 18:39:30 <nirik> #info 2012-06-18 remove people with pkgdb bugzilla issues. 18:39:30 <nirik> #info 2012-06-21 to 2012-07-04 Kevin is off on trains and boats. 18:39:30 <nirik> #info 2012-06-26 Fedora 15 end of life. 18:39:30 <nirik> #info 2012-06-28 Seth at jury duty. 18:39:30 <nirik> #info 2012-07-05 nag fi-apprentices 18:39:32 <nirik> #info 2012-07-12 drop inactive apprentices. 18:39:34 <nirik> #info 2012-08-07 to 2012-08-21 F18 Alpha Freeze 18:39:36 <nirik> #info 2012-08-21 F18 Alpha release. 18:39:46 <nirik> anyhow, as noted there, I will be gone the next two meetings. ;) 18:40:06 <nirik> if anyone needs anything from me, please ask me to do it before next thursday. 18:40:18 <skvidal> nirik: I need you to not be gone, kthx 18:40:23 <skvidal> nirik: :) 18:40:30 <nirik> does anyone have any other upcoming tasks or things they would like to note on the schedule? 18:40:49 <nirik> skvidal: working on it. ;) Looking forward to be sitting on the train reading a book looking out the window. ;) 18:41:32 <skvidal> hrmph 18:41:36 <nirik> Oh, our private cloud hardware is supposedly in the datacenter somewhere. We just need it to be located and racked and wired and we can start setting it up. 18:41:44 <skvidal> nirik: and the networking setup 18:42:08 <nirik> yeah. 18:42:21 <nirik> I'm not sure if thats just one switch or two. 18:42:44 <skvidal> and of course whatever it means for ips 18:42:56 <nirik> yeah. we do have an external class C ready for this. ;) 18:43:22 <relrod> sorry, wayyyyy late, but I'm here. 18:43:31 <nirik> oh, also, we are hopefully getting a osuosl02 box... will be good to have 2 machines there so we can HA them or whatever we need. 18:45:16 <nirik> #topic Open Floor 18:45:26 <nirik> any questions, comments, ideas for open floor/ 18:46:10 <relrod> well since I missed the app discussion, quick update on fedorahosted automation app stuff 18:46:18 <rossdylan> Fedora badges is coming along pretty well, working on building the nessicary rpm's of the python modules i have been working on 18:46:31 <nirik> relrod: sure... 18:46:35 <nirik> rossdylan: cool. 18:47:20 * nirik noted the ubuntu badges thing thats incompatible with open badges had a 0.2 release the other day. 18:47:46 <relrod> The web side of the fedorahosted automation app is pretty much done, and the CLI I'd say is 75% done. The CLI (at least to the point where I can test it locally) can fully process git requests and Hg requests. I need to get it processing bzr and svn. 18:48:33 <nirik> relrod: how much pain would it be if we had a hosted-agilo01 instance that was just for projects that needed agilo trac plugin/ 18:48:33 <relrod> Flask still isn't packaged for el6 yet though. The maintainer is having some issues with the Flask tests not passing on el6 18:49:23 <nirik> ah 18:49:38 <relrod> nirik: Probably not too much pain, you'd just run the CLI on -agilo01 instead of hostedXX 18:49:46 <nirik> ok 18:50:22 <skvidal> item: cgit vs gitweb-caching? 18:50:40 <skvidal> did we come to a conclusion there? 18:50:42 <nirik> #topic cgit? 18:51:05 <nirik> not that I know of. I was going to ask gnome.org folks what they thought of cgit (since they use it there) 18:51:13 <nirik> but I didn't get around to it. 18:51:22 <skvidal> I got an internal email 18:51:25 <skvidal> on the subject 18:51:27 <skvidal> which said 18:51:39 <skvidal> 'cgit is much better' 18:51:42 <skvidal> (more or less) 18:51:51 <nirik> yeah... from looking it seems that way to me. 18:52:04 <nirik> so, I'm fine moving to it. 18:52:17 <nirik> the main downside is broken links. 18:52:20 <abadger1999> +1 for cgit from me. 18:52:24 <nirik> but there's some redirect rules that could help. 18:52:41 <abadger1999> But I've never been as concerned about the broken links as other people. 18:53:06 <nirik> yeah, it doesn't worry me overly. I don't think those links are used much... 18:53:14 <skvidal> abadger1999: I think I am inline with that now 18:53:17 <nirik> if someone hits an old bug with a gitweb link, too bad. 18:53:18 <skvidal> I used to worry about the links 18:53:20 <skvidal> but screw it 18:53:25 <skvidal> it's just how things fall down sometimes 18:54:10 <nirik> I'd be ok adding the redirects to try and make it somewhat nicer, or if we want just try and redirect all those gitweb things to a page that explains we are using cgit and how to search for what they were looking for. 18:54:56 <skvidal> worksforme 18:55:03 <skvidal> oh - I have another sysadmin-y task 18:55:04 <nirik> so, does someone want to lead this? if not, I can add it to my list. ;) 18:55:06 <skvidal> that is a touch herculean 18:55:17 * nirik notes we could test cgit on hosted01/02 18:55:32 <skvidal> nirik: might be easier to test cgit on fedorapeople 18:55:43 <skvidal> nirik: then again maybe those ~ repos will be tricky on fedorapeople 18:56:04 <nirik> there's also pkgs01.stg 18:56:11 <skvidal> nod 18:56:14 <nirik> anyhow, you had another topic? 18:56:30 <skvidal> yah 18:56:32 <skvidal> so 18:56:41 <skvidal> our httpd::websites, etc module in puppet 18:56:42 <skvidal> is 18:56:44 <skvidal> to say the least 18:56:45 <skvidal> complicated 18:56:57 <skvidal> a while back when we moved infra.fp.o to be standalone 18:57:04 <skvidal> I wrote a new httpd::site class 18:57:16 <skvidal> which simplifies how websites can be setup in puppet 18:57:20 <skvidal> it doesn't involve any templates 18:57:28 <skvidal> and makes me less likely to scream 18:57:43 <nirik> yeah, +1 on that 18:57:45 <skvidal> so 18:57:49 <skvidal> we need to move to that more 18:57:51 <nirik> #topic http::websites 18:58:01 <nirik> yeah, fine with me. 18:58:03 <skvidal> we need to convert sites over and whittle our way off of the other one 18:58:08 <skvidal> just takes people 18:58:17 <nirik> yeah. 18:58:26 <skvidal> another item that is on my todolist but... 18:58:28 <nirik> and getting puppet to do the right thing. 18:58:29 <skvidal> well it's a todolist from hell 18:58:38 <skvidal> iptables templates 18:59:08 <skvidal> my plan is to break iptables templates up into stg/prod templates 18:59:19 <skvidal> this separation is mainly to make sure we keep stg from talking to prod 18:59:40 <nirik> sure... and possibly "untrusted vpn" ? 18:59:41 <skvidal> the idea is for the template to use the heredoc trick 19:00:00 <skvidal> so we have a standard preamble 19:00:14 <skvidal> then if iptables.$iptables_group for that node exists - it gets include 19:00:23 <skvidal> and if iptables.$iptables_datacenter exists - that gets included 19:00:37 <skvidal> and if iptables.$fqdn exits - that gets included 19:00:45 <skvidal> (actually reverse the first two 19:00:49 <skvidal> datacenter, group, fqdn 19:01:01 <nirik> yep. just like the other sane places you already converted to that. ;) 19:01:13 <skvidal> so that we end up being able to add arbitrary rules, per host or per group of hosts (or per datacenter) 19:01:25 <skvidal> w/o having to deal with the defintion problem for iptables 19:01:30 <skvidal> that we deal with in puppet all the time 19:01:41 <skvidal> the other alternative, which I am not advocating but I am throwing out there 19:01:44 <nirik> right. so would we remove the custom rules from nodes then? 19:01:50 <skvidal> yes 19:01:58 <skvidal> we would remove custom rules from node files 19:02:01 <nirik> sounds good to me. 19:02:04 <skvidal> and put them in simple iptables <heredocs> 19:02:07 <skvidal> so the other alternative 19:02:10 <skvidal> that I want to mention 19:02:15 <skvidal> that the dns thing this week made me think about 19:02:35 <skvidal> we could setup iptables in templates - just the dns zone template 19:03:01 <skvidal> in a separate git repo, etc 19:03:11 <skvidal> construct per host and have puppet just run the update-iptables 19:03:15 <skvidal> which sucks down via git, etc 19:03:19 <skvidal> like I said 19:03:22 <skvidal> not advocating 19:03:24 <skvidal> just thinking about it 19:03:30 <nirik> we could, but we don't often change iptables and it doesn't have serial numbers and such... not sure it's worth it. 19:03:51 <skvidal> nod - thr advantage I was thinking of was being able to validate iptables 19:04:19 <skvidal> which is... difficult with the pieces of iptables we'd have to work with in puppet 19:04:33 <nirik> validating iptables in general is difficult. ;( 19:04:44 <skvidal> nirik: true 19:05:00 <misc> especially if you can have a valid iptables config that just block yourself :) 19:05:18 <nirik> I'm happy to simplify and split out what we have now tho for sure... 19:05:27 <nirik> since if you make a mistake now, it affects ALL machines. 19:05:30 <skvidal> the second advantage would be the speed at which we could deploy an iptable 19:05:34 <skvidal> change 19:06:20 <nirik> yeah, currently we don't update often... but there are use cases I suppose. 19:06:27 <skvidal> right 19:06:50 <skvidal> anyway it's something I'm going to be working on so I figured it would be worth mentioning it 19:06:58 <nirik> yeah, sounds good. 19:06:59 <skvidal> if anyone wants to work on it and is familiar with iptables - enjoy 19:07:20 <nirik> #info iptables folks welcome to help with iptables revamp 19:07:37 <nirik> #topic Open Floor (^2) 19:07:44 <skvidal> hah 19:07:48 <nirik> any other items for open floor or other questions, comments? ;) 19:08:19 <ingm4r> just a basic question, if thats ok 19:08:27 <nirik> ingm4r: sure, fire away 19:08:35 <ingm4r> stg ist staging and prd is productive? 19:08:44 <misc> production 19:08:53 <ingm4r> ok 19:09:27 <nirik> ingm4r: yeah... 19:09:42 <nirik> so we try and test things like new package versions and changes in our staging setup... 19:09:53 <nirik> then when they appear fine there, they go to production machines. 19:10:05 <ingm4r> jup, thought so. Just wanted to be sure about the naming. 19:10:16 <nirik> our staging setup is not a complete 1 to 1 mapping, but it has many copies of productions stuff. 19:10:26 <sdrfed17> nirik: so are apprentice guys allowed to work on both staging and production? 19:11:13 <nirik> sdrfed17: sure, the way it works is that apprentices can login to machines and check out a read only copy of our puppet repo... so any changes you make need to be sent throug someone that has commit access. 19:11:25 <nirik> so that way you can see how things are setup and propose patches for review. 19:11:55 <sdrfed17> nirik: ok 19:11:55 <nirik> anyhow, happy to discuss more over in #fedora-admin... 19:12:04 <nirik> we are over time, so lets go ahead and close out... 19:12:09 <nirik> #endmeeting

1 0

Fedora Board Meeting Minutes 2012-06-13
by Christoph Wickert 14 Jun '12

14 Jun '12

Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2012-06-13/fedora_board.201… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2012-06-13/fedora_board.201… Log: http://meetbot.fedoraproject.org/fedora-meeting/2012-06-13/fedora_board.201… ===================================== #fedora-meeting: Fedora Board Meeting ===================================== Meeting started by rbergeron at 18:30:31 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-06-13/fedora_board.201… . Meeting summary --------------- * Who's around (rbergeron, 18:32:42) * jreznik, ke4qqq, gholms, rbergeron, cwickert, abadger1999 present (rbergeron, 18:33:13) * LINK: http://fedoraproject.org/wiki/Board/History (rbergeron, 18:34:45) * ACTION: rbergeron to leave pbrobinson in e5, move sparks into rdieter's e3 spot (THANKS REX!), and jds2001 gets a hot dog in the future for an extra week of hanging out ;) (rbergeron, 18:37:46) * ACTION: and rbergeron to update wiki history of board seats accordingly, and move folks into emeritus territory as necessary (rbergeron, 18:38:08) * Announcements (rbergeron, 18:38:14) * There is currently a runoff election for the remaining board seat in progress (rbergeron, 18:38:45) * LINK: http://lists.fedoraproject.org/pipermail/announce/2012-June/003085.html (rbergeron, 18:38:50) * see link for information on voting; election ends Wednesday, june 20 at 00:00:00 (which may be tuesday in your time zone, plz pay attention) (rbergeron, 18:39:20) * Open Q&A (rbergeron, 18:41:28) * This is an open board meeting! We dedicate the first portion of this meeting to answering your burning questions. If you have any, speak up, and try to vaguely follow the protocol listed here: http://fedoraproject.org/wiki/Board_public_IRC_meetings (rbergeron, 18:43:22) * LINK: https://fedoraproject.org/wiki/Secureboot (nirik, 18:50:29) * Discussion / questions on UEFI - https://fedoraproject.org/wiki/Secureboot is a page nirik has set up with some basic info, more info welcome (rbergeron, 18:51:08) * (work in progress) SecureBoot feature page at https://fedoraproject.org/wiki/User:Pjones/Features/SecureBoot (pjones, 18:51:48) * IDEA: have an IRC town hall for covering questions on secureboot/uefi? (rbergeron, 18:52:04) * Lots of discussion in logs, probably best that you, minutes-reader, read the full log ;) (rbergeron, 18:53:48) * Questions on election process (rbergeron, 19:06:01) * ACTION: cwickert to draft a common nominations/elections wiki page till next week (cwickert, 19:19:27) * Update on Naming Stuff (rbergeron, 19:28:36) * Naming meeting is Friday 2012-06-15 (this friday) at 17:00 UTC (1pm EDT, 7pm CEST) in #fedora-meeting-1 (rbergeron, 19:33:51) * results of doodle poll are at http://www.doodle.com/2y43y5vxxizsqyef (rbergeron, 19:35:54) * Meeting is open (rbergeron, 19:36:05) * Open Floor (rbergeron, 19:48:38) Meeting ended at 20:11:12 UTC. Action Items ------------ * rbergeron to leave pbrobinson in e5, move sparks into rdieter's e3 spot (THANKS REX!), and jds2001 gets a hot dog in the future for an extra week of hanging out ;) * and rbergeron to update wiki history of board seats accordingly, and move folks into emeritus territory as necessary * cwickert to draft a common nominations/elections wiki page till next week Action Items, by person ----------------------- * cwickert * cwickert to draft a common nominations/elections wiki page till next week * jds2001 * rbergeron to leave pbrobinson in e5, move sparks into rdieter's e3 spot (THANKS REX!), and jds2001 gets a hot dog in the future for an extra week of hanging out ;) * rbergeron * rbergeron to leave pbrobinson in e5, move sparks into rdieter's e3 spot (THANKS REX!), and jds2001 gets a hot dog in the future for an extra week of hanging out ;) * and rbergeron to update wiki history of board seats accordingly, and move folks into emeritus territory as necessary * rdieter * rbergeron to leave pbrobinson in e5, move sparks into rdieter's e3 spot (THANKS REX!), and jds2001 gets a hot dog in the future for an extra week of hanging out ;) * **UNASSIGNED** * (none)

1 0

Fwd: [KFI] Rangkuman Meeting 7 Juni 2012
by Prima Yogi Loviniltra 14 Jun '12

14 Jun '12

---------- Forwarded message ---------- From: Yonisman Blankxys <blank.xys(a)gmail.com> Date: Fri, Jun 8, 2012 at 1:04 AM Subject: [KFI] Rangkuman Meeting 7 Juni 2012 To: id-community(a)lists.fedoraproject.org Assalamualaikum wr wb, Berikut rangkuman meeting masih membahas FAD Padang, Minutes : http://meetbot.fedoraproject.org/fedora-id/2012-06-07/fedora-id.2012-06-07-… Minutes (Text) : http://meetbot.fedoraproject.org/fedora-id/2012-06-07/fedora-id.2012-06-07-… Log : http://meetbot.fedoraproject.org/fedora-id/2012-06-07/fedora-id.2012-06-07-… Wassalam, _______________________________________________ Milis Komunitas Fedora Indonesia id-community(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/id-community -- *Best Regards,* *PRIMA YOGI LOVINILTRA* Fedora Contributor & Ambassadors *Indonesian guy who live in and love Malaysia* *M: (6)016 640 0385* *W: *http://fedoraproject.org/wiki/User:Jurankdankkal *B: **http://loviniltra.com/ <http://numoss.org/>** *

1 0

Fwd: Rangkuman Meeting 14 Juni 2012
by Prima Yogi Loviniltra 14 Jun '12

14 Jun '12

---------- Forwarded message ---------- From: Prima Yogi Loviniltra <prima.yogi(a)loviniltra.com> Date: Fri, Jun 15, 2012 at 12:41 AM Subject: Rangkuman Meeting 14 Juni 2012 To: Komunitas Fedora Indonesia <id-community(a)lists.fedoraproject.org> Rangkuman Meeting 14 Juni 2012. Masih persiapan FAD Padang yang bisa di bilang 60% kali yah,hehe. Sayang bgt arifiauo DC tadi, saya mau menanyakan tentang kedatangan ke FAD Padang ini. Berikut rangkumannya : Minutes: http://meetbot.fedoraproject.org/fedora-id/2012-06-14/fedora-id.2012-06-14-… Minutes (text): http://meetbot.fedoraproject.org/fedora-id/2012-06-14/fedora-id.2012-06-14-… Log: http://meetbot.fedoraproject.org/fedora-id/2012-06-14/fedora-id.2012-06-14-… ================== #fedora-id Meeting ================== Meeting started by jurank_dankkal at 14:11:50 UTC. The full logs are available athttp://meetbot.fedoraproject.org/fedora-id/2012-06-14/fedora-id.2012-06-1… . Meeting summary --------------- * menentukan Physical Meeting FAD Padang (jurank_dankkal, 14:13:26) * LINK: https://fedoraproject.org/wiki/FAD_Padang_2012#Meeting_Minutes (jurank_dankkal, 14:17:50) * IDEA: FAD Physical Meeting akan di adakan di gubuk inibudi dan di gabung dgn gath IBT-S (jurank_dankkal, 14:33:51) * ACTION: FAD Physical Meeting, Jam 14.00, 17 Juni 2012 di rumah inibudi (jurank_dankkal, 14:44:22) * Venue Confirmation (jurank_dankkal, 14:44:48) * ACTION: jurank_dankkal akan mengirim proposal yang udah fix ke blankxys dan inibudi (jurank_dankkal, 14:56:28) * ACTION: FAD Padang akan di adakan di Gedung Graha Telkom Padang (jurank_dankkal, 15:04:44) * Speaker untuk FAD Padang (jurank_dankkal, 15:06:37) * LINK: https://fedoraproject.org/wiki/FAD_Padang_2012#Schedule (jurank_dankkal, 15:08:26) * ACTION: hircus akan membuat ticket funding travel sebelum senin (jurank_dankkal, 15:25:15) * LINK: https://fedoraproject.org/wiki/FAD_Padang_2012#Schedule (jurank_dankkal, 16:04:02) * Tugas Promo Team (jurank_dankkal, 16:06:59) * LINK: http://bit.ly/FADPadang2012 (jurank_dankkal, 16:11:46) * ACTION: erdie1one akan menyelesaikan banner sebelum Jumat, 15 Juni 2012 (jurank_dankkal, 16:15:15) * open floor (jurank_dankkal, 16:17:35) Meeting ended at 16:25:08 UTC. Action Items ------------ * FAD Physical Meeting, Jam 14.00, 17 Juni 2012 di rumah inibudi * jurank_dankkal akan mengirim proposal yang udah fix ke blankxys dan inibudi * FAD Padang akan di adakan di Gedung Graha Telkom Padang * hircus akan membuat ticket funding travel sebelum senin * erdie1one akan menyelesaikan banner sebelum Jumat, 15 Juni 2012 Action Items, by person ----------------------- * blankxys * jurank_dankkal akan mengirim proposal yang udah fix ke blankxys dan inibudi * erdie1one * erdie1one akan menyelesaikan banner sebelum Jumat, 15 Juni 2012 * hircus * hircus akan membuat ticket funding travel sebelum senin * inibudi * FAD Physical Meeting, Jam 14.00, 17 Juni 2012 di rumah inibudi * jurank_dankkal akan mengirim proposal yang udah fix ke blankxys dan inibudi * jurank_dankkal * jurank_dankkal akan mengirim proposal yang udah fix ke blankxys dan inibudi * **UNASSIGNED** * FAD Padang akan di adakan di Gedung Graha Telkom Padang People Present (lines said) --------------------------- * jurank_dankkal (217) * hircus (64) * blankxys (57) * inibudi (48) * betefive (44) * zodbot (31) * erdie1one (28) * Qrinz (25) * smart4rd1_ (18) * H4nk (7) * smart4rd1 (6) * acenk90 (6) * street (4) * arifiauo (1) -- *Best Regards,* *PRIMA YOGI LOVINILTRA* Fedora Contributor & Ambassadors *Indonesian guy who live in and love Malaysia* *M: (6)016 640 0385* *W: *http://fedoraproject.org/wiki/User:Jurankdankkal *B: **http://loviniltra.com/ <http://numoss.org/>** * -- *Best Regards,* *PRIMA YOGI LOVINILTRA* Fedora Contributor & Ambassadors *Indonesian guy who live in and love Malaysia* *M: (6)016 640 0385* *W: *http://fedoraproject.org/wiki/User:Jurankdankkal *B: **http://loviniltra.com/ <http://numoss.org/>** *

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

meetingminutes June 2012