On Wed, 20 Nov 2024, Simon McVittie wrote:
>On Thu, 07 Feb 2019 at 17:59:42 +0000, Thorsten Glaser wrote:
>> + xvfb-run -a -e /dev/stderr -s '-screen 0 1024x768x24 -fbdir /var/tmp' --
>> ctest -O ctest.log -j8 --output-on-failure
>> /usr/bin/xvfb-run: 159: /usr/b
retitle 1067207 mesa: [m68k] switch statement too large, needs
-mlong-jump-table-offsets
tags 1067207 + patch
thanks
>Adding the -mlong-jump-table-offsets flag to CFLAGS on m68k should
That did it. I built with…
APPEND CFLAGS -mlong-jump-table-offsets
APPEND CXXFLAGS -mlong-jump-table-offsets
Source: mesa
Version: 24.0.3-1
Severity: important
Justification: FTBFS on d-ports arch
X-Debbugs-CC: t...@mirbsd.de, debian-...@lists.debian.org
Tags: ftbfs
mesa currently FTBFS on m68k with:
[…]
cc -Isrc/nouveau/headers/libnvidia_headers.a.p […] -o
src/nouveau/headers/libnvidia_headers.a.p/mes
# this is for a nōn-release architecture
severity 1026002 important
# this is a bug in the imake buildsystem, not xlax which merely uses it
reassign 1026002 xutils-dev
retitle 1026002 xutils-dev: imake support for riscv64 vanished?
affects 1026002 src:xlax
thanks
sun min dixit:
>xlax failed to bu
Simon McVittie dixit:
>If that's what you want, here are diffs (these are only the xfonts-base
>subset, the remarkably similar diffs for the other packages will follow
>when I get round to it).
Thanks. Looking good.
>Or if you want to try the web UI, closing the file list/search on the
>left sho
Hi,
this bug still exists.
bye,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
Hi,
we just installed a bullseye system “barebones” and then
added the GUI by “apt-get install xorg icewm xterm”, etc.
and use “exec startx” to run it.
For some reason, the keyboard layout from the installer
is only preserved on the virtual terminal, not in X11.
I know there’s some magic supposed
# imake
reassign 997628 xutils-dev
found 997628 1:7.7+5
retitle 997628 imake: uses “ar clq” by default, which recent binutils broke in
an incompatible way
# causes an FTBFS, cannot be workarounded in mgp
affects 997628 src:mgp
# root bug is in binutils
block 997628 by 981072
# at least, if not mor
Package: x11-xserver-utils
Version: 7.7+8
Severity: normal
Tags: upstream
X-Debbugs-Cc: t...@mirbsd.de
My ~/.xsessionrc has:
xset dpms 0 0 0
With a regular X11 session, this works, but in an xrdp+xorgxrdp session,
it fails because the server lacks DPMS support. But then, once having
fail
Thomas Dickey dixit:
>The example is correct, however. xterm's manpage isn't a tutorial
>on shell programming.
Yes and yes, but it’s still over-microoptimised, in a way that is
not helpful to users.
bye,
//mirabilos
--
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*m
Package: xterm
Version: 366-1
Severity: minor
Tags: upstream
X-Debbugs-Cc: t...@mirbsd.de
The manual page includes example commands such as…
printf '\033]2;Hello world!\033\'
… which use unescaped backslashes at the end of the command.
In general this works…
$ printf '\' | hd
00
Cyril Brulebois dixit:
>Lucas Nussbaum (2021-04-24):
>> C) Do nothing and document this in the release notes
>
>As said above, I strongly recommend against this.
Right… what about, add another Plan C…
C) When X won’t work, fail gracefully, show a console login
… and dump the above to Plan D?
Utkarsh Gupta dixit:
>Thanks to Thomas for his help, I've uploaded a fix for this regression
>(by reverting the backport of that part of the patch which was not
>necessary
It’s got some memory impact, but probably neglegible here, true.
> for this CVE fix). And thanks to Thorsten for his
>compre
Sven Joachim dixit:
>I see that this might be a problem (albeit unlikely to happen in
>practice), however I have trouble understanding exactly where a
>use-after-realloc bug comes into play. Maybe Thorsten can help me fix
>my blindness?
The next time something is selected, the code a little furt
Source: xterm
Version: 327-2+deb9u1
Severity: serious
Justification: introduces use-after-realloc
debian/patches/CVE-2021-27135.patch changes button.c line (after
patching) 3747 to:
line = realloc(line, screen->selection_size);
But “line” is a local variable, the address of the buffer mus
Package: mesa-vulkan-drivers
Version: 20.3.2-1
Severity: important
X-Debbugs-Cc: t...@mirbsd.de
Package: mesa-vulkan-drivers
[…]
Multi-Arch: same
The file /usr/share/vulkan/icd.d/intel_icd.x86_64.json differs.
amd64:
{
"ICD": {
"api_version": "1.2.145",
"library_path": "/
Thomas Dickey dixit:
>I'm guessing that it's timing, e.g., xterm could wait a few milliseconds
>to retry and then give up on that loop, in case the window events don't
>arrive rapidly enough.
“rapidly enough” as criterium isn’t going to help everyone.
We have multi-GHz desktop bolides, few-MHz m
Thomas Dickey dixit:
>how far below?
>
>Just the window-decoration, or a line or so?
About a line, give or take (for the syslog window, the last line
is the cursor, so I don’t need it, and I took a bit more than a
line there; for that test, it’s a bit less).
>Looking at the changes for #361, the
Thomas Dickey dixit:
>I see that version in testing, but don't see a problem on the screen.
>I made a short script to cat those lines to the terminal, sleeping 0.2
>seconds between bursts, and the result looks ok, even with a magnifier.
Indeed, tricky. I experimented with this a bit.
I can repro
On Sun, 20 Dec 2020, Thorsten Glaser wrote:
> corruption effects which vary (see screenshot).
Oops, attached.
Hi Thomas,
>If you're going to compile it, the debug-trace can be useful
>(--enable-trace). If not, the -report-fonts option is helpful.
I hadn’t recompiled, at least not with actual changes.
The -report-fonts output is attached, fNorm is the one
in question.
I did a little bisecting: Debian’s
Thomas Dickey dixit:
>"Recently" could be something overlooked in #362's change
No, 362 is the current one, and I definitely had this in
the previous version shipped in Debian as well, but I can’t
narrow it down further than that. According to apt history
log, that was 361.
>On the other hand (i
Package: xterm
Version: 362-1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
I’ve got the following in my ~/.xinitrc…
/usr/bin/xterm +sb -fg black -geom 78x10+1+637 \
-bg slateblue -e top &
/usr/bin/xterm +sb -fg black -geom 90x11+475+637 \
-bg cornflowerblu
Package: x11-xkb-utils
Version: 7.7+5
Followup-For: Bug #953032
Control: retitle -1 xkbcomp: Internal error: Could not resolve keysym
XF86FullScreen
The high keycode errors went away, but this one still happens.
(Can I tell it to load a .Xmodmap file instead, by the way?
I anyway load one as par
Hi Michel,
>You're probably using the modesetting driver already, since the Xorg
>nouveau driver doesn't support glamor. The fundamental problem is in the
>kernel and/or Mesa nouveau drivers.
ah okay, thanks for the explanation… my X knowledge is a bit rusty
(XFree86*cough*), and this is news to
Timo Aaltonen dixit:
>That was done over two years ago in 1.0.0-1, so you are looking at the
>wrong package? Same thing with the other bug.
No, definitely checked the two packages.
Did you remember to request ftpmasters to change Priority
in the override file after you changed them in the packag
Package: libgles2
Version: 1.1.0-1+b1
Severity: normal
Please change Priority extra to optional, in accordance with latest
Policy, as to not make packages depending on libgles2 but of a conforming
priority violate Policy’s requirement of not depending on packages with
a lower priority.
-- System
Package: libgl1
Version: 1.1.0-1+b1
Severity: normal
Please change Priority extra to optional, in accordance with latest
Policy, as to not make packages depending on libgl1 but of a conforming
priority violate Policy’s requirement of not depending on packages with
a lower priority.
-- System Info
Hi Sven,
>That has apparently helped, but I have just re-enabled asm in git[1],
>since the bug is supposed to be fixed since Mesa 17.0.0.
>
>@Thorsten: would be great if you could test that this actually works.
sure, thanks for informing me. Upgrading was a bit of a hassle due to
Multi-Arch but I
commit 389a79ec6362ae31dc34dd498b47fec10e536492
builds fine on x32, thanks!
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan B
On Tue, 17 Sep 2019, Thomas Dickey wrote:
> > Please apply the following patch (which is _not_ suitable for
> > upstream as the C.UTF-8 locale is my invention and not shipped
>
> really?
Sure, introduced in eglibc 2.13-1, see #609306 for 240 lynx screen
pages of 113x34 for the discussions around
Package: xserver-xorg-legacy
Version: 2:1.20.4-1
Followup-For: Bug #801614
Yes please, I need this preseedable so I can set this to yes in the
debconf database in an installer for a specific platform which needs
this for the X server to work, so that, when the user later installs
the X server, the
Package: xterm
Version: 348-2
Severity: normal
Tags: patch
Please apply the following patch (which is _not_ suitable for
upstream as the C.UTF-8 locale is my invention and not shipped
in all operating systems):
--- usr/bin/uxterm
+++ uxterm
@@ -71,7 +71,7 @@ do
C|POSIX)
Version: 19.1.6-1
Hello Timo,
would you please also fix the bug in the file installation logic?
(This is likely a case where any-amd64 includes x32 because they
share the CPU architecture (but not the ABI), or something like
that.)
Thanks in advance,
//mirabilos
--
tarent solutions GmbH
Rochus
Package: xserver-xorg-core
Version: 2:1.20.4-1
Followup-For: Bug #912325
This happened again.
syslog shows:
Aug 21 02:46:34 tglase xlock[14877]: xlock: xio_error
Aug 21 02:46:34 tglase xlock[14877]: Stop: tglase, tglase, :0, 411m 2s
Aug 21 02:46:34 tglase kdm[2854]: X server for display :0 term
Package: xserver-xorg-video-intel
Version: 2:2.99.917+git20180925-2
Severity: wishlist
Please replace “it’s” (short for “it is”) with “its” (genitive form)
in the package long Description.
(That being said, what benefits has the modesetting driver over the
intel driver viceque versa? I encountere
Package: xserver-xorg-core
Version: 2:1.20.4-1
Followup-For: Bug #912325
This happened again.
-- Package-specific info:
X server symlink status:
lrwxrwxrwx 1 root root 13 Sep 17 2014 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Mar 5 21:11 /usr/bin/Xorg
VGA-c
Source: mesa
Version: 19.1.2-1
Severity: important
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
on debian-ports architecture
https://buildd.debian.org/status/fetch.php?pkg=mesa&arch=x32&ver=19.1.2-1&stamp=1563475274&raw=0
[…]
# Copy the hardlinked vd
Package: xvfb
Version: 2:1.20.3-1
Severity: minor
+ xvfb-run -a -e /dev/stderr -s '-screen 0 1024x768x24 -fbdir /var/tmp' --
ctest -O ctest.log -j8 --output-on-failure
/usr/bin/xvfb-run: 159: /usr/bin/xvfb-run: cannot create /dev/stderr:
Permission denied
/usr/bin/xvfb-run: 82: /usr/bin/xvfb-run
On Wed, 12 Dec 2018, Sven Joachim wrote:
> xterm (338-1) unstable; urgency=medium
> .
>* New upstream release.
[…]
> - Revert the change which prevented concurrent ownership of different
>selection targets, and instead modify selection storage so that
>different concurre
Dixi quod…
> I don’t know how to test this right now, as “xauth add” seems
> to misbehave: instead of adding one line it replaces all three
> lines:
[…]
> (That’s still running under X.)
From outside X I get:
tglase@tglase-nb:~ $ xauth list
tglase@tglase-nb:~ $ xauth add :0 . $(mcookie)
tglase@t
Dixi quod…
> However, on my system I somehow get two (the same but,
I think these come from startx itself, plus the system having
had crashed once while X was running.
If I rm ~/.Xauthority then startx, and, under X, run “xauth list”,
I get:
tglase-nb.lan.tarent.de/unix:0 MIT-MAGIC-COOKIE-1
Package: xinit
Version: 1.4.0-1
Severity: minor
/usr/bin/startx contains this around line 198:
for displayname in $authdisplay $hostname$authdisplay; do
authcookie=`xauth list "$displayname" \
| sed -n "s/.*$displayname[[:space:]*].*[[:space:]*]//p"` 2>/dev/null;
[…]
Package: xserver-xorg-core
Version: 2:1.20.3-1
Severity: important
I came back to work and found the KDM login screen, despite having
locked, not exited, my desktop session when I was using it the last
time. This is the second time this happens, so I investigated:
Oct 29 15:05:54 tglase xlock[325
reopen 901249
thanks
On Tue, 16 Oct 2018, Ondřej Kuzník wrote:
> I've had the following in my .Xprofile for a few years:
> XTerm*VT100.translations: #override : select-end(PRIMARY, CLIPBOARD,
> CUT_BUFFER0)
>
> Since the last upload, mouse selection has become highly unreliable and
Ouch. Yes,
On Mon, 24 Sep 2018, Thomas Dickey wrote:
> hmm - no. This is "wishlist".
It would be if this were a completely new thing, a feature request.
But why would xterm allow binding different clipboards (cut buffers,
PRIMARY, SECONDARY, CLIPBOARD) to different copy/paste key/mouse
bindings if it did n
Package: xterm
Version: 337-1
Severity: important
Tags: upstream
What passes as a “fix” for #901249 broke things in a different manner.
I’m filing as a new bug instead of reopening, though, because the
original report was “behaviour does not match documentation”, and this
one is “behaviour does no
Thomas Dickey dixit:
>actually it was never intended that you could select both at the same
>time. In #336, I've disallowed that.
What does that even mean, wrt. the bug report?
bye,
//mirabilos
--
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. B
Package: xterm
Version: 333-1
Severity: normal
I was working on my .Xresources and found this quite crazy.
I could not select PRIMARY and CLIPBOARD independent of each
other. To reproduce, I chose to have *only* the lines from
the manual page…
*VT100*translations:#override \n\
On Fri, 23 Dec 2016, root wrote:
> * Disable assembly usage on x32. Related to Bug #758094.
>
> -- Andreas Boll Thu, 15 Dec 2016 15:16:56 +0100
Thanks, this appears to help (at least, glxgears works now).
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://ww
Debian Bug Tracking System dixit:
>#846158: Xorg: -logfile /dev/null not allowed, prevents xrdp from working
>
>It has been closed by Emilio Pozuelo Monfort .
I agree with it not being RC any more (sorry about that),
but not with closing it (as I still believe -logfile /dev/null
should work and t
Package: xserver-xorg-core
Version: 2:1.19.0-2
Severity: serious
Justification: prevents xrdp from working
tg@leee:~ $ Xorg :10 -config xrdp/xorg.conf -noreset -nolisten tcp -logfile
/dev/null -retro
(EE)
Fatal server error:
(EE)
Invalid argument for -logfile - "/dev/null"
With elevated p
Package: x11-utils
Version: 7.7+3
Severity: normal
Tags: upstream
I find myself in the situation of wishing to change the
charset for a remote session, i.e. ssh to a cp1252 system
from an UTF-8 system. I thought to use luit for this, but:
tglase@tglase-nb:~ $ luit -encoding 'CP 1252' echo mäh
War
upload.
+ * Fix kfreebsd patch that caused an FTBFS on Linux/x32: (Closes: #787496)
+only include if configure detects it.
+
+ -- Thorsten Glaser Tue, 02 Jun 2015 11:29:50 +0200
+
libdrm (2.4.60-3) unstable; urgency=medium
[ Timo Aaltonen ]
diff -u
libdrm-2.4.60/debian/patches/Fix
Source: libdrm
Version: 2.4.60-3
Severity: important
Justification: fails to build from source (but built successfully in the past)
Hi,
your last kFreeBSD patch added an unconditional inclusion of
the header. Unfortunately, people on Linux don’t
like it and deprecated it to the point it’s a hard
Fun fact:
Install xserver-xorg-video-nouveau:x32 (1:1.0.11-1)
Reboot
Start an i386 Mozilla™ Firefox™ binary, or some other
application using X-server-side OpenGL
Watch it crash
[ 378.186605] firefox[4521]: segfault at c ip f18c78b4 sp
ff93538c error 4 in libxcb-glx.so.0.0.0[f
Package: libgl1-mesa-glx
Version: 10.2.5-1
Severity: normal
Hi!
After crossgrading from i386 to x32, OpenGL applications crash.
glxgears from mesa-utils:i386 (8.2.0-1) works, but
glxgears from mesa-utils:x32 (8.2.0-1) fails:
Program received signal SIGSEGV, Segmentation fault.
0xf76db60b in glL
On Thu, 17 Jul 2014, Jan Vesely wrote:
> why not use __attribute__ ((aligned(X))) for explicit padding?
That’s ① GCC-specific and ② relies on environmental guarantees
that cannot always be given (e.g. you cannot align a struct
more than the stack alignment if it is ever passed on the
stack; for s
etty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font. -- Rob Pike in "Notes on Programming in C"From: Thorsten Glaser
On Thu, 17 Jul 2014, Eero Tamminen wrote:
> While effect of unaligned accesses is normally invisible,
No, the compiler is inserting padding here silently.
We call this “implicit padding”. The problem with it
is that this padding is architecture-dependent, and
some platforms have other alignment r
On Wed, 16 Jul 2014, John Paul Adrian Glaubitz wrote:
> Absolutely. Could the upstream Mesa developers maybe apply the patch
> as well?
They are not taking us for real, see #728053 for their feedback…
> We're putting lots of efforts into the m68k port and we have many
> users who love running De
-10.2.3/debian/changelog
--- mesa-10.2.3/debian/changelog
+++ mesa-10.2.3/debian/changelog
@@ -1,3 +1,9 @@
+mesa (10.2.3-1+m68k.1) unreleased; urgency=low
+
+ * Fix struct alignment assumptions. (Closes: #728053)
+
+ -- Thorsten Glaser Tue, 15 Jul 2014 13:50:57 +0200
+
mesa (10.2.3-1) unstable
On Thu, 6 Mar 2014, Thomas Dickey wrote:
> ok I fixed the regression (as well as another one which doesn't affect
> Debian, but Fedora), and uploaded #303
OK, thanks. I’ve built me my own package, and can confirm
that it fixes this problem.
bye,
//mirabilos
--
tarent solutions GmbH
Rochusst
Thomas Dickey dixit:
>you may notice that the change was intentional (to fix a serious bug
>in contrast to a user-configurable preference).
Hm, which bug?
>So - to the point: is /bin/mksh in /etc/shells? If not, adding it
>there is the way to get your intended behavior. If it is, then
>there's
Package: xterm
Version: 302-1
Severity: important
Hi *,
I’ve got a script that dumps the contents of the environment at
startup to syslog, and just used it to investigate a user-visible
problem. tl;dr: the output of xterm -e dumpargs differs between
screen 301-1 (Debian) and 302-1 (Debian; no ide
Hi,
this is not a bug. The key labelled Alt is the Meta key, which
people use to write Umlauts and similar things:
http://fsinfo.noone.org/~abe/typing-8bit.html
xterm is a Unix terminal emulator. Unix terminals do not have
an Alt key, that is a PC/Windows® thing.
Applications such as irssi, tha
Source: xorg-server
Version: 2:1.14.99.3-1
Severity: important
Justification: fails to build from source (but built successfully in the past)
Hi,
trying to build xorg-server from experimental because it includes
a patch to support the Atari planes for the fbdev module, upstream.
Note that the ve
Matt Turner dixit:
>[sarcasm]How well does NV84 video decoding work on m68k these days
>anyway?[/sarcasm]
Dunno, but people do use PCI ATI Radeon cards on Ataris
(not yet with Linux for lack of a driver for the PCI bridge,
but can’t be long now that they already wrote one for the
USB host control
werfen,
⎜wenn er beim booten das chipmunks intro spielt
-- Forwarded message --
From: Julien Cristau
Message-ID: <20131106151538.gg4...@betterave.cristau.org>
X-Spam-Status: No, hits=0.00 required=0.90
To: Thorsten Glaser , 728...@bugs.debian.org
Date: Wed, 6 No
2.2/debian/changelog
--- mesa-9.2.2/debian/changelog
+++ mesa-9.2.2/debian/changelog
@@ -1,3 +1,9 @@
+mesa (9.2.2-1+m68k.1) unreleased; urgency=low
+
+ * Fix struct alignment assumptions. (Closes: #728053)
+
+ -- Thorsten Glaser Wed, 30 Oct 2013 18:05:12 +0100
+
mesa (9.2.2-1) unstable; urgency=low
severity 693194 important
thanks
Indeed!
tglase@tglase:~ $ DISPLAY=:2 twm
twm: unable to open fontset "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-*-*"
Fails. (:2 is a tightvncserver I just started without wm,
since IceWM seems to segfault in sid right now.)
tglase@tglase:~ $ LC_ALL=C DISPLA
Julien Cristau dixit:
>you want to send that to your buildd, not uninterested parties.
The buildd was bcc'd, but the maintainer might just be interested.
bye,
//mirabilos
--
Sorry, I’m annoyed today and you came by as an Arch user. These are the
perfect victims for any crime against humanity,
fail
input: ../../test/input.c:1359: dix_valuator_alloc: Assertion `((void *)
v->axisVal - (void *) v) % sizeof(double) == 0' failed.
Testing double to FP1616/FP3232 conversions
Testing bits_to_bytes()
/bin/bash: line 5: 5344 Aborted MALLOC_PERTURB_=15 ${dir}$tst
--
To UNSUBSC
Hi,
FWIW: the BSD wscons(4) text console does the same,
and it always annoys me that Linux’ doesn’t…
bye,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas.
68k.1) unreleased; urgency=low
+
+ * Build-Depends += libatomic-ops-dev [m68k] (Closes: #654329)
+
+ -- Thorsten Glaser Sat, 16 Jun 2012 22:09:11 +
+
libdrm (2.4.33-1) unstable; urgency=low
* New upstream release.
diff -u libdrm-2.4.33/debian/control libdrm-2.4.33/debian/control
--- l
Dixi quod…
>Andreas Schwab dixit:
>
>> mesa FTBFS on m68k due to lack of GCC atomic intrinsics. (Why are
>> they (still) missing, anyway?) Ib>>>
>
They are now implemented in 4.7.
>>>
>>> Can they easily be backported to Debian's gcc 4.x (x = 6?)?
>>
>>Probably.
>
>Seems so. I’m tryin
Geert Uytterhoeven dixit:
>CAS is a read-modify-write instruction, which is not guaranteed to work
>on all m68k platforms (hence the existence of CONFIG_RMW_INSNS in
>the kernel).
All platforms currently supported by Debian (that is, not Coldfire and
with MMU) should have it, right? I think other
. (Closes: #654630)
+
+ -- Thorsten Glaser Sun, 08 Jan 2012 17:23:47 +
+
mesa (7.11.2-1) unstable; urgency=low
* New upstream release:
diff -Nru mesa-7.11.2/debian/patches/15-m68k-atomic-ops.diff
mesa-7.11.2/debian/patches/15-m68k-atomic-ops.diff
--- mesa-7.11.2/debian/patches/15-m68k
Hi,
I could try my hands at making a patch to let it use libatomic-ops-dev
on m68k, unless someone has got a better idea. No guarantees I could
succeed though (not a porter nor an X developer).
bye,
//mirabilos
--
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting,
Source: mesa
Version: 7.11.2-1
Hi,
mesa FTBFS (with gcc-4.6) with error messages like these:
/tmp/buildd/mesa-7.11.2/build/dri/src/gallium/drivers/r600/../../../../src/gallium/auxiliary/util/u_atomic.h:151:
undefined reference to _sync_sub_and_fetch_4'
This is due to it using GCC Atomic built
ibdrm-2.4.29/debian/changelog 2012-01-02 22:17:19.0 +
+++ libdrm-2.4.29/debian/changelog 2012-01-02 22:19:58.0 +
@@ -1,3 +1,9 @@
+libdrm (2.4.29-1+m68k.1) unreleased; urgency=low
+
+ * [m68k] B-D on libatomic-ops-dev to fix FTBFS
+
+ -- Thorsten Glaser Mon, 02 Jan
Cyril Brulebois dixit:
>That's what we have in stable, so it might well be that I didn't bother
OK.
>to bump the version. What's your use case for using pre-stable software?
Right now, building build-depends of packages without building
_all_ of X manually, on m68k (which is pretty dusty). It’s
Source: libpciaccess
Version: 0.12.902-1
B-D on (among others): xutils-dev (>= 1:7.5)
FTBFS against xutils-dev_7.5+1:
dh_autoreconf -O--builddirectory=build/ -O--parallel
configure.ac:41: error: xorg-macros version 1.8 or higher is required but 1.4.2
found
xutils-dev_7.5+4 seems to be enoug
Compose + ( + A + ) always worked for me.
bye,
//mirabilos
--
20:54⎜ dmaphy: remember: "In theory there's no difference
⎜ between theory and practice, but in practice..."
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact li
84 matches
Mail list logo
