From Fedora Project Wiki

Fedora Packaging Committee Meeting of {2007-10-16}


  • DavidLutterkort (lutter)
  • JasonTibbitts (tibbs)
  • JesseKeating (f13)
  • RalfCorsepius (racor)
  • RexDieter (rdieter)
  • TomCallaway (spot)
  • ToshioKuratomi (abadger1999)
  • VilleSkyttä (scop)


No new guidelines this week.


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