Bug#910988: x11-xkb-utils: Please add Multi-Arch: foreign
Package: x11-xkb-utils Version: 7.7+3 Severity: wishlist User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch Hi, It looks like x11-xkb-utils offers an architecture independent (process/cli level) interface to its users. Would you mind setting it to Multi-Arch: foreign? It's usually a matter of adding one line to debian/control. This would hopefully improve install options for different architectures. Like for example using the x32 variant on a mixed amd64/x32 system. Cheers Elrond
Bug#810492: x11-xserver-utils: Please add Multi-Arch: foreign
Package: x11-xserver-utils Version: 7.7+5 Severity: wishlist Hi, It looks like x11-xserver-utils offers an architecture independent (process/cli level) interface to its users. Would you mind setting it to Multi-Arch: foreign? It's usually a matter of adding one line to debian/control. This would hopefully improve install options for different architectures. Like for example using the x32 variant of x11-xserver-utils on a mixed amd64/x32 system. Cheers Elrond
Bug#394529: xorg.conf(5): Please mention APM/ACPI in NoPM option
Package: xserver-xorg-core Version: 2:1.1.1-10 Severity: wishlist xorg.conf(5) is long, being able to search for keywords is important. In my case I was looking on how to disable xorg's usage of APM. (Disabling it makes X more reliable on my box). So please add something like "On Linux this disables APM and ACPI." to the >>Option "NoPM" "boolean"<< stanza. I admit, searching for "power" would also have helped me. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348730: xserver-xorg/glint sometimes freezes
Package: xserver-xorg Version: 6.8.2.dfsg.1-11 Without disabling some accelaration, some apps (especial KOffice) can freeze the X-Server, it goes to 100% CPU and does not react at all. Forcing me to reboot the box. I have this: 00:08.1 Non-VGA unclassified device: 3DLabs GLINT Delta (rev 01) 00:08.2 Non-VGA unclassified device: 3DLabs GLINT MX (rev 01) The following options make X slower (noticeable!), but fix it: Option "XaaNoSolidFillRect" "yes" Option "XaaNoSolidFillTrap" "yes" I haven't yet tested, if one of the two is enough to fix it too. (finding those two using logarithmic search was enough work!) The basic problem already existed in xfree86 4.3, which was my reason to upgrade to xorg. My Xorg.0.log does not have any really useful information, and the most important part of my xorg.conf is: Section "Device" Identifier "ELSE GLoria-L/MX" Driver "glint" BusID "PCI:0:8:1" Option "XaaNoSolidFillRect" "yes" Option "XaaNoSolidFillTrap" "yes" EndSection Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332521: Split xbase-clients
Package: xbase-clients Version: 6.8.2.dfsg.1-8 Severity: wishlist Hi, xbase-clients by now has an installed size of 4,5MB. Quite a lot for a "base" package. One, that nearly every X workstation has installed. It has a lot of specific add-ons, that not everyone needs. I've tried to create some categories of tools in xbase-clients: - diagnostics / debugging: xev, xfd, xrandr, xtrap*, xlsatoms, dpsexec, dpsinfo, xprop, xdpyinfo, xwininfo, glxinfo, xvinfo, appres, editres, listres, viewres, Xmark, x11perf, and x11perfcomp - management tools: xvidtune, atobm, bmtoa, fstobdf, - desktop utilities: (see Bug#199675) beforelight, oclock, xclock, xmag, xload, xeyes, xconsole, xbiff, - demos xgc, dga, ico, glxgears, texteroids, xlogo, - basic tools: xset, xsetroot, xrefresh, xkill, xauth, startx, xinit. (for xauth see Bug#151613) - discouraged tools both xorg*config tools The intention of this list is to serve as a starting point. There are surely hundreds of things, that need to be changed in it, and it misses some tools from xbase-clients, that I do not use nor do I have an idea, what they _really_ could do. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#29194: Bug #29194: xfree86: have all XFree86 packages symlink to xfree86-common for copyright and changelog(s)
On Wed, Jun 02, 2004 at 01:51:57AM -0500, Branden Robinson wrote: > [I don't know that Joey Hess really needs to be CCed on this, so I have Some year ago or so, the submitter of a bug didn't get mail for [EMAIL PROTECTED], might have changed, not to mention, that this mail isn't terribly relevant to him. > removed him from the headers.] > [...] > > "Debian packaging infrastructure" doesn't sound much like > > copyright to me, but you know better, I presume. > > Let me rewrite that sentence in psuedo-LISP. > > The remainder is a list of copyright holders and license terms that > apply to (the various parts of the XFree86 source distribution, and the > Debian packaging infrastructure). > > I think if you had actually read the file, this would have been clear to > you. Well, "but you know better, I presume" was intended to say: "Let's stop this discussion here, I'm 99% sure, you know, what you're doing there." ;) [...] > > It was just an idea. An idea to add some structure... Okay, > > structure in one of the complexest packages in debian... > > It already has lots of structure. Also, I think xfree86's > debian/copyright file *is* structured. You might agree if you'd read > it. Well, I wanted to explain, what the idea _was_. Anyway, I think, we should stop this discussion here and hope for Joey to say anything. (I don't see a point in coding debhelper stuff like mad for realising at the end, that Joey has much better plans.) Elrond
Bug#29194: Bug #29194: xfree86: have all XFree86 packages symlink to xfree86-common for copyright and changelog(s)
On Tue, Jun 01, 2004 at 02:03:52AM -0500, Branden Robinson wrote: [... valid comments ...] Yeah... > > On Fri, Apr 23, 2004 at 12:36:44PM -0500, Branden Robinson wrote: > > [...] > > > It may be unwise to not physically pack copyright info into every .deb, > > > > Unless I miss something, most of the coypright file is a list of > > changes. > > Have you read it? Okay, I have to admit, I only scrolled over the first 30 lines and gave up. My fault. > Approximately 19% of the file is a list of changes. The remainder is a > list of copyright holders and license terms that apply to the various > parts of the XFree86 source distribution, and the Debian packaging > infrastructure. "Debian packaging infrastructure" doesn't sound much like copyright to me, but you know better, I presume. [...] > > This would at least mitigate the situation. > > Solving 20% -- at best -- of the problem doesn't strongly motivate me to > work on this. It was just an idea. An idea to add some structure... Okay, structure in one of the complexest packages in debian... > > If it helps, I will happily file a wishlist bug against debhelper. > > That's your decision to make. You'd be best advised to make it without > trying to predict what any particular package maintainer will do. When > requesting functionality in debhelper, keep in mind the needs of the > vast majority of Debian packages. [...] > Maybe you can help Joey Hess implement the functionality. Joey Hess, are you listening? The idea is to make this whole thing optional, that wont break it for others. My basic idea is something like: dh_installdocs --put-real-file-in-this-package -and-make-symlinks-in-other-packages =xfree86-common Of course the option-name is too long, but it's the basic idea. And dh_installchangelogs could have the same option. I haven't looked at debhelper sources since years, but my quick presumption is, that it can't be too hard to add this. Elrond
Bug#29194: Bug #29194: xfree86: have all XFree86 packages symlink to xfree86-common for copyright and changelog(s)
Hi, I was about to file exactly this bug since some time, finally I found it already existed. Note, that the situatuion is now even more interesting. We have packages like "libxv1". 16k /usr/X11R6/lib/libXv.so.1.0 177k/usr/share/doc/libxv1 And none of the three files in doc/libxv1 are unique to this package. On Fri, Apr 23, 2004 at 12:36:44PM -0500, Branden Robinson wrote: [...] > It may be unwise to not physically pack copyright info into every .deb, Unless I miss something, most of the coypright file is a list of changes. Those could be moved into say /usr/share/doc/xfree86-common/Debian.changes.gz and copyright could just reference it. Maybe even with the note to update xfree86-common to the correct version to get the correct list. (or maybe the Debian.changes.gz should contain this note). This would at least mitigate the situation. > but as for the changelog, well, that's probably a matter of taste. > > I will note that if debhelper were to do this for me, I'd probably > meekly follow along. If it helps, I will happily file a wishlist bug against debhelper. And notify this bug back, when it's ever resolved positively. *g* Not to mention, that the maintainer for debhelper is the submitter of this bug ;o)) I'll happily post some of my ideas on this. > Tagging wontfix, as I haven't the courage to explore this particular > frontier. If you no longer feel this should be done, please close the > bug. Well, if a second opinion counts something: I'd like this to happen too. Elrond
Bug#248539: libxrandr2: No need to conflict with xlibs
Just as a quick add on: Since this package doesn't replace any files in xlibs, it also does not need to have "Replaces: xlibs (<< 4.3.0)" in it. Elrond
Bug#248539: libxrandr2: No need to conflict with xlibs
On Wed, May 12, 2004 at 04:36:17AM -0500, Branden Robinson wrote: [...] > > libxrandr2 does not need to conflict with xlibs (<< 4.3.0). > > I thought I had a reason for this, but if it's not documented, it > doesn't count. I didn't search for that documentation very thoroughly so. I could imagine, that some version of xlibs (something like 4.3.0-0pre-something) had libXrandr 2.0 in it, but the conflict wouldn't catch that. The other obvious thing being libxrandr-dev. This of course has to conflict with xlibs-dev (<< 4.3.0), for the headers, etc. But that's not the issue here. [...] > ># dpkg -S libXrandr > >xlibs-dev: /usr/X11R6/lib/libXrandr.a [...] > > Even that seems to work very well. (I wonder, where > > libXrandr.so is, but that's out of the scope of this bug > > and probably covered in some FAQ.) > > In Debian, .so files are generally in lib*-dev packages, not lib*. Well, xlibs-dev (4.2.1-12.1) does only contain a .a, but anyway, I just checked, libxrandr-dev contains the .so. > May I ask what motivated you to try having both versions of libXrandr on > your machine at the same time? Just curious. The obvious answer _would_ be "I have some weird app dynamicly linked against 1.0". But that's not true. My reason is a bit subtle: I like to update only a small amount of packages at a time. So with some luck, I can install say xbase-clients on a box with say x from debian/stable. This was the reasoning for setting the severity to minor, it might be lowered to wishlist, if you have to. Elrond
Bug#248539: libxrandr2: No need to conflict with xlibs
Package: libxrandr2 Version: 4.3.0.dfsg.1-1 Severity: minor Hi, libxrandr2 does not need to conflict with xlibs (<< 4.3.0). xlibs 4.2.1-12.1 does only contain libxrandr 1.0 and not 2.0. # dpkg --force-conflicts -i libxrandr2_4.3.0.dfsg.1-1_i386.deb this works very well with my xlibs 4.2.1-12.1 and xlibs-dev 4.2.1-12.1 installed. It gives only a warning about the conflict, but not override-stuff. # dpkg -S libXrandr xlibs: /usr/X11R6/lib/libXrandr.so.1.0 xlibs-dev: /usr/X11R6/lib/libXrandr.a xlibs: /usr/X11R6/lib/libXrandr.so.1 libxrandr2: /usr/X11R6/lib/libXrandr.so.2 libxrandr2: /usr/X11R6/lib/libXrandr.so.2.0 Even that seems to work very well. (I wonder, where libXrandr.so is, but that's out of the scope of this bug and probably covered in some FAQ.) Elrond
