Packaging:Minutes20080311

Present

 * DominikMierzejewski
 * HansdeGoede
 * JasonTibbitts
 * RalfCorsepius
 * RexDieter
 * TomCallaway
 * ToshioKuratomi
 * VilleSkyttä

Proposals
The following proposals were considered:


 * http://fedoraproject.org/wiki/PackagingDrafts/OCaml
 * Accepted (6 - 0)
 * Voting for: hansg spot Rathann|work rdieter tibbs abadger1999
 * Voting against: none
 * Abstaining: scop racor


 * http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions
 * Further questions were posed and will be relayed to the draft submitter.


 * http://fedoraproject.org/wiki/PackagingDrafts/Tcl
 * Accepted (6 - 0)
 * Voting for: spot rdieter avadger1999 hansg Rathann|work tibbs
 * Voting against: none


 * Ban unicode in package names (no draft submitted)
 * Not accepted
 * Voting for: racor rdieter
 * Voting against: abadger1999
 * Abstaining: tibbs

Next Meeting
Unless the time is changed to adjust for DST or the schedules of the new committee members, the next meeting will be March 25 at 17:00 UTC in
 * 1) fedora-meeting.

IRC Logs
[12:05] Hi all, I don't know how involved in any discussions I'll be as I'm home alone with my 2 (awake) daughters of 10 months resp. 4 years old. [12:06] unfortunately I'll have to leave in about 10 minutes today [12:06] * rwmjones just wants to discuss any issues with http://fedoraproject.org/wiki/PackagingDrafts/OCaml [12:07] rwmjones, I've taken a good look at it this week, and it looks fine to me [12:07]  <-- svahl has left this channel. [12:07] But don't  shouldn't we have something like a schedule and someone leading the meeting (making sure we sortof stick to the schedule) [12:08] spot: ping, around to lead FPC meeting? [12:09] Does anyone have the right to set the topic here? [12:09] Yes. [12:09] The running agenda is http://fedoraproject.org/wiki/Packaging/GuidelinesTodo [12:10] sorry, lunch ran late [12:10] * spot is here now [12:12] who else is still around? abadger1999, racor, hansg, rdieter, Rathann|work, scop? [12:12] * abadger1999 half here. Also busy with FAS2 migration. [12:12] here [12:12] * hansg is here (sortof also babysitting at the same time :) [12:12] here [12:12] still around, but will need to leave in just a couple of minutes, so count me out [12:13] Can we get opinions on the ocaml changes really quick? [12:13] any questions, just ask me [12:13]  * spot is still reading the ocaml draft [12:13] ocaml gets +! from me [12:13] http://fedoraproject.org/wiki/PackagingDrafts/OCaml [12:13] make that +1 [12:14] I wish the draft indicated where the changes are. [12:14] you're disabling debuginfo [12:14] is that really what we want to do? [12:14] You have to disable debuginfo for ocaml. [12:14] Otherwise it just comes out empty. [12:15] debuginfo doesn't really contain anything useful for ocaml programs [12:15] you _can_ debug them under gdb [12:15] but gdb doesn't know the language so you end up having to debug assembler [12:15] (if I've understood the purpose of debuginfo, that is) [12:15] "Binaries should be stripped, as per ordinary Fedora packaging guidelines." is misleading [12:15] Not to mention that the compiler doesn't put in any symbols that you could strip out. [12:15] * Rathann|work is here [12:15] http://fedoraproject.org/wiki/PackagingDrafts/OCaml?action=diff&rev2=3&rev1=1 [12:16] scop I didn't understand that -- I just meant that ordinary Fedora policy about stripping binaries should apply, except in that one special circumstance (which in practice affects precisely two binaries at the moment) [12:17] ok [12:17]  +1 from me [12:17]   rwmjones: as far as I know this stripping bug is being addressed upstream [12:17] Rathann|work, afaiaa upstream rejected it? [12:18] if you follow that debian bug report you'll see some messages from upstream on the subject [12:18]  yes [12:18] If in the future is addressed upstream then we can update the guidelines to indicate releases where it is no longer necessary to avoid stripping. [12:18] sorry, I need to go now, and am not familiar enough with the draft to vote [12:18]  > Rather than muck with ELF, a simpler solution would be to embed the [12:18]  > bytecode executable as initialized C arrays in the executable [12:18]  > generated by ocamlc -custom. That's what ocamlc -output-obj does, and [12:18]  > I believe it shouldn't be too hard to adapt the existing -output-obj [12:18]  > code to the -custom case. [12:18]  Mmm. Ok, it will be ocaml 3.09 stuff though. [12:18] ah ok, upstream did a partial fix in ocaml 3.09 [12:18] but they didn't fix the ocamlc -custom case [12:18] it used to be that you couldn't strip any bytecode binaries at all, but that's not true since 3.09 [12:19] Do we need to/want to discuss new meeting times? (Since we have new members)? [12:19] <-- scop has left this channel ("Leaving"). [12:19] abadger1999: lets do that on the mailing list [12:19] * spot tries to keep us focused on the ocaml topic [12:19] if you haven't voted, please do so. issue needs +5 to pass. [12:19]  +1 from me [12:19]  +1 [12:20] that's +4 so far by my count ... [12:20] +1 all seems reasonable. [12:20] still +1 from me [12:20]  0 [12:20]  I'd like the find-provides/requires to hack to find its way into our rpm-build package [12:20] Plus I've reviewed a bunch of ocaml stuff and this will help to clarify. [12:20] rwmjones: What is the META file you reference? [12:20] abadger1999: want to vote? [12:20] Rathann|work, there's still a bug that I'm working with upstream about [12:20]  cool [12:20] I agree with Rathann|work that it should get upstream. [12:21] I want to +1 as son as I know what META is. [12:21] abadger1999, META is a file which describes how libraries are linked together (kind of link pkg-config) [12:21] But we can't really wait. [12:21] abadger1999, debian agreed to standardize and have _all_ their libraries require a valid META file [12:21] abadger1999: There's a file named META that contains some package description. [12:21] so I copied their policy for us [12:21]  rwmjones: What should the packager/reviewer "check" in it? [12:21] not much, basically just the 'requires = "..."' lists all required libraries [12:22] I should reference some upstream documentation about META if I can find any ... [12:22] hmm [12:22] * rwmjones checks [12:22] Hmm, yeah, might be nice to say what should be there. [12:22] I've only been checking that it exists. [12:22] Ocaml +1 [12:22] ok, it passes. [12:22] do I need to take it to fesco now? [12:23] rwmjones: we'll take it [12:23]  It will be in the summary and fesco will discuss it on Thursday. [12:23] ok thanks [12:23] Next item: http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions [12:23] diff since we last discussed it: http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions?action=diff&rev2=4&rev1=2 [12:25] the main concern from before was that we weren't sure how unpacking the file in advance saved disk space [12:25] caolan updated the draft with explanatio [12:25] ...n. :) [12:25]  it also includes an example, so I'm +1 on this. [12:26]  I don't remember whether we discussed it last time, but is there nothing compiled in these extensions? [12:26]  tibbs: i'm pretty sure the answer is no [12:27]   what language are they written in? [12:27]  sorry to interrupt out of turn, I've just made this edit which adds a link describing META files: http://fedoraproject.org/wiki/PackagingDrafts/OCaml?action=diff&rev2=4&rev1=3 [12:27]  Most of these are in Java, I think. [12:27]   I mean, they're not binaries, are they? [12:28]  is the new example correct?  It looks like the unpackaed extension is going in a directory with a .zip extension. [12:28]  Hmm, IMHO the openoffice-foo naming should be made mandatory [12:28]  i think they're java goop [12:28]   hm [12:28]  Do we still want to see Java guidelines first? [12:28]   shouldn't they be compiled using our javac then? [12:29] It's possible that compiling them would have no use. [12:29] But honestly someone who knows needs to be around to answer these questions. [12:29] hansg: +1 [12:30] no precompiled binaries is pretty much already covered by existing guidelines. [12:30] ok, i'll pose these items to caolan and we'll revisit it in two weeks [12:30] Also, there's probably no point in having Orion in the template changelog. [12:30]  rwmjones: you should add a footnote link, not just tell people to look at the bottom [12:30] Indeed I see no compiling / build step in the current .spec example. Since its mandatory that everything gets compiled from source, this is not acceptable [12:30] rdieter: True, but the examples should show that then. [12:30] next item: http://fedoraproject.org/wiki/PackagingDrafts/Tcl [12:31] since last discussed: http://fedoraproject.org/wiki/PackagingDrafts/Tcl?action=diff&rev2=11&rev1=10 [12:31] hansg: Many specs have no %build and that's not problematic. [12:31] the concern was around the ambivalent naming case [12:31] he has since resolved it [12:31]  If there's nothing to compile, the rule about compiling from source doesn't really apply. [12:31] <Rathann|work> tibbs: yes, but they contain scripts, not binaries [12:31] <Rathann|work> or firmware [12:31] tibbs I know, but these plugins are code afaik, not data files / nor in an intepreted language [12:31] where in $PATH is unopkg? fc8 has /usr/lib64/openoffice.org/program/unopkg, so scriptlets won't work [12:32] [spot@localhost logjam-4.5.3] $ rpm -qf /usr/bin/unopkg [12:32] openoffice.org-core-2.4.0-9.1.fc9.x86_64 [12:32] I was just about to complement spot that he is keeping the tempo up, but it seems we're still at ooo extensions? [12:32] I guess doing to tcl was optimistic. [12:33] * spot waves his hands about [12:33] spot: => R: openoffice.org-core is not sufficient [12:33] racor: The scriptlets do work. [12:33] I can't say just how. [12:33] racor, you;re probably at F-8, and this is F-9 and up only [12:33] See the existing writer2latex package, btw. [12:33] in particular, ooo >= 2.4 [12:33] tibbs: fc8 doesn't have /usr/bin/unopkg => this proposal is incompatible to fc8 [12:34] racor: Who said it was supposed to be compatible with f8? [12:34] i will have caolan clarify how to do this for F-8 and older. [12:34] <Rathann|work> -1 from me on openoffice extensions for packaging java binaries without compiling them [12:34] caolan indicated that he may push 2.4.0 to the release branches which would bring in a proper unopkg. [12:34] Rathann|work,  no voting needed I think, this cleary needs more work [12:34] Rathann|work: we're not voting on this draft, it still has obvious issues [12:35] hansg: Yes, FC8. This proposal apparently is only applicable for fc >9. [12:35] we are, however, now looking at the tcl draft. [12:35] http://fedoraproject.org/wiki/PackagingDrafts/Tcl [12:35] diff since last discussed: http://fedoraproject.org/wiki/PackagingDrafts/Tcl?action=diff&rev2=11&rev1=10 [12:35] from last time, the concern was around the ambivalent naming case, which the author has resolved. [12:36] I'm +1 on this. [12:37] * spot assumes everyone is reading (or i've fallen off the internet) [12:37] * Rathann|work is reading [12:37] "This rule applies even for Tcl/Tk packages that are already prefixed with tcl in the name (see examples below)", really? [12:37] all the things I remember being issues have been cleaned up. [12:37] I guess EPEL people might appreciate some comments on some of the version-specific issues in those releases. [12:37] But we can add that later. [12:38] I'm only curious, I'm +1 either way. [12:39] +1 [12:39]  +1 [12:39]  thats +4. +5 needed. :) [12:39] FYI, yum list tcl\*|grep -v tcl- gives 21 packages. [12:40]  So we'd have tcl-tclxml according to these new naming guidelines. [12:40]  And I picked the example that's already in there.  Duh. [12:41]  <Rathann|work> looks sensible, +1 [12:41]  Anyway, +1. [12:41]  But we need to think about whether we want existing packages to be renamed. [12:41]  tibbs: we've never mandated that in the past. [12:41]  tibbs: renaming -1 [12:41]  I was wonderying why tcl- was mandatory.  That's contrary to our guidelines wrt python, for example. [12:41]  our guidelines don't forbid it. [12:42]  I personally dislike the python guidelines because of that. [12:42]  anyways, it passes [12:42]  PackagingDrafts/Lisp still isn't ready, i need to spend some time working on that one with the author [12:42]  tibbs: I'd prefer consistency, one way or the other. [12:43]  thats all the items that I have on the schedule [12:43] <Rathann|work> rdieter: I've been told to rename a subpackage from foo-python to python-foo a couple of times [12:43] the floor is open to any other issues [12:43] I only bring up the renaming because I don't think we've made guideline changes that would cause so much renaming before. [12:43] I would like to start working on the java guidelines [12:43] Yes. [12:43] hansg: great! [12:43] Rathann|work: been there, done that. :) [12:43] you don't need our permission to do that. ;) [12:43] hansg: Did you get the message about the conference call? [12:44] So any people who are willing to assist (as in review what ever ugly thing I come up with) ? [12:44] I think the idea of a conference call is kind of pointless but I'm going to try to be up early enough to attend anyway. [12:44] hansg: Did you see the in-progress draft? [12:44] Or shall I just post a message to the packaging-list when I've got a new draft ready? [12:44] Folks have been working on it. [12:44] hansg: the packaging-list might not be a bad idea, a wider audience [12:45] We have unicode naming from last wekk. [12:45] tibbs: yes and I'm in contact with Lubu erm whats his name? [12:45] I'm still -1 to banning unicode in package names. [12:45] Conference call? [12:45] <Rathann|work> abadger1999: well, I was half-joking in my posts on that topic ;) [12:45]  But there might be enough people to passit. [12:45]  <Rathann|work> -1 from me too [12:45]  hansg: Yes, Andrew Overholt mailed a bunch of people about having a conference call on Friday. [12:46]  I'm -1 to unicode in packagenames, package name == filename, and our mirrors aren't ready, I'm not even sure we are ready. [12:46]  I'm happy to simply not vote until we know the infrastructure is ready. [12:47]  hansg: The proposal was from racor:  "Ban unicode in package names" [12:47]  tibbs, a conference call about the java guidelines? [12:47]  Although I think we should have one inconsequential unicode package name just to test our infrastructure. [12:47]  abadger1999,  I know [12:47]  hansg: Yes.  Andrew Overholt == big Java guy in Red Hat. [12:47]  Okay.  But you'd be +1 to the proposal then. [12:47] <Rathann|work> écolier-fonts? [12:47] Lubomir isn't really the person to be talking to as far as I know. [12:48] tibbs, which sounds like a good idea until createrepo explodes on updates, or half of the mirrors fail to sync [12:48] abadger1999, yes [12:48] If we keep our heads in the sand and never test it, we'll never test it. At some point we have to try sometthing. [12:48] But that's more in the court of the infrastructure folks. [12:50] tibbs, about the java things, Lubomir  was asking people to take a look at the guidelines on fedora-devel list, but I'll get in contact with Andrew too. [12:50] hansg: We're seeing the typical tichotomy between people who work better in person or via voice and the people who want to work by email, wiki and IRC. [12:51] Personally I don't understand why we need a conference call at all, but I didn't call for it, so.... [12:51] Maybe we need to create a little repo on our infrastructure that gets mirrored but isn't the main repo. Then we can start trying things and see what breaks. [12:52] drop écolier-fonts in there and see what breaks. [12:52] abadger1999, sounds like a plan [12:52] A pain for someone besides us, though. [12:52] * abadger1999 opens a ticket [12:53] I say we can ask infrastructure to tell us when they think things are ready. Until then we obviously can't have utf8 package names for fear of breaking things. [12:53] sorry, i got distracted [12:54] abadger1999: -1 [12:54] racor: -1 to what? [12:55] to abadger1999's drop écolier-fonts in there and see what breaks [12:55] That's an infrastructure team matter. [12:55] tibbs: my issue is not the infrastructure, my point is usability [12:55] racor: Because of usability? [12:56] abadger1999: let me reiterate: ban non acsii, because many users will not be able to type such package names [12:56] racor I think you misunderstand / misread, abadger proposed a seperate unicode-test repo, and then request some mirrors to carry this (seperately) and then we can get some idea if utf-8 names are technicall feasible [12:57] You know, I think we all understand the point that you're against this. Simply throwing out -1 whenever someone wants to investigate part of the issue really isn't productive. [12:57] hansg: this would be OK [12:57]  ok, so the proposal is to ban unicode (non-ascii) in package names [12:57] racor: system -> preferences -> hardware -> keyboard [12:57] can i see votes on that specific proposal? [12:58] tibbs:  drop écolier-fonts in there and see what breaks to me means : release this package under this name and see who complains. [12:58] layoutoptions-> composekey -> choose one [12:58] compose " e ->ë [12:58]  I wish I had a compose key. [12:58]  tibbs: gotcha [12:58]  racor: Sorry.  My thought was split over two lines. [12:58]  * spot whistles to himself [12:58]  tibbs, you can choose one, I use left alt, or one of those never used windows keys [12:59]  spot: -1 [12:59]  make that right alt [12:59]  hansg: I give you 5 secs to answer: type a cyrillic "k" (small k) [12:59]  anyways the point is latin1 chars aren't that hard, I agree chinese chars is a different story [13:00]  spot: 0 [13:00]  racor that isn't laten1 but latin2 [13:00]  I don't think we can really consider the matter as long as a vote allowing utf8 package names is pointless because infrastructure blocks it. [13:00]  * spot calls for votes again... [13:00]  hansg: to you! to aunt tillie "é" or "ß" is a problem [13:00]  aunt tillie will use a gui -> no problem [13:01]  The aunt tillie argument really gets old. [13:01] She'll just click. [13:01] sorry, but this is going to be ridiculous [13:01] <-- racor has left this server ("Leaving"). [13:02] "takes his ball...." [13:02] spot: +1 (at least until infrastructure signs off) [13:02] spot votes for what, I say lets vote to end this meeting :) [13:02]  since we're down to 6 members, and two have voted either against or to abstain... [13:02]  the measure fails [13:03]  are there any other items for today? [13:03]  Did we make any progress on the remaining vacancy? [13:03]  am I one of those 2? and what measure I'm confused now [13:03]   ok, so the proposal is to ban unicode (non-ascii) in package names [13:03]   spot: -1 [13:03]   spot: 0 [13:03]  ok [13:04]  if you don't have anything additional for today, please indicate that no, you do not. :) [13:04] my psychic powers only work on thursday. [13:04] I don't [13:04]  Nothing besides the question I just posed. [13:04] no [13:04]  tibbs: we have some volunteers, i'm going to send an email out for people to vote on them. [13:04] Cool, thanks. [13:05] ok guys, we're done for today. thanks for your patience. we'll meet again in two weeks. [13:05] no