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 2009-04-28

Present

  • Denis Leroy (delero)
  • Jason Tibbitts (tibbs)
  • Rex Dieter (rdieter)
  • Tom Callaway (spot)
  • Toshio Kuratomi (abadger1999)

Regrets

  • Dominik Mierzejewski (Rathann|work)
  • Hans de Goede (hansg)
  • Ralf Corsepius (racor)
  • Xavier Lamien (SmootherFrOgZ)

Votes

There were no completed votes this week.

Other Discussions

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

IRC Logs

* spot looks around for FPC folks 12:01
spot abadger1999, tibbs, rdieter, delero, SmootherFrOgZ: ping 12:03
tibbs HHowdy. 12:03
abadger1999 pong. I'm here. 12:03
* delero is here 12:03
rdieter yo 12:03
spot i don't think racor is coming due to time conflicts, but he did send his votes for todays items via email 12:05
spot we have quorum though, so lets go ahead and get started 12:06
spot first item: GConf scriptlets: https://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/GConf 12:07
abadger1999 So spstarr wrote the first section of this by looking at what SuSE does. 12:08
abadger1999 (just pinged him in #fedora-devel to see if he's available). 12:08
delero do we know how significant the speedup is ? 12:08
tibbs This is way complicated, though. I'd really want buyin from our Gnome maintainers. 12:08
abadger1999 spstarr had generated some numbers but I don't recall what they were. It was significant. 12:09
tibbs Actually it's kind of ludicrously complicated. 12:09
spot tibbs: agreed. i'd want buyoff from them before we even consider adding a pile of painful macros 12:09
abadger1999 I agree, so I wrote a much simplified alternative in the bottom section. 12:09
abadger1999 mclasen liked my alternative. 12:09
abadger1999 (I think that he liked anything that hid things behind macros) 12:10
rdieter mclassen helped spstarr with a revision or 2 of what has been proposed. I assume he's for it 12:10
tibbs Is mclasen the only person we want to see approval from? 12:10
abadger1999 Dunno. He's the one from the desktop team that comments on FPC proposals the most. 12:11
rdieter during/after meeting we (I) could drop a message to fedora-desktop list asking for further feedback 12:12
--> mclasen has joined this channel (n=mclasen@nat/redhat/x-f2ba5db99bc02eb5). 12:12
abadger1999 Since spstarr isn't here at the moment, can we defer this to the end and talk about it then? 12:12
spot well, since mclasen is here, i'd like his thoughts on the draft 12:12
abadger1999 Ah cool :-) 12:12
spot I have a few points: I think simplifying the scriptlets is a good thing, but i don't want to use macros to obfuscate other things 12:13
spot e.g. I do not like %{magic_requires_for_things}, i much prefer: Requires(pre): %{requires_for_scriptlets} 12:14
mclasen I think opencoding these scriptlets in hundreds of spec files is error-prone and repetitive 12:14
mclasen but I agree that the requires part is not necessary 12:14
spot mclasen: how do you feel about the revised macro proposal at the bottom of: https://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/GConf 12:15
tibbs I do wish we could keep these drafts a bit cleaner. I can't really understand from this draft what is being proposed by whom. 12:16
* abadger1999 be sure and login -- looks like the wiki's caching is interfering 12:17
tibbs The stuff after "Discussion" is a counterproposal, but it doesn't seem complete. 12:17
spot yeah, it is a bit of a mess. 12:17
abadger1999 yeah... so everything above Discussion is spstarr's work. Everything below Discussion is my work. 12:17
abadger1999 I mainly focused on whether we could get some macros that were less complex. 12:18
spot yeah, i think keeping the macros simple and to a minimum is key 12:18
tibbs So the spec template is the same in either case? 12:19
abadger1999 Before we write it up, it would need to have a ScriptletSnippets entry that explained it... the outline of that is in the comments of the rpm macro script. 12:19
tibbs Well, no. 12:19
abadger1999 That's changed too. 12:19
spot no, the spec template would be different, look at the comments in the second scriptlet header 12:19
abadger1999 if you read the comments of each rpm macro script you'll see. 12:19
abadger1999 Another thing I didn't like about the SuSE method is that the macros are different in different cases. 12:20
abadger1999 Sometimes you can use find_gconf_schemas as documented in the proposed update... but other times you need to use def_gconf_schemas and add_gconf_schemas instead. 12:20
spot abadger1999: have you tested your macros? 12:21
abadger1999 spot: Yes, and they don't quite work yet. 12:21
abadger1999 rdieter: Have you messed with rpm macro files? 12:21
spot okay, i'd like to do this then... 12:21
spot can we table this until next meeting, so that A) the macros can be tested 12:22
rdieter abadger1999: i've dabbled here and there. :) 12:22
spot B) the draft can be cleaned up in a separate proposal 12:22
rdieter abadger1999: mind sending me what you have? 12:22
tibbs Can we agree that we'd like to see something simpler than the SuSE macros? 12:22
spot yeah, i like the direction that abadger1999 is taking it much better than the SuSE style 12:22
abadger1999 rdieter: Yep, I'll tar up a small spec and the macro file. 12:23
abadger1999 spot: Cool. Sounds like a good plan. 12:23
spot okay, lets move on to the next item: https://fedoraproject.org/wiki/PackagingDrafts/Globus 12:24
delero another heavyweight 12:24
rdieter step 1: flog globus upstream for inducing such packaging pain (reminds me of sage) (I'm only slighly kidding) 12:25
delero is the globus packaging going to be the work of a single packager ? 12:25
abadger1999 So far it has been. 12:26
mattiasellert I'm here by the way... 12:26
abadger1999 These instructions seem to be comprehensive enough that someone else could work on it too, though. 12:26
tibbs Ralf's opinion was that this doesn't need specialized guidelines. 12:26
abadger1999 mattiasellert: Excellent. 12:26
spot i'm not really sure why there is so much hopping around handling the LICENSE file as a %doc 12:26
rdieter that's so Ralf 12:26
abadger1999 mattiasellert is the author of the proposal. 12:26
tibbs I don't necessarily agree but the comment does have merit. 12:26
rdieter tibbs: nod, it's more a howto than anything else 12:27
delero a lot of work went into this draft... 12:27
spot the spec examples have a creation of the %docdir, then copying the license into %docdir, then multiple lines in %files to cover the docdir as a %dir and the license as a file 12:27
spot when the same end result occurs for %doc LICENSE_FILE 12:27
mattiasellert No that would delete the rest of the documentation. 12:28
spot i don't think so... 12:28
spot especially since in your spec example, you're making the $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version} directory just before you copy the license into it (and after running make install) 12:29
abadger1999 Some packages have documentation and some do not. 12:29
mattiasellert exactly 12:30
abadger1999 and since it's a mkdir -p it won't fail if the dir already exists. 12:30
spot even if they do, listing %doc LICENSE in %files should be additive rather than removing the directory to replace it with the license file 12:30
delero right 12:30
spot thats how it works for the other... umm... all Fedora packages. :) 12:30
* abadger1999 recalls a discussion of that in fedora-devel where %doc removed the stuff installed in /usr/share/doc/PACKAGE-VERSION. 12:30
mattiasellert It does. 12:31
spot okay, well, i won't harp on that point, but we should get that fixed. 12:31
abadger1999 This isn't the one I recall but: http://markmail.org/message/ysg4gq3im57ufa5n 12:31
spot i tend to disagree with ralf, we have always permitted good type specific packaging guidelines 12:32
spot the only thing that i see missing is any discussion of formal namespacing 12:33
spot e.g. globus-$foo 12:33
spot mattiasellert: will all globus toolkit packages start with globus- ? or just the libraries? 12:34
tibbs I agree; I don't see how this is measurably different from, say, Ruby Gems or Perl modules in deserving their own guidelines. 12:34
tibbs The fact that things have to be so incredibly complicated only reinforces that. 12:34
spot indeed. also, having guidelines with good spec templates helps reviewers 12:35
mattiasellert The vast majority are called globus-, there are a few that have other namespaces, e.g. gaa- and gridshib-. Then there are a few oddballs. 12:36
tibbs I really wish we could do without some of the terrible !?fedora and !?rhel conditionals. 12:36
spot mattiasellert: okay, so it sounds like you don't need a global namespace like we do with perl or ruby, for example 12:36
tibbs When you see things like %if %{?fedora}%{!?fedora:0} >= 3 you have to wonder. 12:36
spot mattiasellert: any chance you can narrow those sorts of things to Fedora 6? 12:37
spot 6+, rather 12:37
tibbs Why not 9+? 12:37
spot well, we've permitted things for two revs off the last active release for items like Provides 12:38
spot which would be 7, rather than 9. 12:38
tibbs But this is all going to be new packages. 12:38
spot yeah, good point. 12:38
spot removing that (the rhel stuff can stay for epel) will simplify the spec quite a bit 12:38
spot mattiasellert: what do you think about that? 12:39
abadger1999 Shold be able to use %if 0%{?fedora} >= 9, yes? 12:39
spot abadger1999: yep. 12:39
spot aside from that macro issue, i'm inclined to +1 here. its obvious a lot of effort went into this draft. 12:40
abadger1999 things that aren't in/differ from the Guidelines: 12:41
abadger1999 "Obtaining source" -- upstream provides a tarball but it's huge and silly about what it provides 12:41
abadger1999 doc packages: separate subpackage regardless of size 12:41
abadger1999 the setup packages explanation 12:41
abadger1999 information about using gpt and what gpt files are. 12:42
abadger1999 So definitely some new stuff. 12:42
spot since the docs come in their own gpt file listing, i'm inclined to permit the subpackages by default, regardless of size 12:42
spot we generally permit the maintainers discretion on such matters 12:42
spot if it is absurd, it will get pointed out during review 12:43
rdieter good stuff by the looks of it, +1 here too 12:43
abadger1999 I think this is a good thing to have: +1 12:44
spot +1, with the old fedora macros removed 12:44
tibbs I'm looking to see if there's anything else that could be simplified. 12:46
spot okay. 12:46
tibbs The %install section in the first template is really scary. Is all of that actually needed for a typical library package? 12:46
delero +1 12:47
<-- mclasen has left this channel ("There must be some way out of here."). 12:47
spot tibbs: it seems to be, but it is also well commented 12:48
tibbs I mean, a simple pushd at the top could shorten a lot of those macros. 12:48
abadger1999 mattiasellert: Perhaps this one is specific to a specific package? # Remove unwanted documentation 12:50
* spot wonders if mattiasellert is still with us. :) 12:52
mattiasellert Not really - some versions of doxygen create a bunch of crap. 12:52
tibbs We should document which versions. 12:52
tibbs Otherwise we get cargo cult specfiles. 12:52
tibbs "The template said that I need this. I have no idea if it really does anything." 12:53
mattiasellert OK, I'll compile a list. 12:54
spot so, it seems like there are three things: A) the spec tool (and templates) needs to limit disttag macro use to rhel and fedora >= 9 12:55
spot B) the spec tool should use pushd/popd to simplify the %install section 12:55
spot (and templates) 12:55
spot C) documenting the versions of doxygen that need to be cleaned up after 12:55
spot anything i missed? 12:56
tibbs "B" only if it makes sense. It might not. Another possibility would be to stuff $RPM_BUILD_ROOT%{_datadir}/globus/packages/%{_name} in a macro. 12:56
spot tibbs: that would be another way to simplify it 12:57
spot mattiasellert: are you willing to make those changes? 12:57
mattiasellert Yes, I will look into adopting these suggestions. 12:58
spot okay, then lets table this for next meeting, pending those changes. 12:58
spot if they end up being done sooner, we can almost certainly do a vote over email 12:58
spot the next item: https://fedoraproject.org/wiki/Compiler_Flags_%28draft%29 12:59
tibbs Is there an "is 64-bit" macro predefined by RPM? 12:59
spot tibbs: there was talk of making one, but i don't think it happened 12:59
rdieter my usual test for 64bitness is %if "%{_lib}" == "lib64" 12:59
spot rdieter: that isn't true on ia64 12:59
tibbs Because the leading %ifarch is bound to give us problems. 12:59
rdieter lovely. 13:00
tibbs __isa_bits 13:00
spot ahh, you could use __isa_bits 13:00
spot but only on fedora, not epel 13:00
rdieter woo 13:00
spot as to the Compiler Flags draft... i think i agree with Ralf. (shocking, i know) 13:02
tibbs Yeah, the guidelines don't need to be a howto document. 13:02
tibbs What prompted this draft? 13:02
spot i think the 0 size debuginfo packages did 13:02
spot the advice in the draft isn't wrong, but it isn't right for all packages, and i'd be concerned that reviewers might start expecting to see CFLAGS= in packages where it isn't needed 13:04
abadger1999 yeah. the chain was 0 size debuginfo; How do I get %{optflags} into my build? Here's how. Why isn't that in the Guidelines? 13:04
tibbs Because that's not what Guidelines are for? 13:04
spot a separate document on "how to ensure you are using optflags in your build" would be valuable 13:05
abadger1999 Despite: "Most C, C++, and Fortran programs will pick up the correct compiler flags if you use a macro that automatically sets them to build the package, such as %configure or %cmake" ? 13:05
spot but i'm not convinced it belongs in the guideline 13:05
tibbs The guidelines say that the compiler flags must be correct. It doesn't tell you how to read makefiles and edit them if necessary 13:05
tibbs abadger1999: So I guess that's a proposal for stripping that sentence from the guidelines, which I would agree with. 13:06
rdieter can the guidelines link-to or refer to this proposal (or something like it) for further details? 13:06
tibbs The problem is that we're sort of schizophrenic on the issue, because we include specfile templates and such. 13:06
spot rdieter: absolutely 13:06
spot i would much rather let this live in Packagers/ 13:07
spot and link to it from the Guidelines 13:07
rdieter better 13:07
spot so, i will formally -1 on those grounds 13:07
tibbs Agreed. 13:08
spot okay, thats all the items on today's agenda 13:08
spot any other items? 13:08
spot i am 7 minutes late for the board meeting 13:08
abadger1999 Not that I can think of. 13:09
tibbs Meeting time again. Hans has complained on-list that the time won't work for him, but he hasn't provided a list of times that work for him. 13:09
spot so i am closing this out. 13:09
tibbs The same for Ralf. I'm not sure what to do. 13:09
spot ah yes, everyone be sure to send in your times 13:09
abadger1999 rdieter, delero: Can you guys be sure to send in the times that work for you? 13:09
delero will do 13:09
rdieter abadger1999: consider me 100% flexible, I can make pretty much any time 13:09
spot tibbs: i'll talk to Hans, as to Ralf.... well. i'm not sure how we can get it from him. 13:09
spot rdieter: except for the KDE SIG meeting time! 13:10
rdieter we can move, that too, if needed 13:10
spot fair enough. 13:10
spot okay, meeting done! 13:12
spot thanks everyone 13:12
abadger1999 thanks for running it 13:12