From Christian.Iseli at licr.org Thu Sep 1 09:54:46 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 01 Sep 2005 11:54:46 +0200 Subject: Maintainers must be reachable by email In-Reply-To: Your message of "Wed, 31 Aug 2005 16:56:40 EDT." <604aa7910508311356202e48a8@mail.gmail.com> Message-ID: <200509010954.j819sksu010354@ludwig-alpha.unil.ch> jspaleta at gmail.com said: > Would it be technically possible to have some sort of centralized bulletin > board system that can handle person-to-person notes and then require > maintainers to check such a system once-a-week-ish? Isn't this called "Bugzilla" ? :-) From bugs.michael at gmx.net Thu Sep 1 11:53:11 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 1 Sep 2005 13:53:11 +0200 Subject: Maintainers must be reachable by email In-Reply-To: <604aa79105083116532a218fab@mail.gmail.com> References: <20050830104119.35c1f94c.bugs.michael@gmx.net> <80d7e409050830075955c92b44@mail.gmail.com> <22720.1125420546@sss.pgh.pa.us> <1125421993.5875.8.camel@cutter> <20050830171552.GC31063@redhat.com> <604aa79105083010394d88ba5a@mail.gmail.com> <1125463574.9260.66.camel@cutter> <604aa7910508311356202e48a8@mail.gmail.com> <1125531218.20273.0.camel@cutter> <604aa79105083116532a218fab@mail.gmail.com> Message-ID: <20050901135311.3735d68f.bugs.michael@gmx.net> On Wed, 31 Aug 2005 19:53:27 -0400, Jeff Spaleta wrote: > > what's so bad about the -maintainers mailing list? > > I've no problem with it for public discussion. But the original post > in this thread from Mr. Schwendt, specifically talked a problem with > private communication between maintainers. I can't speak as to why he > needs private communication with another contributor. Contributors must be able to contact sponsors. Sponsors must be able to contact contributors. Anyone else may want to contact a package developer privately [e.g. in case of security issues or other warnings ["don't build your last update, it will break badly because of a really embarrassing mistake!"]). Now, -maintainers list (which limits communication to insiders) can be used by fellow contributors to post something like "Joe, I cannot reach you by mail" and Joe hopefully sees that message in the list traffic. But that doesn't solve the problem. What does Joe do? If there is another e-mail address where he can be reached, that address could receive forwarded messages from the @fedora.redhat.com alias. And that would solve the problem. Other things to consider: * Possibility to do account system lookups Name -> Username -> e-mail address * Message submission box in account system * Are all Extras contributors in bugzilla "fedora_contrib" group? From tcallawa at redhat.com Mon Sep 5 01:24:39 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 04 Sep 2005 20:24:39 -0500 Subject: License text in binary packages Message-ID: <1125883479.11674.28.camel@localhost.localdomain> This is just a reminder: YOU MUST PUT THE LICENSE TEXT as a %doc in your Fedora Extra packages. Even perl packages. The only exception to this is when the package is Public Domain, and even then, if there is some text file that says as much, you should include it as %doc. Specifically, concern was raised that the GPL did not require this. Greg took this specific question to Red Hat Legal, and their response was that it is a requirement of the GPL that either the full license or the link to the license be included -- but Red Hat Legal recommend including the full license text as a best practice. They advised us to keep this guideline as a "MUST" in the case of the GPL. Rather than submit every possible license to legal to see whether or not they would advice us to include the text or not, I proposed to the Fedora Extras Steering Committee (FESCO) that we keep the guideline as it is, and require all licenses used in a package to be included in text format, as %doc, in the %files section of that package. The proposal passed. This is MUST item number 7 in the Things To Check On Review section in the PackageReviewGuidelines: http://fedoraproject.org/wiki/PackageReviewGuidelines#head-05a78c7ca440544397657679f87fbdbd84d9be28 This is not optional, this is the direction we're taking based on review with Red Hat Legal. Fedora Core packagers: I don't have control over how you make your packages (yet!) but you should also strongly consider doing this. Fedora Extras packagers: Please audit your own packages and make changes where necessary. Fedora Extras reviewers: Please do not approve packages that are missing license text(s). If you have any questions about this, please feel free to contact me (either publicly or privately). Thanks, ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From rc040203 at freenet.de Mon Sep 5 04:00:54 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 05 Sep 2005 06:00:54 +0200 Subject: License text in binary packages In-Reply-To: <1125883479.11674.28.camel@localhost.localdomain> References: <1125883479.11674.28.camel@localhost.localdomain> Message-ID: <1125892854.25892.41.camel@mccallum.corsepiu.local> On Sun, 2005-09-04 at 20:24 -0500, Tom 'spot' Callaway wrote: > This is just a reminder: YOU MUST PUT THE LICENSE TEXT as a %doc in your > Fedora Extra packages. IMO, this decision is a fault, because it puts contributors into a legally questionable and attackable position. > Even perl packages. The only exception to this is > when the package is Public Domain, and even then, if there is some text > file that says as much, you should include it as %doc. > > Specifically, concern was raised that the GPL did not require this. Greg > took this specific question to Red Hat Legal, and their response was > that it is a requirement of the GPL that either the full > license or the link to the license be included -- but Red Hat Legal > recommend including the full license text as a best practice. They > advised us to keep this guideline as a "MUST" in the case of the GPL. This contradicts the FSF's lawyer's recommendations who, wrt. the GPL say: Detached license files probably will not withstand trial at US courts, only licenses inlined into source code will. Also, I doubt one is permitted to add license files to packages without prior permission of the original authors, because this implies "re-licensing" packages. > Rather than submit every possible license to legal to see whether or not > they would advice us to include the text or not, I proposed to the > Fedora Extras Steering Committee (FESCO) that we keep the guideline as > it is, and require all licenses used in a package to be included in text > format, as %doc, in the %files section of that package. The proposal > passed. This is impracticable, because a) Licensing of sources doesn't necessarily have to match with licenses of binaries. b) There exist packages, where almost each source file carries a license of its own. As an exercise, I'd recommend you trying to package a Fedora->Cygwin cross toolchain. Binutils are GPL'ed, GCC is GPL'ed with exceptions, Cygwin libs are GPL'ed, newlib binaries are "BSD-like" with several dozens of different licenses, newlib sources are GPL'ed. > This is MUST item number 7 in the Things To Check On Review section in > the PackageReviewGuidelines: > http://fedoraproject.org/wiki/PackageReviewGuidelines#head-05a78c7ca440544397657679f87fbdbd84d9be28 > > This is not optional, this is the direction we're taking based on review > with Red Hat Legal. > > Fedora Core packagers: I don't have control over how you make your > packages (yet!) but you should also strongly consider doing this. Let me put it this way: If this legal requirement is as important as you seem to regard it, it would be legally grossly negligible to RH not to update their packages, ASAP. However, as RH, other Linux distributors and package vendors ship their packages without it for > 10 years, I am having strong doubts on FESCO decision rsp. RH-legal's advice and its importance. Ralf From rc040203 at freenet.de Mon Sep 5 04:15:41 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 05 Sep 2005 06:15:41 +0200 Subject: License text in binary packages In-Reply-To: <1125892854.25892.41.camel@mccallum.corsepiu.local> References: <1125883479.11674.28.camel@localhost.localdomain> <1125892854.25892.41.camel@mccallum.corsepiu.local> Message-ID: <1125893741.25892.43.camel@mccallum.corsepiu.local> On Mon, 2005-09-05 at 06:00 +0200, Ralf Corsepius wrote: > On Sun, 2005-09-04 at 20:24 -0500, Tom 'spot' Callaway wrote: > > This is just a reminder: YOU MUST PUT THE LICENSE TEXT as a %doc in your > > Fedora Extra packages. > IMO, this decision is a fault, because it puts contributors into a > legally questionable and attackable position. > > > Even perl packages. The only exception to this is > > when the package is Public Domain, and even then, if there is some text > > file that says as much, you should include it as %doc. > > > > Specifically, concern was raised that the GPL did not require this. Greg > > took this specific question to Red Hat Legal, and their response was > > that it is a requirement of the GPL that either the full > > license or the link to the license be included -- but Red Hat Legal > > recommend including the full license text as a best practice. They > > advised us to keep this guideline as a "MUST" in the case of the GPL. > This contradicts the FSF's lawyer's recommendations who, wrt. the GPL say: > Detached license files probably will not withstand trial at US courts, > only licenses inlined into source code will. > > Also, I doubt one is permitted to add license files to packages without > prior permission of the original authors, because this implies > "re-licensing" packages. > > > Rather than submit every possible license to legal to see whether or not > > they would advice us to include the text or not, I proposed to the > > Fedora Extras Steering Committee (FESCO) that we keep the guideline as > > it is, and require all licenses used in a package to be included in text > > format, as %doc, in the %files section of that package. The proposal > > passed. > This is impracticable, because > a) Licensing of sources doesn't necessarily have to match with licenses > of binaries. > b) There exist packages, where almost each source file carries a license > of its own. > > As an exercise, I'd recommend you trying to package a Fedora->Cygwin > cross toolchain. Binutils are GPL'ed, GCC is GPL'ed with exceptions, > Cygwin libs are GPL'ed, newlib binaries are "BSD-like" with several > dozens of different licenses, newlib sources are GPL'ed. > > > This is MUST item number 7 in the Things To Check On Review section in > > the PackageReviewGuidelines: > > http://fedoraproject.org/wiki/PackageReviewGuidelines#head-05a78c7ca440544397657679f87fbdbd84d9be28 > > > > This is not optional, this is the direction we're taking based on review > > with Red Hat Legal. > > > > Fedora Core packagers: I don't have control over how you make your > > packages (yet!) but you should also strongly consider doing this. > Let me put it this way: > > If this legal requirement is as important as you seem to regard it, it > would be legally grossly negligible to RH not to update their packages, s/negligible/negligent/ > ASAP. > > However, as RH, other Linux distributors and package vendors ship their > packages without it for > 10 years, I am having strong doubts on FESCO > decision rsp. RH-legal's advice and its importance. From tcallawa at redhat.com Mon Sep 5 04:38:31 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 04 Sep 2005 23:38:31 -0500 Subject: License text in binary packages In-Reply-To: <1125892854.25892.41.camel@mccallum.corsepiu.local> References: <1125883479.11674.28.camel@localhost.localdomain> <1125892854.25892.41.camel@mccallum.corsepiu.local> Message-ID: <1125895111.11674.39.camel@localhost.localdomain> On Mon, 2005-09-05 at 06:00 +0200, Ralf Corsepius wrote: > Also, I doubt one is permitted to add license files to packages without > prior permission of the original authors, because this implies > "re-licensing" packages. Not if the upstream author lists the license of the package. If they say "application foo is GPL", but do not include the license text, then adding the text to the binary package is not relicensing it. > > Rather than submit every possible license to legal to see whether or not > > they would advice us to include the text or not, I proposed to the > > Fedora Extras Steering Committee (FESCO) that we keep the guideline as > > it is, and require all licenses used in a package to be included in text > > format, as %doc, in the %files section of that package. The proposal > > passed. > This is impracticable, because > a) Licensing of sources doesn't necessarily have to match with licenses > of binaries. I'm not really sure how you'd achieve this. And even if you did, you could include the text of the "before" and "after" licenses in %doc. > b) There exist packages, where almost each source file carries a license > of its own. > > As an exercise, I'd recommend you trying to package a Fedora->Cygwin > cross toolchain. Binutils are GPL'ed, GCC is GPL'ed with exceptions, > Cygwin libs are GPL'ed, newlib binaries are "BSD-like" with several > dozens of different licenses, newlib sources are GPL'ed. This simply involves multiple files in %doc. Never said it was pretty in the worst corner case, but its by no means impossible. > > This is MUST item number 7 in the Things To Check On Review section in > > the PackageReviewGuidelines: > > http://fedoraproject.org/wiki/PackageReviewGuidelines#head-05a78c7ca440544397657679f87fbdbd84d9be28 > > > > This is not optional, this is the direction we're taking based on review > > with Red Hat Legal. > > > > Fedora Core packagers: I don't have control over how you make your > > packages (yet!) but you should also strongly consider doing this. > Let me put it this way: > > If this legal requirement is as important as you seem to regard it, it > would be legally grossly negligible to RH not to update their packages, > ASAP. > > However, as RH, other Linux distributors and package vendors ship their > packages without it for > 10 years, I am having strong doubts on FESCO > decision rsp. RH-legal's advice and its importance. Your doubts are duly noted, but Red Hat legal advised us to take this course of action, it was discussed by FESCO (not just me), and it was decided as a must. Basically, Red Hat wants us to cover all the bases legally in Extras, and we're going to do it, even if it could end up being unnecessary in the long run. As to whether it will happen in Core, I have no idea, and no control over that whatsoever. If you (or anyone) comes across any complicated or difficult to decide cases of licensing, then we'll deal with those cases at that time. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From rc040203 at freenet.de Mon Sep 5 05:57:20 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 05 Sep 2005 07:57:20 +0200 Subject: License text in binary packages In-Reply-To: <1125895111.11674.39.camel@localhost.localdomain> References: <1125883479.11674.28.camel@localhost.localdomain> <1125892854.25892.41.camel@mccallum.corsepiu.local> <1125895111.11674.39.camel@localhost.localdomain> Message-ID: <1125899841.25892.61.camel@mccallum.corsepiu.local> On Sun, 2005-09-04 at 23:38 -0500, Tom 'spot' Callaway wrote: > On Mon, 2005-09-05 at 06:00 +0200, Ralf Corsepius wrote: > > > Also, I doubt one is permitted to add license files to packages without > > prior permission of the original authors, because this implies > > "re-licensing" packages. > > Not if the upstream author lists the license of the package. If they say > "application foo is GPL", but do not include the license text, then > adding the text to the binary package is not relicensing it. Please contact Prof. Eben Mogden (The FSF's legal adviser). I am inclined to agree wrt. the GPL, but I have doubts on other cases and I have strong doubts on if this is applicable to people outside of the USA. Eg. my feel is, adding such license files is legally void in Germany, and if so, it probably will be considered voiding the licenses of a package as whole. > > > Rather than submit every possible license to legal to see whether or not > > > they would advice us to include the text or not, I proposed to the > > > Fedora Extras Steering Committee (FESCO) that we keep the guideline as > > > it is, and require all licenses used in a package to be included in text > > > format, as %doc, in the %files section of that package. The proposal > > > passed. > > This is impracticable, because > > a) Licensing of sources doesn't necessarily have to match with licenses > > of binaries. > > I'm not really sure how you'd achieve this. Ask Jeff Johnston and/or RH legal. Newlib is maintained and hosted by RH. AFACT, the trick is: Newlib contains GPL'ed code in independent sub-packages, which is only used in certain configurations. In these configurations, the resulting binaries are GPL'ed, in all other cases, the resulting binaries do not use the [L]GPL'ed code, therefore the resulting binaries are not covered by the GPL. > And even if you did, you > could include the text of the "before" and "after" licenses in %doc. > > > b) There exist packages, where almost each source file carries a license > > of its own. > > > > As an exercise, I'd recommend you trying to package a Fedora->Cygwin > > cross toolchain. Binutils are GPL'ed, GCC is GPL'ed with exceptions, > > Cygwin libs are GPL'ed, newlib binaries are "BSD-like" with several > > dozens of different licenses, newlib sources are GPL'ed. > > This simply involves multiple files in %doc. I guess you are aware about the number of varieties of BSD'sh licenses? > Never said it was pretty in > the worst corner case, but its by no means impossible. The extremal case would be to copy the source tree, were a "BSD-compatible" would be sufficient otherwise. Not unlikely to happen with BSD derived code. > > > This is MUST item number 7 in the Things To Check On Review section in > > > the PackageReviewGuidelines: > > > http://fedoraproject.org/wiki/PackageReviewGuidelines#head-05a78c7ca440544397657679f87fbdbd84d9be28 > > > > > > This is not optional, this is the direction we're taking based on review > > > with Red Hat Legal. > > > > > > Fedora Core packagers: I don't have control over how you make your > > > packages (yet!) but you should also strongly consider doing this. > > Let me put it this way: > > > > If this legal requirement is as important as you seem to regard it, it > > would be legally grossly negligible to RH not to update their packages, > > ASAP. > > > > However, as RH, other Linux distributors and package vendors ship their > > packages without it for > 10 years, I am having strong doubts on FESCO > > decision rsp. RH-legal's advice and its importance. > > Your doubts are duly noted, but Red Hat legal advised us to take this > course of action, it was discussed by FESCO (not just me), and it was > decided as a must. Then let me put it a bit stronger: I think Red Hat Legal is in error and FESCO is not qualified to decide on this (Neither am I). Let me ask differently: Is FESCO or RH taking liability on consequences of this decision? > Basically, Red Hat wants us to cover all the bases legally in Extras, > and we're going to do it, even if it could end up being unnecessary in > the long run. As to whether it will happen in Core, I have no idea, and > no control over that whatsoever. > > If you (or anyone) comes across any complicated or difficult to decide > cases of licensing, then we'll deal with those cases at that time. For the moment, I have decided to suspend all Fedora activities, because all this seems way to risky to me. Ralf From wtogami at redhat.com Mon Sep 5 09:37:32 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 04 Sep 2005 23:37:32 -1000 Subject: License text in binary packages In-Reply-To: <1125892854.25892.41.camel@mccallum.corsepiu.local> References: <1125883479.11674.28.camel@localhost.localdomain> <1125892854.25892.41.camel@mccallum.corsepiu.local> Message-ID: <431C11DC.5010603@redhat.com> Ralf Corsepius wrote: > >>This is MUST item number 7 in the Things To Check On Review section in >>the PackageReviewGuidelines: >>http://fedoraproject.org/wiki/PackageReviewGuidelines#head-05a78c7ca440544397657679f87fbdbd84d9be28 >> >>This is not optional, this is the direction we're taking based on review >>with Red Hat Legal. >> >>Fedora Core packagers: I don't have control over how you make your >>packages (yet!) but you should also strongly consider doing this. > > Let me put it this way: > > If this legal requirement is as important as you seem to regard it, it > would be legally grossly negligible to RH not to update their packages, > ASAP. Ralf has an important point here. It is hypocritical to enforce this on Extras when legal hasn't mandated that Core or RHEL must follow this rule. > > However, as RH, other Linux distributors and package vendors ship their > packages without it for > 10 years, I am having strong doubts on FESCO > decision rsp. RH-legal's advice and its importance. FESCO (and everyone here) is unqualified to make legal opinions, and I really wonder if legal considered all information carefully when making this recommendation. Perhaps the recommendation was made in haste because they are normally very busy. I don't know the details of what happened. I personally think it is insane to necessitate the license in every single package (especially with perl packages, Artistic?). I personally would want to see more clarification before forcing such an onerous change upon everything. The biggest problem of this FESCO mandate however is "Follow what I say, but not what I do." Does nobody else see this as a horribly hypocritical? If Red Hat is serious about enforcing this rule, then first mandate it on Core to lead by example. Then everyone is forced to discuss the technical annoyances like below: How are we supposed to deal with cases where the source did not ship a full copy of the license in order to add to %doc easily? We are supposed to add another copy of the license to each SRPM? If clarification does confirm this requirement, then we should seriously re-explore the license file consolidation question again. It is stupid to ship 1000 copies of the GPL and other standard licenses and there are better ways we could do this. We could have versioned standard licenses somewhere (and maybe with RPM virtual-provides to ensure that they are actually installed.) /path/to/somewhere/GPLv2 (for GPL v2 only) /path/to/somewhere/LGPLv2 /path/to/somewhere/GPL-newest (for GPL v2 or newer) /path/to/somewhere/...other standard licenses Also... what is Debian's policy about all this? DISCLAIMER: Views expressed here are of Warren Togami as an individual and not reflective of views of the project or company. Warren Togami wtogami at redhat.com From sundaram at redhat.com Mon Sep 5 09:55:47 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 05 Sep 2005 15:25:47 +0530 Subject: License text in binary packages In-Reply-To: <431C11DC.5010603@redhat.com> References: <1125883479.11674.28.camel@localhost.localdomain> <1125892854.25892.41.camel@mccallum.corsepiu.local> <431C11DC.5010603@redhat.com> Message-ID: <431C1623.6070006@redhat.com> Hi > > > /path/to/somewhere/GPLv2 (for GPL v2 only) > /path/to/somewhere/LGPLv2 > /path/to/somewhere/GPL-newest (for GPL v2 or newer) > /path/to/somewhere/...other standard licenses > > Also... what is Debian's policy about all this? Debian has /usr/share/common-licenses/ and every package has a copyright file which points to this regards Rahul From bugs.michael at gmx.net Mon Sep 5 11:13:37 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 5 Sep 2005 13:13:37 +0200 Subject: License text in binary packages In-Reply-To: <431C11DC.5010603@redhat.com> References: <1125883479.11674.28.camel@localhost.localdomain> <1125892854.25892.41.camel@mccallum.corsepiu.local> <431C11DC.5010603@redhat.com> Message-ID: <20050905131337.1fd9c1bc.bugs.michael@gmx.net> On Sun, 04 Sep 2005 23:37:32 -1000, Warren Togami wrote: > Ralf Corsepius wrote: > > If this legal requirement is as important as you seem to regard it, it > > would be legally grossly negligible to RH not to update their packages, > > ASAP. > > Ralf has an important point here. It is hypocritical to enforce this on > Extras when legal hasn't mandated that Core or RHEL must follow this rule. > > > > > However, as RH, other Linux distributors and package vendors ship their > > packages without it for > 10 years, I am having strong doubts on FESCO > > decision rsp. RH-legal's advice and its importance. > > FESCO (and everyone here) is unqualified to make legal opinions, and I > really wonder if legal considered all information carefully when making > this recommendation. Perhaps the recommendation was made in haste > because they are normally very busy. I don't know the details of what > happened. "Haste" sounds about right. Going back in the list archives, it looks like Legal was asked about GNU GPL, not about any other MIT/BSD/whatever Open Source licencing mix that's out there. More often than any other licence, the GPL document is missing within source tarballs. Further, the general "yes" to "inclusion of licence documents in binary packages" refers to any source tarballs which include such licence files. I completely agree with Ralf that it would not be feasible or legally correct for packagers to create such licence files themselves in any cases where no such files exist already. It would mean that packagers would need to verify whether the licence chosen by the upstream developers is really accurate/legal/compliant with all their source files and derived work. > Does nobody else see this as a horribly hypocritical? If Red Hat is > serious about enforcing this rule, then first mandate it on Core to lead > by example. +1 > Then everyone is forced to discuss the technical annoyances > like below: > > How are we supposed to deal with cases where the source did not ship a > full copy of the license in order to add to %doc easily? We are > supposed to add another copy of the license to each SRPM? Do we have examples for this? (other than a missing GPL "COPYING" file) From rc040203 at freenet.de Mon Sep 5 11:22:28 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 05 Sep 2005 13:22:28 +0200 Subject: License text in binary packages In-Reply-To: <431C11DC.5010603@redhat.com> References: <1125883479.11674.28.camel@localhost.localdomain> <1125892854.25892.41.camel@mccallum.corsepiu.local> <431C11DC.5010603@redhat.com> Message-ID: <1125919348.25892.85.camel@mccallum.corsepiu.local> On Sun, 2005-09-04 at 23:37 -1000, Warren Togami wrote: > Ralf Corsepius wrote: > Does nobody else see this as a horribly hypocritical? If Red Hat is > serious about enforcing this rule, then first mandate it on Core to lead > by example. Exactly, to me all this sounds like FESCO and RH are implementing "double standards". Also, to me, it sounds untrustworthy to hear common practice (I.e. not to _add_ explicit license files) having been practiced for more than a decade, out of a sudden should be treated illegal. Guess what I would do now, if I were SCO ;) > Then everyone is forced to discuss the technical annoyances > like below: > > How are we supposed to deal with cases where the source did not ship a > full copy of the license in order to add to %doc easily? IMO, no. > We are supposed to add another copy of the license to each SRPM? I.e. IMHO, we must ship license files, if the sources do. If the sources don't ship license files, we don't have to. Apparently, RH-legal's opinion seems to be different. > Also... what is Debian's policy about all this? Cf. http://www.debian.org/doc/debian-policy/ch-archive.html#s-pkgcopyright Also see: http://ftp.novell.com/pub/forge/library/SUSE%20Package%20Conventions/spc.html [The don't even mention it; Also see their perl template] Ralf From paul at city-fan.org Mon Sep 5 11:33:40 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 05 Sep 2005 12:33:40 +0100 Subject: License text in binary packages In-Reply-To: <20050905131337.1fd9c1bc.bugs.michael@gmx.net> References: <1125883479.11674.28.camel@localhost.localdomain> <1125892854.25892.41.camel@mccallum.corsepiu.local> <431C11DC.5010603@redhat.com> <20050905131337.1fd9c1bc.bugs.michael@gmx.net> Message-ID: <431C2D14.7030800@city-fan.org> Michael Schwendt wrote: > On Sun, 04 Sep 2005 23:37:32 -1000, Warren Togami wrote: >>Does nobody else see this as a horribly hypocritical? If Red Hat is >>serious about enforcing this rule, then first mandate it on Core to lead >>by example. > > > +1 Me too >>Then everyone is forced to discuss the technical annoyances >>like below: >> >>How are we supposed to deal with cases where the source did not ship a >>full copy of the license in order to add to %doc easily? We are >>supposed to add another copy of the license to each SRPM? > > > Do we have examples for this? (other than a missing GPL "COPYING" file) It's very common for both the GPL and Artistic license texts not to be shipped with perl modules that use the same license as perl (i.e. dual GPL/Artistic). Paul. From jpo at di.uminho.pt Mon Sep 5 15:16:48 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Mon, 05 Sep 2005 16:16:48 +0100 Subject: License text in binary packages In-Reply-To: <431C2D14.7030800@city-fan.org> References: <1125883479.11674.28.camel@localhost.localdomain> <1125892854.25892.41.camel@mccallum.corsepiu.local> <431C11DC.5010603@redhat.com> <20050905131337.1fd9c1bc.bugs.michael@gmx.net> <431C2D14.7030800@city-fan.org> Message-ID: <431C6160.4060904@di.uminho.pt> Paul Howarth wrote: > Michael Schwendt wrote: > >> On Sun, 04 Sep 2005 23:37:32 -1000, Warren Togami wrote: >> >>> Does nobody else see this as a horribly hypocritical? If Red Hat is >>> serious about enforcing this rule, then first mandate it on Core to >>> lead by example. >> >> >> >> +1 > > > > Me too > > >>> Then everyone is forced to discuss the technical annoyances like below: >>> >>> How are we supposed to deal with cases where the source did not ship >>> a full copy of the license in order to add to %doc easily? We are >>> supposed to add another copy of the license to each SRPM? >> >> >> >> Do we have examples for this? (other than a missing GPL "COPYING" file) > > > It's very common for both the GPL and Artistic license texts not to be > shipped with perl modules that use the same license as perl (i.e. dual > GPL/Artistic). > You may also add LaTeX packages from CTAN: most of them are licensed under the LPPL (LaTeX Project Public License) but usually don't include the full text of the license . I think this may extended to all (?) comprehensive mirror systems: * CPAN - Comprehensive Perl Archive Network http://www.cpan.org/ * CTAN - Comprehensive TeX Archive Network http://www.ctan.org/ * CRAN - Comprehensive R Archive Network http://cran.r-project.org/ * ... jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From toshio at tiki-lounge.com Mon Sep 5 16:34:34 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 05 Sep 2005 09:34:34 -0700 Subject: License text in binary packages In-Reply-To: <20050905131337.1fd9c1bc.bugs.michael@gmx.net> References: <1125883479.11674.28.camel@localhost.localdomain> <1125892854.25892.41.camel@mccallum.corsepiu.local> <431C11DC.5010603@redhat.com> <20050905131337.1fd9c1bc.bugs.michael@gmx.net> Message-ID: <1125938075.12092.25.camel@localhost> On Mon, 2005-09-05 at 13:13 +0200, Michael Schwendt wrote: > On Sun, 04 Sep 2005 23:37:32 -1000, Warren Togami wrote: > > > > How are we supposed to deal with cases where the source did not ship a > > full copy of the license in order to add to %doc easily? We are > > supposed to add another copy of the license to each SRPM? > > Do we have examples for this? (other than a missing GPL "COPYING" file) I just imported a LICENSE for pexpect. The license is The Python Software Foundation license. When I did this, I was a bit confused. Unlike the GPL, the PSF explicitly names "python" as "the software". Would the license need to have every instance of python changed to pexpect? Would this be "relicensing"? foremost, which I posted about to fedora-extras earlier is GPL. But due to its history as a work created by the US Government it was listed as Public Domain [1] in some places. After exploring with upstream, it was discovered that most of the "GPL" work done on foremost was also US Government work and therefore Public Domain [1]. The project had included one file from another, GPL, project so the FSF analysis still applied. So in this case, the license file was missing and it was decidedly non-obvious for a packager how the package should be licensed. If I had included one license with upstream's blessing but it turned out that they didn't have the right to use that license, who's at fault? I think the "packagers adding a LICENSE file" policy needs to be looked over and questions about it need to be FAQ'd. -Toshio [1] The original author of foremost believes that US Government work _cannot_ be copyrighted (unless authorized by Congress). So it isn't simply public domain, it's perpetually public domain. That's why the FSF advises that code contributed by US Federal Government employees to GPL projects is contributed as public domain. Here's the relevant section of the United States Code: 17 USC 105. Subject matter of copyright: United States Government works Copyright protection under this title is not available for any work of the United States Government, but the United States Government is not precluded from receiving and holding copyrights transferred to it by assignment, bequest, or otherwise. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Mon Sep 5 18:02:53 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 05 Sep 2005 13:02:53 -0500 Subject: License text in binary packages In-Reply-To: <1125899841.25892.61.camel@mccallum.corsepiu.local> References: <1125883479.11674.28.camel@localhost.localdomain> <1125892854.25892.41.camel@mccallum.corsepiu.local> <1125895111.11674.39.camel@localhost.localdomain> <1125899841.25892.61.camel@mccallum.corsepiu.local> Message-ID: <1125943373.11674.79.camel@localhost.localdomain> On Mon, 2005-09-05 at 07:57 +0200, Ralf Corsepius wrote: > Then let me put it a bit stronger: I think Red Hat Legal is in error and > FESCO is not qualified to decide on this (Neither am I). > > Let me ask differently: Is FESCO or RH taking liability on consequences > of this decision? In the FESCO meeting (now two weeks past), I discussed the finding of RH Legal that GPL packages should include the text of the GPL license. I also stated that I thought it would be prohibitive to send every single possible license to RH Legal for review. Based on that, I proposed that all packages include the license text(s) that are relevant to them in % doc, which has been the policy since the first draft of the PackagingGuidelines. This proposal was passed in the meeting. It is now apparent to me that we require more legal clarification on specific questions. I've requested that Red Hat Legal answer the following questions: 1. In the specific case of the GPL, should Fedora Extras be including the license text as part of the binary package? 2. In the case of all other licenses, should Fedora Extras be including the license text as part of the binary package? 3. If the answer to either of those questions is yes, then please explain why Red Hat has not ever required these practices in RHEL or Fedora Core packages. 4. If the answer to either of those questions is yes, then please advise us on how we should include license texts for software packages which do not include the license text with the source distribution. Should these programs be exempt from such practices, or is it the responsibility of the packager to include the license text as a second source? 5. Is Red Hat taking legal liability for the consequences of these practices, including the possibility of mistakenly including a license text which does not match the upstream source? Or does this liability fall onto the individual packager? Hopefully, Red Hat Legal will look at these questions on Tuesday, and get us some answers as soon as possible. Based on those answers, FESCO will re-evaluate this policy. Until then, I ask for everyone's patience, and to try to keep your flames to a minimum. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From smooge at gmail.com Mon Sep 5 20:39:52 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Mon, 5 Sep 2005 14:39:52 -0600 Subject: License text in binary packages In-Reply-To: <1125938075.12092.25.camel@localhost> References: <1125883479.11674.28.camel@localhost.localdomain> <1125892854.25892.41.camel@mccallum.corsepiu.local> <431C11DC.5010603@redhat.com> <20050905131337.1fd9c1bc.bugs.michael@gmx.net> <1125938075.12092.25.camel@localhost> Message-ID: <80d7e40905090513397b2e1005@mail.gmail.com> On 9/5/05, Toshio Kuratomi wrote: > On Mon, 2005-09-05 at 13:13 +0200, Michael Schwendt wrote: > > On Sun, 04 Sep 2005 23:37:32 -1000, Warren Togami wrote: > > > > > > How are we supposed to deal with cases where the source did not ship a > > > full copy of the license in order to add to %doc easily? We are > > > supposed to add another copy of the license to each SRPM? > > > > Do we have examples for this? (other than a missing GPL "COPYING" file) > > I just imported a LICENSE for pexpect. The license is The Python > Software Foundation license. When I did this, I was a bit confused. > Unlike the GPL, the PSF explicitly names "python" as "the software". > Would the license need to have every instance of python changed to > pexpect? Would this be "relicensing"? > > foremost, which I posted about to fedora-extras earlier is GPL. But due > to its history as a work created by the US Government it was listed as > Public Domain [1] in some places. After exploring with upstream, it was > discovered that most of the "GPL" work done on foremost was also US > Government work and therefore Public Domain [1]. The project had > included one file from another, GPL, project so the FSF analysis still > applied. So in this case, the license file was missing and it was > decidedly non-obvious for a packager how the package should be licensed. > If I had included one license with upstream's blessing but it turned out > that they didn't have the right to use that license, who's at fault? I would get a Fedora Legal written opinion on this, but from what code I deal with from the U.S. Government.. these codes are always in the Public Domain and could not be put under any license/copyright without explicite permission from Congress. Like all things legal.. it would be up to a court to decide who was at fault for wrongly licensing a set of software. -- Stephen J Smoogen. CSIRT/Linux System Administrator From jpo at di.uminho.pt Mon Sep 12 15:57:13 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Mon, 12 Sep 2005 16:57:13 +0100 Subject: Build system: devel builds are failing Message-ID: <4325A559.1010702@di.uminho.pt> Hi, All the devel builds are failing with the following error: ---------- .... /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core-796239199aa845c03247b22ed4bc22d56a87f245/root groupinstall build file:///pub/fedora/linux/core/development/i386/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. Error: failure: repodata/primary.xml.gz from core: [Errno 256] No more mirrors to try. Cleaning up... ---------- Could someone check the repo status? TIA, jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From paul at city-fan.org Mon Sep 12 16:04:49 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 12 Sep 2005 17:04:49 +0100 Subject: Build system: devel builds are failing In-Reply-To: <4325A559.1010702@di.uminho.pt> References: <4325A559.1010702@di.uminho.pt> Message-ID: <4325A721.5070203@city-fan.org> Jos? Pedro Oliveira wrote: > Hi, > > All the devel builds are failing with the following error: > > ---------- > .... > /usr/sbin/mock-helper yum --installroot > /var/lib/mock/fedora-development-i386-core-796239199aa845c03247b22ed4bc22d56a87f245/root > groupinstall build > file:///pub/fedora/linux/core/development/i386/repodata/primary.xml.gz: > [Errno -1] Metadata file does not match checksum > Trying other mirror. > Error: failure: repodata/primary.xml.gz from core: [Errno 256] No more > mirrors to try. > Cleaning up... > ---------- > > Could someone check the repo status? I'm getting that for development mock builds locally too. I had to manually create new repodata and it still didn't work because of sqlite dependency issues: /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core/root groupinstall build Error: Missing Dependency: libsqlite3.so.0 is needed by package rpm-build Error: Missing Dependency: libsqlite3.so.0 is needed by package rpm Error: Missing Dependency: libsqlite3.so.0 is needed by package rpm-libs Paul. From jspaleta at gmail.com Mon Sep 12 16:21:20 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 12 Sep 2005 12:21:20 -0400 Subject: Build system: devel builds are failing In-Reply-To: <4325A559.1010702@di.uminho.pt> References: <4325A559.1010702@di.uminho.pt> Message-ID: <604aa79105091209212a84db9d@mail.gmail.com> On 9/12/05, Jos? Pedro Oliveira wrote: > Hi, > > All the devel builds are failing with the following error: side effect of yesterday's rawhide "confusion". Today's rawhide tree just got pushed and it looks like today's repodata is self-consistent for the i386 tree atleast. So i suggest you give it a few hours to propogate to mirrors and try doing builds again then. -jef From jpo at di.uminho.pt Mon Sep 12 16:34:13 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Mon, 12 Sep 2005 17:34:13 +0100 Subject: Build system: devel builds are failing In-Reply-To: <604aa79105091209212a84db9d@mail.gmail.com> References: <4325A559.1010702@di.uminho.pt> <604aa79105091209212a84db9d@mail.gmail.com> Message-ID: <4325AE05.6050300@di.uminho.pt> Jeff, The build system is working again: I just managed to get two noarch packages built. Thanks, jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From tcallawa at redhat.com Wed Sep 14 19:55:14 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 14 Sep 2005 14:55:14 -0500 Subject: Updated policy for licensing texts Message-ID: <1126727714.2957.27.camel@localhost.localdomain> While we are still waiting for Red Hat Legal to return specific answers on the licensing legal questions, I proposed a policy change in the interim to FESCO. This change was announced (and approved) during the FESCO meeting on September 8th, and revised by FESCO from then until now. The new policy is as follows: - Any package which includes a license text(s) in its own file from upstream MUST include that as %doc. (Note that this only covers license text(s) that appear in a text document, not situations where the license text is only embedded in source files. In those situations, you do not need to include source files as %doc) - If the package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. - Packagers are no longer required to add any license files which are not included from upstream. If you have already done this for your package(s), then you are not required to undo this, but can, at your discretion. The PackageReviewGuidelines have been updated to reflect this change in policy. Questions or comments are welcome. Thanks, ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From kwade at redhat.com Thu Sep 15 23:45:14 2005 From: kwade at redhat.com (Karsten Wade) Date: Thu, 15 Sep 2005 16:45:14 -0700 Subject: Release Notes - A New Era Message-ID: <1126827914.27149.202.camel@erato.phig.org> It's time to start gathering notes for FC5 test1 and final release notes. There are some very good changes and additions to the process, to make participation easier. There are also some new things that you, as developers, must do. Highlights: * Wiki used to gather notes, - not just bugzilla! * Using *docs* keyword in CVS commit logs - new magic from Elliot! * Translations of relnotes included in fedora-release package * Sub-projects responsible for supplying a beat writer - You can coerce them, you can hijack them, but you have no content in the relnotes without them http://fedoraproject.org/wiki/Docs/Beats/HowTo covers much of this same material. Don't know what the relnotes beats are? http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Beats * Changes * ** Wiki Used to Gather Notes ** Beat writers are now able to use the tree at http://fedoraproject.org/wiki/Docs/Beats to gather raw input and form it into content for the release notes. These pages have a light structure that generally goes one layer deep, for example, Docs/Beats/Kernel is for the kernel portion of the release notes. This maps nicely to one
or in XML. Beat writers are free to add and change sub-pages, as they need. Other contributors can do the same. The only requirement to edit is that the user be registered and logged in. These beat notes are ongoing workspaces. A snapshot is taken just prior to freeze for translation, and the content is merged into the overall DocBook/XML-based release notes. These XML release notes are canonical, but necessarily behind the raw Wiki pages. Beat writers need to keep the content cleaned-up and relevant. You want to watch your page and all sub-pages using the pattern Docs/Beats/Beatname.* in your "Subscribed wiki pages" of your UserPreferences. Wiki-help for beat contributions is on-topic for #fedora-docs. ** Highlighting Your CVS Commit for Documentation ** The next time that you make a CVS commit that fulfills a feature, fixes a bug, or otherwise is worth noting in the relnotes, try this trick. Put the keyword *docs* in the commit log message, and a copy of the commit is sent to relnotes at fedoraproject.org . The beat writers and editors parse the note into the proper place, or open a bugzilla report to track the note suggestion. This is a must-do for Core packages, look for opportunities. Extras packages are encouraged to use this at milestone events, etc. This page tells more about what to highlight for *docs*: http://fedoraproject.org/wiki/DocsProject/WhatToDocument ** Use Bugzilla to Highlight an Existing Report ** Just add relnotes at fedoraproject.org to the Cc: field. We'll parse this into the proper place. ** File a Bug Report ** This small URL is for a pre-filled bugzilla report. This is a great way to submit a note or idea for the release notes, since conversations and solutions are logged. Bugs are set to block a master tracker for the release. http://tinyurl.com/89dkk ** Translations With Release ** The schedule for the release notes now includes time for translation, so that the translated content can appear within the fedora-release package. At the top of the shipping release notes is a prominent link to the latest online version of the relnotes. This helps to counter the problem of having to freeze the release notes so long before test and release. We'll do a Web-launch of a latest set of release notes to time with the distro releases. * New For Developers * You are responsible within your Fedora sub-project to produce content for the FC release notes. Someone from your team needs to step-up and take the role of beat writer, or find someone interested in helping your project to take that role. Being a beat writer is a _fantastic_ and reasonable way to get involved with an open source project. It's designed to be bite-sized for the average volunteer. Ultimately, the amount and quality of content in the release notes is your responsibility. The FDP takes all the rest of the responsibility -- merge, edit, convert to XML, get translated, build multiple output formats, package for fedora-release, publish to Web, make downloads available, and support with ongoing updates as needed. ** Deadline to Pick Beat Writer ** By 23 September, all sub-projects need to have picked the person who is the beat writer for your part of the release notes. This is effective for FC5 and forward. In other words, a beat may be handed-off, it may not be abandoned. Cheers - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From petersen at redhat.com Wed Sep 21 05:44:13 2005 From: petersen at redhat.com (Jens Petersen) Date: Wed, 21 Sep 2005 14:44:13 +0900 Subject: extras development x86_64 builds failing Message-ID: <4330F32D.9050204@redhat.com> Hi, Builds are failing on development/x86_64 in the extras buildsystem. Not sure from here if it is rawhide breakage, broken yum repo or something wrong on the buildserver... Jens From fedora at leemhuis.info Wed Sep 21 06:01:24 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 21 Sep 2005 08:01:24 +0200 Subject: extras development x86_64 builds failing In-Reply-To: <4330F32D.9050204@redhat.com> References: <4330F32D.9050204@redhat.com> Message-ID: <1127282484.3224.8.camel@thl.ct.heise.de> Am Mittwoch, den 21.09.2005, 14:44 +0900 schrieb Jens Petersen: > Builds are failing on development/x86_64 in the extras buildsystem. > Not sure from here if it is rawhide breakage, broken yum repo or something wrong > on the buildserver... https://www.redhat.com/archives/fedora-extras-list/2005-September/msg01223.html Quote: > From: Jeremy Katz >[...] > The libsetrans package in rawhide today is busted. The tarball was > created with the binaries included and so they didn't get rebuilt on > every arch. Dan is fixing now (so it should be resolved after > tomorrow's rawhide push) HTH CU thl From katzj at redhat.com Wed Sep 21 14:21:27 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 21 Sep 2005 10:21:27 -0400 Subject: extras development x86_64 builds failing In-Reply-To: <1127282484.3224.8.camel@thl.ct.heise.de> References: <4330F32D.9050204@redhat.com> <1127282484.3224.8.camel@thl.ct.heise.de> Message-ID: <1127312487.11121.22.camel@bree.local.net> On Wed, 2005-09-21 at 08:01 +0200, Thorsten Leemhuis wrote: > Am Mittwoch, den 21.09.2005, 14:44 +0900 schrieb Jens Petersen: > > From: Jeremy Katz > >[...] > > The libsetrans package in rawhide today is busted. The tarball was > > created with the binaries included and so they didn't get rebuilt on > > every arch. Dan is fixing now (so it should be resolved after > > tomorrow's rawhide push) And this is fixed now. Jeremy From uwog at uwog.net Sun Sep 25 20:52:31 2005 From: uwog at uwog.net (J.M. Maurer) Date: Sun, 25 Sep 2005 22:52:31 +0200 Subject: New packages policy Message-ID: <1127681551.3450.47.camel@localhost.localdomain> Recently I added several packages to Extras devel after going through the 'formal' procedure to add new packages. I'd like to see several of those packages in FC-4 extras as well (specifically gtkmathview and link-grammar, as they will be a dependency for AbiWord 2.4). Does the approval I got for Extras devel hold for FC-4 Extras as well? Cheers, Marc PS. Maybe it's a good idea to add this to the Wiki as well (if it isn't already there and I just missed it). From tcallawa at redhat.com Sun Sep 25 21:21:33 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 25 Sep 2005 16:21:33 -0500 Subject: New packages policy In-Reply-To: <1127681551.3450.47.camel@localhost.localdomain> References: <1127681551.3450.47.camel@localhost.localdomain> Message-ID: <1127683293.2481.162.camel@localhost.localdomain> On Sun, 2005-09-25 at 22:52 +0200, J.M. Maurer wrote: > Recently I added several packages to Extras devel after going through > the 'formal' procedure to add new packages. > > I'd like to see several of those packages in FC-4 extras as well > (specifically gtkmathview and link-grammar, as they will be a dependency > for AbiWord 2.4). Does the approval I got for Extras devel hold for FC-4 > Extras as well? > > Cheers, > Marc > > PS. Maybe it's a good idea to add this to the Wiki as well (if it isn't > already there and I just missed it). Yes, you just need to request branches for FC-4 (and FC-3 if you want it). I'll try to make that clearer on the wiki. :) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tibbs at math.uh.edu Thu Sep 29 14:31:45 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 29 Sep 2005 09:31:45 -0500 Subject: Handling mandatory config file updates Message-ID: I maintain a package (denyhosts) for which I would like to push an update. Unfortunately the new version requires changes to the configuration file. The syntax hasn't changed, but one setting was renamed and several mandatory ones have been added. If the changes aren't made, the daemon won't start properly. So, do I: 1) Tag a fresh config file as %config instead of %config(noreplace) so that the updated package will at least start but will require operator intervention to return to previous behavior. (Assuming the admin notices the change in behavior.) 2) Attempt to fix up the configuration in %post and hope I don't mangle something. 3) Do nothing and hope the admin notices the error messages when the daemon restarts. - J< From nphilipp at redhat.com Thu Sep 29 15:32:23 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 29 Sep 2005 17:32:23 +0200 Subject: Handling mandatory config file updates In-Reply-To: References: Message-ID: <1128007943.6688.13.camel@wombat.tiptoe.de> On Thu, 2005-09-29 at 09:31 -0500, Jason L Tibbitts III wrote: > I maintain a package (denyhosts) for which I would like to push an > update. Unfortunately the new version requires changes to the > configuration file. The syntax hasn't changed, but one setting was > renamed and several mandatory ones have been added. If the changes > aren't made, the daemon won't start properly. > > So, do I: > > 1) Tag a fresh config file as %config instead of %config(noreplace) so > that the updated package will at least start but will require > operator intervention to return to previous behavior. (Assuming > the admin notices the change in behavior.) > > 2) Attempt to fix up the configuration in %post and hope I don't > mangle something. > > 3) Do nothing and hope the admin notices the error messages when the > daemon restarts. 4) Build new package only in devel and mention the change in FC5 release notes? Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From tibbs at math.uh.edu Thu Sep 29 16:05:39 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 29 Sep 2005 11:05:39 -0500 Subject: Handling mandatory config file updates In-Reply-To: <1128007943.6688.13.camel@wombat.tiptoe.de> (Nils Philippsen's message of "Thu, 29 Sep 2005 17:32:23 +0200") References: <1128007943.6688.13.camel@wombat.tiptoe.de> Message-ID: >>>>> "NP" == Nils Philippsen writes: NP> 4) Build new package only in devel and mention the change in FC5 NP> release notes? Which is where things are at now, but as I mentioned, I'd like to push an update if possible. (It's no big deal if its not possible, but users have asked me about it.) I suppose your answer implies what Red Hat would do in this situation were the package in Core; are the strictures different for Extras? - J< From ville.skytta at iki.fi Thu Sep 29 17:36:58 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 29 Sep 2005 20:36:58 +0300 Subject: Handling mandatory config file updates In-Reply-To: <1128007943.6688.13.camel@wombat.tiptoe.de> References: <1128007943.6688.13.camel@wombat.tiptoe.de> Message-ID: <1128015418.2458.4.camel@localhost.localdomain> On Thu, 2005-09-29 at 17:32 +0200, Nils Philippsen wrote: > On Thu, 2005-09-29 at 09:31 -0500, Jason L Tibbitts III wrote: > > > > 1) Tag a fresh config file as %config instead of %config(noreplace) so > > that the updated package will at least start but will require > > operator intervention to return to previous behavior. (Assuming > > the admin notices the change in behavior.) > > > > 2) Attempt to fix up the configuration in %post and hope I don't > > mangle something. > > > > 3) Do nothing and hope the admin notices the error messages when the > > daemon restarts. > > 4) Build new package only in devel and mention the change in FC5 release > notes? Personally, I'd go for 1) and 4) and whine upstream, asking them to take backwards compatibility issues better into account between releases. Also, dunno if there will be release notes for FE. From nphilipp at redhat.com Thu Sep 29 19:52:10 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 29 Sep 2005 21:52:10 +0200 Subject: Handling mandatory config file updates In-Reply-To: <1128015418.2458.4.camel@localhost.localdomain> References: <1128007943.6688.13.camel@wombat.tiptoe.de> <1128015418.2458.4.camel@localhost.localdomain> Message-ID: <1128023531.28843.9.camel@gibraltar.stuttgart.redhat.com> On Thu, 2005-09-29 at 20:36 +0300, Ville Skytt? wrote: > Also, dunno if there will be release notes for FE. That's a valid point. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011