17:00:43 <geppetto> #startmeeting fpc
17:00:43 <zodbot> Meeting started Thu Jan 15 17:00:43 2015 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:43 <geppetto> #meetingname fpc
17:00:43 <zodbot> The meeting name has been set to 'fpc'
17:00:44 <geppetto> #topic Roll Call
17:00:48 <tibbs|w> Howdy.
17:00:56 <geppetto> #chair tibbs|w
17:00:56 <zodbot> Current chairs: geppetto tibbs|w
17:00:58 <michel_slm> hello
17:01:04 * spot is around for once
17:01:10 * daMaestro is lurking
17:01:12 <geppetto> #chair spot
17:01:12 <zodbot> Current chairs: geppetto spot tibbs|w
17:01:39 <geppetto> spot: You want to run the meeting ?;)
17:01:58 <spot> geppetto: i'm not quite prepped for that, so... ;)
17:04:25 * tomspur is here also
17:04:41 <geppetto> #char tomspur
17:04:45 <geppetto> #chair tomspur
17:04:45 <zodbot> Current chairs: geppetto spot tibbs|w tomspur
17:05:04 <geppetto> limburgher mbooth orionp racor Rathann SmootherFr0gZ: FPC ping
17:05:15 <orionp> hello, distracted
17:05:21 <Rathann> here
17:06:08 <geppetto> #chair orionp
17:06:08 <zodbot> Current chairs: geppetto orionp spot tibbs|w tomspur
17:06:10 <geppetto> #chair Rathann
17:06:10 <zodbot> Current chairs: Rathann geppetto orionp spot tibbs|w tomspur
17:06:19 <geppetto> ok, we have enough to start
17:06:55 * racor is here for the moment, but I am likely to quit early.
17:06:55 <geppetto> #chair racor
17:06:55 <zodbot> Current chairs: Rathann geppetto orionp racor spot tibbs|w tomspur
17:07:05 <geppetto> is salimma here?
17:07:45 * jsmith is lurking
17:07:54 <tibbs|w> He said he would be, but we should probably delay until he responds.
17:07:58 <michel_slm> geppetto: that's me
17:08:03 <geppetto> Ok, cool
17:08:03 <tibbs|w> Ah.
17:08:06 <mbooth> Sorry I am late
17:08:20 <geppetto> #chair mbooth
17:08:20 <zodbot> Current chairs: Rathann geppetto mbooth orionp racor spot tibbs|w tomspur
17:08:35 <geppetto> Ok, so might as well revisit this one first … and get the joy out of the way
17:08:37 <geppetto> #topic #476 	Requesting copylib exemption for libgnome-volume-control
17:08:37 <geppetto> .fpc 476
17:08:38 <geppetto> https://fedorahosted.org/fpc/ticket/476
17:09:04 <michel_slm> one sec, let me see if hadess is online somewhere
17:09:14 <michel_slm> he's not. ok
17:10:19 <Corey84> .hellomynameis Corey84
17:10:20 <zodbot> Corey84: Sorry, but you don't exist
17:10:33 <Corey84> .fas Corey84
17:10:34 <zodbot> Corey84: corey84 'Corey84' <sheldon.corey@gmail.com>
17:11:10 <tibbs|w> I'm lagging pretty badly.
17:11:12 * spot wishes the response was more of a surprise. :/
17:11:15 <geppetto> Ok, everyone had a quick look at the history? And: https://git.gnome.org/browse/libgnome-volume-control/tree/
17:11:48 <tibbs|w> I'm up to date.  I don't really see that any reason was given to change my vote.
17:11:53 <michel_slm> last commit is from Sept 2013
17:12:13 <tibbs|w> This seems more a case of "we just don't want to do it that way" and I assume they'll just ignore whatever we decide anyway.
17:12:22 <geppetto> Yeh, we noticed that last time and the size of the code … which was why we hoped they'd dtrt and make it a real library
17:12:27 <michel_slm> I'm actually ok with the rejection, but want to know what will be done to the Gnome packages
17:12:33 <geppetto> big and not changing seems like a good time to make it shared
17:13:09 <michel_slm> seems like there's a case for having an FPC swat team to bring packages into compliance, when upstream == packager and they refuse
17:13:20 <geppetto> that would be nice
17:13:23 <orionp> It's like a surrealist piece of art - c'est ne pas un library ....
17:13:57 <rdieter_work> imo, punt enforcement/review back to FESco, it's not FPC job to be the police here
17:14:28 <michel_slm> ah. this is when having the fesco and fpc trac be separate instance is kind of annoying
17:14:47 <tomspur> rdieter_work: +1 also wanted to write something similar right now
17:14:50 <geppetto> The obvious fix is to require the new package do a static lib. to get past review, and then hope gnome devs. do the absolute least right thing and stop bundling
17:15:26 <geppetto> rdieter: What do we punt to FESCO … please make gnome devs. obey policy?
17:15:38 <rdieter_work> geppetto: yes
17:15:56 <geppetto> It's not like remove gnome is a realistic option, so I'm not sure I see the point
17:15:58 <rdieter_work> or alternatively, fesco can choose to override fpc decision and not enforce it
17:16:10 <michel_slm> geppetto: time permitting I'd be willing to do that ... *if* gnome devs are willing to merge the code
17:16:46 <michel_slm> of course, if we're going to fesco first it's worth waiting to see what gets decided there
17:16:47 <geppetto> rdieter: One would assume that "obey policy" is kind of a given for all packages, in non-gnome world
17:16:48 <rdieter_work> assuming (as it seems) fpc doesn't change the decision based on recent trac comments
17:17:15 <rdieter_work> geppetto: it is a given, except when maintainers choose to not follow it :-/
17:17:16 <geppetto> Again, I'm not sure what we are asking FESCO to say/do?
17:17:47 <rdieter_work> geppetto: ask fesco to enforce fpc decision (to unbundle the libary here)
17:18:05 <rdieter_work> which is (apparently) what the current package maintainer(s) are refusing to do
17:18:34 * geppetto shrug … if someone else wants to open that ticket, feel free … but it seems like a pointless waste of time, to me.
17:18:57 <geppetto> FESCO's swat team is as big as ours
17:19:08 <michel_slm> as in, zero, unfortunately?
17:19:15 <geppetto> yeh
17:19:30 <rdieter_work> true, you can ask the submitter of the fpc ticket #476 to do so, it doesn't have to be fpc that does the requesting
17:19:32 <michel_slm> ideally Gnome developers fix it, since then it's easy to get Budgie's developer to change too
17:19:58 <rdieter_work> but imo, once fpc decision is made, the fpc job is done
17:20:09 <michel_slm> whereas someone trying to get Budgie packaged and having to develop the fix and then try to convince two sets of upstreams.. but well
17:20:40 <geppetto> I agree … our job is done.
17:20:54 <michel_slm> if people think it's not worth taking to fesco .. question, hypothetically what'd happen if after there's a static lib for libg-v-c , the devs still refuse to fix their packages
17:20:57 <geppetto> It does suck for Budgie maintainer(s) … but that's life when upstream sucks
17:21:16 <Rathann> there were cases where packages were taken away from their maintainers for not following the FPGs
17:21:20 <tibbs|w> michel_slm: They'd refuse, and life would go on.
17:21:36 <tibbs|w> I don't think this is worth a huge blowup either way.
17:21:41 <michel_slm> taking the package away from a maintainer who's upstream seems... hostile
17:21:43 <michel_slm> yeah
17:21:46 <geppetto> michel_slm: Normally bugs are opened requesting packages comply with policy … but after that nothing, again FPC/FESCO has no swat teams
17:22:30 <michel_slm> maybe a bz tag for different sorts of violations .. but well, that won't really do anything
17:22:33 <geppetto> In theory you could go for a bad/unresponsive maintainer … but with gnome stack relying on it … *shrug*
17:22:45 <michel_slm> alright then, let's move to the next item
17:23:06 <tomspur> fesco is accountable for sponsors and can revoke it (well at least in theory)
17:23:37 <geppetto> #action No change in FPC opinion, static library packaging work has to fall to Budgie maintainer if upstream/gnome refuse to do any work
17:23:56 <geppetto> #topic #490 	Remove gcc, gcc-c++ and make from minimal build root
17:23:57 <geppetto> .fpc 490
17:23:57 <geppetto> https://fedorahosted.org/fpc/ticket/490
17:24:55 <tibbs|w> There's a lot there, but I had a really simple proposal.
17:25:05 <geppetto> go on
17:25:14 <tibbs|w> Just rip out this section:
17:25:32 <tibbs|w> https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2
17:25:51 <tibbs|w> And say somewhere that you should specify all of your build dependencies in BuildRequires:
17:26:05 <tibbs|w> That gets us out of that business entirely.
17:26:15 <tibbs|w> And honestly, that exceptions list is almost certainly wrong anyway.
17:26:33 <geppetto> Can you or spot remember why we didn't go this route initially?
17:26:52 <tibbs|w> The "don't specify gcc" rule existed before Fedora.
17:27:02 <geppetto> yeh, just wondered if you knew why?
17:27:03 <spot> yeah. we were codifying existing practices?
17:27:09 <orionp> The ones I could imagine keeping are: fedora-release, redhat-rpm-config, rpm-build
17:27:14 <geppetto> just random history from rhl-1.0 days?
17:27:28 * geppetto nods
17:27:42 <Rathann> and whatever contains useradd
17:27:54 <geppetto> orionp: Those need to be outside the buildroot, but not in it … right?
17:27:58 <tibbs|w> Not sure why we shouldn't specify useradd, honestly.
17:28:26 <tibbs|w> If you really need it to build.
17:28:34 <tibbs|w> Not sure why you'd need it to build, though.
17:28:41 <geppetto> I'm happy to just remove the entire section … but replacing it with something tiny seems less useful
17:29:06 <orionp> I'm happy to completely get rid of it
17:29:11 <Rathann> geppetto: well, every package would have to BR: redhat-rpm-config
17:29:12 <tibbs|w> Less useful than what?
17:29:14 <Rathann> does it make sense?
17:29:23 <Rathann> well, all 3-4 packages
17:29:50 <Rathann> that's a lot of unnecessary bits in each spec file
17:30:03 <geppetto> fedora-release and rpm-build are needed inside the buildroot?
17:30:12 <tibbs|w> But those aren't build dependencies.
17:30:26 <orionp> but I don't want every package to have BR redhat-rpm-config
17:30:28 <tibbs|w> I mean, if you're writing a spec file you know you have rpm somewhere.
17:30:29 <racor> Rathann: BR: redhat-rpm-config would render rpms non-reusable
17:30:40 <Rathann> exactly
17:30:51 <geppetto> Dito. redhat-rpm-macros … I guess they are kind of BR if you build via. rpmbuild on the host machine … but who does that in 2015 ?:)
17:31:09 <tibbs|w> I just can't see how the rpm environment is what we'd consider a build dependency.
17:31:22 <geppetto> yeh
17:31:26 <tibbs|w> BR: some-hardware-to-build-on
17:31:27 <orionp> we need it for all the macros we use
17:31:47 <geppetto> orionp: But, again, it needs to be there before the specfile is looked at
17:31:53 <tibbs|w> And we need rpm for... everything, but it's not a build dependency.
17:32:05 <geppetto> orionp: So it's not really a BR … it's a "pre-BR"
17:32:51 <tibbs|w> Anyway, I don't think this is a huge deal, but I would like to get out of the business of essentially telling releng what they have to have in buildsys-build.
17:33:08 <geppetto> Yeh, not that I believe they care what we say …
17:33:13 <geppetto> +1 on tibbs proposal
17:33:52 <Rathann> so what exactly is the proposal now?
17:33:55 <tibbs|w> I can provide the short text to replace that section in a ticket if people would like to see it before voting.
17:34:05 <Rathann> yes, please
17:34:05 <michel_slm> someone needs to decide on the base set though? filesystem, redhat-rpm-config, fedora-release...
17:34:08 <geppetto> <tibbs|w> Just rip out this section:
17:34:08 <geppetto> <tibbs|w> https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2
17:34:52 <geppetto> michel_slm: filesystem isn't necessarily needed … the other two there are pre-BR anyway
17:35:00 <orionp> So our response to 490 is that it's a fesco/releng decision?
17:35:13 <orionp> but we'll get out of the way.
17:35:18 <geppetto> Yeh, ask rel-eng to remove gcc from the group
17:35:23 <tibbs|w> Let's just table this for now and I can provide a proper draft; we can either vote in the ticket or hit it up next week.
17:35:29 <tibbs|w> But the issue of gcc really isn't ours.
17:35:36 <spot> we could also redefine the group to match the deps on rpm-build.
17:35:56 <spot> its a shorter list.
17:36:06 <tibbs|w> We could, but who is to say that won't change.
17:36:16 <geppetto> yeh, and again that's all pre-BR stuff
17:36:32 <tibbs|w> And, honestly, what do we really lose by having packagers actually specify what they need to build?
17:36:37 <geppetto> if that is in the host, you don't need it in mock/etc.
17:36:37 <spot> i think that was sort of the point of the original list, not to have to explicitly state the pre-BR stuff
17:37:19 <tibbs|w> But gcc isn't what we're calling pre-BR stuff.
17:37:20 <orionp> The guidelines above basically, build it mock, if it fails, keep adding stuff until it works
17:37:33 <geppetto> yeh
17:37:37 <orionp> so it kind of implicitly leaves exceptions
17:37:59 * spot is fine with dropping gcc/gcc-c++ and make from that list, they're not pre-BR items
17:38:14 <spot> but i'm a little worried about nuking the whole list
17:38:15 * Rathann is fine with that, too
17:38:28 <Rathann> I mean gcc/gcc-c++ and make
17:38:59 <racor> I am considering dropping gcc/gcc-c++ a too brutal step with too many unknowns attached.
17:39:14 <tibbs|w> racor: But that's not what we're discussing, really.
17:39:14 <racor> Why not start with dropping make only?
17:39:18 <geppetto> racor: that was the main reason I didn't want us to be the decider of that
17:39:36 <geppetto> racor: rel-eng can much more easily manage that transition, if they want to do so
17:39:47 * geppetto shrugs
17:40:09 <tibbs|w> racor: I'm sure whoever ends up making this decision would value your input.
17:40:11 <spot> geppetto: we could ask rel-eng to maintain that list, but I'm not sure they will.
17:40:12 <orionp> all we're saying is that if you want to add BR: gcc to your package, it's okay
17:40:12 <racor> what are we discussing, then?
17:40:26 <geppetto> dropping just make doesn't seem like it'd make anyone happy
17:40:31 <tibbs|w> The proposal that's been stated twice in this ticket.
17:40:46 <geppetto> spot: We could maybe replace the list with "anything in the buildsys-build group"
17:41:24 <tibbs|w> How about this: we close 490, I open a new ticket and add a draft.  Then we can discuss the "just drop the exceptions list" bit.
17:41:33 <geppetto> And give the current members of the group (with a note saying those are just the current members, check the group)
17:41:36 <tibbs|w> Without all of the other cruft which appears to be causing confusion.
17:41:41 <geppetto> That forces them to take ownership of it :)
17:41:42 <racor> 490 item 3: Remove the packages (gcc, g++, make) from minimal build root in F24 timeframe.
17:42:18 <geppetto> tibbs|w: Why not add the draft to 490?
17:42:21 <orionp> racor - i think the concensus is that's not an FPC decision
17:42:27 <tibbs|w> racor: But that has nothing to do with us; the ticket was asking us to do something we have no authority to do.  I provided a counterproposal, which has been stated here twice now.
17:42:51 <tibbs|w> geppetto: I could, but obviously the other stuff in that ticket is confusing at least one FPC member.
17:43:00 <spot> worth noting that the last time the issue of changing the list came up we bounced it to FESCo
17:43:04 <spot> https://fedorahosted.org/fesco/ticket/528
17:43:05 <racor> tibbs: no idea what you are refering to - URL?
17:43:18 * geppetto nods … if you'd prefer I can close it with "we don't have the auth. to do what you want"
17:43:37 <geppetto> tibbs|w: Basically almost whatever you want to do I'll +1, I think :)
17:43:57 <tibbs|w> racor: https://fedorahosted.org/fpc/ticket/490#comment:2 under "Proposal:".
17:44:18 <tibbs|w> Anyway, can we move on so we can get something done before racor needs to leave?
17:45:28 <racor> tibbs|w: Thanks.
17:45:47 <geppetto> #action tibbs We don't have the auth. to remove gcc from buildroots, tibbs has plans to write a policy change that better reflects reality
17:45:55 <geppetto> #topic #491 	Bundling exception: libiax for sflphone on F20, F21
17:45:55 <geppetto> .fpc 491
17:45:55 <geppetto> https://fedorahosted.org/fpc/ticket/491
17:46:19 <racor> geppetto: understood. comment#2 was what I was missing.
17:46:24 <tibbs|w> I think I'm OK with this.
17:47:04 <geppetto> Yeh, I'm fine with this … or them just releasing iaxclient-libiax with obsoletes in f20/f21
17:47:21 <Rathann> +1 for temporary exception
17:47:29 <geppetto> +1
17:47:33 <mbooth> Reason for exception seems reasonable to me
17:47:35 <mbooth> +1
17:47:40 <tibbs|w> +1
17:47:50 <tomspur> +1
17:47:55 <racor> Any reason why this lib can't co-exist with the dead one?
17:47:55 <orionp> +1
17:48:09 <racor> +1 for temporary exception
17:48:19 <geppetto> racor: I assume they are using the same libiax filename
17:48:24 <Rathann> "libiax 0.2.3 is ABI incompible with the version 0.2.2"
17:48:46 <geppetto> spot: vote?
17:48:48 <racor> then, the natural thing would be to reflect the fact of having forked into the libraries name ;)
17:48:50 <Rathann> one question though: is the soname different?
17:49:00 <spot> +1
17:49:26 <racor> ... library's name
17:49:39 <tibbs|w> I mean, I guess he could just drop the new package in in a way that allows them both to be installed in parallel, and fix up the other packages to use it instead of bundling.
17:49:50 <tibbs|w> But, meh.
17:49:52 <geppetto> #action Bundling for iaxclient-libiax on f20/f21 (+1:8, 0:0, -1:0)
17:49:59 <Rathann> well, just the soname, it's not entirely clear it's a fork rather than a new upstream
17:50:16 <geppetto> tibbs: Yeh, esp. as the other thing is dead upstream
17:50:20 <geppetto> #topic #492 	Reverse weak dependencies
17:50:20 <geppetto> .fpc 492
17:50:20 <geppetto> https://fedorahosted.org/fpc/ticket/492
17:50:34 <Rathann> but if there are no other users then it might not make sense to unbundle
17:51:20 <geppetto> I'm -1 on using these before recommends/suggests
17:51:43 <spot> the weak deps always give me a headache
17:51:44 <geppetto> Esp. given they are much less efficient
17:52:07 <Rathann> actually enhances and supplements might be more useful for external repositories like RPMFusion
17:52:15 <tibbs|w> Less efficient in what context?
17:52:37 <geppetto> In that they work like obsoletes … so you have to do reverse lookups
17:52:41 <tibbs|w> To me, reverse dependencies like these actually make more sense in most contexts.
17:53:03 <tibbs|w> Because it avoids the "add a new package, update some other package with additional Suggests: entry".
17:53:27 * spot has a vision of dnf installing apache, then asking the user "the following 47 mod_* packages enhance it, would you like to install them?"
17:53:38 <geppetto> yeh, pretty much
17:53:47 <Rathann> well the upside is exactly what tibbs|w says, the "main" package maintainer doesn't have to keep a list of plugin packages in his specfile
17:54:04 <geppetto> except AIUI they aren't going to go the interactive way … so more likely it'll just install all of them by default
17:54:15 <tibbs|w> Oh, I sure as hell hope not.
17:54:15 <Rathann> spot: well, that's the consequence of using weak deps
17:54:32 <spot> geppetto: i think there was discussion in the ticket implying dnf would be an interactive transaction
17:54:45 <spot> but anaconda wouldn't be.
17:54:52 <Rathann> interactive dependency resolution, maybe
17:55:49 <Rathann> IMHO anaconda should run the installation with weak deps ignored
17:55:53 <geppetto> I think someone might be confused there … but maybe they do plan a simple "would you like all the enhances/recommends, or none of them" boolean option
17:56:17 <Rathann> geppetto: that's the idea, not sure if anything is implemented yet
17:56:20 <geppetto> Rathann: I bet people will complain if that's true
17:56:25 * michel_slm wonders what happens if an enhancement itself has enhancements
17:56:28 * spot would like to know how dnf/anaconda wants to handle weak deps before we sign off on it
17:56:32 <geppetto> Rathann: I hadn't heard anything about it
17:57:03 <spot> michel_slm: we recurse the user. :D
17:57:04 <geppetto> AFAIK the dnf side just has plans for a _config_ option which tells dnf to include all enhances/suggests or ignore them
17:57:11 <geppetto> with the default being to include them
17:57:11 <Rathann> geppetto: otherwise it needs to grow an UI option to install enhancements or not
17:57:31 <spot> "please have a child, then have the child confirm the next set of enhancement packages"
17:57:39 <michel_slm> spot: hehe
17:58:19 <geppetto> I feel like we could solve a lot of problems by requiring those first four words ;)
17:58:30 <michel_slm> seems like it's useful metadata to have though. better than just relying on packages having the right prefix
17:58:56 <michel_slm> "dnf, tell me what add-ons exist for my shiny new nginx install"
17:59:14 <tibbs|w> So where do I file a ticket to have the default be to not include them?  It's either that or have yet another thing I have to patch in my kickstart files.
17:59:24 <geppetto> michel_slm: that might actually be a useful thing … feel free to open an FRE for that
17:59:55 <geppetto> tibbs: Probably open a BZ against dnf
18:00:04 <michel_slm> geppetto:  an RFE to dnf, right?
18:00:12 <geppetto> michel_slm: yeh
18:01:07 <michel_slm> geppetto: that assumes weak deps are voted in today though
18:01:11 * spot still wants to know how the core tools will handle them before adding them in.
18:01:15 <michel_slm> else there's no way to implement that feature, no?
18:01:17 <geppetto> So do we want anymore info. for this ticket … or do we want to close it until it's all ready?
18:01:42 <geppetto> michel_slm: just because they can't be shipped in Fedora doesn't mean dnf can't operate on them
18:01:45 * michel_slm agrees with spot. if this change is in, we should err on the conservative side
18:01:58 <tibbs|w> I think we need to work back and forth to avoid a chicken/egg problem.
18:02:02 <geppetto> michel_slm: And it kind of needs to have the code to do something useful with them before we let people add them to the repos.
18:02:05 <michel_slm> geppetto: ah, true.
18:02:25 <tibbs|w> We can't add guidelines until there's an implementation, but our guidelines could guide the implementation.
18:02:49 <michel_slm> got to run to another meeting, will check back later
18:03:32 <geppetto> I'm not sure what our guidelines would say other than "you can now put Suggests/recommends/enhances/etc. in your specfiles"
18:03:44 <spot> tibbs|w: except, we can't really say "the tooling must do this"
18:03:50 <geppetto> right
18:03:59 <tibbs|w> But we can say "it would be really great if the tooling did this".
18:04:12 * spot just wants to know how the tool devs plan to handle this
18:04:21 <geppetto> We just have to know it's not going to blow up the distro. if people use them, we can't design dnf
18:04:36 <tibbs|w> If the tooling is going to just add all of these things in by default, then we need the guideline to tell packagers to be extremely conservative in what you add.
18:05:03 <tibbs|w> To the point that I think we should consider having to approve them.
18:05:11 <tomspur> Adding a veto option for the "main" package maintainer would be good. Or how would be a conflict solved when people have different optinions if it is really enhancing the main package
18:05:39 <geppetto> So, debian did two levels of each … Eg. enhances is installed by default and supplements isn't … I think it's fair to assume that'll be true in Fedora too
18:05:43 <tibbs|w> But if these things are merely suggestions by the packaging system, then I'm all for letting packagers do what they feel is best.
18:06:42 <geppetto> tomspur: That seems bad, the only cases where I assume it'd be useful is if some idiot decides their packages needs to be installed everywhere and does enhances: glibc or something
18:06:54 * nirik notes people are already using them... even tho the tools really don't do much with them yet
18:07:03 <geppetto> tomspur: And hopefully we don't need the glibc packager invovled to fix that kind of thing
18:07:11 <spot> kde Enhances: gnome-shell
18:07:17 <tomspur> :)
18:07:20 <geppetto> That's true though
18:07:31 * spot just waits for kkofler to realize that.
18:07:59 <geppetto> that's cool … I just got a popcorn machine for xmas, so I'm prepared
18:09:14 <geppetto> nirik: So they are in f21 packages, and thus. in the current f21 repodata?
18:09:16 * geppetto looks
18:09:35 <nirik> geppetto: probibly. There were 3-4 when I looked a few months ago.
18:11:05 <tibbs|w> So...
18:11:16 <geppetto> Hmm
18:14:44 <tomspur> Why are recommends and suggests not allowed for now?
18:15:56 <spot> they're not explictly forbidden, just not in the guidelines (iirc)
18:16:36 <tomspur> "is not allowed for now" sounds like forbidden
18:17:19 <tomspur> "forbidden until we support them in a few weeks/months"
18:17:30 <spot> i don't think the current guidelines say either.
18:17:44 <nirik> tomspur: I asked fesco to say that and they declined.
18:18:16 <nirik> https://fedorahosted.org/fesco/ticket/1353
18:18:20 <geppetto> I don't see them in the f21 repodata
18:18:31 <nirik> well, they didn't decline, I guess I just retracted it, because they don't do anything
18:18:48 <racor> rpm -q --suggests -p imsettings-1.6.7-6.fc21.x86_64.rpm
18:18:57 <racor> imsettings-gsettings
18:19:13 <spot> racor: yeah, but that's just rpm parsing the tag.
18:19:21 <racor> Isn't this already one of these "dominance" cases
18:19:38 <racor> it's inside of repodata as well
18:19:49 * mirek-hm is late, but here
18:20:14 <geppetto> racor: Hmmm … I don't see imsettings in the repodata
18:20:19 <spot> i think at the least, we should document how the "weak" fields are handled by the tools so that packagers know what to expect when using them.
18:20:48 <spot> and only if the tools do really naughty things should we consider forbidding their use.
18:20:49 <tibbs|w> I guess once that has been decided....
18:22:20 <geppetto> racor: Oh, nevermind … I'm looking at updates not release
18:24:50 <geppetto> yeh, I see a couple of people using suggests … but not recommends/enhances
18:25:47 <geppetto> Anyway, I guess what do we want to do … just close this ticket and wait for the tooling to be official before we do anything with any soft/clever requires
18:25:58 <mirek-hm> can someone fpaste me beggining of meeting (till :18)?
18:26:01 <geppetto> Or does someone want to take a stab at some policy ?
18:26:22 <racor> I see exactly 2 packages using "suggests" in fc21 (release): imsettings and  erlang-tools
18:26:29 <geppetto> yeh
18:26:45 <mirek-hm> geppetto: the problem is that there will be no push for tooling when there will be no data/tags
18:27:08 <mirek-hm> and as I said reverse weak deps are pretty harmless
18:28:17 <spot> geppetto: i'd rather simply ask for documentation on how dnf and anaconda will handle weak flags, leave the ticket open until we can review that info
18:28:21 <geppetto> that's not how things work … rpm/dnf/etc. devs. have to setup test repos. anyway, to debug their tooling … they can then describe how they think it should run, and we can then decide on appropriate policy
18:28:29 <geppetto> spot: Ok
18:28:56 <geppetto> mirek-hm: And I would disagree … reverse deps. have pretty big efficieny concerns, and all the UI concerns of recommends/etc.
18:28:59 <mirek-hm> spot: I assume that dnf will probably never handle it, because that is noninteractive
18:29:11 <mirek-hm> ti is more about PackageKit or apper
18:29:30 <geppetto> apper?
18:29:37 <racor> geppetto: please don't forget repoquery. Just noticed, rpm supports --suggests, but repoquery doesn't.
18:29:39 <spot> mirek-hm: better to ask and be told than to assume and be wrong. ;)
18:29:51 <mirek-hm> geppetto: that inst Software Installer in KDE
18:30:18 <racor> Folks, I need to leave.
18:30:42 <geppetto> racor: repoquery is now "dnf repoquery" in the new order
18:30:51 <geppetto> Didn't seem much point adding it to the yum side
18:31:19 * spot needs to go soon too. :/
18:31:24 <mirek-hm> dnf repoquery support weak deps
18:31:52 <geppetto> #action We need documentation on how dnf and anaconda will handle weak flags, so we can decide what to do from here
18:32:14 <geppetto> Ok, well that's the new tickets anyway
18:32:26 <geppetto> And the weird reopened one from last week
18:32:37 <geppetto> #topic Open Floor
18:33:02 <geppetto> Schedule was: https://lists.fedoraproject.org/pipermail/packaging/2015-January/010433.html
18:33:14 <geppetto> If anyone needs to bring up an older ticket, now's the chance
18:33:31 <geppetto> orionp: I assume noone spoke to you about 478?
18:33:37 <orionp> nope
18:35:52 <geppetto> Anyone want to discuss 481?
18:36:06 <geppetto> 481 	static uids systemd-network, systemd-timesync,
18:36:06 <geppetto> systemd-resolve
18:36:16 <tibbs|w> Yeah.
18:36:26 <geppetto> #topic #481 	static uids systemd-network, systemd-timesync,
18:36:26 <geppetto> systemd-resolve
18:36:26 <geppetto> .fpc 481
18:36:27 <geppetto> https://fedorahosted.org/fpc/ticket/481
18:36:35 <tibbs|w> I think we're out of options here.
18:36:52 <geppetto> I'd still rather not
18:37:03 <geppetto> this feels very slippery slope
18:37:18 <tibbs|w> I think we're long past that where systemd is concerned.
18:37:18 <geppetto> And the reason for taking static uids is boot over NFS?
18:37:52 <tibbs|w> I don't think so, no.
18:38:01 <tibbs|w> Not sure how NFS would be involved at all here.
18:38:05 <geppetto> they even say the services are restarted once the real root is available
18:38:19 <geppetto> Which feels like they could restart with the correct uids
18:38:30 <tibbs|w> The issue is the on-disk data, I guess.
18:38:48 <geppetto> tibbs: It's their answer to the question "why do the need to be started before the system has booted"
18:40:25 <tibbs|w> So the same people who said that separate /usr is not supported are working hard to support NFS root?
18:41:19 <geppetto> ¯\_(ツ)_/¯
18:43:01 <geppetto> So, unless a bunch of you want to +1 this … I'll write a comment explaining our side a bit more in that static uids are a scarce resource
18:43:22 <geppetto> And esp. responding to their usecases and "They are started in the initramfs as systemd services, run until the switchroot happens, and are restarted by the main systemd instance"
18:43:50 <tibbs|w> I'm kind of leaning +1 personally, but, uh, I'm willing to go along with your comment.
18:45:21 <geppetto> Ok, I'll try to be nice about it and hopefully we can get them to do some more code and not need them
18:46:05 <geppetto> #action geppetto More questions about uscases, changing uid when switchroot happens, and scarcity of static uids
18:46:16 <geppetto> #topic Open Floor
18:46:31 <geppetto> Ok, anything else to bring up before I close and everyone can go eat something :)
18:46:34 <tibbs|w> So, about that mono ticket.
18:46:51 <tibbs|w> Do you think I should just go ahead and change redhat-rpm-config to add those two macros that are already in F21.
18:46:53 <tibbs|w> ?
18:46:55 <geppetto> I don't see a mono ticket?
18:47:05 <geppetto> oh, the old one
18:47:12 <tibbs|w> I hit it when doing writeups last night.  I'm trying to find it.
18:47:21 * geppetto nods, I read the email
18:47:46 <tomspur> https://fedorahosted.org/fpc/ticket/395#comment:5
18:48:00 <tibbs|w> Why could I not see that in the list?
18:48:19 <tibbs|w> Anyway, if I just make that change I don't have to conditionalize the guidelines for <F21.
18:48:33 <tibbs|w> I just don't know how prickly they are about changes to redhat-rpm-config.
18:48:55 <tibbs|w> It always seemed to me like adding new macros is kind of a big deal for some reason.
18:49:07 <tibbs|w> Thought maybe geppetto knew those folks.
18:49:10 <tibbs|w> Well, ffesti.
18:49:20 <geppetto> Kind of, but no idea how they'll react
18:49:34 <tibbs|w> I think this is a forgiveness/permission issue.
18:49:44 <tomspur> What could break, if such a macro is added?
18:49:54 <tibbs|w> Uh, nothing?
18:50:00 * tomspur cannot see anything either...
18:50:17 <tomspur> So +1 for adding it everywhere
18:50:34 <tibbs|w> It just defines a macro for a directory, and is already in F21 (though the F21 redhat-rpm-config package is significantly different from the F20 one.
18:51:36 <geppetto> yeh, my guess is ffesti just doesn't have much time to work on this while doing el7/etc. … or doesn't know how important this is for mono
18:52:30 <geppetto> you could always ping him directly tomorrow morning (he's on berlin time)
18:54:01 <geppetto> or just do it for f20, how bad could it be ?:)
18:54:09 <tibbs|w> Right.
18:54:28 <tibbs|w> Didn't really want to spend any time on it, just thought I would ask in case that package is somehow "special".
18:54:49 <geppetto> only in that it gets installed a lot
18:55:05 <geppetto> well, by packagers anyway
18:55:25 * tomspur needs to leave soonish
18:55:36 <geppetto> ok, unless anyone else has anything I'll close … and I'll see you next week
18:57:22 <tomspur> bye, see you next week
18:58:55 <geppetto> #endmeeting