[Pkg-xen-devel] Contacting upstream

Ralph Passgang ralph at debianbase.de
Sun Feb 19 16:41:21 UTC 2006


Am Sonntag, 19. Februar 2006 09:33 schrieb Jeremy T. Bouse
>     I think both of these items are good ones to address that would
> hopefully be gladly accepted upstream. The /etc/sysconfig path is RedHat
> specific and isn't even within the FHS if I'm not mistaken so we
> absolutely have to patch as packages are supposed to follow it. The = vs
> ?= may have simply been overlooked.
>
>     The only other thing might be the kernel patching but we can deal
> with that at a later time.

right, kernel-patching in upstream is broken, but they should know that, at 
least I saw that already reported on the xen ml. In fact it isn't really 
important, because we supply a static patch file anyway and don't need that 
in our packages.

But as you said "kernel patch" I realized that I missed to create a bug report 
against debconf, because of dh_installkpatches doesn't handle patches with an 
extraversion set correctly (as I already reported on this list).

I will do this on monday, because I want to include the error message that 
dh_installkpatches brings up and I might also supply a patch for debconf 
then, so that this is easier for the maintainer to fix. I think this is just 
an one-line fix :)

We should replace the static kernel patch as soon as debconf is fixed, because 
otherwise our kernel patch will not have to correct version in .config.

--Ralph

> Guido Trotter wrote:
> >Hi,
> >
> >during the week I was thinking to send an email to the upstream
> > development list to see if, at some point in the future, we might have
> > the changes needed for us not to patch their package, or to reduce our
> > patches even more...
> >
> >The points I was going to touch were:
> >
> >/etc/sysconfig:
> >	We'd like, if it's possible, to have this be configurable at build
> >	time... The default can remain like it is now, so no one gets confused,
> >	but on the other hand we remove 10sysconfig.dpatch. This can probably be
> >	efficiently done by making the path a parameter, calling the source file
> >	xendomains.in and then processing it to produce the official xendomains
> >	substituting the path with the provided one.
> >
> >LIBDIR:
> >	I guess we could do away with our patch if they accept to change their
> >	Config.mk from:
> >
> >		ifeq ($(XEN_TARGET_ARCH),x86_64)
> >		LIBDIR = lib64
> >		else
> >		LIBDIR = lib
> >		endif
> >
> >	to:
> >
> >		ifeq ($(XEN_TARGET_ARCH),x86_64)
> >		LIBDIR ?= lib64
> >		else
> >		LIBDIR ?= lib
> >		endif
> >
> >	Which shoudln't change anything for them and lets us pass the LIBDIR=
> > parameter to make and remove our 20lib64.dpatch.
> >
> >Any other points we might want to touch, while we're at it?
> >
> >Guido
> >
> >
> >_______________________________________________
> >Pkg-xen-devel mailing list
> >Pkg-xen-devel at lists.alioth.debian.org
> >http://lists.alioth.debian.org/mailman/listinfo/pkg-xen-devel
>
> _______________________________________________
> Pkg-xen-devel mailing list
> Pkg-xen-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-xen-devel



More information about the Pkg-xen-devel mailing list