Re: X.org plans for the squeeze cycle
Julien Cristau wrote: On Sun, Aug 16, 2009 at 14:41:24 +0200, Marc Brockschmidt wrote: * How many big transitions will the upcoming changes cause? When should those happen? Can we do something to make them easier? Lately the big problems were related to the stability of the intel driver, which went through several big changes (full modesetting in the driver instead of using the bios, then switch of acceleration architecture to EXA, then a kernel memory manager, then kernel mode setting, and I'm probably forgetting some). Hopefully most of that is over, and we can migrate it to testing soon along with the rest of the X stack. What's the status about this? When do you think the X stack will be ready to migrate? Cheers Luk -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Breaking X.Org on sparc (was: Bug#514418: [FIX]: ultra45 boot failing...)
Bastian Blank wrote: Hi We introduced a workaround by reverting a removal in the kernel to allow the current X.Org on sparc work. However this patch is not supportable and breaks all newer machines quite badly. This means that we have to back it out again and the only question is if we will do that for r0 or r1. I think it's best to delay that to r1. Can someone please provide a text for the release notes to describe the problem, TIA? Cheers Luk - Forwarded message from Bastian Blank wa...@debian.org - Package: linux-2.6 Version: 2.6.26-13 Severity: grave I consider this RC. We'll break X.org either for r0 or r1. debian-sparc: Please provide someone who wants to take over sparc architecture maintenance of the Linux packages. On Sat, Feb 07, 2009 at 10:45:31AM +, Jurij Smakov wrote: On Fri, Feb 06, 2009 at 11:11:44PM -0800, David Miller wrote: The patch: debian/patches/bugfix/sparc/arch_pci_hostcontroller_workaround.patch causes ultra45 (and other PCI-Express based workstations) to hard reset when the PCI bus is initially scanned by the kernel. Please revert this patch from the debian kernel in Lenny and anywhere else it appears. The code in that patch creating dummy PCI root host controller nodes is wrong and does nothing other than cause trouble. If it fixes some problem with the X server for PCI devices on sparc64 that problem needs to be fixed some other way. Thank you. I believe that we are just a few days from Lenny release, so uploading a new kernel and rebuilding debian-installer might not be an option at this point, unfortunately. The best we can probably do is include the fixed kernel in the point release, but that's up to kernel team to decide. - End forwarded message - -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508126: xine-ui: ctrl/shift key press emulation implementation broken
Ben Hutchings wrote: On Sat, 2009-01-03 at 18:00 +0100, Julien Cristau wrote: On Fri, Jan 2, 2009 at 15:30:01 +, Ben Hutchings wrote: #508126: x11-utils: xprop -spy does not handle destruction properly the xprop patch looks reasonable afaict, so go ahead and NMU. somebody should also forward that patch to bugs.freedesktop.org. unblocked Cheers Luk -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xorg-server unblock request
Julien Cristau wrote: Hi, I'd like to request an unblock hint for xorg-server: unblock xorg-server/2:1.4.2-2 This version fixes some parallel build issues in the packaging, and cherry-picks 3 bug fixes from upstream. unblocked There'll be at least one further upload before release, we have some pending debconf translation updates for xprint. ok Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: architecture: all but ... (please add armel to architecture list)
Osamu Aoki wrote: Hi Luk, I wish things were such simple. Here is the root cause etc. On Fri, Jan 18, 2008 at 06:58:40PM +0100, Luk Claes wrote: Osamu Aoki wrote: Hi, Dear porter, please enlighten me. On Wed, Jan 16, 2008 at 02:26:20PM +, Martin Guy wrote: Package: gsynaptics Version: 0.9.7-3 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi Please add armel to the architecture list in debian/control (or make it any) (A new ARM port should be going into lenny to replace the old one in lenny+1; see wiki.debian.org/ArmEabiPort) Since S360 build failure caused me to chose explicit arch list, I think I have to add eabi to fix this bug. I wish if we can do s/s360/s390/ Yes. What build failure do you mean? 0.9.7-1+b1 as well as 0.9.7-1+b2 built fine and 0.9.7-2 didn't have s390 listed anymore as a supported architecture... That is intentional because of Bug #397917. http://bugs.debian.org/397917 What I meant by build failure was that an uninstallable package was created, I think. Ok, though it was still you that chose to go for option 3 which means you have to change the Arch-line every time a new supported arch is known... Changing the synaptics related packages is not going to happen as s390 has no support for it... So you can either still go for option 3 or change to option 4 now by changing it to Arch:any. As the binaries are already removed and it won't be built on s390 anymore anyway, this might be the best thing to do... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: architecture: all but ... (please add armel to architecture list)
Now we have several overlapping mechanisms to avoid building packages on selected architectures. Worse, we don't have any proper instructions explaining which mechaism to use. 1) Architecture: list in package source This is what gsynaptics does now. wanna-build will still offer the package to build (why?), but sbuild will fail it immeadetly. Annoyingly maintainers can't define negations (!s390). It's still offered for building as it might only be temporary relevant and buildd maintainers and/or porters might want to look into it. sbuild will fail as that's what one expects it to do without changing the Arch-field. 2) Architecture: list on binary section This is used on packages that build some binary on all archs and some on only selected ones. This is very usefull unless misused. And probably should be used more often for particular kind of packages... 3) Wanna-build state not-for-us. buildd maintainer sets this. From wanna-build docs[1]: there's need for a way to list packages for which even an attempt to build isn't required. The first solution to this problem was not-for-us; however, as that is difficult to maintain, not-for-us is deprecated nowadays; autobuilder maintainers should use packages-arch-specific instead. From my armel short buildd maintainance experience, I can't see why n-f-u is more difficult to maintain. neither n-f-u or p-a-s have any connection to what package maintainer defines in Architecture: strings. You can't document why it's in n-f-u AFAICS and one can't easily have a listing of packages per issue probably. 4) wanna-build state dep-wait One option would be to put gsynaptics to dep-wait on xfree86-driver-synaptics. Thus buildd would not try to build it unless xfree86-driver-synaptics becomes some day available on s390. While X on s390 might seem unlikely, stranger things have happened. Perfectly reasonable IMHO. 5) packages-arch-specific [2] p-a-s makes package never appear in wanna-build. It will never by tried to be built on architectures defined there. It' maintained by three people who manually update it. Any technical advantage this approarch has over n-f-u is completly negated by the fact the people who are supposed to update it ignore my requests to update it... It is also not being built on other suites then the one were it sometimes is meant not to build anymore... Some updates go quickly, others take time, I guess that's because there are only a few persons who can update it... 6) type-handling This is a kludge that has been written to workaround problems in rest of the architecture selection system. In practice it seems to work very well. Osamu, for short term, I suggest using type-handling to generate architecture strings. I guess one can see this as a dynamic case of 1) and 2)? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448970: xprint-utils recommends unmet xprint
Package: xprint-utils Version: 7.1-1 Severity: important User: [EMAIL PROTECTED] Usertags: goal-recommends Hi xprint-utils recommends xprint which is not available in unstable. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Meeting for etch and a half
dann frazier wrote: (sorry for the nasty cross-posting) hey, Now that 2.6.23 is out and the proposed timeframe for etch 1/2 is just over two months away, its probably a good time to start making some progress on an etch 1/2. Yes, I think it's a good time to start the discussion. Perhaps we should start with an IRC meeting? I've created a wiki page here with an initial stab at an agenda, starting with Is it still a good idea?: http://wiki.debian.org/EtchAndAHalf If we have consensus is to proceed, then I'd like to see if we can come up with a list of next steps. I'll be travelling Thur-Monday of this week, so Wednesday is the only day I can do this week, but next week is pretty open. If you're interested in attending, please mark available times here: http://www.doodle.ch/wa4r43rq55uif8rf People that are interested, please mark the times your available so the meeting can be scheduled... Dann: you don't seem to be listed? :-) Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424684: Working config + log for comparison
Brice Goglin wrote: You seem to have the latest xserver-xorg-core (1.3.something) and vesa and via drivers. Does the problem go away if you downgrade to xserver-xorg-core 2:1.1.1-21 (the one in Etch/stable and in testing) without downgrading anything else? Do you know what got upgraded during your recent upgrade? (/var/log/dpkg.log might help you find out) No, I'm not sure what got upgraded as I don't restart X after an upgrade. There is basically nothing in package xserver-xorg, so this bug will probably have to be reassigned to xserver-xorg-core or to the vesa driver (since the via driver seem to work fine, right?). The via driver works fine indeed. I'll test with downgrading to the version you mentioned of xserver-xorg-core if it's still needed tomorrow. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424684: X fails to start: VESA(0): No matching modes
Package: xserver-xorg Version: 1:7.2-3 Severity: important Hi After a recent upgrade, when starting X it failed with the error in the subject. I hope you can fix the issue with the included config file and log. Cheers Luk -- Package-specific info: Contents of /var/lib/x11/X.roster: xserver-xorg /etc/X11/X target does not match checksum in /var/lib/x11/X.md5sum. X server symlink status: lrwxrwxrwx 1 root root 13 Apr 17 2006 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1698800 May 9 11:59 /usr/bin/Xorg Contents of /var/lib/x11/xorg.conf.roster: xserver-xorg VGA-compatible devices on PCI bus: 01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8378 [S3 UniChrome] Integrated Video (rev 01) /var/lib/x11/xorg.conf.md5sum does not exist. Xorg X server configuration file status: -rw-r--r-- 1 root root 3170 May 16 20:46 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # xorg.conf (Xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type man xorg.conf at the shell prompt.) # # 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 to be automatically updated # again, run the following commands as root: # # cp /etc/X11/xorg.conf /etc/X11/xorg.conf.custom # md5sum /etc/X11/xorg.conf /var/lib/xfree86/xorg.conf.md5sum # dpkg-reconfigure xserver-xorg Section Files FontPathunix/:7100# local font server # if the local font server has problems, we can fall back on these FontPath/usr/share/fonts/X11/misc FontPath/usr/share/fonts/X11/cyrillic FontPath/usr/share/fonts/X11/100dpi/:unscaled FontPath/usr/share/fonts/X11/75dpi/:unscaled FontPath/usr/share/fonts/X11/Type1 FontPath/usr/share/fonts/X11/CID FontPath/usr/share/fonts/X11/100dpi FontPath/usr/share/fonts/X11/75dpi EndSection Section Module Loadbitmap Loaddbe Loadddc Loaddri Loadevdev Loadextmod Loadfreetype Loadglx Loadint10 Loadrecord Loadtype1 Loadvbe EndSection Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xorg Option XkbModel pc105 Option XkbLayout be EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/psaux Option Protocol PS/2 Option Emulate3Buttons true Option ZAxisMapping 4 5 EndSection Section InputDevice Identifier Synaptics Touchpad Driver synaptics Option SendCoreEventstrue Option Device/dev/psaux Option Protocol auto-dev Option HorizScrollDelta 0 EndSection Section Device Identifier Generic Video Card Driver vesa BusID PCI:1:0:0 EndSection Section Monitor Identifier Generic Monitor Option DPMS HorizSync 28-49 VertRefresh 43-72 EndSection Section Screen Identifier Default Screen Device Generic Video Card Monitor Generic Monitor DefaultDepth24 SubSection Display Depth 1 Modes 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 4 Modes 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 8 Modes 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 15 Modes 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 16 Modes EndSubSection SubSection Display Depth 24 Modes 1152x864 1024x768 800x600 640x480 EndSubSection EndSection Section ServerLayout Identifier Default Layout Screen Default Screen InputDevice Generic Keyboard InputDevice Configured Mouse InputDevice Synaptics Touchpad EndSection Section
Bug#424684: Working config + log for comparison
Hi As noted on IRC, I changed the config a bit: changed driver from vesa to via for instance. Anyway attached the working config and log... Cheers Luk X Window System Version 1.3.0 Release Date: 19 April 2007 X Protocol Version 11, Revision 0, Release 1.3 Build Operating System: Linux Debian Current Operating System: Linux base 2.6.18-4-k7 #1 SMP Mon Mar 26 17:57:15 UTC 2007 i686 Build Date: 09 May 2007 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present 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: Wed May 16 22:06:18 2007 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout Default Layout (**) |--Screen Default Screen (0) (**) | |--Monitor Generic Monitor (**) | |--Device Generic Video Card (**) |--Input Device Generic Keyboard (**) Option XkbRules xorg (**) XKB: rules: xorg (**) Option XkbModel pc105 (**) XKB: model: pc105 (**) Option XkbLayout be (**) XKB: layout: be (==) Keyboard: CustomKeycode disabled (**) |--Input Device Configured Mouse (**) |--Input Device Synaptics Touchpad (**) Option AIGLX off (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/X11/CID does not exist. Entry deleted from font path. (WW) Including the default font path /usr/share/fonts/X11/misc,/usr/share/fonts/X11/cyrillic,/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. (**) FontPath set to: unix/:7100, /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, /usr/share/fonts/X11/misc, /usr/share/fonts/X11/cyrillic, /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 (==) RgbPath set to /etc/X11/rgb (==) ModulePath set to /usr/lib/xorg/modules (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) (II) No APM support in BIOS or kernel (II) Loader magic: 0x81dc3e0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 1.2 X.Org XInput driver : 0.7 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: pcidata (II) Loading /usr/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor=X.Org Foundation compiled for 1.3.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.2 (--) using VT number 7 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1106,3205 card 1106,7205 rev 00 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1106,b168 card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:07:0: chip 104c,ac50 card 2000, rev 02 class 06,07,00 hdr 02 (II) PCI: 00:08:0: chip 104c,8026 card 1025,0033 rev 00 class 0c,00,10 hdr 00 (II) PCI: 00:10:0: chip 1106,3038 card 1025,0033 rev 80 class 0c,03,00 hdr 80 (II) PCI: 00:10:1: chip 1106,3038 card 1025,0033 rev 80 class 0c,03,00 hdr 80 (II) PCI: 00:10:2: chip 1106,3038 card 1025,0033 rev 80 class 0c,03,00 hdr 80 (II) PCI: 00:10:3: chip 1106,3104 card 1025,0033 rev 82 class 0c,03,20 hdr 00 (II) PCI: 00:11:0: chip 1106,3177 card 1025,0033 rev 00 class 06,01,00 hdr 80 (II) PCI: 00:11:1: chip 1106,0571 card 1025,0033 rev 06 class 01,01,8a hdr 00 (II) PCI: 00:11:5: chip 1106,3059 card 1025,0033 rev 50 class 04,01,00 hdr 00 (II) PCI: 00:11:6: chip 1106,3068 card 1025,0033 rev 80 class 07,80,00 hdr 00 (II) PCI: 00:12:0: chip 1106,3065 card 1025,0033 rev 74 class 02,00,00 hdr 00 (II) PCI: 01:00:0: chip 1106,7205 card 1025,0033 rev 01 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,2), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000c (VGA_EN is set) (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xd100 - 0xd1ff (0x100) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xf000 - 0xf3ff (0x400) MX[B] (II)
Bug#401777: Please add xkeyboard-config uploaders
Package: xkeyboard-config Version: 0.9-4 Hi Please add one or more persons to the Uploaders of xkeyboard-config to ease QA work for the package. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Bug#363086: xserver-xorg: preinstallation scripts fails with error 64
Salvador Fandiño wrote: Hi, Hi the xserver-xorg version I was trying to install was xserver-xorg_1%3a7.0.12_all.deb The new version 1:7.0.13 should fix this, a workaround is installing discover1 before upgrading. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
