From Fedora Project Wiki

Revision as of 16:30, 24 May 2008 by Ravidiip (talk | contribs) (1 revision(s))

Fedora Packaging Committee Meeting of {2007-08-21}

Present

  • DavidLutterkort (lutter)
  • JasonTibbitts (tibbs)
  • JesseKeating (f13)
  • RalfCorsepius (racor)
  • TomCallaway (spot)
  • ToshioKuratomi (abadger1999)
  • VilleSkyttä (scop)

Writeups

Nothing was submitted to FESCo last week.

Votes

The following proposals were considered:

Other Discussions

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

  • Whether the buildsys should fail builds that result in empty debuginfo packages.
  • What the License: tag actually applies to.

IRC Logs

[11:59]  <f13> meetin in pogress.
[12:01]  <lutter> doesn't look like a quorum
[12:02]  --> racor has joined this channel (n=rc040203@HSI-KBW-082-212-056-027.hsi.kabelbw.de).
[12:03]  --> scop has joined this channel (n=scop@cs181043142.pp.htv.fi).
[12:05]  <spot> ok, i see racor, scop, lutter, f13, myself
[12:06]  <spot> abadger1999? tibbs?
[12:06]  <scop> I'm semi-afk, fully here in a few minutes
[12:06]  * abadger1999 here
[12:06]  <tibbs> Sorry, on the phone.
[12:08]  <racor> here, but as usual, will have to quit early
[12:09]  <scop> here now
[12:09]  <spot> ok, first item:
[12:09]  <spot> http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns
[12:09]  <spot> all the bugzillas holding this one back have been resolved
[12:09]  <tibbs> Finally.
[12:11]  <spot> the only item missing is that the templates need BuildRequires: pkgconfig
[12:12]  <spot> Otherwise, I vote +1 (with the fixed BR)
[12:13]  <spot> is it safe to assume everyone is reading this?
[12:14]  <abadger1999> I don't use emacs but it looks good in general.
[12:14]  <scop> well, emacs-devel and xemacs-devel install pkgconfig files so they should be pulling in pkgconfig already
[12:14]  <spot> scop: ahh, valid point
[12:14]  <scop> there were some differing opinions about the emacs-common- prefix but I don't remember the outcome
[12:15]  <spot> scop: this proposal doesn't change the existing naming scheme
[12:15]  <scop> yep
[12:15]  <scop> +1
[12:16]  <spot> ok. thats +2. :)
[12:16]  <f13> +1
[12:16]  <abadger1999> +1
[12:16]  <f13> it's a policy, better than nothing, can be adjusted.
[12:16]  <spot> +4... racor? tibbs? lutter?
[12:17]  <racor> I don't use emacs and have almost no clues about it =>No opinion
[12:17]  <tibbs> Still on the phone...
[12:17]  <lutter> sorry ... on the phone
[12:17]  <racor> my gut feeling: no obvious bugs, but too long, don't want to block it => +1
[12:17]  <lutter> and I think I have to drop off the meeting .. I can look into this in about 30 mins or so
[12:18]  <spot> ok, +5, it passes
[12:18]  <spot> thats the only item on the agenda for today that I know of
[12:18]  <spot> does anyone else have anything?
[12:18]  <scop> making empty debuginfo packages a build error?
[12:18]  * scop looks up ML and bugzilla references
[12:19]  <tibbs> OK, finally off of the damn phone.
[12:19]  <tibbs> +1 for emacs
[12:19]  <spot> scop: is that a koji issue or a packaging issue?
[12:19]  <scop> nothing to do with koji
[12:19]  <scop> it's about whether we would find that desirable
[12:19]  <tibbs> Empty debuginfo should be a packaging error but it's up to someone else if the build fails or not.
[12:20]  <spot> i think rpmlint should pick it up (doesn't it?)
[12:20]  <tibbs> I don't think so.
[12:20]  <scop> I think it does (but I may misremember)
[12:20]  <spot> it should say something like W: Empty package
[12:20]  <scop> anyway rpmlint is not enough for that
[12:21]  <scop> new empty debuginfo packages keep appearing
[12:21]  <scop> http://www.redhat.com/archives/fedora-packaging/2007-July/msg00159.html
[12:21]  <scop> https://bugzilla.redhat.com/249956
[12:22]  <tibbs> I'd be all for having the build fail in that case, but I don't think it's FPC's place to say that it should happen.
[12:22]  <scop> whose would that be?  fesco?
[12:23]  <tibbs> spot: What about that addendum on whether the license: tag covers source or binary?
[12:23]  <spot> scop: fesco, probably.
[12:23]  <tibbs> scop: I'd just say it's up to the koji developers.
[12:23]  <scop> -1 for koji devs, this is a policy thing
[12:23]  <tibbs> I mean, if they want to make build errors out of guideline violations, they really aren't doing anything wrong.
[12:23]  <racor> spot,scop: debuginfos are a packaging issue, our job, not fescos
[12:24]  <tibbs> Whether koji returns an error for something is not our job.
[12:24]  <spot> I don't think empty debuginfos should be permitted by the guidelines
[12:24]  <spot> but i don't think we should be erroring builds when they're empty
[12:24]  <tibbs> If the guidelines permit empty debuginfo packages currently then we need to rectify that.
[12:24]  <racor> tibbs: right koji isn't ours, but  a guideline saying "valid debuginfo/not empty" would be
[12:25]  <spot> i don't think that they say anything about debuginfo packages right now
[12:25]  <scop> oh, they do
[12:25]  <scop> http://fedoraproject.org/wiki/Packaging/Debuginfo
[12:25]  <spot> Packages should produce useful -debuginfo packages, or explicitly disable them when it is not possible to generate a useful one but rpmbuild would do it anyway
[12:25]  <tibbs> So we've done our job.
[12:25]  <spot> Yeah, i think we've got this one covered.
[12:26]  <scop> why I would like it to fail builds is because I can't think of a case where empty debuginfo would be useful
[12:26]  <scop> and more importantly
[12:26]  <scop> it is often a sign of bad CFLAGS in use, which is a security issue
[12:26]  <scop> eg. possibly no stack protection, source fortification done
[12:27]  <spot> scop: i see what you're saying, but I think that it is outside of the FPC scope
[12:27]  <spot> since it involves code changes in either redhat-rpm-config or rpm
[12:27]  <spot> you've got to convince the maintainer(s)
[12:27]  <spot> FESCo could also say "make it so"
[12:28]  <scop> I already have a maintainer ack in Bugzilla
[12:28]  <racor> spot:I feel the issue behind this is more general: who's job is it to enforce the guidelines?
[12:28]  <spot> racor: at review time, its the reviewer
[12:28]  <spot> after that? i don't know.
[12:28]  <tibbs> It's everyone's responsibility.
[12:28]  <scop> frankly, I don't see how this would be any more controversial/different from failing the builds on unpackaged files
[12:29]  <racor> it's more general: static libs, CFLAGS abuse, *.la's, ...
[12:29]  <spot> scop: the guidelines support you on this issue
[12:29]  <scop> but if fesco is better suited for the decision, I have no problem with that
[12:29]  <scop> could someone here who is in fesco put this on their agenda?
[12:30]  <spot> sure. i'll take it to fesco.
[12:30]  <scop> thanks, that's good enough for me
[12:30]  <scop> if it gets a green light, I'm also available to help out with the implementation
[12:30]  <racor> sorry, I've got to quit, bye
[12:31]  <abadger1999> racor: Bye
[12:31]  <spot> tibbs: on the licensing issue
[12:31]  <tibbs> Which one?
[12:31]  <spot> i spoke with several people (Max, RH Legal) about it
[12:31]  <spot> whether the tag covers source or binary
[12:32]  <spot> based on their advice, we decided that the tag covers the binaries, as determined solely by the source code within the package
[12:32]  <tibbs> As amazing as it sounds, that may actually be even more confusing.
[12:33]  <spot> I know.
[12:33]  <spot> What it means is that to figure out the license(s) of your package, you need to look at the sources in your package and how they are linked together (or not).
[12:34]  <tibbs> OK, so you ignore the act of dynamic linking.
[12:34]  <tibbs> I can get behind that, but what about static links or use of headers?
[12:34]  <spot> if the static library is included in the source package, take it into account
[12:34]  <spot> (static library source, rather)
[12:35]  <spot> if the headers are included in the source package, take them into account
[12:36]  <spot> they also confirmed that interpreted languages calling out to other "modules" is not linking, and does not create a derived work
[12:36]  <spot> at least in the opinion of RHT
[12:37]  <scop> interesting
[12:37]  <spot> they also noted that there is no real legal definition of a derived work in the sense of the term that the FSF uses
[12:38]  <abadger1999> :-)
[12:38]  <spot> no one's ever taken a case to court with that as an item
[12:38]  <spot> legal advised that dynamic/static linking may not even create derived works
[12:38]  <spot> but that within the same package, there was enough of a gray area to play it safe
[12:39]  <spot> so the idea is that we draw an invisible box around the package, determine the license of the compiled bits based on the source used inside the box
[12:39]  <spot> then list those in the tag
[12:40]  <spot> this gives us the added benefit of being prepared for the possibility that dynamic linking _does_ create a derived work
[12:40]  <spot> we can then use the License tag info as a starting point to check for potential problems
[12:41]  <spot> with all of that said...
[12:41]  <spot> we were still advised to be careful with GPLv3 mixing
[12:42]  <spot> (if your head doesn't hurt yet, imagine how mine feels)
[12:42]  <abadger1999> spot: To make license tag useful for auditing, we're going to need some tools to be written.
[12:42]  <spot> Yes, we're just starting to make some crude ones on fedora-legal-list
[12:43]  <abadger1999> Cools.  Tracing deps and associating a license with each node in the dep chain?
[12:43]  <tibbs> spot: So do we still need to float that proposal, or has the issue already been decided by the lawyers?
[12:43]  <spot> the issue has been decided
[12:44]  <spot> abadger1999: eventually, yes.
[12:44]  <spot> any other topics for today?
[12:44]  <scop> none here
[12:45]  <abadger1999> What about COPYING (GPLv2) file with no license tags embedded in any source file?
[12:45]  <abadger1999> What license if the work under?
[12:45]  <drago01> GPL+
[12:45]  <tibbs> The COPYING file itself should say that it's GPL+.
[12:45]  <spot> they confirmed that without any note of intent from upstream, we have to consider it GPL+
[12:46]  <tibbs> "You can choose any version"
[12:46]  <spot> because COPYING is a sign of intent, technically
[12:46]  <tibbs> However, is even a mention of "GPLv2" in setup.py or a README  enough intent?
[12:46]  <spot> yes
[12:46]  <spot> any mention of a version in a user composed doc or source code is intent enough
[12:47]  <tibbs> Can we also just use an email?
[12:47]  <spot> yes, but if we do that, we need to include the email as %doc
[12:47]  <drago01> aren'T 90% of the gpl headers in source files just copy & paste?
[12:47]  <tibbs> That has happened multiple times with Perl modules; we always include the email as %doc.
[12:48]  <spot> tibbs: *nod* they didn't have any problem with us doing that, although they'd prefer upstream fix the source
[12:48]  <abadger1999> So COPYING(GPLv2)  is a sign of intent to use GPL but not a sign of intent to use GPLv2?
[12:48]  <spot> abadger1999: yes.
[12:48]  <abadger1999> Love it
[12:48]  <tibbs> Because the GPLv2 COPYING file explicitly says that.
[12:48]  <spot> only because the GPL text says explicitly that
[12:48]  <spot> any other non GPL/LGPL license, we could go by that
[12:49]  <tibbs> It was weird channeling spot there.
[12:49]  <drago01> spot: whats the differece between a copy&pasted header and a unmodificed COPYING file?
[12:49]  <spot> drago01: the header in the source code is legally binding, and specifies a version
[12:49]  <spot> even if its copied and pasted, the author did it.
[12:49]  <drago01> ok
[12:50]  <spot> ok, i think we're done for today, thanks all.
[12:51]  <scop> thanks
[12:51]  <-- scop has left this channel ("Leaving").
[12:52]  <abadger1999> Thanks spot
Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:Minutes20070821&oldid=9011"