Re: How can I best help with glibc packaging?
On Mon, Jul 25, 2005 at 07:53:00PM +0300, Lars Wirzenius wrote:
> The glibc bug list is many hundreds of bugs long, and shortening it a
> lot would be good. Now that we're not in any kind of freeze and that
> 2.3.5 is going into sid in the near future, I hope it will be possible
> to fix even bugs with low severities.
Yes! Completely agreed. My priorities are getting us onto 2.3.5, and
from there onto the 2.3 branch in CVS. Then pruning any unnecessary
patches, merging things both ways, and generally trying to get our
fixes into upstream CVS. This is mind-numbing and time-consuming.
> If I file patches, is it better to make them against the newest version
> in the archive (experimental or sid), or agains the Subversion
> repository? The former would probably be easier for me, but either is of
> course doable. Things that need changes to upstream source will have to
> go into a dpatch file, and other things need to be normal patches
> against files in debian/*, right?
The subversion repository would be substantially more helpful - in
particular, the branch that's going into experimental. I think it's
trunk now, but I'm not 100% sure.
> Also, a different question: is there a known best approach to hacking on
> the glibc package to keep development cycles short? A full build of the
> package takes up to two hours for me, and even the fastest build of the
> Debian package (using ccache, and commenting out most of the binary
> packages, such as -dbg) takes over half an hour. Is there any way of
> making this faster without buying faster hardware?
Not really. I do a lot of things by running make in object
directories, instead. I also work on multiple bugs at a time and build
them together.
--
Daniel Jacobowitz
CodeSourcery, LLC
Reply to: