On Wed, Jun 20, 2018 at 05:44:22PM +0900, Mike Hommey wrote:
> Package: xwayland
> Version: 2:1.20.0-2
> Followup-For: Bug #901883
>
> Dear Maintainer,
>
> I am able to reproduce this reliably with Firefox from experimental by
> going to
> http://example.qt.io/qt-w
Package: xwayland
Version: 2:1.20.0-2
Followup-For: Bug #901883
Dear Maintainer,
I am able to reproduce this reliably with Firefox from experimental by
going to
http://example.qt.io/qt-webassembly/widgets/richtext/textedit/textedit.html
Attaching gdb to Xwayland shows the same information as
Hi,
Do you mind if I upload backports of pixman and cairo to
squeeze-backports?
Cheers,
Mike
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
On Mon, Aug 15, 2011 at 12:33:17PM +0200, Cyril Brulebois wrote:
Mike Hommey m...@glandium.org (15/08/2011):
Do you mind if I upload backports of pixman and cairo to
squeeze-backports?
Not at all. Feel free to push pixman's packaging in a branch
(debian-squeeze-backports) in our git
pixman-0.22.0/debian/changelog
--- pixman-0.22.0/debian/changelog
+++ pixman-0.22.0/debian/changelog
@@ -1,3 +1,10 @@
+pixman (0.22.0-1.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * debian/rules, debian/control, debian/*.install: Allow easy backport.
+
+ -- Mike Hommey gland
On Sun, Jan 30, 2011 at 06:10:36AM +0100, Cyril Brulebois wrote:
Hi Mike,
Mike Hommey mh+report...@glandium.org (25/03/2010):
Package: xvfb
Version: 2:1.7.5.902-1
Severity: normal
xulrunner reftests ended with 62 failures on s390, which are to be
attributed to xvfb rendering
On Sun, Aug 01, 2010 at 09:52:46PM -0700, John Aston au...@yahoo.com wrote:
I defer to the expert's judgment on where the bug belongs, but I will note
that I've only experienced the bug with Iceweasel, and no other programs.
I've taken the same image (locally saved) and opened it using
On Thu, Aug 28, 2008 at 07:25:19PM +0200, Julien Cristau wrote:
On Thu, Aug 28, 2008 at 19:21:06 +0200, Mike Hommey wrote:
On the other hand, switching to XAA made Xv stop working here. I hope
I'm alone in that case.
FWIW, xvinfo returns 2 adapters, the first being Intel(R) Textured
On Wed, Aug 27, 2008 at 07:38:38PM +0200, Julien Cristau wrote:
On Wed, Aug 27, 2008 at 19:25:17 +0200, Mike Hommey wrote:
[ Brice Goglin ]
* Add 02_xaa_by_default_on_i965.diff to switch back to XAA on
i965 by default to avoid many rendering problems, closes: #451791
On Thu, Aug 28, 2008 at 07:25:19PM +0200, Julien Cristau wrote:
On Thu, Aug 28, 2008 at 19:21:06 +0200, Mike Hommey wrote:
On the other hand, switching to XAA made Xv stop working here. I hope
I'm alone in that case.
FWIW, xvinfo returns 2 adapters, the first being Intel(R) Textured
On Thu, Aug 28, 2008 at 09:16:15PM +0200, Brice Goglin wrote:
Mike Hommey wrote:
Argh, right, Xv on XAA is fail. None of the adapters work?
I'd try them all if i knew how to...
xvinfo gives you the port base and number of ports for each adapter.
Then you can try something
[ Brice Goglin ]
* Add 02_xaa_by_default_on_i965.diff to switch back to XAA on
i965 by default to avoid many rendering problems, closes: #451791.
Interestingly, I've never been hit by these rendering problems with EXA,
but I don't exactly have a 965G, but a 965GM. But the switch
On Thu, Jun 12, 2008 at 02:53:36PM +0200, Josselin Mouette [EMAIL PROTECTED]
wrote:
reassign 485939 xserver-xorg-core
thanks
Le jeudi 12 juin 2008 à 14:08 +0200, Fabian Greffrath a écrit :
Package: epiphany-browser
Version: 2.22.2-2
Severity: normal
Dear Epiphany-maintainers,
Package: compiz-core
Version: 0.7.4-1
Severity: important
File: /usr/bin/compiz
I unfortunately partially upgraded compiz, and left libcompizconfig0 at
the previous version:
ii libcompizconfig0 0.6.0-3
This led to this error message (and compiz failure to start):
/usr/bin/compiz.real
On Sat, May 24, 2008 at 10:14:58AM +0200, Mike Hommey wrote:
Package: compiz-core
Version: 0.7.4-1
Severity: important
File: /usr/bin/compiz
I unfortunately partially upgraded compiz, and left libcompizconfig0 at
the previous version:
ii libcompizconfig0 0.6.0-3
This led
On Mon, Apr 07, 2008 at 10:45:31AM +0200, Evgeni Golov [EMAIL PROTECTED]
wrote:
On Sat, 05 Apr 2008 17:16:29 +0200 Krzysztof Sobolewski wrote:
Mike Hommey pisze:
This occurs in xserver-xorg-video-intel from both sid and experimental,
but this is the only program that has
On Tue, Apr 01, 2008 at 12:18:29AM +0200, Brice Goglin wrote:
forwarded 473551 https://bugs.freedesktop.org/show_bug.cgi?id=15294
thank you
On Mon, Mar 31, 2008 at 11:56:28PM +0200, Mike Hommey wrote:
Here is a stacktrace I was able to get after setting
Option NoTrapSignals
Package: libgl1-mesa-dri
Version: 7.0.3~rc2-1
Severity: important
I don't really know if this belongs here, but the stacktrace in the
crashed X server logs seem to indicate that somehow i965_dri.so might be
responsible for this crash.
The stacktrace is the following:
Backtrace:
0:
On Mon, Mar 31, 2008 at 12:17:20PM +0200, Mike Hommey wrote:
wine Steam.exe steam://hardwarepromo/609. Click a few times on Next,
and *bam*.
Actually, you don't even need to click a few times, it crashes as soon
as you launch the command.
Mike
--
To UNSUBSCRIBE, email to [EMAIL
On Mon, Mar 31, 2008 at 12:55:52PM +0200, Julien Cristau wrote:
On Mon, Mar 31, 2008 at 12:17:20 +0200, Mike Hommey wrote:
Package: libgl1-mesa-dri
Version: 7.0.3~rc2-1
Severity: important
I don't really know if this belongs here, but the stacktrace in the
crashed X server logs
On Mon, Mar 31, 2008 at 12:55:52PM +0200, Julien Cristau wrote:
On Mon, Mar 31, 2008 at 12:17:20 +0200, Mike Hommey wrote:
Package: libgl1-mesa-dri
Version: 7.0.3~rc2-1
Severity: important
I don't really know if this belongs here, but the stacktrace in the
crashed X server logs
On Mon, Mar 31, 2008 at 11:49:06PM +0200, Mike Hommey wrote:
On Mon, Mar 31, 2008 at 12:55:52PM +0200, Julien Cristau wrote:
On Mon, Mar 31, 2008 at 12:17:20 +0200, Mike Hommey wrote:
Package: libgl1-mesa-dri
Version: 7.0.3~rc2-1
Severity: important
I don't really know
On Wed, Feb 06, 2008 at 07:49:55PM +0100, Brice Goglin wrote:
Mike Hommey wrote:
Package: xserver-xorg-video-intel
Version: 2:2.2.0+git20080107-1
Severity: normal
By default, on my laptop, the kernel BACKLIGHT_CONTROL is used, and
that doesn't quite help xbacklight to work. I don't
Package: xserver-xorg-video-intel
Version: 2:2.2.0+git20080107-1
Severity: normal
By default, on my laptop, the kernel BACKLIGHT_CONTROL is used, and
that doesn't quite help xbacklight to work. I don't know what X uses in
such a case, but it appears that tweaking
Followup-For: Bug #442892
Package: xserver-xorg
Version: 1:7.3+9
FWIW, I got the same thing again when installing a brand new debian system,
first installing the base system, then xserver-xorg with
APT::Install-Recommends set to false.
This sadly results in an empty xorg.conf, which makes the
Package: xserver-xorg
Version: 1:7.3+2
Severity: important
Hi,
I recently upgraded my x.org server in sid, and, after upgrade, the X
server would not work. But this is another issue I will try to
understand at another time.
Anyways, the thing is, since my conf was not working, I wanted to try
found 280579 1.0~cvs.20070721-1
thanks
On Sat, Jul 21, 2007 at 07:39:03PM +, Debian Bug Tracking System [EMAIL
PROTECTED] wrote:
This is an automatic notification regarding your Bug report
#280579: xlibs-data: [xkb] jp106 backslash/yen issue,
which was filed against the xkb-data package.
On Sun, Jun 17, 2007 at 08:20:44PM +0200, Brice Goglin [EMAIL PROTECTED]
wrote:
Hi,
About a year ago, you reported a bug to the Debian BTS regarding a wrong
keyboard being chosen for japanese keyboard. Did you reproduce this
problem recently? With Xorg/Etch? With latest Xorg packages in
Package: xserver-xorg
Version: 1:7.0.23
Severity: normal
I totally fail to enable EXA. I've tried
Option AccelMethod EXA,
Option AccelMethod exa,
with or without AGP stuff,
with or without the composite extension,
I *always* get the XAA method loaded, as stated by the Xorg.0.log.
Mike
--
reassign 367158 gdm
thanks
Hi,
First, I believe the bug belongs to gdm, so i'm reassigning.
The problem appears that when running a second X server by mean of gdm
(by asking a new login from the gnome desktop, for example), the gdm
login form in this second X server uses smaller fonts than the
Package: xserver-xorg
Version: 1:7.0.14
Severity: normal
/etc/X11/xorg.conf states:
# This file is automatically updated on xserver-xorg package upgrades
# *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it
Package: libxft-dev
Version: 2.1.8.2-5
Severity: serious
Followup-For: Bug #358578
I'm raising severity because it makes other packages FTBFS.
Due to the lack of the link, a whole lot of packages like firefox,
xulrunner and probably many others just FTBFS.
Please fix that quickly.
Thanks
Mike
Package: xserver-xorg
Version: 6.9.0.dfsg.1-4
Severity: normal
When at install time, the user selects the japanese keyboard, the
configuration is made as follows:
xserver-xorg/config/inputdevice/keyboard/options: jp106
xserver-xorg/config/inputdevice/keyboard/model: pc105
Unless the model is
On Wed, Nov 10, 2004 at 10:21:22PM +0100, Denis Barbier [EMAIL PROTECTED]
wrote:
On Wed, Nov 10, 2004 at 07:49:41PM +0900, Mike Hommey wrote:
[...]
Note that on the same keyboard, The windows key gives keycode 115
(keysym 0x0, NoSymbol), which i think is not expected. Shall I file a
new
On Sun, Feb 26, 2006 at 01:38:24PM +0100, Michel D?nzer [EMAIL PROTECTED]
wrote:
On Fri, 2006-02-24 at 19:11 +0100, Mike Hommey wrote:
I get the following message in my logs:
(II) Loading /usr/lib/xorg/modules/extensions/libGLcore.so
dlopen: /usr/lib/xorg/modules/extensions/libGLcore.so
Package: xserver-xorg
Version: 6.9.0.dfsg.1-4
Severity: normal
My screen is 1280x800 and the closer I could find in the video modes
selection was 1200x800, which I'm not exactly sure exists...
It would be greatly appreciated if 1280x800 was added ;)
-- Package-specific info:
Contents of
Package: xserver-xorg-core
Version: 1:1.0.1-1
Severity: normal
I get the following message in my logs:
(II) Loading /usr/lib/xorg/modules/extensions/libGLcore.so
dlopen: /usr/lib/xorg/modules/extensions/libGLcore.so: undefined symbol:
__glXLastContext
(EE) Failed to load
Package: xbase-clients
Version: 1:1.0.1-1
Severity: normal
Contrary to what is said in the package description, (at least) glxgears
is not present in the package.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Package: libxft-dev
Version: 2.1.8.2-1
Severity: critical
Justification: breaks unrelated software
The file /usr/lib/pkgconfig/xft.pc says xft requires xproto, which is
available in no package, as stated by apt-file.
Even if it existed, there should be a dependency to the dev package
holding it.
I don't know which bug you intended to close, but it's not this one...
Mike
On Tue, Jan 24, 2006 at 09:48:16AM -0800, Debian Bug Tracking System [EMAIL
PROTECTED] wrote:
This is an automatic notification regarding your Bug report
#349678: libxft-dev: pkg-config file says requires xproto that
On Fri, Jul 15, 2005 at 02:58:32PM +0300, Horms [EMAIL PROTECTED] wrote:
Package: xlibs
Version: 6.8.2.dfsg.1-2
Severity: important
Tags: patch
Hi,
After upgrading xlibs the backslash no longer works on
my Toshiba Dynabook with a japanese keyboard. This makes
coding really hard!
On Tue, Dec 07, 2004 at 11:24:55AM -0500, Michel Dänzer [EMAIL PROTECTED]
wrote:
With a 2.6 kernel, /dev/psaux is just an alias of /dev/input/mice. So
you have two input devices for the same thing (didn't you notice the
mouse being twice as fast as it should be? ;), but the button remapping
Package: xserver-xfree86
Version: 4.3.0.dfsg.1-8
Severity: normal
Tags: upstream
When trying to remap the mouse buttons with xmodmap, xinput or the gnome
mouse panel (left-handed setting), the mouse events get mixed up.
I used the following commands, all showing the same behaviour:
$ xmodmap -e
On Sun, Dec 05, 2004 at 09:19:25PM -0600, Billy Biggs [EMAIL PROTECTED] wrote:
The GNOME system has the nice property that it can be changed without
restarting X. Moving towards systems with this property is a good
thing. GNOME also advertises it in a vendor neutral way (XSETTINGS) and
On Mon, Dec 06, 2004 at 07:26:24AM +0100, Jean-Christophe Dubacq [EMAIL
PROTECTED] wrote:
However, Keith's computation is a bit hard: I tested 120 dpi with my
1600x1200 and already find those fonts are gigantic. I would not like
staying with 150.
Probably because you're using 12 or 13 points
On Mon, Dec 06, 2004 at 08:52:57AM +, Anders Karlsson [EMAIL PROTECTED]
wrote:
On Mon, 2004-12-06 at 16:20 +0900, Mike Hommey wrote:
On Sun, Dec 05, 2004 at 09:19:25PM -0600, Billy Biggs [EMAIL PROTECTED]
wrote:
The GNOME system has the nice property that it can be changed without
On Mon, Dec 06, 2004 at 12:58:30AM -0800, Keith Packard [EMAIL PROTECTED]
wrote:
Around 8 o'clock on Dec 6, Anders Karlsson wrote:
No, he said he wanted to make Xft applications default to 96 DPI.
Nothing stopping you from tweaking the Xft.dpi value to what you want it
to be.
So
On Mon, Dec 06, 2004 at 11:23:48AM +, Anders Karlsson [EMAIL PROTECTED]
wrote:
Well, yes and no. If you are a normal user, you would not have to tweak
anything. If you mess with printing/image manipulating a lot, then you
might have to tweak two sets of values, one to tell X what DPI the
On Mon, Dec 06, 2004 at 12:17:27PM +, Anders Karlsson [EMAIL PROTECTED]
wrote:
I still fail to see the advantage of having 2 settings of the same
thing, being the number of dots per inch.
Golden middle way then, if the X DPI is specified manually in the
XF86Config, the Xft.dpi gets
On Mon, Dec 06, 2004 at 08:26:38AM -0600, Billy Biggs [EMAIL PROTECTED] wrote:
1. Other operating systems do not use the screen's DPI when rendering
fonts. On Windows, there is a different function to determine the
real DPI of the display, separate from the DPI used in text
On Mon, Dec 06, 2004 at 09:38:06AM -0600, Billy Biggs [EMAIL PROTECTED] wrote:
[...]
I think that's fair enough, I mean, I think the font design problem is
somewhat intractable and therefore you'll never get great-looking text
at small pixel sizes, but we can happily diagree on this point.
I would not like to have my screen projected with 1/2 inch (or 1 cm or
whatever galactic leagues) letters high. In fact, I do not want to know
the dpi of my projector (which varies according to the distance between
it and the wall, anyway).
So I would have to lie about the DPI of my
On Mon, Dec 06, 2004 at 10:30:22AM -0600, Billy Biggs [EMAIL PROTECTED] wrote:
I think we agree on this. My opinion was that either every display
manager set the DPI in their config file (and that be the one place)
or its done elsewhere. Consensus seems to be to do it elsewhere.
Well, it
On Mon, Dec 06, 2004 at 12:55:20PM -0600, Billy Biggs [EMAIL PROTECTED] wrote:
- Font hints are not designed for small pixel sizes at arbitrary
DPIs. I have shown this via screenshots which I posted.
See Keith's answer
- GNOME defaults to a 10 point font for the application font. My
On Sun, Dec 05, 2004 at 08:55:17PM -0600, Billy Biggs [EMAIL PROTECTED] wrote:
I discussed this issue further and updated my proposal. Given that
many people do believe that a measure of the real DPI is a useful
thing to keep around, and that all font rendering systems seem to honour
the
On Mon, Nov 22, 2004 at 09:22:57PM +0100, Denis Barbier [EMAIL PROTECTED]
wrote:
http://people.debian.org/~barbier/xkb/xkb-4.3.0.dfsg.1-8+SVN.tar.bz2
Sorry about the delay, I confirm it works with the xkb tree from this
tarball, so I guess it will be fixed in 4.3.0.dfsg.1-9...
Thanks
Mike
On Sun, Nov 21, 2004 at 04:06:22PM +0100, Denis Barbier wrote:
On Sat, Nov 13, 2004 at 11:52:30AM +0900, Mike Hommey wrote:
[...]
[EMAIL PROTECTED]:/tmp$ wget
http://ftp.jp.debian.org/debian/pool/main/x/xfree86/xlibs_4.3.0.dfsg.1-8_all.deb
[EMAIL PROTECTED]:/tmp$ md5sum xlibs_4.3.0.dfsg.1
On Fri, Nov 12, 2004 at 10:09:48AM +0100, Denis Barbier wrote:
On Fri, Nov 12, 2004 at 11:08:02AM +0900, Mike Hommey wrote:
[...]
Just in case that would change some things, my keyboard is a laptop one
and the non working windows key is the left one (there is no right
windows key
On Fri, Nov 12, 2004 at 11:05:22AM +0100, Denis Barbier wrote:
On Fri, Nov 12, 2004 at 06:27:17PM +0900, Mike Hommey wrote:
BTW please run
$ xkbcomp :0
and send the 'server-0.xkb' file generated by this command.
Attached to this mail.
[...]
xkb_symbols jp+compose(menu
On Fri, Nov 12, 2004 at 09:35:50PM +0100, Denis Barbier wrote:
On Sat, Nov 13, 2004 at 01:54:50AM +0900, Mike Hommey wrote:
I haven't tested your fix yet, but what i can tell you is that my
/etc/X11/xkb/rules/xfree86 file is the exact same as the one in the
xlibs_4.3.0.dfsg.1-8_all.deb
On Fri, Nov 12, 2004 at 12:19:57AM +0100, Denis Barbier wrote:
tags 280696 + unreproducible
thanks
On Thu, Nov 11, 2004 at 11:42:15AM +0900, Mike Hommey wrote:
Package: xlibs-data
Version: 4.3.0.dfsg.1-8
On Wed, Nov 10, 2004 at 10:21:22PM +0100, Denis Barbier wrote:
On Wed, Nov 10
Package: xlibs-data
Version: 4.3.0.dfsg.1-8
Severity: minor
On a japanese keyboard, there is one key of the Yen sign, and one for
the backslash. While in EUC-JP and SHIFT-JIS encoding, Yen and backslash
are mapped to the same character, it is not the case in UTF-8.
Thus, i'd like the Yen key to
Package: xlibs-data
Version: 4.3.0.dfsg.1-8
On Wed, Nov 10, 2004 at 10:21:22PM +0100, Denis Barbier wrote:
On Wed, Nov 10, 2004 at 07:49:41PM +0900, Mike Hommey wrote:
[...]
Note that on the same keyboard, The windows key gives keycode 115
(keysym 0x0, NoSymbol), which i think
On Thu, Aug 26, 2004 at 10:13:10PM +0100, TJ wrote:
(...)
How to use compose?
well to get a ä (a umlaut)
press compose (right win)(and release, not hold) then press
(shift+2 on uk keyboards) then press a.
compose will combine the and a to give you ä
also: compose then s then s, gives you
On Thu, Aug 19, 2004 at 10:47:06AM +0200, Emmanuel Fleury wrote:
Hi,
I just write here a quick update of the bug to tell you the state of the
process.
(...)
I'm impressed with the amount of energy you've put into tracking this
bug, but you should have read history of the bugs merged with
Package: xlibs-data
Version: 4.3.0.dfsg.1-6
Severity: wishlist
Hi,
First, I'm not quite sure if the bug belongs to xlibs-data, so please
reassign if I am wrong.
All basic X applications using xlibs (tested with xedit and emacs)
fail to get composition sequences when using the ja_JP.UTF-8
On Wednesday January 28 2004 02:56, Branden Robinson wrote:
Do you ever run X at color depth 24?
xdpyinfo says so...
Mike
On Thursday November 13 2003 17:06, Daniel Stone wrote:
Yes. Splitting xlibs/xbase-clients, breaking the xlibs build out so you
can choose to use the freedesktop.org versions ... none of this is
particularly easy.
Speaking of which there will be a package naming issue at some point, since
the
On Wednesday October 29 2003 05:00, Branden Robinson wrote:
I'm sorry, but I do not think I can be of much assistance:
1) You have reached the Debian Project, not Lindows.com. You will need
to contact Lindows Customer Support for assistance with their products,
such as Lindows 4.
2) Please
On Monday 15 September 2003 00:37, Daniel Stone wrote:
You'll either need to use --force-overwrite, or get the pre1v1 packages.
... or dpkg-divert.
Mike
--
I have sampled every language, french is my favorite. Fantastic language,
especially to curse with. Nom de dieu de putain de bordel de
Is there a chance to see 1400x1050 resolution in debconf templates in upcoming
4.3.0 packages ?
Regards
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Is there a chance to see 1400x1050 resolution in debconf templates in upcoming
4.3.0 packages ?
Regards
Mike
72 matches
Mail list logo
