Bug#1067207: mesa: switch statement too large, might need -mlong-jump-table-offsets

[Thorsten Glaser]

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

… in /etc/dpkg/buildflags.conf in the chroot. An equivalent patch
for d/rules would be:

--- debian/rules~   2024-04-01 23:29:11.0 +0200
+++ debian/rules2024-04-01 23:31:39.379936168 +0200
@@ -18,7 +18,11 @@

 export DEB_BUILD_MAINT_OPTIONS=optimize=-lto

-ifeq (,$(filter $(DEB_HOST_ARCH), armhf ppc64el sh3 sh4))
+ifneq (,$(filter $(DEB_HOST_ARCH), m68k))
+# This library has huge jump tables: Debian #1067207
+buildflags = \
+   $(shell DEB_CFLAGS_MAINT_APPEND='-Wall -mlong-jump-table-offsets' 
DEB_CXXFLAGS_MAINT_APPEND='-Wall -mlong-jump-table-offsets' dpkg-buildflags 
--export=configure)
+else ifeq (,$(filter $(DEB_HOST_ARCH), armhf ppc64el sh3 sh4))
 buildflags = \
$(shell DEB_CFLAGS_MAINT_APPEND=-Wall DEB_CXXFLAGS_MAINT_APPEND=-Wall 
dpkg-buildflags --export=configure)
 else

While there, you might want to consider changing these
nested ifs to the new gmake else-if model or perhaps
sorting it, or even changing to something like:

--- debian/rules~   2024-04-01 23:29:11.0 +0200
+++ debian/rules2024-04-01 23:36:10.368947470 +0200
@@ -18,20 +18,25 @@
 
 export DEB_BUILD_MAINT_OPTIONS=optimize=-lto
 
-ifeq (,$(filter $(DEB_HOST_ARCH), armhf ppc64el sh3 sh4))
-buildflags = \
-   $(shell DEB_CFLAGS_MAINT_APPEND=-Wall DEB_CXXFLAGS_MAINT_APPEND=-Wall 
dpkg-buildflags --export=configure)
-else
-  ifneq (,$(filter $(DEB_HOST_ARCH), armhf))
-  # Workaround for a variant of LP: #725126
-  buildflags = \
-   $(shell DEB_CFLAGS_MAINT_APPEND="-Wall -fno-optimize-sibling-calls" 
DEB_CXXFLAGS_MAINT_APPEND="-Wall -fno-optimize-sibling-calls" dpkg-buildflags 
--export=configure)
-  else
-# Workaround for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
-buildflags = \
-   $(shell DEB_CFLAGS_MAINT_APPEND="-Wall -O1" 
DEB_CXXFLAGS_MAINT_APPEND="-Wall -O1" dpkg-buildflags --export=configure)
-  endif
+DEB_CFLAGS_MAINT_APPEND := -Wall
+DEB_CXXFLAGS_MAINT_APPEND := -Wall
+ifneq (,$(filter $(DEB_HOST_ARCH), armhf))
+# Workaround for a variant of LP: #725126
+DEB_CFLAGS_MAINT_APPEND += -fno-optimize-sibling-calls
+DEB_CXXFLAGS_MAINT_APPEND += -fno-optimize-sibling-calls
+else ifneq (,$(filter $(DEB_HOST_ARCH), m68k))
+# This library has huge jump tables: Debian #1067207
+DEB_CFLAGS_MAINT_APPEND += -mlong-jump-table-offsets
+DEB_CXXFLAGS_MAINT_APPEND += -mlong-jump-table-offsets
+else ifneq (,$(filter $(DEB_HOST_ARCH), ppc64el sh3 sh4))
+# Workaround for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
+DEB_CFLAGS_MAINT_APPEND += -O1
+DEB_CXXFLAGS_MAINT_APPEND += -O1
 endif
+buildflags = $(shell \
+   DEB_CFLAGS_MAINT_APPEND='$(DEB_CFLAGS_MAINT_APPEND)' \
+   DEB_CXXFLAGS_MAINT_APPEND='$(DEB_CXXFLAGS_MAINT_APPEND)' \
+   dpkg-buildflags --export=configure)
 
 EGL_PLATFORMS = x11
 GALLIUM_DRIVERS = swrast

bye,
//mirabilos
-- 
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

Bug#1067207: mesa: switch statement too large, might need -mlong-jump-table-offsets

[Thorsten Glaser]

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/meson-generated_.._nvk_cla097.c.o -c 
src/nouveau/headers/nvk_cla097.c
/tmp/ccrcAVyk.s: Assembler messages:
/tmp/ccrcAVyk.s:15766: Error: Adjusted signed .word (0x8002) overflows: 
`switch'-statement too large.
/tmp/ccrcAVyk.s:15766: Error: Adjusted signed .word (0x8008) overflows: 
`switch'-statement too large.
[…]

Not sure if it makes sense to exclude building this part of nouveau
on m68k (I do know someone who has added a PCI bus to his Atari and
runs a Radeon on it) or whether other files in this source package
also have huge jump tables.

Adding the -mlong-jump-table-offsets flag to CFLAGS on m68k should
unbreak this; bonus points if you add it to only the files where
it’s needed, if it’s only a few and not expected to change, for example.

Re: Bug#1026002: FTBFS gcc: error: LinuxMachineDefines: linker input file not found: No such file or directory

[Thorsten Glaser]

# 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 build from source for architecture riscv64,it complains:
>gcc: warning: LinuxMachineDefines: linker input file unused because linking 
>not done
>gcc: error: LinuxMachineDefines: linker input file not found: No such file or 
>directory

This is something done by imake, which is in the xutils-dev package,
it merely affects all packages that use imake for building.

Please take this up with the xutils-dev maintainers but ideally,
first figure out which versions worked and which stopped to work.

Thanks,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜ also warum machen die xorg Jungs eigentlich alles
kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?  -- ~/.Xmodmap wonders…

Bug#856271: Bug#999177: xfonts-*: missing required debian/rules targets build-arch and/or build-indep

[Thorsten Glaser]

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 should give the content of the diff enough space to not wrap.

I couldn’t find a way to do that, only to change it between linear
and tree.

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999

Bug#913468: xauth unknown command on startx, still pertinent

[Thorsten Glaser]

Hi,

this bug still exists.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Where is the X keyboard configuration magic?

[Thorsten Glaser]

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 to do that, and
/etc/default/keyboard is also correct. console-setup, kbd,
keyboard-configuration and xkb-data are installed.

Adding setkbmap to ~/.xsessionrc obviously “fixes” this,
but I’m curious why it didn’t work by default, and what
parts should normally come together to make it do that.

Please do Cc me in replies, as I’m not subscribed to the list.

Thanks in advance,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

imake: uses an argument to ar(1) which recent binutils changed in an incompatible way, causing packages using imake to FTBFS (was Re: Bug#997628: mgp: FTBFS: ar: libdeps specified more than once)

[Thorsten Glaser]

# 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 more
severity 981072 important
thanks

Lucas Nussbaum dixit:

>> ar clq libmgpimage.a  imagetypes.o send.o zio.o zoom.o new.o compress.o 
>> reduce.o value.o misc.o rotate.o rle.o rlelib.o smooth.o halftone.o 
>> clip.o   dither.o path.o bright.o window.o imlib_loader.o
>> ar: libdeps specified more than once

WTF, what does that even mean? *researches*

This is #981072, an incompatible(!) change in binutils, which I’d
consider of a rather serious severity but is tagged wontfix.

Basically, ar(1) in bullseye documents the ‘l’ modifier as…

   l   This modifier is accepted but not used.

… and ar(1) in sid reuses it in an incompatible way, with no
deprecation/warning period, instead of doing the sensible thing
and using a different, not currently used, flag.


Robert Luberda dixit:

>Quick search on sources of packages showed that there are about 30
>other packages that also call "ar clq", see [2] - that's why I'm writing

No, it’s far more than your search shows.


I’m tempted to reassign to binutils, but this would probably
be ignored. But I’ve got to reassign it anyway since the clq
is injected by imake(1). Which version(s) of binutils contain
this breaking change? (That is, does imake need a change in a
stable release?)

Doko, I urge you to request the upstream developers to change
this and use a currently-unused flag for their new feature. I
know getting them to do that, therefore admitting a mistake,
is going to be hard, but considering this is embedded in *so*
many build systems, they’re not going to make any friends by
breaking this.

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r

Bug#996417: xset: handle absence of DPMS support in the X server more gracefully

[Thorsten Glaser]

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
failed on the dpms keywords, it interprets the 0 as another argument,
instead of first parsing the "dpms [standby [suspend [off]]]" then exiting
as there are no further arguments:


server does not have extension for dpms option
xset:  unknown option 0

usage:  xset [-display host:dpy] option ...
To turn bell off:
-bb off   b 0
[…]


This is, of course, both suboptimal and avoidable by moving the parsing
of the dpms-related options to before the check for its presence.

-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages x11-xserver-utils depends on:
ii  cpp  4:10.2.1-1
ii  libc62.31-13+deb11u2
ii  libice6  2:1.0.10-1
ii  libx11-6 2:1.7.2-1
ii  libxaw7  2:1.0.13-1.1
ii  libxcursor1  1:1.2.0-2
ii  libxext6 2:1.3.3-1.1
ii  libxi6   2:1.7.10-1
ii  libxmu6  2:1.1.2-2+b3
ii  libxmuu1 2:1.1.2-2+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxt6   1:1.2.0-1
ii  libxxf86vm1  1:1.1.4-1+b2

x11-xserver-utils recommends no packages.

Versions of packages x11-xserver-utils suggests:
pn  cairo-5c
pn  nickle  
pn  xorg-docs-core  

-- no debconf information

Bug#988221: xterm: uses unescaped backslashes in manpage example

[Thorsten Glaser]

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
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

Bug#988221: xterm: uses unescaped backslashes in manpage example

[Thorsten Glaser]

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
  5c|\|

… but when copying this specific example into a larger string,
such as appending “abc”, it fails:

$ printf '\abc' | hd
  07 62 63  |.bc|

Doubling the backslash fixes this:

$ printf '\\abc' | hd
  5c 61 62 63   |\abc|

In the manpage, this will mean changing the sequence “\e'” to
“\e\e'” (as each ‘\e’ denotes a backslash in nroff escaping).




-- System Information:
Debian Release: 11.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages xterm depends on:
ii  libc6   2.31-12
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.4+dfsg-1
ii  libice6 2:1.0.10-1
ii  libtinfo6   6.2+20201114-2
ii  libutempter01.2.1-2
ii  libx11-62:1.7.0-2
ii  libxaw7 2:1.0.13-1.1
ii  libxext62:1.3.3-1.1
ii  libxft2 2.3.2-2
ii  libxinerama12:1.1.4-2
ii  libxmu6 2:1.1.2-2+b3
ii  libxpm4 1:3.5.12-1
ii  libxt6  1:1.2.0-1
ii  xbitmaps1.1.1-2.1

Versions of packages xterm recommends:
ii  x11-utils  7.7+5

Versions of packages xterm suggests:
pn  xfonts-cyrillic  

-- no debconf information

Re: Tentative summary of the AMD/ATI/NVidia issue

[Thorsten Glaser]

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?

(Perhaps doing this is a good idea in general, for when a
similar issue pops up in the future?)

bye,
//mirabilos
-- 
22:59⎜ glaub ich termkit is kompliziert | glabe nicht das man
damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil
zuviel bilder │ wie ein spiel | 23:00⎜ die meisten raffen auch
nicht mehr von windows | 23:01⎜ bilderbücher sind ja auch nich
wirklich verbreitet als erwachsenen literatur   ‣ who needs GUIs thus?

Bug#984615: xterm: bug in CVE-2021-27135 patch in at least stretch

[Thorsten Glaser]

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
>comprehensive bug report and to Sven for further debugging and taking
>a look.

You’re welcome.

>Thorsten, could you please test the latest upload and see if
>everything works alright for you?

I don’t actally have a testcase, I’ve just noticed that this is wrong
when trying to backport the patch further myself.

But it won’t hit the bug now.

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Bug#984615: xterm: bug in CVE-2021-27135 patch in at least stretch

[Thorsten Glaser]

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 further
up will check if the allocated size is sufficient, and, if so,
use screen->selection_data which was the pre-realloc address of
line.

>> I am glad and surprised that sid is okay and there doesn't seem to be

The code in sid completely differs (structures, variable names, etc).

>suggestion you could also apply the patches to the SaltTextAway()
>function from xterm 365e.

If 365e is like 366 (currently in sid), you’ll have lots of fun due
to the renamed everything.

I’d rather Tom changed xterm upstream to address the realloc-failure
difference. I know he reads Debian bugreports ;-) and he’s really
busy so probably takes longer to respond.

bye,
//mirabilos
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel

Bug#984615: xterm: bug in CVE-2021-27135 patch in at least stretch

[Thorsten Glaser]

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 must
be stored in the one handed out, too, so please change this to:

if ((have * 2) < (size_t) j) { 
Char *next = realloc(line, have + 1);
if (next) {
screen->selection_data = line = next;
screen->selection_size = have + 1;
}
}

This also deals properly with realloc failures (since we’re
shrinking, ignore them and just keep the older, larger area).

I’ve not looked at jessie-ELTS or buster-security whether they
are affected as well; sid is clean (and where I got the realloc
failure check necessity from, although sid’s free()s the buffer
if realloc fails; this isn’t needed @Tom).

bye,
//mirabilos
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh

Bug#980148: mesa-vulkan-drivers: file content conflict in Multi-Arch:same package

[Thorsten Glaser]

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": "/usr/lib/x86_64-linux-gnu/libvulkan_intel.so"
},
"file_format_version": "1.0.0"
}

x32:

{   
"ICD": {
"api_version": "1.2.145",
"library_path": "/usr/lib/x86_64-linux-gnux32/libvulkan_intel.so"
},
"file_format_version": "1.0.0"
}

This file must be moved out of /usr/share and into a multiarch library
path. This was discovered by mizvekov on IRC.


-- System Information:
Debian Release: bullseye/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages mesa-vulkan-drivers depends on:
ii  libc6   2.31-9
ii  libdrm2 2.4.103-2
ii  libexpat1   2.2.10-1
ii  libgcc-s1   10.2.1-3
ii  libstdc++6  10.2.1-3
ii  libvulkan1  1.2.162.0-1
ii  libwayland-client0  1.18.0-2~exp1.1
ii  libx11-xcb1 2:1.7.0-1
ii  libxcb-dri3-0   1.14-2.1
ii  libxcb-present0 1.14-2.1
ii  libxcb-randr0   1.14-2.1
ii  libxcb-sync11.14-2.1
ii  libxcb1 1.14-2.1
ii  libxshmfence1   1.3-1
ii  libzstd11.4.8+dfsg-1
ii  zlib1g  1:1.2.11.dfsg-2

mesa-vulkan-drivers recommends no packages.

mesa-vulkan-drivers suggests no packages.

Bug#975687: xterm: loses text lines, even descenders from some lines

[Thorsten Glaser]

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 m68k/SPARC/POWER/… machines,
and running X11 over various network protocols (X, VNC, RDP, NX, x2go),
with varying latencies.

If the solution for this issue with XCheckWindowEvent is dependent on
such things, I’d argue that not using XCheckWindowEvent is the correct
fix instead ☺

bye,
//mirabilos
--  
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

Bug#975687: xterm: loses text lines, even descenders from some lines

[Thorsten Glaser]

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, there's the changes for wrap-mark,
>and copy-wait.  The latter was just this:

I did…

begin 644 xterm_362-1.0.1.debdiff
M9`M3G)U('AT97)M+3,V,B]D96)I86XO8VAA;F=E;&]G('AT97)M+3,V
M,B]D96)I86XO8VAA;F=E;&]G"BTM+2!X=&5R;2TS-C(O9&5B:6%N+V-H86YG
M96QO9PDR,#(P+3$Q+3$U(#$V.C,T.C,V+C`P,#`P,#`P,"`K,#$P,`HK*RL@
M>'1E'1E3UM961I=6T**PHK("`J($YO
M;BUM86EN=&%I;F5R('5P;&]A9"X**R`@*B!497-T('!A=&-H("@C.3'1E'!O2P@5E=I;F1O=RAS8W)E96XI+"!%
M>'!O2D["BL@"7-W:71C:"`HPHK(`EC87-E($5X<&]S93H**R`)("`@($AA;F1L945X<&]S=7)E*'AW+"`F
M'1E

Bug#975687: xterm: loses text lines, even descenders from some lines

[Thorsten Glaser]

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 reproduce this if I change your script from while true
to for x in 1 2 3 (so it does that only three times) but, and
this is important, move the xterm so that its bottom is below
the bottom end of the X11 screen.

If I move the syslog terminal up by a few pixels, the problem
does not happen.

If I use other terminal, font, etc. sizes, I also get display
corruption effects which vary (see screenshot).

If I switch virtual workspaces (Ctrl-Alt-[1-8←→] in evilwm)
the effects go away as well.

Maybe you can reproduce it with this info?

Thanks,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜ also warum machen die xorg Jungs eigentlich alles
kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?  -- ~/.Xmodmap wonders…

Bug#975687: xterm: loses text lines, even descenders from some lines

[Thorsten Glaser]

On Sun, 20 Dec 2020, Thorsten Glaser wrote:

> corruption effects which vary (see screenshot).

Oops, attached.

Bug#975687: xterm: loses text lines, even descenders from some lines

[Thorsten Glaser]

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 360-1 did not have
the bug, 361-1 did, and when recompiling 360-1 unchanged
in a current unstable chroot, it also doesn’t have the
bug, so it’s not something else that changed.

Looking at debian/patches/ in 361-1 it also doesn’t change
any of the code, so I guess it’s some upstream change.

>If I can reproduce it, I'll see what I can do.

If not but you still have patches I could test, send them
and I’ll apply them and rebuild locally. If you need the
trace, I’ll also do that, but not tonight…

bye,
//mirabilos
-- 
21:12⎜ sogar bei opensolaris haben die von der community so
ziemlich jeden mist eingebaut │ man sollte unices nich so machen das
desktopuser zuviel intresse kriegen │ das macht die code base kaputt
21:13⎜ linux war früher auch mal besser :DScript started on 2020-11-27 00:46:29+01:00 [TERM="screen" TTY="/dev/pts/15" 
COLUMNS="113" LINES="34"]
tglase@tglase-nb:~ $ /usr/bin/xterm +sb -fg black -geom 90x11+475+637 
-report-fonts -bg cornflowerblue -e tail 
+sb -fg black -geom 90x11+475+637 -report-fonts -bg cornflowerblue -e tail  
   <-F 
/var/log/syslog


Loaded VTFonts(default)

fNorm: -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1

all chars: no

default char:  0

direction: 0

ascent:11

descent:   2

first char:0

last char: 65535

maximum-chars: 65536

missing-chars: 61413

present-chars: 4123

min_byte1: 0

max_byte1: 255

properties:22

min_bounds:

lbearing: 0

rbearing: 0

width:6

ascent:   -1

descent:  -10

max_bounds:

lbearing: 5

rbearing: 6

width:6

ascent:   11

descent:  2

fBold: -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1

all chars: no

default char:  0

direction: 0

ascent:11

descent:   2

first char:0

last char: 65535

maximum-chars: 65536

missing-chars: 61413

present-chars: 4123

min_byte1: 0

max_byte1: 255

properties:22

min_bounds:

lbearing: 0

rbearing: 0

width:6

ascent:   -1

descent:  -10

max_bounds:

lbearing: 5

rbearing: 6

width:6

ascent:   11

descent:  2

fWide: -misc-fixed-medium-r-normal-ja-13-120-75-75-c-120-iso10646-1

all chars: no

default char:  0

direction: 0

ascent:11

descent:   2

first char:0

last char: 65535

maximum-chars: 65536

missing-chars: 46328

present-chars: 19208

min_byte1: 0

max_byte1: 255

properties:23

min_bounds:

lbearing: 0

rbearing: 0

width:12

ascent:   -1

descent:  -10

max_bounds:

lbearing: 11

rbearing: 12

width:12

ascent:   11

descent:  2

fWBold: -misc-fixed-medium-r-normal-ja-13-120-75-75-c-120-iso10646-1

all chars: no

default char:  0

direction: 0

ascent:11

descent:   2

first char:0

last char: 65535

maximum-chars: 65536

missing-chars: 46328

present-chars: 19208

min_byte1: 0

max_byte1: 255

properties:23

min_bounds:

Bug#975687: xterm: loses text lines, even descenders from some lines

[Thorsten Glaser]

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 (if it's not specific to #362), a lot of the
>font/display problems aren't xterm (and if the problem doesn't show up
>on macOS, I wouldn't notice it right away).

Hmmh. It’s a regular X11 BDF/PCF font, so at least the
ugly fontconfig/freetype/… combination doesn’t affect
this, but as such you indeed won’t be able to see this
on a Macintosh.

Since I can _somewhat_ reproduce this (three “sudo true”
in quick succession did it right now), I could try to
bisect releases until I find one, if that helps?

bye,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜ also warum machen die xorg Jungs eigentlich alles
kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?  -- ~/.Xmodmap wonders…

Bug#975687: xterm: loses text lines, even descenders from some lines

[Thorsten Glaser]

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 cornflowerblue -e tail -F /var/log/syslog &

… to monitor the system on my laptop.

Recently, I’ve noticed that the right (syslog) window reliably
loses some text lines when multiple lines end up in syslog in
the same second, which tail would then also output very quickly.

I can’t find these lines when scrolling up with Shift-PgUp,
and when I select them with the mouse the spook ends(the text
is shown, in inverse as usual, again and (when deselected) in
normal colour), so it definitively is a display issue in xterm.

I can somewhat reproduce it with “sudo true” given I have…

*.* -/var/log/syslog

… in /etc/syslog.conf.

The log lines in question (hard-wrapped to match xterm’s soft):

Nov 25 06:23:43 tglase-nb sudo: pam_unix(sudo:session): session opened for user 
root by tg
lase(uid=0)
Nov 25 06:23:43 tglase-nb sudo: pam_unix(sudo:session): session closed for user 
root
Nov 25 06:23:45 tglase-nb sudo:   tglase : TTY=pts/2 ; PWD=/home/tglase ; 
USER=root ; COMM
AND=/bin/true

The line with 'TTY=pts/2' is the one that gets hidden, but,
interestingly enough, the descender of the “g” and “p” in
the line above (session closed) *also* go away.

~/.Xresources sets a pretty standard font:

XTerm*VT100*font:   
-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1



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

Kernel: Linux 5.9.0-3-amd64 (SMP w/2 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages xterm depends on:
ii  libc6   2.31-4
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.2+dfsg-4
ii  libice6 2:1.0.10-1
ii  libtinfo6   6.2+20201114-1
ii  libutempter01.1.6-6
ii  libx11-62:1.6.12-1
ii  libxaw7 2:1.0.13-1+b2
ii  libxext62:1.3.3-1+b2
ii  libxft2 2.3.2-2
ii  libxinerama12:1.1.4-2
ii  libxmu6 2:1.1.2-2+b3
ii  libxpm4 1:3.5.12-1
ii  libxt6  1:1.2.0-1
ii  xbitmaps1.1.1-2

Versions of packages xterm recommends:
ii  x11-utils  7.7+5

Versions of packages xterm suggests:
pn  xfonts-cyrillic  

-- no debconf information

Bug#953032: Internal error: Could not resolve keysym XF86FullScreen

[Thorsten Glaser]

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 part of my .xinitrc, so xkb is not needed.)


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

Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages x11-xkb-utils depends on:
ii  libc62.29-10
ii  libx11-6 2:1.6.9-2
ii  libxaw7  2:1.0.13-1+b2
ii  libxkbfile1  1:1.0.9-2+b12
ii  libxt6   1:1.1.5-1+b3

x11-xkb-utils recommends no packages.

x11-xkb-utils suggests no packages.

-- no debconf information

Bug#912325: glamor0: GL error: GL_OUT_OF_MEMORY in glBufferData, GL_INVALID_OPERATION, X server crashes

[Thorsten Glaser]

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 me.

So this needs to be fixed in the kernel and/or mesa, or I have to
switch to the non-free packages ☹

Are there corresponding bugreports in linux/mesa already?

bye,
//mirabilos
-- 
 ch: good, you corrected yourself. ppl tend to tweet such news
immediately, sth. like "grml devs seem to be buyable" dileks: we
_are_. if you throw enough money in our direction, things will happen
 everyone is buyable, it's just a matter of priceand now
comes [mira] and uses this as a signature ;0   -- they asked for it…

Bug#945962: libgl1: still uses Priority: extra

[Thorsten Glaser]

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 package?
ftpmasters determine Section and Priority in the archive,
not the packages themselves.

bye,
//mirabilos
-- 
 Beware of ritual lest you forget the meaning behind it.
 yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.

Bug#945963: libgles2: still uses Priority: extra

[Thorsten Glaser]

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 Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-1-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages libgles2 depends on:
ii  libc6  2.29-3
ii  libglvnd0  1.1.0-1+b1

libgles2 recommends no packages.

libgles2 suggests no packages.

Versions of packages libgles2 is related to:
pn  libgl1-nvidia-glx-any  

-- no debconf information

Bug#945962: libgl1: still uses Priority: extra

[Thorsten Glaser]

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 Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-1-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages libgl1 is related to:
pn  libgl1-nvidia-glx-any  

Bug#758094: libgl1-mesa-glx:x32: SIGSEGV in OpenGL applications on x32

[Thorsten Glaser]

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’ve managed to persuade apt and dpkg ☻

It built fine (log attached) and works in xrdp (I’m currently at home
and could test only remotely).

In xrdp+xorgxrdp, glxgears’ performance shrinks from ~280 fps with
mesa 18.3.6-2 to ~275 fps with git master. That’s less than 2% and
probably partially due to the major version bump so I’d not count
it as a loss.

I can test this on the native nouveau hardware on Monday.

bye,
//mirabilos

PS: Do check the build log, especially lintian at the end… ☻☺
-- 
 den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt…
oder netzteile, an die man auch den monitor angeschlossen hat und die dann für
ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder
LAN party │  damals, als der pizzateig noch auf dem monior "gegangen" ist

mesa_19.2.0-2_x32.build.xz
Description: Binary data

Bug#932733: fixed in git

[Thorsten Glaser]

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 Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#940626: uxterm: please lessen dependency on locales

[Thorsten Glaser]

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 that following my fea‐
ture request for such locale.

> (I forget exactly, but my first sighting of this was from the Cygwin crowd -
> there was a long thread on austin-review a few years later).

After reading your eMail I thought “huh, Cygwin doesn’t have locale
support *at all*” and checked and apparently, they added it in the
1.7 version, which is much more recent (and which I’ve never installed).

> > in all operating systems):
> 
> still, a bad idea regarding interoperability (in case one uses ssh,
> passing the locale settings from one machine to another).

I’ve had enough grief with en_US.{utf8,UTF-8} in mksh’s testsuite
to request a C.UTF-8 locale. Considering “most” remote systems are
Debian or comparable¹ nowadays, locales-all is not normally installed
and d-i does not generate the en_US.UTF-8 locale, a switch to C.UTF-8
would actually i̲m̲p̲r̲o̲v̲e̲ this situation.

① Added to Arch Linux in task 59737, Red Hat BZ#902094, Fedora too,
  and OpenSuSE also carries it… oh, PEP 538 even talks about the
  glibc developers (upstream) “are working towards making the C.UTF-8
  locale universally available”… seems my idea gained traction.

  And many systems just do a !stristr(setlocale(…), "UTF-8").

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 Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#801614: xserver-xorg-legacy: ask for needs_root_rights in Xwrapper.config

[Thorsten Glaser]

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 settings will be already correct (we do not install
X by default but wish to prepare for it).

-- System Information:
Debian Release: bullseye/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages xserver-xorg-legacy depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  libaudit1  1:2.8.5-2
ii  libbsd00.10.0-1
ii  libc6  2.29-1
ii  xserver-common 2:1.20.4-1

xserver-xorg-legacy recommends no packages.

xserver-xorg-legacy suggests no packages.

-- debconf information:
  xserver-xorg-legacy/xwrapper/actual_allowed_users: anybody
  xserver-xorg-legacy/xwrapper/allowed_users: Anybody

Bug#940626: uxterm: please lessen dependency on locales

[Thorsten Glaser]

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)
# Yes, I know this is not the same - but why are you
# here then?
-   value=en_US
+   value=C
;;
esac
break
@@ -87,7 +87,7 @@ if test $found != yes ; then
value=`echo ${value} |sed -e 's/[.@].*//'`.UTF-8
else
name="LC_CTYPE"
-   value="en_US.UTF-8"
+   value="C.UTF-8"
fi
eval save=\$${name}
eval ${name}=${value}


-- System Information:
Debian Release: bullseye/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages xterm depends on:
ii  libc6   2.29-1
ii  libfontconfig1  2.13.1-2+b1
ii  libfreetype62.9.1-4
ii  libice6 2:1.0.9-2
ii  libtinfo6   6.1+20190803-1
ii  libutempter01.1.6-3
ii  libx11-62:1.6.7-1
ii  libxaw7 2:1.0.13-1+b2
ii  libxext62:1.3.3-1+b2
ii  libxft2 2.3.2-2
ii  libxinerama12:1.1.4-2
ii  libxmu6 2:1.1.2-2+b3
ii  libxpm4 1:3.5.12-1
ii  libxt6  1:1.1.5-1+b3
ii  xbitmaps1.1.1-2

Versions of packages xterm recommends:
ii  x11-utils  7.7+4

Versions of packages xterm suggests:
pn  xfonts-cyrillic  

-- no debconf information

Bug#932733: mesa: FTBFS on x32: usr/share/vulkan/explicit_layer.d/*.json, libVkLayer_MESA_overlay.so not built but attempted to be installed

[Thorsten Glaser]

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
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 Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#912325: glamor0: GL error: GL_OUT_OF_MEMORY in glBufferData, GL_INVALID_OPERATION

[Thorsten Glaser]

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 terminated 
unexpectedly
Aug 21 02:46:34 tglase kdm: :0[2919]: pam_unix(kdm:session): session closed for 
user tglase

I’ll attach the X log with the backtrace.


-- 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-compatible devices on PCI bus:
--
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 
8400 GS Rev. 3] [10de:10c3] (rev a2)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 0 May 18  2015 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-19)) #1 SMP Debian 4.19.37-6 (2019-07-18)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 26484 Dec  9  2016 /var/log/Xorg.10.log
-rw-r--r-- 1 root root 43494 Aug 21 12:59 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[2366640.337] 
X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
[2366640.337] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[2366640.337] Current Operating System: Linux tglase.lan.tarent.de 
4.19.0-5-amd64 #1 SMP Debian 4.19.37-6 (2019-07-18) x86_64
[2366640.337] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 
root=/dev/mapper/vg--tglase-lv--tglase ro rootdelay=5 net.ifnames=0 
syscall.x32=y vsyscall=emulate kaslr l1tf=flush,nosmt
[2366640.337] Build Date: 05 March 2019  08:11:12PM
[2366640.337] xorg-server 2:1.20.4-1 (https://www.debian.org/support) 
[2366640.337] Current version of pixman: 0.36.0
[2366640.337]   Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[2366640.337] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[2366640.337] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Aug 21 02:46:34 
2019
[2366640.337] (==) Using config file: "/etc/X11/xorg.conf"
[2366640.337] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[2366640.337] (==) No Layout section.  Using the first Screen section.
[2366640.337] (==) No screen section available. Using defaults.
[2366640.337] (**) |-->Screen "Default Screen Section" (0)
[2366640.337] (**) |   |-->Monitor ""
[2366640.338] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[2366640.338] (==) Automatically adding devices
[2366640.338] (==) Automatically enabling devices
[2366640.338] (==) Automatically adding GPU devices
[2366640.338] (==) Max clients allowed: 256, resource mask: 0x1f
[2366640.338] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[2366640.338]   Entry deleted from font path.
[2366640.338] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[2366640.338] (==) ModulePath set to "/usr/lib/xorg/modules"
[2366640.338] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[2366640.338] (II) Loader magic: 0x56807e00
[2366640.338] (II) Module ABI versions:
[2366640.338]   X.Org ANSI C Emulation: 0.4
[2366640.338]   X.Org Video Driver: 24.0
[2366640.338]   X.Org XInput driver : 24.1
[2366640.338]   X.Org Server Extension : 10.0
[2366640.339] (++) using VT number 7

[2366640.339] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[2366640.340] (II) xfree86: Adding drm device (/dev/dri/card0)
[2366640.350] (--) PCI:*(2@0:0:0) 10de:10c3:3842:1301 rev 162, Mem @ 
0xf900/16777216, 0xd000/268435456, 0xee00/33554432, I/O @ 
0xdf00/128, BIOS @ 0x/131072
[2366640.350] (II) LoadModule: "glx"
[2366640.350] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[2366640.352] (II) Module glx: vendor="X.Org Foundation"
[2366640.352]   compiled for 1.20.4, module version = 1.0.0

Bug#934776: xserver-xorg-video-intel: spelling mistake in package description

[Thorsten Glaser]

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 encountered crashes during zooming in
a map on a website with modesetting, and modesetting has OpenGL 2.x
only — does a comparison exist? I’m on an IBM X61 with GM965.)

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages xserver-xorg-video-intel depends on:
ii  libc6  2.28-10
ii  libdrm-intel1  2.4.97-1
ii  libdrm22.4.97-1
ii  libpciaccess0  0.14-1
ii  libpixman-1-0  0.36.0-1
ii  libudev1   241-7
ii  libx11-6   2:1.6.7-1
ii  libx11-xcb12:1.6.7-1
ii  libxcb-dri2-0  1.13.1-2
ii  libxcb-dri3-0  1.13.1-2
ii  libxcb-sync1   1.13.1-2
ii  libxcb-util0   0.3.8-3+b2
ii  libxcb11.13.1-2
ii  libxcursor11:1.2.0-2
ii  libxdamage11:1.1.5-1
ii  libxext6   2:1.3.3-1+b2
ii  libxfixes3 1:5.0.3-1
ii  libxinerama1   2:1.1.4-2
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  libxshmfence1  1.3-1
ii  libxss11:1.2.3-1
ii  libxtst6   2:1.2.3-1
ii  libxv1 2:1.0.11-1
ii  libxvmc1   2:1.0.10-1
ii  xserver-xorg-core [xorg-video-abi-24]  2:1.20.4-1

xserver-xorg-video-intel recommends no packages.

xserver-xorg-video-intel suggests no packages.

Bug#912325: glamor0: GL error: GL_OUT_OF_MEMORY in glBufferData, GL_INVALID_OPERATION

[Thorsten Glaser]

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-compatible devices on PCI bus:
--
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 
8400 GS Rev. 3] [10de:10c3] (rev a2)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 0 May 18  2015 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-5 (2019-06-19)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 26484 Dec  9  2016 /var/log/Xorg.10.log
-rw-r--r-- 1 root root 35533 Jul 24 17:05 /var/log/Xorg.0.log

Contents of the crashed Xorg X server log file (/var/log/Xorg.0.log.old):
-
[41.050] 
X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
[41.050] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[41.050] Current Operating System: Linux tglase.lan.tarent.de 
4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64
[41.050] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 
root=/dev/mapper/vg--tglase-lv--tglase ro rootdelay=5 net.ifnames=0 
syscall.x32=y vsyscall=emulate kaslr l1tf=flush,nosmt
[41.050] Build Date: 05 March 2019  08:11:12PM
[41.050] xorg-server 2:1.20.4-1 (https://www.debian.org/support) 
[41.050] Current version of pixman: 0.36.0
[41.050]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[41.050] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[41.050] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jul 18 16:06:30 
2019
[41.084] (==) Using config file: "/etc/X11/xorg.conf"
[41.084] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[41.129] (==) No Layout section.  Using the first Screen section.
[41.129] (==) No screen section available. Using defaults.
[41.129] (**) |-->Screen "Default Screen Section" (0)
[41.129] (**) |   |-->Monitor ""
[41.129] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[41.129] (==) Automatically adding devices
[41.129] (==) Automatically enabling devices
[41.129] (==) Automatically adding GPU devices
[41.129] (==) Max clients allowed: 256, resource mask: 0x1f
[41.254] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[41.254]Entry deleted from font path.
[41.314] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[41.314] (==) ModulePath set to "/usr/lib/xorg/modules"
[41.314] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[41.314] (II) Loader magic: 0x567bce00
[41.314] (II) Module ABI versions:
[41.314]X.Org ANSI C Emulation: 0.4
[41.314]X.Org Video Driver: 24.0
[41.314]X.Org XInput driver : 24.1
[41.314]X.Org Server Extension : 10.0
[41.315] (++) using VT number 7

[41.315] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[41.316] (II) xfree86: Adding drm device (/dev/dri/card0)
[41.326] (--) PCI:*(2@0:0:0) 10de:10c3:3842:1301 rev 162, Mem @ 
0xf900/16777216, 0xd000/268435456, 0xee00/33554432, I/O @ 
0xdf00/128, BIOS @ 0x/131072
[41.326] (II) LoadModule: "glx"
[41.370] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[41.630] (II) Module glx: vendor="X.Org Foundation"
[41.630]compiled for 1.20.4, module version = 1.0.0
[41.630]ABI class: X.Org Server Extension, version 10.0
[41.748] (==) Matched modesetting as autoconfigured driver 0
[41.748] (==) Matched fbdev as autoconfigured driver 1
[41.748] (==) Matched vesa as autoconfigured driver 2
[41.748] (==) Assigned the driver to the xf86ConfigLayout
[41.748] (II) LoadModule: "modesetting"
[41.766] (II) Loading 

Bug#932733: mesa: FTBFS on x32: usr/share/vulkan/explicit_layer.d/*.json, libVkLayer_MESA_overlay.so not built but attempted to be installed

[Thorsten Glaser]

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=x32=19.1.2-1=1563475274=0

[…]
# Copy the hardlinked vdpau drivers correctly.  
 
install -m755 -d debian/mesa-vdpau-drivers/usr/lib/x86_64-linux-gnux32/vdpau/   
 
mv debian/tmp/usr/lib/x86_64-linux-gnux32/vdpau/libvdpau*.so* \ 
 
   debian/mesa-vdpau-drivers/usr/lib/x86_64-linux-gnux32/vdpau/ 
 
# Copy the hardlinked va drivers correctly. 
 
install -m755 -d debian/mesa-va-drivers/usr/lib/x86_64-linux-gnux32/dri/
 
mv debian/tmp/usr/lib/x86_64-linux-gnux32/dri/*_drv_video.so \  
 
   debian/mesa-va-drivers/usr/lib/x86_64-linux-gnux32/dri/  
 
dh_install -a   
 
dh_install: Cannot find (any matches for) 
"usr/share/vulkan/explicit_layer.d/*.json" (tried in ., debian/tmp)

 
dh_install: mesa-vulkan-drivers missing files: 
usr/share/vulkan/explicit_layer.d/*.json  
dh_install: Cannot find (any matches for) 
"usr/lib/*/libVkLayer_MESA_overlay.so" (tried in ., debian/tmp)

 
dh_install: mesa-vulkan-drivers missing files: 
usr/lib/*/libVkLayer_MESA_overlay.so  
dh_install: missing files, aborting 
 
make[1]: *** [debian/rules:210: override_dh_install] Error 255  
 
make[1]: Leaving directory '/<>'   
 
make: *** [debian/rules:244: binary-arch] Error 2   
 
dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess returned 
exit status 2

Bug#921657: xvfb-run: -e /dev/stderr does not work

[Thorsten Glaser]

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: cannot create /dev/stderr: Permission 
denied
+ rv=2


This could probably worked around by opening the error file
early, onto a higher file descriptor.

Bug#901249: (xterm: translation overrides for copy/paste do not work as documented): fixed in xterm 338-1

[Thorsten Glaser]

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 concurrent requests for different selection targets will
>be stored/retrieved independently (Closes: #901249).

Thanks a lot, this now works as expected and will raise my
productivity somewhat (and makes fire under my arse to port
the newer xterm to MirBSD/XFree86 so I can use it there as
well… when I last tried to upgrade its xterm (200 → 215) I
failed at merging the local patches inherited from OpenBSD,
but perhaps they are redundant now?).

Ondřej, I think your translation should now work again.

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 Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#913468: startx: doesn't cope with multiple xauth cookies

[Thorsten Glaser]

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@tglase-nb:~ $ xauth list
tglase-nb.lan.tarent.de/unix:0  MIT-MAGIC-COOKIE-1  
fc863a474bbaf9d38bd7cffbd7bba100
tglase@tglase-nb:~ $ xauth add :0 . $(mcookie)
tglase@tglase-nb:~ $ xauth list
tglase-nb.lan.tarent.de/unix:0  MIT-MAGIC-COOKIE-1  
0e3aea779d160c8308c57f3923debe8f

So, similar misbehaviour, but :0 is added as hostname/unix:0.
No idea where the duplicate other entry comes from.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#913468: startx: doesn't cope with multiple xauth cookies

[Thorsten Glaser]

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  
1d91628277c6a2e586377f11ad5e94c4
tglase-nb.lan.tarent.de:0  MIT-MAGIC-COOKIE-1  1d91628277c6a2e586377f11ad5e94c4
tglase-nb.lan.tarent.de:0  MIT-MAGIC-COOKIE-1  1d91628277c6a2e586377f11ad5e94c4

The actual cookie is now different every session, but we see
that the duplicate is there. So chances are this issue will
pop up over the lifetime of a $HOME in all startx users.

startx adds the cookie twoce in line 203 (since the previous
.Xauthority was empty, $authcookie also is, so we hit this
one instead of line 209 from my initial report). I don’t have
an idea why :0 is added as hostname:0 though.

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:

tglase@tglase-nb:~ $ xauth list 

tglase-nb.lan.tarent.de/unix:0  MIT-MAGIC-COOKIE-1  
1d91628277c6a2e586377f11ad5e94c4
tglase-nb.lan.tarent.de:0  MIT-MAGIC-COOKIE-1  65cf22362c15bf009a13d32c115f
tglase-nb.lan.tarent.de:0  MIT-MAGIC-COOKIE-1  65cf22362c15bf009a13d32c115f
tglase@tglase-nb:~ $ xauth add tglase-nb.lan.tarent.de:0 . $(mcookie)   

tglase@tglase-nb:~ $ xauth list 

tglase-nb.lan.tarent.de/unix:0  MIT-MAGIC-COOKIE-1  
2f2178f0974e8b0e3654eb084e469b39
tglase-nb.lan.tarent.de:0  MIT-MAGIC-COOKIE-1  2f2178f0974e8b0e3654eb084e469b39
tglase-nb.lan.tarent.de:0  MIT-MAGIC-COOKIE-1  2f2178f0974e8b0e3654eb084e469b39

(That’s still running under X.)

So perhaps this is one, or even two, bugs in xauth instead?

(That being said, I’d add a “| uniq”, at the very least, in the
indicated place in startx, if not handling for multiple cookies.)

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!

Bug#913468: startx: doesn't cope with multiple xauth cookies

[Thorsten Glaser]

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;
[…]
dummy=$(($dummy+1));
xauth -q -f "$xserverauthfile" << EOF
add :$dummy . $authcookie
EOF

This clearly assumes that $authcookie is only one.
However, on my system I somehow get two (the same but,
nevertheless, two), leading to xauth throwing a syntax
error upon running startx.

tglase@tglase-nb:~ $ displayname=tglase-nb.lan.tarent.de:0
tglase@tglase-nb:~ $ xauth list "$displayname" | sed -n 
"s/.*$displayname[[:space:]*].*[[:space:]*]//p"
2f5582db6c1e1d0f6da34c7f4fec89c7
2f5582db6c1e1d0f6da34c7f4fec89c7


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages xinit depends on:
ii  coreutils   8.30-1
ii  libc6   2.27-8
ii  libx11-62:1.6.7-1
ii  x11-common  1:7.7+19
ii  xauth   1:1.0.10-1

Versions of packages xinit recommends:
ii  evilwm [x-window-manager] 1.1.1-1
ii  icewm [x-window-manager]  1.4.3.0~pre-20181030-2
ii  konsole [x-terminal-emulator] 4:18.04.0-1
ii  kwin-x11 [x-window-manager]   4:5.13.5-1+b1
ii  plasma-workspace [x-session-manager]  4:5.13.5-1+b1
ii  tigervnc-standalone-server [xserver]  1.9.0+dfsg-2
ii  xserver-xorg [xserver]1:7.7+19
ii  xterm [x-terminal-emulator]   337-1

xinit suggests no packages.

-- no debconf information

Bug#912325: glamor0: GL error: GL_OUT_OF_MEMORY in glBufferData, GL_INVALID_OPERATION

[Thorsten Glaser]

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[32540]: xlock: xio_error 
Oct 29 15:05:54 tglase xlock[32540]: Stop: tglase, tglase, :0, 3855m 1s
Oct 29 15:05:54 tglase kdm[3334]: X server for display :0 terminated 
unexpectedly
Oct 29 15:05:54 tglase kdm: :0[3584]: pam_unix(kdm:session): session closed for 
user tglase

.oO(huh?)

/var/log/Xorg.0.log.old has more information:

[435017.600] (EE) glamor0: GL error: GL_OUT_OF_MEMORY in glBufferData
[435017.600] (EE) glamor0: GL error: GL_INVALID_OPERATION in glReadPixels(out 
of bounds PBO access)
[435017.600] (EE) glamor0: GL error: GL_INVALID_OPERATION in glMapBuffer(length 
= 0)
[435017.600] (EE) 
[435017.600] (EE) Backtrace:
[435017.600] (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x54) [0x567ec2d4]
[435017.600] (EE) 1: /usr/lib/xorg/Xorg (0x5664d000+0x1a2dc5) [0x567efdc5]
[435017.600] (EE) 2: /lib/x86_64-linux-gnux32/libpthread.so.0 
(0xf688e000+0x10870) [0xf689e870]
[435017.600] (EE) 3: /usr/lib/xorg/modules/libfb.so (fbBltOne+0x634) 
[0xf51a5e24]
[435017.600] (EE) 4: /usr/lib/xorg/modules/libfb.so (fbPutXYImage+0x171) 
[0xf51a9541]
[435017.600] (EE) 5: /usr/lib/xorg/modules/libfb.so (fbPutImage+0x1c7) 
[0xf51a9977]
[435017.600] (EE) 6: /usr/lib/xorg/modules/libglamoregl.so (0xf51b6000+0xddeb) 
[0xf51c3deb]
[435017.600] (EE) 7: /usr/lib/xorg/Xorg (0x5664d000+0x128714) [0x56775714]
[435017.600] (EE) 8: /usr/lib/xorg/Xorg (0x5664d000+0x43108) [0x56690108]
[435017.601] (EE) 9: /usr/lib/xorg/Xorg (0x5664d000+0x4674e) [0x5669374e]
[435017.601] (EE) 10: /usr/lib/xorg/Xorg (0x5664d000+0x4a6b9) [0x566976b9]
[435017.601] (EE) 11: /lib/x86_64-linux-gnux32/libc.so.6 
(__libc_start_main+0xe7) [0xf66f4ad7]
[435017.601] (EE) 12: /usr/lib/xorg/Xorg (_start+0x2b) [0x566816db]
[435017.601] (EE) 
[435017.601] (EE) Segmentation fault at address 0x2e0ce8

I’m attaching the full log.

-- 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 Oct 25 20:15 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 
8400 GS Rev. 3] [10de:10c3] (rev a2)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 0 May 18  2015 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.18.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-29)) #1 SMP Debian 4.18.10-2 (2018-10-07)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 26484 Dec  9  2016 /var/log/Xorg.10.log
-rw-r--r-- 1 root root 43006 Oct 30 12:41 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[435017.793] 
X.Org X Server 1.20.3
X Protocol Version 11, Revision 0
[435017.793] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[435017.793] Current Operating System: Linux tglase.lan.tarent.de 
4.18.0-2-amd64 #1 SMP Debian 4.18.10-2 (2018-10-07) x86_64
[435017.793] Kernel command line: BOOT_IMAGE=/vmlinuz-4.18.0-2-amd64 
root=/dev/mapper/vg--tglase-lv--tglase ro rootdelay=5 net.ifnames=0 
syscall.x32=y vsyscall=emulate kaslr
[435017.793] Build Date: 25 October 2018  06:15:23PM
[435017.793] xorg-server 2:1.20.3-1 (https://www.debian.org/support) 
[435017.793] Current version of pixman: 0.34.0
[435017.793]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[435017.793] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[435017.793] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Oct 29 15:05:54 
2018
[435017.794] (==) Using config file: "/etc/X11/xorg.conf"
[435017.794] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[435017.794] (==) No Layout section.  Using the first Screen section.
[435017.794] (==) No screen section available. Using defaults.
[435017.794] (**) |-->Screen "Default Screen Section" (0)
[435017.794] (**) |   |-->Monitor ""
[435017.794] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[435017.794] (==) Automatically adding devices
[435017.794] (==) Automatically enabling devices
[435017.794] (==) Automatically adding GPU devices
[435017.794] 

Bug#901249: xterm: translation overrides for copy/paste do not work as documented

[Thorsten Glaser]

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, this is most likely caused by the change
“Ensure that only one of PRIMARY and CLIPBOARD is owned by xterm
at a given time” which not only does not fix my problem but also
causes this to no longer work.

On MirBSD, I have select-end(PRIMARY, CUT_BUFFER0) for ~Shift,
and I guess this will then also no longer work.

Tom, please do revert that change, as it’s bogus *and* does not
address my initial problem (not being able to have xterm hold
*both* CLIPBOARD *and* PRIMARY but with *different* content).

Thanks,
//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 Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#909474: xterm: cannot copy to both CLIPBOARD and PRIMARY

[Thorsten Glaser]

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 not support having multiple of them at the same time?

> selection.  But using both at the same time was never intended (and
> consequently there is no discussion of that in the manual).
> 
> Changing that would be a feature request.

See above, but then, please treat it as a feature request.

> For either primary or clipboard, xterm has only one source-buffer which
> it uses to satisfy requests for selection content.  That's been the case

That’s not good.

My use case is this: in xterm, select two things (one to CLIPBOARD,
one to PRIMARY), then switch to a GUI application, and insert them
into different places. This greatly speeds up things, and from a
GUI application as sender, it already works (mark stuff, ^C, mark
other stuff, switch to receiving application).

Perhaps does this explain it better?

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 Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#909474: xterm: cannot copy to both CLIPBOARD and PRIMARY

[Thorsten Glaser]

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 not match expectation, documentation silent”.

Same scenario as in #901249.

I have two words on the command line, “foo” and “bar”.

I wish to have “foo” in CLIPBOARD and “bar” in PRIMARY.

I select “foo” with Shift. Now I can paste it with ^V in
a GUI application, but not with middle-click. Okaaay…

Then I select “bar” without Shift. I can paste it with
middle-click, but ^V does not paste “foo” any more.

Then I select “foo” with Shift again. Now middle-click
is dead again.

This is *not* why I have multiple clipboards in X11 and
go through pains of mapping them distinctly in xterm!


-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages xterm depends on:
ii  libc6   2.27-6
ii  libfontconfig1  2.13.0-5
ii  libfreetype62.8.1-2
ii  libice6 2:1.0.9-2
ii  libtinfo6   6.1+20180714-1
ii  libutempter01.1.6-3
ii  libx11-62:1.6.6-1
ii  libxaw7 2:1.0.13-1+b2
ii  libxft2 2.3.2-2
ii  libxinerama12:1.1.4-1
ii  libxmu6 2:1.1.2-2
ii  libxpm4 1:3.5.12-1
ii  libxt6  1:1.1.5-1
ii  xbitmaps1.1.1-2

Versions of packages xterm recommends:
ii  x11-utils  7.7+4

Versions of packages xterm suggests:
pn  xfonts-cyrillic  

-- no debconf information

Bug#901249: xterm: translation overrides for copy/paste do not work as documented

[Thorsten Glaser]

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. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

Bug#901249: xterm: translation overrides for copy/paste do not work as documented

[Thorsten Glaser]

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\
  ~Shift~Ctrl: insert-selection(PRIMARY, CUT_BUFFER0) \n\
   Shift~Ctrl: insert-selection(CLIPBOARD, CUT_BUFFER1) \n\
  ~Shift  : select-end(PRIMARY, CUT_BUFFER0) \n\
   Shift  : select-end(CLIPBOARD, CUT_BUFFER1)

… loaded with “xrdb -merge filename”, with no .Xresources
at all, then I started two xterms, in one I selected, in
another, I ran xsel commands to discern what is the content
of PRIMARY and CLIPBOARD, respectively.

tglase@tglase-nb:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P<> C<>
tglase@tglase-nb:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P C<>
tglase@tglase-nb:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P C
tglase@tglase-nb:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P C

After the first command I selected “foo” without Shift.
⇒ as expected, PRIMARY gets assigned “foo”, CLIPBOARD is left alone
After the second command I selected “bar” with Shift.
⇒ unexpectedly, PRIMARY *also* gets “bar” in addition to CLIPBOARD
After the third line, I selected “foo” without Shift again.
⇒ unexpectedly, CLIPBOARD *also* gets “foo” in addition to PRIMARY


For comparison, here’s the same sequence of things on MirBSD,
with xterm 200 on XFree86:

tg@blau:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P<> C<>
tg@blau:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P C<>
tg@blau:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P C
tg@blau:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P C<>

For that, I used this in .Xresources though:

*VT100*translations: #override \n\
 Shift~CtrlInsert:insert-selection(PRIMARY, CUT_BUFFER0) \n\
 Shift CtrlInsert:insert-selection(CLIPBOARD, CUT_BUFFER1) \n\
~Shift~Ctrl:insert-selection(PRIMARY, CUT_BUFFER0) \n\
 Shift~Ctrl:insert-selection(CLIPBOARD, CUT_BUFFER1) \n\
~Shift:select-end(PRIMARY, CUT_BUFFER0) \n\
 Shift:select-end(CLIPBOARD, CUT_BUFFER1)

(Actually, do I need a trailing \n or \n\ after the last line?)

Here, selecting “foo” without Shift again *clears* CLIPBOARD
instead of assigning to it. Still buggy.


I was considering not using cut buffers in xterm 333 on X.org:

*VT100*translations: #override \n\
 Shift~CtrlInsert:insert-selection(PRIMARY) \n\
 Shift CtrlInsert:insert-selection(CLIPBOARD) \n\
~Shift~Ctrl:insert-selection(PRIMARY) \n\
 Shift~Ctrl:insert-selection(CLIPBOARD) \n\
~Shift:select-end(PRIMARY) \n\
 Shift:select-end(CLIPBOARD) \n\

Anyway, from the above tests I concur that this never worked
as documented and still does not work as documented.


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

Kernel: Linux 4.16.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages xterm depends on:
ii  libc6   2.27-3
ii  libfontconfig1  2.13.0-5
ii  libfreetype62.8.1-2
ii  libice6 2:1.0.9-2
ii  libtinfo6   6.1+20180210-3
ii  libutempter01.1.6-3
ii  libx11-62:1.6.5-1
ii  libxaw7 2:1.0.13-1+b2
ii  libxft2 2.3.2-2
ii  libxinerama12:1.1.3-1+b3
ii  libxmu6 2:1.1.2-2
ii  libxpm4 1:3.5.12-1
ii  libxt6  1:1.1.5-1
ii  xbitmaps1.1.1-2

Versions of packages xterm recommends:
ii  x11-utils  7.7+4

Versions of packages xterm suggests:
pn  xfonts-cyrillic  

-- no debconf information

Bug#758094: apt-listchanges: changelogs for tglase.lan.tarent.de

[Thorsten Glaser]

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://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 Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#846158: closed by Emilio Pozuelo Monfort <po...@debian.org> (Re: Bug#846158: Xorg: -logfile /dev/null not allowed, prevents xrdp from working)

[Thorsten Glaser]

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 therefore suggest to keep it open with wishlist
severity, or just patch it in some next upload).

Thanks,
//mirabilos
-- 
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.

Bug#846158: Xorg: -logfile /dev/null not allowed, prevents xrdp from working

[Thorsten Glaser]

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 privileges -logfile must specify a relative path
without any ".." elements.

(EE)
(EE)
Please consult the The X.Org Foundation support
 at http://wiki.x.org
 for help.
(EE)


This is, in the effect, what xrdp does when it starts a new
X session for the remote user.

-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Dec  6  2014 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Nov 23 18:32 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GSE 
Express Integrated Graphics Controller [8086:27ae] (rev 03)

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.8.0-1-686-pae (debian-ker...@lists.debian.org) (gcc version 
5.4.1 20161019 (Debian 5.4.1-3) ) #1 SMP Debian 4.8.7-1 (2016-11-13)

Xorg X server log files on system:
--
-rw-r--r-- 1 tg tg 16675 Nov 22  2015 /home/tg/.local/share/xorg/Xorg.0.log
-rw-r--r-- 1 tg tg 13103 Jun 29 18:12 /home/tg/.local/share/xorg/Xorg.10.log

Contents of most recent Xorg X server log file 
(/home/tg/.local/share/xorg/Xorg.10.log):

[  2632.664] 
X.Org X Server 1.18.3
Release Date: 2016-04-04
[  2632.666] X Protocol Version 11, Revision 0
[  2632.666] Build Operating System: Linux 3.16.0-4-amd64 i686 Debian
[  2632.667] Current Operating System: Linux leee.mirbsd.org 4.5.0-2-686-pae #1 
SMP Debian 4.5.5-1 (2016-05-29) i686
[  2632.668] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.5.0-2-686-pae 
root=UUID=68f0cece-7bc7-4c33-81ec-dff7d2bad5a0 ro acpi_osi=Linux net.ifnames=0 
kaslr
[  2632.671] Build Date: 05 April 2016  07:01:49AM
[  2632.671] xorg-server 2:1.18.3-1 (http://www.debian.org/support) 
[  2632.672] Current version of pixman: 0.33.6
[  2632.673]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[  2632.673] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  2632.681] (==) Log file: "/home/tg/.local/share/xorg/Xorg.10.log", Time: Wed 
Jun 29 18:12:24 2016
[  2632.688] (++) Using config file: "/etc/X11/xrdp/xorg.conf"
[  2632.689] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  2632.695] (==) ServerLayout "X11 Server"
[  2632.695] (**) |-->Screen "Screen (xrdpdev)" (0)
[  2632.695] (**) |   |-->Monitor "Monitor"
[  2632.697] (**) |   |-->Device "Video Card (xrdpdev)"
[  2632.697] (**) |-->Input Device "xrdpMouse"
[  2632.698] (**) |-->Input Device "xrdpKeyboard"
[  2632.698] (**) Option "DontVTSwitch" "on"
[  2632.699] (**) Option "AutoAddDevices" "off"
[  2632.700] (**) Not automatically adding devices
[  2632.700] (==) Automatically enabling devices
[  2632.700] (==) Automatically adding GPU devices
[  2632.701] (==) Max clients allowed: 256, resource mask: 0x1f
[  2632.707] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[  2632.708]Entry deleted from font path.
[  2632.715] (**) FontPath set to:
/usr/share/fonts/X11/misc/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[  2632.715] (==) ModulePath set to "/usr/lib/xorg/modules"
[  2632.716] (II) Loader magic: 0x8027c700
[  2632.716] (II) Module ABI versions:
[  2632.717]X.Org ANSI C Emulation: 0.4
[  2632.717]X.Org Video Driver: 20.0
[  2632.717]X.Org XInput driver : 22.1
[  2632.718]X.Org Server Extension : 9.0
[  2632.730] (EE) systemd-logind: failed to get session: The name 
org.freedesktop.login1 was not provided by any .service files
[  2632.778] (II) xfree86: Adding drm device (/dev/dri/card0)
[  2632.839] (--) PCI:*(0:0:2:0) 8086:27ae:1043:8340 rev 3, Mem @ 
0xf7e0/524288, 0xd000/268435456, 0xf7dc/262144, I/O @ 0xdc00/8
[  2632.841] (--) PCI: (0:0:2:1) 8086:27a6:1043:8340 rev 3, Mem @ 
0xf7e8/524288
[  2632.842] (II) "glx" will be loaded. This was enabled by default and also 
specified in the config file.
[  2632.842] (II) LoadModule: "dbe"
[  2632.843] (II) Module 

Bug#816289: luit: unable to use advertised conversion charset

[Thorsten Glaser]

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
Warning: couldn't find charset data for locale CP 1252; using ISO 8859-1.
mäh
tglase@tglase-nb:~ $ luit -encoding microsoft-cp1252 echo mäh
Warning: couldn't find charset data for locale microsoft-cp1252; using ISO 
8859-1.
mäh
tglase@tglase-nb:~ $ luit -list | fgrep 1252
  CP 1252

This is not specific to Debian (Cc’ing the original author from
the manpage), as I can reproduce it also on MirBSD with XFree86®.

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

Kernel: Linux 4.4.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages x11-utils depends on:
ii  libc6 2.21-9
ii  libfontconfig12.11.0-6.3
ii  libfontenc1   1:1.1.3-1
ii  libfreetype6  2.6.1-0.1
ii  libgl1-mesa-glx [libgl1]  11.1.2-1
ii  libx11-6  2:1.6.3-1
ii  libx11-xcb1   2:1.6.3-1
ii  libxaw7   2:1.0.13-1
ii  libxcb-shape0 1.11.1-1
ii  libxcb1   1.11.1-1
ii  libxcomposite11:0.4.4-1
ii  libxext6  2:1.3.3-1
ii  libxft2   2.3.2-1
ii  libxi62:1.7.6-1
ii  libxinerama1  2:1.1.3-1+b1
ii  libxmu6   2:1.1.2-2
ii  libxmuu1  2:1.1.2-2
ii  libxrandr22:1.5.0-1
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  libxtst6  2:1.2.2-1+b1
ii  libxv12:1.0.10-1+b1
ii  libxxf86dga1  2:1.1.4-1+b1
ii  libxxf86vm1   1:1.1.4-1

x11-utils recommends no packages.

Versions of packages x11-utils suggests:
pn  mesa-utils  

-- no debconf information

Bug#787496: libdrm: FTBFS: unconditionally includes deprecated-on-Linux sysctl header

[Thorsten Glaser]

tags 787496 + patch
thanks

Hi again,

now I’ve got the bugnumber, a debdiff and a build log.

Enjoy,
//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 Barth, Kai Ebenrett, Boris Esser, Alexander Steegdiff -u libdrm-2.4.60/debian/changelog libdrm-2.4.60/debian/changelog
--- libdrm-2.4.60/debian/changelog
+++ libdrm-2.4.60/debian/changelog
@@ -1,3 +1,11 @@
+libdrm (2.4.60-3+x32) unreleased; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix kfreebsd patch that caused an FTBFS on Linux/x32: (Closes: #787496)
+only include sys/sysctl.h if configure detects it.
+
+ -- Thorsten Glaser t.gla...@tarent.de  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-headers-inclusion-in-xf86drmMode.c.diff 
libdrm-2.4.60/debian/patches/Fix-headers-inclusion-in-xf86drmMode.c.diff
--- libdrm-2.4.60/debian/patches/Fix-headers-inclusion-in-xf86drmMode.c.diff
+++ libdrm-2.4.60/debian/patches/Fix-headers-inclusion-in-xf86drmMode.c.diff
@@ -9,8 +9,22 @@
  xf86drmMode.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)
 
-diff --git a/xf86drmMode.c b/xf86drmMode.c
-index 61d5e01..de37548 100644
+Updated by Thorsten “mirabilos” Glaser t.gla...@tarent.de
+to add autoconf check and only include sys/sysctl.h if it
+is detected by configure as it’s unusable on Linux/x32 (and
+others, e.g. other new architectures).
+
+--- a/configure.ac
 b/configure.ac
+@@ -41,7 +41,7 @@ AC_USE_SYSTEM_EXTENSIONS
+ AC_SYS_LARGEFILE
+ AC_FUNC_ALLOCA
+ 
+-AC_CHECK_HEADERS([sys/mkdev.h])
++AC_CHECK_HEADERS([sys/mkdev.h sys/sysctl.h])
+ 
+ # Initialize libtool
+ LT_PREREQ([2.2])
 --- a/xf86drmMode.c
 +++ b/xf86drmMode.c
 @@ -32,6 +32,9 @@
@@ -26,17 +40,15 @@
-@@ -39,12 +42,9 @@
+@@ -39,11 +42,10 @@
   */
  #include stdint.h
  #include sys/ioctl.h
-+#include sys/sysctl.h
- #include stdio.h
- 
+-#include stdio.h
+-
 -#ifdef HAVE_CONFIG_H
 -#include config.h
--#endif
--
++#ifdef HAVE_SYS_SYSCTL_H
++#include sys/sysctl.h
+ #endif
++#include stdio.h
+ 
  #include xf86drmMode.h
  #include xf86drm.h
- #include drm.h
--- 
-2.1.4
-


libdrm_2.4.60-3+x32_x32.build.xz
Description: application/xz

Bug#787496: libdrm: FTBFS: unconditionally includes deprecated-on-Linux sysctl header

[Thorsten Glaser]

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 sys/sysctl.h header. Unfortunately, people on Linux don’t
like it and deprecated it to the point it’s a hard failure on
new architectures, such as x32.

I’m currently building libdrm with a local trivial patch to
use autoconf mechanisms to check for it.

@kFreeBSD porters: please *never* add this header unconditionally
any more but *always* use autoconf mechanisms to check whether it
is actually usable first (note it exists but has a hard #error).

Thanks!

-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150602093813.10545.29676.report...@tglase.lan.tarent.de

Bug#758094: using an x32 X server considered harmful, for now

[Thorsten Glaser]

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[f18ba000+16000]


I’ve switched back to xserver-xorg-video-nouveau:i386 for now
(with gratitutous editing of /var/lib/dpkg/status to allow
for partial regrading to i386, e.g. for things like cpp:x32
or xserver-xorg:i386 satisfying global dependencies).

Looks like I’ll have some fun ahead debugging this…

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 Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1409161102300.4...@tglase.lan.tarent.de

Bug#758094: libgl1-mesa-glx:x32: SIGSEGV in OpenGL applications on x32

[Thorsten Glaser]

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 glLightfv () from /usr/lib/x86_64-linux-gnux32/libGL.so.1
(gdb) bt
#0  0xf76db60b in glLightfv () from /usr/lib/x86_64-linux-gnux32/libGL.so.1
#1  0x0040146f in ?? ()
#2  0xf6aceeea in __libc_start_main (main=optimized out, argc=1, 
argv=optimized out,
init=optimized out, fini=optimized out, rtld_fini=optimized out, 
stack_end=0xd448)
at libc-start.c:287
#3  0x00401cfc in ?? ()

I’ve first noticed that in “xlock -nolock -mode cage”,
which, with debugging information, has:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xf6af524b in glGetBooleanv () from /usr/lib/x86_64-linux-gnux32/libGL.so.1
(gdb) bt
#0  0xf6af524b in glGetBooleanv () from /usr/lib/x86_64-linux-gnux32/libGL.so.1
#1  0x0040fcfe in init_GL (mi=mi@entry=0x228bde0) at visgl.c:287
#2  0x004dc6d4 in init_cage (mi=optimized out) at cage.c:400
#3  0x0040e462 in call_init_hook (ls=0x823340 LockProcs+1152, mi=optimized 
out) at mode.c:1290
#4  0x0040887c in justDisplay (display=0x226e870) at xlock.c:2821
#5  0x0040764f in main (argc=36104304, argv=0x0) at xlock.c:3998

Bugs occur in (first glxgears, then xlock):

(gdb) disas
Dump of assembler code for function glLightfv:
   0xf76db600 +0: movrax,QWORD PTR [rip+0x21b9f1]# 0xf78f6ff8
   0xf76db607 +7: movr11,QWORD PTR fs:[rax]
= 0xf76db60b +11:jmpQWORD PTR [r11+0x500]

(gdb) disas
Dump of assembler code for function glGetBooleanv:
   0xf6af5240 +0: movrax,QWORD PTR [rip+0x21adb1]# 0xf6d0fff8
   0xf6af5247 +7: movr11,QWORD PTR fs:[rax]
= 0xf6af524b +11:jmpQWORD PTR [r11+0x810]

So this appears to be an indirect function call both times.


-- System Information:
Debian Release: jessie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh

Versions of packages libgl1-mesa-glx:x32 depends on:
ii  libc6  2.19-7
ii  libdrm22.4.56-1
ii  libglapi-mesa  10.2.5-1
ii  libudev1   208-7
ii  libx11-6   2:1.6.2-2
ii  libx11-xcb12:1.6.2-2
ii  libxcb-dri2-0  1.10-3
ii  libxcb-dri3-0  1.10-3
ii  libxcb-glx01.10-3
ii  libxcb-present01.10-3
ii  libxcb-sync1   1.10-3
ii  libxcb11.10-3
ii  libxdamage11:1.1.4-2
ii  libxext6   2:1.3.2-1
ii  libxfixes3 1:5.0.1-2
ii  libxshmfence1  1.1-3
ii  libxxf86vm11:1.1.3-1
ii  multiarch-support  2.19-7

Versions of packages libgl1-mesa-glx:x32 recommends:
ii  libgl1-mesa-dri  10.2.5-1

libgl1-mesa-glx:x32 suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140814084614.7433.79110.report...@tglase.lan.tarent.de

Bug#728053: Updated debdiff for mesa to compile on m68k

[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 requirements than
other platforms.

Take this example:

struct {
char c;
int i;
} foo;

This looks like this to the programmer:

┌───┬───┬───┬───┬───┐
│ c │ i   i   i   i │
└───┴───┴───┴───┴───┘

But it looks like this on i386:

┌───┬───┬───┬───┬───┬───┬───┬───┐
│ c │ XpaddingX │ i   i   i   i │
└───┴───┴───┴───┴───┴───┴───┴───┘

And only like this on m68k:

┌───┬───┬───┬───┬───┬───┐
│ c │ X │ i   i   i   i │
└───┴───┴───┴───┴───┴───┘

This is because the compiler uses the architecture’s optimal
minimum alignment for “implicit” padding, to avoid the misalignment
you’re talking about. On i386, access to a 32-bit quantity is fast
if it’s 4-byte aligned; on m68k, 2-byte alignment is not only enough
for it to be fast (4-byte would have no benefit), but is also required
by the ABI.


To fix this, we use explicit padding:

struct {
char c;
char unused1[3];
int i;
} foo;

Now all cases look the same (except if you have a CPU which
wants to align its “int”s to 64 bit…).


The problem here is that the code in question uses arrays of
such structs with implicit padding, and checks their sizes
against its expectations. Maybe because the array is written
directly to the hardware.

What my patch does is to insert e̲x̲p̲l̲i̲c̲i̲t̲ padding to exactly
match the i̲m̲p̲l̲i̲c̲i̲t̲ padding present on the i386 architecture,
to make this the “minimum amount of padding” used. (Other
architectures may still insert implicit padding, e.g. if
they want their “int”s to be 64-bit aligned, but that’s
outside of the scope of this, and will fail with that code
anyway.)

bye,
//mirabilos
-- 
[16:04:33] bkix: veni vidi violini
[16:04:45] bkix: ich kam, sah und vergeigte...


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1407171014560.16...@tglase.lan.tarent.de

Bug#728053: [Mesa-dev] Updated debdiff for mesa to compile on m68k

[Thorsten Glaser]

On Thu, 17 Jul 2014, Ilia Mirkin wrote:

 Yes, implicit padding is definitely bad. I didn't realize I even had
 it in there, although I'm glad my STATIC_ASSERT did its job. There are

;-)

 various references to patches, however I haven't seen any. Perhaps
 they're lost in my inbox, or they were never sent to mesa-dev, or
 something else. Could the patch author (or another interested party)
 send it as a proper patch to mesa-dev? Assuming it doesn't break x86,
 happy to check it in.

Oh fun. I’m the patch author, and it was here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=37;filename=mesa_10.2.3-1%2Bm68k.1.debdiff;att=1;bug=728053

I’ve attached the part you’re probably most interested in.

Thanks,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty 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 CFrom: Thorsten Glaser t...@debian.org
Date: Wed, 30 Oct 2013 18:04:07 +0100
Subject: Fix FTBFS on m68k due to invalid struct alignment assumptions
Debian-Bug: #728053

Make alignment assumptions explicit by inserting correct padding,
as upstream already did for other parts of the structure.

--- a/src/gallium/drivers/nouveau/nv50/nv84_video_bsp.c
+++ b/src/gallium/drivers/nouveau/nv50/nv84_video_bsp.c
@@ -67,10 +67,15 @@ struct iparm {
  uint32_t field_is_ref; // 04 // bit0: top, bit1: bottom
  uint8_t is_long_term; // 08
  uint8_t non_existing; // 09
+ uint8_t u0a; // 0a
+ uint8_t u0b; // 0b
  uint32_t frame_idx; // 0c
  uint32_t field_order_cnt[2]; // 10
  uint32_t mvidx; // 18
  uint8_t field_pic_flag; // 1c
+ uint8_t u1d; // 1d
+ uint8_t u1e; // 1e
+ uint8_t u1f; // 1f
  // 20
   } refs[0x10]; // 1e0
} ipicparm; // 150

Bug#728053: [Mesa-dev] Updated debdiff for mesa to compile on m68k

[Thorsten Glaser]

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 static or auto storage, it relies on the linker;
for malloc, it relies on libc).

The approach here is not to make the struct aligned, but
rather, to make it consistent within itself. In a portable
way, even (although we do use GCC 4.9 on Debian/m68k).

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1407171625190.16...@tglase.lan.tarent.de

Bug#728053: Updated debdiff for mesa to compile on m68k

[Thorsten Glaser]

Hi all,

updated debdiff attached. Package compiles fine with it
(on i386 and m68k), and the invalid alignment assumptions
were made explicit with no ABI breakage.
Please apply.

Thanks,
//mirabilos
-- 
15:41⎜Lo-lan-do:#fusionforge Somebody write a testsuite for helloworld :-)diff -u mesa-10.2.3/debian/changelog mesa-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 t...@mirbsd.de  Tue, 15 Jul 2014 13:50:57 +0200
+
 mesa (10.2.3-1) unstable; urgency=low
 
   [ Maarten Lankhorst ]
diff -u mesa-10.2.3/debian/patches/series mesa-10.2.3/debian/patches/series
--- mesa-10.2.3/debian/patches/series
+++ mesa-10.2.3/debian/patches/series
@@ -1,0 +2 @@
+08_gallium-fix-build-failure-on-m68k.diff
only in patch2:
unchanged:
--- mesa-10.2.3.orig/debian/patches/08_gallium-fix-build-failure-on-m68k.diff
+++ mesa-10.2.3/debian/patches/08_gallium-fix-build-failure-on-m68k.diff
@@ -0,0 +1,26 @@
+From: Thorsten Glaser t...@debian.org
+Date: Wed, 30 Oct 2013 18:04:07 +0100
+Subject: Fix FTBFS on m68k due to invalid struct alignment assumptions
+Debian-Bug: #728053
+
+Make alignment assumptions explicit by inserting correct padding,
+as upstream already did for other parts of the structure.
+
+--- a/src/gallium/drivers/nouveau/nv50/nv84_video_bsp.c
 b/src/gallium/drivers/nouveau/nv50/nv84_video_bsp.c
+@@ -67,10 +67,15 @@ struct iparm {
+  uint32_t field_is_ref; // 04 // bit0: top, bit1: bottom
+  uint8_t is_long_term; // 08
+  uint8_t non_existing; // 09
++ uint8_t u0a; // 0a
++ uint8_t u0b; // 0b
+  uint32_t frame_idx; // 0c
+  uint32_t field_order_cnt[2]; // 10
+  uint32_t mvidx; // 18
+  uint8_t field_pic_flag; // 1c
++ uint8_t u1d; // 1d
++ uint8_t u1e; // 1e
++ uint8_t u1f; // 1f
+  // 20
+   } refs[0x10]; // 1e0
+} ipicparm; // 150

Bug#728053: Updated debdiff for mesa to compile on m68k

[Thorsten Glaser]

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 Debian on retro m68k hardware and emulators
 and we even got some official funding through Debian to buy hardware.
 Even Greg Kroah-Hartman says he appreciates the port when I asked
 him about on LinuxTag, it helps spotting regressions :).

Not just that – I’ve seen people run MiNT on Atari with actual
ATI Radeon cards (not yet supported on Linux due to missing
kernel-side PCI bus glue, but probably not much work), and
it’s not a stretch to believe Nięvida could be next.

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty 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


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1407161311180.25...@tglase.lan.tarent.de

Bug#740919: xterm: clears $SHELL from environment at startup

[Thorsten Glaser]

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
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 Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.10.1403071007460.9...@tglase.lan.tarent.de

Bug#740919: xterm: clears $SHELL from environment at startup

[Thorsten Glaser]

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 idea if this bug is
also upstream):

Among the usual differences like $PGRP and $WINDOWID I have:

--- x1  2014-03-06 09:28:26.356676132 +0100
+++ x2  2014-03-06 09:28:26.092672608 +0100
@@ -31,8 +31,8 @@
 typeset PWD=/home/tglase
 typeset -x QUILT_PATCHES=-
-typeset -i -x -U RANDOM=15871
+typeset -i -x -U RANDOM=565
 typeset -i SECONDS=0
-typeset -x SHELL=
+typeset -x SHELL=/bin/mksh
 typeset -x SIRCNICK='mira|AO'
 typeset -x SIRCSERVER=127.0.0.1:s7000
 typeset -x SSH_AGENT_PID=3511
@@ -52,12 +52,12 @@
 typeset -x USER=tglase
 typeset -i -U USER_ID=2339
 typeset -x VISUAL=/usr/bin/jupp
-typeset -x WINDOWID=25165837
+typeset -x WINDOWID=33554445
 typeset -x WINDOWPATH=7
 typeset -x 
XDG_SESSION_COOKIE=87bd0826b5c41524a188f458494f992f-1393518574.144306-436980184
 typeset -x XDM_MANAGED='method=classic'
 typeset -x XTERM_LOCALE=en_GB.UTF-8
 typeset -x XTERM_SHELL=/usr/local/bin/dumpargs
-typeset -x XTERM_VERSION='XTerm(302)'
+typeset -x XTERM_VERSION='XTerm(301)'
 typeset -x _=/usr/bin/xterm
 args(0) 0:/usr/local/bin/dumpargs


User story: I use “xterm -e screen” (basically) to start GNU screen,
which then has “shell -${SHELL}” in ~/.screenrc which should really
really not be empty. Also, xterm IMHO has no business touching that
part of my environment.


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (100, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh

Versions of packages xterm depends on:
ii  libc6   2.18-4
ii  libfontconfig1  2.11.0-5
ii  libice6 2:1.0.8-2
ii  libtinfo5   5.9+20140118-1
ii  libutempter01.1.5-4
ii  libx11-62:1.6.2-1
ii  libxaw7 2:1.0.12-1
ii  libxft2 2.3.1-2
ii  libxmu6 2:1.1.1-1
ii  libxpm4 1:3.5.10-1
ii  libxt6  1:1.1.4-1
ii  xbitmaps1.1.1-2

Versions of packages xterm recommends:
ii  x11-utils  7.7+1

Versions of packages xterm suggests:
pn  xfonts-cyrillic  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140306083136.987.1959.report...@tglase.lan.tarent.de

Bug#740919: xterm: clears $SHELL from environment at startup

[Thorsten Glaser]

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 some additional aspect that I've overlooked.

Yes, /bin/mksh is in /etc/shells.

I can test patches, if you throw them to t.gla...@tarent.de (work
eMail).

In case that’s relevant, I have UXTerm*VT100*loginShell: true in
my .Xresources. (And my login shell is mksh. Of course. ☺)

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/pine.bsm.4.64l.1403061325200.3...@herc.mirbsd.org

Bug#729849: xterm: Meta key ≠ Alt key

[Thorsten Glaser]

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, that incorrectly say to use, for
example, Alt-1 to do an action, should instead document that,
correctly, Esc+1 is the way to invoke that action. So, for
your GNU nano example, it’s Esc+w.

bye,
//mirabilos
-- 
13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good
guy. But he's always right! In every fsckin' situation, he's right. Even
with his deeply perverted taste in software and borked ambition towards
broken OSes - in the end, he's damn right about it :(! […] works in mksh


--
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/pine.bsm.4.64l.1311181108490.23...@herc.mirbsd.org

Bug#729337: xorg-server: FTBFS: preprocessor macro R_SP conflict with glibc headers

[Thorsten Glaser]

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 version in sid FTBFS due to this:
.../../../../hw/xfree86/int10/xf86x86emu.c:89:5: warning: function might be 
possible candidate for 'gnu_printf' format attribute 
[-Wsuggest-attribute=format]
I have no idea why, but (also in #728333 for console-tools) on
some buildds, -Werror=format-security is enabled, leading to
those. I do suspect this also applies to the version in experimental,
given the warnings shown (full build log attached), but the flag
does not show up in cowbuilder and on some other buildds, so this
is an unknown issue.

Anyway, back to the problem at hand: there’s a build failure, basically
because xf86x86emu.c #defines R_SP before including signal.h which in
turn pulls /usr/include/m68k-linux-gnu/sys/ucontext.h in, which *also*
defines R_SP (which is apparently valid to do).

The R_SP definition in X11 comes from: hw/xfree86/x86emu/x86emu/regs.h
signal.h comes from: ../../../../include/globals.h

There are some ways to fix this, such as including signal.h first
in regs.h, then #undef-ing all R_* things before redefining them,
which (given the existing use of headers-including-headers here)
would fit the overall theme, or blaming eglibc (which doesn’t look
like a viable solution), or other hacks. I’m tending towards the
first way, which is why I file this against xorg-server; please
let me know if something like this is acceptable:


--- ../../../../hw/xfree86/x86emu/x86emu/regs.h~2013-11-11 
22:52:33.0 +
+++ ../../../../hw/xfree86/x86emu/x86emu/regs.h 2013-11-11 22:55:55.0 
+
@@ -39,6 +39,9 @@
 #ifndef __X86EMU_REGS_H
 #define __X86EMU_REGS_H
 
+/* we sometimes clash with system headers, so pull them in here */
+#include signal.h
+
 /*-- Macros and type definitions --*/
 
 #ifdef PACK
@@ -117,6 +120,14 @@
 };
 
 /* 8 bit registers */
+#undef R_AH
+#undef R_AL
+#undef R_BH
+#undef R_BL
+#undef R_CH
+#undef R_CL
+#undef R_DH
+#undef R_DL
 #define R_AH  gen.A.I8_reg.h_reg
 #define R_AL  gen.A.I8_reg.l_reg
 #define R_BH  gen.B.I8_reg.h_reg
@@ -127,18 +138,32 @@
 #define R_DL  gen.D.I8_reg.l_reg
 
 /* 16 bit registers */
+#undef R_AX
+#undef R_BX
+#undef R_CX
+#undef R_DX
 #define R_AX  gen.A.I16_reg.x_reg
 #define R_BX  gen.B.I16_reg.x_reg
 #define R_CX  gen.C.I16_reg.x_reg
 #define R_DX  gen.D.I16_reg.x_reg
 
 /* 32 bit extended registers */
+#undef R_EAX
+#undef R_EBX
+#undef R_ECX
+#undef R_EDX
 #define R_EAX  gen.A.I32_reg.e_reg
 #define R_EBX  gen.B.I32_reg.e_reg
 #define R_ECX  gen.C.I32_reg.e_reg
 #define R_EDX  gen.D.I32_reg.e_reg
 
 /* special registers */
+#undef R_SP
+#undef R_BP
+#undef R_SI
+#undef R_DI
+#undef R_IP
+#undef R_FLG
 #define R_SP  spc.SP.I16_reg.x_reg
 #define R_BP  spc.BP.I16_reg.x_reg
 #define R_SI  spc.SI.I16_reg.x_reg
@@ -147,14 +172,12 @@
 #define R_FLG spc.FLAGS
 
 /* special registers */
-#define R_SP  spc.SP.I16_reg.x_reg
-#define R_BP  spc.BP.I16_reg.x_reg
-#define R_SI  spc.SI.I16_reg.x_reg
-#define R_DI  spc.DI.I16_reg.x_reg
-#define R_IP  spc.IP.I16_reg.x_reg
-#define R_FLG spc.FLAGS
-
-/* special registers */
+#undef R_ESP
+#undef R_EBP
+#undef R_ESI
+#undef R_EDI
+#undef R_EIP
+#undef R_EFLG
 #define R_ESP  spc.SP.I32_reg.e_reg
 #define R_EBP  spc.BP.I32_reg.e_reg
 #define R_ESI  spc.SI.I32_reg.e_reg
@@ -163,6 +186,12 @@
 #define R_EFLG spc.FLAGS
 
 /* segment registers */
+#undef R_CS
+#undef R_DS
+#undef R_SS
+#undef R_ES
+#undef R_FS
+#undef R_GS
 #define R_CS  seg.CS
 #define R_DS  seg.DS
 #define R_SS  seg.SS



-- System Information:
Debian Release: jessie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: m68k

Kernel: Linux 3.11-1-m68k
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh


-- 
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/2013225718.23696.24577.report...@ara3.mirbsd.org

Bug#728053: [Mesa-dev] Fwd: Bug#728053: [PATCH] mesa: FTBFS: invalid alignment assumptions

[Thorsten Glaser]

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 controller).

It’s not my job to disable building that certain code in
the Debian package, I’m just building whatever the Debian
package maintainers shove our way.

Anyway, implicit alignment and padding assumptions are,
nevertheless, bad, so I believe that, even should that
particular code be disabled, this patch should be applied
upstream. (Also, to show others how it’s done correctly.
People learn coding by reading code.)

Thanks,
//mirabilos
-- 
21:26⎜cnuke cool cool, pitch ist zu hoch
21:26⎜cnuke eingebauter chipmunk modus in dragonfly bsd │ I luv it ^^
21:31⎜«yofuh» ich glaube ich wuerde den rechner aussm fenster werfen,
 ⎜wenn er beim booten das chipmunks intro spielt


--
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/pine.bsm.4.64l.1311071628100.8...@herc.mirbsd.org

Bug#728053: Fwd: Bug#728053: [PATCH] mesa: FTBFS: invalid alignment assumptions

[Thorsten Glaser]

Hi everyone,

here’s a bugfix to make implicit alignment and padding
assumptions explicit, please apply.

Thanks,
//mirabilos
-- 
21:26⎜cnuke cool cool, pitch ist zu hoch
21:26⎜cnuke eingebauter chipmunk modus in dragonfly bsd │ I luv it ^^
21:31⎜«yofuh» ich glaube ich wuerde den rechner aussm fenster werfen,
 ⎜wenn er beim booten das chipmunks intro spielt

-- Forwarded message --
From: Julien Cristau jcris...@debian.org
Message-ID: 20131106151538.gg4...@betterave.cristau.org
X-Spam-Status: No, hits=0.00 required=0.90
To: Thorsten Glaser t...@mirbsd.de, 728...@bugs.debian.org
Date: Wed, 6 Nov 2013 16:15:38 +0100
Subject: Re: Bug#728053: [PATCH] mesa: FTBFS: invalid alignment assumptions

On Fri, Nov  1, 2013 at 17:25:11 +, Thorsten Glaser wrote:

 tags 728053 + patch
 thanks
 
 Dear Maintainers,
 
 I’ve prepared the attached patch for mesa to fix this issue and
 built it once, fully, to test that it no longer FTBFSes with it
 applied. Please add this patch to the Debian package as well as
 forward it upstream.
 
Please send it to mesa-...@lists.freedesktop.org yourself.

Cheers,
Juliendiff -u mesa-9.2.2/debian/changelog mesa-9.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 t...@mirbsd.de  Wed, 30 Oct 2013 18:05:12 +0100
+
 mesa (9.2.2-1) unstable; urgency=low
 
   * New upstream release.
diff -u mesa-9.2.2/debian/patches/series mesa-9.2.2/debian/patches/series
--- mesa-9.2.2/debian/patches/series
+++ mesa-9.2.2/debian/patches/series
@@ -1,3 +1,4 @@
+12-m68k-struct-alignment.diff
 01_gbm_egl.diff
 02_gbm_no_undefined.diff
 04_osmesa_version.diff
only in patch2:
unchanged:
--- mesa-9.2.2.orig/debian/patches/12-m68k-struct-alignment.diff
+++ mesa-9.2.2/debian/patches/12-m68k-struct-alignment.diff
@@ -0,0 +1,26 @@
+From: Thorsten Glaser t...@debian.org
+Date: Wed, 30 Oct 2013 18:04:07 +0100
+Subject: Fix FTBFS on m68k due to invalid struct alignment assumptions
+Debian-Bug: #728053
+
+Make alignment assumptions explicit by inserting correct padding,
+as upstream already did for other parts of the structure.
+
+--- a/src/gallium/drivers/nv50/nv84_video_bsp.c
 b/src/gallium/drivers/nv50/nv84_video_bsp.c
+@@ -67,10 +67,15 @@ struct iparm {
+  uint32_t field_is_ref; // 04 // bit0: top, bit1: bottom
+  uint8_t is_long_term; // 08
+  uint8_t non_existing; // 09
++ uint8_t u0a; // 0a
++ uint8_t u0b; // 0b
+  uint32_t frame_idx; // 0c
+  uint32_t field_order_cnt[2]; // 10
+  uint32_t mvidx; // 18
+  uint8_t field_pic_flag; // 1c
++ uint8_t u1d; // 1d
++ uint8_t u1e; // 1e
++ uint8_t u1f; // 1f
+  // 20
+   } refs[0x10]; // 1e0
+} ipicparm; // 150

Bug#728053: [PATCH] mesa: FTBFS: invalid alignment assumptions

[Thorsten Glaser]

tags 728053 + patch
thanks

Dear Maintainers,

I’ve prepared the attached patch for mesa to fix this issue and
built it once, fully, to test that it no longer FTBFSes with it
applied. Please add this patch to the Debian package as well as
forward it upstream.

Thanks,
//mirabilos
-- 
diogenese Beware of ritual lest you forget the meaning behind it.
igli yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.diff -u mesa-9.2.2/debian/changelog mesa-9.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 t...@mirbsd.de  Wed, 30 Oct 2013 18:05:12 +0100
+
 mesa (9.2.2-1) unstable; urgency=low
 
   * New upstream release.
diff -u mesa-9.2.2/debian/patches/series mesa-9.2.2/debian/patches/series
--- mesa-9.2.2/debian/patches/series
+++ mesa-9.2.2/debian/patches/series
@@ -1,3 +1,4 @@
+12-m68k-struct-alignment.diff
 01_gbm_egl.diff
 02_gbm_no_undefined.diff
 04_osmesa_version.diff
only in patch2:
unchanged:
--- mesa-9.2.2.orig/debian/patches/12-m68k-struct-alignment.diff
+++ mesa-9.2.2/debian/patches/12-m68k-struct-alignment.diff
@@ -0,0 +1,26 @@
+From: Thorsten Glaser t...@debian.org
+Date: Wed, 30 Oct 2013 18:04:07 +0100
+Subject: Fix FTBFS on m68k due to invalid struct alignment assumptions
+Debian-Bug: #728053
+
+Make alignment assumptions explicit by inserting correct padding,
+as upstream already did for other parts of the structure.
+
+--- a/src/gallium/drivers/nv50/nv84_video_bsp.c
 b/src/gallium/drivers/nv50/nv84_video_bsp.c
+@@ -67,10 +67,15 @@ struct iparm {
+  uint32_t field_is_ref; // 04 // bit0: top, bit1: bottom
+  uint8_t is_long_term; // 08
+  uint8_t non_existing; // 09
++ uint8_t u0a; // 0a
++ uint8_t u0b; // 0b
+  uint32_t frame_idx; // 0c
+  uint32_t field_order_cnt[2]; // 10
+  uint32_t mvidx; // 18
+  uint8_t field_pic_flag; // 1c
++ uint8_t u1d; // 1d
++ uint8_t u1e; // 1e
++ uint8_t u1f; // 1f
+  // 20
+   } refs[0x10]; // 1e0
+} ipicparm; // 150

Bug#693194: twm: does not handle UTF-8 locales

[Thorsten Glaser]

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 DISPLAY=:2 twm

… works. Confirmed this bug.

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-314
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Boris Esser, Sebastian Mancke


--
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/alpine.deb.2.10.1307191434380.5...@tglase.lan.tarent.de

Re: Log for attempted build of xorg-server_2:1.12.4-6 on m68k (dist=unstable)

[Thorsten Glaser]

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 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/pine.bsm.4.64l.1304181150010.29...@herc.mirbsd.org

Re: Log for attempted build of xorg-server_2:1.12.4-6 on m68k (dist=unstable)

[Thorsten Glaser]

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, like  systemd,  feminism
or social democracy.
-- Christoph Lohmann on d...@suckless.org


--
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/pine.bsm.4.64l.1304181625420.23...@herc.mirbsd.org

Bug#326200: Please keep xterm doing Alt-d=ä as this is how I type German

[Thorsten Glaser]

Hi,

FWIW: the BSD wscons(4) text console does the same,
and it always annoys me that Linux’ doesn’t…

bye,
//mirabilos
-- 
15:41⎜Lo-lan-do:#fusionforge Somebody write a testsuite for helloworld :-)


--
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/alpine.deb.2.02.1210042042530@tglase.lan.tarent.de

Bug#654329: libdrm: FTBFS when atomic operations are only available through libatomic-ops-dev

[Thorsten Glaser]

found 654329 2.4.33-1
thanks

Hi,

please do consider applying the patch, as it does truly fix an FTBFS
on m68k.

Thanks in advance,
//mirabilos
-- 
22:20⎜asarch The crazy that persists in his craziness becomes a master
22:21⎜asarch And the distance between the craziness and geniality is
only measured by the success 18:35⎜asarch Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistentdiff -u libdrm-2.4.33/debian/changelog libdrm-2.4.33/debian/changelog
--- libdrm-2.4.33/debian/changelog
+++ libdrm-2.4.33/debian/changelog
@@ -1,3 +1,9 @@
+libdrm (2.4.33-1+m68k.1) unreleased; urgency=low
+
+  * Build-Depends += libatomic-ops-dev [m68k] (Closes: #654329)
+
+ -- Thorsten Glaser t...@mirbsd.de  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
--- libdrm-2.4.33/debian/control
+++ libdrm-2.4.33/debian/control
@@ -11,6 +11,7 @@
  libpthread-stubs0-dev,
  libudev-dev [linux-any],
  libpciaccess-dev,
+ libatomic-ops-dev [m68k],
 Standards-Version: 3.9.2
 Section: libs
 Vcs-Git: git://git.debian.org/git/pkg-xorg/lib/libdrm

Bug#654630: Please review this diff for atomic ops in mesa on m68k

[Thorsten Glaser]

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 trying that now (patched package is compiling
on m68k and an amd64 VM) so expect results in three days or
so. ☺


“Or so.”

Turns out init_sync_libfuncs (added in gcc r181134) is not
in 4.6, and without that, handling of the atomic builtins
looks funny; it touches quite a bit of MI code and probably
needs later followup commits (I’ve seen references to other
commits touching this function), so I give up on this.

We’ll “just” have to build Mesa with gcc-4.7 next time. This
of course will have to wait until gcc-4.7 is in unstable, but
it’s looked good so far.

bye,
//mirabilos
-- 
[00:02] Vutral gecko: benutzt du emacs ?
[00:03] gecko nö  [00:03] gecko nur n normalen mac
[00:04] Vutral argl   [00:04] Vutral ne den editor
-- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)



--
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/pine.bsm.4.64l.1201281421290.31...@herc.mirbsd.org

Bug#654630: Please review this diff for atomic ops in mesa on m68k

[Thorsten Glaser]

Dear m68k porters,

mesa FTBFS on m68k due to lack of GCC atomic intrinsics. (Why are
they (still) missing, anyway?) I’ve had a look at other patches
floating around on this mailing list and drafted the attached diff
which makes it at least compile again. My knowledge is not enough
to validate that this DTRT, especially where multi-threaded pro‐
gramming is involved, so please look it over.

At first I wanted to use libatomic-ops-dev, but since Gallium hard‐
codes the use of pointers to int32_t, it wasn’t feasible without
touching large parts of the code, hence the m68k-specific fix, as
seems to have been tradition in several places.

bye,
//mirabilos, who’s currently pretty busy with daylife ☹
-- 
  “Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool.”
-- Edward Burrdiff -Nru mesa-7.11.2/debian/changelog mesa-7.11.2/debian/changelog
--- mesa-7.11.2/debian/changelog2012-01-10 08:48:31.0 +
+++ mesa-7.11.2/debian/changelog2012-01-10 08:49:40.0 +
@@ -1,3 +1,9 @@
+mesa (7.11.2-1+m68k.1) unreleased; urgency=low
+
+  * Add atomic operations for m68k. (Closes: #654630)
+
+ -- Thorsten Glaser t...@mirbsd.de  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-atomic-ops.diff  1970-01-01 
00:00:00.0 +
+++ mesa-7.11.2/debian/patches/15-m68k-atomic-ops.diff  2012-01-10 
08:49:40.0 +
@@ -0,0 +1,90 @@
+Index: mesa-7.11.2/src/gallium/auxiliary/util/u_atomic.h
+===
+--- mesa-7.11.2.orig/src/gallium/auxiliary/util/u_atomic.h 2012-01-08 
17:41:45.0 +
 mesa-7.11.2/src/gallium/auxiliary/util/u_atomic.h  2012-01-08 
21:09:19.0 +
+@@ -31,6 +31,9 @@
+ #define PIPE_ATOMIC_ASM_GCC_X86
+ #elif (defined(PIPE_CC_GCC)  defined(PIPE_ARCH_X86_64))
+ #define PIPE_ATOMIC_ASM_GCC_X86_64
++#elif (defined(PIPE_CC_GCC)  defined(__m68k__))
++/* hopefully 68020 or better, Linux */
++#define PIPE_ATOMIC_ASM_GCC_M68K
+ #elif defined(PIPE_CC_GCC)  (PIPE_CC_GCC_VERSION = 401)
+ #define PIPE_ATOMIC_GCC_INTRINSIC
+ #else
+@@ -343,6 +346,75 @@
+ #endif
+ 
+ 
++#if defined(PIPE_ATOMIC_ASM_GCC_M68K)
++#define PIPE_ATOMIC GCC m68k assembly
++
++#ifdef __cplusplus
++extern C {
++#endif
++
++#define p_atomic_set(_v, _i) (*(_v) = (_i))
++#define p_atomic_read(_v) (*(_v))
++
++#define p_atomic_m68k_cmpxchg(p, old, new, dst)   \
++  __asm__ __volatile__(casl %0,%2,%1\
++   : =d (dst), =m (*p)\
++   : d (new), 0 (old), m (*p))
++
++static INLINE int32_t
++p_atomic_m68k_add_and_fetch(int32_t *v, int32_t i)
++{
++   int32_t prev, next;
++
++   for (;;) {
++  prev = *v;
++  next = prev + i;
++  p_atomic_m68k_cmpxchg(v, prev, next, prev);
++  if (prev == next)
++ return next;
++   }
++}
++
++static INLINE boolean
++p_atomic_dec_zero(int32_t *v)
++{
++   return (p_atomic_m68k_add_and_fetch(v, (int32_t)-1) == 0);
++}
++
++static INLINE void
++p_atomic_inc(int32_t *v)
++{
++   p_atomic_m68k_add_and_fetch(v, 1);
++}
++
++static INLINE void
++p_atomic_dec(int32_t *v)
++{
++   p_atomic_m68k_add_and_fetch(v, (int32_t)-1);
++}
++
++static INLINE int32_t
++p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
++{
++   int32_t prev, dest;
++
++   for (;;) {
++  prev = *v;
++  if (prev != old)
++ return prev;
++  p_atomic_m68k_cmpxchg(v, prev, _new, dest);
++  if (dest == _new)
++ return prev;
++   }
++}
++
++#ifdef __cplusplus
++}
++#endif
++
++#endif /* PIPE_ATOMIC_ASM_GCC_M68K */
++
++
+ #ifndef PIPE_ATOMIC
+ #error No pipe_atomic implementation selected
+ #endif
diff -Nru mesa-7.11.2/debian/patches/series mesa-7.11.2/debian/patches/series
--- mesa-7.11.2/debian/patches/series   2012-01-10 08:48:31.0 +
+++ mesa-7.11.2/debian/patches/series   2012-01-10 08:49:40.0 +
@@ -7,3 +7,4 @@
 11-hurd-ftbfs-again.diff
 13-llvm-config-pick-a-version.diff
 14-load-swrastg-before-swrast.diff
+15-m68k-atomic-ops.diff

Bug#654630: Please review this diff for atomic ops in mesa on m68k

[Thorsten Glaser]

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 otherwise the cmpxchg syscall
can be used, but, as I haven’t seen an example of it in use, I’ve not
felt like experimenting.

If anyone feeld like making an upstreamable diff…

Andreas Schwab dixit:

 mesa FTBFS on m68k due to lack of GCC atomic intrinsics. (Why are
 they (still) missing, anyway?) Ib

 Perhaps Andreas knows?

 They are now implemented in 4.7.

Great, good to know, thanks. Maybe we can just keep this patch
around locally until such time as 4.7 is used, so no need to
bother upstream. Unless my assumption that all Debian/m68k targets
have CAS or something else with the patch is wrong. I’ve strictly
tested only whether the result compiles. (This will fulfill quite
a lot of B-D now.)

bye,
//mirabilos, who unfortunately doesn’t see an end to dayjob work
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  -- Tonnerre, psychoschlumpf and myself in #nosec



--
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/pine.bsm.4.64l.1201101905260.6...@herc.mirbsd.org

Bug#654630: mesa: [m68k] FTBFS due to lack of GCC atomic builtins

[Thorsten Glaser]

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, d.A.] mechanically produce pretty 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



-- 
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/pine.bsm.4.64l.1201071851370.14...@herc.mirbsd.org

Bug#654630: mesa: [m68k] FTBFS due to lack of GCC atomic builtins

[Thorsten Glaser]

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 builtins which are not supported
on all architectures. Can it be told to use libatomic-ops-dev instead,
which implements all this stuff correctly?

Otherwise, PIPE_ATOMIC_OS_UNLOCKED might be an option, but if mesa
is used from threaded programmes, probably unsafe even on !SMP.

Any idea?

Thanks in advance,
//mirabilos
-- 
15:41⎜Lo-lan-do:#fusionforge Somebody write a testsuite for helloworld :-)



--
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/alpine.deb.2.02.1201041833000.5...@tglase.lan.tarent.de

Bug#654329: libdrm: FTBFS when atomic operations are only available through libatomic-ops-dev

[Thorsten Glaser]

Source: libdrm
Version: 2.4.29-1
Severity: important
Tags: patch

Hi,

your package FTBFS on m68k with the following error message:

[…]
checking for native atomic primitives... checking atomic_ops.h usability... no
checking atomic_ops.h presence... no
checking for atomic_ops.h... no
checking for atomic_cas_uint... no
none
configure: error: libdrm_radeon depends upon atomic operations, which were not 
found for your compiler/cpu. Try compiling with -march=native, or install the 
libatomics-op-dev package, or, failing both of those, disable support for 
Radeon support by passing --disable-radeon to ./configure
dh_auto_configure: ../configure --build=m68k-linux-gnu --prefix=/usr 
--includedir=${prefix}/include --mandir=${prefix}/share/man 
--infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--libdir=${prefix}/lib/m68k-linux-gnu --libexecdir=${prefix}/lib/m68k-linux-gnu 
--disable-maintainer-mode --disable-dependency-tracking --enable-static=yes 
--enable-udev --enable-libkms --enable-vmwgfx-experimental-api 
--enable-nouveau-experimental-api --enable-radeon --disable-intel returned exit 
code 1
make[1]: *** [override_dh_auto_configure] Error 2
make[1]: Leaving directory `/tmp/buildd/libdrm-2.4.29'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
E: Failed autobuilding of package

The following trivial patch does fix the problem and allow the package
to build successfully, to get B-D for mesa ready:

--- libdrm-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 t...@mirbsd.de  Mon, 02 Jan 2012 22:02:42 +
+
 libdrm (2.4.29-1) unstable; urgency=low
 
   * New upstream release:
diff -Nru libdrm-2.4.29/debian/control libdrm-2.4.29/debian/control
--- libdrm-2.4.29/debian/control2012-01-02 22:17:19.0 +
+++ libdrm-2.4.29/debian/control2012-01-02 22:19:58.0 +
@@ -11,6 +11,7 @@
  libpthread-stubs0-dev,
  libudev-dev [linux-any],
  libpciaccess-dev,
+ libatomic-ops-dev [m68k],
 Standards-Version: 3.9.2
 Section: libs
 Vcs-Git: git://git.debian.org/git/pkg-xorg/lib/libdrm



(Also, believe it or not, but the Atari guys at OpenRheinRuhr did have
a PCI Radeon card, by means of self-soldered converters, on their sy‐
stems; GEM in 1440x900 looks _good_ but the keyboard mouse-emulation,
for when the hardware goes on strike, is vry slow then.)

Thanks for your consideration,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh



--
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/pine.bsm.4.64l.1201022329340.29...@herc.mirbsd.org

Bug#653452: libpciaccess FTBFS: inaccurate versioning of B-D

[Thorsten Glaser]

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 enough.



-- 
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/pine.bsm.4.64l.1112272319190.3...@herc.mirbsd.org

Bug#653452: libpciaccess FTBFS: inaccurate versioning of B-D

[Thorsten Glaser]

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 of
course not the usual use case…

(I guess if someone manages to set up a buildd we’ll get recent
X eventually. I don’t have the knowledge and, sadly, at the
moment not much time for anything.)

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  -- Tonnerre, psychoschlumpf and myself in #nosec



--
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/pine.bsm.4.64l.1112281435420.17...@herc.mirbsd.org

Bug#555938: Composing

[Thorsten Glaser]

Compose + ( + A + ) always worked for me.

bye,
//mirabilos
-- 
20:54⎜SvenG:#grml 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 listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1011260932480.23...@herc.mirbsd.org