Summary/Minutes from today's FESCo Meeting (2012-06-18)

=================================== #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-... . 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_maintainer... 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... 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