Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore
It was difficult to find in the Gnome Settings, but yes, you're right : there's a French(legacy,variant) that can be reached and should be taken to have the dead keys back. So it isn't a bug, eventually, that I've encountered. Except that I don't understand how my keyboard might have changed its layout once. Thanks for all the help you provided ! It's fine now. À È Ù Ì Ỳ... Regards, Marc Le Bihan De : "Simon McVittie" A : gru...@laposte.net,1072...@bugs.debian.org,xkeyboard-con...@packages.debian.org,debian-l10n-fre...@lists.debian.org,i...@packages.debian.org Envoyé: lundi 10 Juin 2024 13:37 Objet : Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore On Mon, 10 Jun 2024 at 12:35:25 +0200, gru...@laposte.net wrote: > Among GNOME settings, I have three choices available: > Français > Français Azerty > Français Azerty (AFNOR) There should be a lot more than that. I don't speak French, but in an English-language GNOME installation on Debian 12, if I click on "Other" and search for French, choices available to me include: * French (alt.) * French (alt., Latin-9 only) * French (alt., no dead keys) * French (legacy, alt.) * French (legacy, alt., no dead keys) * French (no dead keys) ... and many more. Many of these are AZERTY layouts even though their names don't specifically say so. Based on the information in /usr/share/X11/xkb/symbols/fr, it seems that "French (legacy, alt.)" should be an AZERTY layout where AltGr+[7] is a "dead_grave" dead key. If I'm reading the translation files correctly, the French translation of "French (legacy, alt.)" might be "Français (obsolète, variante)". I am not a French speaker and I am not familiar with the history of French keyboard layouts, so I cannot say whether you are right or wrong to expect that AltGr+[7] should be a dead key. Perhaps would be able to clarify whether there is a bug in xkb-data or not. Based on the information available in this bug report, I'm confident that GLib is now doing the right thing, so this is not a GLib bug. > Français > Français Azerty > don't fire dead keys on the first row of keys > but > Français Azerty (AFNOR) > does. Strange... If you think this is a regression when compared with older versions of Debian, then the xkb-data maintainers will need to know the answer to this question: What was the most recent date when your keyboard had the behaviour that you expected, and what version of Debian were you running at that time? Thanks, smcv
Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore
On Mon, 10 Jun 2024 at 12:35:25 +0200, gru...@laposte.net wrote: > Among GNOME settings, I have three choices available: > Français > Français Azerty > Français Azerty (AFNOR) There should be a lot more than that. I don't speak French, but in an English-language GNOME installation on Debian 12, if I click on "Other" and search for French, choices available to me include: * French (alt.) * French (alt., Latin-9 only) * French (alt., no dead keys) * French (legacy, alt.) * French (legacy, alt., no dead keys) * French (no dead keys) ... and many more. Many of these are AZERTY layouts even though their names don't specifically say so. Based on the information in /usr/share/X11/xkb/symbols/fr, it seems that "French (legacy, alt.)" should be an AZERTY layout where AltGr+[7] is a "dead_grave" dead key. If I'm reading the translation files correctly, the French translation of "French (legacy, alt.)" might be "Français (obsolète, variante)". I am not a French speaker and I am not familiar with the history of French keyboard layouts, so I cannot say whether you are right or wrong to expect that AltGr+[7] should be a dead key. Perhaps <https://lists.debian.org/debian-user-french/> would be able to clarify whether there is a bug in xkb-data or not. Based on the information available in this bug report, I'm confident that GLib is now doing the right thing, so this is not a GLib bug. > Français > Français Azerty > don't fire dead keys on the first row of keys > but > Français Azerty (AFNOR) > does. Strange... If you think this is a regression when compared with older versions of Debian, then the xkb-data maintainers will need to know the answer to this question: What was the most recent date when your keyboard had the behaviour that you expected, and what version of Debian were you running at that time? Thanks, smcv
Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore
I've chosen another configuration to regain the exclamation mark with
sudo dpkg-reconfigure keyboard-configuration
Among GNOME settings, I have three choices available:
Français
Français Azerty
Français Azerty (AFNOR)
the two firsts displays with ` under the 7 (and Français as also an 1/8 sign at
the key upper top), but ` of the -7 isn't a dead key and doesn't
produce a À.
the last one, Français Azerty (AFNOR), makes the -7 produce a _ sign
(or something like similar) that is a dead key!
Français
Français Azerty
don't fire dead keys on the first row of keys
but
Français Azerty (AFNOR)
does. Strange...
De : "Simon McVittie"
A :
gru...@laposte.net,1072...@bugs.debian.org,xkeyboard-con...@packages.debian.org,debian-l10n-fre...@lists.debian.org,i...@packages.debian.org
Envoyé: lundi 10 Juin 2024 11:27
Objet : Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys
doesn't type an À anymore
On Mon, 10 Jun 2024 at 05:48:44 +0200, gru...@laposte.net wrote:
> I did a
> $ sudo dpkg-reconfigure keyboard-configuration
This changes the keyboard layout that is used for the login screen, and
for any session that does not have its own, separate configuration.
It does not change the keyboard layout for sessions that have already
saved their own session-specific configuration.
> $ dconf dump /org/gnome/desktop/input-sources/
> [/]
> show-all-sources=false
> sources=[('xkb', 'fr+azerty')]
> xkb-options=['lv3:ralt_switch']
Your personal GNOME configuration is still using fr+azerty. If you want
a different layout while you are logged in to GNOME, you will need to
reconfigure that in the Settings application (gnome-control-center).
If you want to reset the layout used within GNOME to match the layout
used by the login screen, you can run
dconf reset /org/gnome/desktop/input-sources/sources
and then log out and back in.
> On logscreen then, and still now, I have the french keyboard
> BUT with the ! (exclamation mark) replaced by the ; (semicolon)
That's the AFNOR layout that you selected. Several other punctuation marks
are in different places in the AFNOR layout: see
for details.
If you don't want the punctuation to move around in this way, then you
should not select the AFNOR variant.
https://norme-azerty.fr/ shows "AZERTY traditionnel" which is something
similar to the layout you were previously using, and
"Nouvel AZERTY" which is the layout that is labelled as AFNOR in Debian.
smcv
Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore
On Mon, 10 Jun 2024 at 05:48:44 +0200, gru...@laposte.net wrote:
> I did a
> $ sudo dpkg-reconfigure keyboard-configuration
This changes the keyboard layout that is used for the login screen, and
for any session that does not have its own, separate configuration.
It does not change the keyboard layout for sessions that have already
saved their own session-specific configuration.
> $ dconf dump /org/gnome/desktop/input-sources/
> [/]
> show-all-sources=false
> sources=[('xkb', 'fr+azerty')]
> xkb-options=['lv3:ralt_switch']
Your personal GNOME configuration is still using fr+azerty. If you want
a different layout while you are logged in to GNOME, you will need to
reconfigure that in the Settings application (gnome-control-center).
If you want to reset the layout used within GNOME to match the layout
used by the login screen, you can run
dconf reset /org/gnome/desktop/input-sources/sources
and then log out and back in.
> On logscreen then, and still now, I have the french keyboard
> BUT with the ! (exclamation mark) replaced by the ; (semicolon)
That's the AFNOR layout that you selected. Several other punctuation marks
are in different places in the AFNOR layout: see
Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore
The idea that my layout could have changed was pertinent:
I did a
$ sudo dpkg-reconfigure keyboard-configuration
chose pc105 with AZERTY AFNOR
$ cat /etc/default/keyboard
I've did a reconfiguration of my keyboard an now I have
XKBMODEL="pc105"
XKBLAYOUT="fr"
XKBVARIANT="afnor"
XKBOPTIONS=""
BACKSPACE="guess"
$ dconf dump /org/gnome/desktop/input-sources/
[/]
show-all-sources=false
sources=[('xkb', 'fr+azerty')]
xkb-options=['lv3:ralt_switch']
as ` dead keys on the top row weren't working still, I've rebooted.
I saw a show FAILED somewhere during that reboot (that didn't appeared in
further reboots after) but I came to the login screen.
On logscreen then, and still now, I have the french keyboard
BUT with the ! (exclamation mark) replaced by the ; (semicolon)
then entering the session, layout revert to normal, except that I still don't
have `a or `A giving À
De : "Simon McVittie"
A :
gru...@laposte.net,1072...@bugs.debian.org,xkeyboard-con...@packages.debian.org,debian-l10n-fre...@lists.debian.org,i...@packages.debian.org
Envoyé: dimanche 9 Juin 2024 19:36
Objet : Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys
doesn't type an À anymore
On Sun, 09 Jun 2024 at 18:16:01 +0100, Simon McVittie wrote:
> However, the French layout in /usr/share/X11/xkb/symbols/fr says that
> pressing the 7 key (with AltGr held) sends "grave" like my UK English
> layout, and not "dead_grave" like the German layout. So if that previously
> participated in dead-key sequences, I don't understand why...
Were you perhaps using the "latin9" or "French (legacy, alt.)" keyboard
layout before? Unlike the default French keyboard layout, the latin9 layout
*does* map AltGr+[7] to "dead_grave", a dead key.
I don't know the name of that keyboard layout in French - it might be
"Français (obsolète, variante)". Perhaps a French-speaking developer
could help here?
What is the output of these commands?
cat /etc/default/keyboard
and
dconf dump /org/gnome/desktop/input-sources/
Processed: Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore
Processing control commands: > reassign -1 xkb-data 2.35.1-1 Bug #1072720 [libglib2.0-0] libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore Bug reassigned from package 'libglib2.0-0' to 'xkb-data'. No longer marked as found in versions glib2.0/2.74.6-2+deb12u2. Ignoring request to alter fixed versions of bug #1072720 to the same values previously set Bug #1072720 [xkb-data] libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore Marked as found in versions xkeyboard-config/2.35.1-1. -- 1072720: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072720 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore
Control: reassign -1 xkb-data 2.35.1-1
On Sun, 09 Jun 2024 at 23:13:32 +0200, gru...@laposte.net wrote:
> XKBMODEL="pc105"
> XKBLAYOUT="fr"
> XKBVARIANT="azerty"
(and)
> $ dconf dump /org/gnome/desktop/input-sources/
> [/]
> show-all-sources=false
> sources=[('xkb', 'fr+azerty')]
> xkb-options=['lv3:ralt_switch']
It seems that instead of the "default" French keyboard, you're using a
French keyboard variant named "azerty". This confuses me, because I
thought the "default" French keyboard layout is already an AZERTY
layout, so specifying AZERTY seems redundant... but the two layouts
seem to be maybe different?
What was the most recent date when your keyboard had the behaviour
that you expected, and what version of Debian were you running at
that time?
> What I notice, is that when I type the backtick character, even on a terminal,
> it doesn't wait without displaying nothing (like previous versions of Debian
> did) or doesn't wait showing the backtick underlined
> like it does when I use the ^ dead key.
That's the expected behaviour on keyboard layouts where the backtick is
just a backtick and not a dead key, like my UK English. In these layouts,
the data file defining the keyboard layout would say "grave".
The behaviour you were hoping for (waits while displaying an underlined
backtick/accent) is what is expected in keyboard layouts where the
backtick is defined to be a dead key, like German. In these layouts, the
data file defining the keyboard layout would say "dead_grave".
Some French keyboard layouts have AltGr+[7] as a backtick ("grave"), like
it is for the similarly labelled key in UK English. Others have AltGr+[7]
as a dead key ("dead_grave"), like it for the similarly labelled key in
German. So, it matters which exact variant you have selected.
It seems that your keyboard layout is one of the variants with "grave"
but you were expecting that it should have "dead_grave". This could
be because your configuration has changed, or because your configured
variant has stayed the same but its meaning has changed. I don't know
what component that would be a bug in, but it isn't GLib that controls
this, so it seems very unlikely to be a GLib regression.
The "default" French keyboard layout is probably labelled in the UI as
just "Français" or similar, with no other information. In that layout,
as far as I can see from /usr/share/X11/xkb/symbols/fr, the symbol you
get from typing AltGr+[7] is "grave", so it is intentionally not a dead
key (same as the backtick on a UK English keyboard).
But, there are several different layouts listed in
/usr/share/X11/xkb/symbols/fr. Some of them have AltGr+[7] mapped to
"dead_grave", which *is* a dead key (same as the backtick on a German
keyboard). The ones I can find that have that behaviour are
identified as "French (legacy, alt.)" and "French (Breton)" (but Breton
is not an AZERTY layout so probably you don't want that one).
"French (legacy, alt.)" might be identified as "Français (obsolète,
variante)" with French language settings.
Your current configuration with XKBVARIANT="azerty" and
sources=[('xkb', 'fr+azerty')] should mean that you are using the
"azerty" variant (lines 1059 to 1141 in /usr/share/X11/xkb/symbols/fr
from xkb-data version /usr/share/X11/xkb/symbols/fr) and in that variant,
as far as I can see, AltGr+[7] is not intended to be a dead key.
There is also a variant "French (AZERTY, AFNOR)" which moves the
"dead_grave" dead key from AltGr+[7] to AltGr+[3], while providing
it as a dead key.
If the French-speaking community considers the layouts in
/usr/share/X11/xkb/symbols/fr to be wrong, then that would be something
that would need to be fixed in xkb-data (part of xkeyboard-config).
I don't know whether what you expected is the same as what the
French-speaking community would expect.
> When I'm using the ` dead key, I :
> 1. type ` and see on screen: ` immediately, and with no underline
> 2. the terminal or editor doesn't wait for me to type another character
> especially.
> 3. I type any other character. `z, `a...
> In fact, ` isn't considered as a dead char at all.
All of this is consistent with your [`] behaving as an ordinary backtick
key (not a dead key), like the one on a UK English keyboard.
> interesting! while the ^ key right to the P on the french keyboard, provides a
> ^ that is a dead char and returns an ê
> the ^ given by a e isn't a dead char!
That's what /usr/share/X11/xkb/symbols/fr says. I don't know whether that's
what a typical French keyboard user would expect, but it's what the xkb
data s
Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore
$ cat /etc/default/keyboard
# KEYBOARD CONFIGURATION FILE
# Consult the keyboard(5) manual page.
XKBMODEL="pc105"
XKBLAYOUT="fr"
XKBVARIANT="azerty"
XKBOPTIONS="compose:menu"
BACKSPACE="guess"
$ dconf dump /org/gnome/desktop/input-sources/
[/]
show-all-sources=false
sources=[('xkb', 'fr+azerty')]
xkb-options=['lv3:ralt_switch']
I'm using a 105 classical keyboard.
I looks like the backtick is now a backtick on french keyboard,
and isn't considered as a grave accent anymore => it isn't a dead key anymore.
What I notice, is that when I type the backtick character, even on a terminal,
it doesn't wait without displaying nothing (like previous versions of Debian
did) or doesn't wait showing the backtick underlined
like it does when I use the ^ dead key.
When I'm using the ^ key, I :
1. type ^ and see on screen: ^ underlined : this marks a dead key
2. the terminal or editor is now "waiting" for me to type another character.
3. I type any other character. ^z => ẑ, ^a => â...
When I'm using the ` dead key, I :
1. type ` and see on screen: ` immediately, and with no underline
2. the terminal or editor doesn't wait for me to type another character
especially.
3. I type any other character. `z, `a...
In fact, ` isn't considered as a dead char at all.
For À, I shall type: a to make it appear, in normal cases.
Here it responds `A
e gives ^E
e gives ^e
interesting! while the ^ key right to the P on the french keyboard, provides a
^ that is a dead char and returns an ê
the ^ given by a e isn't a dead char!
It's the top row of keys of a 102 or 105 keyboard that would not fire dead keys
anymore?
My apt history (I noticed the problem on May, 8th) :
Start-Date: 2024-05-07 06:41:05
Commandline: apt-get upgrade
Requested-By: lebihan (1000)
Upgrade: linux-compiler-gcc-12-x86:amd64 (6.1.85-1, 6.1.90-1),
linux-kbuild-6.1:amd64 (6.1.85-1, 6.1.90-1), virtualbox-7.0:amd64
(7.0.16-162802~Debian~bookworm, 7.0.18-162988~Debian~bookworm),
linux-libc-dev:amd64 (6.1.85-1, 6.1.90-1)
End-Date: 2024-05-07 06:41:41
Start-Date: 2024-05-08 06:04:05
Commandline: apt-get upgrade
Requested-By: lebihan (1000)
Upgrade: google-chrome-stable:amd64 (124.0.6367.118-1, 124.0.6367.155-1),
libglib2.0-bin:amd64 (2.74.6-2, 2.74.6-2+deb12u1), libglib2.0-data:amd64
(2.74.6-2, 2.74.6-2+deb12u1), gnome-shell:amd64 (43.9-0+deb12u1,
43.9-0+deb12u2), gnome-shell-common:amd64 (43.9-0+deb12u1, 43.9-0+deb12u2),
libglib2.0-0:amd64 (2.74.6-2, 2.74.6-2+deb12u1), libglib2.0-0:i386 (2.74.6-2,
2.74.6-2+deb12u1), gnome-shell-extension-prefs:amd64 (43.9-0+deb12u1,
43.9-0+deb12u2)
End-Date: 2024-05-08 06:04:12
Start-Date: 2024-05-08 09:22:27
Commandline: apt-get dist-upgrade
Requested-By: lebihan (1000)
Install: linux-headers-6.1.0-21-amd64:amd64 (6.1.90-1, automatic),
linux-headers-6.1.0-21-common:amd64 (6.1.90-1, automatic),
linux-image-6.1.0-21-amd64:amd64 (6.1.90-1, automatic)
Upgrade: linux-headers-amd64:amd64 (6.1.85-1, 6.1.90-1),
linux-image-amd64:amd64 (6.1.85-1, 6.1.90-1)
End-Date: 2024-05-08 09:23:03
Start-Date: 2024-05-09 07:03:38
Commandline: apt-get upgrade
Requested-By: lebihan (1000)
Upgrade: libglib2.0-bin:amd64 (2.74.6-2+deb12u1, 2.74.6-2+deb12u2),
libglib2.0-data:amd64 (2.74.6-2+deb12u1, 2.74.6-2+deb12u2), libglib2.0-0:amd64
(2.74.6-2+deb12u1, 2.74.6-2+deb12u2), libglib2.0-0:i386 (2.74.6-2+deb12u1,
2.74.6-2+deb12u2)
End-Date: 2024-05-09 07:03:40
Start-Date: 2024-05-09 12:09:21
Commandline: apt-get upgrade
Requested-By: lebihan (1000)
Upgrade: libjavascriptcoregtk-4.1-0:amd64 (2.42.5-1~deb12u1, 2.44.1-1~deb12u1),
gir1.2-javascriptcoregtk-4.0:amd64 (2.42.5-1~deb12u1, 2.44.1-1~deb12u1),
gir1.2-javascriptcoregtk-4.1:amd64 (2.42.5-1~deb12u1, 2.44.1-1~deb12u1),
gir1.2-webkit2-4.0:amd64 (2.42.5-1~deb12u1, 2.44.1-1~deb12u1),
gir1.2-webkit2-4.1:amd64 (2.42.5-1~deb12u1, 2.44.1-1~deb12u1),
libjavascriptcoregtk-6.0-1:amd64 (2.42.5-1~deb12u1, 2.44.1-1~deb12u1),
libjavascriptcoregtk-4.0-18:amd64 (2.42.5-1~deb12u1, 2.44.1-1~deb12u1),
libwebkit2gtk-4.1-0:amd64 (2.42.5-1~deb12u1, 2.44.1-1~deb12u1),
libwebkit2gtk-4.0-37:amd64 (2.42.5-1~deb12u1, 2.44.1-1~deb12u1),
libwebkitgtk-6.0-4:amd64 (2.42.5-1~deb12u1, 2.44.1-1~deb12u1)
End-Date: 2024-05-09 12:09:25
Start-Date: 2024-05-10 18:04:46
Commandline: apt-get upgrade
Requested-By: lebihan (1000)
Upgrade: docker-ce-cli:amd64 (5:26.1.1-1~debian.12~bookworm,
5:26.1.2-1~debian.12~bookworm), libdav1d-dev:amd64 (1.0.0-2, 1.0.0-2+deb12u1),
google-chrome-stable:amd64 (124.0.6367.155-1, 124.0.6367.201-1),
postgresql-14:amd64 (14.11-1.pgdg120+2, 14.12-1.pgdg120+1), libdav1d6:amd64
(1.0.0-2, 1.0.0-2+deb12u1), libdav1d6:i386 (1.0.0-2, 1.0.0-2+deb12u1),
filebeat:amd64 (8.13.3, 8.13.4), logstash:amd64 (1:8.13.3-1, 1:8.13.4-1),
docker-ce:amd64 (5:26.1.1-1~debian.12~bookworm, 5:26.1.2-1~debian.12~bookworm),
postgres
Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore
On Sun, 09 Jun 2024 at 18:16:01 +0100, Simon McVittie wrote: > However, the French layout in /usr/share/X11/xkb/symbols/fr says that > pressing the 7 key (with AltGr held) sends "grave" like my UK English > layout, and not "dead_grave" like the German layout. So if that previously > participated in dead-key sequences, I don't understand why... Were you perhaps using the "latin9" or "French (legacy, alt.)" keyboard layout before? Unlike the default French keyboard layout, the latin9 layout *does* map AltGr+[7] to "dead_grave", a dead key. I don't know the name of that keyboard layout in French - it might be "Français (obsolète, variante)". Perhaps a French-speaking developer could help here? What is the output of these commands? cat /etc/default/keyboard and dconf dump /org/gnome/desktop/input-sources/
Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore
ibus and xkeyboard-config maintainers and debian-l10n-french cc'd in the hope that someone understands what is happening here, because I dont think this is actually a libglib2.0-0 bug. On Sun, 09 Jun 2024 at 17:23:27 +0200, gru...@laposte.net wrote: > When you did the fix that repaired most of the #1070745, didn't you > forget to enable/check the rules for keyboards having backtick for > grave accent? That's not how #1070745 was fixed: I didn't change the rules for any specific keyboard layout. The bug that caused #1070745 was that a security fix in GLib broke the communication between applications and ibus, so *all* dead keys stopped working (and so did everything else that goes via ibus, like Compose key combinations). I fixed #1070745 by making GLib's security checks less strict, so that ibus could work again. In the bug you've reported, the dead-keys feature does work in general (I know this because you say you can still type [^],[e] and get ê), so ibus must be *mostly* working - but there must be a more specific problem that affects the [`],Shift+[A] sequence, at least with your settings. Please look at /var/log/apt/history.log. What other packages did you update at around the time that this stopped working for you? Is there a recently-updated package that you can downgrade that gives you the old behaviour back? > With most keyboards, most languages, `A doesn't give À > But with some, like the French one that has the backtick for grave accent > too, it should return À Yes: on many keyboard layouts that have a key marked [`], it's expected to be only a backtick symbol, and doesn't act as a dead key. The German layout that I tested is unusual in having [`] available as a dead key which can be combined with letters to get an accented letter. On my UK English keyboard layout /usr/share/X11/xkb/symbols/gb, the key marked [`] sends xkb symbol "grave", which is not a dead key. US English /usr/share/X11/xkb/symbols/us is similar. On the German layout that I tested, /usr/share/X11/xkb/symbols/de, the key to the left of Backspace (with Shift held) sends xkb symbol "dead_grave", which *is* a dead key. However, the French layout in /usr/share/X11/xkb/symbols/fr says that pressing the 7 key (with AltGr held) sends "grave" like my UK English layout, and not "dead_grave" like the German layout. So if that previously participated in dead-key sequences, I don't understand why... According to the same file, if you press AltGr + [*] (the key printed with * and µ, between Shift and $) then *that* should send "dead_grave", which is a dead key that can be followed by a letter to get a grave accent. > => Please note that ^e gives ê correctly > but `A doesn't What about [`],[e], or [`],[a], or other sequences involving the dead-key grave accent? Or, the other way around: do you expect [^],Shift+[e] to give you Ê, and if yes, what does it actually do? Or similar sequences? When you say you are typing ` followed by A, what exact keys are you pressing? You say that ` is on the 7 key, but based on the diagram you linked, pressing the 7 key without Shift should be è. I think when you say you type `A and expect to get À, what you are typing is actually: AltGr + [7], Shift + [A]. Is that correct? Or if not, what? Similarly, when you say you are typing ^ followed by e, what exact keys are you pressing? Is it the key between P and $, followed by [E]? Or is it AltGr+[9] followed by [E]? If I'm reading correctly, the key between P and $ is expected to be a "dead_circumflex" (which is part of dead-key sequences) but AltGr+[9] is meant to be an "asciicircum" which is not a dead key. smcv
Buster has an too old version of libxkbfile and it prevents to install the new version of vscode
Package: libxkbfile Version: 1:1.0.9-2 Hello, With the last version of Microsoft vscode (1.87.0-1709078641), it is not more possible to install it because of the following dependency : libxkbfile1 (>= 1:1.1.0) Under Buster, the last version is 1:1.0.9-2 Under Bullseye, the last version is 1:1.1.0-1 There's not seems to have a big difference between both packages. Could it be possible to backport a version of libxkbfile greater than or equal to 1:1.1.0 from Bullseye to Buster ? Thank you by advance Best Regards Karim MOGAADI karim-externe.moga...@edf.fr Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message. Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus. This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. E-mail communication cannot be guaranteed to be timely secure, error or virus-free.
Bug#1050884: evdev.4: some remarks and an editorial patch for the manual
button is 0 and 126:is on, any motion of the device is converted into wheel events. Default: 4. 131:press/release events in wheel emulation mode. Default: 10. Property: "Evdev 139:the name \*qinertia\*q is a misnomer. This option defines the distance 144:options. It does not enable inertia in the 150:must be pressed before wheel emulation is started. If the 153:is sent. Default: 200. Property: "Evdev Wheel Emulation Timeout". 156:Enable third button emulation. Third button emulation emits a right button 157:event (by default) by pressing and holding the first button. The first 159:than the configured threshold for the emulation to activate. Otherwise, the 160:first button event is posted as normal. Default: off. Property: "Evdev 166:Default: 1000. Property: "Evdev Third Button Emulation Timeout". 175:emulation. If the device moves by more than this threshold before the third 178:Default: 20. Property: "Evdev Third Button Emulation Threshold". 181:Force a grab on the event device. Doing so will ensure that no other driver 183:events to /dev/kbd or /dev/input/mice. Events from this device will not be 184:sent to virtual devices (e.g. rfkill or the Macintosh mouse button emulation). 190:Invert the given axis. Default: off. Property: "Evdev Axis Inversion". 195:Ignore the specified type of axis. Default: unset. The X server cannot deal 196:with devices that have both relative and absolute axes. Evdev tries to guess 198:mice and relative axes for tablets, touchscreens and touchpad. These options 199:allow to forcibly disable an axis type. Mouse wheel axes are exempt and will 200:work even if relative axes are ignored. No property, this configuration must 204:axes regardless of the presence of other axes. This may trigger buggy 205:behavior and events from this axis are always forwarded. Users are 210:coordinate system than reported to the X server. This feature is required 212:originally reported by the kernel (e.g. touchscreens). The scaling to the 214:the transformation. Property: "Evdev Axis Calibration". 222:Swap x/y axes. Default: off. Property: "Evdev Axes Swap". 230:is mapped to the positive X axis motion. Default: no mapping. Property: 239:is mapped to the positive Y axis motion. Default: "4 5". Property: 245:based on the device's capabilities. This option is provided for devices that 261:Sets the resolution of the device in dots per inch. The resolution is used 262:to scale relative motion events from mouse devices to 1000 DPI resolution. This 264:acceleration. If set to 0 no scaling will be performed. Default: "0". 276:2 boolean values (8 bit, 0 or 1), order X, Y. 1 inverts the axis. 279:1 boolean value (8 bit, 0 or 1). 1 swaps x/y axes. 282:8-bit. Either 1 value or pairs of values. Value range 0-32, 0 disables a 298:4 8-bit values, order X up, X down, Y up, Y down. 0 disables a value. -.-. Rephrase the beginning of a sentence, if it starts with a digit (see a style manual). 272:4 32-bit values, order min-x, max-x, min-y, max-y or 0 values to disable 276:2 boolean values (8 bit, 0 or 1), order X, Y. 1 inverts the axis. 279:1 boolean value (8 bit, 0 or 1). 1 swaps x/y axes. 282:8-bit. Either 1 value or pairs of values. Value range 0-32, 0 disables a 286:1 boolean value (8 bit, 0 or 1). 289:1 16-bit positive value. 292:1 8-bit value, allowed range 0-32, 0 disables the button. 295:1 boolean value (8 bit, 0 or 1). 298:4 8-bit values, order X up, X down, Y up, Y down. 0 disables a value. 301:1 8-bit value, allowed range 0-32, 0 disables the button. 304:1 16-bit positive value. 307:1 16-bit positive value. 310:3 32-bit values: vertical, horizontal and dial. -.-. The name of a man page is set in bold type and the section in roman (see man-pages(7)). 37:directive (refer to xorg.conf(5)) instead of manual 39:xorg.conf(5) are not hot-plug capable. 48:Please refer to xorg.conf(5) for general configuration 243:Specify the X Input 1.x type (see XListInputDevices(3)). 315:Xorg(1), xorg.conf(5), Xserver(1), X(7) -.-. [ "test-groff" is a developmental version of "groff" ] Input file is ./evdev.4 Output from "test-groff -b -mandoc -dAD=l -rF0 -rHY=0 -t -w w -z -rCHECKSTYLE=0": troff: backtrace: file '':26 troff::26: warning: trailing space in the line troff: backtrace: file '':43 troff::43: warning: trailing space in the line troff: backtrace: file '':52 troff::52: warning: trailing space in the line troff: backtrace: file '':67 troff::67: warning: trailing space in the line -.-. Additional changes: Add information about the encoding of the file for "man" (from preconv(1)): '\" -*- coding: utf-8 -*- >From "codespell": evdev.4:197: wich ==> which -.- -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kerne
Bug#1042961: mesa-utils: glxdemo dumps core when called with an empty environment
Francesco Potortì kirjoitti 3.8.2023 klo 13.57: Package: mesa-utils Version: 8.5.0-1 Severity: normal X-Debbugs-Cc: none, Francesco Potortì $ env - glxdemo Segmentation fault (core dumped) Probably because it can't open the display, although it could be more graceful like glxinfo. That said, if you like to see it fixed at some point, file this upstream: https://gitlab.freedesktop.org/mesa/demos/-/issues -- t
Bug#1042961: mesa-utils: glxdemo dumps core when called with an empty environment
Package: mesa-utils Version: 8.5.0-1 Severity: normal X-Debbugs-Cc: none, Francesco Potortì $ env - glxdemo Segmentation fault (core dumped) -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (101, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mesa-utils depends on: ii mesa-utils-bin 8.5.0-1 mesa-utils recommends no packages. mesa-utils suggests no packages. -- no debconf information
Bug#1038939: xserver-xorg-core: Xorg crashed after a Ctrl-C in an xterm
Package: xserver-xorg-core Version: 2:21.1.7-3 Severity: important In the morning, shortly after a kernel upgrade (I hadn't rebooted yet), Xorg crashed immediately after I typed Ctrl-C in an xterm (because I ran a command with lots of output). An excerpt of the journalctl output, though this is not much interesting: Jun 23 10:36:58 zira audit[369004]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined pid=369004 comm="emacs" exe="/usr/bin/emacs-gtk" sig=6 res=1 Jun 23 10:36:58 zira kernel: audit: type=1701 audit(1687509418.596:125): auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined pid=369004 comm="emacs" exe="/usr/bin/emacs-gtk" sig=6 res=1 Jun 23 10:36:58 zira kernel: audit: type=1113 audit(1687509418.596:126): pid=1821 uid=0 auid=1000 ses=2 subj=unconfined msg='op=logout id=1000 exe="/usr/sbin/lightdm" hostname=zira addr=? terminal=/dev/tty7 res=success' Jun 23 10:36:58 zira kernel: audit: type=1701 audit(1687509418.596:127): auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined pid=13335 comm="emacs" exe="/usr/bin/emacs-gtk" sig=6 res=1 Jun 23 10:36:58 zira audit[1821]: USER_LOGOUT pid=1821 uid=0 auid=1000 ses=2 subj=unconfined msg='op=logout id=1000 exe="/usr/sbin/lightdm" hostname=zira addr=? terminal=/dev/tty7 res=success' Jun 23 10:36:58 zira audit[13335]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined pid=13335 comm="emacs" exe="/usr/bin/emacs-gtk" sig=6 res=1 Jun 23 10:36:58 zira lightdm[1821]: pam_unix(lightdm:session): session closed for user vinc17 [...] One of the emacs-gtk processes left a core dump: it aborted due to an X related error: [...] #4 0x55d0cbbb1d25 in emacs_abort () at ./debian/build-src/src/sysdep.c:2282 #5 0x55d0cbbb0d9e in x_connection_closed (dpy=dpy@entry=0x55d0cd029910, error_message=error_message@entry=0x7ffe2320d278 "Connection lost to X server ':0'", ioerror=ioerror@entry=true) at ./debian/build-src/src/xterm.c:10218 dpyinfo = 0x55d0cd13dd60 frame = tail = 0x0 idx = 5 #6 0x55d0cbbb0e6a in x_io_error_quitter (display=0x55d0cd029910) at ./debian/build-src/src/xterm.c:10315 buf = "Connection lost to X server ':0'", '\000' ... #7 0x7f7c2d7d5a8f in _XIOError () at /usr/lib/x86_64-linux-gnu/libX11.so.6 #8 0x7f7c2d7d3a1e in _XReply () at /usr/lib/x86_64-linux-gnu/libX11.so.6 #9 0x7f7c2d7cee3b in XSync () at /usr/lib/x86_64-linux-gnu/libX11.so.6 [...] but this seems to be just a consequence of the Xorg crash. The machine also went into sleep, but again, this is a consequence of the Xorg crash: I got logged out, so that my systemd-inhibit process to prevent the sleep was no longer in effect. Note: below, the kernel does not correspond to the running kernel at that time (I still had 6.1.0-9-amd64). -- Package-specific info: /etc/X11/X does not exist. /etc/X11/X is not a symlink. /etc/X11/X is not executable. Diversions concerning libGL are in place diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/powerpc64le-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/powerpc64le-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLX_indirect.so.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLX_indirect.so.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.1.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.1.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0 by glx-diversi
Bug#1027142: Update: Probably not a GLX but an accelerator issue
In order to get the PC usable, I have tried to disable the part of the system causing the error. Disabling GLX made no difference (Option "GLX" "Disable"), but disabling the 2D hardware acceleration did it (Option "AccelMethod" "none"). So with the latter setting, the PC is usable until there is a solution to the hardware acceleration problem. BTW: A test with 2D acceleration and the ' Option "ShadowPrimary" "on" ' crashed the x-server, showing a backtrace on the console. Possibly caused by the same issue. smime.p7s Description: S/MIME Cryptographic Signature
[Git][xorg-team/xorg][debian-unstable] Rely on command -v to check for an executable
Timo Aaltonen pushed to branch debian-unstable at X Strike Force / xorg
Commits:
2e175516 by Jochen Sprickerhof at 2022-12-06T21:30:28+01:00
Rely on command -v to check for an executable
command -v could prefer shell builtins that don't have a full path (true
instead of bin/true). Resulting in a failing Xsession for example with:
/etc/X11/Xsession true
As command -v already checks if the command is executable, we can remove
the extra check.
Closes: #1012474
Regression of 3d6bd60
- - - - -
1 changed file:
- debian/local/Xsession.d/20x11-common_process-args
Changes:
=
debian/local/Xsession.d/20x11-common_process-args
=
@@ -33,14 +33,8 @@ case $# in
;;
*)
# Specific program was requested.
-STARTUP_FULL_PATH=$(command -v "${1%% *}" || true)
-if [ -n "$STARTUP_FULL_PATH" ] && [ -e "$STARTUP_FULL_PATH" ]; then
- if [ -x "$STARTUP_FULL_PATH" ]; then
-STARTUP="$1"
- else
-message "unable to launch \"$1\" X session ---" \
-"\"$1\" not executable; falling back to default session."
- fi
+if command -v "$1" >/dev/null; then
+ STARTUP="$1"
else
message "unable to launch \"$1\" X session ---" \
"\"$1\" not found; falling back to default session."
View it on GitLab:
https://salsa.debian.org/xorg-team/xorg/-/commit/2e1755166a88c8631d1ed88fac4f7f63b05f29dd
--
View it on GitLab:
https://salsa.debian.org/xorg-team/xorg/-/commit/2e1755166a88c8631d1ed88fac4f7f63b05f29dd
You're receiving this email because of your account on salsa.debian.org.
can/should x window managers depend on an X server?
Hello, I recently saw a user question regarding installing a window manager, and then not being able to run it. The user didn't have xorg installed: they probably finished d-i with no desktop tasks selected in tasksel. That crops up occasionally - I was curious if I could improve the situation for those users. I found two surprising things. First, I didn't find a solution to copy: according to a quick search [1], no x-window-manager package (directly) brings in an X server. Some will bring one in via another dependency (e.g. cinnamon -> cinnamon-core -> lightdm -> Recommends: xserver-xorg) Second, policy didn't really clarify. Sec 11.8.1 says: > Programs that can be configured with support for the X Window System > must be configured to do so and must declare any package dependencies > necessary to satisfy their runtime requirements when using the X > Window System. Historically, I can think of some reasons why this once would've clearly excluded an X server: 1. it might not've been clear which X server to install 2. X used to require elaborate config, with scary warnings 3. someone might've wanted a window manager to be displayed remotely The first two strike me as false now, and #3 is probably less common than minimall installs. So here's what I'm wondering: - can x-window-manager packages depend/recommend/suggest an X server? - should they? - if so: - what should the relationship be? - what should the target be? - should these vary depending on the WM? (ie, twm probably still works well-enough remotely. enlightenment not so much.) - should policy be updated? Thanks for your thoughts, Ross [1] - grepping the output of "aptitude search -F %p ~Px-window-manager | xargs apt show" for "xserver" and "xorg".
Bug#1004358: weston: Firefox is significantly slower on weston compared to X, on an i386, 32 bit machine.
Package: weston Version: 9.0.0-2 Severity: normal X-Debbugs-Cc: pe...@easthope.ca Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Used forefox 91.5.0esr on weston. * What exactly did you do (or not do) that was effective (or ineffective)? Installed weston and firefox using aptitude. Also set as suggested. peter@joule:/home/peter$ grep MOZ .bashrc export MOZ_ENABLE_WAYLAND=1 According to https://wiki.debian.org/Wayland#Firefox_.28supported.29 firefox runs natively on wayland. Ie. firefox doesn't require Xwayland. * What was the outcome of this action? Firefox is noticeably less responsive on weston, compared to X. Also note the messages near the bottom of the stderr output from weston, copied below. * What outcome did you expect instead? According to https://en.wikipedia.org/wiki/Wayland_(display_server_protocol) I expected firefox to be more responsive on weston, compared to X. *** End of the template - remove these template lines *** -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 5.10.0-11-686-pae (SMP w/1 CPU thread) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages weston depends on: ii adduser 3.118 ii libc62.31-13+deb11u2 ii libcairo21.16.0-5 ii libcolord2 1.4.5-3 ii libdrm2 2.4.104-1 ii libegl1 1.3.2-1 ii libegl1-mesa 20.3.5-1 ii libevdev21.11.0+dfsg-1 ii libgbm1 20.3.5-1 ii libgles2 1.3.2-1 ii libglib2.0-0 2.66.8-1 ii libinput10 1.16.4-3 ii libjpeg62-turbo 1:2.0.6-4 ii liblcms2-2 2.12~rc1-2 ii libpam0g 1.4.0-9+deb11u1 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libpixman-1-00.40.0-1 ii libpng16-16 1.6.37-3 ii libsystemd0 247.3-6 ii libwayland-client0 1.18.0-2~exp1.1 ii libwayland-cursor0 1.18.0-2~exp1.1 ii libwayland-egl1 1.18.0-2~exp1.1 ii libwayland-server0 1.18.0-2~exp1.1 ii libwebp6 0.6.1-2.1 ii libweston-9-09.0.0-2 ii libxkbcommon01.0.3-2 Versions of packages weston recommends: ii libgl1-mesa-dri 20.3.5-1 weston suggests no packages. - no debconf information *** StdErr output from weston here. *** Date: 2022-01-23 PST [14:32:17.922] weston 9.0.0 https://wayland.freedesktop.org Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/ Build: 9.0.0 [14:32:17.923] Command line: weston [14:32:17.923] OS: Linux, 5.10.0-11-686-pae, #1 SMP Debian 5.10.92-1 (2022-01-18), i686 [14:32:17.923] Using config file '/home/peter/.config/weston.ini' [14:32:17.923] Output repaint window is 7 ms maximum. [14:32:17.924] Loading module '/usr/lib/i386-linux-gnu/libweston-9/drm-backend.so' [14:32:17.930] initializing drm backend [14:32:17.940] logind: session control granted [14:32:17.961] using /dev/dri/card0 [14:32:17.961] DRM: does not support atomic modesetting [14:32:17.961] DRM: does not support GBM modifiers [14:32:17.961] DRM: supports picture aspect ratio [14:32:17.961] Loading module '/usr/lib/i386-linux-gnu/libweston-9/gl-renderer.so' [14:32:18.151] EGL client extensions: EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses EGL_EXT_client_extensions EGL_KHR_debug EGL_EXT_platform_device EGL_EXT_platform_wayland EGL_KHR_platform_wayland EGL_EXT_platform_x11 EGL_KHR_platform_x11 EGL_MESA_platform_gbm EGL_KHR_platform_gbm EGL_MESA_platform_surfaceless [14:32:18.155] EGL version: 1.4 [14:32:18.155] EGL vendor: Mesa Project [14:32:18.155] EGL client APIs: OpenGL OpenGL_ES [14:32:18.155] EGL extensions: EGL_ANDROID_blob_cache EGL_EXT_buffer_age EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_create_context EGL_KHR_create_context_no_error EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float EGL_KHR_wait_sync EGL_MESA_configless_context
Re: Bug#1002690: clutter-1.0: unit tests fail on mips64el: segmentation fault in an llvmpipe thread with swrast_dri.so driver
On Mon, 27 Dec 2021 at 14:36:01 +, Simon McVittie wrote: > I'm now trying to build 1.26.4+dfsg-2 on eller to see whether this is a > regression in some other package - I suspect it was, since clutter-1.0 > has had no code changes since 2020, but it would be good to be more sure > of this. Yes, I think this is a regression in some other component, probably Mesa or LLVM. 1.26.4+dfsg-2 passed unit tests on the buildds, but when rebuilt on eller with current versions, it fails the same 5 tests as 1.26.4+dfsg-3 (although the failure is ignored by the d/rules from 1.26.4+dfsg-2). smcv
Re: Bug#1002690: clutter-1.0: unit tests fail on mips64el: segmentation fault in an llvmpipe thread with swrast_dri.so driver
Control: user debian-m...@lists.debian.org Control: usertags -1 + mips64el On Mon, 27 Dec 2021 at 14:26:56 +, Simon McVittie wrote: > The clutter-1.0 unit tests fail on mips64el with segmentation faults in > actor-anchors, actor-layout, actor-offscreen-redirect, actor-pick and > texture. > > This (or at least a similar crash) is reproducible in a sid mips64el > chroot on eller, and can be reproduced in the built tree with a command > like: > > dbus-run-session -- xvfb-run -a ./libtool --mode=execute gdb > ./tests/conform/texture This might be related to https://bugs.debian.org/935884 and/or https://bugs.debian.org/868745, which are other mips-specific crashes involving llvmpipe. I'm now trying to build 1.26.4+dfsg-2 on eller to see whether this is a regression in some other package - I suspect it was, since clutter-1.0 has had no code changes since 2020, but it would be good to be more sure of this. smcv
Bug#1002690: clutter-1.0: unit tests fail on mips64el: segmentation fault in an llvmpipe thread with swrast_dri.so driver
Source: clutter-1.0 Version: 1.26.4+dfsg-3 Severity: important Tags: ftbfs X-Debbugs-Cc: debian-m...@lists.debian.org, m...@packages.debian.org The clutter-1.0 unit tests fail on mips64el with segmentation faults in actor-anchors, actor-layout, actor-offscreen-redirect, actor-pick and texture. This (or at least a similar crash) is reproducible in a sid mips64el chroot on eller, and can be reproduced in the built tree with a command like: dbus-run-session -- xvfb-run -a ./libtool --mode=execute gdb ./tests/conform/texture By installing libgl1-mesa-dri-dbgsym on eller, I was able to get the backtrace below. This might indicate that this is actually a Mesa bug, I don't know. Before version 1.26.4+dfsg-3, the result of clutter-1.0 unit tests was ignored on mips*el. For now I'm going to resume ignoring the failed result: I suspect that Mesa and Clutter have few or no users on mips*. Clutter is essentially unmaintained upstream (see #996690) so if it needs anything architecture-specific, that will have to come from architecture porters, and is vanishingly unlikely to come from upstream. smcv Thread 10 (Thread 0xffe17f9e50 (LWP 25902) "texture:disk$0"): #0 0x00fff6f813bc in __futex_abstimed_wait_common64 () at /lib/mips64el-linux-gnuabi64/libpthread.so.0 #1 0x00fff6f8 in pthread_cond_wait@@GLIBC_2.3.2 () at /lib/mips64el-linux-gnuabi64/libpthread.so.0 #2 0x00fff4c20e44 in cnd_wait (mtx=0xb30ba8, cond=0xb30bd0) at ../include/c11/threads_posix.h:155 #3 util_queue_thread_func (input=) at ../src/util/u_queue.c:294 #4 0x00fff4c206e0 in impl_thrd_routine (p=) at ../include/c11/threads_posix.h:87 #5 0x00fff6f6f24c in start_thread () at /lib/mips64el-linux-gnuabi64/libpthread.so.0 Thread 9 (Thread 0xffe1ffae50 (LWP 25901) "texture"): #0 0x00fff6f813bc in __futex_abstimed_wait_common64 () at /lib/mips64el-linux-gnuabi64/libpthread.so.0 #1 0x00fff6f8 in pthread_cond_wait@@GLIBC_2.3.2 () at /lib/mips64el-linux-gnuabi64/libpthread.so.0 #2 0x00fff537102c in cnd_wait (mtx=0xb30250, cond=0xb30278) at ../include/c11/threads_posix.h:155 #3 lp_cs_tpool_worker (data=0xb30250) at ../src/gallium/drivers/llvmpipe/lp_cs_tpool.c:48 #4 0x00fff5370f80 in impl_thrd_routine (p=) at ../include/c11/threads_posix.h:87 #5 0x00fff6f6f24c in start_thread () at /lib/mips64el-linux-gnuabi64/libpthread.so.0 Thread 8 (Thread 0xffe27fbe50 (LWP 25900) "texture"): #0 0x00fff6f813bc in __futex_abstimed_wait_common64 () at /lib/mips64el-linux-gnuabi64/libpthread.so.0 #1 0x00fff6f8 in pthread_cond_wait@@GLIBC_2.3.2 () at /lib/mips64el-linux-gnuabi64/libpthread.so.0 #2 0x00fff537102c in cnd_wait (mtx=0xb30250, cond=0xb30278) at ../include/c11/threads_posix.h:155 #3 lp_cs_tpool_worker (data=0xb30250) at ../src/gallium/drivers/llvmpipe/lp_cs_tpool.c:48 #4 0x00fff5370f80 in impl_thrd_routine (p=) at ../include/c11/threads_posix.h:87 #5 0x00fff6f6f24c in start_thread () at /lib/mips64el-linux-gnuabi64/libpthread.so.0 Thread 7 (Thread 0xffe2ffce50 (LWP 25899) "texture"): #0 0x00fff6f813bc in __futex_abstimed_wait_common64 () at /lib/mips64el-linux-gnuabi64/libpthread.so.0 #1 0x00fff6f8 in pthread_cond_wait@@GLIBC_2.3.2 () at /lib/mips64el-linux-gnuabi64/libpthread.so.0 #2 0x00fff537102c in cnd_wait (mtx=0xb30250, cond=0xb30278) at ../include/c11/threads_posix.h:155 #3 lp_cs_tpool_worker (data=0xb30250) at ../src/gallium/drivers/llvmpipe/lp_cs_tpool.c:48 #4 0x00fff5370f80 in impl_thrd_routine (p=) at ../include/c11/threads_posix.h:87 #5 0x00fff6f6f24c in start_thread () at /lib/mips64el-linux-gnuabi64/libpthread.so.0 Thread 6 (Thread 0xffe37fde50 (LWP 25898) "texture"): #0 0x00fff6f813bc in __futex_abstimed_wait_common64 () at /lib/mips64el-linux-gnuabi64/libpthread.so.0 #1 0x00fff6f8 in pthread_cond_wait@@GLIBC_2.3.2 () at /lib/mips64el-linux-gnuabi64/libpthread.so.0 #2 0x00fff537102c in cnd_wait (mtx=0xb30250, cond=0xb30278) at ../include/c11/threads_posix.h:155 #3 lp_cs_tpool_worker (data=0xb30250) at ../src/gallium/drivers/llvmpipe/lp_cs_tpool.c:48 #4 0x00fff5370f80 in impl_thrd_routine (p=) at ../include/c11/threads_posix.h:87 #5 0x00fff6f6f24c in start_thread () at /lib/mips64el-linux-gnuabi64/libpthread.so.0 Thread 5 (Thread 0xffe3ffee50 (LWP 25897) "llvmpipe-3"): #0 0x00fff6f79420 in pthread_barrier_wait () at /lib/mips64el-linux-gnuabi64/libpthread.so.0 #1 0x00fff5374944 in util_barrier_wait (barrier=0xb220a0) at ../src/util/u_thread.h:301 #2 thread_function (init_data=0xb20e38) at ../src/gallium/drivers/llvmpipe/lp_rast.c:887 #3 0x00fff5374350 in impl_thrd_routine (p=) at ../include/c11/threads_posix.h:87 #4 0x00fff6f6f24c in start_thread () at /lib/mips64el-linux-gnuabi64/libpthread.so.0 Thread 4 (Thread 0xffe8f5ae50 (LWP 25896) "llvmpipe-2"): #0 0x00fff6f79420
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)
# 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
[Git][xorg-team/vulkan/gfxreconstruct][master] 2 commits: Add an upstream patch to fix compiling with GCC 11
Dylan Aïssi pushed to branch master at X Strike Force / vulkan / gfxreconstruct
Commits:
b814bda2 by Dylan Aïssi at 2021-10-21T17:52:20+02:00
Add an upstream patch to fix compiling with GCC 11
- - - - -
f6d5de7f by Dylan Aïssi at 2021-10-21T17:58:15+02:00
Uplaod to unstable
Signed-off-by: Dylan Aïssi <dylan.ai...@collabora.com>
- - - - -
4 changed files:
- debian/changelog
- + debian/patches/02_Fix_build_with_GCC11.patch
- debian/patches/series
- debian/rules
Changes:
=
debian/changelog
=
@@ -1,3 +1,9 @@
+gfxreconstruct (0.9.9+dfsg-2) unstable; urgency=medium
+
+ * Add an upstream patch to fix compiling with GCC 11.
+
+ -- Dylan Aïssi Thu, 21 Oct 2021 17:57:53 +0200
+
gfxreconstruct (0.9.9+dfsg-1) unstable; urgency=medium
* Initial release (Closes: #989464)
=
debian/patches/02_Fix_build_with_GCC11.patch
=
@@ -0,0 +1,57 @@
+From 1e1853aea10c43232c64d8cd572ff1d4b98a7688 Mon Sep 17 00:00:00 2001
+From: Michael Skorokhodov
+Date: Wed, 11 Aug 2021 12:44:35 +0300
+Subject: [PATCH] Fix compiling with gcc11
+
+---
+ framework/encode/trace_manager.cpp| 8 +---
+ framework/encode/vulkan_handle_wrapper_util.h | 3 ++-
+ 2 files changed, 7 insertions(+), 4 deletions(-)
+
+diff --git a/framework/encode/trace_manager.cpp
b/framework/encode/trace_manager.cpp
+index 2542b96b..687084ca 100644
+--- a/framework/encode/trace_manager.cpp
b/framework/encode/trace_manager.cpp
+@@ -37,6 +37,8 @@
+ #include "util/page_guard_manager.h"
+ #include "util/platform.h"
+
++#include
++#include
+ #include
+ #include
+
+@@ -920,9 +922,9 @@ void
TraceManager::WriteSetDeviceMemoryPropertiesCommand(format::HandleId
+ // populate thread_data's scratch_buffer_ then write to file.
+ auto& scratch_buffer = thread_data->GetScratchBuffer();
+ scratch_buffer.clear();
+-scratch_buffer.insert(scratch_buffer.end(),
+-
reinterpret_cast(&memory_properties_cmd),
+-
reinterpret_cast(&memory_properties_cmd) +
sizeof(memory_properties_cmd));
++std::copy(reinterpret_cast(&memory_properties_cmd),
++ reinterpret_cast(&memory_properties_cmd) +
sizeof(memory_properties_cmd),
++ std::back_inserter(scratch_buffer));
+
+ format::DeviceMemoryType type;
+ for (uint32_t i = 0; i < memory_properties.memoryTypeCount; ++i)
+diff --git a/framework/encode/vulkan_handle_wrapper_util.h
b/framework/encode/vulkan_handle_wrapper_util.h
+index f94ca3f3..e3e04b35 100644
+--- a/framework/encode/vulkan_handle_wrapper_util.h
b/framework/encode/vulkan_handle_wrapper_util.h
+@@ -30,6 +30,7 @@
+ #include "util/defines.h"
+
+ #include
++#include
+ #include
+ #include
+
+@@ -77,7 +78,7 @@ class HandleUnwrapMemory
+ {
+ next_buffer = &buffers_[next_index];
+ next_buffer->clear();
+-next_buffer->insert(next_buffer->end(), data, data + len);
++std::copy(data, data + len, std::back_inserter(*next_buffer));
+ }
+ else
+ {
=
debian/patches/series
=
@@ -1 +1,2 @@
01_Use_system_Vulkan.patch
+02_Fix_build_with_GCC11.patch
=
debian/rules
=
@@ -2,10 +2,6 @@
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
-# Temporary workaround to build with GCC 11
-# https://github.com/LunarG/gfxreconstruct/issues/544
-export DEB_CXXFLAGS_MAINT_APPEND = "-Wno-error=stringop-overflow="
-
%:
dh $@
View it on GitLab:
https://salsa.debian.org/xorg-team/vulkan/gfxreconstruct/-/compare/786b3574b3ce0ea828662828d24ae98990431607...f6d5de7ff2890fda11ef2ae9cf8d7136195d22b2
--
View it on GitLab:
https://salsa.debian.org/xorg-team/vulkan/gfxreconstruct/-/compare/786b3574b3ce0ea828662828d24ae98990431607...f6d5de7ff2890fda11ef2ae9cf8d7136195d22b2
You're receiving this email because of your account on salsa.debian.org.
[Git][xorg-team/lib/libx11][debian-unstable] 2 commits: Add an upstream commit to handle new _EVDEVK symbols.
Timo Aaltonen pushed to branch debian-unstable at X Strike Force / lib / libx11
Commits:
764cd66f by Timo Aaltonen at 2021-09-15T09:18:19+03:00
Add an upstream commit to handle new _EVDEVK symbols.
- - - - -
33eebc77 by Timo Aaltonen at 2021-09-15T09:19:30+03:00
release to sid
- - - - -
3 changed files:
- debian/changelog
- + debian/patches/0001-makekeys-handle-the-new-_EVDEVK-xorgproto-symbols.patch
- debian/patches/series
Changes:
=
debian/changelog
=
@@ -1,3 +1,9 @@
+libx11 (2:1.7.2-2) unstable; urgency=medium
+
+ * Add an upstream commit to handle new _EVDEVK symbols.
+
+ -- Timo Aaltonen Wed, 15 Sep 2021 09:18:20 +0300
+
libx11 (2:1.7.2-1) unstable; urgency=medium
[ Timo Aaltonen ]
=
debian/patches/0001-makekeys-handle-the-new-_EVDEVK-xorgproto-symbols.patch
=
@@ -0,0 +1,43 @@
+From e92efc63acd7b377faa9e534f4bf52aaa86be2a9 Mon Sep 17 00:00:00 2001
+From: Peter Hutterer
+Date: Tue, 27 Jul 2021 11:46:19 +1000
+Subject: [PATCH] makekeys: handle the new _EVDEVK xorgproto symbols
+
+These keys are all defined through a macro in the form:
+ #define XF86XK_BrightnessAuto _EVDEVK(0x0F4)
+
+The _EVDEVK macro is simply an offset of 0x10081000.
+Let's parse these lines correctly so those keysyms end up in our
+hashtables.
+
+Signed-off-by: Peter Hutterer
+---
+ src/util/makekeys.c | 12
+ 1 file changed, 12 insertions(+)
+
+diff --git a/src/util/makekeys.c b/src/util/makekeys.c
+index e847ef4c..4896cc53 100644
+--- a/src/util/makekeys.c
b/src/util/makekeys.c
+@@ -78,6 +78,18 @@ parse_line(const char *buf, char *key, KeySym *val, char
*prefix)
+ return 1;
+ }
+
++/* See if we can parse one of the _EVDEVK symbols */
++i = sscanf(buf, "#define %127s _EVDEVK(0x%lx)", key, val);
++if (i == 2 && (tmp = strstr(key, "XK_"))) {
++memcpy(prefix, key, (size_t)(tmp - key));
++prefix[tmp - key] = '\0';
++tmp += 3;
++memmove(key, tmp, strlen(tmp) + 1);
++
++*val += 0x10081000;
++return 1;
++}
++
+ /* Now try to catch alias (XK_foo XK_bar) definitions, and resolve them
+ * immediately: if the target is in the form XF86XK_foo, we need to
+ * canonicalise this to XF86foo before we do the lookup. */
+--
+2.32.0
+
=
debian/patches/series
=
@@ -3,3 +3,4 @@
008_remove_ko_Compose.diff
009_remove_th_Compose.diff
015_russian_locale_alias.diff
+0001-makekeys-handle-the-new-_EVDEVK-xorgproto-symbols.patch
View it on GitLab:
https://salsa.debian.org/xorg-team/lib/libx11/-/compare/db34414f7755283730e1ed915993b353af49f003...33eebc7788a7a8140701e8b39689892f243f9470
--
View it on GitLab:
https://salsa.debian.org/xorg-team/lib/libx11/-/compare/db34414f7755283730e1ed915993b353af49f003...33eebc7788a7a8140701e8b39689892f243f9470
You're receiving this email because of your account on salsa.debian.org.
Bug#890357: Graphical issues with an RX 480
Can you confirm this issue is/is-not relevant any more on either of:- * Debian Bullseye (testing) * Debian Buster (stable) with the backported version of kernel (5.10.0-0.bpo.7) installed. Amdgpu has improved a long way since the time this bug report was created, and would be good to get the bug closed or issue forwarded upstream if still relevant. --simon
[Git][xorg-team/lib/libinput][debian-unstable] 93 commits: util-list.h: simplify code by removing an excess initialization
Timo Aaltonen pushed to branch debian-unstable at X Strike Force / lib / libinput Commits: 3f2c4834 by Konstantin Kharlamov at 2021-03-02T09:07:42+03:00 util-list.h: simplify code by removing an excess initialization The assignment of zero is done to work around false-positives of coverity about uninitialized variable usage. Getting rid of it inside the macro will allow in later commit to declare a variable inside `for-loop` rather than outside of it. Do it by declaring a new list_first_entry_by_type helper which accepts a type rather than a variable. Signed-off-by: Konstantin Kharlamov <hi-an...@yandex.ru> - - - - - 3d3d9b7f by Konstantin Kharlamov at 2021-03-02T09:10:35+03:00 treewide: get rid of `tmp` argument in list_for_each_safe Signed-off-by: Konstantin Kharlamov <hi-an...@yandex.ru> - - - - - 5e69c5f9 by Pedro Ribeiro at 2021-03-02T23:07:48+00:00 Add Lenovo Legion 5 keyboard to 50-system-lenovo.quirks Signed-off-by: Pedro Ribeiro <ped...@gmail.com> - - - - - c00c5cb6 by weizhixiang at 2021-03-08T20:59:20+00:00 replace strncmp with strneq for safety-check Signed-off-by: weizhixiang <weizhixi...@uniontech.com> - - - - - 40b83b11 by Peter Hutterer at 2021-03-10T09:54:07+10:00 completion: add missing libinput analyze subtools to the zsh completions Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - fe30bea3 by Peter Hutterer at 2021-03-10T00:24:51+00:00 tools/per-slot-delta: print the button state too while analyzing Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - f17ef2d5 by Peter Hutterer at 2021-03-10T00:24:51+00:00 tools/per-slot-delta: handle KeyboardInterrupts nicely Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - de706612 by Peter Hutterer at 2021-03-10T03:48:21+00:00 util: document our list interface Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - c71fa066 by Peter Hutterer at 2021-03-11T10:40:00+10:00 tools/debug-gui: start the unaccelerated motion deltas in the screen center Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - e99f5942 by Peter Hutterer at 2021-03-11T10:40:00+10:00 tools/debug-gui: move the pointer position into a struct point No functional change Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - 1926a66f by Peter Hutterer at 2021-03-11T10:40:00+10:00 tools/debug-gui: move the abs pointer position into a struct point No functional changes Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - 39b64107 by Peter Hutterer at 2021-03-11T10:40:00+10:00 tools/debug-gui: draw a sprite for the unaccelerated pointer as well Add a second grey v-shaped (upside down triangle) pointer that moves around with the unaccelerated deltas. This makes it easier to visualize how the unaccelerated pointer moves around, the snake helps for some use-cases but not all of them. Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - 31d20acd by Peter Hutterer at 2021-03-11T16:32:59+10:00 test: fix two inadvertent pointer jumps in a test Got papered over by bugs in the implementation and didn't trigger the jump detection or movement detection otherwise. Related to #578 Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - 832c346b by Peter Hutterer at 2021-03-11T16:32:59+10:00 test: add a comment to the thumb speed test Incorrect comment, the purpose of this test was to ensure that an unused slot doesn't affect how other touches are treated, see commit 928bad9. Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - 42d6fed8 by Peter Hutterer at 2021-03-11T16:33:00+10:00 touchpad: always push a touch's current point to the motion history The way touchpads (generally) work is that they get the position of each finger on each scanout. The kernel filters touches that haven't moved to reduce bandwidth so any touch that is logically down that we don't see an update for is in the same position as during the last scanout. Previously, touches that didn't sent events were effectively ignored, causing our jump detection to fail: - time t0: touch moves to position x/y, motion history time is set to t0 - time t1..t5: touch remains at position for several frames, no updates to the motion history - time t6: touch jumps to position x+a/y+b - tp_detect_jumps() sees the last update time is t0 which is too long ago and exits without detecting a jump This is fixed by pushing to the motion history any time we have *any* update - if the touchpad notices a state change on any touch update all touches with their current position, whether it changed or not. This obsoletes the `time` field in the tp_touch struct, most of this patch is passing down the current time to the few users of t->time. Fixes #578 Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - 3427b457 by Peter Hu
[Git][xorg-team/lib/libinput][upstream-unstable] 89 commits: util-list.h: simplify code by removing an excess initialization
Timo Aaltonen pushed to branch upstream-unstable at X Strike Force / lib / libinput Commits: 3f2c4834 by Konstantin Kharlamov at 2021-03-02T09:07:42+03:00 util-list.h: simplify code by removing an excess initialization The assignment of zero is done to work around false-positives of coverity about uninitialized variable usage. Getting rid of it inside the macro will allow in later commit to declare a variable inside `for-loop` rather than outside of it. Do it by declaring a new list_first_entry_by_type helper which accepts a type rather than a variable. Signed-off-by: Konstantin Kharlamov <hi-an...@yandex.ru> - - - - - 3d3d9b7f by Konstantin Kharlamov at 2021-03-02T09:10:35+03:00 treewide: get rid of `tmp` argument in list_for_each_safe Signed-off-by: Konstantin Kharlamov <hi-an...@yandex.ru> - - - - - 5e69c5f9 by Pedro Ribeiro at 2021-03-02T23:07:48+00:00 Add Lenovo Legion 5 keyboard to 50-system-lenovo.quirks Signed-off-by: Pedro Ribeiro <ped...@gmail.com> - - - - - c00c5cb6 by weizhixiang at 2021-03-08T20:59:20+00:00 replace strncmp with strneq for safety-check Signed-off-by: weizhixiang <weizhixi...@uniontech.com> - - - - - 40b83b11 by Peter Hutterer at 2021-03-10T09:54:07+10:00 completion: add missing libinput analyze subtools to the zsh completions Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - fe30bea3 by Peter Hutterer at 2021-03-10T00:24:51+00:00 tools/per-slot-delta: print the button state too while analyzing Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - f17ef2d5 by Peter Hutterer at 2021-03-10T00:24:51+00:00 tools/per-slot-delta: handle KeyboardInterrupts nicely Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - de706612 by Peter Hutterer at 2021-03-10T03:48:21+00:00 util: document our list interface Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - c71fa066 by Peter Hutterer at 2021-03-11T10:40:00+10:00 tools/debug-gui: start the unaccelerated motion deltas in the screen center Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - e99f5942 by Peter Hutterer at 2021-03-11T10:40:00+10:00 tools/debug-gui: move the pointer position into a struct point No functional change Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - 1926a66f by Peter Hutterer at 2021-03-11T10:40:00+10:00 tools/debug-gui: move the abs pointer position into a struct point No functional changes Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - 39b64107 by Peter Hutterer at 2021-03-11T10:40:00+10:00 tools/debug-gui: draw a sprite for the unaccelerated pointer as well Add a second grey v-shaped (upside down triangle) pointer that moves around with the unaccelerated deltas. This makes it easier to visualize how the unaccelerated pointer moves around, the snake helps for some use-cases but not all of them. Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - 31d20acd by Peter Hutterer at 2021-03-11T16:32:59+10:00 test: fix two inadvertent pointer jumps in a test Got papered over by bugs in the implementation and didn't trigger the jump detection or movement detection otherwise. Related to #578 Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - 832c346b by Peter Hutterer at 2021-03-11T16:32:59+10:00 test: add a comment to the thumb speed test Incorrect comment, the purpose of this test was to ensure that an unused slot doesn't affect how other touches are treated, see commit 928bad9. Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - 42d6fed8 by Peter Hutterer at 2021-03-11T16:33:00+10:00 touchpad: always push a touch's current point to the motion history The way touchpads (generally) work is that they get the position of each finger on each scanout. The kernel filters touches that haven't moved to reduce bandwidth so any touch that is logically down that we don't see an update for is in the same position as during the last scanout. Previously, touches that didn't sent events were effectively ignored, causing our jump detection to fail: - time t0: touch moves to position x/y, motion history time is set to t0 - time t1..t5: touch remains at position for several frames, no updates to the motion history - time t6: touch jumps to position x+a/y+b - tp_detect_jumps() sees the last update time is t0 which is too long ago and exits without detecting a jump This is fixed by pushing to the motion history any time we have *any* update - if the touchpad notices a state change on any touch update all touches with their current position, whether it changed or not. This obsoletes the `time` field in the tp_touch struct, most of this patch is passing down the current time to the few users of t->time. Fixes #578 Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> - - - - - 3427b457 by Peter Hu
[Git][xorg-team/lib/libx11][upstream-unstable] 15 commits: nls: add 'C.utf8' as an alias for 'en_US.UTF-8'
Emilio Pozuelo Monfort pushed to branch upstream-unstable at X Strike Force / lib / libx11 Commits: cc9f8878 by Benno Schulenberg at 2020-11-25T17:06:38+01:00 nls: add 'C.utf8' as an alias for 'en_US.UTF-8' The normal form is 'C.UTF-8', but 'C.utf8' has been seen in the wild. Fixes #102. Reported-by: Tomas Korbar Signed-off-by: Benno Schulenberg <bensb...@telfort.nl> - - - - - cb03da44 by Walter Harms at 2020-11-27T19:00:00+01:00 FIX: warning: macro `Pn' not defined The missing macro is found via: roff -t -mandoc -Z -wmac -Tutf8 XAnyEvent.man >/dev/null To fix the problem the macro is replaced with .RB. Signed-off-by: Walter Harms <wha...@bfs.de> - - - - - 14fb4e53 by Walter Harms at 2020-11-27T20:04:22+01:00 FIX: warning: macro `hN' not defined this was found by checking man pages with groff -t -mandoc -Z -wmac -Tutf8 $FILE >/dev/null In most cases .hN could be replaced with .BR Signed-off-by: Walter Harms <wha...@bfs.de> - - - - - 7ca3ceb9 by Walter Harms at 2020-11-27T21:58:04+01:00 fix warning: macro `s' not defined this is caused by bad nroff coding, fix some more issues on the fly - - - - - b7ec67d3 by Walter Harms at 2020-11-27T22:26:15+01:00 FIX: warning: macro `IN' not defined just remove an other dead macro use. - - - - - 7bdeae23 by Walter Harms at 2020-11-27T22:43:21+01:00 FIX: warning: macro `hN' not defined Signed-off-by: Walter Harms <wha...@bfs.de> - - - - - daa10692 by Walter Harms at 2020-11-28T17:49:25+01:00 fix broken nroff coding for code comments the comments /* */ are code as /\(** */ that does not work. the coding in other X11 man pages is /\&* */ so we do the same here. - - - - - 4f15cfc6 by Walter Harms at 2020-11-28T20:56:35+01:00 Fix some roff code add see also Signed-off-by: Walter Harms <wha...@bfs.de> - - - - - 78027fdb by Walter Harms at 2020-11-28T21:05:33+01:00 fix same roff code Signed-off-by: Walter Harms <wha...@bfs.de> - - - - - b126bfd7 by Benno Schulenberg at 2021-01-12T00:32:09+00:00 nls: allow composing all breved letters also with a lowercase "u" The letters ă and ŭ can already be composed with "u a" and "u u", but ĕ, ğ, ĭ, and ŏ can be composed only with an uppercase U. Emancipate the latter four and understand also a lowercase "u" to mean 'breve'. (Yesterday I needed ğ and was annoyed that "u g" did not work.) Signed-off-by: Benno Schulenberg <bensb...@telfort.nl> - - - - - 5faa8dc0 by Benno Schulenberg at 2021-01-12T00:32:09+00:00 nls: adjust three comments about the APL compose sequences Commit 0bbc0d5e605e (from eight years ago) removed the lines that two of these comments referred to. Without those lines, the comments don't make sense any more. Reword and shorten them. Also reword a comment about two sequences that don't work. Signed-off-by: Benno Schulenberg <bensb...@telfort.nl> - - - - - 32491b02 by Christopher Chavez at 2021-05-03T19:08:03+00:00 Xlib.h: spelling fix in comment - - - - - 838ea5a5 by Gaurav Ujjwal at 2021-05-09T11:30:09+05:30 Fix out-of-bound access in KeySymToUcs4() Array `keysym_to_unicode_590_5fe` is only valid for range [0x590, 0x5fe] but current lower-bound is checked against 0x589. So invalid values from 0x58a to 0x58f are being allowed by current check. If any of these invalid value is passed as `keysym`,`keysym - 0x590` would underflow. Signed-off-by: Gaurav Ujjwal <gujjwa...@gmail.com> - - - - - 8d2e02ae by Matthieu Herrb at 2021-05-18T13:57:49+02:00 Reject string longer than USHRT_MAX before sending them on the wire The X protocol uses CARD16 values to represent the length so this would overflow. CVE-2021-31535 Signed-off-by: Matthieu Herrb <matth...@herrb.eu> - - - - - 6953a586 by Matthieu Herrb at 2021-05-18T15:27:58+02:00 Version 1.7.1 Release notes in README.md, version bump in configure.ac - - - - - 30 changed files: - README.md - configure.ac - include/X11/Xlib.h - man/XAllocClassHint.man - man/XAllocColor.man - man/XAllocIconSize.man - man/XAllocSizeHints.man - man/XAllocStandardColormap.man - man/XAllocWMHints.man - man/XAnyEvent.man - man/XChangeKeyboardControl.man - man/XConfigureWindow.man - man/XCreateColormap.man - man/XCreateGC.man - man/XCreateWindow.man - man/XErrorEvent.man - man/XFlush.man - man/XGetVisualInfo.man - man/XGrabKeyboard.man - man/XGrabPointer.man - man/XGraphicsExposeEvent.man - man/XInitImage.man - man/XLoadFont.man - man/XMapWindow.man - man/XOpenDisplay.man - man/XParseGeometry.man - man/XRecolorCursor.man - man/XSelectInput.man - man/XSetInputFocus.man - man/XSetScreenSaver.man The diff was not included because it is too large. View it on GitLab: https://salsa.debian.org/xorg-team/lib/libx11/-/compare/ca8115186f810eccb7d86b0979980eff3ba95f0b...6953a586df4819143c4d55e011b3a5e5377981b8 -- View it on GitLab: https://salsa.debian.org/xorg-team/lib/libx11/-/compare/ca8115186f810eccb7d86b0979980eff3ba95f0b...6953a586df4819143c4d55e011b3a5e5377981b8 You're receiving this email because of your account on salsa.debian.org.
[Git][xorg-team/lib/libx11][debian-unstable] 18 commits: nls: add 'C.utf8' as an alias for 'en_US.UTF-8'
Emilio Pozuelo Monfort pushed to branch debian-unstable at X Strike Force / lib / libx11 Commits: cc9f8878 by Benno Schulenberg at 2020-11-25T17:06:38+01:00 nls: add 'C.utf8' as an alias for 'en_US.UTF-8' The normal form is 'C.UTF-8', but 'C.utf8' has been seen in the wild. Fixes #102. Reported-by: Tomas Korbar Signed-off-by: Benno Schulenberg <bensb...@telfort.nl> - - - - - cb03da44 by Walter Harms at 2020-11-27T19:00:00+01:00 FIX: warning: macro `Pn' not defined The missing macro is found via: roff -t -mandoc -Z -wmac -Tutf8 XAnyEvent.man >/dev/null To fix the problem the macro is replaced with .RB. Signed-off-by: Walter Harms <wha...@bfs.de> - - - - - 14fb4e53 by Walter Harms at 2020-11-27T20:04:22+01:00 FIX: warning: macro `hN' not defined this was found by checking man pages with groff -t -mandoc -Z -wmac -Tutf8 $FILE >/dev/null In most cases .hN could be replaced with .BR Signed-off-by: Walter Harms <wha...@bfs.de> - - - - - 7ca3ceb9 by Walter Harms at 2020-11-27T21:58:04+01:00 fix warning: macro `s' not defined this is caused by bad nroff coding, fix some more issues on the fly - - - - - b7ec67d3 by Walter Harms at 2020-11-27T22:26:15+01:00 FIX: warning: macro `IN' not defined just remove an other dead macro use. - - - - - 7bdeae23 by Walter Harms at 2020-11-27T22:43:21+01:00 FIX: warning: macro `hN' not defined Signed-off-by: Walter Harms <wha...@bfs.de> - - - - - daa10692 by Walter Harms at 2020-11-28T17:49:25+01:00 fix broken nroff coding for code comments the comments /* */ are code as /\(** */ that does not work. the coding in other X11 man pages is /\&* */ so we do the same here. - - - - - 4f15cfc6 by Walter Harms at 2020-11-28T20:56:35+01:00 Fix some roff code add see also Signed-off-by: Walter Harms <wha...@bfs.de> - - - - - 78027fdb by Walter Harms at 2020-11-28T21:05:33+01:00 fix same roff code Signed-off-by: Walter Harms <wha...@bfs.de> - - - - - b126bfd7 by Benno Schulenberg at 2021-01-12T00:32:09+00:00 nls: allow composing all breved letters also with a lowercase "u" The letters ă and ŭ can already be composed with "u a" and "u u", but ĕ, ğ, ĭ, and ŏ can be composed only with an uppercase U. Emancipate the latter four and understand also a lowercase "u" to mean 'breve'. (Yesterday I needed ğ and was annoyed that "u g" did not work.) Signed-off-by: Benno Schulenberg <bensb...@telfort.nl> - - - - - 5faa8dc0 by Benno Schulenberg at 2021-01-12T00:32:09+00:00 nls: adjust three comments about the APL compose sequences Commit 0bbc0d5e605e (from eight years ago) removed the lines that two of these comments referred to. Without those lines, the comments don't make sense any more. Reword and shorten them. Also reword a comment about two sequences that don't work. Signed-off-by: Benno Schulenberg <bensb...@telfort.nl> - - - - - 32491b02 by Christopher Chavez at 2021-05-03T19:08:03+00:00 Xlib.h: spelling fix in comment - - - - - 838ea5a5 by Gaurav Ujjwal at 2021-05-09T11:30:09+05:30 Fix out-of-bound access in KeySymToUcs4() Array `keysym_to_unicode_590_5fe` is only valid for range [0x590, 0x5fe] but current lower-bound is checked against 0x589. So invalid values from 0x58a to 0x58f are being allowed by current check. If any of these invalid value is passed as `keysym`,`keysym - 0x590` would underflow. Signed-off-by: Gaurav Ujjwal <gujjwa...@gmail.com> - - - - - 8d2e02ae by Matthieu Herrb at 2021-05-18T13:57:49+02:00 Reject string longer than USHRT_MAX before sending them on the wire The X protocol uses CARD16 values to represent the length so this would overflow. CVE-2021-31535 Signed-off-by: Matthieu Herrb <matth...@herrb.eu> - - - - - 6953a586 by Matthieu Herrb at 2021-05-18T15:27:58+02:00 Version 1.7.1 Release notes in README.md, version bump in configure.ac - - - - - 2d20b967 by Emilio Pozuelo Monfort at 2021-05-19T16:57:46+02:00 Merge branch 'upstream-unstable' into debian-unstable - - - - - b018eeb2 by Emilio Pozuelo Monfort at 2021-05-19T17:22:01+02:00 New upstream release - - - - - 081b50e0 by Emilio Pozuelo Monfort at 2021-05-19T17:22:16+02:00 Release to sid - - - - - 30 changed files: - README.md - configure.ac - debian/changelog - include/X11/Xlib.h - man/XAllocClassHint.man - man/XAllocColor.man - man/XAllocIconSize.man - man/XAllocSizeHints.man - man/XAllocStandardColormap.man - man/XAllocWMHints.man - man/XAnyEvent.man - man/XChangeKeyboardControl.man - man/XConfigureWindow.man - man/XCreateColormap.man - man/XCreateGC.man - man/XCreateWindow.man - man/XErrorEvent.man - man/XFlush.man - man/XGetVisualInfo.man - man/XGrabKeyboard.man - man/XGrabPointer.man - man/XGraphicsExposeEvent.man - man/XInitImage.man - man/XLoadFont.man - man/XMapWindow.man - man/XOpenDisplay.man - man/XParseG
For 12 years, nouveau hasn't been able to correct a shortfall stated to be minor by an FSF report
Namaste, Dear Team Nouveau Developers, First of all, I thank you for continuing to provide us with Free and Open Source Software that empowers us from the Proprietary universe. As mentioned in my earlier posts as well as the present one being faced after my having installed from debian-live-10.8.0-amd64-lxde.iso fhere: http://forums.debian.net/viewtopic.php?f=17&t=149248, it is now impossible to find an nvidia driver compatible with the Debian OS installed on a new HDD for my laptop as mentioned therein. The FSF report is here: https://h-node.org/videocards/view/en/821/NVIDIA-Corporation-C79--GeForce-9200M-G---rev-b1- None of the options that I have tried so far has worked. No suggestion/advice received from anywhere: https://ubuntuforums.org/showthread.php?t=2460287 https://bbs.archlinux.org/viewtopic.php?id=265402 https://forum.puppylinux.com/viewtopic.php?f=2&t=2664 other than the Debian Forums, link posted above. Please. I need to either have a nouveau for my system work, or have the proprietary NVIDIA driver allowed and installed. The Debian Ecosystem erected, along with hardware, doesn't simply work in my country of residence. Whatever outputs required from lspci, demesg et al could be sent. Please help. Regards, Rajib Bandopadhyay A dedicated Debian and Knoppix user, and sometimes, Ubuntu
Bug#694832: marked as done (Bug in starting an xsession with arguments)
Your message dated Sun, 27 Oct 2019 09:20:34 + with message-id and subject line Bug#694832: fixed in xorg 1:7.7+20 has caused the Debian Bug report #694832, regarding Bug in starting an xsession with arguments to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 694832: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694832 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: x11-common Version: 1:7.7+1 When specifying arguments to an xsession under GDM3 (3.4.x), in '/usr/share/xsessions/*.desktop' such as "gnome-session --debug" the session fails to load with the following error: Xsession: unable to launch "" > Xsession --- "" not found; falling back to default > It's actually the double quotes the argument is parsed with that makes it to fail in: '/etc/X11/Xsession.d/20x11-common_process-args' Line: STARTUP_FULL_PATH=$(/usr/bin/which "$1"|| true) Line: STARTUP="$1" Removing those double quotations from the argument name in the two lines solves the problem to me and the sessions loads fine afterward Please consider including this fix in x11-common package I'm confirming finding this bug in Debian Testing (Wheezy), kernel 3.2.28-0 and x11-common 1:7.7+1 --- End Message --- --- Begin Message --- Source: xorg Source-Version: 1:7.7+20 We believe that the bug you reported is fixed in the latest version of xorg, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 694...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Timo Aaltonen (supplier of updated xorg package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 27 Oct 2019 11:03:47 +0200 Source: xorg Architecture: source Version: 1:7.7+20 Distribution: unstable Urgency: medium Maintainer: Debian X Strike Force Changed-By: Timo Aaltonen Closes: 694832 906537 Changes: xorg (1:7.7+20) unstable; urgency=medium . [ Julien Cristau ] * Update docs for alioth→salsa move. . [ Sven Joachim ] * Let xorg-dev depend on x11proto-dev rather than on the transional x11-proto-*-dev packages (Closes: #906537). . [ Timo Aaltonen ] * x11-common.dirs: Add etc/X11/xorg.conf.d for config snippets. . [ Iain Lane ] * 20x11-common_process-args: Find the first word of our startup program for $STARTUP. It's valid for this to be a full invocation, with arguments, but for our purposes we only care what the executable was. (Closes: #694832) Checksums-Sha1: 6762a27a55a570fa96bdbc071e3ac73fc591d456 1969 xorg_7.7+20.dsc 6e5f4972e98e6f5c7ddeaabf05c250ab55104553 286646 xorg_7.7+20.tar.gz 31b6772205d5cfc8113b366535748149dfc52853 6928 xorg_7.7+20_source.buildinfo Checksums-Sha256: e24781dcf02522f070811acdeaba7113b560c61148a692c6b74719aacd85bd0b 1969 xorg_7.7+20.dsc 2da7138a6f437ce7ccf63e36786b17053ffbdbcf177dab4874260bfa54595b5c 286646 xorg_7.7+20.tar.gz f8b8cc9d3d25439eec8c306ecf49370d7fd0bdd1bc07633d012eab6504d0103b 6928 xorg_7.7+20_source.buildinfo Files: 695ad33407800416c5a02ae39dfa2e25 1969 x11 optional xorg_7.7+20.dsc 1523ffd3775205da3ce915013e1ca27e 286646 x11 optional xorg_7.7+20.tar.gz cb9d75a489ec17156b06c1703243b75d 6928 x11 optional xorg_7.7+20_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdS3ifE3rFwGbS2Yjy3AxZaiJhNwFAl21XY0ACgkQy3AxZaiJ hNxnCg/9GdkmRffGZqJCqQgrRCEFmLGrjRypdJIstRFQzHvf+3oDFWy2sZMLb3/I 0SkiNxnJrEIYMzAFFqDupfmrTPbagUpIldSwFtCpobiW4ytnj4XSXFW6OW3csYdI L2EqG0+30QibhhQAnJzqXTq7T8a8UYDSEr8RtEc6AU8wlBUUIuFW/9h5JBYgpBgy B3PTMHn6Mmr0/s8Z2W1s4E8z7fO/yWDH+PUeqUpEhpE7ITuO9K7iKFICUDCXkOBN +E+mzyZ2zYyR3n7/io3JLy7QwqnAokYEqOh4IBMtul6d5Dp37ZCPR43SWU2wVNY4 Q50VvynBI1rjvhXPl0aXcee+VNXO5sH8s3CCFFX+lMvAJHmECGFQ53NnzTbOC4+x 9Fa9NjoSaoJ2S+TDpJEg9O+NqEyaPDPh2cAmvTxTtbxjeDGHysdQl3KuAtOJXO7E 3Q2p4fGtzhC1QudFH+9ZCcWDDZk7gBUX0X5dGFkjXNeSBblwn/SRbL9WF/08dA+C Di6PnjdA03uVIwmshCmRxxwMhC8A7oR0pKWjty1pYPxGCXgYwCtDTfRkuxvvAeqQ iyh2Fs5uI6ykwhlldIHQsrR3S2fc+2sQE1FfbeNPPcoyY2VCAxDbQ5laJGH09KfT OdpIjmNE+S9i7agX8l1P2rY4utql2CmPXiIwNdd0hvAxLaDvQgU= =w1J6 -END PGP SIGNATURE End Message ---
Bug#922346: marked as done (eog: Opened an image and my display server crashed)
Your message dated Sat, 06 Apr 2019 19:19:23 + with message-id and subject line Bug#922346: fixed in mesa 18.3.6-1 has caused the Debian Bug report #922346, regarding eog: Opened an image and my display server crashed to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 922346: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922346 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: eog Version: 3.28.4-2+b1 Severity: critical Justification: breaks the whole system I opened a png file in eog and my display server crashed. Here is the relevant part of my syslog: Feb 14 20:44:45 debian org.gnome.Shell.desktop[1414]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x187 (Visionneur) Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: Xwayland: src/intel/genxml/gen7_pack.h:72: __gen_uint: Assertion `v <= max' failed. Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) Backtrace: Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 0: /usr/bin/Xwayland (OsLookupColor+0x139) [0x55b8e2f27e09] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) [0x7fba70a3372f] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0x10b) [0x7fba708978bb] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (abort+0x121) [0x7fba70882535] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) unw_get_proc_name failed: no unwind info found [-10] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7fba70882400] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (__assert_fail+0x42) [0x7fba708900f2] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 6: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_nouveau_vieux+0x416573) [0x7fba6fb6c503] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 7: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_nouveau_vieux+0x416dd5) [0x7fba6fb6cd95] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 8: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_i915+0x136b7b) [0x7fba6f402d8b] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 9: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_i915+0x1370e7) [0x7fba6f403ab7] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 10: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_i915+0x12f041) [0x7fba6f3f3711] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 11: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_i915+0x11a2dc) [0x7fba6f3c952c] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 12: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_nouveau_vieux+0x1ccc7a) [0x7fba6f6d929a] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 13: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (__driDriverGetExtensions_nouveau_vieux+0x1ccfea) [0x7fba6f6d999a] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 14: /usr/bin/Xwayland (glamor_create_gc+0xd535) [0x55b8e2df1a05] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 15: /usr/bin/Xwayland (DamageRegionAppend+0x19f8) [0x55b8e2e98eb8] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 16: /usr/bin/Xwayland (glamor_pixmap_exchange_fbos+0x7b7) [0x55b8e2deef57] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 17: /usr/bin/Xwayland (glamor_pixmap_exchange_fbos+0x67e) [0x55b8e2dee9be] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 18: /usr/bin/Xwayland (AddTraps+0x3551) [0x55b8e2e8aad1] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 19: /usr/bin/Xwayland (SendErrorToClient+0x35e) [0x55b8e2ef1e6e] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 20: /usr/bin/Xwayland (InitFonts+0x3b6) [0x55b8e2ef5df6] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 21: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xeb) [0x7fba7088409b] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 22: /usr/bin/Xwayland (_start+0x2a) [0x55b8e2dc71ea] Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: Fatal server error: Feb 14 20:44:4
Bug#799325: marked as done (weston: won't start despite having an active logind session)
Your message dated Thu, 28 Mar 2019 13:34:46 + with message-id and subject line Bug#799325: fixed in weston 5.0.0-3 has caused the Debian Bug report #799325, regarding weston: won't start despite having an active logind session to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 799325: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799325 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: weston Version: 1.8.0-3 Severity: important Dear Maintainer, According to README.Debian, having an active logind session should be sufficient to start weston without being in the weston-launch group. This does not work. $ loginctl list-sessions SESSIONUID USER SEAT 198 1000 ben seat0 8 1000 ben seat0 262 1000 ben seat0 197128 sddm seat0 4 sessions listed. $ loginctl show-session 262 Id=262 Name=ben Timestamp=Thu 2015-09-17 14:33:40 PDT TimestampMonotonic=111440115978 VTNr=2 TTY=/dev/tty2 Remote=no Service=login Scope=session-262.scope Leader=25537 Audit=262 Type=tty Class=user Active=yes State=active IdleHint=no IdleSinceHint=1442525896738975 IdleSinceHintMonotonic=111715924138 $ weston-launch weston-launch: Permission denied. You should either: - enable systemd session support for weston-launch. - or add yourself to the 'weston-launch' group. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages weston depends on: ii adduser 3.113+nmu3 ii libc6 2.19-19 ii libcairo2 1.14.2-2 ii libcolord2 1.2.11-1 ii libdrm2 2.4.64-1 ii libegl1-mesa [libegl1-x11] 10.6.3-1 ii libgbm1 10.6.3-1 ii libgles2-mesa [libgles2]10.6.3-1 ii libglib2.0-02.44.1-1.1 ii libinput10 1.0.1-1 ii libjpeg62-turbo 1:1.4.1-2 ii liblcms2-2 2.6-3+b3 ii libmtdev1 1.1.5-1 ii libpam0g1.1.8-3.1 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpixman-1-0 0.32.6-3 ii libpng12-0 1.2.50-2+b2 ii libudev1225-1 ii libwayland-client0 1.8.1-1 ii libwayland-cursor0 1.8.1-1 ii libwayland-egl1-mesa [libwayland-egl1] 10.6.3-1 ii libwayland-server0 1.8.1-1 ii libx11-62:1.6.3-1 ii libx11-xcb1 2:1.6.3-1 ii libxcb-composite0 1.10-3+b1 ii libxcb-render0 1.10-3+b1 ii libxcb-shape0 1.10-3+b1 ii libxcb-shm0 1.10-3+b1 ii libxcb-xfixes0 1.10-3+b1 ii libxcb-xkb1 1.10-3+b1 ii libxcb1 1.10-3+b1 ii libxcursor1 1:1.1.14-1+b1 ii libxkbcommon0 0.5.0-1 Versions of packages weston recommends: ii libgl1-mesa-dri 10.6.3-1 weston suggests no packages. -- no debconf information --- End Message --- --- Begin Message --- Source: weston Source-Version: 5.0.0-3 We believe that the bug you reported is fixed in the latest version of weston, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 799...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Héctor Orón Martínez (supplier of updated weston package) (This message was generated automatically at their request; if you believe that there is
Bug#922346: eog: Opened an image and my display server crashed
Hello, I found a similar bug on Ubuntu's Launchpad: https://bugs.launchpad.net/ubuntu/+source/totem/+bug/1815236 The patch for that issue was added in Mesa 18.3.5 released on March 18, 2019. Michel Le Bihan
Bug#799325: weston: won't start despite having an active logind session
Control: found -1 5.0.0 Control: forwarded -1 https://gitlab.freedesktop.org/wayland/weston/issues/204 Dear Hector, dear Ben, On 06/02/16 13:30, Hector Oron wrote: > On Thu, Sep 17, 2015 at 02:42:59PM -0700, Ben Longbons wrote: > >> $ weston-launch >> weston-launch: Permission denied. You should either: >> - enable systemd session support for weston-launch. >> - or add yourself to the 'weston-launch' group. > > Thanks for the report, I have been testing with 1.11.0 version and > the issue is gone on my system. Could you please re-test and update > the bug report? As the bug report title talks about Weston and not `weston-launch`, I am following up, saying that `weston --modules systemd-notify.so` does not work on a current Debian Sid/unstable system run from a tty. [10:24:41.689] fatal: drm backend should be run using weston-launch binary, or your system should provide the logind D-Bus API. [10:24:41.689] fatal: failed to create compositor backend It looks like `libdbus-1-dev` [1] is missing as a build dependency, so that support for systemd-login is *not* detected. After installing the development package, the configure output contains the line below. systemd-login support yes Can you please check the package build logs? Building with `CFLAGS=-O0 -g` I then verified, that `launcher_logind_iface` is a member of the the array `ifaces`. Kind regards, Paul [1]: https://salsa.debian.org/xorg-team/wayland/weston/blob/debian-unstable/debian/control [2]: https://packages.debian.org/search?keywords=libdbus-1-dev smime.p7s Description: S/MIME Cryptographic Signature
Processed: Re: Bug#799325: weston: won't start despite having an active logind session
Processing control commands: > found -1 5.0.0 Bug #799325 [weston] weston: won't start despite having an active logind session There is no source info for the package 'weston' at version '5.0.0' with architecture '' Unable to make a source version for version '5.0.0' Marked as found in versions 5.0.0. > forwarded -1 https://gitlab.freedesktop.org/wayland/weston/issues/204 Bug #799325 [weston] weston: won't start despite having an active logind session Set Bug forwarded-to-address to 'https://gitlab.freedesktop.org/wayland/weston/issues/204'. -- 799325: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799325 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#923334: I suspect it's not an xorg problem
I went into IceWm after reporting this this morning and xorg is acting normally under that windown manager. I now suspect it's a Mate problem. Sorry for the noise.
Bug#922346: eog: Opened an image and my display server crashed
Le jeudi 14 février 2019 à 20:31 +, Simon McVittie a écrit : > Control: reassign -1 libgl1-mesa-dri > Control: tags -1 + moreinfo > > On Thu, 14 Feb 2019 at 21:18:42 +0100, Michel Le Bihan wrote: > > I opened a png file in eog and my display server crashed. > > eog shouldn't be able to cause this, even if it wanted to, so this is > a bug in the display server or some library it uses. > > From the backtrace you provided, I think this is most likely to be an > assertion failure in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so, so > I'm > reassigning this. > > The Mesa maintainers will want to know more details of your system. > The output of `reportbug --template libgl1-mesa-dri` would presumably > be useful information. > > Was the file that you opened in eog particularly large, or otherwise > unusual? No. It was only 1,5MB. It didn't appear to be unusual in any way, but I don't know if it was a fully valid PNG file. Michel Le Bihan
Processed: Re: Bug#922346: eog: Opened an image and my display server crashed
Processing control commands: > reassign -1 libgl1-mesa-dri Bug #922346 [eog] eog: Opened an image and my display server crashed Bug reassigned from package 'eog' to 'libgl1-mesa-dri'. No longer marked as found in versions eog/3.28.4-2. Ignoring request to alter fixed versions of bug #922346 to the same values previously set > tags -1 + moreinfo Bug #922346 [libgl1-mesa-dri] eog: Opened an image and my display server crashed Added tag(s) moreinfo. -- 922346: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922346 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Bug#922346: eog: Opened an image and my display server crashed
Control: reassign -1 libgl1-mesa-dri Control: tags -1 + moreinfo On Thu, 14 Feb 2019 at 21:18:42 +0100, Michel Le Bihan wrote: > I opened a png file in eog and my display server crashed. eog shouldn't be able to cause this, even if it wanted to, so this is a bug in the display server or some library it uses. >From the backtrace you provided, I think this is most likely to be an assertion failure in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so, so I'm reassigning this. The Mesa maintainers will want to know more details of your system. The output of `reportbug --template libgl1-mesa-dri` would presumably be useful information. Was the file that you opened in eog particularly large, or otherwise unusual? Thanks, smcv > Here is the relevant part of my syslog: > > Feb 14 20:44:45 debian org.gnome.Shell.desktop[1414]: Window manager warning: > Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for > 0x187 (Visionneur) > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: Xwayland: > src/intel/genxml/gen7_pack.h:72: __gen_uint: Assertion `v <= max' failed. > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) Backtrace: > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 0: > /usr/bin/Xwayland > (OsLookupColor+0x139) [0x55b8e2f27e09] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 1: > /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) [0x7fba70a3372f] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 2: > /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0x10b) [0x7fba708978bb] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 3: > /lib/x86_64-linux-gnu/libc.so.6 (abort+0x121) [0x7fba70882535] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) unw_get_proc_name > failed: no unwind info found [-10] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 4: > /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7fba70882400] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 5: > /lib/x86_64-linux-gnu/libc.so.6 (__assert_fail+0x42) [0x7fba708900f2] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 6: > /usr/lib/x86_64-linux-gnu/dri/i965_dri.so > (__driDriverGetExtensions_nouveau_vieux+0x416573) [0x7fba6fb6c503] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 7: > /usr/lib/x86_64-linux-gnu/dri/i965_dri.so > (__driDriverGetExtensions_nouveau_vieux+0x416dd5) [0x7fba6fb6cd95] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 8: > /usr/lib/x86_64-linux-gnu/dri/i965_dri.so > (__driDriverGetExtensions_i915+0x136b7b) [0x7fba6f402d8b] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 9: > /usr/lib/x86_64-linux-gnu/dri/i965_dri.so > (__driDriverGetExtensions_i915+0x1370e7) [0x7fba6f403ab7] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 10: > /usr/lib/x86_64-linux-gnu/dri/i965_dri.so > (__driDriverGetExtensions_i915+0x12f041) [0x7fba6f3f3711] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 11: > /usr/lib/x86_64-linux-gnu/dri/i965_dri.so > (__driDriverGetExtensions_i915+0x11a2dc) [0x7fba6f3c952c] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 12: > /usr/lib/x86_64-linux-gnu/dri/i965_dri.so > (__driDriverGetExtensions_nouveau_vieux+0x1ccc7a) [0x7fba6f6d929a] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 13: > /usr/lib/x86_64-linux-gnu/dri/i965_dri.so > (__driDriverGetExtensions_nouveau_vieux+0x1ccfea) [0x7fba6f6d999a] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 14: > /usr/bin/Xwayland (glamor_create_gc+0xd535) [0x55b8e2df1a05] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 15: > /usr/bin/Xwayland (DamageRegionAppend+0x19f8) [0x55b8e2e98eb8] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 16: > /usr/bin/Xwayland (glamor_pixmap_exchange_fbos+0x7b7) [0x55b8e2deef57] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 17: > /usr/bin/Xwayland (glamor_pixmap_exchange_fbos+0x67e) [0x55b8e2dee9be] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 18: > /usr/bin/Xwayland (AddTraps+0x3551) [0x55b8e2e8aad1] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 19: > /usr/bin/Xwayland (SendErrorToClient+0x35e) [0x55b8e2ef1e6e] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 20: > /usr/bin/Xwayland (InitFonts+0x3b6) [0x55b8e2ef5df6] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 21: > /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xeb) [0x7fba7088409b] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 22: > /usr/bin/Xwayland (_start+0x2a) [0x55b8e2dc71ea] > Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) > Feb 14 20:44:46 debian org.gno
Bug#917026: xorg: All the system freezes when ejects an USB stick with Thunar
Hello Alain, just saw your report and though it sounds similar to another one [1]. Do you have linux-image in version 4.9.130-2 installed? Were older kernels working like expected? If possible you might want also check if reverting back to 4.9.110-3+deb9u6 gives you a not hanging system on eject. Kind regards, Bernhard [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914696
Bug#917026: xorg: All the system freezes when ejects an USB stick with Thunar
Source: xorg Severity: important Dear Maintainer, I mount a fat USB sticker with Thunar (and udisks). All work fine. When I eject with the arrow button in Thunar, all xorg freezes. The mouse does not work and only a poweroff with the power button works. Alt-Fx does not work. No errors log in syslog. -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#913237: marked as done (xterm: exec-formatted sends an ending bracketed-paste sequence to the application (when enabled))
Your message dated Wed, 12 Dec 2018 19:49:45 +
with message-id
and subject line Bug#913237: fixed in xterm 338-1
has caused the Debian Bug report #913237,
regarding xterm: exec-formatted sends an ending bracketed-paste sequence to the
application (when enabled)
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
913237: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913237
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: xterm
Version: 337-1
Severity: normal
In my XTerm configuration, I have:
*VT100*translations:#override \n\
Meta: exec-formatted("browser %s", PRIMARY)
The problem is that when exec-formatted is invoked from zsh or emacs
(when run in xterm, e.g. with "emacs -nw"), a ~ character appears.
Other shells such as dash, bash and ksh are not affected. Curses
applications such as mutt and tack are not affected either.
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500,
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages xterm depends on:
ii libc6 2.27-8
ii libfontconfig1 2.12.6-0.1
ii libfreetype62.6.3-3.2
ii libice6 2:1.0.9-2
ii libtinfo6 6.1+20181013-1
ii libutempter01.1.6-3
ii libx11-62:1.6.7-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
--- End Message ---
--- Begin Message ---
Source: xterm
Source-Version: 338-1
We believe that the bug you reported is fixed in the latest version of
xterm, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 913...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Sven Joachim (supplier of updated xterm package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Wed, 12 Dec 2018 20:31:33 +0100
Source: xterm
Binary: xterm
Architecture: source
Version: 338-1
Distribution: unstable
Urgency: medium
Maintainer: Debian X Strike Force
Changed-By: Sven Joachim
Description:
xterm - X terminal emulator
Closes: 901249 913237 913815
Changes:
xterm (338-1) unstable; urgency=medium
.
* New upstream release.
- Amend solution for #758633 to ensure that replies for bracketed
paste are not sent while processing a selection for exec-formatted
(Closes: #913237).
- Change compiled-in default for saveLines to match the resource-file
changed in xterm 192 (Closes: #913815).
- 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).
* Mark the autopkgtests as superficial.
* Update copy of XTerm FAQ to revision 1.375 (dated 2018/10/16).
Checksums-Sha1:
b41f54fa6bd8db84609075c78413d721fbf4dfcf 2406 xterm_338-1.dsc
50a3111fa3a583321521e3c2dcece56a022afbb3 1344219 xterm_338.orig.tar.gz
37b9e095fb559cfd5bfe8d19f4ccb8e73b8c19dc 251 xterm_338.orig.tar.gz.asc
0f11f5327696d7a426eaab7e55ee3799e07c97bb 108444 xterm_338-1.debian.tar.xz
00bbc2a8536997bd036a0e58e4480427396ee2bd 8217 xterm_338-1_source.buildinfo
Checksums-Sha256:
a07602b2a813800ae63807512c53f590091cc2f7129f2fe9456bacbdf1137195 2406
xterm_338-1.dsc
b93536f5ed9847a701c1a9a81aca99a769cfd5dc001652b5e1bb600d7bfb871e 1344219
xterm_338.orig.tar.gz
9b5e7a085bd0232
Bug#889676: marked as done (xvfb: xvfb-run script contains an unnecessary dependency on the external tool "which")
Your message dated Fri, 17 Aug 2018 20:46:46 + with message-id and subject line Bug#889676: fixed in xorg-server 2:1.20.1-1 has caused the Debian Bug report #889676, regarding xvfb: xvfb-run script contains an unnecessary dependency on the external tool "which" to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 889676: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889676 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: xvfb Version: 2:1.19.6-1 Severity: minor Arch Linux has imported the xvfb-run script from Debian's package, but our package dependencies do not mandate that the "which" utility be installed. OTOH we do have it in our base package group, which users are expected to have installed, although there is a bit of bikeshedding about whether these unstated dependencies should actually be explicitly listed... See the following xvfb bugreport on our bugtracker: https://bugs.archlinux.org/task/56997 All that being said, this immediately made me think, why is the script using `which` at all, rather than the POSIX `command -v` which is far more portable as any #!/bin/sh shell has this as a builtin. It also provides a micro-optimization by avoiding an external subprocess. Please consider making this script more reusable by switching to the POSIX shell builtin. Example output on a system which does not have /usr/bin/which available: $ xvfb-run some_command /usr/bin/xvfb-run: line 139: which: command not found xvfb-run: error: xauth command not found (This error message seems rather redundant.) -- Eli Schwartz Bug Wrangler and Trusted User --- End Message --- --- Begin Message --- Source: xorg-server Source-Version: 2:1.20.1-1 We believe that the bug you reported is fixed in the latest version of xorg-server, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 889...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Andreas Boll (supplier of updated xorg-server package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 17 Aug 2018 22:05:00 +0200 Source: xorg-server Binary: xserver-xorg-core xserver-xorg-core-udeb xserver-xorg-dev xdmx xdmx-tools xnest xvfb xserver-xephyr xserver-common xorg-server-source xwayland xserver-xorg-legacy Architecture: source Version: 2:1.20.1-1 Distribution: unstable Urgency: medium Maintainer: Debian X Strike Force Changed-By: Andreas Boll Description: xdmx - distributed multihead X server xdmx-tools - Distributed Multihead X tools xnest - Nested X server xorg-server-source - Xorg X server - source files xserver-common - common files used by various X servers xserver-xephyr - nested X server xserver-xorg-core - Xorg X server - core server xserver-xorg-core-udeb - Xorg X server - core server (udeb) xserver-xorg-dev - Xorg X server - development files xserver-xorg-legacy - setuid root Xorg server wrapper xvfb - Virtual Framebuffer 'fake' X server xwayland - Xwayland X server Closes: 889676 900125 900550 900658 906034 Changes: xorg-server (2:1.20.1-1) unstable; urgency=medium . [ Julien Cristau ] * xvfb-run portability improvements by Eli Schwartz (thanks!): + Fix use of deprecated tempfile utility + Use builtin `case` to test variable value, rather than external `expr` + Use "command -v" rather than "which" (closes: #889676) . [ Sven Joachim ] * Depend on x11proto-dev rather than on the transitional x11proto-*-dev packages in xserver-xorg-dev (Closes: #900125). * Remove remaining x11proto-*-dev packages from Build-Depends. . [ Andreas Boll ] * New upstream release. - exa: Use PictureMatchFormat for source-only picture format description (Closes: #900550). - modesetting: use drmmode_bo_import() for rotate_fb (Closes: #906034, #900658). * Drop 07_fix_glamor_fds_from_pixmap.diff, upstream. Checksums-Sha1: 78c03fcb6d05634d1d81a46d0eca387f2fe2ea49 4059 xorg-server_1.20.1-1.dsc b26048e56fd1e213ee3578d9c24c0d81522194b2 8512253 xorg-server_1.20.1.orig.tar.gz ec21ffbf2af05306db02e63d759217d9b159a5
[Git][xorg-team/xserver/xorg-server][debian-unstable] Apply 3da999a and 4d5950c from upstream to fix an infinite loop in XWayland
Timo Aaltonen pushed to branch debian-unstable at X Strike Force / xserver /
xorg-server
Commits:
2b925c8a by Mike Hommey at 2018-06-21T07:03:26+09:00
Apply 3da999a and 4d5950c from upstream to fix an infinite loop in XWayland
- - - - -
3 changed files:
- debian/changelog
- + debian/patches/07_fix_glamor_fds_from_pixmap.diff
- debian/patches/series
Changes:
=
debian/changelog
=
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,7 +1,12 @@
xorg-server (2:1.20.0-3) UNRELEASED; urgency=medium
+ [ Timo Aaltonen ]
* control: Add Breaks on libgl1-mesa-dri older than 18.0.5.
+ [ Mike Hommey ]
+ * 07_fix_glamor_fds_from_pixmap.diff: Apply 3da999a and 4d5950c from
+upstream to fix an infinite loop in XWayland. Closes: #901883.
+
-- Timo Aaltonen Wed, 13 Jun 2018 11:07:10 +0300
xorg-server (2:1.20.0-2) unstable; urgency=medium
=
debian/patches/07_fix_glamor_fds_from_pixmap.diff
=
--- /dev/null
+++ b/debian/patches/07_fix_glamor_fds_from_pixmap.diff
@@ -0,0 +1,40 @@
+Description: Apply 3da999a and 4d5950c from upstream
+Author: Michel Dänzer
+
+Index: xorg-server/glamor/glamor.c
+===
+--- xorg-server.orig/glamor/glamor.c
xorg-server/glamor/glamor.c
+@@ -828,20 +828,20 @@ glamor_fds_from_pixmap(ScreenPtr screen,
+ glamor_get_screen_private(pixmap->drawable.pScreen);
+
+ if (!glamor_priv->dri3_enabled)
+-return -1;
++return 0;
+ switch (pixmap_priv->type) {
+ case GLAMOR_TEXTURE_DRM:
+ case GLAMOR_TEXTURE_ONLY:
+ if (!glamor_pixmap_ensure_fbo(pixmap, pixmap->drawable.depth == 30 ?
+ GL_RGB10_A2 : GL_RGBA, 0))
+-return -1;
++return 0;
+ return glamor_egl_fds_from_pixmap(screen, pixmap, fds,
+ strides, offsets,
+ modifier);
+ default:
+ break;
+ }
+-return -1;
++return 0;
+ }
+
+ _X_EXPORT int
+@@ -857,7 +857,7 @@ glamor_fd_from_pixmap(ScreenPtr screen,
+ &modifier);
+
+ /* Pixmaps with multi-planes/modifier are not supported in this interface
*/
+-if (ret > 1) {
++if (ret != 1 || offsets[0] != 0) {
+ while (ret > 0)
+ close(fds[--ret]);
+ return -1;
=
debian/patches/series
=
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -5,3 +5,4 @@
03_static-nettle.diff
05_Revert-Unload-submodules.diff
06_use-intel-only-on-pre-gen4.diff
+07_fix_glamor_fds_from_pixmap.diff
View it on GitLab:
https://salsa.debian.org/xorg-team/xserver/xorg-server/commit/2b925c8a0e312a6251aa7d8d85b71733f43ea446
--
View it on GitLab:
https://salsa.debian.org/xorg-team/xserver/xorg-server/commit/2b925c8a0e312a6251aa7d8d85b71733f43ea446
You're receiving this email because of your account on salsa.debian.org.
Bug#893391: marked as done (libinput: please add an autopkgtest smoke-test for the library)
Your message dated Thu, 21 Jun 2018 19:34:23 +
with message-id
and subject line Bug#893391: fixed in libinput 1.11.1-1
has caused the Debian Bug report #893391,
regarding libinput: please add an autopkgtest smoke-test for the library
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
893391: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893391
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: libinput
Version: 1.10.3-1
Severity: wishlist
Tags: patch
Some common failure modes of library packaging (particularly around
dependencies or transitions) result in inability to link dependent
binaries to the library. To catch mistakes before they become
release-critical, it's useful to have an autopkgtest that checks that
the library can work at all, even if it's a library that is awkward or
impossible to test more thoroughly.
I attach a simple autopkgtest that checks that libinput-dev can be
initialized and uninitialized, loosely based on one that I added to dbus.
I included a test for static linking, but libinput-dev doesn't seem to
contain libinput.a, so I've assumed that linking to it statically is
unsupported and left that part of the test commented out.
Note that I don't really know this library, so if I'm using it
incorrectly or in ways that are not what its upstream developers would
recommend, the test might need adjusting. It seems to work locally though.
If libinput_path_create_context() cannot legitimately fail (even in a
chroot or container running as an unprivileged user) then you might
want to make the test abort() if that call fails.
Thanks,
smcv
>From f850c612b25fe8964ff900447f444698578572cc Mon Sep 17 00:00:00 2001
From: Simon McVittie
Date: Sun, 18 Mar 2018 14:24:20 +
Subject: [PATCH] Add a simple compile/link/execute smoke-test for libinput-dev
This verifies that it is possible to link to libinput, and would have
detected #893067.
Signed-off-by: Simon McVittie
---
debian/tests/build | 60
debian/tests/control | 2 ++
2 files changed, 62 insertions(+)
create mode 100755 debian/tests/build
create mode 100644 debian/tests/control
diff --git a/debian/tests/build b/debian/tests/build
new file mode 100755
index ..bacd15e1
--- /dev/null
+++ b/debian/tests/build
@@ -0,0 +1,60 @@
+#!/bin/sh
+
+exec 2>&1
+set -eux
+
+cd "${AUTOPKGTEST_TMP:-"${ADTTMP}"}"
+
+echo "1..2"
+
+cat > simple.c <<'EOF'
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+static int
+my_open (const char *path, int flags, void *user_data)
+{
+ return open (path, flags);
+}
+
+static void
+my_close (int fd, void *user_data)
+{
+ close (fd);
+}
+
+static struct libinput_interface iface = { my_open, my_close };
+
+int
+main (void)
+{
+ struct libinput *ctx;
+
+ ctx = libinput_path_create_context (&iface, NULL);
+
+ if (ctx)
+libinput_unref (ctx);
+
+ return 0;
+}
+EOF
+
+gcc -o dynamic simple.c $(pkg-config --cflags --libs libinput)
+echo "ok 1 - compile dynamic executable"
+test -x dynamic
+./dynamic
+echo "ok 2 - run dynamic executable"
+
+# This should also be tested if linking statically to libinput is supported
+#gcc -static -o static simple.c $(pkg-config --static --cflags --libs libinput)
+#echo "ok 3 - compile static executable"
+#test -x static
+#./static
+#echo "ok 4 - run static executable"
+
+echo "# everything seems OK"
diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index ..493aaf0f
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,2 @@
+Tests: build
+Depends: build-essential, libinput-dev
--
2.16.2
--- End Message ---
--- Begin Message ---
Source: libinput
Source-Version: 1.11.1-1
We believe that the bug you reported is fixed in the latest version of
libinput, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 893...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Timo Aaltonen (supplier of updated libinput package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP
Bug#893391: marked as done (libinput: please add an autopkgtest smoke-test for the library)
Your message dated Thu, 07 Jun 2018 07:49:49 +
with message-id
and subject line Bug#893391: fixed in libinput 1.11.0-1
has caused the Debian Bug report #893391,
regarding libinput: please add an autopkgtest smoke-test for the library
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
893391: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893391
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: libinput
Version: 1.10.3-1
Severity: wishlist
Tags: patch
Some common failure modes of library packaging (particularly around
dependencies or transitions) result in inability to link dependent
binaries to the library. To catch mistakes before they become
release-critical, it's useful to have an autopkgtest that checks that
the library can work at all, even if it's a library that is awkward or
impossible to test more thoroughly.
I attach a simple autopkgtest that checks that libinput-dev can be
initialized and uninitialized, loosely based on one that I added to dbus.
I included a test for static linking, but libinput-dev doesn't seem to
contain libinput.a, so I've assumed that linking to it statically is
unsupported and left that part of the test commented out.
Note that I don't really know this library, so if I'm using it
incorrectly or in ways that are not what its upstream developers would
recommend, the test might need adjusting. It seems to work locally though.
If libinput_path_create_context() cannot legitimately fail (even in a
chroot or container running as an unprivileged user) then you might
want to make the test abort() if that call fails.
Thanks,
smcv
>From f850c612b25fe8964ff900447f444698578572cc Mon Sep 17 00:00:00 2001
From: Simon McVittie
Date: Sun, 18 Mar 2018 14:24:20 +
Subject: [PATCH] Add a simple compile/link/execute smoke-test for libinput-dev
This verifies that it is possible to link to libinput, and would have
detected #893067.
Signed-off-by: Simon McVittie
---
debian/tests/build | 60
debian/tests/control | 2 ++
2 files changed, 62 insertions(+)
create mode 100755 debian/tests/build
create mode 100644 debian/tests/control
diff --git a/debian/tests/build b/debian/tests/build
new file mode 100755
index ..bacd15e1
--- /dev/null
+++ b/debian/tests/build
@@ -0,0 +1,60 @@
+#!/bin/sh
+
+exec 2>&1
+set -eux
+
+cd "${AUTOPKGTEST_TMP:-"${ADTTMP}"}"
+
+echo "1..2"
+
+cat > simple.c <<'EOF'
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+static int
+my_open (const char *path, int flags, void *user_data)
+{
+ return open (path, flags);
+}
+
+static void
+my_close (int fd, void *user_data)
+{
+ close (fd);
+}
+
+static struct libinput_interface iface = { my_open, my_close };
+
+int
+main (void)
+{
+ struct libinput *ctx;
+
+ ctx = libinput_path_create_context (&iface, NULL);
+
+ if (ctx)
+libinput_unref (ctx);
+
+ return 0;
+}
+EOF
+
+gcc -o dynamic simple.c $(pkg-config --cflags --libs libinput)
+echo "ok 1 - compile dynamic executable"
+test -x dynamic
+./dynamic
+echo "ok 2 - run dynamic executable"
+
+# This should also be tested if linking statically to libinput is supported
+#gcc -static -o static simple.c $(pkg-config --static --cflags --libs libinput)
+#echo "ok 3 - compile static executable"
+#test -x static
+#./static
+#echo "ok 4 - run static executable"
+
+echo "# everything seems OK"
diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index ..493aaf0f
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,2 @@
+Tests: build
+Depends: build-essential, libinput-dev
--
2.16.2
--- End Message ---
--- Begin Message ---
Source: libinput
Source-Version: 1.11.0-1
We believe that the bug you reported is fixed in the latest version of
libinput, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 893...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Timo Aaltonen (supplier of updated libinput package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP
Bug#893391: libinput: please add an autopkgtest smoke-test for the library
Source: libinput
Version: 1.10.3-1
Severity: wishlist
Tags: patch
Some common failure modes of library packaging (particularly around
dependencies or transitions) result in inability to link dependent
binaries to the library. To catch mistakes before they become
release-critical, it's useful to have an autopkgtest that checks that
the library can work at all, even if it's a library that is awkward or
impossible to test more thoroughly.
I attach a simple autopkgtest that checks that libinput-dev can be
initialized and uninitialized, loosely based on one that I added to dbus.
I included a test for static linking, but libinput-dev doesn't seem to
contain libinput.a, so I've assumed that linking to it statically is
unsupported and left that part of the test commented out.
Note that I don't really know this library, so if I'm using it
incorrectly or in ways that are not what its upstream developers would
recommend, the test might need adjusting. It seems to work locally though.
If libinput_path_create_context() cannot legitimately fail (even in a
chroot or container running as an unprivileged user) then you might
want to make the test abort() if that call fails.
Thanks,
smcv
>From f850c612b25fe8964ff900447f444698578572cc Mon Sep 17 00:00:00 2001
From: Simon McVittie
Date: Sun, 18 Mar 2018 14:24:20 +
Subject: [PATCH] Add a simple compile/link/execute smoke-test for libinput-dev
This verifies that it is possible to link to libinput, and would have
detected #893067.
Signed-off-by: Simon McVittie
---
debian/tests/build | 60
debian/tests/control | 2 ++
2 files changed, 62 insertions(+)
create mode 100755 debian/tests/build
create mode 100644 debian/tests/control
diff --git a/debian/tests/build b/debian/tests/build
new file mode 100755
index ..bacd15e1
--- /dev/null
+++ b/debian/tests/build
@@ -0,0 +1,60 @@
+#!/bin/sh
+
+exec 2>&1
+set -eux
+
+cd "${AUTOPKGTEST_TMP:-"${ADTTMP}"}"
+
+echo "1..2"
+
+cat > simple.c <<'EOF'
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+static int
+my_open (const char *path, int flags, void *user_data)
+{
+ return open (path, flags);
+}
+
+static void
+my_close (int fd, void *user_data)
+{
+ close (fd);
+}
+
+static struct libinput_interface iface = { my_open, my_close };
+
+int
+main (void)
+{
+ struct libinput *ctx;
+
+ ctx = libinput_path_create_context (&iface, NULL);
+
+ if (ctx)
+libinput_unref (ctx);
+
+ return 0;
+}
+EOF
+
+gcc -o dynamic simple.c $(pkg-config --cflags --libs libinput)
+echo "ok 1 - compile dynamic executable"
+test -x dynamic
+./dynamic
+echo "ok 2 - run dynamic executable"
+
+# This should also be tested if linking statically to libinput is supported
+#gcc -static -o static simple.c $(pkg-config --static --cflags --libs libinput)
+#echo "ok 3 - compile static executable"
+#test -x static
+#./static
+#echo "ok 4 - run static executable"
+
+echo "# everything seems OK"
diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index ..493aaf0f
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,2 @@
+Tests: build
+Depends: build-essential, libinput-dev
--
2.16.2
Bug#889676: xvfb: xvfb-run script contains an unnecessary dependency on the external tool "which"
On 02/18/2018 04:04 PM, Sven Joachim wrote: > Historical reasons, POSIX has only mandated "command -v" since 2008 and > Debian does not even require that /bin/sh supports it, since the Policy > Manual specifies SUSv3 aka POSIX.2001 as the baseline[1]. As a > consequence, the minimal posh shell does not support[2] "command -v" > (not that using posh as /bin/sh is actually supported in Debian). > > See also bugs #747320[3] (talks about the "type" command, but mentions > "command -v" in the last comment) and #864615[4] (requests that Debian > should upgrade to SUSv4). > > Cheers, >Sven > > > 1. https://www.debian.org/doc/debian-policy/#scripts > 2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397601 > 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747320 > 4. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864615 Hmm, well, it would be exceedingly nice to support a POSIX standard that is *only* a decade old. That debian policy mandates the local keyword on top of POSIX, as well as completely frivolous things like echo -n (even though printf is already allowed and unambiguously better than any conceivable version of echo in any shell implementation, no matter how you want to use it) so it would be nice if there was at least one reliable way to figure out if a command exists which I would think is more important. ... Having never heard of posh before (except in the context of powershell, which I severely doubt is what you meant), I looked it up. Apparently busybox/dash were not sufficient as regards POSIX-compliant sh shells with a super minimal footprint, so debian decided to strip a third shell down for no reason other than to remove everything which is not totally vital to the standardized sh requirement as specified there. I... guess? this could make sense purely for testing purposes, but it seems a bit of a reach to support that for end users *just because* it exists. Can I at least hope that it has meaningful performance benefits over dash??? Meh, I guess this is why we can't have nice things. Woe betide the person attempting to write modern yet POSIX compliant scripts in a generally cross-distro manner. Even Debian cannot do it, and they're the ones who made the big push to get rid of bashisms. I guess if I want my cross-distro scripts I will have to settle for GNU bash in all its tremendous [sic] glory. If I want to implement some tool I have no time to spelunk around the history of SUSv3 to determine if every outdated version of a standard supports it. Well, hopefully this works. I even fixed a couple extra things as a bonus. But this is getting rather exhausting... https://salsa.debian.org/eschwartz-guest/xorg-server/commits/debian-unstable -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Bug#889676: xvfb: xvfb-run script contains an unnecessary dependency on the external tool "which"
On 2018-02-05 13:25 -0500, Eli Schwartz wrote: > Package: xvfb > Version: 2:1.19.6-1 > Severity: minor > > Arch Linux has imported the xvfb-run script from Debian's package, but > our package dependencies do not mandate that the "which" utility be > installed. OTOH we do have it in our base package group, which users are > expected to have installed, although there is a bit of bikeshedding > about whether these unstated dependencies should actually be explicitly > listed... See the following xvfb bugreport on our bugtracker: > https://bugs.archlinux.org/task/56997 > > All that being said, this immediately made me think, why is the script > using `which` at all, rather than the POSIX `command -v` which is far > more portable as any #!/bin/sh shell has this as a builtin. Historical reasons, POSIX has only mandated "command -v" since 2008 and Debian does not even require that /bin/sh supports it, since the Policy Manual specifies SUSv3 aka POSIX.2001 as the baseline[1]. As a consequence, the minimal posh shell does not support[2] "command -v" (not that using posh as /bin/sh is actually supported in Debian). See also bugs #747320[3] (talks about the "type" command, but mentions "command -v" in the last comment) and #864615[4] (requests that Debian should upgrade to SUSv4). Cheers, Sven 1. https://www.debian.org/doc/debian-policy/#scripts 2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397601 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747320 4. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864615
Bug#889676: xvfb: xvfb-run script contains an unnecessary dependency on the external tool "which"
On 02/06/2018 05:58 AM, Emilio Pozuelo Monfort wrote: > There are some differences in command vs which, e.g.: > > emilio@tatooine:~$ which ls > /bin/ls > emilio@tatooine:~$ command -v ls > alias ls='ls --color=auto' > > Some special casing would need to be added to handle aliases, whereas with > 'which' we don't. > > OTOH portability is a good goal and I'm happy that you're using xvfb-run, so > if > we can come up with a good and clean solution then that'd be good. Well, this was a rather interesting summary of options (including why the which command itself might not be what you think it is): https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then I'm not sure I understand the case for avoiding command -v, as it will only fail if the user has somehow set an alias inside a non-interactive script, which implies either modifying the script, or *sourcing* it from an interactive shell. But, there are other options. If the script was strictly bash-only, you could use type -P. From testing bash, dash, and busybox ash, in all cases `hash $command` exited with no output and a successful status, if it detected a command executable in $PATH (bash went so far as to check if the command has executable permissions, which is also what GNU which does), OR it exited with a "permission denied" or "not found" on stderr and a return code of 1. hash is also POSIX. Since xvfb-run is not trying to remember the location of the command, only check that one exists on disk (i.e. `alias xauth=asdafsjdlfkjlsdkfjslfs` would currently break everything if someone was indeed mad enough to use aliases, and also *wanted* to break things), this seems like a reasonable solution as well. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Bug#889676: xvfb: xvfb-run script contains an unnecessary dependency on the external tool "which"
Hi Eli, On 05/02/18 19:25, Eli Schwartz wrote: > Package: xvfb > Version: 2:1.19.6-1 > Severity: minor > > Arch Linux has imported the xvfb-run script from Debian's package, but > our package dependencies do not mandate that the "which" utility be > installed. OTOH we do have it in our base package group, which users are > expected to have installed, although there is a bit of bikeshedding > about whether these unstated dependencies should actually be explicitly > listed... See the following xvfb bugreport on our bugtracker: > https://bugs.archlinux.org/task/56997 > > All that being said, this immediately made me think, why is the script > using `which` at all, rather than the POSIX `command -v` which is far > more portable as any #!/bin/sh shell has this as a builtin. It also > provides a micro-optimization by avoiding an external subprocess. > > Please consider making this script more reusable by switching to the > POSIX shell builtin. > > Example output on a system which does not have /usr/bin/which available: > > $ xvfb-run some_command > /usr/bin/xvfb-run: line 139: which: command not found > xvfb-run: error: xauth command not found > > (This error message seems rather redundant.) There are some differences in command vs which, e.g.: emilio@tatooine:~$ which ls /bin/ls emilio@tatooine:~$ command -v ls alias ls='ls --color=auto' Some special casing would need to be added to handle aliases, whereas with 'which' we don't. OTOH portability is a good goal and I'm happy that you're using xvfb-run, so if we can come up with a good and clean solution then that'd be good. Cheers, Emilio
Bug#889676: xvfb: xvfb-run script contains an unnecessary dependency on the external tool "which"
Package: xvfb Version: 2:1.19.6-1 Severity: minor Arch Linux has imported the xvfb-run script from Debian's package, but our package dependencies do not mandate that the "which" utility be installed. OTOH we do have it in our base package group, which users are expected to have installed, although there is a bit of bikeshedding about whether these unstated dependencies should actually be explicitly listed... See the following xvfb bugreport on our bugtracker: https://bugs.archlinux.org/task/56997 All that being said, this immediately made me think, why is the script using `which` at all, rather than the POSIX `command -v` which is far more portable as any #!/bin/sh shell has this as a builtin. It also provides a micro-optimization by avoiding an external subprocess. Please consider making this script more reusable by switching to the POSIX shell builtin. Example output on a system which does not have /usr/bin/which available: $ xvfb-run some_command /usr/bin/xvfb-run: line 139: which: command not found xvfb-run: error: xauth command not found (This error message seems rather redundant.) -- Eli Schwartz Bug Wrangler and Trusted User
Bug#804110: Grüße an Dich
"In einer kurzen Einführung, Ich bin ein Rechtsanwalt Meinze Klaus Peter, aus Deutschland, lebe ich in London, habe ich Ihnen eine E-Mail über meine verstorbene Familie geschickt, aber ich habe keine Antwort von Ihnen erhalten, der Verstorbene ist ein Bürger in Ihrem Land mit dem gleichen Nachnamen bei Ihnen er ist Goldexporteur hier in London, mein Kunde ist vor ein paar Jahren gestorben, als seine Familie sein Geschäft verließ und riesige Geldbeträge von insgesamt 5,7 Millionen Pfund bei derUBS Investment Bank hier in London deponiert wurden, ich bin der persönliche Anwalt des verstorbenen Kunden,Ich brauche Ihre volle Kooperation, damit wir das Geld von der Bank nehmen können, bevor die Regierung endlich doch greift Ich werde erklären, mehr Details, wenn ich von dir höre Gott sei mit dir??
Processed: Re: Bug#879041: libglvnd0: Nvidia-Installer 384.90: "An incomplete installation of libglvnd was found."
Processing control commands: > reassign -1 src:nvidia-graphics-drivers Bug #879041 [libglvnd0] libglvnd0: Nvidia-Installer 384.90: "An incomplete installation of libglvnd was found." Bug reassigned from package 'libglvnd0' to 'src:nvidia-graphics-drivers'. No longer marked as found in versions 0.2.999+git2. Ignoring request to alter fixed versions of bug #879041 to the same values previously set -- 879041: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879041 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#879041: libglvnd0: Nvidia-Installer 384.90: "An incomplete installation of libglvnd was found."
Control: reassign -1 src:nvidia-graphics-drivers On Fri, Dec 01, 2017 at 08:27:05AM -0500, Chris Manougian wrote: > 384.98-2 dropped into sid this morning. It installed. > > This last weekend, I purged nvidia, and reinstalled. What was available in > sid was 375.82, and it stalled. Then 378 came into sid, and it was > installable. Then this morning, I was able to install 384.98-2. > > Still having a mesa-related error: > > root@asus:/home/chris# glxinfo | grep OpenGL > libGL error: No matching fbConfigs or visuals found > libGL error: failed to load driver: swrast > X Error of failed request: GLXBadContext > Major opcode of failed request: 154 (GLX) > Minor opcode of failed request: 6 (X_GLXIsDirect) > Serial number of failed request: 48 > Current serial number in output stream: 47 > root@asus:/home/chris# glxinfo | grep rendering > libGL error: No matching fbConfigs or visuals found > libGL error: failed to load driver: swrast > X Error of failed request: GLXBadContext > Major opcode of failed request: 154 (GLX) > Minor opcode of failed request: 6 (X_GLXIsDirect) > Serial number of failed request: 48 > Current serial number in output stream: 47 > root@asus:/home/chris# > > But that's another issue that I'm hoping a mesa update will fix. The > installation issue is resolved for me. This doesn't look like a mesa issue. Re-assigning to nvidia-graphics-drivers. Thanks, Andreas
Bug#879041: libglvnd0: Nvidia-Installer 384.90: "An incomplete installation of libglvnd was found."
384.98-2 dropped into sid this morning. It installed. This last weekend, I purged nvidia, and reinstalled. What was available in sid was 375.82, and it stalled. Then 378 came into sid, and it was installable. Then this morning, I was able to install 384.98-2. Still having a mesa-related error: root@asus:/home/chris# glxinfo | grep OpenGL libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast X Error of failed request: GLXBadContext Major opcode of failed request: 154 (GLX) Minor opcode of failed request: 6 (X_GLXIsDirect) Serial number of failed request: 48 Current serial number in output stream: 47 root@asus:/home/chris# glxinfo | grep rendering libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast X Error of failed request: GLXBadContext Major opcode of failed request: 154 (GLX) Minor opcode of failed request: 6 (X_GLXIsDirect) Serial number of failed request: 48 Current serial number in output stream: 47 root@asus:/home/chris# But that's another issue that I'm hoping a mesa update will fix. The installation issue is resolved for me.
Bug#879041: libglvnd0: Nvidia-Installer 384.90: "An incomplete installation of libglvnd was found."
Andreas, the experimental 384.98 driver failed. Sid's 375.82 is installable. This all started with the last Xorg and Mesa updates. There's a new Mesa at RC5 in experimental. I guess I'm going to wait for that to drop into sid.
Bug#879041: libglvnd0: Nvidia-Installer 384.90: "An incomplete installation of libglvnd was found."
On Wed, 18 Oct 2017 19:07:41 +0200 Dirk Lehmann wrote: > During installing the Nvidia Geforce driver version 384.90 the > following error occurs: Please use the 384.xx nvidia-graphics-drivers packages from experimental. Andreas
Bug#879041: libglvnd0: Nvidia-Installer 384.90: "An incomplete installation of libglvnd was found."
Package: libglvnd0 Version: 0.2.999+git2 Severity: normal Dear Maintainer, During installing the Nvidia Geforce driver version 384.90 the following error occurs: "An incomplete installation of libglvnd was found. Do you want to install a full copy of libglvnd? This will overwrite any existing libglvnd libraries." After choosing to NOT overwrite the installation all OpenGL applications does not work. For example GLXGEARS outputs the error: Begin of glxgreas output libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 154 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x0 Serial number of failed request: 35 Current serial number in output stream: 37 End of glxgreas output Here is the full output of /var/log/nvidia-installer.log Begin of /var/log/nvidia-installer.log nvidia-installer log file '/var/log/nvidia-installer.log' creation time: Wed Oct 18 18:09:11 2017 installer version: 384.90 PATH: /root/bin:/usr/local/ocs/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin nvidia-installer command line: ./nvidia-installer Unable to load: nvidia-installer ncurses v6 user interface Using: nvidia-installer ncurses user interface -> Detected 4 CPUs online; setting concurrency level to 4. -> License accepted. -> Installing NVIDIA driver version 384.90. -> There appears to already be a driver installed on your system (version: 384.90). As part of installing this driver (version: 384.90), the existing driver will be uninstalled. Are you sure you want to continue? (Answer: Continue installation) -> Performing CC sanity check with CC="/usr/bin/cc". -> Kernel source path: '/lib/modules/4.13.0-1-amd64/source' -> Kernel output path: '/lib/modules/4.13.0-1-amd64/build' -> Performing Compiler check. -> Performing Dom0 check. -> Performing Xen check. -> Performing PREEMPT_RT check. -> Cleaning kernel module build directory. executing: 'cd ./kernel; /usr/bin/make -k -j4 clean NV_EXCLUDE_KERNEL_MODULES="" SYSSRC="/lib/modules/4.13.0-1-amd64/source" SYSOUT="/lib/modules/4.13.0-1-amd64/build"'... rm -f -r conftest /usr/bin/make "CC=cc" KBUILD_OUTPUT=/lib/modules/4.13.0-1-amd64/build KBUILD_VERBOSE= -C /lib/modules/4.13.0-1-amd64/source M=/tmp/selfgz4965/NVIDIA-Linux-x86_64-384.90/kernel ARCH=x86_64 NV_KERNEL_SOURCES=/lib/modules/4.13.0-1-amd64/source NV_KERNEL_OUTPUT=/lib/modules/4.13.0-1-amd64/build NV_KERNEL_MODULES="nvidia nvidia-uvm nvidia-modeset nvidia-drm" INSTALL_MOD_DIR=kernel/drivers/video clean make[1]: Entering directory '/usr/src/linux-headers-4.13.0-1-common' make[2]: Entering directory '/usr/src/linux-headers-4.13.0-1-amd64' make[2]: Leaving directory '/usr/src/linux-headers-4.13.0-1-amd64' make[1]: Leaving directory '/usr/src/linux-headers-4.13.0-1-common' -> Building kernel modules executing: 'cd ./kernel; /usr/bin/make -k -j4 NV_EXCLUDE_KERNEL_MODULES="" SYSSRC="/lib/modules/4.13.0-1-amd64/source" SYSOUT="/lib/modules/4.13.0-1-amd64/build"'... /usr/bin/make "CC=cc" KBUILD_OUTPUT=/lib/modules/4.13.0-1-amd64/build KBUILD_VERBOSE= -C /lib/modules/4.13.0-1-amd64/source M=/tmp/selfgz4965/NVIDIA-Linux-x86_64-384.90/kernel ARCH=x86_64 NV_KERNEL_SOURCES=/lib/modules/4.13.0-1-amd64/source NV_KERNEL_OUTPUT=/lib/modules/4.13.0-1-amd64/build NV_KERNEL_MODULES="nvidia nvidia-uvm nvidia-modeset nvidia-drm" INSTALL_MOD_DIR=kernel/drivers/video modules make[1]: Entering directory '/usr/src/linux-headers-4.13.0-1-common' make[2]: Entering directory '/usr/src/linux-headers-4.13.0-1-amd64' SYMLINK /tmp/selfgz4965/NVIDIA-Linux-x86_64-384.90/kernel/nvidia/nv-kernel.o SYMLINK /tmp/selfgz4965/NVIDIA-Linux-x86_64-384.90/kernel/nvidia-modeset/nv-modeset-kernel.o CONFTEST: INIT_WORK CONFTEST: remap_pfn_range CONFTEST: hash__remap_4k_pfn CONFTEST: follow_pfn CONFTEST: vmap CONFTEST: set_pages_uc CONFTEST: set_memory_uc CONFTEST: set_memory_array_uc CONFTEST: change_page_attr CONFTEST: pci_get_class CONFTEST: pci_choose_state CONFTEST: vm_insert_page CONFTEST: acpi_device_id CONFTEST: acquire_console_sem CONFTEST: console_lock CONFTEST: kmem_cache_create CONFTEST: on_each_cpu CONFTEST: smp_call_function CONFTEST: acpi_evaluate_integer CONFTEST: ioremap_cache CONFTEST: ioremap_wc CONFTEST: acpi_walk_namespace CONFTEST: pci_domain_nr CONFTEST: pci_dma_mapping_error CONFTEST: sg
An
Sent from my iPhone
Re: nested screen on an attached display
Uhhm, this is most probably not the best list for this support level. I had several attempts last year to solve this problem on several IRC channels, but none who could help me, so I wrote directly to the dev list. But forget that there is a user list, not for this special topic but for user matters as a whole. However, sorry for this mail into the wrong list. Best Regards Christian > Hello out there, > I have probably a bug to report (Debian testing). Im not sure which is > the component which fails in my case. Its regarding my Thinkpad X60, > which is connected with a docking station and over that with a monitor. > I faced this issue last year already but supposed that is has something > to do with my change from Awesome WM to i3 WM. The screen resolution on > my TP is allright in most of the cases. But on my attached 19" display > it's a mess. First with the display manager Lightdm, I have the > wallpaper all over the screen (which is what I want) but within that I > have a "nested" screen. And the login dialog is alligned within this > nested screen. The nested screen has the resolution of my TP (11") > On my desktop (i3) it's the same, the wallpaper all over the screen and > a nested screen within that screen, with the size of the Thinkpad > screen. And I can use only that nested screen for applications, whereas > I can move the mousepointer all over the screen. I tinkered myself a > solution with xrandr but this is not very predictable. Sometimes it > workes sometimes not. And it drives me crazy when I plug in a SSD with a > Xubuntu 15.10 which works fine. And as I mentioned until december 2015 I > didn't have this problem with Testing. I do not talk about a two screen > solution or any like that, its just if work with my docking station, I > use an external 19" display and the notebook display is off. > It should work, it worked all over the last years. > I could make a bug report, but Im not sure, which is the culprit for > this issue. > > Has anybody a clue, which the problem caused? > > Thank you in advance > > Best Regards Christian > >
nested screen on an attached display
Hello out there, I have probably a bug to report (Debian testing). Im not sure which is the component which fails in my case. Its regarding my Thinkpad X60, which is connected with a docking station and over that with a monitor. I faced this issue last year already but supposed that is has something to do with my change from Awesome WM to i3 WM. The screen resolution on my TP is allright in most of the cases. But on my attached 19" display it's a mess. First with the display manager Lightdm, I have the wallpaper all over the screen (which is what I want) but within that I have a "nested" screen. And the login dialog is alligned within this nested screen. The nested screen has the resolution of my TP (11") On my desktop (i3) it's the same, the wallpaper all over the screen and a nested screen within that screen, with the size of the Thinkpad screen. And I can use only that nested screen for applications, whereas I can move the mousepointer all over the screen. I tinkered myself a solution with xrandr but this is not very predictable. Sometimes it workes sometimes not. And it drives me crazy when I plug in a SSD with a Xubuntu 15.10 which works fine. And as I mentioned until december 2015 I didn't have this problem with Testing. I do not talk about a two screen solution or any like that, its just if work with my docking station, I use an external 19" display and the notebook display is off. It should work, it worked all over the last years. I could make a bug report, but Im not sure, which is the culprit for this issue. Has anybody a clue, which the problem caused? Thank you in advance Best Regards Christian
Re: Bug#844357: binutils: mips* mesa libGL.so.1 contains an invalid symbol table
Control: tags -1 patch Hi, On 18/11/16 23:39, James Cowgill wrote: > On 16/11/16 17:15, James Cowgill wrote: >> Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=20828 >> >> Hi, >> >> I've submitted the bug upstream with a reduced testcase and a bisection. >> >> As the bug requires -Wl,--gc-sections to occur, it may be possible to >> workaround in mesa by recompiling without it. > > I have attached two patches: > > binutils-pr20828-v1.patch attempts to fix the underlying issue in > binutils where local symbols appear intermixed with global symbols. It > does this by applying another pass over the symbol table to assign all > the local symbol indexes first, then ignoring local symbols in the > second pass. This seems to fix my testcase and mesa, although I am not > 100% sure of it and I would like to get some feedback from upstream as > well since I don't really do much work with binutils. I think the breakage is too much to wait any longer, so please can you apply this patch to binutils so we can start recovering from all this. Thanks, James signature.asc Description: OpenPGP digital signature
Re: Bug#844357: binutils: mips* mesa libGL.so.1 contains an invalid symbol table
Hi,
On 16/11/16 17:15, James Cowgill wrote:
> Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=20828
>
> Hi,
>
> I've submitted the bug upstream with a reduced testcase and a bisection.
>
> As the bug requires -Wl,--gc-sections to occur, it may be possible to
> workaround in mesa by recompiling without it.
I have attached two patches:
binutils-pr20828-v1.patch attempts to fix the underlying issue in
binutils where local symbols appear intermixed with global symbols. It
does this by applying another pass over the symbol table to assign all
the local symbol indexes first, then ignoring local symbols in the
second pass. This seems to fix my testcase and mesa, although I am not
100% sure of it and I would like to get some feedback from upstream as
well since I don't really do much work with binutils.
mesa-mips-844227-workaround.patch is a workaround for mesa I was
investigating in the meantime. It turns out that removing
--Wl,gc-sections triggers some more undefined references so you need to
link libnir.a in a few extra places.
Thanks,
James
--- a/bfd/elfxx-mips.c
+++ b/bfd/elfxx-mips.c
@@ -743,6 +743,8 @@ static struct mips_got_entry *mips_elf_create_local_got_entry
struct mips_elf_link_hash_entry *, int);
static bfd_boolean mips_elf_sort_hash_table_f
(struct mips_elf_link_hash_entry *, void *);
+static bfd_boolean mips_elf_sort_hash_table_local_f
+ (struct mips_elf_link_hash_entry *, void *);
static bfd_vma mips_elf_high
(bfd_vma);
static bfd_boolean mips_elf_create_dynamic_relocation
@@ -3850,6 +3852,11 @@ mips_elf_sort_hash_table (bfd *abfd, struct bfd_link_info *info)
= hsd.min_got_dynindx
= (elf_hash_table (info)->dynsymcount - g->reloc_only_gotno);
hsd.max_non_got_dynindx = count_section_dynsyms (abfd, info) + 1;
+
+ mips_elf_link_hash_traverse (((struct mips_elf_link_hash_table *)
+elf_hash_table (info)),
+mips_elf_sort_hash_table_local_f,
+&hsd);
mips_elf_link_hash_traverse (((struct mips_elf_link_hash_table *)
elf_hash_table (info)),
mips_elf_sort_hash_table_f,
@@ -3879,28 +3886,40 @@ mips_elf_sort_hash_table_f (struct mips_elf_link_hash_entry *h, void *data)
{
struct mips_elf_hash_sort_data *hsd = data;
- /* Symbols without dynamic symbol table entries aren't interesting
- at all. */
- if (h->root.dynindx == -1)
+ /* Only interested in global symbols with dynamic symbol table entries */
+ if (h->root.dynindx == -1 || h->root.forced_local)
return TRUE;
- switch (h->global_got_area)
-{
-case GGA_NONE:
+ if (h->global_got_area == GGA_NONE) {
h->root.dynindx = hsd->max_non_got_dynindx++;
- break;
+ } else {
+ if (h->global_got_area == GGA_NORMAL)
+ h->root.dynindx = --hsd->min_got_dynindx;
+ else
+ h->root.dynindx = hsd->max_unref_got_dynindx++;
-case GGA_NORMAL:
- h->root.dynindx = --hsd->min_got_dynindx;
- hsd->low = (struct elf_link_hash_entry *) h;
- break;
+ if (hsd->low == NULL || h->root.dynindx < hsd->low->dynindx)
+ hsd->low = (struct elf_link_hash_entry *) h;
+ }
-case GGA_RELOC_ONLY:
- if (hsd->max_unref_got_dynindx == hsd->min_got_dynindx)
- hsd->low = (struct elf_link_hash_entry *) h;
- h->root.dynindx = hsd->max_unref_got_dynindx++;
- break;
-}
+ return TRUE;
+}
+
+/* All local symbols must be appear before global symbols in the dynamic symbol
+ table so they're assigned indexs first. */
+
+static bfd_boolean
+mips_elf_sort_hash_table_local_f (struct mips_elf_link_hash_entry *h, void *data)
+{
+ struct mips_elf_hash_sort_data *hsd = data;
+
+ /* Only interested in local symbols with dynamic symbol table entries */
+ if (h->root.dynindx == -1 || !h->root.forced_local)
+return TRUE;
+
+ h->root.dynindx = hsd->max_non_got_dynindx++;
+ if (h->global_got_area != GGA_NONE && hsd->low == NULL)
+ hsd->low = (struct elf_link_hash_entry *) h;
return TRUE;
}
--- a/configure.ac
+++ b/configure.ac
@@ -543,17 +543,7 @@ AC_SUBST([BSYMBOLIC])
dnl
dnl Check if linker supports garbage collection
dnl
-save_LDFLAGS=$LDFLAGS
-LDFLAGS="$LDFLAGS -Wl,--gc-sections"
-AC_MSG_CHECKING([whether ld supports --gc-sections])
-AC_LINK_IFELSE(
-[AC_LANG_SOURCE([static char UnusedFunc() { return 5; } int main() { return 0;}])],
-[AC_MSG_RESULT([yes])
-GC_SECTIONS="-Wl,--gc-sections";],
-[AC_MSG_RESULT([no])
-GC_SECTIONS="";])
-LDFLAGS=$save_LDFLAGS
-
+GC_SECTIONS=""
AC_SUBST([GC_SECTIONS])
dnl
--- a/src/gallium/targets/va/Makefile.am
+++ b/src/gallium/targets/va/Makefile.am
@@ -29,6 +29,7 @@ gallium_drv_video_la_LIBADD = \
$(top_builddir)/src/gallium/auxiliary/libgalliumvl.la \
$(top_builddir)/src/gallium/auxiliary/libgallium.la \
$(top_builddir)/src/util/libmesautil.la \
+ $(top_builddir)/src/compiler/nir/libnir.la \
$(VL_LIBS) \
$(LIBDRM_LIBS) \
$(GALLIUM_COMMON_LIB_DEPS)
--- a/src/gall
Re: Bug#844357: binutils: mips* mesa libGL.so.1 contains an invalid symbol table
Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=20828 Hi, I've submitted the bug upstream with a reduced testcase and a bisection. As the bug requires -Wl,--gc-sections to occur, it may be possible to workaround in mesa by recompiling without it. Thanks, James signature.asc Description: OpenPGP digital signature
Re: Bug#844357: binutils: mips* mesa libGL.so.1 contains an invalid symbol table (Was: fracplanet FTPFS on mips*: libQtOpenGL.so: undefined reference to `glLoadMatrixd')
On 16/11/16 11:32, James Cowgill wrote: > Here 3 = the index of the first non-global symbol, and 9 = the total s/non-global/non-local/ James signature.asc Description: OpenPGP digital signature
Bug#832607: xrandr: crash when trying to desactivate an external screen
On Wed, Jul 27, 2016 at 15:28:00 +0200, Vincent Danjean wrote: > Somtimes, when trying to desactivate my external screen, I get a segfault: > vdanjean@eyak:~$ xrandr --output VGA1 --off --output VIRTUAL1 --off --output > DP-1-1 --off --output DP-1-2 --off --output DP-1-3 --off --output eDP1 --auto > --primary > Floating point exception (core dumped) > That's not a segfault... > I'm not sure the bug comes from xrandr itself. Perhaps it is in an > underlining driver, as > I get a very suspiscous "resolution" value from xdpyinfo for example: > vdanjean@eyak:~$ xdpyinfo | grep -B 100 -A 20 resolution [...] > screen #0: > dimensions:3840x2160 pixels (0x0 millimeters) > resolution:-2147483648x-2147483648 dots per inch The divide by 0 is a bug in xrandr. The 0mm is arguably a bug in the driver. Cheers, Julien
Bug#832607: xrandr: crash when trying to desactivate an external screen
Package: x11-xserver-utils Version: 7.7+7 Severity: important Hi, I've a laptop with its LCD driven by an integrated Intel Card and a 4k external screen driven by an NVidia card (managed with the nouveau driver). vdanjean@eyak:~$ xrandr --listproviders Providers: number : 2 Provider 0: id: 0xb0 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 3 associated providers: 1 name:Intel Provider 1: id: 0x66 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 4 outputs: 3 associated providers: 1 name:nouveau vdanjean@eyak:~$ xrandr --current Screen 0: minimum 8 x 8, current 3840 x 2160, maximum 32767 x 32767 eDP1 connected 1920x1080+3840+1080 (normal left inverted right x axis y axis) 340mm x 190mm 1920x1080 60.02*+ 59.9347.99 [...] 640x360 60.00 VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) DP-1-1 disconnected (normal left inverted right x axis y axis) DP-1-2 disconnected (normal left inverted right x axis y axis) DP-1-3 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 597mm x 336mm 3840x2160 60.00*+ 29.98 [...] 640x480 (0x88) 25.175MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew0 clock 31.47KHz v: height 480 start 490 end 492 total 525 clock 59.94Hz vdanjean@eyak:~$ uname -a Linux eyak 4.7.0-rc7-amd64 #1 SMP Debian 4.7~rc7-1~exp1 (2016-07-14) x86_64 GNU/Linux vdanjean@eyak:~$ apt-cache policy linux-image-4.7.0-rc7-amd64 linux-image-4.7.0-rc7-amd64: Installed: 4.7~rc7-1~exp1 Candidate: 4.7~rc7-1~exp1 Version table: *** 4.7~rc7-1~exp1 100 1 http://ftp.fr.debian.org/debian experimental/main amd64 Packages 100 /var/lib/dpkg/status Somtimes, when trying to desactivate my external screen, I get a segfault: vdanjean@eyak:~$ xrandr --output VGA1 --off --output VIRTUAL1 --off --output DP-1-1 --off --output DP-1-2 --off --output DP-1-3 --off --output eDP1 --auto --primary Floating point exception (core dumped) I'm not sure the bug comes from xrandr itself. Perhaps it is in an underlining driver, as I get a very suspiscous "resolution" value from xdpyinfo for example: vdanjean@eyak:~$ xdpyinfo | grep -B 100 -A 20 resolution name of display::0.0 version number:11.0 vendor string:The X.Org Foundation vendor release number:11804000 X.Org version: 1.18.4 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 [...] depth 32, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0x620211c, revert to Parent number of extensions:29 BIG-REQUESTS [...] XVideo-MotionCompensation default screen number:0 number of screens:1 screen #0: dimensions:3840x2160 pixels (0x0 millimeters) resolution:-2147483648x-2147483648 dots per inch depths (7):24, 1, 4, 8, 15, 16, 32 root window id:0x13d depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x8c default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store WHEN MAPPED, save-unders NO largest cursor:256x256 current input event mask:0xfac03f KeyPressMask KeyReleaseMask ButtonPressMask ButtonReleaseMaskEnterWindowMask LeaveWindowMask KeymapStateMask ExposureMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask ColormapChangeMask number of visuals:40 default visual id: 0x8a visual: visual id:0x8a class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits [...] Do you have any clue about this behavior? Fill free to reassign to another package if you think the bug come from elsewhere (nouveau/intel xorg driver, kernel module, ...) Regards Vincent -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armel, mipsel Kernel: Linux 4.7.0-rc7-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages x11-xserver-utils depends on: ii cpp 4:5.3.
Bug#830723: When X server start fails it ends up in an endless loop
Package: xserver-xorg Version: 1:7.7+7 Severity: important Hello, for more than one time i have the problem that when the X server fails to start it ends up in an loop to try to start! When you have a damaged vga card and change it you never get a simple console again. Sometimes the system doesn't react any more because it is somehow locked by the X server. Why this loop? In the past the X server tried to start and when it fails it prompted the error and you land on the console. Now the system behaviour is like in windows where the system get's unusable without an graphical frontend! Cheers Karsten -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Jun 21 2015 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 2401376 Feb 11 2015 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 430] [10de:0de1] (rev a1) /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. KMS configuration files: /etc/modprobe.d/i915-kms.conf: options i915 modeset=1 /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u2 (2015-07-17) Xorg X server log files on system: -- -rw-r--r-- 1 root root 42479 Dec 4 2010 /var/log/Xorg.2.log -rw-r--r-- 1 root root 35553 Jun 19 12:29 /var/log/Xorg.1.log -rw-r--r-- 1 root root 8004 Jul 10 21:04 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [ 309.595] X.Org X Server 1.16.4 Release Date: 2014-12-20 [ 309.595] X Protocol Version 11, Revision 0 [ 309.595] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian [ 309.595] Current Operating System: Linux PC8 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u2 (2015-07-17) x86_64 [ 309.595] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=22e85ef8-276b-4cdd-bfd9-bc76e4f12e56 ro quiet [ 309.595] Build Date: 11 February 2015 12:32:02AM [ 309.596] xorg-server 2:1.16.4-1 (http://www.debian.org/support) [ 309.596] Current version of pixman: 0.32.6 [ 309.596]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 309.596] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 309.597] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Jul 10 21:04:34 2016 [ 309.597] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 309.598] (==) No Layout section. Using the first Screen section. [ 309.598] (==) No screen section available. Using defaults. [ 309.598] (**) |-->Screen "Default Screen Section" (0) [ 309.598] (**) | |-->Monitor "" [ 309.598] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 309.598] (==) Automatically adding devices [ 309.598] (==) Automatically enabling devices [ 309.598] (==) Automatically adding GPU devices [ 309.598] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 309.598]Entry deleted from font path. [ 309.598] (==) 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 [ 309.598] (==) ModulePath set to "/usr/lib/xorg/modules" [ 309.598] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 309.598] (II) Loader magic: 0x7fe8ba921d80 [ 309.598] (II) Module ABI versions: [ 309.598]X.Org ANSI C Emulation: 0.4 [ 309.598]X.Org Video Driver: 18.0 [ 309.598]X.Org XInput driver : 21.0 [ 309.598]X.Org Server Extension : 8.0 [ 309.598] (II) xfree86: Adding drm device (/dev/dri/card0) [ 309.600] (--) PCI:*(0:2:0:0) 10de:0de1:: rev 161, Mem @ 0xfd00/16777216, 0xf000/134217728, 0xfa00/33554432, I/O @ 0xe800/128, BIOS @ 0x/524288 [ 309.600] (II) LoadModule: "glx" [ 309.600] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 309.601] (II) Module glx: vendor="X.Org Foundation" [ 309.601]compiled for 1.16.4, module version = 1.0.0 [ 309.601]ABI class: X.Org Server Extension, version 8.0 [ 309.601]
Bug#799325: weston: won't start despite having an active logind session
Hello, On Thu, Sep 17, 2015 at 02:42:59PM -0700, Ben Longbons wrote: > $ weston-launch > weston-launch: Permission denied. You should either: > - enable systemd session support for weston-launch. > - or add yourself to the 'weston-launch' group. Thanks for the report, I have been testing with 1.11.0 version and the issue is gone on my system. Could you please re-test and update the bug report? Regards, -- Hector Oron signature.asc Description: PGP signature
双喜外贸软件 shared an album with you.
软件功能： 智能设置关键词搜索 提供多种搜索引擎 支持多种语言搜索 搜索结果相关性大，质量高 搜索结果可作整理与分类管理 智能模拟人工群发信，避免开发信被栏截 外贸客户搜索与开发=主动式营销 联系QQ号码：2535847186 可在线利用贵司产品，直接展示搜索效果。 Contact person：Mr.mai https://picasaweb.google.com/lh/sredir?uname=100016044510146339079&target=ALBUM&id=5864410092452187153&authkey=Gv1sRgCJLg58KN_OHzygE&invite=CPiXuuUK&feat=email
Bug#803528: glxgears works with x64 and an AMD card
For what it's worth, someone with the nick name "Sc0rpius" on OFTC's #debian-next channel said glxgears works with the same versions of the libgl1-mesa-dri:i386, libgl1-mesa-glx:i386, libx11-6:i386 and libxcb1:i386 packages. However, Sc0rpius was using x64 and an AMD card. glxgears fails for me with i386 and an nVidia card. I hope that helps, Kingsley -- Time is the fire in which we all burn.
Bug#799325: weston: won't start despite having an active logind session
Package: weston Version: 1.8.0-3 Severity: important Dear Maintainer, According to README.Debian, having an active logind session should be sufficient to start weston without being in the weston-launch group. This does not work. $ loginctl list-sessions SESSIONUID USER SEAT 198 1000 ben seat0 8 1000 ben seat0 262 1000 ben seat0 197128 sddm seat0 4 sessions listed. $ loginctl show-session 262 Id=262 Name=ben Timestamp=Thu 2015-09-17 14:33:40 PDT TimestampMonotonic=111440115978 VTNr=2 TTY=/dev/tty2 Remote=no Service=login Scope=session-262.scope Leader=25537 Audit=262 Type=tty Class=user Active=yes State=active IdleHint=no IdleSinceHint=1442525896738975 IdleSinceHintMonotonic=111715924138 $ weston-launch weston-launch: Permission denied. You should either: - enable systemd session support for weston-launch. - or add yourself to the 'weston-launch' group. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages weston depends on: ii adduser 3.113+nmu3 ii libc6 2.19-19 ii libcairo2 1.14.2-2 ii libcolord2 1.2.11-1 ii libdrm2 2.4.64-1 ii libegl1-mesa [libegl1-x11] 10.6.3-1 ii libgbm1 10.6.3-1 ii libgles2-mesa [libgles2]10.6.3-1 ii libglib2.0-02.44.1-1.1 ii libinput10 1.0.1-1 ii libjpeg62-turbo 1:1.4.1-2 ii liblcms2-2 2.6-3+b3 ii libmtdev1 1.1.5-1 ii libpam0g1.1.8-3.1 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpixman-1-0 0.32.6-3 ii libpng12-0 1.2.50-2+b2 ii libudev1225-1 ii libwayland-client0 1.8.1-1 ii libwayland-cursor0 1.8.1-1 ii libwayland-egl1-mesa [libwayland-egl1] 10.6.3-1 ii libwayland-server0 1.8.1-1 ii libx11-62:1.6.3-1 ii libx11-xcb1 2:1.6.3-1 ii libxcb-composite0 1.10-3+b1 ii libxcb-render0 1.10-3+b1 ii libxcb-shape0 1.10-3+b1 ii libxcb-shm0 1.10-3+b1 ii libxcb-xfixes0 1.10-3+b1 ii libxcb-xkb1 1.10-3+b1 ii libxcb1 1.10-3+b1 ii libxcursor1 1:1.1.14-1+b1 ii libxkbcommon0 0.5.0-1 Versions of packages weston recommends: ii libgl1-mesa-dri 10.6.3-1 weston suggests no packages. -- no debconf information
Bug#792356: libx11-6: X_GetWindowAttributes fails to report if window is launched direction to an extended desktop screen.
On Tue, Jul 14, 2015 at 02:35:15 -0500, Darren Decker wrote: > Package: libx11-6 > Version: 2:1.6.2-3 > Severity: important > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? > > Working with xdotool. > >* What exactly did you do (or not do) that was effective (or > ineffective)? > > Launched window directly to extended desktop screen. > >* What was the outcome of this action? > > X_GetWindowAttributes failed request. > >* What outcome did you expect instead? > > X_GetWindowAttributes returning window attributes. > There's not nearly enough details to do anything with this report... Cheers, Julien signature.asc Description: Digital signature
Bug#792356: libx11-6: X_GetWindowAttributes fails to report if window is launched direction to an extended desktop screen.
Package: libx11-6 Version: 2:1.6.2-3 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Working with xdotool. * What exactly did you do (or not do) that was effective (or ineffective)? Launched window directly to extended desktop screen. * What was the outcome of this action? X_GetWindowAttributes failed request. * What outcome did you expect instead? X_GetWindowAttributes returning window attributes. *** End of the template - remove these template lines *** -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libx11-6 depends on: ii libc6 2.19-18 ii libx11-data2:1.6.2-3 ii libxcb11.10-3+b1 ii multiarch-support 2.19-18 libx11-6 recommends no packages. libx11-6 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/20150714073515.3567.82174.report...@thehost.thedomainname.net
Bug#729200: [xserver-xorg-input-synaptics] Still an issue in jessie/stretch
Package: xserver-xorg-input-synaptics Version: 1.8.2-1 --- Please enter the report below this line. --- This is still a major issue in current debian. There is a patch on the launchpad bug page which appears to solve the issue for people, however I haven't tried it myself yet. --- System information. --- Architecture: amd64 Kernel: Linux 3.16.0-4-amd64 Debian Release: stretch/sid 500 testing mirror.aarnet.edu.au 500 stable security.debian.org 500 stable mirror.aarnet.edu.au --- Package information. --- Depends(Version) | Installed -+-=== libc6 (>= 2.14) | 2.19-18 libevdev2 (>= 0.9.1) | 1.4.2+dfsg-1 libx11-6 | 2:1.6.3-1 libxi6 (>= 2:1.2.0) | 2:1.7.4-1+b2 xorg-input-abi-21| xserver-xorg-core (>= 2:1.15.99.903) | 2:1.17.1-2 Package's Recommends field is empty. Suggests (Version) | Installed -+-=== gpointing-device-settings| touchfreeze | -- 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/557a2653.5000...@uq.edu.au
Re: Fwd: An important mesa fix
On Tue, Mar 3, 2015 at 17:44:03 +0100, intrigeri wrote: > Hi, > > I've not checked if it affects Debian, not sure if you follow GNOME > lists, so FYI: > We don't follow gnome lists, but the bugzilla says this only affects the mesa 10.5 branch, so we should be fine. Cheers, Julien signature.asc Description: Digital signature
Fwd: An important mesa fix
Hi, I've not checked if it affects Debian, not sure if you follow GNOME lists, so FYI: --- Begin Message --- Hi fellow distributors, we've noticed a regresssion in taking screenshots with the gnome-shell calendar popup open ( https://bugzilla.gnome.org/show_bug.cgi?id=744978 ). This turned out to be caused by a bug in mesa that has been fixed in the meantime. You might want to make sure that your mesa build includes the patch in http://lists.freedesktop.org/archives/mesa-dev/2015-February/078074.html Matthias ___ distributor-list mailing list distributor-l...@gnome.org https://mail.gnome.org/mailman/listinfo/distributor-list --- End Message --- Cheers! -- intrigeri
Bug#778991: marked as done (xserver-xorg-video-intel: graphical glitches in the circulating symbol while waiting for an application)
Your message dated Mon, 23 Feb 2015 17:21:11 +0100 with message-id <20150223162111.gf1...@betterave.cristau.org> and subject line [fwd] failure notice has caused the Debian Bug report #778991, regarding xserver-xorg-video-intel: graphical glitches in the circulating symbol while waiting for an application to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 778991: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778991 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: xserver-xorg-video-intel Version: 2:2.21.15-2+b2 Severity: normal Dear Maintainer, this problem affects multiple application. E.g. Empathy: Connecting to an account takes a while. The process is visualized by two circulating symbols in the empathy window. The normal behaviour should be that these symbols integrate well in the background of the window. But instead of this they have a little black square background. Sorry, I can't give a more detailed description of the bug and will send a picture after recieve the bug number. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Feb 21 15:37 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 2401376 Feb 10 19:35 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) /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 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) Xorg X server log files on system: -- -rw-r--r-- 1 root root 33205 Feb 22 11:57 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [44.723] X.Org X Server 1.16.4 Release Date: 2014-12-20 [44.723] X Protocol Version 11, Revision 0 [44.723] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian [44.723] Current Operating System: Linux mobybit 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 [44.723] Kernel command line: BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/mobybit--vg-root ro quiet [44.723] Build Date: 11 February 2015 12:32:02AM [44.723] xorg-server 2:1.16.4-1 (http://www.debian.org/support) [44.723] Current version of pixman: 0.32.6 [44.723]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [44.723] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [44.723] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Feb 22 10:43:12 2015 [44.724] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [44.725] (==) No Layout section. Using the first Screen section. [44.725] (==) No screen section available. Using defaults. [44.725] (**) |-->Screen "Default Screen Section" (0) [44.725] (**) | |-->Monitor "" [44.725] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [44.725] (==) Automatically adding devices [44.725] (==) Automatically enabling devices [44.725] (==) Automatically adding GPU devices [44.726] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [44.726]Entry deleted from font path. [44.726] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist. [44.726]Entry deleted from font path. [44.726] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist. [44.726]Entry deleted from font path. [44.726] (WW) The directory "/usr/share/fonts/X11/Type1" does not exist. [44.726]Entry deleted from font path. [44.726] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist. [44.726]Entry deleted from font path. [44.726] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist. [44.726]Entry deleted from font path. [44.726] (==) FontPath set to: /usr/share/fonts/X11/misc, built-
Bug#778991: xserver-xorg-video-intel: graphical glitches in the circulating symbol while waiting for an application
On Sun, Feb 22, 2015 at 12:26:42 -0500, tim wrote: > Package: xserver-xorg-video-intel > Version: 2:2.21.15-2+b2 > Severity: normal > > Dear Maintainer, > > this problem affects multiple application. E.g. Empathy: > > Connecting to an account takes a while. The process is visualized by two > circulating symbols in the empathy window. The normal behaviour should be > that these symbols integrate well in the background of the window. But > instead of this they have a little black square background. > > Sorry, I can't give a more detailed description of the bug and will send a > picture after recieve the bug number. > Is this reproducible with the intel driver from experimental? Cheers, Julien signature.asc Description: Digital signature
Bug#778991: xserver-xorg-video-intel: graphical glitches in the circulating symbol while waiting for an application
Package: xserver-xorg-video-intel Version: 2:2.21.15-2+b2 Severity: normal Dear Maintainer, this problem affects multiple application. E.g. Empathy: Connecting to an account takes a while. The process is visualized by two circulating symbols in the empathy window. The normal behaviour should be that these symbols integrate well in the background of the window. But instead of this they have a little black square background. Sorry, I can't give a more detailed description of the bug and will send a picture after recieve the bug number. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Feb 21 15:37 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 2401376 Feb 10 19:35 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) /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 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) Xorg X server log files on system: -- -rw-r--r-- 1 root root 33205 Feb 22 11:57 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [44.723] X.Org X Server 1.16.4 Release Date: 2014-12-20 [44.723] X Protocol Version 11, Revision 0 [44.723] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian [44.723] Current Operating System: Linux mobybit 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 [44.723] Kernel command line: BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/mobybit--vg-root ro quiet [44.723] Build Date: 11 February 2015 12:32:02AM [44.723] xorg-server 2:1.16.4-1 (http://www.debian.org/support) [44.723] Current version of pixman: 0.32.6 [44.723]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [44.723] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [44.723] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Feb 22 10:43:12 2015 [44.724] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [44.725] (==) No Layout section. Using the first Screen section. [44.725] (==) No screen section available. Using defaults. [44.725] (**) |-->Screen "Default Screen Section" (0) [44.725] (**) | |-->Monitor "" [44.725] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [44.725] (==) Automatically adding devices [44.725] (==) Automatically enabling devices [44.725] (==) Automatically adding GPU devices [44.726] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [44.726]Entry deleted from font path. [44.726] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist. [44.726]Entry deleted from font path. [44.726] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist. [44.726]Entry deleted from font path. [44.726] (WW) The directory "/usr/share/fonts/X11/Type1" does not exist. [44.726]Entry deleted from font path. [44.726] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist. [44.726]Entry deleted from font path. [44.726] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist. [44.726]Entry deleted from font path. [44.726] (==) FontPath set to: /usr/share/fonts/X11/misc, built-ins [44.726] (==) ModulePath set to "/usr/lib/xorg/modules" [44.726] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [44.726] (II) Loader magic: 0x7f1c9237bd80 [44.726] (II) Module ABI versions: [44.726]X.Org ANSI C Emulation: 0.4 [44.726]X.Org Video Driver: 18.0 [44.726]X.Org XInput driver : 21.0 [44.726]X.Org Server Extension : 8.0 [44.727] (II) xfree86: Adding drm device (/dev/dri/card0) [44.728] (--) PCI:*(0:0:2:0) 8086:0166:17aa:21fa rev 9, Mem @ 0xf000/4194304, 0xe000/268435456, I/O @ 0x5000/64 [44.728] (II) LoadModule: "glx" [44.729] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [44.737] (II) Module glx: vendor="X.Org Foundation" [44.737]compiled for 1.16.4
Bug#767356: xserver-xorg-core: segfaults when starting on an AMD APU at glamor_set_screen_pixmap from within radeon_drv (Failed to create fbo, incomplete attachment)
On Wed, 24 Dec 2014 16:56:05 +0900 Michel Dänzer wrote: > Do you have libegl1-mesa-drivers installed? If yes, can you try if the > problem also occurs without it? It doesn't seem to make a difference. After downgrading libgbm1 back to 10.2.8-1, the problem occurs with or without libegl1-mesa-drivers_10.3.2 (and its dependency libopenvg1-mesa_10.3.2). After upgrading libgbm1 back to 10.3.2-1, X11 works with or without libegl1-mesa-drivers. -- 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/549a8744.5080...@.org
Bug#767356: xserver-xorg-core: segfaults when starting on an AMD APU at glamor_set_screen_pixmap from within radeon_drv (Failed to create fbo, incomplete attachment)
On 12.12.2014 17:48, Wim Lewis wrote: > Package: xserver-xorg-core > Version: 2:1.16.2.901-1 > Followup-For: Bug #767356 > > Dear Maintainer, > > Xorg segfaults with a backtrace at startup on my AMD desktop with > integrated (Radeon KAVERI) graphics. This looks like the same problem > as Yaroslav Halchenko's report in bug #767356. I've attached a more > detailed backtrace. I had this problem in 1.16.1.901 in testing, > upgraded to 1.16.2.901 from unstable, no apparent change. > > There is discussion of what looks like the same bug at: >https://www.libreoffice.org/bugzilla/show_bug.cgi?id=84186 As you found out there, upgrading libgbm1 to 10.3.y helped. Do you have libegl1-mesa-drivers installed? If yes, can you try if the problem also occurs without it? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -- 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/549a7195.4080...@daenzer.net
Bug#773684: Not specific to Hugin; happens only when an external display is connected
Hi again, I have another piece of (hopefully useful) information: 1) I was apparently not using the "right applications"; I just found out that launching basically any 3D application causes xserver to crash instantly. Easily reproduced e.g. by launching glxgears. 2) Also, I found out that it happens ONLY if I have an external display connected (via HDMI, the laptop has no other reasonable outputs available). The external display is set up by: xrandr --output HDMI1 -r 85 --mode 1024x768 --right-of eDP1 . Best regards, Martin -- 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/5499d529.6050...@gmail.com
Bug#767356: xserver-xorg-core: segfaults when starting on an AMD APU at glamor_set_screen_pixmap from within radeon_drv (Failed to create fbo, incomplete attachment)
On 12.12.2014 17:48, Wim Lewis wrote: > Package: xserver-xorg-core > Version: 2:1.16.2.901-1 > Followup-For: Bug #767356 > > Dear Maintainer, > > Xorg segfaults with a backtrace at startup on my AMD desktop with > integrated (Radeon KAVERI) graphics. This looks like the same problem > as Yaroslav Halchenko's report in bug #767356. I've attached a more > detailed backtrace. I had this problem in 1.16.1.901 in testing, > upgraded to 1.16.2.901 from unstable, no apparent change. > > There is discussion of what looks like the same bug at: >https://www.libreoffice.org/bugzilla/show_bug.cgi?id=84186 Let's continue there. I just added a suggestion for getting more information. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -- 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/548ff819.8020...@daenzer.net
Bug#767356: xserver-xorg-core: segfaults when starting on an AMD APU at glamor_set_screen_pixmap from within radeon_drv (Failed to create fbo, incomplete attachment)
Package: xserver-xorg-core
Version: 2:1.16.2.901-1
Followup-For: Bug #767356
Dear Maintainer,
Xorg segfaults with a backtrace at startup on my AMD desktop with
integrated (Radeon KAVERI) graphics. This looks like the same problem
as Yaroslav Halchenko's report in bug #767356. I've attached a more
detailed backtrace. I had this problem in 1.16.1.901 in testing,
upgraded to 1.16.2.901 from unstable, no apparent change.
There is discussion of what looks like the same bug at:
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=84186
The crash happens in glamor_set_screen_pixmap() because pixmap_priv->base.fbo is
NULL, but (as the comments in the libreoffice bug mention) the real problem
is presumably earlier when it can't create the FBO. Here's a gdb session with
some extra debugging env vars turned on:
Reading symbols from /usr/bin/Xorg...Reading symbols from
/usr/lib/debug//usr/bin/Xorg...done.
done.
(gdb) set env GLAMOR_DEBUG=1
(gdb) set env EGL_LOG_LEVEL=debug
(gdb) run -keeptty
Starting program: /usr/bin/Xorg -keeptty
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
X.Org X Server 1.16.1.901 (1.16.2 RC 1)
Release Date: 2014-11-02
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.2.0-4-amd64 x86_64 Debian
Current Operating System: Linux underwood 3.16.0-4-amd64 #1 SMP Debian 3.16.7-2
(2014-11-06) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64
root=UUID=5fdbbdbd-c492-4d83-9452-7b8441374d18 ro quiet
Build Date: 03 November 2014 09:44:08PM
xorg-server 2:1.16.1.901-1 (http://www.debian.org/support)
Current version of pixman: 0.32.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Dec 11 15:44:53 2014
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(II) [KMS] Kernel modesetting enabled.
[New Thread 0x7fffed1ef700 (LWP 4694)]
libEGL debug: Native platform type: drm (autodetected)
libEGL debug: EGL search path is /usr/lib/x86_64-linux-gnu/egl
libEGL debug: added /usr/lib/x86_64-linux-gnu/egl/egl_gallium.so to module array
libEGL debug: added egl_dri2 to module array
libEGL debug: dlopen(/usr/lib/x86_64-linux-gnu/egl/egl_gallium.so)
libEGL info: use DRM for display 0x559dd4a0
libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize(no
usable display)
libEGL debug: the best driver is DRI2
glamor_pixmap_ensure_fb: glamor: Failed to create fbo,
incomplete attachment
glamor_pixmap_ensure_fb: glamor: Failed to create fbo,
incomplete attachment
XXX fail to create fbo.
Program received signal SIGSEGV, Segmentation fault.
0x713883b0 in glamor_set_screen_pixmap
(screen_pixmap=screen_pixmap@entry=0x561f88d0, back_pixmap=0x0) at
../../glamor/glamor.c:122
122../../glamor/glamor.c: No such file or directory.
(gdb) bt
#0 0x713883b0 in glamor_set_screen_pixmap
(screen_pixmap=screen_pixmap@entry=0x561f88d0, back_pixmap=0x0) at
../../glamor/glamor.c:122
#1 0x71385060 in glamor_egl_create_textured_screen
(screen=screen@entry=0x559d77f0, handle=handle@entry=49,
stride=stride@entry=10240)
at ../../../../glamor/glamor_egl.c:239
#2 0x7138513d in glamor_egl_create_textured_screen_ext
(screen=screen@entry=0x559d77f0, handle=49, stride=10240,
back_pixmap=back_pixmap@entry=0x0)
at ../../../../glamor/glamor_egl.c:254
#3 0x7204048c in radeon_glamor_create_screen_resources
(screen=screen@entry=0x559d77f0) at ../../src/radeon_glamor.c:67
#4 0x72038e0a in RADEONCreateScreenResources_KMS
(pScreen=0x559d77f0) at ../../src/radeon_kms.c:258
#5 0x5561fc4e in xf86CrtcCreateScreenResources (screen=0x559d77f0)
at ../../../../hw/xfree86/modes/xf86Crtc.c:709
#6 0x555aef36 in dix_main (argc=2, argv=0x7fffe658,
envp=) at ../../dix/main.c:223
#7 0x75d16b45 in __libc_start_main (main=0x555994e0 ,
argc=2, argv=0x7fffe658, init=, fini=,
rtld_fini=, stack_end=0x7fffe648) at libc-start.c:287
#8 0x5559950e in _start ()
(gdb) inf loc
pixmap_priv = 0x5622f6f0
(gdb) p *pixmap_priv
$1 = {{type = GLAMOR_TEXTURE_DRM, base = {type = GLAMOR_TEXTURE_DRM, gl_fbo =
GLAMOR_FBO_UNATTACHED, map_access = GLAMOR_ACCESS_RO, is_picture = 0 '\000',
gl_tex = 0 '\000', fbo = 0x0, pixmap = 0x561f88d0, box = {x1 = 0, y1
= 0, x2 = 2560, y2 = 1440}, drm_stride = 0, glamor_priv = 0x55a1cc40,
picture = 0x0, image = 0x5622de30}, large = {{type =
GLAMOR_TEXTURE_DRM, base = {type = GLAMOR_TEXTURE_DRM, gl_fbo =
GLAMOR_FBO_UNATTACHED,
map_access = GLAMOR_ACCESS_RO, is_pictur
Bug#761398: Fw: An IBM message from Andreas Glaeser
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Begin forwarded message: Date: Tue, 25 Nov 2014 10:15:29 -0500 From: "Andreas Glaeser" To: "Andreas Glaeser" Subject: An IBM message from Andreas Glaeser Dear Andreas Glaeser, IBM is sending this e-mail message to you at my request. I thought you would find the content referenced on the IBM web page below of interest: Enable multiuser logins with VNC Note: The links within this e-mail message will expire in 90 days. Links to password-protected or dynamic content may not operate. IBM is committed to protecting your privacy. You may view IBM's privacy policy at: http://www.ibm.com/privacy/us/en/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlR1gToACgkQ5+rBHyUt5wtj7wCffwFSSc58fLYs3LeUk+/UccFN cDEAoIyDjwtGOeFK2CODJnwcfeAO7/nr =GoDj -END PGP SIGNATURE-
Bug#767356: Acknowledgement (X.Org segfaults when starting on an Intel+Radeon laptop at glamor_set_screen_pixmap from within radeon_drv)
FWIW dirty workaround was to diver radeon_drv.so , restart gdm3 so it fails to find it, remove diversion, restart gdm3 and it managed to start fine (well -- now I got a stuck mouse's cursor pointer copy in the middle of the screen for some reason, but that is the least of my problems atm) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20141030130115.ga30...@onerussian.com
Bug#767356: X.Org segfaults when starting on an Intel+Radeon laptop at glamor_set_screen_pixmap from within radeon_drv
Package: xserver-xorg-core Version: 2:1.16.1-1 Severity: important I have got hp zbook 14 with has Intel IGP + Radeon GPU. In pursue of enabling access to the display ports on the docking station installed 3.17 kernel and fresh intel driver. With xrandr --setprovideroffloadsink radeon Intel xrandr --setprovideroutputsource radeon Intel made those display ports visible but they showed just gray, and when I switched one of them back to onboard display port, the other one on docking station started to show some garbled image (just colored stripes/dots). Then when I turned it off (in gnome3 display settings), the entire X crashed. I have by now rebooted few times but every time Xorg just segfaults upon boot, so some stale settings bring it into the mysery and I can't even use it (besides logging in like now via ssh). Any recipe for help/remedy would be welcomed It seems to differ from the similar case https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761445 Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) Backtrace: Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) 0: /usr/bin/Xorg (xorg_backtrace+0x56) [0x7f24f4c08ab6] Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) 1: /usr/bin/Xorg (0x7f24f4a53000+0x1b9c99) [0x7f24f4c0cc99] Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (0x7f24f2748000+0x350f0) [0x7f24f277d0f0] Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) 3: /usr/lib/xorg/modules/libglamoregl.so (glamor_set_screen_pixmap+0x60) [0x7f24ecfc23b0] Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) 4: /usr/lib/xorg/modules/libglamoregl.so (glamor_egl_create_textured_screen+0xa0) [0x7f24ecfbf060] Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) 5: /usr/lib/xorg/modules/libglamoregl.so (glamor_egl_create_textured_screen_ext+0x3d) [0x7f24ecfbf13d] Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) 6: /usr/lib/xorg/modules/drivers/radeon_drv.so (0x7f24ee42f000+0x4c48c) [0x7f24ee47b48c] Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) 7: /usr/lib/xorg/modules/drivers/radeon_drv.so (0x7f24ee42f000+0x44e0a) [0x7f24ee473e0a] Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) 8: /usr/bin/Xorg (0x7f24f4a53000+0xcbbfe) [0x7f24f4b1ebfe] Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) 9: /usr/bin/Xorg (0x7f24f4a53000+0x5aed4) [0x7f24f4aaded4] Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) 10: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf5) [0x7f24f2769b45] Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) 11: /usr/bin/Xorg (0x7f24f4a53000+0x4550e) [0x7f24f4a9850e] Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) Segmentation fault at address 0x1c Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: Fatal server error: Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) Caught signal 11 (Segmentation fault). Server aborting Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: Please consult the The X.Org Foundation support Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: at http://wiki.x.org Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: for help. Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) Please also check the log file at "/dev/null" for additional information. Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (EE) Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: (II) AIGLX: Suspending AIGLX clients for VT switch Oct 30 08:32:38 hopa gdm-Xorg-:5[1495]: Xorg: intel_device.c:752: intel_put_master: Assertion `dev->master_count' failed. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Oct 19 23:12 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 2397280 Sep 22 17:49 /usr/bin/Xorg Diversions concerning libGL are in place diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/arm-linux-
Bug#758094: using an x32 X server considered harmful, for now
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#761445: Acknowledgement (xserver-xorg-core: X.Org segfaults when starting KDE on an Intel+Radeon laptop)
The same error occurs when starting XFCE... Probably it's not related to a specific DE... -- With best regards, Vitaliy Filippov -- 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/op.xl5atvf20ncgu9@vitalif.vhome
Bug#761445: xserver-xorg-core: X.Org segfaults when starting KDE on an Intel+Radeon laptop
Package: xserver-xorg-core Version: 2:1.16.0-2+b1 Severity: important Dear Maintainer, On my laptop with 2 graphics cards (integrated Intel + discrete Radeon 8770M) X.Org crashes in the very beginning of KDE startup. I.e I enter my login and password in KDM or in lightdm, the KDE splashscreen shows up, and X crashes right after showing the first icon on KDE splashscreen. This is caused by a null-pointer dereference in libpciaccess0, but I'm not sure if it's libpciaccess or X.org bug... pci_sys is NULL, does that mean libpciaccess failed to do something or X.org failed to correctly initialise libpciaccess? Stack trace: Program received signal SIGSEGV, Segmentation fault. 0x7fbc716b197c in pci_device_vgaarb_set_target (dev=0x0) at ../../src/common_vgaarb.c:230 230 dev = pci_sys->vga_default_dev; (gdb) bt #0 0x7fbc716b197c in pci_device_vgaarb_set_target (dev=0x0) at ../../src/common_vgaarb.c:230 #1 0x7fbc724ad700 in xf86VGAarbiterLock (pScrn=pScrn@entry=0x7fbc72b09af0) at ../../../../hw/xfree86/common/xf86VGAarbiter.c:92 #2 0x7fbc7248ac30 in DPMSSetScreen (pScrn=0x7fbc72b09af0, level=0) at ../../../../hw/xfree86/common/xf86DPMS.c:141 #3 0x7fbc7248af26 in DPMSSet (client=, level=level@entry=0) at ../../../../hw/xfree86/common/xf86DPMS.c:176 #4 0x7fbc72505a6b in ProcDPMSDisable (client=) at ../../Xext/dpms.c:159 #5 ProcDPMSDispatch (client=) at ../../Xext/dpms.c:227 #6 0x7fbc7244cf07 in Dispatch () at ../../dix/dispatch.c:432 #7 0x7fbc72451096 in dix_main (argc=10, argv=0x7fff6e319c88, envp=) at ../../dix/main.c:296 #8 0x7fbc7010ab45 in __libc_start_main (main=0x7fbc7243b4e0 , argc=10, argv=0x7fff6e319c88, init=, fini=, rtld_fini=, stack_end=0x7fff6e319c78) at libc-start.c:287 #9 0x7fbc7243b50e in _start () -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Jun 28 03:05 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 2397280 Sep 9 05:37 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) /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 3.16-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-10) ) #1 SMP Debian 3.16.2-3 (2014-09-13) Xorg X server log files on system: -- -rw-r--r-- 1 root root 40311 Sep 13 23:34 /var/log/Xorg.1.log -rw-r--r-- 1 root root 48260 Sep 14 01:30 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [ 5147.212] X.Org X Server 1.16.0 Release Date: 2014-07-16 [ 5147.212] X Protocol Version 11, Revision 0 [ 5147.212] Build Operating System: Linux 3.2.0-4-amd64 x86_64 Debian [ 5147.212] Current Operating System: Linux gnusmas 3.16-1-amd64 #1 SMP Debian 3.16.2-3 (2014-09-13) x86_64 [ 5147.212] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16-1-amd64 root=UUID=05ec9def-2023-4ba6-ba0e-44c396a986c4 ro [ 5147.212] Build Date: 09 September 2014 01:34:43AM [ 5147.212] xorg-server 2:1.16.0-2+b1 (http://www.debian.org/support) [ 5147.212] Current version of pixman: 0.32.6 [ 5147.212]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 5147.212] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 5147.212] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Sep 14 01:29:07 2014 [ 5147.212] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 5147.212] (==) No Layout section. Using the first Screen section. [ 5147.212] (==) No screen section available. Using defaults. [ 5147.212] (**) |-->Screen "Default Screen Section" (0) [ 5147.212] (**) | |-->Monitor "" [ 5147.212] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 5147.212] (==) Automatically adding devices [ 5147.212] (==) Automatically enabling devices [ 5147.212] (==) Automatically adding GPU devices [ 5147.212] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 5147.212]Entry deleted from font path. [ 5147.212] (==) 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 [ 5147.212] (==) ModulePath set to "/usr/lib/xorg/modules" [ 5147.212] (II) The server relies on udev to provide th
Bug#755809: xorg.conf.5 man page mentions an incorrect "Enable" option for Monitors
Julien Cristau, 2014-07-28 23:56+0200: Note how the manpage says "enable all connected monitors", not "enable all monitors". Right, that was subtle but useful indeed. Here is an updated patch then. -- ,--. : /` ) ن Tanguy Ortolo | `-'Debian Developer \_ Description: Complete the xorg.conf.5 manpage with Option "Disable" The xorg.conf.5 manpage mentions an "Enable" option to enable a monitor regardless of whether or not it is connected, but gives no indication of how to disable it. This patch corrects that by documenting the "Disable" option. Author: Tanguy Ortolo Last-Update: 2014-07-29 --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ Index: xorg-server/hw/xfree86/man/xorg.conf.man === --- xorg-server.orig/hw/xfree86/man/xorg.conf.man +++ xorg-server/hw/xfree86/man/xorg.conf.man @@ -1812,6 +1812,12 @@ at startup. By default, the server will monitors. (RandR 1.2-supporting drivers only) .TP 7 +.BI "Option \*qDisable\*q \*q" bool \*q +This optional entry specifies whether the monitor should be turned off +at startup. By default, the server will attempt to enable all connected +monitors. +(RandR 1.2-supporting drivers only) +.TP 7 .BI "Option \*qDefaultModes\*q \*q" bool \*q This optional entry specifies whether the server should add supported default modes to the list of modes offered on this monitor. By default, the server signature.asc Description: Digital signature
Bug#755809: xorg.conf.5 man page mentions an incorrect "Enable" option for Monitors
On Mon, Jul 28, 2014 at 17:58:26 +0200, Tanguy Ortolo wrote: > Julien Cristau, 2014-07-28 16:47+0200: > >On Mon, Jul 28, 2014 at 16:35:06 +0200, Tanguy Ortolo wrote: > >>Is that useful at all, considering that a monitor is on by default at > >>startup? > >> > >>If needed, I can write a patch that documents both options, of course, but I > >>am not convinced that an option that does that same than the default > >>behaviour is useful. > > > >That's not the same as the default behaviour. > > Then what is the default behaviour? According to the manpage: > >Option "Enable" "bool" > > This optional entry specifies whether the monitor should be > > turned on at startup. By default, the server will attempt to > > enable all connected monitors. (RandR 1.2-supporting drivers > > only) > > If this is not the case, then this last sentence should be corrected as > well, which I can do in the same patch, only I am not sure of what the > default behaviour is then. > Note how the manpage says "enable all connected monitors", not "enable all monitors". Cheers, Julien signature.asc Description: Digital signature
Bug#755809: xorg.conf.5 man page mentions an incorrect "Enable" option for Monitors
Julien Cristau, 2014-07-28 16:47+0200: On Mon, Jul 28, 2014 at 16:35:06 +0200, Tanguy Ortolo wrote: Is that useful at all, considering that a monitor is on by default at startup? If needed, I can write a patch that documents both options, of course, but I am not convinced that an option that does that same than the default behaviour is useful. That's not the same as the default behaviour. Then what is the default behaviour? According to the manpage: Option "Enable" "bool" This optional entry specifies whether the monitor should be turned on at startup. By default, the server will attempt to enable all connected monitors. (RandR 1.2-supporting drivers only) If this is not the case, then this last sentence should be corrected as well, which I can do in the same patch, only I am not sure of what the default behaviour is then. -- ,--. : /` ) ن Tanguy Ortolo | `-'Debian Developer \_ signature.asc Description: Digital signature
Bug#755809: xorg.conf.5 man page mentions an incorrect "Enable" option for Monitors
On Mon, Jul 28, 2014 at 16:35:06 +0200, Tanguy Ortolo wrote: > Julien Cristau, 2014-07-27 14:11+0200: > >The "enable" option forces a monitor on. > > Is that useful at all, considering that a monitor is on by default at > startup? > > If needed, I can write a patch that documents both options, of course, but I > am not convinced that an option that does that same than the default > behaviour is useful. That's not the same as the default behaviour. Cheers, Julien signature.asc Description: Digital signature
Bug#755809: xorg.conf.5 man page mentions an incorrect "Enable" option for Monitors
Julien Cristau, 2014-07-27 14:11+0200: The "enable" option forces a monitor on. Is that useful at all, considering that a monitor is on by default at startup? If needed, I can write a patch that documents both options, of course, but I am not convinced that an option that does that same than the default behaviour is useful. signature.asc Description: Digital signature
Bug#755809: xorg.conf.5 man page mentions an incorrect "Enable" option for Monitors
On Fri, Jul 25, 2014 at 14:24:57 +0200, Tanguy Ortolo wrote: > Julien Cristau, 2014-07-24 22:46+0200: > >I don't know what you think is incorrect about the existing text. > > The existing texts is about an option named “Enable”, which may or may not > exist, but does nothing and is thus useless to mention. The behaviour > expected from that option (disabling a monitor at server startup) is > achieved by using the option “Disable” which is not documented at all. > The "enable" option forces a monitor on. The "disable" option forces it off. Cheers, Julien signature.asc Description: Digital signature
