Packaging:Minutes20070424

Present

 * AxelThimm
 * DavidLutterkort
 * JasonTibbitts
 * JesseKeating
 * RexDieter
 * TomCallaway
 * ToshioKuratomi
 * VilleSkyttä

Writeups
The following drafts have been accepted by FESCO and are to be written into the guidelines:


 * Minor clarifications to the filename encoding guidelines: https://www.redhat.com/archives/fedora-packaging/2007-April/msg00156.html

Votes
No proposals are submitted for FESCo consideration this week. There was preliminary voting on one issue (see below) but there will be further discussion at the next FPC meeting.

Other Discussions
The following additional items were discussed; see the logs for full details.


 * Switching the guidelines to recommend the use of %global instead of %define in specfiles. %define works unintuitively in some situations where %global works as expected.  See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237448 for a reference.  A draft on the differences between %global and %define in specfiles is being prepared and should be presented next week.


 * FPC's obligations to present information to FESCO and the manner in which that's done. We'll continue to use the current method until FESCO decides they'd like it done differently.

IRC Logs
[12:00] * tibbs here [12:00] * spot is here [12:01] /me, too [12:01] kinda here [12:03] Hmmm. [12:03] We can get something done if we have one more committee member. [12:03] f13 is almost certainly not going to be here [12:04] he's on vacation [12:04] Who allowed that? [12:04] --> scop has joined this channel (n=scop@cs181043142.pp.htv.fi). [12:05] eh, he escaped from his cage [12:05] we've got dogs tracking him down [12:05] here [12:05] * scop here in just a moment [12:06] thimm: wrt python macros, any thoughts on putting the macros directly into python-devel, kinda like how we recently did with cmake? [12:06] That would be a separate issue [12:06] Well, we're good to go on the encoding guidelines change, although there was a suggestion to u0pload the ascii chart to our wiki instead of linking to wikipedia. [12:06] But why not put them into redhat-rpm-config? [12:07] --> prosody has joined this channel (n=prosody@59.92.45.2). [12:07] ok, I don't care where they go, honestly, but (re)defining them in *every* python-related specfile seems overkill. [12:07] ++++ [12:07]  rdieter: i'm not sure anyone is advocating that [12:07] rather that the macros be fixed. [12:08] spot: well, consider *me* as an advocate then. :) [12:08] anyone disagrees on %define -> %global changes? [12:08]  thimm: no, %global is a good idea. [12:08]  If not, we could make it a QuickVote [12:08]  yeah, using global makes sense, its a pretty straightforward bug avoidance [12:08]  +1 [12:08]  --> Pingoomax has joined this channel (n=Maxime@fedora/Pingoomax). [12:08]  +1 [12:08]  +1 [12:08]  +1 [12:09]  <-- gilboa has left this server (Read error: 110 (Connection timed out)). [12:09]  * scop here [12:09]  do we know all the effects of %define -> %global? [12:09]  scop: using %global instead of %define to avoid recursion bugs in macros [12:09]  scop: In theory, yes, and in limited praxis [12:10]  It effectively places the %define outside of the surrounding braces [12:10]  while stil being conditional [12:11]  well it sounds good to me, but without knowing the exact semantics of either I don't feel comfortable voting for nor against [12:11] I don't even understand the difference; I'm sure there are subleties only divined by memorizing the RPM source. [12:11] Difference: [12:11] %define is local scope [12:11] %global is ... global scope [12:11] RPM actually has defined scoping rules? [12:11] Simple %define == simple %global [12:11] what is "local scope" in the context of rpm specfiles? [12:12] If used within another macro, then %define is only locally defined for the macros definition, %global not [12:12] and %define will re-evaluate stuff inside %'s, where's %global evaluates only once. [12:12] local scope= %{...} [12:12] Or the definition of a multiline macro [12:12] how does %{expand: ...} fit into the picture? [12:12] Same [12:13] it's local [12:13] So %{expand: } will break, too [12:13] what does %{expand: %global ...} mean? [12:13] If it also has lazy (=sloppy) grabage collection [12:13] s/%global/%%global/ [12:13] scop: %{expand:%define} is roughly equivalent to %global [12:13] Same as %define, only that %define may be level 1 nested, while %global is always level 0 [12:14] scop: %{expand:%global ...} is (afaik) kinda redundant. [12:14] hm [12:14]  Anyway it fixes a mean problem [12:15] And was commented by the god of rpm in a sane way [12:15] I'm reading the bug report ATM [12:15] sure, but what exactly are we voting for? [12:15] always use %global? [12:15] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237448 [12:15]  who is the god of rpm? [12:15] Use %global in %{!?...} [12:15] Hmm, CLOSED NOTABUG [12:16] That was me [12:16]  It isn't a bug in rpm [12:16] tibbs: axel closed it, not paul. [12:16] XulChris: he who must not be named. :) [12:16] Proposal is bug's summary: "%{!?bar: %define bar ...} construct broken by design, use %global instead" [12:16]  So is there any reason to actually use %define anywhere? [12:17]   rdieter: lol [12:17]  --> fabian_a has joined this channel (n=fabian_a@84-75-211-95.dclient.hispeed.ch). [12:17]  tibbs: Not really for non-.advanced stuff [12:17]  we have lots of python packages using the same template which uses %define - why are they not affected? [12:17]  If you have complicated macros that temporaily define a macro and dump it at the end you need %define [12:18]  Because there was no other macros invoced that did garbage collection [12:18]  * abadger1999 is here [12:18]  To my knowledge this includes paramterized macros and expand [12:18]  what was the package that triggered the issue?  vtk? [12:18]  OK, if you need more testing we can table this [12:18]  Yes, vtk [12:18]  But I've seen this bug before [12:19] OK, I've read the bug report and it makes sense to me. [12:19] And I have always worked around it with trial and error not understanding it [12:19]  But now with Jeff's comments on garbage collection it makes sense [12:19] So, we've ben using an ill construct all the time and were just "lucky" [12:20] yeah, it's also in the ruby guidelines .. probably other places, too [12:20] So the earlier voting was about changing the suggested python macros to use %global instead of %define? [12:20] Aynway, if you need some more time to spend on this, we can table this [12:20] tibbs: Not only python, every usage of this kind [12:20] Including ruby, if it uses that [12:21] i thought it was wherever "%{!?bar: %define bar ...}" appears in the guidelines, it should be replaced with "%{!?bar: %global bar ...} [12:21]   pear template uses %global [12:21]  Well, I'm all for it if it fixes bizarre bugs.  Our guidelines should always be as correct as we can get them. [12:21]  So +1. [12:21]  Proposal is "Make%{!?bar:%define bar ...} to %{!?bar: %global bar ...} everywhere" [12:21]  ok, lets vote on thimm's proposal [12:21]  +1 [12:21]  +1 [12:21]  +1 [12:21]  +1 [12:21]  Where "everywhere" == "wherever it appears in the guidelines", I assume. [12:21]  +1 [12:22]  so do we want to encourage use of %define _anywhere_? [12:22]  Well, we are only authitative for the guidelines [12:22]  <-- prosody has left this server (Read error: 60 (Operation timed out)). [12:22]  well, %define foo bar works fine [12:22]  yeah, it seems that for spec files, %global is always preferrable [12:22] +1 [12:22]  scop: Maybe not to avoid such bugs [12:22] its really only when you start to recurse that you hit issues. [12:22] %global would avoid them all [12:23] and it's what I always thought %define does :( [12:23]  RPM for the win! [12:23]  I think the preference of %define over %global is historical [12:23]  %define was there first [12:23]  And when nesting was invented one needed %global [12:23]  +1 for the current proposal, but I suggest we add an item about possibly s/%define/%global/g everywhere in the guidelines and spec templates [12:24]  yeah, i think we should do the following: [12:24]  OK, we are unanimous for the change :) [12:24] Use %global everywhere in the guidelines. Add a section to the guidelines describing %global vs %define. [12:24] where's Ralf when you need him? :) [12:25] I can prepare the section and we vote on it next time, OK? [12:25]  any ideas in which rpm version was %global introduced, if it was added after %define? [12:25]  thimm++ [12:25]  sounds good [12:25]  OK.  Do we want to pass any part of this to FESCo this week? [12:25]  let's do the whole shebang when it's ready [12:25]  sounds good. [12:26]  --> prosody has joined this channel (n=prosody@59.92.54.225). [12:26]  Is it OK, to push packages using %global for now? [12:26]  I have ancient vtk review request and that need %global [12:26]  thimm: there was never anything that said you couldn't use %global [12:27]  Well, we do have guidelines that tell me the exact line to paste in and that contains %define [12:27]  and yet, you're smart enough to know that you need to diverge from that with a good reason. :) [12:27] no need to start campaigning for use of %global in packages where %define works right now, I think [12:27] OK, point taken [12:28] thimm: we'll make the guidelines fix next week, we'll look forward to your draft. [12:28] OK [12:28]  lutter: any progress on ruby? [12:29] spot: sadly still nothing .. sorry [12:29] ok. [12:29] scop: got a draft for user/groups? [12:29] one way almost there [12:29] at least ready for discussion [12:29] (one way == all dynamic) [12:29] i think we might want to do the discussion on the list [12:30] still going? [12:30] or meeting over? [12:30] when the draft is ready, of course. :) [12:30] f13: still going, barely. [12:30]  k [12:30]  Well, one thing to note [12:31]  There was discussion at the FESCO meeting [12:31]  about whether they need to ack "minor" changes. [12:31]  I don't think the define -> global thing is "minor" but some could consider it to be so. [12:32]  It's a dangerous game to let us draw the line, later we will be accused of slipping thing under the carpet [12:32]  imo, minor and not controversial. [12:32]  If it is really minor, then fesco just nods off [12:32]  That's what I said, but FESCO seems to think differently. [12:32]  --> [splinux]  has joined this channel (n=splinux@fedora/splinux). [12:32]  So I still plan to pass all changes by them. [12:32]  Waste of 30secs of fesco time per minor item? [12:33]  FESCO will get over it. [12:33]  It's not as if we presented 100 items per meeting. [12:33]  Or even five. [12:33]  if they really get annoyed by "minor" issues, they can clearly define what they think is minor [12:33] how does it work, that FESCO ACKS everything, or that they have the ability to NACK(ie, veto) items? (there's a difference) [12:33] Officially they have veto power. [12:33] rdieter: isn't that the same? [12:34] when i was told to create this committee, it was with the mandate that FESCO can veto anything [12:34] But they still need to have the items presented to them for consideration. Otherwise we could just make changes and not report them. [12:34] no, because "not voting = not NACK'ing" [12:34] tibbs: doesn't the packging report to fedora-maintainers (or whatever) could as items presented? [12:34] s/could/count/ [12:35] Yes, but we all know that people don't read, and FESCO asks us for a summary at the beginning of every meeting. [12:35] it could. but we're being nice about it. :) [12:35] from the rabble seats: rdieter, that how it was planed in the past [12:35]  rdieter: you mean if fesco doesn't pay attention we get to do what we want? ;) [12:35] thimm: we have a winner! [12:35]  until you do something controversial and fesco notices [12:35] XulChris: exactly. [12:35] OK, then let's do the veto procedure and tibbs send his reports to fedora-noone-reads-this-list ;) [12:36]  tibbs/I whoever can still give summaries when/if FESCo wants.  no biggie. [12:36]  Aynway, if that's the way fesco wants to handle it, it's OK [12:36]  I just don't want to be the one deciding waht is major and minor [12:36]  how about this. [12:37]  how about we report on what we decided, we lset fesco decide if they want ot vote on something or not [12:37]   f13: isnt that how it works now? [12:37]  <-- bpepple has left this channel ("Ex-Chat"). [12:37]  That's pretty much what I've been doing. [12:37]  no, they get to vote on everything [12:37]  XulChris, they vote on everything [12:37]  of course, voting to vote is silly [12:37]   thats silly [12:37]  XulChris, that happend somehow over time and was never planed like this afaik [12:37]  Usually I present and it goes through if nobody has a complaint. [12:38] Which is precisely what I understood "they can veto" to mean. [12:38] yeah, i'm ok with what we're doing now [12:38] if FESCO wants us to change, they can tell us that. [12:39] back to UsersAndGroups, it's as finished as I'm going to make it for now without more discussion [12:39] ok [12:39]  i'd like to try and do this discussion on the list [12:40] if someone wants to document the other approaches (fixed uid mappings etc), it'd be better if someone other than me does it - I'm probably a bit too biased to do that objectively :) [12:40]  since its bound to be controversial [12:40]  scop: can you announce the draft on the mailing list? [12:41]  sure, if you think it needs to be announced in addition to being mentioned in the meeting report [12:41]  scop: I'll do the semi-static uid proponent [12:41]  --> llaumgui has joined this channel (n=llaumgui@fac34-5-82-239-136-153.fbx.proxad.net). [12:41]  "Nah, I think semi-static model sucks, I go for Ville's model" [12:42]  if we want the other models documented, I think we should do them in a "black box" manner [12:42]  ie. stick with the implementation, and compare/bash others later when we have all documented [12:42]  From what I read your proposal looks quite sane [12:43]  one item for the meeting: meeting time. [12:43] It would be sad to create lots of noise with 10 more models [12:43] i'm really going to send out a request for us to consider a meeting time change [12:43] we're losing racor entirely [12:43] i'm going to clear http://fedoraproject.org/wiki/Packaging/NewMeetingTime out and let people fill it back in [12:44]  (i know i said this last week, but i _will_ do it this time) [12:44] so, keep your eyes open for that, and try to be flexible [12:44] anything else for today? [12:45] We still have 15 min [12:45]  i got some php stuff but wont be ready until next week [12:45] Maybe fix multilib? [12:46] I don't think it's within our power to fix multilib. [12:46] (since no one bites, I'll amdit it was a joke) [12:46] OK, one bites :) [12:46]  We can write guidelines for how to split packages to avoid problems, though. [12:46]  No, I was joking, the multilib design is currently making people smash their heads [12:46]  tibbs: +1 [12:46]  thats an F8 item. i'll write the draft for that after F7. [12:47]   remi seemed kinda angry at packaging comittee for not looking at his pecl proposal, any familiar with that? [12:47]  what pecl proposal? [12:47]  *** knurd is now known as knurd_afk. [12:47]   spot: im not sure, i vaguely remember him mentioning it several months ago on packaging list [12:47]  "what proposal?" is exactly the problem.  :) [12:47]  spot: ill get more info and present it to you with other stuff next week [12:48] spot: Regarding the meeting time, I'm honestly not sure that chart would look any different than it does now. [12:48] tibbs: eh, well, we'll see [12:48] XulChris: Please check http://fedoraproject.org/wiki/Packaging/Committee#head-bc786fd8400956418c30ac87c30733f0c008b146 [12:49]  thimm: cool thx [12:49] ok, then, lets adjourn early. thanks all. [12:49] XulChris: you or remi create the proposal under http://fedoraproject.org/wiki/PackagingDrafts [12:49] OK, buy all [12:49] rdieter: Are you still blocked at 16:00? [12:50] tibbs: no worries, we can move if need be. [12:50] BTW I may not be able to make it next and next to next time, I'll mail that on the list, too