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