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-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"