Re: debian/patches review
GOTO,
> Carlos O'Donell wrote:
> > > 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.
>
> So, changing checking for 2.4.4 -> 2.4.9 is more appropriate?
>
Lets just check for 2.4.9
--- glibc22-hppa-unwind.dpatch.orig 2002-08-11 15:14:41.000000000 -0400
+++ glibc22-hppa-unwind.dpatch 2002-08-11 15:15:07.000000000 -0400
@@ -24,7 +24,7 @@
;;
hppa*)
- arch_minimum_kernel=2.3.99
-+ arch_minimum_kernel=2.4.4
++ arch_minimum_kernel=2.4.9
+ libc_cv_gcc_unwind_find_fde=yes
;;
mips*)
@@ -37,7 +37,7 @@
;;
hppa*)
- arch_minimum_kernel=2.3.99
-+ arch_minimum_kernel=2.4.4
++ arch_minimum_kernel=2.4.9
+ libc_cv_gcc_unwind_find_fde=yes
;;
mips*)
---------
> > > 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.
>
> OK, change mark as 'should be sent to upstream author'.
Yup.
> > > 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?
>
> So, how to handle this patch? Sending this to upstream is OK?
This is a good question. We need this. I'm not sure what upstream will
say about this. I would gladly talk to upstream about this, but that is
probbly Ben's job :} Ben, what's the word?
> > 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.
>
> If you have changelog entries in your old tree, then could you tell
> me where they can be gotten? Adding the changelog into .dpatch seems
> good idea. Well, we should be careful to write changelog...
I'm not sure I understand you correctly... the changelog entries cannot
be added to the .dpatch, they are just added by hand :) We should _only_
write to changelog by hand.
glibc22-hppa-rela.dpatch - Needs entry (none exists).
glibc22-hppa-unwind.dpatch - Needs entry (none exists).
hppa-data-start.dpatch - Needs entry (none exists).
glibc22-hppa-pthreads.dpatch - Changelog should be taken from [1].
glibc22-hppa-tests.dpatch - Has changelog entry.
glibc22-hppa-unwind.dpatch.orig - Needs entry (none exists).
I've CC'd this to Matthew Wilcox to see if I'm right here :}
[1] http://cvs.parisc-linux.org/*checkout*/obsolete/glibc/ChangeLog?rev=HEAD&content-type=text/plain
c.
Reply to: