Bug#677733: Add multiarch support.

[Goswin von Brederlow]

Package: xcb-util-renderutil
Version: 0.3.8-1
Severity: normal

Hello:

Please make this package compatible with multiarch, as described at
.

More info: http://wiki.debian.org/ReleaseGoals/MultiArch

Thanks,
Goswin

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120616152151.31997.22801.reportbug@frosties.localnet

Bug#656719: Please provide xvmc and vdpau Gallium3D video acceleration drivers (libg3dvl-mesa package)

[Goswin von Brederlow]

Package: mesa
Version: 9.1.4
Followup-For: Bug #656719

The dependency on linux-firmware-nonfree should be firmware-linux-nonfree
instead.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130712220449.28540.24445.reportbug@frosties.localnet

Re: /usr/X11R6/lib64 symlink for amd64

[Goswin von Brederlow]

Branden Robinson <[EMAIL PROTECTED]> writes:

> clone 259302 -1
> retitle -1 xfree86-common: provide /usr/X11R6/lib64 compatibility symlink on 
> amd64 systems
> reassign -1 xfree86-common
> severity -1 wishlist
> thanks
>
> [I am not subscribed to debian-amd64.]
>
> On Tue, Nov 30, 2004 at 06:40:42PM +0100, Santiago Vila wrote:
>> Hello.
>> 
>> The amd64 porters have asked me that I add several symlinks to base-files
>> (see Bug #259302) for the amd64 architecture. As base-files itself does
>> not even contain the /usr/X11R6/lib directory on the other architectures,
>> I consider adding /usr/X11R6/lib64 to base-files an ugly hack.
>> 
>> Would the X maintainers be willing to add the /usr/X11R6/lib64 symlink
>> to the xfree86-common package? I think it would be much more suitable.
>
> Yeah, okay.
>
> As long as AMD64 is both unofficial and I only have to ship this lib64
> thing for unofficial architectures, it will survive the ordinarily level of
> strict scrutiny I would apply.
>
> I still say "/lib64" is one of the nastiest pieces of shit I've ever
> heard of.

The link could go into the LSB package. The link is not needed for
Debian but only for LSB compliance and 3rd party software.

MfG
Goswin

Bug#236132: libx11-6 postrm bug prevents removal of package

[Goswin von Brederlow]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> Op do 04-03-2004, om 14:57 schreef Michael Schmitz:
> > I'll shut my autobuilder down for the time being, until after 4.3.0-3 has
> > been installed.
> 
> That's not necessary. If you preinstall the b0rken packages (using
> "apt-get --reinstall install foo bar baz" should do it), you can
> continue to build. I've done that on quickstep, seems to work.
> 
> (alternatively, you could just dep-wait everything on xserver-xfree86
> (>> 4.3.0-2) ...)

buildd realy should have the option to delete the chroot and rebuild
(or untar) a new one. For big builds its probably even faster to wipe
and untar a fresh chroot than to uninstall all the packages.

MfG
Goswin

PS: On i386 I use an lvm snapshot that gets created for every package
build. No time wasted on rebuilding the chroot but always a fresh
one. Might be an option for the amiga buildds running 2.4.x.

Bug#207305: you forgotto CC to control

[Goswin von Brederlow]

topic says it all



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#207481: different approach to the XFree86 config

[Goswin von Brederlow]

Hi,

I have two little things I would like to add.

1. Try to do autodetection. Read out the lang and the monitor. Almost any
  modern system will report its parameter.

2. Fill in the autodetected values and present them to the user with the
   following choises:
   [ ] Bugger off, I do it myself
   [ ] Use values (I will change what needs changed manually)
   [ ] change values

The first one would disable the configuration completly. No more test and no
questions about conffile changes in the future. Thats hardcore guys.

The second would be the default. Things like the exact keyboard moddel or
the monitor frequency (if reading them out failed) could still be asked
or left to the user to fill in. A minimum of questions should be asked.

The last options would go through all settings having the autotedted stuff
as defaults. That would be like the setup now.


An alternative approach would be to present the probed values as menu and
the user can choose the items that need changes. Items not probed would
need to be selected before  could be selected.

I'm not sure what debconf interfaces can cope with such a menu though.

MfG
Goswin



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#207305: you forgotto CC to control

[Goswin von Brederlow]

topic says it all

Bug#207481: different approach to the XFree86 config

[Goswin von Brederlow]

Hi,

I have two little things I would like to add.

1. Try to do autodetection. Read out the lang and the monitor. Almost any
  modern system will report its parameter.

2. Fill in the autodetected values and present them to the user with the
   following choises:
   [ ] Bugger off, I do it myself
   [ ] Use values (I will change what needs changed manually)
   [ ] change values

The first one would disable the configuration completly. No more test and no
questions about conffile changes in the future. Thats hardcore guys.

The second would be the default. Things like the exact keyboard moddel or
the monitor frequency (if reading them out failed) could still be asked
or left to the user to fill in. A minimum of questions should be asked.

The last options would go through all settings having the autotedted stuff
as defaults. That would be like the setup now.


An alternative approach would be to present the probed values as menu and
the user can choose the items that need changes. Items not probed would
need to be selected before  could be selected.

I'm not sure what debconf interfaces can cope with such a menu though.

MfG
Goswin

Bug#276345: Reproducing the bug

[Goswin von Brederlow]

Hi,

I found a way to reproduce this for sure:

You need some text spaning multiple lines that has partially scrolled
out of the visible area. Then start some application that has a
window, anything curses based should do and select the first word/line.

E.g.:

echo $(seq 1000); xemacs -nw
echo $(seq 1000); less some-file
echo $(seq 1000); zile
echo $(seq 1000); irssi
echo $(seq 1000); screen
...

The tripple click to select the top line will also select the partial
line that was scrolled out of the visible window. Scroling up in the
scrollback buffer will show the text it selects.

MfG
Goswin



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#362787: Needless Build-Depends on ssh | rsh

[Goswin von Brederlow]

Package: xbase-clients
Version: 7.0.0-3
Severity: normal
Tags: patch

Hi,

xbase-clients Build-Depends on ssh | rsh, which means it pulls in
openssh-server and openssh-client into the buildd chroot and generate
new host keys. Something that uses up a lot of entropy and takes a
long time on e.g. m68k.

At a minimum the Build-Depends should be updated to "openssh-client |
ssh | rsh" reflecting the split package. The attached patch goes one
step further and eliminates the need for ssh alltogether by supplying
the path to rsh on the configure call. There is little point trying to
autodetect what we already know to be.

MfG
Goswin

-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.8-frosties-2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
diff -u xbase-clients-7.0.0/debian/changelog 
xbase-clients-7.0.0/debian/changelog
--- xbase-clients-7.0.0/debian/changelog
+++ xbase-clients-7.0.0/debian/changelog
@@ -1,3 +1,9 @@
+xbase-clients (1:7.0.0-3c0.mrvn.1) unstable; urgency=low
+
+  * Set RSH=/usr/bin/rsh instead of Build-Depending on ssh | rsh
+
+ -- Goswin von Brederlow <[EMAIL PROTECTED]>  Sat, 15 Apr 2006 14:10:22 +
+
 xbase-clients (1:7.0.0-3) unstable; urgency=low
 
   * Remove mention of xorgconfig and xorgcfg in package description. Thanks
diff -u xbase-clients-7.0.0/debian/control xbase-clients-7.0.0/debian/control
--- xbase-clients-7.0.0/debian/control
+++ xbase-clients-7.0.0/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian X Strike Force 
 Uploaders: David Nusinow <[EMAIL PROTECTED]>, Branden Robinson <[EMAIL 
PROTECTED]>, Fabio M. Di Nitto <[EMAIL PROTECTED]>
-Build-Depends: debhelper (>= 4.0.0), pkg-config, libfs-dev (>= 2:1.0.0-1), 
libpng-dev, libx11-dev (>= 2:1.0.0-1), libxaw7-dev (>= 1:1.0.1-1), 
libxcursor-dev (>= 1.1.5.2-1), libxext-dev (>= 1:1.0.0-1), libxft-dev (>= 
2.1.8.2-6), libxi-dev (>= 1:1.0.0-3), libxkbfile-dev (>= 1:1.0.1-1), 
libxmuu-dev (>= 1:1.0.1-1), libxrandr-dev (>= 2:1.1.0.2-1), libxrender-dev (>= 
1:0.9.0.2-2), libxss-dev (>= 1:1.0.1-1), libxt-dev (>= 1:1.0.0-1), libxtrap-dev 
(>= 1:1.0.0-1), libxtst-dev (>= 1:1.0.1-1), libxxf86dga-dev (>= 1:1.0.1-1), 
libxv-dev (>= 1:1.0.1-1), libxxf86vm-dev (>= 1:1.0.0-1), ssh | rsh, 
x11proto-gl-dev, libgl1-mesa-dev, xbitmaps
+Build-Depends: debhelper (>= 4.0.0), pkg-config, libfs-dev (>= 2:1.0.0-1), 
libpng-dev, libx11-dev (>= 2:1.0.0-1), libxaw7-dev (>= 1:1.0.1-1), 
libxcursor-dev (>= 1.1.5.2-1), libxext-dev (>= 1:1.0.0-1), libxft-dev (>= 
2.1.8.2-6), libxi-dev (>= 1:1.0.0-3), libxkbfile-dev (>= 1:1.0.1-1), 
libxmuu-dev (>= 1:1.0.1-1), libxrandr-dev (>= 2:1.1.0.2-1), libxrender-dev (>= 
1:0.9.0.2-2), libxss-dev (>= 1:1.0.1-1), libxt-dev (>= 1:1.0.0-1), libxtrap-dev 
(>= 1:1.0.0-1), libxtst-dev (>= 1:1.0.1-1), libxxf86dga-dev (>= 1:1.0.1-1), 
libxv-dev (>= 1:1.0.1-1), libxxf86vm-dev (>= 1:1.0.0-1), x11proto-gl-dev, 
libgl1-mesa-dev, xbitmaps
 Standards-Version: 3.6.1.0
 
 Package: xbase-clients
diff -u xbase-clients-7.0.0/debian/rules xbase-clients-7.0.0/debian/rules
--- xbase-clients-7.0.0/debian/rules
+++ xbase-clients-7.0.0/debian/rules
@@ -46,7 +46,7 @@
echo "$$FILE" ; \
mkdir "$$FILE"-obj-$(DEB_BUILD_GNU_TYPE); \
(cd "$$FILE"-obj-$(DEB_BUILD_GNU_TYPE) && \
-   ../"$$FILE"/configure --prefix=/usr 
--mandir=\$${prefix}/share/man \
+   RSH=/usr/bin/rsh ../"$$FILE"/configure --prefix=/usr 
--mandir=\$${prefix}/share/man \
 --infodir=\$${prefix}/share/info $(confflags) \
 CFLAGS="$(CFLAGS)" && \
$(MAKE)) || exit 1; \
only in patch2:
unchanged:
--- xbase-clients-7.0.0.orig/xsm-X11R7.0-1.0.1/configure
+++ xbase-clients-7.0.0/xsm-X11R7.0-1.0.1/configure
@@ -2915,7 +2915,6 @@
 test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644'
 
 
-RSH=
 if [ -z $RSH ] ; then
# Extract the first word of "rsh", so it can be a program name with args.
 set dummy rsh; ac_word=$2
only in patch2:
unchanged:
--- xbase-clients-7.0.0.orig/xsm-X11R7.0-1.0.1/configure.ac
+++ xbase-clients-7.0.0/xsm-X11R7.0-1.0.1/configure.ac
@@ -31,7 +31,6 @@
 AC_PROG_CC
 AC_PROG_INSTALL
 
-RSH=
 if [[ -z $RSH ]] ; then
AC_PATH_PROG(RSH,rsh)
 fi

Bug#521623: [Pkg-ia32-libs-maintainers] Bug#521623: ia32-libs: libGL.so tries to load x86-64 i915_dri.so

[Goswin von Brederlow]

Julien Cristau  writes:

> On Mon, Mar 30, 2009 at 16:37:31 +0200, Goswin von Brederlow wrote:
>
>> This is a problem with plugins. Unless the software/library is
>> prepared to use the lib64/lib32 path to the plugin it will allways use
>> the native bitness and fail if that is wrong. In this case libGL needs
>> to be patched to look in /usr/lib32/dri when compiled for 32bit and
>> /usr/lib64/dri when compiled for 64bit.
>> 
> We don't ship a 32-bit libGL for 64-bit userspace.  ia32-libs does that,
> so you get to deal with the fallout, thanks.
>
> Cheers,
> Julien

Ia32-libs ships the libgl binary from the i386 archive. It does not
and can not build the source so it can not patch the path.

The only way this bug can be fixed is if you help by paching the
normal i386 and amd64 libgl package. Others like gtk and pango
maintainers have done so for the benefit of our users.

If you are unwilling then this bug is a wont-fix.

MfG
Goswin



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#521623: [Pkg-ia32-libs-maintainers] Bug#521623: ia32-libs: libGL.so tries to load x86-64 i915_dri.so

[Goswin von Brederlow]

Michel Dänzer  writes:

> On Wed, 2009-04-01 at 00:50 +0200, Goswin von Brederlow wrote:
>> Julien Cristau  writes:
>> 
>> > On Mon, Mar 30, 2009 at 16:37:31 +0200, Goswin von Brederlow wrote:
>> >
>> >> This is a problem with plugins. Unless the software/library is
>> >> prepared to use the lib64/lib32 path to the plugin it will allways use
>> >> the native bitness and fail if that is wrong. In this case libGL needs
>> >> to be patched to look in /usr/lib32/dri when compiled for 32bit and
>> >> /usr/lib64/dri when compiled for 64bit.
>> >> 
>> > We don't ship a 32-bit libGL for 64-bit userspace.  ia32-libs does that,
>> > so you get to deal with the fallout, thanks.
>> >
>> > Cheers,
>> > Julien
>> 
>> Ia32-libs ships the libgl binary from the i386 archive. It does not
>> and can not build the source so it can not patch the path.
>> 
>> The only way this bug can be fixed is if you help by paching the
>> normal i386 and amd64 libgl package. Others like gtk and pango
>> maintainers have done so for the benefit of our users.
>
> FWIW, strictly speaking no patching is necessary, ia32-libs could just
> arrange for $LIBGL_DRIVERS_PATH containing something like
>
> /usr/lib/dri:/usr/lib32/dri

Now that would be a violation of policy. :)

> However, it would probably be better to make something like this the
> default path built into libGL instead...

yes. And /usr/lib/$(DEB_HOST_GNU_TYPE)/dir could be added as well in
preparation of the multiarch dirs.

MfG
Goswin



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#387133: libx11: FTBFS: floating point exception

[Goswin von Brederlow]

Package: libx11
Version: 2:1.0.0-8
Severity: serious
Justification: no longer builds from source

Hi, when I try to build libx11 under etch or sid I get the following error:

make[3]: Leaving directory 
`/scratch/build/amd64/etch-biarch/xorg/libx11/libx11-1.0.0/obj-x86_64-linux-gnu/src/util'
../src/util/makekeys < /usr/include/X11/keysymdef.h > ks_tables_h
/bin/sh: line 1: 27372 Floating point exception../src/util/makekeys 
ks_tables_h
make[2]: *** [ks_tables.h] Error 136
make[2]: Leaving directory 
`/scratch/build/amd64/etch-biarch/xorg/libx11/libx11-1.0.0/obj-x86_64-linux-gnu/src'

Full debuild log for sid is attached.

MfG
Goswin

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-frosties-2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
 fakeroot debian/rules clean
rm -f stampdir/genscripts
rm -f debian/*.config \
  debian/*.postinst \
  debian/*.postrm \
  debian/*.preinst \
  debian/*.prerm
rm -f stampdir/patch
Unapplying patches...nothing to do.
dh_testdir
rm -f .pc patches
rm -rf stampdir build-tree
rm -rf imports
dh_clean debian/shlibs.local \
 debian/MANIFEST.amd64 debian/MANIFEST.amd64.new \
 debian/po/pothead
dh_testdir
dh_testroot
rm -f build-stamp
rm -f config.cache config.log config.status
rm -f */config.cache */config.log */config.status
rm -f conftest* */conftest*
rm -rf autom4te.cache */autom4te.cache
rm -rf obj-*
dh_clean
 debian/rules build
mkdir stampdir
>stampdir/stampdir
for FILE in debian/*.config.in \
debian/*.postinst.in \
debian/*.postrm.in \
debian/*.preinst.in \
debian/*.prerm.in; do \
  if [ -e "$FILE" ]; then \
MAINTSCRIPT=$(echo $FILE | sed 's/.in$//'); \
sed -n '1,/^#INCLUDE_SHELL_LIB#$/p' <$FILE \
  | sed -e '/^#INCLUDE_SHELL_LIB#$/d' >$MAINTSCRIPT.tmp; \
cat debian/xsfbs/xsfbs.sh >>$MAINTSCRIPT.tmp; \
sed -n '/^#INCLUDE_SHELL_LIB#$/,$p' <$FILE \
  | sed -e '/^#INCLUDE_SHELL_LIB#$/d' >>$MAINTSCRIPT.tmp; \
sed -e 's/@SOURCE_VERSION@/2:1.0.0-8/' \
-e 's/@OFFICIAL_BUILD@/yes/' \
-e 's/@DEFAULT_DCRESOLUTIONS@//' \
  <$MAINTSCRIPT.tmp >$MAINTSCRIPT; \
rm $MAINTSCRIPT.tmp; \
  fi; \
done
# Validate syntax of generated shell scripts.
#sh debian/scripts/validate-posix-sh debian/*.config \
#debian/*.postinst \
#debian/*.postrm \
#debian/*.preinst \
#debian/*.prerm
>stampdir/genscripts
if [ ! -e stampdir/patches ]; then \
mkdir stampdir/patches; \
ln -s stampdir/patches .pc; \
echo 2 >stampdir/patches/.version; \
fi; \
if [ ! -e stampdir/log ]; then \
mkdir stampdir/log; \
fi; \
if [ ! -e patches ]; then \
ln -s debian/patches patches; \
fi; \
>stampdir/prepare
if ! [ `which quilt` ]; then \
echo "Couldn't find quilt. Please install it or add it to the 
build-depends for this package."; \
exit 1; \
fi; \
if quilt next; then \
  echo -n "Applying patches..."; \
  if quilt push -a -v >stampdir/log/patch 2>&1; then \
echo "successful."; \
  else \
echo "failed! (check stampdir/log/patch for details)"; \
exit 1; \
  fi; \
else \
  echo "No patches to apply"; \
fi; \
>stampdir/patch
001_no_xkb_in_pc_file.diff
Applying patches...successful.
dh_testdir
test -d obj-x86_64-linux-gnu || mkdir obj-x86_64-linux-gnu
cd obj-x86_64-linux-gnu && \
../configure --prefix=/usr --mandir=\${prefix}/share/man \
 --infodir=\${prefix}/share/info --build=x86_64-linux-gnu 
--enable-man-pages=3 --enable-loadable-i18n \
 CFLAGS="-Wall -g -O2 -DLIBXCURSOR=\\\"libXcursor.so.1\\\"" 
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are 

Bug#387133: libx11: FTBFS: floating point exception

[Goswin von Brederlow]

Daniel Stone <[EMAIL PROTECTED]> writes:

> On Tue, Sep 12, 2006 at 02:01:59PM +0200, Goswin von Brederlow wrote:
>> Package: libx11
>> Version: 2:1.0.0-8
>> Severity: serious
>> Justification: no longer builds from source
>> 
>> Hi, when I try to build libx11 under etch or sid I get the following error:
>> 
>> make[3]: Leaving directory 
>> `/scratch/build/amd64/etch-biarch/xorg/libx11/libx11-1.0.0/obj-x86_64-linux-gnu/src/util'
>> ../src/util/makekeys < /usr/include/X11/keysymdef.h > ks_tables_h
>> /bin/sh: line 1: 27372 Floating point exception../src/util/makekeys 
>> ks_tables_h
>> make[2]: *** [ks_tables.h] Error 136
>> make[2]: Leaving directory 
>> `/scratch/build/amd64/etch-biarch/xorg/libx11/libx11-1.0.0/obj-x86_64-linux-gnu/src'
>> 
>> Full debuild log for sid is attached.
>
> Yes, unfortunately x11proto-core 7.0.3 or above (or something) breaks
> the build of libx11 << 1.0.1.

Meanwhile Tollef Fog Heen told me to try the Ubuntu version (1.0.3)
which worked. So I just added the makekeys.c from it to 1.0.0 and then
it compiled fine. If updating to 1.0.1+ is too much change then maybe
this quick fix would do.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#387444: libx11: Should compile for /usr/lib64 as per FHS

[Goswin von Brederlow]

Package: libx11
Severity: important
Tags: patch

Hi,

the FHS specifies that on amd64 64bit libraries must be placed in
(/usr)/lib64 and I believe the same rationale applies to the locale
plugins in libx11.

The libx11-6 library on Debian expects to find its locales in
/usr/lib/X11/locale/common while other distributions have them
(correctly as per FHS) in /usr/lib64/X11/locale/common.

The attached patch compiled libx11-6 to use (/usr)/lib64 as libdir but
renames that to (/usr)/lib before building debs as Debian wants
it. That way compatibility with other distributions is preserved and
the FHS is followed.

This also allows automatic conversion to multiarch for the package
alowing both 64 and 32bit packages to be installed at the same time
without having to recompile the source on every update.

MfG
Goswin

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-frosties-2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
diff -u libx11-1.0.0/debian/patches/series libx11-1.0.0/debian/patches/series
--- libx11-1.0.0/debian/patches/series
+++ libx11-1.0.0/debian/patches/series
@@ -14,0 +15 @@
+015_makekeys.diff
only in patch2:
unchanged:
--- libx11-1.0.0.orig/debian/patches/015_makekeys.diff
+++ libx11-1.0.0/debian/patches/015_makekeys.diff
@@ -0,0 +1,20 @@
+Index: libx11/src/util/makekeys.c
+===
+--- libx11-1.0.0/src/util/makekeys.c	2006-01-25 01:40:34.0 +
 libx11-1.0.3/src/util/makekeys.c	2006-06-22 21:25:32.0 +
+@@ -1,5 +1,5 @@
+ /* $Xorg: makekeys.c,v 1.5 2001/02/09 02:03:40 $ */
+-/* $XdotOrg: xc/lib/X11/util/makekeys.c,v 1.4 2004/09/26 20:46:17 kuhn Exp $ */
++/* $XdotOrg: lib/X11/src/util/makekeys.c,v 1.5 2005-07-03 07:00:56 daniels Exp $ */
+ /*
+ 
+ Copyright 1990, 1998  The Open Group
+@@ -49,7 +49,7 @@
+ KeySym	val;
+ } info[KTNUM];
+ 
+-#define MIN_REHASH 10
++#define MIN_REHASH 15
+ #define MATCHES 10
+ 
+ char tab[KTNUM];
diff -u libx11-1.0.0/debian/changelog libx11-1.0.0/debian/changelog
--- libx11-1.0.0/debian/changelog
+++ libx11-1.0.0/debian/changelog
@@ -1,3 +1,11 @@
+libx11 (2:1.0.0-8a0.mrvn.0.1) unstable; urgency=low
+
+  * Add makekeys patch from upstreams 1.0.3 version
+  * Set libdir to /usr/lib64 on amd64
+  * Move debian/tmp/usr/lib64 to lib on amd64
+
+ -- Goswin von Brederlow <[EMAIL PROTECTED]>  Tue, 12 Sep 2006 12:19:17 +
+
 libx11 (2:1.0.0-8) unstable; urgency=low
 
   [ Denis Barbier ]
diff -u libx11-1.0.0/debian/rules libx11-1.0.0/debian/rules
--- libx11-1.0.0/debian/rules
+++ libx11-1.0.0/debian/rules
@@ -44,6 +44,10 @@
 
 confflags += --enable-man-pages=3 --enable-loadable-i18n
 
+ifeq ($(DEB_HOST_ARCH), amd64)
+confflags += --libdir=/usr/lib64
+endif
+
 # so very wrong
 CFLAGS += -DLIBXCURSOR=\\\"libXcursor.so.1\\\"
 
@@ -80,6 +84,11 @@
 	dh_installdirs
 
 	cd obj-$(DEB_BUILD_GNU_TYPE) && $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install
+ifeq ($(DEB_HOST_ARCH), amd64)
+	mkdir -p debian/tmp/usr/lib
+	mv debian/tmp/usr/lib64/* debian/tmp/usr/lib
+	rmdir debian/tmp/usr/lib64
+endif
 
 # Build architecture-dependent files here.
 binary-arch: build install

Bug#466790: libGL.so.1.2 hardcodes /usr/lib/dri

[Goswin von Brederlow]

Cyril Brulebois  writes:

> Michel Dänzer  (09/02/2011):
>> What would be the problem with making the default search path
>> /usr/lib/dri:/usr/lib32/dri ?
>
> Looks easy enough. Goswin, could you try that and tell us if that's
> enough for your needs? Not sure how ia32-libs works. Just bundles
> libraries, moving usr/lib to usr/lib32?
>
> KiBi.

Two things:

1) /usr/lib/dri:/usr/lib32/dri needs to be supported by the library. As
in the library has to be able to search multiple dirs instead of just a
single hardcoded dir. And it should better be the other way around,
lib32:lib for 32bit and lib64:lib for 32bit. And yes, ia32-libs just
bundles and moves the libs to usr/lib32. This is how gtk/pango solved
the problem.

2) Multiarch is ready as far as it concerns you. Just move the files to
/usr/lib/$(DEB_HOST_GNU_TYPE)/dri/. For compatibility reasons it would
be best to add the dir to the search path (if the lib supports multiple
paths, see 1).

MfG
Goswin




--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ei7aj3m8.fsf@frosties.localnet

Bug#466790: libGL.so.1.2 hardcodes /usr/lib/dri which breaks in ia32-libs

[Goswin von Brederlow]

Michel Dänzer  writes:

> On Fre, 2011-02-11 at 00:30 +0100, Javier Serrano Polo wrote: 
>> I've been using this for lenny:
>> 
>> diff -Nru mesa-7.0.3.orig/configs/debian-dri-default 
>> mesa-7.0.3/configs/debian-d
>> ri-default
>> --- mesa-7.0.3.orig/configs/debian-dri-default  2010-07-08 
>> 20:32:49.0 +0200
>> +++ mesa-7.0.3/configs/debian-dri-default   2010-07-08 
>> 20:33:17.0 +0200
>> @@ -15,8 +15,9 @@
>>  
>>  LIB_DIR = lib/glx
>>  
>> +DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
>>  DRI_DRIVER_INSTALL_DIR = $(INSTALL_DIR)/lib/dri
>> -DRI_DRIVER_SEARCH_DIR = /usr/lib/dri
>> +DRI_DRIVER_SEARCH_DIR = /usr/lib/$(DEB_HOST_GNU_TYPE)/dri:/usr/lib/dri
>>  
>>  DRI_DIRS = mach64 mga r128 r200 r300 radeon s3v savage tdfx trident
>>  
>> 
>> 
>> You may want to use /usr/lib$(BITS)/dri:/usr/lib/dri instead.
>
> Yeah, AFAICT DEB_HOST_GNU_TYPE wouldn't help on amd64 at least.

Why? The 32bit libGL then looks in /usr/lib/i486-linux-gnu/dri on amd64.
That is where the files belong under multiarch.

> I'd also recommend keeping /usr/lib/dri first in the path, so native
> apps can succeed on the first lookup.

But then the non native arch would also always look there first and find
the wrong plugins and fail to load them. Hopefully they then would keep
searching and find the right plugin as second try but that requires
extra logic in the source. Better to search the specific dir first and
then fallback to the common dir. It is not like the extra stat() will
slow things down noticeably.

MfG
Goswin




--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vxij3dl.fsf@frosties.localnet