16:07:37 <abadger1999> #startmeeting Fedora Pckaging Committee
16:07:37 <zodbot> Meeting started Wed Nov 17 16:07:37 2010 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:07:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:07:41 <abadger1999> #meetingname fpc
16:07:41 <zodbot> The meeting name has been set to 'fpc'
16:07:55 <geppetto> here
16:07:56 <tibbs> spot just dropped offline.
16:08:17 <abadger1999> #chair tibbs geppetto rdieter rdieter_work
16:08:17 <zodbot> Current chairs: abadger1999 geppetto rdieter rdieter_work tibbs
16:08:37 <rdieter> yo
16:08:39 <tibbs> Not going to get very far with four people.
16:08:42 <abadger1999> yeah
16:09:16 <tibbs> Why do we keep having this problem?
16:09:38 <rdieter> need to find members that actually come to meetings
16:10:12 <abadger1999> so no racor, spot, rathann, limb, SmootherFrogZ
16:10:17 <geppetto> spot is on a buggy server, or something, and is trying to login
16:10:23 <abadger1999> k
16:10:25 <rdieter> (or at least are active enough by proxy via mailing list or other means)
16:10:29 <tibbs> Speak of the devil.
16:10:37 <spot> okay, lets try again
16:10:40 <spot> can anyone hear me?
16:10:43 <abadger1999> #chair spot
16:10:43 <zodbot> Current chairs: abadger1999 geppetto rdieter rdieter_work spot tibbs
16:10:43 <tibbs> Yep.
16:10:49 <spot> excellent. much better.
16:10:56 <spot> apologies, i have no idea what was going on.
16:11:01 <abadger1999> spot: We have five exactly
16:11:05 <spot> okay.
16:11:39 <spot> Alright, lets get right to the fun stuff.
16:11:40 <rdieter> we are fpc borg
16:11:50 <spot> #topic Bundling Exceptions
16:12:10 <spot> FESCo has given us responsibility for considering and approving bundling exceptions.
16:12:28 <spot> If we choose, we can send decisions to them for review/ratification, just like any thing else.
16:12:29 <tibbs> Should we decide on the information we want up front before folks submit exception requests?
16:12:39 <spot> tibbs: that seems like a very good first step.
16:13:34 <hicham> +!
16:13:40 <rdieter> yeah, else we'll just end up pinging everyone for more info
16:13:42 <abadger1999> #topic Bundling Exceptions --  https://fedorahosted.org/fpc/ticket/30
16:13:46 <hicham> +1
16:14:53 <abadger1999> We could use this section as a start: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Standard_questions
16:14:57 <tibbs> Personally I'd like to see things like a plan for resolving the bundling, the attitude of the upstream of the bundled code and input from the Fedora maintainer of the package which is being bundled (if one exists).
16:15:11 <spot> tibbs: seems sane
16:15:30 <tibbs> But every case is going to be different anyway.
16:15:39 <rdieter> abadger1999: ok, that's a good start.
16:15:51 <geppetto> It'd also be nice to know: How many other packages are likely to want something similar?
16:16:49 <rdieter> geppetto: not sure what you mean, can you rephrase that perhaps? or give an example?
16:17:09 <tibbs> I would expect that to be difficult for a submitter to know in general.
16:18:26 <geppetto> rdieter: As a generic example: I'd be much happier to allow bundling in a package that does something nothing else does … than to allow firefox to bundle something to make JS/blah faster (as then it's possible a whole bunch of web browsers will want to do the same)
16:18:55 <rdieter> ok, gotcha.
16:19:25 * spot isn't sure how we boil that down into a question that gives that answer
16:19:45 <rdieter> spot: agreed
16:20:03 <abadger1999> It's similar but not quite the same as: # Are the changes useful to consumers other than the bundling application? If so why aren't we proposing that the library be released as a fork of the upstream library?
16:20:06 <rdieter> I'be happy starting with https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Standard_questions , plus tibbs' suggestions
16:20:19 * geppetto nods
16:20:33 <spot> we could simply add tibbs's item to the list, as it already says "You should have answers to these standard questions before seeking an exception."
16:20:44 <spot> we could also change "should" to "must" in that sentence.
16:20:51 <rdieter> spot: +1
16:20:55 <geppetto> +1
16:21:01 <tibbs> Oh, definitely.
16:21:03 <tibbs> +1
16:21:17 <spot> +1 from me
16:22:04 <spot> abadger1999 ?
16:22:09 <abadger1999> +1
16:22:41 <spot> #action add tibbs's questions to the existing list, make it a must instead of a should
16:22:57 <spot> #action spot will make the changes and request the answers from the existing pending tickets
16:23:19 <tibbs> Do we want to look at any of the existing requests this week, or delay?
16:23:24 <spot> perhaps it would be worthwhile to walk through my request
16:23:28 <spot> since i am present
16:23:55 <spot> although, to be fair, it would be proper for me to recuse myself from a vote on it.
16:24:05 <spot> (and that would leave us without quorum to approve it)
16:24:54 * spot wonders if he's dropped off irc again
16:24:58 <geppetto> no
16:25:02 <spot> okay, good.
16:25:06 <tibbs> I just had to find which one was yours.
16:25:10 <tibbs> https://fedorahosted.org/fpc/ticket/25
16:25:15 <spot> yes, sorry.
16:25:37 <abadger1999> well -- we could walk through the questions we just approved and then see whatother things we are left asking.
16:25:42 <abadger1999> And then vote in the ticket.
16:25:44 <spot> okay.
16:26:04 <abadger1999> * Library modified -- yes.
16:26:15 <abadger1999> But then I want to ask how?  Is it bugfixes?
16:26:26 <spot> Some items are bugfixes, some are API changes.
16:26:42 <spot> EMBOSS depends on the modified behavior
16:27:30 <spot> It is also noteworthy to point out that EMBOSS has pulled out all other bundled copies of libraries and made it simpler for distributions to link against them.
16:27:32 <abadger1999> Is there any sense in reducing the set of differences on our own?  ie: by ourselves submitting the bugfixes to upstream plplot?
16:27:43 <abadger1999> \<nod>  That is significant.
16:27:57 <tibbs> Yes, they obviously have a plan, which makes it easier to accept what they are doing.
16:28:07 <spot> abadger1999: I asked them if they wanted me to do that, and they would prefer to attempt it themselves, because "they understand the reasoning behind the changes more clearly"
16:28:22 <tibbs> One other question I guess I might have is "why can't we just ship the fork"?
16:28:45 <geppetto> spot: Well for the bugfixes, the reasoning should be pretty simple … no?
16:28:58 <spot> geppetto: assuming I know what bug they're fixing. :)
16:29:06 <spot> geppetto: there are 10 years worth of changes here.
16:29:17 <geppetto> Yeh, it's the 10 years number that worries me a bit :)
16:29:19 <rdieter> tibbs: no one else uses it?  If there's only 1 consumer, that makes less sense doesn't it?
16:29:31 <spot> geppetto: the good news is that they were careful to make minimal API changes
16:29:45 <spot> geppetto: the code actually links against the system plplot, it just doesn't work when you do it.
16:29:53 <tibbs> Well, there are plenty of plplot-* packages and gdl.
16:30:17 <geppetto> spot: Can we move to the forked version?
16:30:29 <tibbs> Not that we should, but it's a fair question.
16:30:44 <spot> geppetto: Hard to say. I would imagine that some packages depend on the behavior of the system plplot and would need to be modified.
16:31:21 <spot> tibbs: to your question, I don't think upstream would prefer that, but they would tolerate us maintaining their fork (eplplot).
16:32:20 <abadger1999> Since it seems they've given it a new name...
16:32:20 <tibbs> My personal preference is that such forks be made pretty obvious.
16:32:36 <tibbs> Package them separately, maintain them as separate packages.
16:32:36 <spot> abadger1999: they gave it a new name to make it clear that there were differences in behavior
16:32:55 <spot> tibbs: I think the best we could hope for is to have a subpackage here.
16:33:17 <spot> tibbs: upstream does see the merit in not continuing to maintain a plplot fork
16:33:42 <rdieter> spot: +1 to subpkg
16:33:44 <spot> tibbs: it is simply a matter of time and money for them, and they have precious little of both.
16:33:57 <rdieter> otherwise, I'm of a mind to approve this exception
16:34:10 <geppetto> Right … so they might continue to not have either …
16:34:16 <geppetto> I'm +1 to a sub-pkg
16:34:49 <spot> the only concern I would have with a sub-package is that it is possible that their changes will make it into plplot upstream, but in a different way.
16:34:50 <rdieter> speaking about the subpkg bit, should we consider adding that to our bundling guidelines?
16:35:03 <spot> anything that depended on the older eplplot fork would be SOL
16:35:08 <geppetto> Given that it's been 10 years, and could well be another 10 … and it has bugfixes … I'm less happy for a bundle
16:35:10 <tibbs> Well, if spot recuses then we can't pass this, but I'm inclined to think this is the kind of thing that we shouldn't have much trouble approving.
16:35:14 <spot> as I would expect that they would then drop that fork entirely.
16:35:45 <spot> (but, it is likely that nothing else will ever depend on it)
16:35:53 <rdieter> since we're not going to pass this here then, should we vote in trac?
16:36:00 <spot> rdieter: please. :)
16:36:26 <spot> rdieter: to your point about the guidelines, i think that makes sense.
16:36:45 <abadger1999> Do we want to ask the plplot maintainer what he thinks and get a timeline of when the next round of funding is from EMBOSS?
16:37:03 <abadger1999> since we're adding those to the standard questions..
16:37:21 <abadger1999> Another question -- is emboss keeping the plplot base version updated?
16:38:00 <spot> abadger1999: a good question, i need to doublecheck that
16:38:11 <tibbs> Ah, yes, that's a good stock question.
16:38:34 * abadger1999 edits the standard questions page
16:38:54 <tibbs> I guess we should also ask something about security exposure.
16:39:30 <spot> abadger1999: the answer to that is no.
16:39:45 <spot> 5.7.2 is the base for their fork, current is 5.9.6
16:40:07 <abadger1999> k
16:40:25 <geppetto> uh … 5.9.4 is over a year old
16:40:32 <tibbs> Do they maintain base+patches?
16:40:52 <abadger1999> How much weight do we want to give to that?  It does mean that we can't react quickly if an update is critical
16:40:54 <spot> tibbs: no. it is a forked dir.
16:41:12 <tibbs> Ugh.  That makes it harder on them.  Doesn't really matter much for us, though.
16:41:33 <spot> well, it is noteworthy to consider that plplot upstream considers 5.7.4 current stable
16:41:40 <abadger1999> tibbs: Security exposure would be interesting but I don't know how useful it would be... Everyone claims that forking does not increase their security exposure.. most claim that it improves security.
16:41:41 <spot> and 5.9.* devel unstable
16:41:50 <geppetto> ahh, fair enough
16:41:57 <spot> so, they're not terribly behind
16:42:32 <tibbs> abadger1999: Sure, they can claim that, I guess.
16:43:04 <rdieter> abadger1999: it's all about point of view.  if the code is bundled, they don't rely on someone else.  but as a distribution, we obviously have a difference of opinion
16:43:11 <tibbs> But knowing that everyone will try to weasel out of answering a question is no reason not to ask it.
16:43:21 <abadger1999> If you look at the fesco tickets about bundling... firefox claimed bundling was more secure, some app that held private keys claimed that inclusion of the app makes fedora more secure and therefore we should allow bundling.
16:44:00 <geppetto> less eyes == more secure?
16:44:19 <rdieter> that's borderline silly
16:44:50 <abadger1999> firefox says: We have the flexibility to fix security ahead of upstreams' release schedules
16:45:09 <tibbs> It goes both ways.
16:45:31 <abadger1999> the private key app said: we need future API from the development branch and the app itself makes fedora more secure so you should let us bundle for now.
16:45:32 <tibbs> But that's especially hypocritical coming from Mozilla.
16:46:54 <tibbs> Didn't mean to kill discussion.
16:47:15 * hicham thinks that forgetting Mozilla case is a good idea
16:47:19 <geppetto> So, if we want to ask about "security exposure" we probably need to define it in some way so that people don't think "my app. does security stuff" == more security
16:47:29 <spot> okay, so i think the next step here is to add comments or votes to that trac ticket
16:47:33 <tibbs> Do we have some guideline business to get into while we still have a little time?
16:47:40 <spot> yep
16:47:43 <spot> we have a few items
16:47:51 <spot> #topic https://fedorahosted.org/fpc/ticket/12
16:48:14 <spot> i have some proposed exception text to the recently approved sourcedir guideline
16:48:25 <geppetto> Probably even define it in terms. of following what is happening with the upstream of their fork: So it's 1) Follow closer == 0. 2) Follow sometimes == bad. 3) Follow rarley == ver bad. 4) Dotn' follow == danger.
16:48:28 <spot> all the way at the bottom. :)
16:49:37 <spot> #topic Proposed exception to %{_sourcedir} guidelines: https://fedorahosted.org/fpc/ticket/12
16:49:41 <tibbs> I don't know of any other way to do that.
16:50:03 <spot> tibbs: neither did i, hence the exception. :)
16:50:06 <tibbs> Maybe someone who understands the lua stuff could find some way, but it hardly seems worth it.
16:51:00 <abadger1999> question though... why does that not apply if I generate the list in my package?
16:51:00 <rdieter> fwiw, in the kde-l10n case, I originally had a ton of -a ... items in %setup macro until than came up with the given solution here (much more compatc)
16:52:08 <spot> abadger1999: eh, okay, i could change the wording from "When upstream provides a list" to "When there is an available list"
16:52:50 <abadger1999> Okay -- +1, the exception makes sense to do.
16:53:33 <spot> +1 from me (with the wording change)
16:53:50 <rdieter> +1 (though biased)
16:53:51 <tibbs> +1
16:54:01 <geppetto> +1
16:54:25 <spot> #action Exception approved, with minor wording change (+1:5, 0:0, -1:0)
16:55:15 <spot> #topic Systemd - https://fedorahosted.org/fpc/ticket/31
16:55:21 <spot> this came in earlier today
16:55:27 <spot> i admit to not having time to have read it yet
16:55:35 <abadger1999> Doesn't look complete to me yet -- still questions on the page.
16:55:39 <tibbs> We did already have a ticket; can we combine tickets in trac?
16:55:54 <abadger1999> But I think it would be really good for us to read it and add other questions.
16:56:00 <tibbs> Are they expecting us to answer those questions for them?
16:56:28 <abadger1999> tibbs: I'll close the old ticket since lennart opened this ticket.
16:56:38 <tibbs> Where does the actual guideline start in that document, I wonder?
16:56:39 <abadger1999> tibbs: I think they'll answer them if they know they have to.
16:57:05 <abadger1999> tibbs: They started with my draft but didn't answer all of my questions/change the overall format.
16:57:11 <tibbs> The "I justify he current guidelines..." bit seems odd for a guideline; does it start down at "Scriptlets"?
16:57:39 <abadger1999> I think so.
16:57:46 <tibbs> And, ugh, triggers.
16:57:55 <spot> this draft is a bit hard to parse.
16:58:04 <abadger1999> I wrote the "I justify..." part and doesn't look like much (any) was added there.
16:58:30 * limburgher here, sorry I'm late. . .
16:59:19 <abadger1999> limburgher: Hey.
16:59:29 <abadger1999> https://fedorahosted.org/fpc/ticket/31
16:59:49 <spot> I think given the time and complexity of this item, we should read it over and put comments in trac
16:59:54 <spot> and we'll lead with it next week
17:00:06 <limburgher> Sounds good.  It's chunky, and importand to get right.
17:00:06 <geppetto> seems fair
17:00:12 <rdieter> ok
17:00:23 <geppetto> it's also not really a guidline yet … lots of "talk" in it
17:00:24 <tibbs> Plus, honestly, it's really not ready to go yet.
17:00:32 <spot> alright.
17:00:48 <abadger1999> Will that trigger work?
17:01:00 <abadger1999> Sounds good.
17:01:00 <spot> i am being pulled away for a work task right now, so i am opening the floor and going afk
17:01:04 <spot> #topic Open Floor
17:01:32 <tibbs> There are still some rpmlint issues.
17:01:33 <abadger1999> spot: Do we have time for: https://fedorahosted.org/fpc/ticket/3
17:02:00 <rdieter> abadger1999: it might, but I think I'd feel better if the init migration was handled in the packages themselves (httpd in this example), rather than upstart
17:02:31 <rdieter> abadger1999: but that would still likely require a %trigger (if we're shipping multiple init's)
17:03:09 <geppetto> abadger1999: So … the %posttrans bit was already done for GSettings?
17:03:23 <geppetto> abadger1999: talking about #3
17:04:02 <abadger1999> geppetto: gsettings isthe only draft of those three that I don't think is ready yet -- need to have the intro paragraph added by mclasen or another desktop guy.
17:04:20 <abadger1999> geppetto: These three: https://fedoraproject.org/wiki/User:Mclasen/giomodules
17:04:30 <abadger1999> https://fedoraproject.org/wiki/User:Mclasen/gdkpixbufloaders
17:04:34 <abadger1999> https://fedoraproject.org/wiki/User:Mclasen/gtkmodules
17:04:50 <abadger1999> I think are okay if we take out the Requires: portion
17:05:04 <geppetto> abadger1999: yeh … I'm mostly happy with them … apart from the posttrans bit … if that's intentional, I doubt it will do what the person who wrote it expects
17:05:05 <rdieter> agreed, knock out the Requires
17:06:28 <geppetto> So have no requires?
17:06:40 <abadger1999> Correct.
17:06:49 <abadger1999> Probably reirect &> /dev/null as well.
17:07:05 <geppetto> Why do we want to do that?
17:07:16 * spot is back
17:08:15 <tibbs> I have to admit I'm not at all up on these proposals.
17:08:30 <rdieter> geppetto: scripets should generally have no output anyway
17:08:48 <geppetto> No, I mean … why don't we want requires for somethign the scripts require?
17:09:03 <tibbs> You know, now that yum does something useful with the output, perhaps we should rethink that.
17:09:12 <rdieter> geppetto: and it'll give an error if the item isn't present (skips the need to wrap with something like ... if [ -x ... ]; then
17:09:22 <rdieter> tibbs: it does?
17:09:24 <tibbs> But how does a posttrans dependency work when you're uninstalling what it might require?
17:09:43 <tibbs> rdieter: It saves it and makes it available in the history, doesn't it?
17:09:46 <spot> tibbs: indeed, i do not think posttrans does what they want here.
17:09:53 <geppetto> Requires(posttrans) isn't valid in rpm atm.
17:10:00 <rdieter> tibbs: dunno, cool if it does
17:10:48 <rdieter> skvidal: ping, if you have a sec... to clarify ^^
17:10:53 <tibbs> So what is the posttrans actually trying to do.
17:10:55 <geppetto> tibbs: It does … but it marks it as "an error message" … so we don't _want_ things to output, but if they do it'll be saved
17:11:01 <skvidal> rdieter: you have geppetto there he's captain history
17:11:08 <abadger1999> tibbs: If the script fails, it's because the library that's going to make se of it has been uninstalled so I think it's okay.
17:11:09 <rdieter> ok. :)
17:11:14 <tibbs> rdieter: Yeah, we already have a yum dev on the committee.
17:11:24 <spot> tibbs: looks like it is trying to update the cache for the pixbuf loader list
17:11:41 <tibbs> But what's the benefit of runnining all of these updates at the end of the transaction?
17:11:45 <tibbs> Some cache effect?
17:11:55 <abadger1999> fs cache effect
17:11:56 <tibbs> Running it exactly once, now that would be useful.
17:11:57 <rdieter> tibbs: yes, that's the primary benefit
17:12:05 <geppetto> _maybe_ … but it'll be _much_ better when everything moves to rpm collections
17:12:27 <geppetto> Until then, I think it'd be better to just do what everything else doess … and have normal %post %postun
17:12:41 <spot> geppetto: +1, i'd prefer that
17:12:46 <tibbs> Any reference on "rpm collections"?
17:12:58 <tibbs> Sorry to distract, but I've not heard that before.
17:13:06 <rdieter> me either
17:13:23 <abadger1999> panu and ffesti were talking about it -- but I haven't heard anything for a while
17:13:23 <geppetto> http://rpm.org/wiki/Releases/4.9.0#Collections
17:13:47 <geppetto> which is useless
17:13:54 <tibbs> Yeah, it doesn't say mich.
17:13:56 <tibbs> much.
17:13:59 <spot> Hmm. %postun of old package runs before %posttrans of new package
17:14:28 <spot> is there any reason why we'd want that behavior, vs %post of new package running before %postun of old package
17:14:46 <spot> (i cant think of any, but i want to be thorough)
17:14:52 <geppetto> The basic idea is to solve this kind of problem (something you want to happen once per. trans, for a collection of packages, to rebuild a cache etc.)
17:16:25 <geppetto> I'd guess that for postun … we only want to rebuild the cache on delete, no?
17:16:42 <geppetto> Or do we normally do it twice, in other packages?
17:16:57 <spot> geppetto: i would think we'd also want to rebuild the cache upon a new install. :)
17:17:10 <spot> hence the %post or %posttrans
17:17:20 <spot> I just dont know what %posttrans buys us that %post doesn't.
17:17:46 <geppetto> I assume that it's a speed thing
17:18:05 <abadger1999> yep... just speed -- and that just from cache effect.
17:18:08 <geppetto> It might even be faster, depending on how the cache generation code is written
17:18:37 <geppetto> But it'll do "interesting" things on transactions that fail in the middle etc.
17:18:47 <geppetto> And is just different from how other stuff works
17:18:49 <abadger1999> although I think the desktop guys may have been planning to introduce a check-timestamps-of-cache type of thing.
17:19:18 <abadger1999> halfline: Do you know if mclasen is around?
17:19:24 <rdieter> posttrans also benefits if scriptlets are intelligent (ie, like the icon cache ones that can generally no-op if the cache is current)
17:19:50 <rdieter> or if scriplets can eventually be made intelligent
17:20:01 <geppetto> rdieter: Right, that's what I meant … you'd still run N %posttrans … but all except the first would just check the timestamps and exit
17:20:29 <abadger1999> mcepl: Hey, so people have some questions.
17:20:39 <abadger1999> mcepl: Sorry
17:21:04 <abadger1999> mclasen: Question was how does %posttrans help?  Is it just for thefs cache effect?
17:21:26 <abadger1999> mclasen: [09:19:25] <rdieter> posttrans also benefits if scriptlets are intelligent (ie, like the icon cache ones that can generally no-op if the cache is current)
17:21:50 <mclasen> I guess it is just the usual idea of 'why update the cache 20 times in a row', instead of just once
17:21:55 <abadger1999> So we don't know if they're intelligent/are planned to be intelligent.
17:22:10 <mclasen> but now that you mention it, I am not sure that the utilities in this case are smart about uptodateness
17:22:13 <abadger1999> mclasen: Ah -- but without the program being intelligent, %posttrans won't do that.
17:22:17 <mclasen> right
17:22:19 <abadger1999> okay.
17:22:54 <mclasen> so make it %post, for all I care
17:23:00 <abadger1999> k
17:23:18 * spot would prefer the devil we know if there is no compelling reason to go with %posttrans
17:23:26 <spot> we can always revisit this in the future if there is
17:23:31 * geppetto nods
17:23:35 <mclasen> this is not really comparable to the icon cache where we read tons of small files
17:23:37 <abadger1999> mclasen: A question was: a the Requires necessary?
17:23:45 <abadger1999> 2/a/are/
17:23:52 <geppetto> Hopefully we'll revisit all of these for F-16 or so, to use rpm collections
17:23:57 * geppetto is being optimistic again
17:24:47 <mclasen> abadger1999: wouldn't they ? or do you mean that a package that installs such a module will have  a dep anyway ?
17:24:54 <rdieter> I'd prefer making items that are even potentially cache-intelligent in %posttrans , then we can benefit from optimizations later and not have to change anything
17:25:01 <tibbs> F16 isn't all that far away.  Or at least the F15 branch isn't.
17:25:05 <abadger1999> If the modules automatically dep on the package they shouldn't be as the scriptlet might fail but then the library package would run its scriptlet and update the cache.
17:25:34 <mclasen> true
17:25:40 <mclasen> so they are not strictly required, then
17:25:45 <abadger1999> okay.
17:26:09 <mclasen> are you guys ok with my use of %{__isa_bits} ?
17:26:22 <abadger1999> looks good to me.
17:26:30 <mclasen> it is nice, in that it avoid these nasty wrapper scripts poking at $host
17:26:38 <spot> sure.
17:26:47 <abadger1999> geppetto: you're more familiar with %{__isa-bits} that look right to you as well?
17:27:02 <geppetto> yeh, it's not the greatest name (prefer rpm made one with less _'s) … but it should be fine
17:27:15 <rdieter> I thought I saw a comment in-ticket about using %{_isa} instead ?
17:27:31 <geppetto> The only thing is that we'd need to require %{_isa} on the package name too
17:27:57 <abadger1999> <nod>  And if we're getting rid of the Requires then we don't need to worry about that :-)
17:28:02 <geppetto> true
17:28:24 <abadger1999> mclasen: Cool -- the only other thing is that we don't have a nice intro paragraph about GSettings like we do for the other three.
17:28:39 <mclasen> I can try to come up with something
17:28:44 <abadger1999> mclasen: Would you be willing to write that and then we can vote on it separately?
17:28:55 <abadger1999> mclasen: Excellent.  Thanks!
17:30:21 <mclasen> abadger1999: where is the current proposal for gsettings ? some ticket ?
17:30:29 * abadger1999 proposes:  Vote on giomodules, gdkpixbufloaders, gtkmodules with these changes: Remove Requires; change %post to %posttrans for now -- revist if things are slow, cache updaters gain intelligence, or rpm collections become usable.
17:30:40 <abadger1999> mclasen: https://fedoraproject.org/wiki/GSettings_Draft
17:30:50 <abadger1999> mclasen: And the ticket is here: https://fedorahosted.org/fpc/ticket/3
17:31:10 <spot> +1 to abadger1999's proposal
17:31:14 <abadger1999> +1
17:31:37 <abadger1999> err s/%post to %posttrans/%posttrans to %post/
17:32:05 <spot> yeah, i meant that too. :)
17:32:05 <geppetto> If we remove the requires, do we need to redirect stderr?
17:32:29 <rdieter> geppetto: yes, imo
17:32:33 <abadger1999> geppetto: Given yum history existence, what do you suggest?
17:32:50 <limburgher> +1
17:32:52 * abadger1999 +1 either way.
17:32:59 <geppetto> I just don't see the point in history logging "no command found: blah"
17:33:24 <abadger1999> Okay, additional change: redirect output to /dev/null.
17:33:32 <geppetto> Ok. +1
17:33:34 <rdieter> +1 (though I'd prefer to keep %posttrans, but I seem to be the only one advocating that...)
17:34:09 <tibbs> One question:
17:34:14 <spot> still +1
17:34:32 <tibbs> the drafts say "These loadable modules have to be installed in (wherever)".
17:34:33 * spot counts +5 in that
17:34:34 * abadger1999 No strong feeling about %posttrans but thinks something is better than nothing.
17:34:43 <spot> tibbs, i think you're the only one missing from the record here
17:34:46 <tibbs> Is any package that puts files in (wherever) required to have these scriptlets?
17:35:09 <geppetto> I would assume so
17:35:22 <tibbs> I don't know if anything else goes in there or not.
17:35:46 * spot thinks so
17:35:53 <abadger1999> mclasen: ^ see tibbs's question
17:36:15 * hicham would file a ticket for a "bundling" exception soon
17:36:30 <mclasen> tibbs: nothing else goes in there, really
17:36:49 <tibbs> In other words, does a package that ends up putting stuff into one of these directories have to have one of these scriptlets?
17:36:55 <mclasen> tibbs: and yes, if you want your modules to be used after installation, you have to update the cache
17:37:12 <tibbs> OK.
17:37:25 <mclasen> so I would consider installing something there without updating the cache to be a packaging bug
17:37:42 <tibbs> +1 from me, but I'd suggest just tossing "MUST" somewhere into these kinds of things.
17:38:08 <tibbs> Otherwise it's not obvious that packages should fail review when they don't have those scriptlets.
17:39:11 * spot nods
17:39:15 <abadger1999> Alright that's +6
17:39:15 <spot> that makes sense
17:40:09 <spot> #action giomodules, gdkpixbufloaders, gtkmodules with these changes: Remove Requires; change %posttrans to %post, redirect output to /dev/null, make clear that these are MUST items (+1:6, 0:0, -1:0)
17:40:47 <spot> We're 40 minutes over time now
17:41:06 <mclasen> thanks for working overtime on my stuff :-)
17:41:07 <spot> So, thanks everyone, we'll see you next week at 1600 UTC (same bat time, same bat channel)
17:41:11 <spot> #endmeeting