Meeting:Packaging IRC log 20061219

Fedora Packaging Meeting of 2006-12-19; times are in US/Central

[11:02] ok, anyone want to bring up anything for discussion? [11:03] before i start randomly throwing darts at the minefield [11:04] http://fedoraproject.org/wiki/PackagingDrafts/ProvidesObsoletes should be ready for discussion [11:04] Hopefully, discussion can be minimal, and we can try to vote/pass more items today. [11:04] i'd like to vote on iconcache, if possible. [11:05] ok, lets tackle ProvidesObsoletes [11:05] the draft seems like common sense to me [11:05]  * rdieter agrees [11:05] short, to the point [11:06] ok, lets vote on it [11:06]  +1 [11:06] ack, i am missing a note on epochs [11:06] +1 [11:06]  +1 [11:06]  +1 [11:06]  +1 [11:06]  racor: good catch, epoch should be in the envr [11:06] yeah, looks good .. if the Provides is meant to be removed, it might be good to indicate that in a comment right next to it, like '# Will be removed in FEn' [11:06] epoch and comment noted, will add [11:07] other than that: +1 [11:07] ok, approved with minor revisions [11:07] What implication does dropping old Provides: have on upgrades over several versions? [11:07] breakage [11:07] * f13 is back [11:07] do we lose anything by keeping the provides around indefinitely? [11:08] Is it important to consider that people might jump from FC5 to FC7, given that we have 13 months of support now? [11:08] I think at least two-version upgrades will be common. [11:08] yes. [11:08] more stuff to churn through for yum .. though I doubt this case willcause a lot of extra data [11:08] We should have a policy of how long to keep compatibility provides [11:08] if we're providing, perhaps with a timeout [11:08] Obviously we do want to get rid of crap at some point. [11:08] becuase while today we may provide what Foo does, but tomorrow we may not [11:08] and make it at least the support life of the next release [11:08] so Provides are not guarenteed to last forever. [11:08] Old provides can even get in the way; that came up recently. [11:09] it'd be nice if there was a real way of marking something as deprecated in packages [11:09] Remove compatibility releases two releases from introduction? [11:09] care could be taken when removing a provide to make sure nothing depends on it [11:09]  So we really do  need to put a time limit on them; I just think one release is too short. [11:09] or fixing what does depend on it. [11:09] so, drop in FC-current+1? FC-current+2? [11:09] repoquery anybody? (: [11:10] fixing is encouraged in the draft [11:10]  repoquery would be great if it could work on arbitrary repodata instead of what yum would use on the machine you're running it on. [11:10]  i dont think upgrades across three major revs are a good idea, +2 is probably the limit [11:10]  agreed. [11:10]  tibbs: we could fix that. [11:10]  why not just say FC-current+2 ? [11:10]  I would try if I knew enough Puthon. [11:10]  spot: I would draw the line at the EOL of the next release [11:10]  spot: +1. [11:10]  spot++ [11:10]  tibbs: gotta start somewhere (: [11:11] spot +1 [11:11] I can't even spell Python. [11:11] +1 [11:11]  ok, FC-current +2. [11:12] ok [11:12]  alright, next up: iconcache [11:12] http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache is the latest draft (i think) [11:12] yep [11:12] Last modified 12-14. [11:12] tibbs, btw, repoquery's -C and --repoid options may be what you're looking for [11:12] need for discussion? [11:12] if not: +1 [11:13] it looks good to me. [11:13] +1 [11:13]  * f13 gives it a quick look [11:14] someone should file a bug against hicolor-icon-theme to Require: xdg-utils [11:14] I will. [11:14] for F7, of course. [11:14] ok [11:14]  the "If none of the package's existing dependencies..." doesn't seem sound to me [11:14] I guess we can assume that there won't be any more split. [11:14] simple == good in my book. :) [11:14] such deps can go on and off at random [11:15]  racor: I can drop that part (for now, at least). [11:15]  +1 to iconcache.  Looks much simplier [11:15]  Yes, and there's a difference between a plain dependency and Requires(post). [11:15]  more simple that is. [11:15]  the current draft will not apply to Core < 7 packages? [11:15]  or? [11:16]  there's no way that it can. [11:16]  does it work on core < 7 packages? [11:16]  scop: no. [11:16]  oh crud [11:16]  why not? [11:16]  Unless you want core to require something in extras. [11:16]  * f13 hoped we wouldn't get into version specific guidelines. [11:16]  xdg-utils isn't in core. [11:16]  +1 for iconcache [11:16]  dependencies on xdg-utils aren't possible in Core < 7 [11:16]  tibbs: well, we aren't adding any new core packages at this point so.... [11:16]  why not "this rule applies to all new packages" [11:16]  I figured it would be ok, since Core packages (<7) are pretty much done (modulo errata's anyway) [11:16] scop: why? [11:16] There could be ne FC6 packages [11:17] s/ne/new/ [11:17] f13: makes sense, "new packages" (: [11:17]  racor, AFAIU, Core can't include dependencies from Extras, Core does not add new packages [11:17]  thimm: there could be new FE6.  Very highly unlikely to be new FC6, adn they could get a waive [11:17]  Ah, ok! [11:17]  scop: very rarely does core add new packages, but it does happen. [11:17]  scop: Core's problem, FE packages can requires them [11:17]  It's simpler for us to just not worry about it. [11:17]  indeed [11:18]  just apply to new packages and be done with it. [11:18]  f13: +1 [11:18]  racor, exactly, that's why I mentioned _Core_ < 7 packages [11:18]  +1 iconcache (duh) [11:18]  xdg-utils is there for all supported FE releases so all of the important situations are handled already. [11:18]  i.e. let FE people use it, if they want. How to handle Core is RH's problem [11:19]  racor: and hopefully, not a problem much longer. :) [11:19] ok, iconcache passes [11:19]  No, it's our problem as well [11:19]  +1 iconcache, assuming the bit about "If none of the package's existing dependencies....' is dropped. [11:19]  I'll drop the "if none" bit, and add "for new packages". [11:19]  ok? [11:19]  +1 with those changes [11:20]  thimm: why? if xdg-utils are in FE and work, FE < 7 packages _can_ use [11:20]  it [11:20]  I wouldn't even worry about "for new packages"; I could update my existing packages. [11:20]  +1 iconcache [11:20]  racor: why about what? [11:20]  Perhaps just add a note that obviously it doesn't work for core packages before F7. [11:21]  tibbs: yeah, I think that's the easiest way to say it. [11:21]  tibbs++ [11:21]  * spot nods [11:21]  worksforme [11:21]  ok, thats two down. [11:21]  thimm: may-be a misunderstanding: I wanted to say "FE < 6" can use it, people should feel encouraged to switch, even with FE < 7 [11:21] any other easyvote items? [11:22] trifecta! [11:22] debuginfo is pretty easy, I think [11:22] * rdieter nods [11:22] Is there a draft? [11:23] Just Packaging/Debuginfo? [11:23] ok.so, the debuginfo item is basically "comment if you're disabling debuginfo to explain why?" [11:23] basically just a link to http://fedoraproject.org/wiki/Packaging/Debuginfo needed in guidelines [11:23] and a requirement to add a comment to specfile if debuginfo is intentionally disabled [11:24] +1 [11:24]  obviously preferred [11:24] +1 [11:24]  +1 [11:24]  +1 [11:24]  +1 [11:24]  +1 [11:24]  What about the TODO: item in there? [11:25] +1 [11:25]  i'll check one of my R packages [11:25] someone who knows R, Mono and/or Ruby will have to comment on the TODO item [11:25] scop: you can drop the reference to ruby packages, teh noarch issue has been fixed, and we build noarch packages for all supported releases [11:25] hurray [11:26] We should add the requirement to comment next to "%define  debug_package %{nil}" [11:26] Otherwise +1 [11:26] * spot has to step afk for a moment, electrician is here to rewire my lab... bbiaf [11:26] lutter, ok, cool, doing it now [11:26] abadger1999, yes, that's included in what's being proposed, see the item in GuidelinesTodo [11:26] it obviously passes :) [11:26]  * Rathann|work has to go, will read the log later [11:27]  +1, had to read it, first [11:27]  scop: Ah I see now. [11:28]  A bit of info about Java debuginfo packages might be in order; I'll see if I can remember the magic incantation to get it working properly and send something to the list. [11:28]  scop: BTW, I recently encountered a case where a debuginfo was generated from a noarch [11:28]  * f13 shudders at 'java' [11:28]  racor, whoo [11:29]  f13: Someone had to review those packages, after all. [11:29]  racor: I didn't think that was possible, but I guess anything is possible with RPM.  What was the package? [11:29]  Cross compilers, debuginfo bogusly being generated from foreign elf-binaries [11:29]  hm, interesting [11:29]  cross compilers packaged as noarch??? [11:30]  tibbs: no, the current java packages are not reviwed [11:30]  at least the core ones. [11:30] thimm: yes target libs, [11:30] f13: I reviewed many Java packages for extras. [11:30] why??? [11:30] Well, they're just data. [11:30] tibbs: are they jpackage crap? [11:30] f13: Sort of, but I beat them into shape. [11:30] tibbs: "why???" was for racor ;) [11:31]  thimm: target libs are just binary data, without any meaning to linux [11:31]  * spot is back [11:31]  Too many concurrent threads.  I'm not multi-core, I guess. [11:31]  comparable to "firmware" [11:31]  same reason wireless firmware are noarch [11:31]  makes sense. [11:31]  racor +1; it's just bits of data [11:31]  yeah, that makes sense [11:31]  racor, f13: make sense, thansk for clarifcying [11:32]  tibbs: but they can be elf => debuginfo [11:32]  racor: i think when we have a cross-compiler guideline document, we can tie the two together [11:32]  Maybe worth mentioning the Ville's debuginfo page? [11:32]  I guess you learn something new about RPM every day. [11:33]  The debuginfo from those packages isn't in any way useful, is it? [11:33]  Perhaps with a croos-gdb [11:33]  corss-gdb [11:33]  arghhhh [11:33]  cross-gdb ? [11:33]  * rdieter boggles at that [11:33]  (: [11:33] cross-gdb, sorry for being illiterate [11:33] thimm: happems to the best of us [11:34]  ;) [11:34]  In any case, that can probably be left to evolve for a bit. [11:34]  OK, are we done with that item? [11:34]  i think so [11:34]  tibbs: +1, yes it's a corner case, but I wouldn't be surprised if it hadn't already hit somewhere [11:35]  i'd like to very briefly touch on the jpackage naming item [11:35]  Was there movement there? [11:35]  currently, the jpackage naming scheme is in violation of the Fedora naming guidelines [11:35]  afaik, there is no movement to resolve this, despite rather significant effort [11:36]  Wouldn't they be caught in any mass-review? [11:36]  yes [11:36]  movement = convergment from the jpackage camp? [11:36]  i think so. [11:36]  There is a proposal on the board. [11:36]  but no real input from the java folks. [11:36]  i'm not sure anything is in our domain to do on this item anymore [11:36]  i'd like to retire this one, since there is no changes we're making at this time [11:37] I forced the issue on the extras packages I reviewed and the packages were changed. [11:37] yeah, the proposal means no changes to our guidelines, so its up to them to either use the proposal, or propose something better [11:37] agreed, the java folks will have to step up when mass review hits... (: [11:37] but at this point, I don't think we should accept any new jpackage packages with the naming scheme. [11:37]  f13: +1 [11:37]  !2 [11:37]  doh. [11:37]  +1 [11:37]  f13: +1 [11:37]  tibbs: please, only vote with non-imaginary numbers. ;) [11:37] f13: +1 [11:37] the problem wit hwaiting until mass review is that there will porbably be a time crunch etc. that makes people less inclined to actually resolve it [11:38]  lutter: if they want their package in fedora, they'll make the trivial change. [11:38] lutter: then the java folks need to get off their asses. [11:38] True. And we're not going to have a lot time to argue about this. [11:38] we saw how well that works last time it came up [11:38]  The proposed schedule is seriously tight. [11:38] lutter: So you think we should issue a warning? "Mass review coming up, all your packages are going to fail" [11:38] abadger1999: i think it might be prudent to do so [11:38]  yes [11:38] * rdieter snickers [11:39] something similar to the email i sent out prior to fc6 [11:39] I'm pinging our java folks right now... [11:39] I suppose someone could do a general sweep over all of the packages, looking for crap names. [11:39] We don't have to single out Java here. [11:39] tibbs: indeed [11:39] when i checked last time, i found lots of non-java badness in naming [11:39] yeah [11:39] That's a lot of work; did you use scripts? [11:39] yeah, that's a good idea [11:40] we're slowly making noise about hte merger internally, as things move from proposals to accepted plans. [11:40] nah, i did it by hand, unfortunately [11:40] speaking of naming, when chatting with the rpmforge folks, they had issues with mixed-case package names. Opinions? [11:40] I suspect a few regexps could help. [11:40] rdieter: what sort of issues? [11:40] they want it or don't want it? [11:40] they argued we should mandate lower-case names. [11:40] * scop would love all lowercase names, everywhere, period [11:41] rdieter: and, um, what exactly do we gain from that? [11:41] I personally prefer all lower-case, but upstream might have other ideas and we should try not to screw them over. [11:41] other than sane sorting. :) [11:41] spot: dunno, I didn't have much opinion. [11:41]  this is tricky, as trademarks are case sensitive [11:41]  rpmforge is already using lower-case, so we were hitting extras vs. rpmforge incompatibilities [11:42]  of course, it was all *our* fault. (: [11:42] rpmforge is not pure lower letters [11:42] spot: just wait for a trademark to include a space. [11:42] given the realities, we can't do more than say 'packae names _should_ be all-lower case' [11:42] i'm not seeing any reasons to actually mandate lowercase vs mixedcase [11:42] I think we'd have to consider those case by case. [11:42] foo\ bar-1.0-2.src.rpm [11:42] we have had an item/discussion somewhere that would mandate adding an all-lowercase Provides if %{name} is not [11:42] I wonder where that has gone [11:42] well, how about I raise the issue on the ml, and we move on. [11:42] scop: yes, i remember that [11:43] i think it may have even been my idea [11:43] that doesn't help to make yum any faster :/ [11:43] but rpmforge is not using lower letters ... [11:43] are we seeing issues were there are none? [11:43] How about we ask upstream what they prefer? [11:43] thimm: Yes [11:43] if they don't care, we go lowercase. if they care, we follow upstream. [11:43] * rdieter agrees with spot. [11:44] spot: confusion [11:44] racor: well, it makes mixedcase naming the corner case [11:44] What about all our perl-Some-There packages? [11:45] Spot: How do you spell your name? [11:45] thimm: thats a good point [11:45] ~spot [11:45] thimm: thankfully they all provide perl(Some::There) [11:45] thimm: and all things should be using that method. [11:45] I don't think perl-Foo-Bar should be an exception [11:45] I really don't think we need to go mandating too much here; won't reason preclude someone from importing "pAcKaGe"? [11:46] tibbs: one can only hope [11:46] we had GiNaC [11:46] we have DevIL [11:46] but these are the upstream names [11:46] reason -1, I guess. [11:46] scop: We have Xt, Xaw, etc. [11:46]  yeah, really, what are we buying by setting a mandate? [11:46] whats missing from our existing Naming Guidelines in this regard? [11:46] Some metrics: FC devel has 104 Mixed vs 1060 lower case [11:46] perhaps this is a place for a recommendation [11:46] f13: plain nothing, this is just debianish zealotry again [11:47] rather than a MUST [11:47] what about the all-lowercase Provides? [11:47] scop: well, we know it will slow down yum, what do we gain? [11:47] Provides are the real important bits! [11:47] One thing we should really try to avoid is two package names that differ only by case. [11:48] spot, got any figures exactly how much? [11:48] scop: i do not [11:48] Mixed case slows down yum? [11:48] it should be something that can be tested (i'm not volunteering for this, i'm buried in aurora) [11:48] thimm: extraneous Provides do [11:48]  thimm: no, adding additional Provides: lowercasename [11:48] More provides = more metadata. [11:48] Ah, ok! [11:48] spot, well, I can say that mixed case names have slowed *me* down quite a few times - needed a few iterations and sometimes yum search to get something right [11:49] perhaps this is a yum plugin? [11:49] ignorecase ? :) [11:49] Although now they're talking about shipping raw sqlite databases as metadata, so who knows what the future will hold. [11:50]  alright, next item [11:50]  tibbs:future, we are just adopting 1970's standards, to make yum/rpm run on 6bit machines [11:50]  Packages already reviewed for Core. Do they need to be re-reviewed for Extras? [11:50]  Yes. [11:50]  I think the answer is yes. [11:50]  I don't see why. [11:50]  Oh wait -- the reviewed packages? [11:51]  I think no. [11:51]  i think the wording here is bad, as it applies to the merge [11:51]  Who reviewed withing Core and according to what guildleines? [11:51]  I've reviewed core packages, according  to the guidelines in place at the time. [11:51]  i think packages which have not gone through a formal Fedora review (not grandfathered in Core by Red Hat) [11:51]  need to be reviewed as we merge [11:51]  so here was my thinking. [11:51] once we do the merger, _every_ package CVS gains an 'unreviewed' file. [11:52] the only way you can remove htis file is by referencing the review bug ID [11:52]  There is an opportunity for a grand cleanup here, but I just don't think we have the time to do it all. [11:52] there are many things in Extras that are unreviwed right now too [11:52] f13: right, grandfatherd from fedora.us. [11:52] we'll have to have some hounds watching CVS commits to make sure nobody is just removing the file without referencing a review ticket. [11:52] rdieter: also moved w/out review from Core [11:52] f13: how about a review file instead, containing either "unreviewed" or the bugzilla number [11:52] many folks disliked "flag" files in CVS in the last FE mass rebuild [11:53] that way, we can script query to list the unreviewed items [11:53] spot: that could work. [11:53] spot +1 [11:53] scop: for what reason? [11:53] lots of files, lots of commits, did not notice, whatever [11:53] spot: this is in lieu of a package DB where the review bug could just be an entry in the packages db entry [11:53] f13: absolutely [11:53] the mythical package DB [11:53]  f13, spot: +1 [11:53] * spot also wants a flying pony [11:53] why not a blocker bug or keyword in current bugzilla? [11:53] s/blocker/tracker/ [11:54] c4chris proposed a reviewURL field for the packageDB that I added. [11:54] spot: +1 (+1 to flying pony too) [11:54] We can use the contents of the review file in cvs to fill that with data. [11:54] scop: ever tried to make changes to a bug that was on a blocker bug that blocked 3K other bugs? [11:54] bugzilla is so much more difficult for this kind of thing than a file in CVS. [11:54] f13, doh [11:54] brings bz to its knees pretty easily [11:55] ok [11:55]  ok, 5 minutes left, i'd like to ask a simple question [11:55] and keyword? [11:55] since we have such good attendance [11:55] Whatever method we use for tracking unreviewed packages, we need to think of a backup plan in case F7 is there and several important packages are not yet through with the review. [11:55] thimm++, not sure if it's our area though [11:55] thimm: we'll just have to make sure that doesn't happen. (: [11:56] spot: ? [11:56]  thimm: barcamp hack session to chew through missing reviews [11:56]  Here is my simple question: Do we want the License field to be detailed or simple? [11:56]  I think this affects the policy we would make [11:56]  Simple. [11:56]  Ah, I was going to ask that. [11:56]  simple [11:56]  Simple [11:56]  Spooge proposed something like: [11:56]  simple [11:56]  simple [11:56]  simple or non-existant. [11:56]  BSD, Original, See /usr/share/licenses/BSD.Original [11:56]  simple [11:56]  Much simpler than what smooge proposed :-) [11:56] I think that's just too much stuff. [11:56] tibbs: i agree wholeheartedly [11:56] License tag could be the location of the license file in teh package payload... [11:57] oh n/m [11:57] What about GPL versus GPLv1, GPLv2 ? [11:57] i think simple is the pretty clear winner there [11:57] tibbs: i think there is merit in some distinction [11:57] Do we have any GPL1 packages at all? [11:57] tibbs: that's simple enough, IMO. [11:58] tibbs: those are actually different licenses, so yeah... :/ [11:58] where it is relevant [11:58] thimm: they will come [11:58] f13, there's a %license macro apparently sometime meant for use in %files, but nobody knows how it works (and it probably doesn't nowadays) [11:58] for example, GPLv3 [11:58] Frankly I've never read the GPLv1; for all I know it could be a typo fix. [11:59] scop: Well, the RPM news afoot may mean that it could be made useful. [11:59] The question is, should it? [11:59] so, part of this will come up in the course of the next round of license auditing [11:59] i'm going to try to accurately document the actual licenses of things [11:59] Distributable is a terrible lie [11:59] Indeed. [11:59] (for 99% of the packages carrying it) [12:00] ok. thats our time for the day. thanks everyone for coming out [12:00] What about "PHP License" versus just "PHP"? [12:00] i hope you all have a great holiday season [12:00] topic owners please send notes to maintainers-list about the things that passed. [12:00] Before we all leave, FESCo asked us to consider a guideline to not use file deps outside of /etc and the bin dirs [12:00] It's holiday? ;) [12:00] Ah, it's noon.  I'll continue on-list. [12:01]  abadger1999: does '/usr/lib' and '/lib' count as 'bin dirs' ? [12:01]  abadger1999: draft it, send it to the list for vote? :) [12:01] abadger1999: THL likes to propose things for us to do. [12:01] next meeting in 2007? [12:01] I'll bring it up on the list unless people are vehemently opposed now :-) [12:01]  or remind thl that we take drafts from anywhere [12:01]  scop: yes, next meeting is... (looks) [12:01]  (sorry, I was supposed to bring that up) [12:01]  either Jan 2 or Jan 9 [12:01]  f13: I'll have to check.  It's to help yum. [12:01]  you guys going to be sobered up by Jan 2? :) [12:01] abadger1999: yes, but there are good reasons to file dep on lib files. [12:02] I have no objections. [12:02] or there was. [12:02] why sober in these meetings? ;) [12:02] *** thimm sets the channel topic to "Channel for Fedora packaging related discussion | Next Meeting: Tuesday, January 2nd, 2007 17:00 UTC". [12:02]  f13: /usr/lib and /lib counts. [12:02]  k.  I'll draft something and send to the list. [12:02]  /lib64/libc.so comes to mind [12:02]  spot: Don't know yet, Jan 6 also is a holyday, here and I don't know if I'll be back Jan 2 [12:02]  Better stick with Jan 9. (: [12:03] We'll be short on time for F7 [12:03]  we'll try for the 2nd, and fall back on the 9th if needed [12:03] ok, I'll (most) likely be here. [12:03] is anyone going to do the logs minutes? [12:03] f13: Yes, lib dirs should be included as well. [12:03] (volunteers?) [12:03] I have them and will put them up. [12:03] tibbs: awesome, thanks.