Packaging:Minutes20071016

Present

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

Writeups
No new guidelines this week.

Votes
No votes this week.

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


 * Moving the meeting one hour earlier. The next FPC meeting will be at 2007-10-30T16:00Z, October 30 16:00UTC.
 * Octave packaging guidelines: http://fedoraproject.org/wiki/PackagingDrafts/Octave
 * It seems this needs a bit more work. rdieter has volunteered to drive this and will work with the draft submitters to get things into shape.

IRC Logs
[12:02] *** You set the channel topic to "Fedora Packaging COmmittee Meeting". [12:03] *** You set the channel topic to "Fedora Packaging Committee Meeting". [12:03] Doh. [12:03] * spot is here [12:03] Fedora Package CO [12:03]  When it absolutely has to be delivered intact (mostly). [12:03] I can't believe I flubbed the time in the previous meeting minutes. [12:04] don't worry. no one reads the minutes anyways. ;) [12:04] I really can't believe that nobody noticed until Ralf complained by personal email to me this morning. [12:04]  I do! [12:04]  ok, who is here? [12:04]  * rdieter is here [12:04]  * lutter is here [12:05]  abadger1999, f13, scop? [12:05]  spot: pong [12:05]  pong [12:05]  spot: here. [12:06]  ok, thats 7. [12:06]  I hate to have to mention this, but thimm has missed several consecutive meetings now. [12:06]  tibbs: yep. [12:06]  hasn't racor too? [12:06]  tibbs: didn't he give us notice that he would tho? [12:06]  thimm did notify us beforehand [12:06]  rdieter: he did. [12:06]  OK, sorry. [12:07]  racor, not sure. [12:07]  but I think he's been away for much longer than he originally said [12:07]  Ralf has stated that the time is inconvenient for him. [12:07]  * spot nods [12:07]  so, i have two items for today [12:07]  Of course, he never replied to pleas for him to tell us what times would actually be convenient. [12:07] 1. Python eggs got approved by FESCo [12:08] the second item is more indepth. [12:08] we've all been on this committee for a long time [12:08] so, if anyone would like to step down and let someone else take their seat, i'm not opposed to it. [12:09] I'm going to send out an email that says as much. [12:09] I'm fine to continue on. [12:09] So we have others who wish to be on the committee? I have no problems with continuing. [12:10] no one has seriously asked to be on the committee [12:10] no problems here either, but I think some fresh blood wouldn't hurt [12:10] but i didn't want anyone to think that this was a lifetime appointment. ;) [12:10] heh [12:10]  I'd like to see some new people in, but I can continue to serve. [12:10]  ok, so maybe we should talk about that. [12:10]  right now, we're at 9 members [12:11]  I think the people who complain most about the decisions of the committee are already on the committee; is there criticism that I'm not really seeing? [12:11]  tibbs: none that i'm aware of, in fact, i think that FESCo seems to think we're doing a good job [12:11]  do we want to open some seats, grow the committee, and increase the quorum? [12:12]  --> racor has joined this channel (n=rc040203@HSI-KBW-082-212-056-027.hsi.kabelbw.de). [12:12]  racor: welcome [12:12]  hi, sorry for being late 17:00 UTC doesn't really suite me [12:12]  * abadger1999 notes that we shrunk quorum before so it's not a leap to expand it. [12:12]  spot: I think a call for who'd be interested might be welcome.  Then those already on teh board can decide given the new interest ifthey want to step down and free up some chairs. [12:13] racor: we're discussing adding new members to this committee [12:13] f13++ [12:13] I think that makes a lot of sense ... also expanding to 11 seems like a good idea [12:13] fpc: no goes to 11 [12:13] our committee goes up to 11. [12:14] sending out a general interest check seems reasonable [12:15] racor: on the subject of time, we'd need to go earlier to make things easier for you, correct? [12:15] spot: right anything < 17:00 UTC would be better [12:16] dst ends soon though, does that help? [12:16]  ! [12:16] We've all been through this before, though; don't folks in California have an issue with going earlier? [12:16] tibbs: i think we have a window from 15:00 - 17:00 UTC [12:16] scop: no, what really matters is 19:00-21:00 local time being my family's dinner time ;) [12:17]  lutter: whats the earliest you could reasonably attend? [12:17]  I can go an hour earlier as long as dst doesn't make everything change. [12:17]  kde sig could (probably) move +1/-1 hr to open 16:00 utc slot [12:17]  spot: right now, 9am P[D|S] T would be the earliest [12:17]  (beforethen, I am on childcare duty ;) ) [12:17] an hour earlier puts it currently through East Coast lunch time, but small sacrifice. [12:18] f13: especially since we're biweekly [12:18] if we don't change the time for timezones that will "resolve itself" for part of the year. [12:18] ok, so lets do this [12:18] rdieter: can you see if you can move the kde sig time slot? [12:19] perhaps, swap it with ours? [12:19] maybe, sure. [12:19] we'd move to 16:00 UTC, one hour earlier than now [12:19] f13: won't we cause racor to miss dinner again ? [12:20] racor: will that work better for you? [12:20] lutter: 16:00 UTC during DST in summer would be OK, in winter it wouldn't [12:21]  * spot tries to remember if the german seasons map up to US seasons or not [12:21] hope so. [12:21] that's what I thought ... we should have hte meeting at a fixed time in everybody's local time (module differences in when dst starts/ends) [12:21] spot: it's hte same hemisphere ;) [12:21]  spot: Basically yes.  (North south is where they flip fop) [12:22]  spot: but I think there's a week or so difference in the fall [12:22]  yeah, ok, thats what i thought. [12:22]  spot: IIRC, almost.  Germany shifts from CEST to CET end of October (next week?) [12:23]  wikipedia: Since 1996 European Summer Time has been observed from the last Sunday in March to the last Sunday in October [12:23]  Starting in 2007, most of the United States and Canada observe DST from the second Sunday in March to the first Sunday in November [12:24]  doesn't sound like a big deal [12:24]  ok, so we really want to meet at 6 PM, local racor time. [12:25]  RST [12:25]  which should always map up to 9 AM, lutter standard time, right? [12:25]  (except for one week) [12:26]  yep [12:26]  do i have that correct? :) [12:26] spot: fine with me. [12:26] great. assuming rdieter can move/swap the kdesig meeting, we'll do that in two weeks [12:27] racor: thanks for being patient with us. [12:27] spot: welcome [12:27] ok, does anyone have anything they'd like to discuss today before we adjourn? (if not, please say no.) [12:28] ponies! [12:28] no [12:28]  no. [12:28]  no. [12:28]  otherwise, no. [12:28]  no [12:28]  Is octave ready? [12:28] no [12:28]  http://fedoraproject.org/wiki/PackagingDrafts/Octave [12:28] * dgilmore is here [12:29] who's driving that? [12:29] (its not on the todo list) [12:29] Alex Lancaster? [12:29] There's no one on committee who's volunteered to drive it yet. [12:29] Or Orion, I guess. [12:30] would someone like to talk to Alex and/or Orion to see if its ready? [12:30] Orion wrote it and it hasn't received any negative feedback so I think it needs at least som commentary [12:30] rdieter: i plan to have knetworkmanager require NetworkManager-gnome  and have /usr/bin/knetworkmanager be a wrapper that calls nm-applet   so that when it does get fixed  it should not be too horrible to revert to knm [12:30] (from us) [12:30] dgilmore: evil. I think I like it. [12:31] rdieter: i just need to make it happen [12:31] the octave guidelines look rather simplistic to me right now [12:31] I can find nothing to complain about in the current Octave draft. [12:31] (not a bad thing) [12:32] I volunteer to drive the octave proposal. [12:32] rdieter: awesome. can you make sure they're ready for us to poke it with sticks? [12:32] rdieter: Thanks! [12:32] Then I can hit ^A^K [12:32] Does anybody know what what  dist_admin in %post %postun does? [12:32] It's described near the botton. [12:32] "bottom". [12:32] Octave maintains a list of installed packages in /usr/share/octave/octave_packages that needs to be updated on package install and removal. This is handled by the dist_admin script in each package. [12:33] It is not uncommon for packages to register themselves with whatever framework they're plugging into. [12:33] yep. R does this too. [12:33] thats what I feared - yet another pkg database :( [12:33]  R, texinfo, anything with a shared library. [12:34]  The only thing I saw was the use of libexec.  Orion said the hierarchy could be moved to libdir though. [12:34]  is the draft actually using libexec? [12:34]  spot: yes. [12:34]  i see %{_datadir} everywhere [12:35]  %{_libexecdir}/octave/packages/%{pkg}-%{version} [12:35]  arch-specific example. [12:35]  tibbs: Note: "shared" == noarch, AFAIU, the octave database is arched => must not be under /usr/share [12:35]  ah, ok. [12:35]  that's where octave put's it's own loadable modules/packages. [12:35]  racor: Not sure why you're directing that at me. [12:36]  yeah, i think i'd much rather see %{_libdir} as well as the db moved to an arch specific location [12:36]  because you replied to my question: texinfo's dir is noarched. [12:36]  otherwise, i can see it breaking on multilib [12:37] spot: naw, you can't(*) have different archs of octave installed anyway. (*) ok, shouldn't. [12:37] rdieter: yum just offered to do it. [12:38] yeah, octave should probably have an octave-libs perhaps. [12:38] but isn't %{_libexecdir} arch-specific anyway? what's the problem? [12:39] rdieter: /usr/share is supposed to be mountable across different arches. [12:39] where is octave's db? [12:39] the proposal says in /usr/share [12:39] I am talking about /usr/share/octave/octave_packages and dist_admin [12:39] libexec is supposed to be for helper binaries, not for arch specific shared objects [12:40] libexecdir is the same on i386 and x86_64. [12:40] libexec is like "/usr/bin" ... single arch'ed [12:40] either way, it doesn't seem like it would work for multilib [12:41] b/c the package directory is in /usr/share [12:41] this is odd though, don't they embed a lib/lib64 later in the path? [12:41] ew, ok. [12:41] spot: right, I forgot. [12:41] %{_libexecdir}/foo/bar/lib64/ ? [12:41] yes. [12:41] * spot frowns [12:42] spot: nope. libexec if for binaries. libs go to libdir (multi*lib*ed) [12:42] racor: i think we're on the same page on how it should be. [12:42] Anyway, I've got to quit (dinner is waiting) ;) [12:42]  in fairness to octave, I think some of the addons include binaries (or used to, in previous versions of octave). [12:42]  racor: thanks [12:43]  rdieter: fwiw, i don't like the arch conditionalization happening below %{_libdir}/ [12:43]  I'll find out for sure, what they are, what is included, so we can determine the best course here. [12:43]  i would much rather see octave behave sanely, and use %{_libdir} for that [12:44]  spot: downside is that would stray much from upstream layout. [12:44]  upstream isn't always the smartest. [12:44]  :) [12:44] "sane" is the key. [12:44] rdieter: understood, but perhaps we should be talking to upstream about this [12:44] especially when it comes to adherence to FHS and handling multilib. [12:44] see if there is a good reason for this. [12:44] will do [12:45]  ok, if there is nothing else, we're adjourned for two weeks. [12:45] thanks all. [12:45] Now, to be clear, what is the meeting time next week? [12:45] fwiw, got confirmation that kde-sig'ers ok with moving to 17:00 UTC. [12:45] so 16:00 is open. [12:46] tibbs: one hour earlier than currently. [12:46] Woo hoo. 16:00UTC [12:46] I'll update the meeting wiki. [12:46] http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel [12:46] rdieter: thanks [12:49] yay