Bug#359023: xterm: Xft support missing on amd64
On Tue, Mar 28, 2006 at 12:52:46AM +0200, Kurt Roeckx wrote: > Hi, > > A binNMU has been scheduled on amd64 for this problem, so the bug > should go away. > > But someone will need to verify that it actually works now. > > It would also be a good idea if it actually failed to build in > case it can't find the Xft header files. Great, thank you! I'm going to try and update xterm to the newest upstream release soon as well, so even if this fails for some reason it'll be fixed within the week once I update xterm. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please put xlibs back
On Mon, Mar 27, 2006 at 08:46:28PM +0200, Denis Barbier wrote: > Ok, good to know, but I still do not see how to purge /etc/X11/xkb ;) > We moved XKB files into /usr/share/X11/xkb, but if admins want to > customise their XKB layouts, they will most certainly copy > /usr/share/X11/xkb into /etc/X11/xkb and make local changes there. > Thus we want to remove files from /etc/X11/xkb only when upgrading from > xlibs. But we will provide xkb-data and xkb-data-legacy, so users > may switch from one package to another, and we do not know when xkb-data > is installed to replace xlibs. Ok, so maybe we shouldn't touch /etc/X11/xkb at all? Or only purge if the md5sum isn't changed? > If I follow you, xlibs is removed to force other packages to upgrade > their dependencies. This can be achieved by clearing out its Depends > field, it is IMO much cleaner. This is a very good point, and hopefully it'll satisfy ftpmaster. > Anyway this issue can be sorted out after modular xorg is uploaded into > unstable, it is not a blocker. Ok, I'll consider this a high priority once modular is in unstable, alongside any other major issues with upgrading cleanly from sarge. We'll get this sorted out, hopefully making everyone happy :-) - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#359023: xterm: Xft support missing on amd64
Hi, A binNMU has been scheduled on amd64 for this problem, so the bug should go away. But someone will need to verify that it actually works now. It would also be a good idea if it actually failed to build in case it can't find the Xft header files. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#359023: xterm: Xft support missing on amd64
AFAICT, xterm wound up getting built against a buggy version of libxft-dev (namely, 2.1.8.2-5) on amd64 and should therefore be binNMUed for that platform. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#359328: xserver-xorg-video-i810: dri doesn't work (maybe because of kernel 2.6.16?)
Package: xserver-xorg-video-i810 Version: 1:1.5.1.0-1 Severity: normal hello, I have hp omnibook XE3 with this card :00:02.0 VGA compatible controller: Intel Corporation 82830 CGC [Chipset Graphics Controller] (rev 04) I have recently upgraded xorg to version 7 (and kernel 2.6.16 vanilla)(xorg.conf is freshly generated with dpkg-recofigure xserver-xorg) and today, i noticed that dri is not working. LIBGL_DEBUG=verbose glxinfo outputs this message libGL: XF86DRIGetClientDriverName: 1.5.1 i915 (screen 0) libGL: OpenDriver: trying /usr/lib/dri/i915_dri.so drmOpenByBusid: Searching for BusID pci::00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenByBusid: drmOpenMinor returns 6 drmOpenByBusid: drmGetBusid reports pci::00:02.0 ERROR! sizeof(I830DRIRec) does not match passed size from device driver libGL warning: 3D driver returned no fbconfigs. libGL error: InitDriver failed libGL error: reverting to (slow) indirect rendering name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: and so on ... after little searching, it seems, that there is some mishmash between some files in xorg, mesa and kernel (or so, i don't understand it much) So i downloaded http://dri.freedesktop.org/snapshots/i915-20060325-linux.i386.tar.bz2 compiled new kernel modules ... it didn't help. So i overwrited /usr/lib/dri/i915_dri.so from libgl1-mesa-dri and /usr/lib/xorg/modules/drivers/i810_drv.so from xserver-xorg-video-i810 with those precompiled files from tarball and dri acceleration seems to work (it works even after moving back original kernel modules). Can you please update these files, if it's possible? thanks Libor (sorry if this bug report comes twice) -- System Information: Debian Release: testing/unstable APT prefers experimental APT policy: (700, 'experimental'), (700, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-swsp-lnb-1 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages xserver-xorg-video-i810 depends on: ii libc6 2.3.6-4GNU C Library: Shared libraries an ii xserver-xorg-core 1:1.0.2-1 X.Org X server -- core server xserver-xorg-video-i810 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347950: Bug#358669: xorg: mouse using evdev doesn't work with 6.9.0.dfsg.1-5 anymore
Am Montag, 27. März 2006 20:32 schrieb Elimar Riesebieter: [...] Ok, I found the solution to my problem but somewhere other than in the config file. I wrote a local udev rule to change the name of the event device to laserG5... Now, it seems that the parser identifies the device by the string given with Phys option and then searches for the device itself. But it won't find any if it's renamed... So my problem is resolved, but that's not the way i like it. I like to name my devices the way i want... Thanks for the help! Matthias
Bug#346469: libxcomposite1: undefined symbols
This bug disappeard after upgrading to Xorg7, libxcomposite from experimental. Now I have: libxcomposite1: 1:0.2.2.2-1 xserver-xorg: 1:7.0.6 I remember that this report was 100% reproducable on xorg 6.9 So it will be probably fixed when experimental Xorg7 packages hit unstable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please put xlibs back
On Sun, Mar 26, 2006 at 05:42:49PM -0500, David Nusinow wrote: > > > Could we just have xkb-data(-legacy) purge them instead? > > > > No, our policy states that a package cannot touch conffiles of another > > package. > > Yes, but that policy is mainly in place to keep packages from stomping all > over each other's files. This is a clear case of migration of conffiles > from one package to another, both of which are maintained by the same group > of people who would agree to do it. My short answer was poorly worded, sorry. I agree with you that we should not blindly follow the policy, but take some common sense into account. > > > We can have them conflict the xlibs as well. Is there really a need to > > > have an empty xlibs package just so we can use its postinst to purge > > > the conffiles? > > > > IMO, yes. > > You also have to take in to account that the release team and ftpmaster > really wants the xlibs package gone completely. Packages have deep old > dependencies on it that causes britney runs to take far longer than they > should. This is largely mitigated by changes I made earlier in the 6.9 > series, but they still want the last bits of it gone. I think it's worth > bending policy a little to give them this. Ok, good to know, but I still do not see how to purge /etc/X11/xkb ;) We moved XKB files into /usr/share/X11/xkb, but if admins want to customise their XKB layouts, they will most certainly copy /usr/share/X11/xkb into /etc/X11/xkb and make local changes there. Thus we want to remove files from /etc/X11/xkb only when upgrading from xlibs. But we will provide xkb-data and xkb-data-legacy, so users may switch from one package to another, and we do not know when xkb-data is installed to replace xlibs. If I follow you, xlibs is removed to force other packages to upgrade their dependencies. This can be achieved by clearing out its Depends field, it is IMO much cleaner. Anyway this issue can be sorted out after modular xorg is uploaded into unstable, it is not a blocker. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#358669: xorg: mouse using evdev doesn't work with 6.9.0.dfsg.1-5 anymore
On Mon, 27 Mar 2006 the mental interface of Elimar Riesebieter told: [...] >Identifier "Mouse" Sorry, according to your ServerLayout this has to be: Identifier "Configured Mouse" Elimar -- On the keyboard of life you have always to keep a finger at the escape key;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#358669: xorg: mouse using evdev doesn't work with 6.9.0.dfsg.1-5 anymore
On Mon, 27 Mar 2006 the mental interface of Matthias Heinz told: > Am Sonntag, 26. März 2006 23:37 schrieben Sie: > > Please tell us the output of > > > > $ cat /proc/bus/input/devices [...] > > I: Bus=0003 Vendor=046d Product=c041 Version=4600 > N: Name="Logitech USB Gaming Mouse" > P: Phys=usb-:00:04.2-2/input0 > S: Sysfs=/class/input/input1 > H: Handlers=mouse0 event1 > B: EV=7 > B: KEY= 0 0 0 0 0 0 0 0 > B: REL=143 The correct InputDevive section for your mouse has to be: Section "InputDevice" # This is evdev with 6.9.0-5 Identifier "Mouse" Driver "evdev" Option "CorePointer" Option "Phys" "usb-*/input0" EndSection And of course yes: Section "Module" ... ... Load "evdev" ... ... EndSection -- Numeric stability is probably not all that important when you're guessing;-) pgpqCAn0udoDY.pgp Description: PGP signature
Bug#352801: (no subject)
I saw this same breakage with my G400/G450 when I upgraded X.org from Debian testing. This is a significant regression, and I hope whoever broke it is able to fix it soon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#175907: Heal ur aches/pains
www.dykres.org/ht9/ is the store to be gone those pounds revious circumstances. Even though he also believes that circumstances has nothing to do with ion in concentration. Approximately six million Poland citizens were killed and two and In Egypt, human rights activists privately contend that the Egyptian government, one of the first to raise complaints about the cartoons, is using the controversy to protest Copenhagen's generous aid contributions to critics of President To make us see the bigger picture. Nature of course sets the scene. Long paragraphs of nature and the speed of light. Perhaps the most important part of his discoveries was the equation: E=mc2.After -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
xorg_7.0.7_i386.changes ACCEPTED
Accepted: libglu1-xorg-dev_7.0.7_i386.deb to pool/main/x/xorg/libglu1-xorg-dev_7.0.7_i386.deb libglu1-xorg_7.0.7_i386.deb to pool/main/x/xorg/libglu1-xorg_7.0.7_i386.deb x11-common_7.0.7_i386.deb to pool/main/x/xorg/x11-common_7.0.7_i386.deb xlibmesa-dri_7.0.7_i386.deb to pool/main/x/xorg/xlibmesa-dri_7.0.7_i386.deb xlibmesa-gl-dev_7.0.7_i386.deb to pool/main/x/xorg/xlibmesa-gl-dev_7.0.7_i386.deb xlibmesa-gl_7.0.7_i386.deb to pool/main/x/xorg/xlibmesa-gl_7.0.7_i386.deb xlibs-data_7.0.7_i386.deb to pool/main/x/xorg/xlibs-data_7.0.7_i386.deb xlibs-static-dev_7.0.7_all.deb to pool/main/x/xorg/xlibs-static-dev_7.0.7_all.deb xorg-dev_7.0.7_i386.deb to pool/main/x/xorg/xorg-dev_7.0.7_i386.deb xorg_7.0.7.dsc to pool/main/x/xorg/xorg_7.0.7.dsc xorg_7.0.7.tar.gz to pool/main/x/xorg/xorg_7.0.7.tar.gz xorg_7.0.7_i386.deb to pool/main/x/xorg/xorg_7.0.7_i386.deb xserver-xfree86_7.0.7_i386.deb to pool/main/x/xorg/xserver-xfree86_7.0.7_i386.deb xserver-xorg-input-all_7.0.7_i386.deb to pool/main/x/xorg/xserver-xorg-input-all_7.0.7_i386.deb xserver-xorg-video-all_7.0.7_i386.deb to pool/main/x/xorg/xserver-xorg-video-all_7.0.7_i386.deb xserver-xorg_7.0.7_all.deb to pool/main/x/xorg/xserver-xorg_7.0.7_all.deb Announcing to debian-devel-changes@lists.debian.org Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
xorg override disparity
There are disparities between your recently accepted upload and the override file for the following file(s): libglu1-xorg_7.0.7_i386.deb: package says section is libdevel, override says libs. xlibmesa-dri_7.0.7_i386.deb: package says section is libdevel, override says x11. xlibmesa-gl_7.0.7_i386.deb: package says section is libdevel, override says libs. xlibs-data_7.0.7_i386.deb: package says section is x11, override says libs. xlibs-static-dev_7.0.7_all.deb: package says section is x11, override says libdevel. Either the package or the override file is incorrect. If you think the override is correct and the package wrong please fix the package so that this disparity is fixed in the next upload. If you feel the override is incorrect then please reply to this mail and explain why. [NB: this is an automatically generated mail; if you replied to one like it before and have not received a response yet, please ignore this mail. Your reply needs to be processed by a human and will be in due course, but until then the installer will send these automated mails; sorry.] -- Debian distribution maintenance software (This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of xorg_7.0.7_i386.changes
xorg_7.0.7_i386.changes uploaded successfully to localhost along with the files: xorg_7.0.7.dsc xorg_7.0.7.tar.gz xserver-xorg_7.0.7_all.deb xlibs-static-dev_7.0.7_all.deb x11-common_7.0.7_i386.deb xserver-xfree86_7.0.7_i386.deb xserver-xorg-video-all_7.0.7_i386.deb xserver-xorg-input-all_7.0.7_i386.deb xorg_7.0.7_i386.deb xorg-dev_7.0.7_i386.deb xlibs-data_7.0.7_i386.deb xlibmesa-dri_7.0.7_i386.deb xlibmesa-gl_7.0.7_i386.deb xlibmesa-gl-dev_7.0.7_i386.deb libglu1-xorg_7.0.7_i386.deb libglu1-xorg-dev_7.0.7_i386.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: My Plan For Uploading Modular To Unstable
On Mon, Mar 27, 2006 at 07:18:57AM -0500, David Nusinow wrote: > So thanks to Micah Anderson of the testing security team, we've got a fixed > version of the monolith uploaded straight to unstable. That leaves us three Er, that'd be testing, not unstable. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: My Plan For Uploading Modular To Unstable
On Sun, Mar 26, 2006 at 05:53:22PM -0500, David Nusinow wrote: > On Sat, Mar 25, 2006 at 11:42:39PM +0100, Denis Barbier wrote: > > On Tue, Mar 21, 2006 at 10:59:45PM -0500, David Nusinow wrote: > > > Hi everyone, > > > > > >So we're finally at the end of a very long line. At the end of this > > > week > > > I'm going to upload the whole of 7.0 to unstable. I've gotten the green > > > light from the release team to do this, so I'm just going to go for it and > > > we'll iron out whatever major bugs are blocking us from actually releasing > > > this with etch. Here's the plan: > > > > > > 1) Wait for the latest upload of 6.9 to propagate to testing. Since this > > > is a high urgency security upload it shouldn't take too long. > > > > AFAICT it won't happen because xorg-x11 FTBFS on mips/mipsel: > > Ugh, thanks for letting me know. Now comes the fun decision: re-upload a > fixed monolith (probably with the evdev patch just removed for this round) > and let it propagate or just go straight for modular? I'm honestly leaning > towards the latter because I sick of delaying it. We need to get these > packages in so we can squash some important bugs for the etch release. So thanks to Micah Anderson of the testing security team, we've got a fixed version of the monolith uploaded straight to unstable. That leaves us three minor arches only vulnerable in unstable, and I'm willing to live with that for now. I'm going to continue building and uploading the individual pieces to gluck, and hopefully the xaw8 issues will all be taken care of by then. I've done QA uploads for 7/21 of the affected packages, and I've gotten confirmations on three more that they're going to switch back to xaw7 (nas and tetex below, and drscheme from Ari on irc). I'm currently also uploading a new version of the xorg source package that adds a compatibility package for xlibs-static-dev to prevent hassles with that transition until after etch. These are the last major issues I'm aware of. If all goes well the transition to 7.0 in unstable will begin later this week. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354553: marked as done (xorg depends on unfindable libgl1-mesa)
Your message dated Mon, 27 Mar 2006 13:45:52 +0200 with message-id <[EMAIL PROTECTED]> and subject line Fixed in 1:7.0.6 has caused the attached Bug report 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 I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: xorg Version: 1:7.0.0 Severity: grave Justification: renders package unusable xorg relies on the libgl1-mesa package, which I can't find a copy of anywhere in the Debian archives (I've also checked incoming and the new packages list on ftp-master.debian.org). There is a copy available in the Ubuntu archives for dapper, but installing this would probably be a bad idea -- System Information: Debian Release: testing/unstable APT prefers stable APT policy: (990, 'stable'), (103, 'testing'), (102, 'unstable'), (99, 'experimental'), (97, 'dapper') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) --- End Message --- --- Begin Message --- Package: xorg Version: 1:7.0.6 I think this got fixed earlier, but definitely fixed in 7.0.6. --- End Message ---
xorg-x11_6.9.0.dfsg.1-4etch2_i386.changes ACCEPTED
Mapping testing to etch-proposed-updates. Accepted: lbxproxy_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/lbxproxy_6.9.0.dfsg.1-4etch2_i386.deb libdmx-dev_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libdmx-dev_6.9.0.dfsg.1-4etch2_i386.deb libdmx1-dbg_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libdmx1-dbg_6.9.0.dfsg.1-4etch2_i386.deb libdmx1_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libdmx1_6.9.0.dfsg.1-4etch2_i386.deb libfs-dev_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libfs-dev_6.9.0.dfsg.1-4etch2_i386.deb libfs6-dbg_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libfs6-dbg_6.9.0.dfsg.1-4etch2_i386.deb libfs6_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libfs6_6.9.0.dfsg.1-4etch2_i386.deb libglu1-xorg-dbg_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libglu1-xorg-dbg_6.9.0.dfsg.1-4etch2_i386.deb libglu1-xorg-dev_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libglu1-xorg-dev_6.9.0.dfsg.1-4etch2_i386.deb libglu1-xorg_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libglu1-xorg_6.9.0.dfsg.1-4etch2_i386.deb libice-dev_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libice-dev_6.9.0.dfsg.1-4etch2_i386.deb libice6-dbg_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libice6-dbg_6.9.0.dfsg.1-4etch2_i386.deb libice6_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libice6_6.9.0.dfsg.1-4etch2_i386.deb libsm-dev_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libsm-dev_6.9.0.dfsg.1-4etch2_i386.deb libsm6-dbg_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libsm6-dbg_6.9.0.dfsg.1-4etch2_i386.deb libsm6_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libsm6_6.9.0.dfsg.1-4etch2_i386.deb libx11-6-dbg_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libx11-6-dbg_6.9.0.dfsg.1-4etch2_i386.deb libx11-6_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libx11-6_6.9.0.dfsg.1-4etch2_i386.deb libx11-dev_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libx11-dev_6.9.0.dfsg.1-4etch2_i386.deb libxau-dev_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libxau-dev_6.9.0.dfsg.1-4etch2_i386.deb libxau6-dbg_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libxau6-dbg_6.9.0.dfsg.1-4etch2_i386.deb libxau6_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libxau6_6.9.0.dfsg.1-4etch2_i386.deb libxaw6-dbg_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libxaw6-dbg_6.9.0.dfsg.1-4etch2_i386.deb libxaw6-dev_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libxaw6-dev_6.9.0.dfsg.1-4etch2_i386.deb libxaw6_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libxaw6_6.9.0.dfsg.1-4etch2_i386.deb libxaw7-dbg_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libxaw7-dbg_6.9.0.dfsg.1-4etch2_i386.deb libxaw7-dev_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libxaw7-dev_6.9.0.dfsg.1-4etch2_i386.deb libxaw7_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libxaw7_6.9.0.dfsg.1-4etch2_i386.deb libxaw8-dbg_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libxaw8-dbg_6.9.0.dfsg.1-4etch2_i386.deb libxaw8-dev_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libxaw8-dev_6.9.0.dfsg.1-4etch2_i386.deb libxaw8_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libxaw8_6.9.0.dfsg.1-4etch2_i386.deb libxcomposite-dev_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libxcomposite-dev_6.9.0.dfsg.1-4etch2_i386.deb libxcomposite1-dbg_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libxcomposite1-dbg_6.9.0.dfsg.1-4etch2_i386.deb libxcomposite1_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libxcomposite1_6.9.0.dfsg.1-4etch2_i386.deb libxdamage-dev_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libxdamage-dev_6.9.0.dfsg.1-4etch2_i386.deb libxdamage1-dbg_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libxdamage1-dbg_6.9.0.dfsg.1-4etch2_i386.deb libxdamage1_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libxdamage1_6.9.0.dfsg.1-4etch2_i386.deb libxdmcp-dev_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libxdmcp-dev_6.9.0.dfsg.1-4etch2_i386.deb libxdmcp6-dbg_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates/main/x/xorg-x11/libxdmcp6-dbg_6.9.0.dfsg.1-4etch2_i386.deb libxdmcp6_6.9.0.dfsg.1-4etch2_i386.deb to pool/security-updates
