Packaging:Minutes20070710

Present

 * AxelThimm
 * DavidLutterkort
 * JasonTibbitts
 * JesseKeating
 * RalfCorsepius
 * RexDieter
 * TomCallaway
 * VilleSkyttä

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