16:00:26 <geppetto> #startmeeting fpc
16:00:26 <zodbot> Meeting started Thu Mar 26 16:00:26 2015 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:26 <geppetto> #meetingname fpc
16:00:26 <zodbot> The meeting name has been set to 'fpc'
16:00:27 <geppetto> #topic Roll Call
16:01:43 <tibbs|w> Howdy.
16:01:56 <orionp> hello
16:02:13 <geppetto> #chair tibbs
16:02:13 <zodbot> Current chairs: geppetto tibbs
16:02:15 <geppetto> #chair orionp
16:02:15 <zodbot> Current chairs: geppetto orionp tibbs
16:02:32 <geppetto> limburgher mbooth racor Rathann SmootherFr0gZ spot tomspur: FPC ping
16:02:46 <mbooth> Hi
16:02:50 * tomspur is here
16:02:51 <geppetto> #chair mbooth
16:02:51 <zodbot> Current chairs: geppetto mbooth orionp tibbs
16:02:52 <tibbs|w> geppetto: BTW, tibbs is my machine at home.
16:02:54 <geppetto> #chair tomspur
16:02:54 <zodbot> Current chairs: geppetto mbooth orionp tibbs tomspur
16:03:07 <tibbs|w> Won't see pings until I get home in 11 or 12 hours.
16:04:43 <geppetto> ahh
16:05:08 <geppetto> I just assumed your tibbs|w account is also setup to get the tibbs pings
16:05:19 <geppetto> Well, public ones anyway
16:05:35 <tibbs|w> Actually it doesn't because I never bothered to set it up.  Durr.
16:05:50 <geppetto> :)
16:06:10 <geppetto> Anyway, I guess we have 5 so …
16:06:22 <geppetto> #topic Schedule
16:06:26 <geppetto> https://lists.fedoraproject.org/pipermail/packaging/2015-March/010526.html
16:06:45 <tibbs|w> I kind of suck at IRC.
16:06:55 <geppetto> #topic #515 	Bundling determination and exception request
16:07:01 <geppetto> https://fedorahosted.org/fpc/ticket/515
16:07:16 <tibbs|w> We did get more info there.
16:08:02 <geppetto> yeh, I'm a pretty big no on bundling 2k line xmlrpc libraries :)
16:08:11 <tibbs|w> Conveniently did not answer my question:  Does the maintainer update all of the various programs when something changes in this library?
16:08:12 <geppetto> in C++ no less
16:08:27 <tibbs|w> I also really don't understand the upstream reasoning.
16:08:36 <geppetto> it's easier
16:08:40 <geppetto> for him
16:08:54 <tibbs|w> I mean, if you didn't want any possibility of anyone else using your code, why release it under a free license?
16:09:13 <tibbs|w> The entire justification seems to be:
16:09:20 <tibbs|w> He doesn't want to support it as a separate library because if he separates it out then it would be directly available for other people/projects to use
16:09:40 <geppetto> yeh, I think that's more "I'd have to care about API/ABI"
16:09:50 <tibbs|w> Which... he wouldn't.
16:10:01 <geppetto> which is kind of fine … he can ship it as a static library
16:10:22 <tibbs|w> Anyway, is anyone actually pro-bundling here?
16:10:29 <tibbs|w> And if not, what solution would we propose?
16:10:43 <tibbs|w> (Not that we have to propose one, but it might be nice.)
16:11:01 <tomspur> A static library as a subpackage would be fine
16:11:55 <geppetto> yeh, I'd suggest static lib.
16:12:07 <tibbs|w> Thing is, without an answer to my question that didn't get answered, the obvious route of just picking one of the programs from which to pull the source for the library isn't so obvious.
16:12:28 <tibbs|w> But I'd leave that up to the maintainer.  Have one of the packages spit out the library, his choice, and have the others use it?
16:12:43 <orionp> that seems reasonable to me
16:12:44 <geppetto> yeh
16:13:06 <tibbs|w> Could do a completely separate package using whatever source he wants to extract the library, but...
16:13:10 <tomspur> Better than leaving all bundled packages as is and just build and ship it (seems to be what upstream suggests)
16:13:36 <orionp> or suggest upstream to port to a maintained xmlrpc library :)
16:13:47 <tibbs|w> I just fear that we'd get into a situation where we have things vulnerable due to this unbundling where we wouldn't have otherwise.
16:15:05 <orionp> Yeah, after thinking a bit more, I'm not sure what unbundling as a static library gains us other than bookkeeping - but maybe that's worth it
16:15:31 <mbooth> xmlrpc-c-c++ is something that exists in fedora -- I wonder how difficult for upstream to port to it... though I wouldn't count on that happening of course
16:15:49 <geppetto> yeh, I'd assume not
16:17:23 * SmootherFrOgZ here
16:17:26 <tibbs|w> I'm kind of ambivalent here, really.
16:17:54 <geppetto> #chair SmootherFrOgZ
16:17:54 <zodbot> Current chairs: SmootherFrOgZ geppetto mbooth orionp tibbs tomspur
16:18:17 <tibbs|w> OK, there's the highlight.  And a different sound that scared the crap out of me.
16:18:18 <geppetto> Yeh, we can't fix the world … so as long as it's not bundling a horrible security problem, our job is done
16:19:23 <tibbs|w> I can vote for bundling here with the proper provides() marking, I guess, assuming we believe we can trust upstream to update everything with an issue is found.
16:20:16 <geppetto> I'd doubt that
16:20:28 <tibbs|w> Which, urgh, is why I asked the question that didn't get answered.
16:20:28 <geppetto> requiring static. lib. guarantees that, mostly
16:20:34 * geppetto nods
16:22:34 <tibbs|w> So, I'm guessing there's no chance of getting to +5.
16:23:54 <mbooth> Ehh, if there's never going to be another user of this lib, I could tolerate bundling
16:24:15 <orionp> I think we'd like there to never be another user
16:24:34 <mbooth> I don't know anything about ham radio, but seems like a low-risk leaf package
16:25:38 <tomspur> Won't be there more programs by the same author, that all uses this to communicate?
16:25:45 <tomspur> So several leaf packages by the same upstream
16:26:54 <mbooth> Sure, still seems low-risk -- it's kinda niche application
16:27:04 <tomspur> The static library would make sure, that all packages use the same code
16:27:22 <tomspur> tibbs|w: you would allow bundling in all applications with the proper provides() instead?
16:28:11 <tibbs|w> In this specific instance, yes, assuming we knew that the dev had a good track record of updating everything at the same time.
16:29:59 <tibbs|w> Which I'm not sure we know.
16:30:47 <tibbs|w> But I'm kind of willing to just go with it since the maintainer seems kind of adamant.  The chance of exposure here is really low, honestly.
16:31:27 <geppetto> I guess if everyone else thinks it's fine, I could go along with bundling
16:33:14 <mbooth> Vote then?
16:33:55 <tibbs|w> So basically: dumb situation, odd practices by upstream maintainer, should be pretty easy unbundling, but that's balanced against very low risk and limited use of the code (nothing outside the packages from a single maintainer).
16:34:24 <tibbs|w> I think we're all going to be waiting on everyone else to see if we'll go with a developing concensus.
16:34:33 <tibbs|w> How about this: is anyone actually strongly against this?
16:34:54 <tibbs|w> I mean, it is a lot of code, but this is getting into one of those "who really cares" situations.
16:34:55 <geppetto> I would certainly prefer a static lib.
16:35:18 <geppetto> just because … lots of code, code is C++, code is communication code, code is xml ;)
16:35:20 <tibbs|w> Maybe just bounce this back asking if that can be done.
16:35:31 * geppetto nods … sounds like a plan
16:35:35 <tibbs|w> And if there's stil; objection then we can revisit.
16:35:36 <tomspur> How about: 1: plain bundling, 2: static lib, 3: -1 as usual?
16:36:32 <mbooth> Fair enough -- if static lib can't be made to work easily, I would not be fundamentally against allowing bundling
16:37:12 <geppetto> Yeh, I would say that too
16:37:29 <tomspur> +1
16:37:56 <geppetto> #action Can you try to create a static library that all the components use
16:38:03 <geppetto> #topic #516 	Bundling exception for Thymeleaf
16:38:07 <geppetto> https://fedorahosted.org/fpc/ticket/516
16:38:24 <tibbs|w> Bundling exception week, it seems.
16:38:46 <geppetto> this seemed like a trivial +1 to me, but I wasn't sure we had a rule on this kind of thing, and they did ask
16:38:46 <tibbs|w> This isn't code, if I understand correctly.
16:39:14 <geppetto> Well it's DTD stuff … but, yeh, not python or C etc.
16:39:31 <tibbs|w> I didn't think DTDs could be considered code, really.
16:39:39 <tibbs|w> More just like a pile of data.
16:39:40 <geppetto> I guess I'd classify it a theme
16:39:46 * geppetto nods
16:40:05 <tibbs|w> But, xml, so I don't really understand it.
16:40:13 <orionp> any license issue?
16:40:31 <geppetto> no idea … I assumed not
16:40:42 <stbnruiz> .. forgiveness is a Security Meeting? .. am newbie! i am following the comments, and ideas :)
16:40:55 <tibbs|w> Bugzilla seems to not give me anything on the second link in the original report.
16:41:03 <tibbs|w> stbnruiz: This is a packaging committee meeting.
16:41:07 <tibbs|w> Of course, you are welcome here.
16:41:16 <tibbs|w> But it's probably pretty boring.
16:41:37 <tibbs|w> Bugzilla seems really broken for me lately.
16:41:43 <tibbs|w> But obviously offtopic.
16:42:10 <tibbs|w> Anyway, I'm +1 here unless anyone can come up with a good objection.
16:42:21 <geppetto> tibbs: click the raw unified link
16:42:36 <geppetto> I actually get text then
16:42:44 <geppetto> although it doesn't have any + or - lines
16:42:46 <tibbs|w> Yeah, that doesn't look like a diff.
16:42:51 <geppetto> which is probably why bugzilla is unhappy
16:44:04 <geppetto> Yeh, I'm still +1
16:44:11 <tibbs|w> Basically he's just pointing us at testsuite failures and not the actual changes.
16:44:18 <geppetto> tomspur: orionp: mbooth: vote?
16:44:22 <mbooth> I'm +1 too
16:44:26 <orionp> I'm +1
16:44:31 <tibbs|w> Which is really kind of annoying, but this is still just a bunch of entity definitions.
16:44:54 <tomspur> +1
16:45:06 <mbooth> I'm happy for software to define itself which subset of xml it can ingest
16:45:08 <geppetto> SmootherFrOgZ: You can vote too :)
16:45:14 <orionp> It seems like a weird thing to do, but seems fine
16:45:39 <SmootherFrOgZ> +1 from me
16:45:54 <geppetto> #action Bundling altered DTDs is fine, assuming the license allows it (+1:6, 0:0, -1:0)
16:46:10 <geppetto> #topic #518 	Confusion about '+' in a package name
16:46:15 <geppetto> https://fedorahosted.org/fpc/ticket/518
16:47:11 <tibbs|w> So I can't remember why we chose to define things this way, but I do think it's left kind of nebulous.
16:47:24 <tibbs|w> But I'm in general agreement with comment 3.
16:48:06 <tibbs|w> Which would imply that we don't need to actually change the guidelines to accommodate this usage, but maybe we should clarify what's the package name, and what's the delimiter.
16:48:23 <tibbs|w> Unfortunately I don't think I can do that without writing a wall of text.
16:48:38 <mbooth> Don't we explicitly allow + in package names? It is listed under "Specifically, all Fedora packages must be named using only the following ASCII characters."
16:48:50 <tibbs|w> mbooth: We do.  It's in the permitted character list.
16:48:56 <geppetto> Well a bunch of packages in Fedora use it
16:49:00 <tibbs|w> But, we don't allow them for separators.
16:49:12 <tibbs|w> Now, in g++ , that's obviously not a separator.
16:49:30 <tibbs|w> But perl-Tabs+Wrap.  Someone thought that the + was a separator.
16:49:31 <mbooth> Why would the usage in question be considered a separator?
16:49:33 <tibbs|w> I don't think it is.
16:49:50 <geppetto> Because it's between two words?
16:50:31 <geppetto> meh. … I'm fine with allowing it, but I'm not desperate to rewrite policy :)
16:51:21 * orionp wonders why the package has wrap in the name at all
16:51:48 <tibbs|w> orionp: It's two modules packed into one thing.
16:51:52 <geppetto> Because it provides Text::Wrap?
16:51:56 <tibbs|w> Text::Tabs and Text::Wrap.
16:51:57 <orionp> ah, found that
16:52:00 <geppetto> yeh, that
16:52:34 <mbooth> Oh I see -- I don't think it is a separator either, I read it as "tabs and wrap" (i.e. short form of and)
16:52:48 <orionp> yup
16:53:09 <tibbs|w> So... nothing to do then?
16:53:19 <geppetto> that would be fine by me :)
16:53:23 <orionp> right
16:53:34 <tibbs|w> Me, too, and I filed the thing (because someone asked me to do so).
16:53:44 <orionp> unless the submitter wants to try a hand at a rewrite
16:53:47 <tibbs|w> The ticket at least exists as clarification.
16:53:57 <tibbs|w> orionp: That would be me, and no.
16:54:02 <orionp> :)
16:54:07 <tomspur> I don't see where + could be used as a delimiter between the name and version? Or where...
16:54:07 <tibbs|w> Maybe when I run out of things to do at work.
16:54:14 * tomspur is confused by the ticket ;)
16:54:45 <tibbs|w> I don't know how else I can explain it.
16:54:56 <tibbs|w> + is not allowed as a "separator" or "delimiter".
16:55:01 <tibbs|w> The guidelines don't define either of those.
16:55:17 <tibbs|w> Someone asked if the + in perl-Text-Tabs+Wrap is a delimiter/separator or not.
16:55:34 <tibbs|w> The guidelines don't actually answer the question.
16:55:43 <tibbs|w> Ticket gets filed.
16:56:05 <tibbs|w> Seems like it's common sense to me, but then we know how rare that can be these days.
16:56:14 <geppetto> :)
16:56:50 <tibbs|w> Some examples might do it, and if I'm bored maybe I'll make some, but for now I think we should just say "the + here isn't a delimiter due to obviousness" and the ticket will exist as some reasonable documentation in case someone comes looking later.
16:57:00 <mbooth> +1 to no, it's not a delimiter, move on with life? :-)
16:57:01 <geppetto> I can see how someone might think it's a separator, so no big if we just say "Yeh, it's fine" and move on :)
16:57:22 <SmootherFrOgZ> tibbs|w: +1
16:57:55 <geppetto> tibbs|w: +1
16:58:19 <tomspur> actually, I cannot think of just one example of + as delimiter. That's why I'm confused right nwo
16:59:05 <geppetto> tomspur: Take a random package name and swap a - for a + :)
16:59:39 <tibbs|w> tomspur: There are none, because the guidelines forbid it.
16:59:43 <geppetto> :)
16:59:55 <geppetto> Anyone else want to vote, or do we even need to?
17:00:10 <tibbs|w> I think what's confusing is that there's the exception for _, which makes it seem like all of those examples use _ as a delimiter, when it's not a delimiter at all.
17:01:13 <tibbs|w> But, meh.
17:01:34 <tibbs|w> I may just go in and tweak the language slightly.  If I suddenly feel the need to rewrite things, I'll file another ticket.
17:02:56 <geppetto> #action The + here isn't a delimiter, so it's fine to use
17:03:10 <Rathann> hi
17:03:17 <geppetto> #chair Rathann
17:03:17 <zodbot> Current chairs: Rathann SmootherFrOgZ geppetto mbooth orionp tibbs tomspur
17:03:26 <tibbs|w> Hi.  Did Europe change time zones yet?
17:03:27 <geppetto> yeh, this is the last week of DST snafu
17:03:35 <geppetto> they change on Sunday
17:03:40 <geppetto> #topic #519 	Old filters in guidelines example
17:03:41 <mbooth> tibbs|w: On Sunday for me
17:03:45 <geppetto> https://fedorahosted.org/fpc/ticket/519
17:04:13 <tibbs|w> Man, comment 2 is annoying as hell.
17:04:30 <tibbs|w> But given Panu's comment, I think there's nothing for us to do here.
17:04:56 <tibbs|w> Unless that '!' is somehow an obvious typo.  At least on my keyboard ! and _ aren't anywhere near each other.
17:04:57 <geppetto> :)
17:05:33 <geppetto> I guess given the text that is what he meant
17:05:43 <geppetto> just replce filter with exclude
17:06:46 <geppetto> Has anyone used rpm excludes/filters?
17:07:01 <Rathann> I have
17:07:01 <tibbs|w> It's been a while, and that was the automatic Perl thing.
17:07:19 <geppetto> Rathann: Is it correct if you just remove the '!' ?
17:08:15 <Rathann> off the top of my head, I don't know, it's been a while since I used the filters, so I don't remember current macro names, but if that's the current name it looks fine
17:08:18 <Rathann> let me dig it up
17:09:22 <Rathann> looks like the name is correct at least for rpm-4.12.0.1 which I have on f21
17:10:02 <mbooth> Hmm, am I doing this wrong? http://pkgs.fedoraproject.org/cgit/eclipse-ecf.git/tree/eclipse-ecf.spec#n10
17:10:25 <orionp> mbooth - no
17:10:33 <Rathann> mbooth: no, you're doing post-filtering
17:10:43 <orionp> you're filtering the discovered requires directly
17:10:59 <orionp> not preventing what is searched for requires
17:11:05 <Rathann> excatly
17:11:11 <Rathann> *exactly
17:11:12 <mbooth> Oh I see -- that's okay then :-)
17:11:31 <tomspur> Is this also working on EPEL? It seems that guidelines is still using %filter_provides_in
17:11:49 <orionp> tomspur - there are notes about it in the epel guidelines
17:12:09 <orionp> only working in newer versions
17:12:44 <geppetto> So … if it works exactly the same, why did the name change?
17:12:52 * geppetto wonders if he really wants to know that
17:13:24 <geppetto> Anyway … I'm +1 for s/filter/exclude/ … if that's the new name
17:14:40 <orionp> I think it's just a typo
17:15:02 <orionp> the old macro is %filter_requires_in
17:17:09 <orionp> And it wasn't declared with %global
17:17:20 <orionp> so the mechanism is quite different
17:17:33 <orionp> see http://fedoraproject.org/wiki/EPEL:Packaging_Autoprovides_and_Requires_Filtering
17:17:39 <orionp> for the old stuff
17:18:03 <tibbs|w> Yeah, the old stuff is really much different.
17:18:49 <tibbs|w> As far as I can remember, there was never __provides_filter_from and this is just a typo and we should just fix it.
17:19:06 <tibbs|w> It's just a typo in an example.  I'm just going to do it now.
17:19:07 <tomspur> +1
17:19:27 <geppetto> ok +1
17:19:52 <geppetto> it would have been helpful if ppisar said it was a typo :(
17:20:02 <SmootherFrOgZ> +1 from me
17:20:17 <Rathann> +1
17:20:20 <mbooth> +1
17:20:21 <tibbs|w> Yes, here we are down the rabbit hole trying to understand what this old filtering mechanism was.
17:20:23 <orionp> I suspect he was confused to
17:20:26 <orionp> :)
17:20:32 <tibbs|w> It would also have helped if he hadn't called us children.
17:20:44 <tibbs|w> Anyway, I already made the change.
17:20:45 <geppetto> #action Fix typo in example from __provides_filter_from to __provides_exclude_from (+1:6, 0:0, -1:0)
17:20:50 * geppetto nods … cool
17:21:24 <geppetto> #topic Open Floor
17:21:37 <sgallagh> What timing. I have a topic :)
17:21:44 <geppetto> 506?
17:22:01 <sgallagh> No, that's still on my list, but I had to postpone it for Beta needs
17:22:09 <sgallagh> So I'll get back to that next week
17:22:12 <geppetto> ok, sorry … what did you want to bring up?
17:22:47 <sgallagh> I wanted to give a heads-up that, thanks to some recent changes, I'm going to be doing a total rewrite of the per-product config requirements
17:23:07 <sgallagh> I figured out a way to avoid the depsolving hackery that caused us a lot of trouble in F21
17:23:16 <Rathann> yay
17:23:24 <geppetto> sounds good :)
17:23:29 <tibbs|w> Yes, that's great.  Did you work out how to get DNF to do what you wanted?
17:23:38 <Rathann> +1 to avoiding dirty hacks
17:23:43 <Rathann> ;)
17:23:52 <sgallagh> The short version is that now the contents of /etc/os-release will be controlled by the fedora-release-* packages and will include an option VARIANT=[Cloud|Server|Workstation] or be nonexistent
17:24:19 <sgallagh> The %posttrans section of packages that need separate configuration should check this value.
17:24:31 <sgallagh> There's no need for separate config subpackages anymore
17:24:58 <sgallagh> I've already updated firewalld to behave this way in Fedora 22 (as of the TC5 currently building)
17:25:21 <sgallagh> By doing this, I was able to remove the Conflicts between the fedora-release-$product packages and kill off the fedora-release-nonproduct package.
17:25:28 <tibbs|w> Well, let us know what we need to change in the current guidelines and we'll have a go.
17:25:35 <tibbs|w> https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration in case anyone is wondering.
17:25:58 <sgallagh> tibbs|w: It'll be a total rewrite, which I'm aiming to put together tomorrow, but I wanted to give a heads-up
17:26:52 <sgallagh> EOF
17:26:58 <tibbs|w> Cool, thanks.
17:26:59 <tomspur> :)
17:27:14 <tibbs|w> I think there were a couple of minor things that I moved to meeting.
17:27:23 <tibbs|w> And the python macros thing.
17:27:45 <tomspur> about bundling for bootstrapping: https://fedorahosted.org/fpc/ticket/517
17:28:03 <tibbs|w> Oh, yeah.
17:28:07 <tomspur> Don't we always need a ticket for bundling anyway, when we bootstrap?
17:28:15 <tomspur> At least http://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries#Bootstrapping says so
17:28:44 <tibbs|w> Dang it, that "treatment" guideline being separate from the No_Bundled_guidelines page is annoying.
17:28:49 <tibbs|w> I always get trypped up.
17:29:25 <tibbs|w> How about I rename No_Bundled_Libraries to Library_Bundling (with a redirect) and merge the Treatment_Of_Bundled_Libraries page into it?
17:29:45 <mbooth> tibbs|w: Seems sane
17:29:52 <geppetto> +1
17:29:54 <tomspur> +1
17:30:09 <Rathann> wait
17:30:22 <Rathann> the bugzilla ticket is closed
17:30:48 <tibbs|w> Does that have any bearing on this discussion?
17:31:20 <tibbs|w> I mean, James closed the ticket as accepted; I assume they just went ahead.
17:31:20 <Rathann> hm, looks like it doesn't, the bootstrap exception is still needed
17:31:45 <tibbs|w> What they do with their bugs isn't really our thing.
17:33:38 <Rathann> +1 from me
17:33:47 <tibbs|w> Anyway, I'll go ahead and clean up the pages.
17:33:58 <tibbs|w> My time has been sporadic but I hope to get to this today or tomorrow.
17:34:09 <geppetto> Ok, cool
17:34:26 <geppetto> One last thing … I'll be away for the next two weeks
17:34:49 <tibbs|w> Awesome.  No meetings+
17:34:52 <geppetto> So we can either wait and have a giant meeting mid. April
17:34:54 <SmootherFrOgZ> heh
17:35:07 <geppetto> Or tibbs gets to volunterr for more work :)
17:35:31 <tibbs|w> I can try, I guess.
17:35:33 <geppetto> Hopefully we'll only get a couple of tickets, so it won't be a big deal to just wait
17:35:55 <geppetto> But seeing how many straws tibbs can take might be fun too :)
17:35:58 <tibbs|w> I'll do my best, assuming we can get quorum.
17:36:08 * geppetto nods
17:36:24 * tomspur is not here in 2 weeks, don't know next week for sure...
17:37:16 <geppetto> Anything else?
17:37:18 <tibbs|w> Well, I'll prep the stuff and if we don't get quorum then I get some free time.
17:37:23 * geppetto nods
17:37:51 <tibbs|w> There were a couple of random things, I guess.
17:37:59 <geppetto> tickets?
17:38:05 <tibbs|w> Is there anything to do for https://fedorahosted.org/fpc/ticket/514 ?
17:38:21 <tibbs|w> That's orionp's thing.
17:38:35 <tibbs|w> Seems to me that's not really something for the guidelines at all.
17:38:47 <tibbs|w> But it certainly should be written down somewhere.
17:38:52 <orionp> Yeah, I think I'm just going to stick it into the packaging tricks page
17:39:11 <tibbs|w> Cool.
17:39:19 <tibbs|w> https://fedorahosted.org/fpc/ticket/508
17:39:20 <geppetto> yeh, seems good
17:39:24 <tibbs|w> They asked us to reconsider.
17:39:29 <tibbs|w> Does anyone want to reconsider?
17:39:52 <mbooth> I'm afraid I have to run
17:39:57 <tibbs|w> What I really, really want is some standard mechanism for letting admins specify static UIDs at deployment time.
17:40:03 <geppetto> yeh
17:40:07 <tibbs|w> And we can get out of this PITA UID approval stuff.
17:40:41 <tibbs|w> Also, something about that ticket is very interesting.
17:40:53 <tibbs|w> There's some internal Red Hat stuff leaking out there.
17:41:08 <geppetto> Stuff like this is similar to ostree … where they have to jump through some hoops because they just want it so that they can have a single install, but not get bitten by rpm reordering install order
17:42:11 <tibbs|w> But the issue is only on initial system installation, right?
17:42:30 <tibbs|w> Otherwise they could just fix that in LDAP or manually add the fixed users before package installation.
17:42:49 <tibbs|w> Or is the concern that somehow randomly the UID they need is already taken by some other package?
17:43:04 <tomspur> Seems like what the client is saying: "So either you create it beforehand or ..."
17:43:07 <geppetto> Yeh, I think they want to have a single kickstart with all their packages … so they can't do the install; LDAP setup; install openstack … workaround
17:43:09 <tibbs|w> I guess if we knew the exact details of the problem, we could make a better determination.
17:43:28 <tibbs|w> OK, so what's needed is some method of UID fixing in kickstart.
17:43:39 <geppetto> yeh, that's my guess.
17:43:43 <tibbs|w> I'm thinking that's doable, really.
17:43:48 <tibbs|w> Just nobody has done it.
17:44:16 <tibbs|w> Honestly if I needed it I'd just rebuild setup locally.....
17:44:29 <tibbs|w> Because... that's not at all difficult.
17:44:44 <geppetto> doing stuff like that would be highly frowned upon within RH
17:44:54 <tibbs|w> Because reasons, I'm sure.
17:45:15 <tibbs|w> I mean, the obvious solution to the problem certainly can't be the permitted one.
17:45:45 <geppetto> Well, for various reasons … think of package building within RH as very similar to being a Fedora contributor
17:46:08 <geppetto> You can build your package … and even put it in special koji tags
17:46:08 <tibbs|w> But if you're doing specialized deployment, you'd do specialized local builds of things.
17:46:15 <geppetto> But you can't randomly change other people's packages.
17:49:58 <tibbs|w> Let me look at setup and anaconda a bit and see if there's any hope that I could figure something out.
17:51:32 <geppetto> cool
17:51:36 <geppetto> Anything else?
17:52:06 <geppetto> Ok, see you all in 3 weeks :)
17:52:09 <tibbs|w> I think I have an idea of how it might work.
17:52:17 <tibbs|w> Have fun or whatever, wherever you're going.
17:52:43 <orionp> later all
17:52:54 <Rathann> ok, thanks
17:53:00 <Rathann> have fun and see you later
17:53:42 <geppetto> #endmeeting