From Fedora Project Wiki

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

Present

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

Writeups

No proposals were submitted to FESCo last week, so no new guidelines this week.

Votes

The following proposals were considered:

Other Discussions

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

IRC Logs

[12:02]  * spot is here
[12:03]  * tibbs here
[12:03]  * lutter here
[12:04]  * rdieter here
[12:04]  <racor> racor is here
[12:04]  <spot> i know f13 and abadger aren't going to be here
[12:04]  <spot> scop?
[12:04]  <scop> pong, working on UsersAndGroups
[12:05]  <spot> ok. i just looked at it to see if it had changed. :)
[12:05]  --> thimm has joined this channel (n=thimm@p54BD7B6E.dip.t-dialin.net).
[12:05]  <spot> ok, with thimm everyone is accounted for
[12:06]  <spot> Lets start with R
[12:06]  <spot> http://fedoraproject.org/wiki/PackagingDrafts/R
[12:06]  <spot> i hope that is fairly straightforward
[12:07]  <spot> theres not a lot of R packages in Fedora yet, but there is a lot of interest
[12:07]  <tibbs> There are a bunch up for review.
[12:07]  <spot> these guidelines were put past the fedora R community for feedback
[12:07]  <spot> and they are pretty happy with them
[12:07]  <spot> i made some minor changes, mostly clarification items
[12:08]  <tibbs> The "Installing the R addon bits" section mentions %{_datadir} but that only works for noarch packages.
[12:08]  <spot> ah, ok. easyfix. :)
[12:08]  <tibbs> Anyway, I've gone through these before, so +1
[12:09]  <rdieter> looks purty nice: +1
[12:09]  <thimm> +1
[12:09]  * spot votes +1 for his own draft
[12:10]  <lutter> +1
[12:10]  <scop> there's no "normal" dependency on R in the templates, just (post) and (postun)?
[12:10]  <spot> scop: the arch specific packages will pick up a libR dependency
[12:10]  <spot> the noarch packages will need a Requires: R
[12:10]  <racor> I'm hesitant on the "cd .."'s
[12:10]  <thimm> (BTW always a tetex dependency or just for the example's sake?)
[12:11]  <spot> thimm: the R docs rely on tetex
[12:11]  <spot> racor: its either cd .. or a much more complicated %setup
[12:11]  <racor> because I've occasionally seen rpm screwing up outside of RPM_BUILD..
[12:11]  <racor> or what the correct name is ... ;)
[12:11]  <spot> i tested with cd .. and it worked ok for me
[12:12]  <thimm> spot: but are there always ARE-docs?
[12:12]  <racor> debug-infos?
[12:12]  <spot> thimm: in every package I've ever done, yes.
[12:12]  <thimm> s/ARE/ARE/
[12:12]  <thimm> Dammit!
[12:12]  <spot> thimm: i know what you meant. ;)
[12:12]  <spot> racor: they're being generated ok
[12:12]  <racor> spot: if YOU say so ...
[12:12]  <tibbs> I think the CD is OK.
[12:12]  <spot> the only reason we have to cd .. is because R wants to look at the toplevel module name
[12:12]  <scop> wouldn't %setup -c, then cd %{packname} instead of ".." in %build, %install and friends work?
[12:13]  <thimm> That's an ugly feature of gaim, replacing  this package's name with "are" ...
[12:13]  <tibbs> After all, if you have multiple setup macros, you're making multiple directories there and may need to manipluate them.
[12:13]  <spot> you end up doing: %setup -T -c -a 0
[12:13]  <spot> or something similar
[12:13]  <tibbs> It's not escaping from the sandbox that's given to it.
[12:14]  <tibbs> But yes, you can save the cd if you tell setup not to cd into there in the first place.
[12:14]  <spot> I'm not opposed to %setup -c
[12:15]  * spot does a quick test
[12:15]  <tibbs> It is a couple of characters shorter.
[12:16]  <spot> racor: [spot@localhost cvs] $ rpm -qlp /home/spot/rpmbuild/RPMS/x86_64/R-hdf5-debuginfo-1.6.6-1.fc8.x86_64.rpm
[12:16]  <spot> /usr/lib/debug/usr/lib64/R/library/hdf5/libs/hdf5.so.debug
[12:16]  <spot> /usr/src/debug/hdf5
[12:16]  <spot> /usr/src/debug/hdf5/hdf5
[12:16]  <spot> /usr/src/debug/hdf5/hdf5/src
[12:16]  <spot> /usr/src/debug/hdf5/hdf5/src/hdf5.c
[12:16]  <spot> and yeah, %setup -c works nicely.
[12:16]  <spot> i'll make that change
[12:17]  <tibbs> It gets rid of the need for the cd in the check section as well, doesn't it?
[12:17]  <spot> yes
[12:17]  <spot> so its win win
[12:18]  <spot> ok, i made the changes to the draft.
[12:18]  <spot> anyone want to add or change a vote?
[12:19]  <scop> # Clean up in advance of check
[12:19]  <scop> doesn't that break repeated -bi --short-circuit builds?
[12:19]  <spot> well, i'm not sure we've ever "supported" --short-circuit builds
[12:20]  <scop> why not?
[12:20]  <spot> eh, because most people don't get what they expect.
[12:20]  <tibbs> I don't see how it would break them.  It's an idempotent operation.
[12:20]  <racor> what about the explicit tetex dep? If, as you said, "Building R always requires tetex", shouldn't R-devel better pull-in tetex?
[12:21]  <spot> racor: it is possible for an R package to not include documentation
[12:21]  <spot> then it wouldn't need tetex
[12:21]  <scop> 1) we have *.o and *.so in place, R CMD INSTALL installs them
[12:21]  <scop> 2) we remove *.o and *.so
[12:21]  <scop> 3) R CMD INSTALL runs again, *.o and *.so are no longer there
[12:21]  <scop> what happens?
[12:21]  <spot> R CMD INSTALL will rebuild them
[12:21]  <spot> if they're not present
[12:22]  <scop> ah, ok, didn't notice the empty %build section
[12:22]  <scop> so there's no R CMD BUILD or something that would just build the stuff to place in %build?
[12:22]  <spot> not really, no.
[12:22]  <tibbs> Unfortunately not.
[12:23]  <spot> and even if there was...
[12:23]  <scop> ok, I think the current template is ok then
[12:23]  <tibbs> I'm assuming R gets the proper CFLAGS and such from when it was built.
[12:23]  <spot> tibbs: it does
[12:23]  <scop> oops
[12:23]  <scop> what about --target i686 on a i386 R system?
[12:24]  <spot> it asks R for the flags it was built with
[12:24]  <spot> and maps up to that
[12:24]  <spot> so it wouldn't i686 opt without a hack
[12:24]  <scop> that's different from others
[12:24]  <racor> spot: This would mean R isn't multilib-able
[12:24]  <scop> we honor the user's choice in perl, python, ruby templates
[12:24]  <spot> racor: ehh...
[12:24]  <spot> it will build i386 and x86_64 fine
[12:25]  <spot> it just doesn't normally know how to handle any subarches
[12:25]  <racor> spot: How? How does compilation receive the appropriate CFLAGS?
[12:26]  <racor> Normally in x86: -m32/-m64
[12:26]  * spot looks to tell you exactly how
[12:29]  <racor> anyway, as usual ;), my time's up for today, I'll have to leave. preliminary +1 to Spot's proposal.
[12:29]  <spot> ok
[12:29]  <spot> so when R builds
[12:29]  <spot> it looks at all the compiler related flag environmentals
[12:29]  <spot> and saves them in a file called Makeconf
[12:30]  <spot> then, everytime R CMD INSTALL gets called after that, it sources Makeconf
[12:30]  <spot> and reuses those flags
[12:30]  <spot> their goal is to prevent compiler mismatches due to altered flags between library addons and the main R library
[12:30]  <spot> think of this like an app polling pkg-config for flag information
[12:31]  <spot> this means that on x86_64, we get the x86_64 flags
[12:31]  <spot> it could be overridden, but R upstream would likely blow a fuse. :)
[12:31]  <scop> perl, python, ruby don't...
[12:32]  <scop> s/don't/upstreams don't/
[12:32]  <spot> but we're not building for these other "subarch" targets currently, are we?
[12:32]  <scop> _we_ are not, but users may want to
[12:32]  * rdieter is ok with R's use of Makeconf
[12:33]  <spot> scop: i'm not sure how well it would work, to optimize an R sublibrary at a different level than R
[12:33]  <spot> if the user really wanted to do that, they'd rebuild R for i686
[12:33]  <spot> then, the addon library modules
[12:33]  <tibbs> I don't think it's productive to refuse to supply guidelines for R simply because there's disagreement about the way R upstream handles builds.
[12:33]  <spot> and it would work.
[12:33]  <scop> use of Makeconf as is effectively means R packages will ignore $RPM_OPT_FLAGS, which is directly against our guidelines
[12:33]  <f13> I'm here
[12:34]  <f13> the eagle has landed
[12:34]  <tibbs> Erm, only if R wasn't built with RPM_OPT_FLAGS
[12:34]  <tibbs> Otherwise Perl has the same problem.
[12:34]  <scop> no, regardless
[12:34]  <rdieter> I'd assume %{optflags} would be included in Makeconf.
[12:35]  <rdieter> yes, no?
[12:35]  <scop> rdieter, probably yes, %{optflags} of R, not the R add-on being build
[12:35]  <tibbs> If they differ, that would again be a violation of our guidelines.
[12:35]  <scop> uh?
[12:36]  <tibbs> It would mean that R wasn't built properly.
[12:36]  <tibbs> In violation of our guidelines.
[12:36]  <rdieter> spot commented this is upstreams intent for all of R to use the same flags.  as long as it includes optflags, I'm ok with that.
[12:36]  <scop> they differ if the user rebuilding the R add-on chooses to make them differ
[12:36]  <rdieter> bending things to tweak flags for individual add-ons is -EWASTEOFTIME.
[12:37]  * f13 looks at topic, is this the KDE meeting or the packaging one?
[12:37]  <scop> I disagree
[12:37]  <rdieter> hee, forgot to change topic.
[12:37]  *** rdieter sets the channel topic to "http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel -- Fedora Packaging Committee meeting".
[12:38]  <spot> well, we have +6 for the draft
[12:38]  <scop> my -1 for the record unless it's changed to honor $RPM_OPT_FLAGS
[12:38]  <spot> ok, i'll research that as a possible future change
[12:38]  <spot> and note the -1.
[12:38]  <scop> but if it passes anyway, please document the reason for ignoring them
[12:39]  <spot> scop: sure, that seems reasonable.
[12:39]  <spot> next item:
[12:40]  <spot> http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups
[12:40]  <spot> this update doesn't let %pre fail
[12:41]  <scop> changes since last week: http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups?action=diff&rev2=19&rev1=18
[12:41]  <tibbs> That's much slimmed down from before.
[12:41]  <spot> the only item i think i'm concerned about is groupadd vs getent
[12:41]  <scop> spot, that's listed in the TODO section
[12:41]  <spot> i know
[12:42]  <spot> i think its safer to use getent
[12:42]  <scop> I don't feel competent to make the call between "id" and "getent passwd", and "groupadd -f" and "getent group"
[12:42]  <scop> (nor even to have an opinion)
[12:43]  <spot> I trust simo's judgement on that
[12:43]  <spot> he knows that code very well
[12:43]  <spot> and he thinks we should use:
[12:43]  <spot> getent passwd <user> >/dev/null
[12:43]  <spot> > getent group <group> >/dev/null
[12:43]  <spot> >
[12:43]  <spot> > if the user/group exist then 0 is returned if not then non zero (2 iirc)
[12:43]  <spot> > is returned
[12:44]  <spot> otherwise, I'm ok with the draft.
[12:44]  <rdieter> ditto what spot said. :)
[12:44]  <scop> does getent consult external databases as well if so configured in NSS?
[12:45]  <spot> scop: yes, getent is tied right into NSS
[12:45]  <scop> okay
[12:45]  <spot> The getent program gathers entries from the specified administrative
[12:45]  <spot>        database using the specified search keys.  Where database is one of
[12:45]  <spot>        aliases, ethers, group, hosts, netgroup, networks, passwd, protocols,
[12:45]  <spot>        rpc, services or shadow.
[12:46]  * scop was just worried that eg. "passwd" == "/etc/passwd"
[12:46]  <spot> nah. :)
[12:46]  <spot> simo pointed that out to me when i was grepping through /etc/passwd
[12:47]  <scop> ok, want me to make those changes and vote then, or already now?
[12:47]  <spot> i'd like to just see the changes before voting
[12:47]  <spot> if only because i know this is going to get a lot of attention
[12:48]  <scop> I have no problem with that, but it'll mean it'll be up to vote next week
[12:48]  <spot> thats fine.
[12:48]  <scop> I want to test and be sure I get it right
[12:48]  * spot nods
[12:48]  <scop> ok, will do that
[12:48]  <spot> ok, thats all i had on the agenda for this week. open to items from anyone else:
[12:49]  <f13> did we talk about the icon cache updating thing?
[12:49]  <rdieter> no
[12:49]  <spot> f13: since i don't know what you're referring to, no, we didn't.
[12:49]  <f13> the scriptlet-snippits stuff that says we shouldn't add a dep on the icon stuff, but we don't safely wrap the script to fail silently if the tool isn't there.
[12:49]  <spot> oh, thats an obvious fix that needs to be made.
[12:49]  <f13> http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=show&redirect=ScriptletSnippets#head-7103f6c38d1b5735e8477bdd569ad73ea2c49bda
[12:50]  <spot> someone want to volunteer to fix it?
[12:50]  <f13> rdieter: you replied to the message
[12:50]  <f13> with an example of how to fix it
[12:50]  <f13> rdieter: I volunteer you to just fix it.
[12:50]  <rdieter> what's preferred, wrap with [ -x /usr/bin/gtk-update-icon-cache ]  &&  or >& /dev/null the output?
[12:50]  <f13> fail silently I thikn
[12:50]  <f13> it's "quicker"
[12:50]  <rdieter> the latter is shorter. :)
[12:50]  <spot> yeah, fail silently.
[12:50]  <rdieter> ok, I'll do it.
[12:50]  <f13> of course, somebody will yell at us about this...
[12:50]  <f13> hrm.
[12:51]  <scop> --quiet can be dropped too if you redirect both stdout,stderr to /dev/null
[12:51]  <f13> maybe we should just ask the desktop folks their opinion.  Maybe we're interested in errors should the executable actually be there.
[12:51]  <rdieter> that means wrapping...
[12:51]  <spot> rdieter: want to talk to mclasen and folks about it?
[12:51]  <spot> see what they'd prefer?
[12:51]  <rdieter> sure, will do
[12:51]  <rdieter> fedora-desktop list?
[12:52]  <f13> ok, and the next item is the init scripts LSB stuff
[12:52]  <spot> seems like as good a place as any.
[12:52]  <f13> we've got folks filling mass bugs about this, but there doesn't seem to be clear definition of what we should do to be LSB compliant.  This I think falls into packaging unforch.
[12:52]  <spot> well, the guidelines already say "follow the LSB"
[12:52]  <spot> i would really prefer to see the bug filers present a draft here
[12:52]  <f13> I personally have no clue about this, and others have pointed out that the LSB is rather vague in places, so we probably need a "Fedora interpretation" of the LSB
[12:52]  <f13> spot: I would too, dearly.
[12:53]  <spot> as I'm not an expert on what makes an initscript LSB compliant
[12:53]  <scop> http://fedoraproject.org/wiki/FCNewInit/Initscripts
[12:53]  <spot> f13: can you email harald@redhat.com and see if he is willing to help draft that?
[12:53]  <scop> I added some answered and unanswered questions there
[12:53]  <f13> spot: sure.
[12:54]  <f13> scop: want to be kept in the loop?  I don't really grok this stuff currently
[12:54]  <f13> (I haven't put effort into it yet is all)
[12:54]  <scop> f13, sure, why not
[12:54]  <scop> I have more questions than answers though ;)
[12:54]  <f13> that's perfect!
[12:55]  <spot> ok, any other items?
[12:55]  <spot> (other than my need for lunch....)
[12:55]  <tibbs> Nothing from me.
[12:56]  <spot> ok. lunchtime for me.
[12:56]  <spot> thanks all.
Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:Minutes20070710&oldid=66557"