Packaging:Minutes20080422

Present

 * DenisLeroy
 * DominikMierzejewski
 * HansdeGoede
 * JasonTibbitts
 * RexDieter
 * TomCallaway
 * ToshioKuratomi
 * XavierLamien

Writeups
The following drafts have been accepted by FESCO and are to be written into the guidelines:

http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv
 * No packages may own files or dirs in /srv:

http://fedoraproject.org/wiki/PackagingDrafts/ConditionalGCJ
 * Build GCJ AOT bits conditionally

Votes
The following proposals were considered:


 * Sugar Activity guidelines
 * http://fedoraproject.org/wiki/DennisGilmore/SugarActivityGuidelines
 * This was discussed last week but tabled. It returns for a vote.
 * Accepted (7 - 0)
 * Voting for: tibbs spot rdieter hansg SmootherFrOgZ delero agadger1999

held to grant it an exception which passed with the following voting for: Rathann spot tibbs hansg rdieter
 * Static Library packaging tweaks
 * http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy
 * A new draft this week which modifies the existing guidelines
 * Accepted (7 - 0)
 * Voting for: spot delero hansg SmootherFrOgZ Rathann tibbs rdieter
 * Note that one particularly odd case (allegro) was discussed and a vote was

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

a usable set of guidelines.
 * Javascript packaging guidelines
 * http://fedoraproject.org/wiki/PackagingDrafts/Javascript
 * If you have experience with javascript, please assist us in coming up with

happen on-list.
 * Discussions about possibly moving the meeting time to account for DST will

IRC Logs
[12:02] * spot pings racor, hansg, abadger1999, delero, SmootherFrOgZ, tibbs [12:02] "SmootherFrOgZ"? [12:02] hi [12:02]  --> Rathann has joined this channel (n=rathann@onizuka.greysector.net). [12:03] * hansg is present [12:03] and there's Rathann. :) [12:03]  present [12:03]   (semi-) [12:03]  * Rathann is fiddling with audio cables [12:03]   tibbs, yep ? [12:04]  tibbs: so, spot is ok, but you draw the line at "SmootherFr0gZ" ? :) [12:04] I simply have no idea who this person is. [12:04] * abadger1999 is late but here now. [12:05] tibbs: he's one of our two new members, specifically, Xavier Lamien [12:05] Whatever happened to Panu? [12:05] delero is our other new member, aka, Denis Leroy [12:05] tibbs: thats how the vote came out. [12:05] * delero raises his hand [12:05] Hmm, disappointing. [12:07] anyways. :) [12:07] i don't see racor or abadger1999 awake, but everyone else is alive [12:08]  I'm here, I'm here! [12:08]  ok, so thats 8 of 9 [12:08]  * abadger1999 jumps up and down [12:08]  lets get to the first item of business [12:08]  abadger1999: is Javascript ready? [12:08]  * hansg wonders why someone is jumping up and down, adhd? [12:09]  spot: It can be discussed. [12:09]  ok. first item is: http://fedoraproject.org/wiki/PackagingDrafts/Javascript [12:09]  I'm satisfied with it but I'm also happy to kick the completed draft out to the list one more time. [12:10]  The issues surrounding this are weird enough that I'd really like to see some input from upstream developers of some of the packages which would fall under this guideline. [12:10]  Okay.  What questions would you like to see specifically asked and answered? [12:10]  I know I'll get pushback from upstream. [12:11]  Specifically, the mootools stuff is just nuts, and the compression issue. [12:11] It'll be a matter of whether concerns like security trump what upstreams perceive as easiest. [12:11] Okay. So talking to mootools and a few of the mootools consumers. [12:12] Well, here's the problem. I have to package mootools in some form in order to update zoneminder. [12:12] And this guideline doesn't actually help me do that. [12:12]  [12:12]  Very true, that. [12:12] I mean, I could package the exact mootools bits that zoneminder needs, but then that should go in zoneminder and thus would be forbidden by this guideline. [12:13] So for the only real-world example that I have interest in, it's counterproductive. [12:13] perhaps working through mootools might provide a good basis for fleshing out this guideline? [12:13] I don't believe there's any work to do something like this anywhere else. [12:13] We could package all ~8192 versions of mootools separately. [12:13] is the mootools issue really javascript-specific, or is mootools a special case ? [12:14] Oops, there are three or four compressors you can apply, so that's too small. [12:14] Well, mootools is a javascript library. [12:14] Can we package the complete mootools package as separate files by working with their source? [12:14] mootools sound like a pathelogical special-case to me. [12:14] abadger1999: I don't believe so. [12:14] Or..hmm... No I see the problem with that. URLs in the zoneminder package... [12:14] rdieter: Yes, but "A package MUST not include javascript libraries that have a separate upstream." [12:14]  IMHO you should make clear that this is only for JavaScript stuff which is part of a web app. There's going to be plenty of JavaScript stuff in future versions of KDE 4 which has nothing to do with Apache and thus "MUST: A javascript library package must provide an apache config file that lets the library be served by apache. This file is placed in %{_sysconfdir}/js/ with a filename extension of *.conf" makes no sen [12:14]  se without defining "javascript library". [12:15] tibbs: guidelines remember, can have exceptions [12:15] Kevin_Kofler: Javascript library with separate upstream. [12:15] Kevin_Kofler: That's a good point. Will there be javascript libraries in KDE4? [12:16] There are some in KDE3 already, aren't there? [12:16] ie: libraris of javascript code... but intended for building non-web applications? [12:16] with seperate usptream + "and managable release mechanism" ? [12:16] delero: thats really vague. [12:16] delero: We've never let "managable release mechanism" stop us before. [12:16] spot: i agree [12:16]  There are bindings for C++ stuff to use with JavaScript (and there will be one for libplasma), not sure about actual JS libraries. [12:17] upstreams without a managable release mechanism deserve cluestick treatment, regardless. [12:17] i think perhaps mootools might need to be a special case, given the large number of variants [12:17] For web-intended javascript outside of mootools, I think this guideline serves us well although the compression but gets tricky with the "must rebuild from source" bit. [12:17] tibbs: perhaps we could use all of their compression methods? [12:17] "compression bit gets tricky". [12:17] Kevin_Kofler: Okay. I'd say that qualifies... So the "separate (sub)package" part would still apply. But the config file should be make clear that it doesn't apply [12:18] Well, do we have the actual compressors as installable packages in Fedora? [12:18] tibbs: i dunno. worth checking at least. [12:18] I.e. is it intended that we not take the pre-compressed source from upstream? [12:18] tibbsWe are missing at leat jsmin. [12:18] So I think we aren't able to compress at this time. [12:19] tibbs: Yes. That is intended. [12:20] The minified stuff is technically javascript still, but it's extremely hard to read. The actual compressed stuff has to be uncompressed in order to read. [12:20] There's GPL interaction with that stuff, too, with the "usual form for making modifications" clause. [12:21] I don't even want to think about how putting compressed GPL javascript code on your web site involves "distribution". [12:22]  [12:22]  I think it's pretty obvious that we should always have the uncompressed version available. [12:23] As in, in the binary rpm? Or just in the source rpm? [12:23] In the web-accessible location. [12:23] i suspect (from what i'm hearing here, not from personal opinion) that many javascript libraries will be incredibly painful to package [12:23] Well, actually most of them are trivial. [12:23] It's just that the issues are complicated. [12:23] All you have to do is stick them in a location and drop in an apache redirect. [12:24] Also, I recall recent grumbling about how that stuff doesn't work at all with another web server. [12:25] spot: Yes. Although ivazquez's MochiKit is both simple and good. [12:25] So: proposed action plan: [12:25] Err.. tibbs's explanation is better :-) [12:25] Investigate what javascript compressors we have in Fedora. [12:25]  Look at a couple of non-mootools javascript libraries.  (I have another one needed for zoneminder.) [12:26]  seems like a good plan to me. [12:26]  spot: Are the GPL-related issues worth looking into? [12:26]  i'll leave this on the agenda, and we'll revisit it next time [12:26]  tibbs: only if we have a specific case [12:26]  because i will have to take it to the lawyers for interpretation [12:27]  tibbs: Sounds good.  Do we want to bring any of this up with any upstreams?  Or just look at it from the "How easy is it to package" side? [12:27]  I think it would be better to have something more fleshed out first. [12:27]  Okay. [12:27]  Alright. Next item: http://fedoraproject.org/wiki/DennisGilmore/SugarActivityGuidelines [12:28]  This has changes for multilib and directory naming [12:29] Is this the correct diff from last time: [12:29] http://fedoraproject.org/wiki/DennisGilmore/SugarActivityGuidelines?action=diff&rev2=8&rev1=4 [12:29] ? [12:29]  yes [12:30] This seems pretty straightforward to me [12:31]  (and not just because i helped Dennis clean it up) [12:31] This looks much better to me, although it's hard to evaluate the "Architecture-specific Activities" bit without actually seeing an example. [12:31] tibbs: SimCity is an example [12:31] I'm hoping "as appropriate" is pretty obvious. [12:31] they have python code that launches it as a sugar activity [12:31] there is a /usr/bin/SimCity [12:32] as appopriate in the context of the other Packaging Guidelines [12:32] Ah, OK. [12:32] the new draft looks like a winner to me. [12:32] +1 [12:32]  +1 [12:32]  ok guys, lets vote on it. [12:33] +1 [12:33]  +1 [12:33]   +1 [12:33] +1 [12:33]  +1 [12:33]  Rathann, racor: feel free to vote if you would like it to be on the record. [12:33] but with a +7, it passes [12:33] for the new guys, anything +5 passes [12:34] and -1 does not substract, so there is no _Real_ difference between 0 and -1 [12:34] ok, next item: http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy [12:34] but where possible we try to achieve no -1's [12:34]  Ah yes [12:34] i reworked this somewhat this morning, there is no longer the concept of "static-noshared" [12:35] after thinking about that, it doesn't make any sense. [12:35] I've got a very interesting package with regard to this, to so called exception to the rule I guess [12:35] I'm happy to pass this if allegro gets excepted [12:35] hansg: what's allegro's situation? [12:36] * rdieter likes the amended static policy better. [12:36] (one of those apostrophes was unnecessary) [12:36] I was just going to ask if anyone wanted to know the long story, but spot beat me to it [12:37]  Okay, so here it goes, allegro is a shared libary, with some asm code used on various platforms [12:37] this asm code however is not PIC, which is a no go on anything but i386 and frowned up on i386 [12:37] upstream has fixed this in an interesting way [12:38] the non PIC asm code is in a static lib called liballeg_unsharable.a [12:38]   so... what's the difference between current guideline and the new draft? [12:38] * Rathann can't find any [12:38] Rathann: almost nothing. its just a clarification, really. [12:38] and all the applications which link to allegro use the following (allegro-config --libs) [12:38] -Wl,--export-dynamic -lalleg-4.2.2 -lalleg_unsharable [12:39]  Surely the right solution there is to fix the ASM? [12:39]  surely :) [12:39]   Many libs manage to make PIC ASM. [12:39]  So the non pic code gets put in the binary not in the .so and then exported to the shared lib [12:39]  hansg: so, the scenario is that the shared library is useless without the static? [12:39]  yes [12:39]   making it pic compatible might make it slower though [12:39]  spot yes that is [12:39]  wow, thats a hell of a corner case. [12:39]  Kevin_Kofler, I'm happy to take paches for this and send them upstream [12:40]  could you put it in -static, and then have base depend on -static ? [12:40]  yes, which I don't think we need to cover in the guidelines, as there will always be exceptions, lets just grant an exception to allegro, keep both the .a and .so  symlink in -devel and be done with it [12:41]  spot, not usefull, as the .a isn't needed to run the applications, as its already linked into the applications [12:41] eh, ok. [12:41] i'm alright with that being a permitted exception [12:41] given how unusual it is. [12:41] So... wouldn't we still want to know that a static library is being linked here? [12:42] * rdieter was wondering that too [12:42] thats a valid point. [12:42] I did think the whole point of the guideline was to make it easy to find what linked against a static lib. [12:42] if the static lib is part of the devel package also ? [12:42] yes but thats easy if a security bug is ever found in allegro's static code we can just query for anything depending on the .so as that will have the static code linked in [12:42]  as the .so is useless (unresolved symbols) otherwise [12:43] hansg: ok, since it's exceptional already. :) [12:43] ok, lets vote on the draft as is: [12:43]  +1 [12:43]  +1 [12:43]  +1 [12:44]   +1 [12:44]   +1 [12:44]  Let me be clear: [12:44]  What's gone here is the weird contradictory exception about being able to BR *-devel if there are only static libaries present? [12:44]  tibbs: yes. [12:44]  +1 [12:45]  +1 [12:45]  and anything static linking needs: BR: *-static ? [12:46]  * abadger1999 would also like to know what rdieter asked [12:46]  reading, looks like the answer is yes. [12:46]  yes. [12:47]  What we lose is the "auto-switch" if a package suddenly starts providing dynamic libs. [12:47]  yes, but we gain in tracking [12:47]  So to use allegro as an example, apps linking against allegro will BuildRequire: allegro-static [12:47]  which is infinitely more important [12:47]  That's such a corner case that it's worth the guideline clarity to get rid of it. [12:47] But we're making an exception so the static library can go in -devel? [12:48] Erm, lets not use allegro as an example please [12:48] allegro is a bad example [12:48] Well, the exception is being written in. [12:48] abadger1999: not into the guidelines it isn't. [12:48]  err.... That's how we've done evey other guiedeline exception. [12:49] well, we could write it in. [12:49] spec file naming with gcc, for instance. [12:49] if i was going to do it, this is what I would say: [12:50] "If (and only if) a packages shared libraries require static libraries to be functional, the static libraries can be included in the -devel subpackage. The devel subpackage must provide -static, and packages dependent on it must BR -static. [12:50]  Sounds good. [12:50]  +1 [12:51]  Can't we just document the exception in the meeting Minutes, if we are going to put every exception ever granted into the guidelines things will become messy [12:51]  lets get a round of votes on the "allegro" exception? [12:51]  hansg: The idea is not to have exceptions. [12:51]   sounds OK [12:51]   +1 [12:51]  +1 from me [12:52]  I have no problems with excepting allegro.  +1 [12:52]  I don't like it, why should the packages BR the -static, what if the code ever gets pic-ified (I'm counting on a patch from Kevin for this soon) [12:52]  When we do have exceptions, the reasons are listed so that we have a basis to adjust the guidelines when things become unwieldy. [12:52] hansg: then they fix their BR. [12:52] hansg: think of this from rel-eng's perspective [12:52] This would mean changing the BR's of 29 packages now and changing them back if this ever changes [12:53] hansg: That's what tibbs and spot were mentioning earlier: [12:53] (10:47:23 AM) tibbs: What we lose is the "auto-switch" if a package suddenly starts providing dynamic libs. [12:53] (10:47:34 AM) spot: yes, but we gain in tracking [12:53] Thats a lot of needless churn [12:53] they'd like to know every package which uses static libs [12:53] <Kevin_Kofler> Speaking of the GCC specfile naming exception, why does GCC have a gcc43.spec now when the guidelines clearly stated that the next version should move to just gcc.spec? [12:53] * hansg is starting to with I've just kept quiet about this [12:53] <Kevin_Kofler> I made that point in the merge review and got entirely ignored. [12:53] "a lot"? [12:53] s/with/wish/ [12:53] This happens, what, once every couple of years? [12:53] Kevin_Kofler: i'll poke jakub. [12:54] What guideline changes, no they seem to happen all the time [12:54] No, a package suddenly providing dynamic libraries when it only provided static ones before. [12:54] tibbs that not the case here [12:55] hansg: i do think it is important that we track static library use, even in this weird hybrid case. [12:55] hansg: you can BR both if you'd like [12:55] Yes and I think its important we support every piece of hardware out there, but there is only so little time and so much todo [12:56] I'm fine with this if someone else will fix all the allegro packages [12:56] hansg: i will do it then. :) [12:56] ok +! [12:56]  make that +1 even [12:56]  alright, i think we have enough +1s for this to be passed [12:57]  i'll add the exception before FESCo looks at it [12:57]  that is all i had for the agenda today [12:57]  the floor is open for other issues [12:57]  +1 here too [12:58]  if you have no additional issues for today, please say "no". [12:58]  so i can close this up and go eat lunch. :) [12:58] no [12:58]  I can't recall if we have new guidelines this week. [12:58] no [12:58]  * Rathann has nothing [12:58] or rather yes, meeting time? [12:58] no [12:58]  since spot's remark queued me that DST has hit the US now too [12:59] hansg: ah, yes. i will send out an email asking for people to fill out a "good time for meeting" matrix [12:59] I'm fine with the current time, but maybe some others want to it changed? [12:59] we'll see if we can come up with "better" options [12:59] ok [12:59]  no more from me [12:59]  Ahh,  NoBitsInSrv and the GCJ update were ratified last week. [13:00] tibbs: thats right. i'll tackle the writeups while i'm poking things today [13:00] OK. Nothing else from me. [13:00] alrighty. lunch time for me, this meeting is done! [13:00] thanks everyone [13:01] Next meeting in two weeks, 2008.05.06