From Fedora Project Wiki

fp-wiki>ImportUser
(Imported from MoinMoin)
 
m (Packaging/Minutes20070619 moved to Packaging:Minutes20070619: Moving Packaging Pages to Packaging Namespace)
 
(One intermediate revision by one other user not shown)
(No difference)

Latest revision as of 03:21, 21 December 2008

Fedora Packaging Committee Meeting of {2007-06-19}

Present

  • AxelThimm (thimm, thim1)
  • DavidLutterkort (lutter)
  • JasonTibbitts (tibbs)
  • RexDieter (rdieter)
  • ToshioKuratomi (abadger1999)
  • VilleSkyttä (scop)

Writeups

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

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:


Other Discussions

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

IRC Logs

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