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#Notes_for_Mass_Orphaning
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@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@bar.com in fas, it tries to set that in bugzilla so bugs filed against packages they own go to foo@bar.com.
17:14:23 <nirik> it's not working because there is no foo@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_Feature
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