Packaging:Minutes20070619

Present

 * AxelThimm
 * DavidLutterkort
 * JasonTibbitts
 * RexDieter
 * ToshioKuratomi
 * VilleSkyttä

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


 * Corrections to the scriptlets: http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippetsFixes
 * OCaml guidelines: http://fedoraproject.org/wiki/PackagingDrafts/OCaml
 * Revisions to the rule on directory ownership:

They should be written into the guidelines and announced soon, if this hasn't already been done by the time you read this.

Votes
The following proposals were considered:


 * Blanket exception for linking against libraries that are only available as static, and initialCC requirement.
 * http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges
 * Accepted (6 - 0)
 * Voting for: tibbs scop abadger1999 lutter thimm drieter

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


 * Allowing SCM commit ID information into the release tag:
 * http://fedoraproject.org/wiki/PackagingDrafts/CommitIDs
 * The draft is being modified significantly to remove pointless stricture.

IRC Logs
[12:01:01] crime time? [12:03:51] I think so [12:04:27]  If we are only two, then we don't count yet as a mob ;) [12:04:41]  here [12:04:42]  * tibbs here. [12:04:56]  * abadger1999 here [12:05:00]  Still not a mob, though. [12:05:15]  Join scop has joined this channel (n=scop@cs181043142.pp.htv.fi). [12:05:37]  That would be six, yes? [12:06:03]  I count six, yes. [12:06:10]  spot? [12:06:13]  f13: ? [12:07:22]  I guess not. [12:08:00]  So we have enough to vote, do we want to consider anything? [12:08:14]  I only see Emacs, Users/Groups and that CommitID thing on the schedule. [12:08:49]  Emacsen stuff is still waiting for input from the GNU Emacs maintainer [12:09:09]  We could consider an exception for libraries which only have static libraries. [12:09:14]  spot added his Users/Groups draft but he's not here today. [12:09:39]  abadger1999: Yes, that would be good to at least talk about. [12:09:54]  spot's proposal was/is being discussed on list [12:10:06] Does anyone have any opinion at all regarding my CommitID proposal? [12:10:17] I'll vote for it. [12:10:18] http://fedoraproject.org/wiki/PackagingDrafts/CommitIDs [12:10:32] Do we also want to consider using just a commitID? [12:10:43] I think the date is important. [12:11:00] Fine for me. [12:11:08] I'm ok with the proposal, makes sense. [12:11:27] Frankly I don't care one way or the other, but people have asked for this and some have just been doing it. [12:11:32] +1 [12:11:48]  With SVN it makes some sense; unfortunately I don't know enough about git to say one way or the other. [12:12:19] The full git commit IDs are extremely long, aren't they? But someone submitted a package with a shorter ID, and I don't know where that came from. [12:12:42] Join Besniku has joined this channel (n=Besnik_B@athedsl-196111.home.otenet.gr). [12:12:52] they probably just truncated [12:13:09] it may be worth mentioning that this tag/commit_id should be kept relatively short. long = bad. [12:13:10] and using the truncated hash is probably a bad idea... I'd rather just stick with the comment above the tarball with the full commit id [12:13:42] git commit ids (and bzr and monotone as well, iirc) are sha1 hashes. so we really don't want them in the %release [12:14:17] With cvs I'm using cvs and with svn r. Would that make my packages non-reviewable? [12:14:22] hg has a numeric id, but it's only valid within a specific repo and shouldn't really be used for identification [12:14:39] thimm: what can you use for CVS? [12:14:47] A tag, maybe? [12:14:48] so, atm, this seems only relevant for cvs/svn then? [12:15:12] s/data/date/ [12:15:21] Then your packages violate the naming guidelines. [12:15:26] It's cvs. [12:15:26] using the numeric revision id for svn instead of date seems reasonable. but I think for snapshots in general, date is the only thing that's viable [12:15:52] I think the date should always be there in any case. [12:16:32] The rest could indeed go into comments. [12:16:42] Which I have no problem with. [12:17:13] So it doesn't look like there's any real concensus here. [12:17:18] The usual nomenclature is cvs20070606 [12:17:30] by the way, rpm has CVSId and SVNId tags, does anyone know what they're for or how they can be used? [12:17:30] Not according to the naming guidelines. [12:17:34] And it is beneficial to keep letters/numbers in that order [12:18:00] scop: dunno, good question tho. [12:18:10] tibbs: maybe modify the proposal to mention length should be limited, maybe to X characters? [12:18:22] tibbs: as I said, I'd be up for modifying for the case of svn. I don't know that we really can for anything else [12:19:08] scop: iirc, they were just text fields without any defined meaning or anything of the sort :/ [12:19:19] jeremy, thought so :) [12:19:41]  Topic rdieter sets the channel topic to "Fedora Packaging Comittee Meeting -- Commit IDs http://fedoraproject.org/wiki/PackagingDrafts/CommitIDs". [12:19:44]  I can resubmit the proposal allowing for only svn and indicating the the commit IDs of other SCMs are either too long or not useful for that purpose. [12:20:08]  So I'll do that for next week. [12:20:11]  The commitID is mostly informational (happens to the right of the significant portion of the release tag.) [12:20:14]  yeah, that would make sense [12:20:29]  So I wouldn't be against short commitIDs from other SCMs. [12:21:00]  Many projects have a canonical tree/repository where the short bzr/hg tag is significant. [12:21:01]  * scop is not sure whether we're interested in *what* the SCM is, maybe just YYYYMMDDsnap for everything? [12:21:28]  scop: I've never understood that either because the instructions for checking out have to be in the spec anyway, [12:21:37] but my aim wasn't to change that much of the guidelines at once. [12:21:46] spot wrote them so perhaps he has more insight. [12:22:07] ok [12:22:54]  I would be happy to consider doing just that, but I'd want to see buy-in from a majority of the committee first. [12:23:29] well, you have my +1 for that [12:23:46] Anyway, I'm done. [12:23:49] YYYYMMDDsnap would be fine by me too :-) [12:24:10]  The only thing is whether contributors who want to do DATEsvnID will be upset. [12:24:20]  or simplify to say YYYYMMDD where len(crap) < X [12:24:40]  and let folks fight over their . [12:24:55]  "As long as the date is there and you're under 16 characters, you're OK"? [12:25:14]  How often do we really epxect snapshots to be packaged? [12:25:16]  I'd be ahppy with that [12:25:17]  tibbs: +1, worksforme [12:25:20]  tibbs: :-) +1 [12:25:48] Is 16 characters enough? Is 20 too much? [12:26:24] tibbs: len(crap) < 16 ? or including the YYYYMMDD too? [12:26:35] The truncated git commit ID case I saw was 21 characters total including the date and "git". [12:27:17] Anyway, I'll write it up with len(crap) <= 16 and see what happens from there. [12:27:20] 16 is plenty, this is only a *guideline* afterall, if there's a case for breaking it, fine. [12:27:31] So abadger1999, you're up, I guess. [12:28:06] What do ya'll think of a blanket exception for libraries which only provide static versions? [12:28:27] Better than going through FESCo all the time, I guess. [12:28:40] makes sense [12:28:48] But the libnet case is interesting. [12:29:02] Topic rdieter sets the channel topic to "Fedora Packaging Comittee Meeting -- blanket exception for libraries which only provide static versions?". [12:29:02] Anyone want background here? [12:29:12] yeah, a little [12:29:18] Something like: If a library you depend on only provides a static version your package can link against it provided that you BuildRequires the -devel so that the package automatically uses the dynamic version when it is available. [12:29:27] libnet is only available as a static library. [12:29:51] I was reviewing two packages which link against it, and by the rules I have to pass it through FESCo. [12:30:05] However, debian patches libnet and shipps it as a .so. [12:30:46] Fedora maintainer doesn't want to follow debian's lead because upstream may come back to life. [12:31:04] I'm ok with that. upstream trumps. [12:31:11] I think that's a bit whacked, especially since this is actually security-sensitive. [12:31:19] yeah, I'd rather those things get resolved upstream [12:31:24] And, to clarify for cases like this, should libnet be named libnet-devel or libnet-static ? [12:31:36] it's unclear to me anyway [12:31:51] I thought it [12:31:56]  is libnet-static [12:31:59] Adding sonames downstream is already dangerous, upstream may come up with a different idea of sonameing [12:32:02] One other thing... upstream is currently dead. [12:32:06] When a package only provides static libraries you can place all the files in the *-devel subpackage. When doing this you also have to have a virtual Provide for the static package: [12:32:12] %package devel [12:32:12] Provides: foo-static = %{version}-%{release} [12:32:21] Quoting from our guidelines there. [12:32:30] so the static/dynamic linking argument for security doesn't matter too much here anyway [12:32:35] tibbs: thanks (sorry, my bad) [12:32:42] btw, there's nothing about -static in naming guidelines [12:32:46] lutter: Oh, it matters. [12:33:04] tibbs: How? [12:33:11] Fedora maintainer could fix a bug, but statically linked applications will need rebuilds to see the fix. [12:33:18] If there is noone fixing security issues we're hosed either way [12:33:43] We have distro maintainers still doing maintanence. [12:33:55] Dead upstream doesn't mean that nobody's working on the software. [12:33:57] Crossing fingers ... [12:34:00] heh [12:34:16] imo, matter is moot in this case, *Fedora* maintainer is unwilling to do it. [12:34:31] it = munge to make shared lib. [12:34:39] there's policy on the wiki that says that a dead upstream means the Fedora Packager is responsible for security fixes. [12:34:42] Which is a poorly considered decision, really. [12:34:43] How about a non-packaging guideline: [12:34:59] ENOTOURBUSINESS [12:35:14] Question that stems from that is whether "dynamic libs" qualifies as a security issue. [12:35:22] "Static lib maintainer must ping reverse dependency chain on his *-static package on security issues"? [12:35:28] or more imortantly, ENOTFPCBUSINESS :) [12:35:52]  right (though it said YOUR, not OUR). [12:36:17]  Well, we're also talking about policy, whether we're authorized to do so or not [12:36:34]  We can suggest the policy or reverse awareness on static libs to fesco [12:36:37]  pinging is good [12:36:46]  thimm: well duh. that's just common sense. I'm uncomfortable trying to make policy around that. [12:37:04]  since Fesco has to decide on a case-by-case basis, they'd have to say they'd had enough, or that they are happy with giving blanket approval for static-only upstream libs [12:37:05]  Common sense != practiced :) [12:37:14] maybe also have all maintainers of packages that contain a static lib from a package be initialcc'd on that static lib package? [12:37:27] s/contain/link in/ [12:37:33] lutter: abadger1999 brought this up becaose FESCo has pretty much had enough. [12:37:48] scop: +1, good sense that. [12:37:51] I brought three static linking cases to them in one week, all of which would fall under the blanket exception. [12:38:13] I've no idea why I was the one who ended up with all of the static linking reviews. [12:38:36] are we ready for a vote yet? [12:38:40] scop: +1 I like that idea. [12:38:51] +1 to abadger1999 blanket exception proposal. [12:38:56] Join thim1 has joined this channel (n=thimm@p54BD593B.dip.t-dialin.net). [12:38:58] scop: +1 [12:39:04] +1 [12:39:08]  blanket exception: +1 [12:39:10] +1 for abadger1999's exception [12:39:11] abadget1999: Want to (re)f+1 [12:39:18] +1 [12:39:35]  +1 for everybody (and kittens too). [12:39:55] +1 to scop's suggestion, too [12:40:42] OK, looks like we're all in agreement here. [12:42:04] abadger1999, scop: can you put your proposals in the wiki, for FESCo ratification? [12:42:18] rdieter: Will do. [12:42:35] Also, we're a go for the proposals we submitted last week. [12:42:40] abadger1999, mail me the URL if you want help with it [12:42:46]  or just mash them into one proposal.... [12:43:14] Because I was late with the summary they asked for an extra couple of days to consider but there were no further comments. [12:43:27] tibbs: ok, I'll go in and s/ratify/writeup/ those older items. [12:43:32] I updated ScriptletSnippets about half an hour ago [12:44:02] And ocaml's been written up already. [12:44:21] The drivers should announce these; do we have the maintainers-announce mailing list yet? [12:44:35] I can't keep track of which list we're supposed to use now. [12:44:43] maintainers-announce exists now, afaik. [12:44:57] not sure if this is something on-topic for that list, however. [12:45:17] New or modified guidelines aren't on-topic? [12:45:31] I think we're supposed to use fedora-devel-announce. [12:46:12] me too, I don't think we're producing too much traffic to upset anyone there [12:52:32] So, I suppose we're done? [12:52:42] * scop just sent a note about ScriptletSnippets to fedora-devel-announce, let's see if it gets through [12:52:46] done++ [12:53:19] done. [12:53:19] Topic thim1 sets the channel topic to "The topic for #fedora-meeting is: http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel -- Meetings often get logged -- see schedule in the wiki for next meeting". [12:53:34] bye all! [12:54:26] tibbs: static library writeup is going here: http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges [12:54:33] I'm working on it now. [12:54:45] OK, I'll get it into the summary and FESCo notice. Thanks.