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:
- R packaging guidelines
- http://fedoraproject.org/wiki/PackagingDrafts/R
- Accepted (6 - 1)
- Voting for: tibbs rdieter thimm spot lutter racor
- Voting against: scop
- Note that racor's vote was indicated as "preliminary"; he did not elaborate
Other Discussions
The following additional items were discussed; see the logs for full details.
- http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups
- Silencing errors from the icon cache update scriptlet
- Guidelines for LSB-compliant init scripts.
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.