[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debian/patches review



> Hi,
> 
> I checked at debian/patches/*, and how these patches should be handled
> after applying the latest 2-2-branch glibc-cvs.dpatch.
> Please review my check. If it's fine to include this in our cvs,
> then I put it on debian/patches/0status. It's ok?
> IMHO in -14 or -15, we update glibc-cvs.dpatch, then simply removed 
> 'remove' status files from 0list.

Looks great GOTO!

> glibc22-hppa-unwind.dpatch
> 	2.2 CVS:	not in
> 	2.3 CVS:	not in
> 	Comment:	After checking it's ok or not, then submit to upstream
> 			if it's correct. This patch is applied only kernel
> 			version lower checking.
> 	Status:		merge

Checking for 2.4.0 is bad... major bugs removed from this kernel.
Checking for 2.4.4 is arbitrary and reflects on the nature of this patches age.
Check for 2.4.9 is recommended since our 0.9.3 ISO shipped with that kernel.
We shipped 2.4.17/18 with woody.

> glibc22-hppa-tests.dpatch
> 	2.2 CVS:	not in
> 	2.3 CVS:	not in
> 	Comment:	IMHO, It's fine. It should be merged into upstream
> 			(#137513).
> 	Status:		merge

Randolph did a great job checking the libm tolerances. This one is golden.

> hppa-data-start.dpatch
> 	2.2 CVS:	not in
> 	2.3 CVS:	not in
> 	Comment:	According to #133666, it's needed for hppa.
> 			I also think this symbol is lack, so should be send to
> 			upstream.
> 	Status:		merge

Agreed.

> glibc22-hppa-pthreads.dpatch
> 	2.2 CVS:	not in
> 	2.3 CVS:	not in
> 	Comment:	? Ben?
> 	Status:		unknown

This is requied for pthreads to work on HPPA. There are number of things
that had to be changed, including the fact that hppa can't use int and 
needs __atomic_lock_t. Also spinlocks don't get assigned 0 but rather
__ATOMIC_LOCK_INIT. These changes alone mandate lots of one liners.

> glibc22-hppa-rela.dpatch
> 	2.2 CVS:	not in
> 	2.3 CVS:	not in
> 	Comment:	? Ben?
> 	Status:		unknown
> 

We need some extra info e.g. "struct link_map *map" to do R_PARISC_RELATIVE 
reloc's. This requires that we pass the *map in all the required calls.
Is this correct Ben?

Note:
It seems that the changelog entries for the addition of the hppa .dpatch's 
is missing? I only found mention of Randolph's glibc22-hppa-tests.dpatch.
Is ther any way we can get these added? Surely upstream won't merge anything
without appropriate changelog entries. Matthew Wilcox has noted that the .dpatch's
had changelog entries in our old tree, it just seems they were missed when
being placed into the debian glibc tree.

I'm here to help! :)

c.



Reply to: