On 08/01/2013 03:32 AM, Stephen Nelson wrote: > On Thu, Aug 1, 2013 at 12:35 AM, Emmanuel Bourg <ebourg@apache.org> wrote: >> >> You can't depend on the version in stable, the goal is to build a set of >> packages that work together. You can't rely on an older revision of a >> package that is no longer available in the current distribution. >> > > Thanks for clarifying - that makes more sense than how I had > originally understood packaging. > >> The solution is to patch the tomcat6 package. You can look at the >> commons-jci and jasperreports packages which were also affected by this >> issue. The patch is trivial, and that's a good opportunity to learn quilt :) >> >> This issue has also been fixed upstream, so upgrading the package to the >> version 6.0.37 might be an alternative. >> >> https://issues.apache.org/bugzilla/show_bug.cgi?id=54615 >> > Thanks for the info Emmanuel . I notice there are a number of patches > already in the package, so presumably if I were to upgrade the package > I would need to determine if those patches had already been applied > upstream? If so I think in this case to avoid making huge mistakes I'd > prefer to patch what is already there and then look into upgrading it > at a later stage. I will also contact the regular maintainer to check > I'm not duplicating effort. Hi Stephen, Yes, the procedure for a new tomcat release is to generate the new orig.tar.gz, import it using git-import-orig, and then determine which of the debian/patches can be dropped. Typically it's not that difficult to figure out because the patches are normally just those cherry-picked directly from the upstream SVN to address CVEs. Also note that 6.0.36 has already been imported, but I think we can skip that and go straight to 6.0.37. In the case of tomcat6, in case you're not already aware, the Debian Security Team has asked us to drop tomcat6 from Jessie since tomcat7 is available and the the additional effort required to manage DSAs over the lifetime of the release. That said, I feel like there is still a user community for tomcat6. At a minimum, we could keep the packaging current in the packaging repo on Alioth and possibly setup a PPA-like mechanism. Or, perhaps it would be permissible to block tomcat6 from migrating to testing but to keep tomcat6 in unstable (only). I just wanted you to be aware of that. First things first - if you're interested in helping to maintain tomcat6, that's great! If you're completely new to the process, please review the Java Packaging Project page [1] and the wiki [2]. I'm going to take this opportunity to propose what I hope is a light-weight process for coordination amongst team members. I believe I've set a poor precedent in the past by simply jumping in and uploading team-maintained packages for which I'm not listed as an uploader. This isn't a problem provided that the other uploaders aren't that active, but a few times it has resulted in duplicated effort. Therefore, I've been thinking that the general workflow should be something like: 1) Mail either the debian-java list or the current list of Uploaders indicating that you're ready and willing to work on a package. Allow up to a week for a response before continuing on to (2). 2) Add yourself to Uploaders and upload or post an RFS. 3) Stay in contact with other Uploaders and/or the list for subsequent updates. I'm thinking about adding these as general guidelines to the "Maintainer: Debian Java maintainers" line on [1]. Suggestions or concerns? Cheers, tony [1] http://pkg-java.alioth.debian.org/ [2] https://wiki.debian.org/Teams/JavaPackaging
Attachment:
signature.asc
Description: OpenPGP digital signature