Has anyone actually tried to build packages from the 4.3.0 branch
lately? It seems that the regression of the changes eliminating the
glu packages are incomplete. I am finding that the current snapshot
of the 4.3.0 branch doesn't actually build libGLU even though it
tries to package it at the en
Is anyone else seen the 4.3.0 branch not be able to
correctly patch for the last few days? Using the files...
branches-4.3.0-sid-debian-2003.06.28.tar.gz
xfree86_4.3.0.orig.tar.gz
from http://necrotic.deadbeast.net/xfree86/ I now get...
Applying patch debian/patches/000_stolen_from_HEAD.diff.
Has anyone actually tried to build packages from the 4.3.0 branch
lately? It seems that the regression of the changes eliminating the
glu packages are incomplete. I am finding that the current snapshot
of the 4.3.0 branch doesn't actually build libGLU even though it
tries to package it at the en
Is anyone else seen the 4.3.0 branch not be able to
correctly patch for the last few days? Using the files...
branches-4.3.0-sid-debian-2003.06.28.tar.gz
xfree86_4.3.0.orig.tar.gz
from http://necrotic.deadbeast.net/xfree86/ I now get...
Applying patch debian/patches/000_stolen_from_HEAD.diff.
Is the X Strike Force repository on necrotic.deadbeast.net set
up to allow anonymous checkouts of the debian directories with svn?
If so what is the correct syntax for that? Thanks in advance.
Jack
ps The web view of the repository at
http://necrotic.deadbeast.
Is the X Strike Force repository on necrotic.deadbeast.net set
up to allow anonymous checkouts of the debian directories with svn?
If so what is the correct syntax for that? Thanks in advance.
Jack
ps The web view of the repository at
http://necrotic.deadbeast.
Franz Sirl, the ppclinux devtool maintainer, has kindly
built the current rawhide XFree86 4.3.0 srpms against
gcc-3.3 from 6/18/03 on Yellow Dog Linux. He is unable to
reproduce the authentication problems we see on debian
under either xdm or kdm. Perhaps we build XFree86 differently
enough fro
Franz Sirl, the ppclinux devtool maintainer, has kindly
built the current rawhide XFree86 4.3.0 srpms against
gcc-3.3 from 6/18/03 on Yellow Dog Linux. He is unable to
reproduce the authentication problems we see on debian
under either xdm or kdm. Perhaps we build XFree86 differently
enough fro
Daniel,
We still need to have the debian bug 187374 fixed for
4.3.0-0pre1v1. I am not sure how to do this properly in
the Imakefiles but if we can end up with the Makefiles having
these changes we should be able to eliminate the undefined non-weak
symbols out of XFree86...
--- xc/lib/Xpm/Makefi
Daniel,
We still need to have the debian bug 187374 fixed for
4.3.0-0pre1v1. I am not sure how to do this properly in
the Imakefiles but if we can end up with the Makefiles having
these changes we should be able to eliminate the undefined non-weak
symbols out of XFree86...
--- xc/lib/Xpm/Makefi
Has anyone else noticed that the repository snapshots for
the 4.3.0-sid branch hasn't been buildable for a few days now?
Using the xfree86 4.3.0 tarball there and the snapshot
branches-4.3.0-sid-debian-2003.06.18.tar.gz I get an error...
make[4]: Entering directory
`/home/howarth/debian-xfree8
Has anyone else noticed that the repository snapshots for
the 4.3.0-sid branch hasn't been buildable for a few days now?
Using the xfree86 4.3.0 tarball there and the snapshot
branches-4.3.0-sid-debian-2003.06.18.tar.gz I get an error...
make[4]: Entering directory
`/home/howarth/debian-xfree8
Branden,
Is this part still needed?
+ * #003_linux.cf_and_xfree86.cf.diff:
+- Always disable `FontLibSharedFreeType' for compatiblity between
+ normal XFree86 server and XFree86-dbg server.
+ We should drop this change, when we can build the Loader Server
+ liked against ex
Branden,
Is this part still needed?
+ * #003_linux.cf_and_xfree86.cf.diff:
+- Always disable `FontLibSharedFreeType' for compatiblity between
+ normal XFree86 server and XFree86-dbg server.
+ We should drop this change, when we can build the Loader Server
+ liked against ex
Daniel,
From http://necrotic.deadbeast.net/xfree86/, I built the
branches-4.3.0-sid-debian-2003.06.07.tar.gz. This is against
current debian ppc sid plus todays freetype6 2.1.4-4 package.
The resulting xfree86 packages, when installed, allow me to
telnet back into my machine and open a xcalc in
Daniel,
From http://necrotic.deadbeast.net/xfree86/, I built the
branches-4.3.0-sid-debian-2003.06.07.tar.gz. This is against
current debian ppc sid plus todays freetype6 2.1.4-4 package.
The resulting xfree86 packages, when installed, allow me to
telnet back into my machine and open a xcalc in
Branden,
Well all I can say is that the current xfree86 4.3.0 branch
debian 0pre1v1 sources that are posted build fine on debian ppc
sid using gcc 3.3 without any evidence of this bug.
Jack
Branden,
Well all I can say is that the current xfree86 4.3.0 branch
debian 0pre1v1 sources that are posted build fine on debian ppc
sid using gcc 3.3 without any evidence of this bug.
Jack
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". T
Branden,
We have never seen this problem with gcc 3.3 builds of XFree86
4.3.0, right? It sounds like it might be better to just push
XFree86 4.3.0 into sid and shake out the remaining bugs there.
Now that freetype6 has been regressed back to a binary compatible
state are there really that many b
Branden,
We have never seen this problem with gcc 3.3 builds of XFree86
4.3.0, right? It sounds like it might be better to just push
XFree86 4.3.0 into sid and shake out the remaining bugs there.
Now that freetype6 has been regressed back to a binary compatible
state are there really that many b
Manoj,
Wouldn't it be better to have a temporary back-compatibility package
for the old flex as a stop-gap measure so things could progress on
other fronts while the lex stuff was sorted out?
Jack
Daniel,
If pymol build depends on glutg3-dev which depends on libglut3-dev
which depends on xlibmesa-dev which depends on xlibmesa3 AND now
xlibmesa3-gl and xlibmesa3-glu replaces xlibmesa3 shouldn't apt-get
favor them instead of an older xlibmesa3 package?
J
Daniel,
If pymol build depends on glutg3-dev which depends on libglut3-dev
which depends on xlibmesa-dev which depends on xlibmesa3 AND now
xlibmesa3-gl and xlibmesa3-glu replaces xlibmesa3 shouldn't apt-get
favor them instead of an older xlibmesa3 package?
J
Daniel,
Well on my debian sid machine it seems that apt-get build-dep pymol
is causing the older xlibmesa3 4.2.1-4 package to be queued for installation.
If anything since pymol's Build-Dep relies on glutg3-dev to drag in the
mesa dev stuff I would assume the fault lies in that package instead.
Branden,
The new mesa packaging still has issues. Try this...
dpkg --purge xlibmesa-gl-dev xlibmesa-glu-dev xlibosmesa-dev libglut3-dev
glutg3-dev
mkdir debian-pymol
cd debian-pymol
apt-get source pymol
apt-get build-dep pymol
On my machine I get a confusing array of error messages like..
Daniel,
Well on my debian sid machine it seems that apt-get build-dep pymol
is causing the older xlibmesa3 4.2.1-4 package to be queued for installation.
If anything since pymol's Build-Dep relies on glutg3-dev to drag in the
mesa dev stuff I would assume the fault lies in that package instead.
Branden,
The new mesa packaging still has issues. Try this...
dpkg --purge xlibmesa-gl-dev xlibmesa-glu-dev xlibosmesa-dev libglut3-dev glutg3-dev
mkdir debian-pymol
cd debian-pymol
apt-get source pymol
apt-get build-dep pymol
On my machine I get a confusing array of error messages like...
Branden,
I understand you submitted some policy recommendation on
handling TrueType fonts in debian. Has there been any decision
about that and is it archived somewhere in the mailing lists?
The current situation has msttcorefonts quite broken with
regard to openoffice.org since the symlinks ar
Branden,
I understand you submitted some policy recommendation on
handling TrueType fonts in debian. Has there been any decision
about that and is it archived somewhere in the mailing lists?
The current situation has msttcorefonts quite broken with
regard to openoffice.org since the symlinks ar
Branden,
In current debian ppc sid, when I install the experimental
XFree86 4.2.0-0pre1v3 packages since perl 5.80 has been installed
I see the following extra warnings (I am assuming these aren't
really errors)...
Setting up xfree86-common (4.2.0-0pre1v3.1) ...
Filehandle STDIN opened only for
Branden,
I figured out the problem when building your test XFree86 4.2.0
packages on debian ppc sid using gcc 3.1.1. The problem is that
when we build with gcc 3.1.1, ppc becomes like alpha and can no
longer do a 'strip --strip-debug' on libGLcore.a in the
xserver-xfree86. So far libGLcore.a
Hello,
Has anyone else tried to rebuild Branden's test xfree86 4.2.0-0pre1v1
packages against the current gcc 3.1.1? On debian ppc sid, I find that
while the build appears to work in general there is at least one glitch
compared to the gcc 2.95.4 build. I see under the gcc 3.1 packages the
follo
Hello,
Has anyone else tried to rebuild Branden's test xfree86 4.2.0-0pre1v1
packages against the current gcc 3.1.1? On debian ppc sid, I find that
while the build appears to work in general there is at least one glitch
compared to the gcc 2.95.4 build. I see under the gcc 3.1 packages the
foll
Branden,
Thanks. The updated source builds fine here on debian ppc sid
using gcc 3.1.1pre2.
Jack
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Building locally on debian ppc sid, I see a build failure
for the new test packages...
making all in doc/specs/programs...
make[6]: Entering directory
`/home/howarth/buildxf42/xfree86-4.2.0/build-tree/xc/doc/specs/programs'
make[6]: *** No rule to make target
`../../../programs/Xserver/hw/xf
Building locally on debian ppc sid, I see a build failure
for the new test packages...
making all in doc/specs/programs...
make[6]: Entering directory
`/home/howarth/buildxf42/xfree86-4.2.0/build-tree/xc/doc/specs/programs'
make[6]: *** No rule to make target
`../../../programs/Xserver/hw/x
Ishikawa,
A minor correction. I noticed you had uploaded new copies
of the xfree86_4.2.0-0b2.diff.gz with a different checksum
so I tried building with gcc 3.1.1-0pre2 again. This time
I didn't have any problems and the resulting binaries work
just as well as your gcc 2.95.4 built ones do. Als
Ishikawa,
A minor correction. I noticed you had uploaded new copies
of the xfree86_4.2.0-0b2.diff.gz with a different checksum
so I tried building with gcc 3.1.1-0pre2 again. This time
I didn't have any problems and the resulting binaries work
just as well as your gcc 2.95.4 built ones do. Al
Ishikawa,
I just installed last nights 4.2.0-0b2 build of XFree86 on
my debian ppc linux machine and it installed without errors
and works flawlessly so far. I tried building the same locally
last night against the current gcc 3.1.1pre1 packages but we
seem to be tickling a compiler error in th
Ishikawa,
I just installed last nights 4.2.0-0b2 build of XFree86 on
my debian ppc linux machine and it installed without errors
and works flawlessly so far. I tried building the same locally
last night against the current gcc 3.1.1pre1 packages but we
seem to be tickling a compiler error in t
Thanks to Felix Homann hint to look at...
http://support.wolfram.com/mathematica/systems/linux/interface/fonterrors.html
...I solved the error message from mathematica. The origin of the problem
was that I had over 3522 fonts and the setting in...
/usr/local/mathematica/SystemFiles/FrontEnd/
Does anyone understand why gsfonts-x11 seems to be so deeply
entrenched in the system after it is installed? I tried to
apt-get remove it and I get...
apt-get remove gsfonts-x11
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be REMOVED:
bonobo bo
Hello,
Does anyone else running debian sid have the linux version of
mathematica installed. It was working fine until a week ago on my
machine and now when I run mathematica it brings up an alert saying
that some of the mathematica fonts could not be loaded. I tried
doing a clean install of mat
Branden,
Actually their is no need for Xprint support for OpenOffice
at this point. For the last couple of OpenOffice releases the
new print system has been in place and one can use your existing
lprng setup. In my case I have it filtered through ghostscript
to my Epson 740i and OpenOffice pri
Branden,
Actually their is no need for Xprint support for OpenOffice
at this point. For the last couple of OpenOffice releases the
new print system has been in place and one can use your existing
lprng setup. In my case I have it filtered through ghostscript
to my Epson 740i and OpenOffice pr
45 matches
Mail list logo
