From Fedora Project Wiki

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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

Present

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

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]  <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 (n=rc040203@HSI-KBW-082-212-056-027.hsi.kabelbw.de).
[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> http://fedoraproject.org/wiki/PackagingDrafts/Octave
[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> http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel
[12:46]  <spot> rdieter: thanks
[12:49]  <f13> yay