Bug#870836: imake generated makefile use deprecated -D_BSD_SOURCE and -D_SVID_SOURCE
On Sat, Nov 24, 2018 at 02:02:58PM -0800, Bart Massey wrote: >Hilariously, I just ran into this today when building a program I wrote in >1987. Thanks huge to Teemu for working out the patch; I have verified that it >works for me. It would be great if this could be packaged. Still seeing this over 5 years later. Is there any reason not to do an upload with the patch here? -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Bug#287876: Bug#276545: Bug#287876: File $HOME/.xsession-errors grows very large
Wow, this is an old bug that seemingly got forgotten about! I've just added locally a change to at least rotate the .xsession-errors file at startup, to stop me wasting gigabytes of disk on errors that I don't care about long-term: diff --git a/X11/Xsession b/X11/Xsession index 6ad7d6e..8302900 100755 --- a/X11/Xsession +++ b/X11/Xsession @@ -60,6 +60,10 @@ USERXSESSIONRC=$HOME/.xsessionrc ALTUSERXSESSION=$HOME/.Xsession ERRFILE=$HOME/.xsession-errors +if [ -f "$ERRFILE" ] && [ ! -L "$ERRFILE" ]; then +mv -f "$ERRFILE" "$ERRFILE".old +fi + # attempt to create an error file; abort if we cannot if (umask 077 && touch "$ERRFILE") 2> /dev/null && [ -w "$ERRFILE" ] && [ ! -L "$ERRFILE" ]; then -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
Bug#902437: xwayland: Firefox crashes Wayland on some web pages
On Tue, Jun 26, 2018 at 08:50:10PM +0300, Lars Wirzenius wrote: >Package: xwayland >Version: 2:1.20.0-2 >Severity: important > >Dear Maintainer, > >My apologies for ruining your day with what looks like a tricky driver >bug. I hate debugging such things, myself. > >I'm marking this "important", because the issue makes me not dare to >browse the web: I've had to reboot my system several times a day >lately. If you think it should be a lower severity, please downgrade. > >Also, I made a wild guess at which package to report this issue >against, and I am so utterly, comically ignorant of everything in a >modern Debian desktop system that I may have guessed wrongly; please >reassign if so. > >I run Debian sid on two different laptops: a Lenovo Thinkpad X220, and >a Lenovo Yoga 900. Both use an Intel graphics card or chip. For the >past week or two, the X220 has been crashing from time to time. I >thought it might be bad memory in the laptop, so I switched to the >Yoga. Then the Yoga started crashing. > >After much headbanging and wailing, I've manged to find way to >reproduce the crash. I use Firefox as my web browser, and certain web >pages trigger the crash reproducibly. One such web page is here: > >http://johannesbrodwall.com/2018/06/24/forget-about-clean-code-lets-embrace-compassionate-code/ > >What happens is that Firefox does not render that page, only updates >the page title in the window title, and then becomes unresponsive. >Menus don't react in anyway. i can't close the tab or window with >Ctrl-W, or by clicking on the window close button. After a few more >seconds, the whole desktop stops working, meaning that pressing the >capslock key no longer toggles the LED. The mouse cursor may or may >not work. If it does work, moving it to the top left corner of the >GNOME desktop makes the mouse not work anymore. Also, the desktop does >not do the "whoosh" feature of GNOME where it shows all windows on the >current virtual desktop, and the "dock" on the left side of the >screen. > >The machine seems to work otherwise: I can log into it via ssh, and >run commands on the command line. I can restart gdm3 from the ssh >session, but if I log back in, it doesn't work: I get a dark grey >screen, no windows, and nothing else for about half a minute, and then >it's back to the gdm3 login screen. Logging in as a different user >seems to work. > >There's nothing new in dmesg output, when the crash happens. I've run >the in-kernel memtest on the Yoga, and it resports no problems. (I've >not bothered to run it on the X220 yet. I can, if it'd be helpful to >you.) > >I reconfigured gdm3 on the Yoga to start Xorg instead of Wayland, and >now the web page above works fine in Firefox. No crash.. The webpage >renders fine under Wayland using Chromium. > >I am OK with this workaround, but I assume the bug should be fixed if >Wayland is to be the default in Debian. The problem is reproducible >for me. If others can reproduce it, it should be doable on any X220, >which is, or used to be, a common laptop. I will be keeping mine >in storage for a while, so that if there's a need, I can try new >package versions to see if they fix the problem. > >Happy hunting. > > > >-- System Information: >Debian Release: buster/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'stable') >Architecture: amd64 (x86_64) > >Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) >Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), >LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) >Shell: /bin/sh linked to /bin/dash >Init: systemd (via /run/systemd/system) > >Versions of packages xwayland depends on: >ii libaudit1 1:2.8.3-1 >ii libbsd0 0.9.1-1 >ii libc6 2.27-3 >ii libdrm2 2.4.92-1 >ii libegl1 1.0.0+git20180308-3 >ii libepoxy0 1.4.3-1 >ii libgbm1 18.1.2-1 >ii libgcrypt20 1.8.3-1 >ii libgl1 1.0.0+git20180308-3 >ii libpixman-1-0 0.34.0-2 >ii libselinux1 2.8-1 >ii libsystemd0 239-1 >ii libwayland-client0 1.15.0-2 >ii libxau6 1:1.0.8-1+b2 >ii libxdmcp6 1:1.1.2-3 >ii libxfont2 1:2.0.3-1 >ii libxshmfence1 1.3-1 >ii xserver-common 2:1.20.0-2 Confirmed here on a fresh install of sid on another X220... -- Steve
Bug#783705: xserver-xorg-video-radeon: Weird X wakeup problem since Jessie upgrade
On Tue, May 05, 2015 at 01:55:16PM +0200, Julien Cristau wrote: >On Tue, May 5, 2015 at 12:40:54 +0100, Steve McIntyre wrote: > >> On Wed, Apr 29, 2015 at 12:45:29PM +0100, Steve McIntyre wrote: >> > >> >In the morning, I turn on the screen and I don't get a display at >> >all. I've wiggled the mouse, hit numlock on the keybard (the numlock >> >led illuminates fine), etc., but no display. I've seen this kind of >> >thing happen in the past on some machines, so I switch to VT1 and back >> >to see if that helps. Still no display at all, either on console or >> >under X. I log in remotely and I can see that the Xorg.0.log file has >> >been updated with mode lines for the monitor, suggesting things have >> >just woken up fine. But still no display. >> >> Similar problem this morning. I've found that using xrandr to disable >> and re-enable the DisplayPort output I'm using helps - the display >> comes back. Until xrandr segfaults, anyway - see separate bug. >> >> Something weird in the card state, I guess? >> >Sounds likely. If this still happens with linux 4.0, can you report >this upstream at >https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM%2fRadeon >and let us know the bug number? OK. New kernel didn't help at all. Bug filed: https://bugs.freedesktop.org/show_bug.cgi?id=90340 -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves. -- 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/20150506132640.ge7...@einval.com
Bug#783705: xserver-xorg-video-radeon: Weird X wakeup problem since Jessie upgrade
On Tue, May 05, 2015 at 09:06:40AM -0400, Alex Deucher wrote: >On Wed, Apr 29, 2015 at 7:45 AM, Steve McIntyre wrote: >> Package: xserver-xorg-video-radeon >> Version: 1:7.5.0-1 >> Severity: normal >> >> Hi folks, >> >> I upgrade my main office desktop to Jessie on Monday, and just about >> evrrything worked really well - just half a dozen oro so config files >> needed merging with new upstream etc. Painless! >> >> However, I'm now seeing a really odd problem with X on my >> machine. I've got an AMD graphics card, which Xorg.0.log tells me is a >> >> RADEON(0): Chipset: "PITCAIRN" (ChipID = 0x6810) >> >> and a DP+ connection to a lovely 27" NEC monitor. It works just fine >> when I'm using it, *but* when I leave it overnight and come in the >> next morning it doesn't want to wake up properly. I'm locking the >> screen with Xscreensaver and then turning off the monitor as I leave. >> >> In the morning, I turn on the screen and I don't get a display at >> all. I've wiggled the mouse, hit numlock on the keybard (the numlock >> led illuminates fine), etc., but no display. I've seen this kind of >> thing happen in the past on some machines, so I switch to VT1 and back >> to see if that helps. Still no display at all, either on console or >> under X. I log in remotely and I can see that the Xorg.0.log file has >> been updated with mode lines for the monitor, suggesting things have >> just woken up fine. But still no display. >> >> Here's the really weird thing: at this point, the monitor has >> basically locked up. It won't respond to the power/input/menu butttons >> at all, and is still showing the blue LED that says "I have signal" >> rather than switching to the amber "no signal" warning. Therefore, I >> can only assume there's a problem here with some weird invalid DP >> signal being produced. >> >> Yesterday, I gave up and rebooted after a few minutes - I had work to >> do. Today, I started searching for any other reports like this using >> my laptop. About ten minutes later while I was doing this >> (approximately, wasn't paying massive attention at this point), my >> desktop screen suddenly came to life and now it's working OK. >> >> I have no idea of where to even start debugging this. Help! > >If this is a regression, what previous version was working correctly? I was using an up-to-date wheezy installation previously, so that would be 1:6.14.4-8. >Does the problem only happen when you physically power off the >monitor? Ah, yes! In fact, it's the act of physically powering off the monitor that's the problem here. I can reproduce immediately by doing that. Last night, I locked the screen and left the monitor on and things were still working fine this morning when I came in. >Does it come back ok when you let dpms kick in? Pass - I disabled dpms ages ago for unrelated reasons... >How about when you physically disconnect the monitor from the >computer? I tried that - if I unplugged the cable from the monitor, the monitor started responding to button presses ok but as soon as I reconnected it locked up again and still no display. >Also, what screensavers are you using? There may be a problematic GL >screensaver that's causing a GPU lockup. Can you try forcing a >single known stable screensaver? I just use "bumps" under xscreensaver, and I've had that configured for years. -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I... -- 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/20150506131222.gd7...@einval.com
Bug#783705: xserver-xorg-video-radeon: Weird X wakeup problem since Jessie upgrade
On Wed, Apr 29, 2015 at 12:45:29PM +0100, Steve McIntyre wrote: > >In the morning, I turn on the screen and I don't get a display at >all. I've wiggled the mouse, hit numlock on the keybard (the numlock >led illuminates fine), etc., but no display. I've seen this kind of >thing happen in the past on some machines, so I switch to VT1 and back >to see if that helps. Still no display at all, either on console or >under X. I log in remotely and I can see that the Xorg.0.log file has >been updated with mode lines for the monitor, suggesting things have >just woken up fine. But still no display. Similar problem this morning. I've found that using xrandr to disable and re-enable the DisplayPort output I'm using helps - the display comes back. Until xrandr segfaults, anyway - see separate bug. Something weird in the card state, I guess? -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess -- 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/20150505114054.ga21...@einval.com
Bug#783705: xserver-xorg-video-radeon: Weird X wakeup problem since Jessie upgrade
Package: xserver-xorg-video-radeon Version: 1:7.5.0-1 Severity: normal Hi folks, I upgrade my main office desktop to Jessie on Monday, and just about evrrything worked really well - just half a dozen oro so config files needed merging with new upstream etc. Painless! However, I'm now seeing a really odd problem with X on my machine. I've got an AMD graphics card, which Xorg.0.log tells me is a RADEON(0): Chipset: "PITCAIRN" (ChipID = 0x6810) and a DP+ connection to a lovely 27" NEC monitor. It works just fine when I'm using it, *but* when I leave it overnight and come in the next morning it doesn't want to wake up properly. I'm locking the screen with Xscreensaver and then turning off the monitor as I leave. In the morning, I turn on the screen and I don't get a display at all. I've wiggled the mouse, hit numlock on the keybard (the numlock led illuminates fine), etc., but no display. I've seen this kind of thing happen in the past on some machines, so I switch to VT1 and back to see if that helps. Still no display at all, either on console or under X. I log in remotely and I can see that the Xorg.0.log file has been updated with mode lines for the monitor, suggesting things have just woken up fine. But still no display. Here's the really weird thing: at this point, the monitor has basically locked up. It won't respond to the power/input/menu butttons at all, and is still showing the blue LED that says "I have signal" rather than switching to the amber "no signal" warning. Therefore, I can only assume there's a problem here with some weird invalid DP signal being produced. Yesterday, I gave up and rebooted after a few minutes - I had work to do. Today, I started searching for any other reports like this using my laptop. About ten minutes later while I was doing this (approximately, wasn't paying massive attention at this point), my desktop screen suddenly came to life and now it's working OK. I have no idea of where to even start debugging this. Help! -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Jul 22 2014 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 2401376 Feb 11 00:35 /usr/bin/Xorg 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/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/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/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/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/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 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/x86_64-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by glx-diversions diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions diversion o
Re: Bug#734093: debian-installer: install plymouth by default
On Fri, Jan 03, 2014 at 08:05:42PM +0100, Cyril Brulebois wrote: >Andreas Cadhalpun (2014-01-03): >> Package: debian-installer >> Severity: wishlist >> X-Debbugs-CC: Antoine Beaupré >> >> Dear Maintainer, >> >> in his installation report [1] Antoine Beaupré requested to have >> plymouth installed by default. >> >> While some want to have it and some don't, I think it really might >> be a good idea to install plymouth by default, as 'novices' >> generally prefer it, and anyone who wants to see the boot messages >> should have sufficient knowledge to remove it. >> >> So please install plymouth by default. > >Last I remember from squeeze (didn't check wheezy too much), plymouth >was quite buggy/broken, and has been RC buggy for a long while (hello >libdrm-nouveau); I'm not sure it's a good idea to install it by default, >but I'm happy to take opinions. No, please! Let's not add more fluff to the base system. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs." -- Matt Mackall -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140103231920.ga12...@einval.com
Bug#620830: Very long package filenames (>80 characters)
On Mon, Apr 04, 2011 at 04:22:39PM +0200, Cyril Brulebois wrote: >Hi Steve & Sean, > >Steve McIntyre (04/04/2011): >> 82 >> compiz-fusion-plugins-unsupported/compiz-fusion-plugins-unsupported_0.9.2.1+git20110224.4d704607-1_kfreebsd-i386.deb >> 83 >> compiz-fusion-plugins-unsupported/compiz-fusion-plugins-unsupported_0.9.2.1+git20110224.4d704607-1_kfreebsd-amd64.deb > >maybe drop the commit id at the very least? Keeping the date and >mentioning the sha1 (“Merge upstream-unstable up to $sha1”) in the >changelog would be sufficient? Sounds good to me, yeah. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering" -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110413164607.gg18...@einval.com
Bug#620830: Very long package filenames (>80 characters)
Package: compiz-fusion-plugins-unsupported Version: 0.9.2.1+git20110224.4d704607-1 Severity: minor Hi, Several of the files in the archive belonging to your package are longer than 80 characters in length, which could cause problems with packaging them onto Debian CDs. See http://lists.debian.org/debian-devel/2011/03/msg00943.html for more details. The files concerned are: 82 compiz-fusion-plugins-unsupported/compiz-fusion-plugins-unsupported_0.9.2.1+git20110224.4d704607-1_kfreebsd-i386.deb 83 compiz-fusion-plugins-unsupported/compiz-fusion-plugins-unsupported_0.9.2.1+git20110224.4d704607-1_kfreebsd-amd64.deb Please consider renaming these files if possible. -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404140522.5917.70649.reportbug@tack.local
Bug#596664: Intermittent server crash on GM45
On Sat, Oct 02, 2010 at 01:47:48PM +0200, Cyril Brulebois wrote: >Hi Steve. Hey KiBi, >Steve McIntyre (13/09/2010): >> I'm seeing intermittent crashes from the X server on my Lenovo >> Thinkpad X200 machine. > >Hmm, X log doesn't say much; maybe running X inside gdb from a remote >machine would help spot what happens when it gets terminated. Maybe >you have the X log of the crash somewhere as a first clue? Sorry, no. In fact, since I reported this problem I've not been able to reproduce things at all in normal use. If I don't confirm it in a week or so, feel free to just close this bug. -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101006134304.ge14...@einval.com
Bug#596664: Intermittent server crash on GM45
Package: xserver-xorg-video-intel Version: 2:2.9.1-4 Severity: important I'm seeing intermittent crashes from the X server on my Lenovo Thinkpad X200 machine. In normal use, things seem fine. But when I resume after suspend, or open the lid after running for a while with the lid closed (i.e. *not* suspended), I'm seeing xdm restart and present me with a login screen instead of the expected Xscreensaver password prompt. xdm.log says: Sun Sep 12 23:37:47 2010 xdm error (pid 3584): Server for display :0 terminated unexpectedly: 2816 As an extra data point: I've just reinstalled this machine a few days ago using amd64; the exact same hardware (and the exact same version of the Intel driver) seemed to work flawlessly in i386, and I certainly never saw this problem there. I've looked in other log files, but can't see anything obvious. If there's anthing I can do to help debug, please let me know. Cheers, Steve -- Package-specific info: /var/lib/x11/X.roster does not exist. /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 Sep 10 01:34 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 1878432 Aug 24 15:29 /usr/bin/Xorg /var/lib/x11/xorg.conf.roster does not exist. VGA-compatible devices on PCI bus: 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) /etc/X11/xorg.conf does not exist. Kernel version (/proc/version): Linux version 2.6.32-5-amd64 (Debian 2.6.32-21) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-2) ) #1 SMP Wed Aug 25 13:59:41 UTC 2010 Xorg X server log files on system: -rw-r--r-- 1 root root 31770 Sep 13 05:12 /var/log/Xorg.0.log Contents of most recent Xorg X server log file /var/log/Xorg.0.log: X.Org X Server 1.7.7 Release Date: 2010-05-04 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32-5-amd64 x86_64 Debian Current Operating System: Linux tack 2.6.32-5-amd64 #1 SMP Wed Aug 25 13:59:41 UTC 2010 x86_64 Kernel command line: BOOT_IMAGE=Linux64 ro root=fd02 resume=/dev/sda2 Build Date: 24 August 2010 02:20:59PM xorg-server 2:1.7.7-4 (Julien Cristau ) Current version of pixman: 0.16.4 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: Mon Sep 13 04:18:19 2010 (==) Using system config directory "/usr/share/X11/xorg.conf.d" (==) No Layout section. Using the first Screen section. (==) No screen section available. Using defaults. (**) |-->Screen "Default Screen Section" (0) (**) | |-->Monitor "" (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. Entry deleted from font path. (==) 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, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins (==) ModulePath set to "/usr/lib/xorg/modules" (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. (II) Loader magic: 0x7c5f40 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 6.0 X.Org XInput driver : 7.0 X.Org Server Extension : 2.0 (++) using VT number 7 (WW) xf86OpenConsole: setpgid failed: Operation not permitted (WW) xf86OpenConsole: setsid failed: Operation not permitted (--) PCI:*(0:0:2:0) 8086:2a42:17aa:20e4 Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller rev 7, Mem @ 0xf200/4194304, 0xd000/268435456, I/O @ 0x1800/8 (--) PCI: (0:0:2:1) 8086:2a43:17aa:20e4 Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller rev 7, Mem @ 0xf240/1048576 (II) Open ACPI successful (/var/run/acpid.socket) (II) LoadModule: "extmod" (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.7.7, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension SELinux (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "dbe" (II) Loading /usr/lib/xorg/modules/extensions
DPL teams review 2008
k all of your tasks in order of importance? f. Finally, are you having fun working on Debian? Why/why not? 2. Teams you're in -- (please answer this section multiple times where appropriate, once per team, but *excluding* teams for maintenance of individual packages) a. What teams do you work on? Are you an "official" member of those teams? b. How well do you think those teams are performing, in terms of getting things done? How are daily/regular tasks dealt with? And how about less common, one-off things? c. How do members of your teams communicate with each other about what they're working on? And how do they (as individuals or as a team) communicate with people outside of the team? Do you feel they coordinate well? d. Are there enough resources for your teams to do their jobs well? If not, what's missing? e. Anything else you'd like to mention? 3. Other teams -- a. What contact, if any, do you (as an individual) have with other teams? How well does that contact work? b. How well do your team(s) interact with other teams? c. If you have any issues in (a) or (b), how would you suggest to fix them? d. Any other observations about the various teams in Debian? === Other stuff === That's the list of things I'm hoping to learn more about from this review of teams. Of course, I'm sure there are many other things in Debian that you'd like to ask or tell me about. By all means, talk to me about them - I see it as part of my job to listen and do what I can to help. But please keep those separate from this survey - it'll help me to avoid my head exploding in all directions... :-) -- Steve McIntyre, Debian Project Leader <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: xaw8
On Sun, Mar 26, 2006 at 07:38:52PM -0500, David Nusinow wrote: >Hello all, > > Because xaw8 is functionally equivalent to xaw7 in every way except for >the xprint suppot, if your app does not need this specific feature then you >can safely depend on xaw7, leaving us to remove xaw8 from the archive. If >any of you do specifically need this support, please let us know (M-F-T set >to debian-x@lists.debian.org) so that we can support you as necessary. If >you don't need this specific feature though, *please* let us know so we >are sure we can kill this package without harming anyone. >Steve McIntyre <[EMAIL PROTECTED]> > nas nas doesn't use xprint, so I'll drop it back to xaw7. I expect to get an updated package uploaded sometime tomorrow. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast." Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New imake config causing problems
On Sun, Sep 30, 2001 at 10:45:40AM -0500, Branden Robinson wrote: >On Sun, Sep 30, 2001 at 12:20:25PM +0100, Steve McIntyre wrote: >> >> That's the really annoying thing about this, though - the binaries in >> question have man pages that worked just fine with the previous imake >> setup. It seems that there has been a spec change of some sort here... > >Yes. David Dawes changed imake so that manpages could be preprocessed. >This is actually a good thing. Ultimately it will enable us to get rid >of the stupid "" relic that appears in so many X manpages. > >If the program in question was doing something subtle and/or clever, it >might be worthwhile to mail and ask for the best way >to handle it. It was supplying a wrapper around InstallManPageLong() that was broken by design and didn't cope with the changed internals. In the end I've found and fixed it and sent a patch upstream. Thanks for your help, Branden. -- Steve McIntyre, Allstor Software [EMAIL PROTECTED] http://www.chiark.greenend.org.uk/~stevem/>My home page "Can't keep my eyes from the circling sky, "Tongue-tied & twisted, Just an earth-bound misfit, I..."
Re: New imake config causing problems
On Sun, Sep 30, 2001 at 10:45:40AM -0500, Branden Robinson wrote: >On Sun, Sep 30, 2001 at 12:20:25PM +0100, Steve McIntyre wrote: >> >> That's the really annoying thing about this, though - the binaries in >> question have man pages that worked just fine with the previous imake >> setup. It seems that there has been a spec change of some sort here... > >Yes. David Dawes changed imake so that manpages could be preprocessed. >This is actually a good thing. Ultimately it will enable us to get rid >of the stupid "" relic that appears in so many X manpages. > >If the program in question was doing something subtle and/or clever, it >might be worthwhile to mail <[EMAIL PROTECTED]> and ask for the best way >to handle it. It was supplying a wrapper around InstallManPageLong() that was broken by design and didn't cope with the changed internals. In the end I've found and fixed it and sent a patch upstream. Thanks for your help, Branden. -- Steve McIntyre, Allstor Software [EMAIL PROTECTED] http://www.chiark.greenend.org.uk/~stevem/>My home page "Can't keep my eyes from the circling sky, "Tongue-tied & twisted, Just an earth-bound misfit, I..." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New imake config causing problems
On Sat, Sep 29, 2001 at 10:57:39PM -0500, Branden Robinson wrote: >On Sun, Sep 30, 2001 at 12:51:56AM +0100, Steve McIntyre wrote: >[...] >> This is really annoying - nas built just fine previously, but it looks >> like there has been a significant change to the output of imake, >> specifically to man page handling in CppManTarget in Imake.rules. My >> other package, xpacman, had just the same problem. I'm not sure >> whether I should file a bug against xlibs-dev for this or just work >> around the problem... > >Yup. Fortunately, the workaround is not difficult. > >In the Imakefile(s), change: > >ComplexProgramTarget() > >to > >ComplexProgramTargetNoMan() > >Alternatively, write a manual page for the binary. That's the really annoying thing about this, though - the binaries in question have man pages that worked just fine with the previous imake setup. It seems that there has been a spec change of some sort here... -- Steve McIntyre[EMAIL PROTECTED] "Can't keep my eyes from the circling sky, "Tongue-tied & twisted, Just an earth-bound misfit, I..."
Re: New imake config causing problems
On Sat, Sep 29, 2001 at 10:57:39PM -0500, Branden Robinson wrote: >On Sun, Sep 30, 2001 at 12:51:56AM +0100, Steve McIntyre wrote: >[...] >> This is really annoying - nas built just fine previously, but it looks >> like there has been a significant change to the output of imake, >> specifically to man page handling in CppManTarget in Imake.rules. My >> other package, xpacman, had just the same problem. I'm not sure >> whether I should file a bug against xlibs-dev for this or just work >> around the problem... > >Yup. Fortunately, the workaround is not difficult. > >In the Imakefile(s), change: > >ComplexProgramTarget() > >to > >ComplexProgramTargetNoMan() > >Alternatively, write a manual page for the binary. That's the really annoying thing about this, though - the binaries in question have man pages that worked just fine with the previous imake setup. It seems that there has been a spec change of some sort here... -- Steve McIntyre[EMAIL PROTECTED] "Can't keep my eyes from the circling sky, "Tongue-tied & twisted, Just an earth-bound misfit, I..." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
New imake config causing problems
[ Note CC: to debian-x ] More of a heads-up than anything else I guess - I don't expect anything to change really. I've just picked up a second serious bug against one of my packages that uses imake. Bug #113859 against nas: == Package: nas Version: 1.4.2-1 Severity: serious When I try to build the nas package, I get the error ... making all in clients/audio/auconvert... make[4]: Entering directory `/home/daniel/src/debian/n/nas/nas-1.4.2/clients/audio/auconvert' gcc -O2 -fno-strength-reduce -I../../../include -I/usr/X11R6/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -DFUNCPROTO=15 -DNARROWPROTO-DHAS_MKSTEMP -c -o auconvert.o auconvert.c rm -f auconvert gcc -o auconvert auconvert.o -O2 -fno-strength-reduce -L/usr/X11R6/lib ../../../lib/audio/libaudio.a -lXt -lSM -lICE -lXext -lX11 -lm make[4]: *** No rule to make target `tmp.man', needed by `tmp._man'. Stop. make[4]: Leaving directory `/home/daniel/src/debian/n/nas/nas-1.4.2/clients/audio/auconvert' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/daniel/src/debian/n/nas/nas-1.4.2/clients/audio' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/daniel/src/debian/n/nas/nas-1.4.2/clients' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/daniel/src/debian/n/nas/nas-1.4.2' make: *** [build] Error 2 == This is really annoying - nas built just fine previously, but it looks like there has been a significant change to the output of imake, specifically to man page handling in CppManTarget in Imake.rules. My other package, xpacman, had just the same problem. I'm not sure whether I should file a bug against xlibs-dev for this or just work around the problem... -- Steve McIntyre, Cambridge, UK. [EMAIL PROTECTED] http://www.rpg-soc.ucam.org/curs/>CURS home page "Can't keep my eyes from the circling sky, +-- "Tongue-tied & twisted, Just an earth-bound misfit, I..." |Finger for PGP key
New imake config causing problems
[ Note CC: to debian-x ] More of a heads-up than anything else I guess - I don't expect anything to change really. I've just picked up a second serious bug against one of my packages that uses imake. Bug #113859 against nas: == Package: nas Version: 1.4.2-1 Severity: serious When I try to build the nas package, I get the error ... making all in clients/audio/auconvert... make[4]: Entering directory `/home/daniel/src/debian/n/nas/nas-1.4.2/clients/audio/auconvert' gcc -O2 -fno-strength-reduce -I../../../include -I/usr/X11R6/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DHAS_MKSTEMP -c -o auconvert.o auconvert.c rm -f auconvert gcc -o auconvert auconvert.o -O2 -fno-strength-reduce -L/usr/X11R6/lib ../../../lib/audio/libaudio.a -lXt -lSM -lICE -lXext -lX11 -lm make[4]: *** No rule to make target `tmp.man', needed by `tmp._man'. Stop. make[4]: Leaving directory `/home/daniel/src/debian/n/nas/nas-1.4.2/clients/audio/auconvert' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/daniel/src/debian/n/nas/nas-1.4.2/clients/audio' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/daniel/src/debian/n/nas/nas-1.4.2/clients' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/daniel/src/debian/n/nas/nas-1.4.2' make: *** [build] Error 2 == This is really annoying - nas built just fine previously, but it looks like there has been a significant change to the output of imake, specifically to man page handling in CppManTarget in Imake.rules. My other package, xpacman, had just the same problem. I'm not sure whether I should file a bug against xlibs-dev for this or just work around the problem... -- Steve McIntyre, Cambridge, UK. [EMAIL PROTECTED] http://www.rpg-soc.ucam.org/curs/>CURS home page "Can't keep my eyes from the circling sky, +-- "Tongue-tied & twisted, Just an earth-bound misfit, I..." |Finger for PGP key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#104313: ytalk segfaults under sparc
On Mon, Aug 13, 2001 at 11:49:11PM +0100, Steve McIntyre wrote: >On Wed, Jul 11, 2001 at 05:02:04PM +0100, Steve McIntyre wrote: >> >>Hmmm. None of the symbols mentioned show up in ytalk at all; this >>would seem to be a bug somewhere else, at a guess the X libs. Does >>anybody on the sparc list have any idea about this? I'm a little >>lost... > >I asked on the sparc list, but got no extra help there. Maybe on the X >list - can anybody help tracking this down? Marcus - do you still have this bug? -- Steve McIntyre, Cambridge, UK. [EMAIL PROTECTED] Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/
Re: Bug#104313: ytalk segfaults under sparc
On Mon, Aug 13, 2001 at 11:49:11PM +0100, Steve McIntyre wrote: >On Wed, Jul 11, 2001 at 05:02:04PM +0100, Steve McIntyre wrote: >> >>Hmmm. None of the symbols mentioned show up in ytalk at all; this >>would seem to be a bug somewhere else, at a guess the X libs. Does >>anybody on the sparc list have any idea about this? I'm a little >>lost... > >I asked on the sparc list, but got no extra help there. Maybe on the X >list - can anybody help tracking this down? Marcus - do you still have this bug? -- Steve McIntyre, Cambridge, UK. [EMAIL PROTECTED] Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]