Re: please use release tarballs :-)
On Mittwoch, 3. September 2003 00:00, Chris Cheney wrote: > On Tue, Sep 02, 2003 at 11:09:55PM +0200, Ralf Nolden wrote: > Content-Description: signed data > > > Hi, > > > > FYI, while communicating with Matt Zimmerman a couple of weeks back on > > security issues for KDE (that the woody debs on kde.org have those fixed > > as well - Martin Schulze included that info while he was doing that) we > > were discussing things like that the KDE packages in sid are made from > > CVS checkouts rather than from the original release tarballs. Matt would > > prefer to get them build from the release tarballs with patchsets against > > CVS if you need them - however, this is none of my business so you might > > want to check with Matt how to proceed with your next upload as that's > > probably the last chance to do it the way the security team would like to > > have things done for sarge. > > For one thing, we always need the updates from branch, KDE is > notoriously buggy, just look at the bug list sometime ;). However, the > orig.tar.gz in 99% of the cases is the KDE_3_1_X_RELEASE export minus all > the autocrap and CVS dir crap that upstream ships in their tarballs. If > debian f*cking supported decent change support, not just text diff then > this could be 100% the case. Sometimes binary files change (eg png's) and > in those cases I have to stuff them in orig.tar.gz since going through the > uuencode/etc process is a REALLY BIG PITA. The resulting diff.gz that is I know that also. The java stuff contains binaries as well, so this was kind of hard to track down if you update from the branch. At least I try to use the release tarballs in my woody builds which worked quite ok for 3.1.3 and I guess 3.1.4 will be smooth as well. I wonder why the CVS dirs are not supported though; they contain the release tag and even if you'd update from CVS or use the branch the security team could track down the information by the revision number that your orig.tar.gz would ship in the CVS dirs. > > I will never ship pristine upstream tarballs due to the CVS dir issue > which Debian officially doesn't want either... so its a no win situation, > someone in Debian will always be bitching. I know :-( > > Chris > > BTW - I make it a habit to never fix things directly in the diff.gz, if > needed I make debian specific changes and then create diffs for them in > the debian/patches dir. That's what I meant. -- We're not a company, we just produce better code at less costs. Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org pgpAerYafuGeN.pgp Description: signature
Re: please use release tarballs :-)
On Tue, Sep 02, 2003 at 11:09:55PM +0200, Ralf Nolden wrote: Content-Description: signed data > Hi, > > FYI, while communicating with Matt Zimmerman a couple of weeks back on > security issues for KDE (that the woody debs on kde.org have those fixed as > well - Martin Schulze included that info while he was doing that) we were > discussing things like that the KDE packages in sid are made from CVS > checkouts rather than from the original release tarballs. Matt would prefer > to get them build from the release tarballs with patchsets against CVS if you > need them - however, this is none of my business so you might want to check > with Matt how to proceed with your next upload as that's probably the last > chance to do it the way the security team would like to have things done for > sarge. For one thing, we always need the updates from branch, KDE is notoriously buggy, just look at the bug list sometime ;). However, the orig.tar.gz in 99% of the cases is the KDE_3_1_X_RELEASE export minus all the autocrap and CVS dir crap that upstream ships in their tarballs. If debian f*cking supported decent change support, not just text diff then this could be 100% the case. Sometimes binary files change (eg png's) and in those cases I have to stuff them in orig.tar.gz since going through the uuencode/etc process is a REALLY BIG PITA. The resulting diff.gz that is built for uploads includes KDE_3_1_BRANCH (minus binary stuff) since the last release plus the autocrap. A new security release shouldn't be very hard to do for KDE 3 since you would just need to do a current KDE_3_1_BRANCH export and build it. I will never ship pristine upstream tarballs due to the CVS dir issue which Debian officially doesn't want either... so its a no win situation, someone in Debian will always be bitching. > I know making patchsets for every change requires a lot of time and effort but > you should seriously think about doing it; it will ensure more quality > control and give the security team a better base in case they will receive > security patches from KDE - again this is my personal opinion, I'm not a > debian developer yet that I could do this on my own but I would be willing to > help there. In future releases I can provide the diff.gz for security releases if wanted. I didn't provide them on 2.2 releases since I didn't maintain KDE during that time (not really anyway) and the build system was a mess, etc. Chris BTW - I make it a habit to never fix things directly in the diff.gz, if needed I make debian specific changes and then create diffs for them in the debian/patches dir.
please use release tarballs :-)
Hi, FYI, while communicating with Matt Zimmerman a couple of weeks back on security issues for KDE (that the woody debs on kde.org have those fixed as well - Martin Schulze included that info while he was doing that) we were discussing things like that the KDE packages in sid are made from CVS checkouts rather than from the original release tarballs. Matt would prefer to get them build from the release tarballs with patchsets against CVS if you need them - however, this is none of my business so you might want to check with Matt how to proceed with your next upload as that's probably the last chance to do it the way the security team would like to have things done for sarge. I know making patchsets for every change requires a lot of time and effort but you should seriously think about doing it; it will ensure more quality control and give the security team a better base in case they will receive security patches from KDE - again this is my personal opinion, I'm not a debian developer yet that I could do this on my own but I would be willing to help there. Ralf -- We're not a company, we just produce better code at less costs. Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org pgpoyIJWQ3OIG.pgp Description: signature
