From Fedora Project Wiki

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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"