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