Re: Bug#1038761: startx.1: a few remarks and editing fixes for the manual
Control: reassign -1 xinit
Hi!
[ It seems this got misfiled, leaving the bulk of the mail for context. ]
On Wed, 2023-06-21 at 00:30:04 +, Bjarni Ingi Gislason wrote:
> Package: dpkg
> Version: 1.21.22
> Severity: minor
> Tags: patch
>
> Dear Maintainer,
>
> here are a few notes and fixes for the manual.
>
> ###
>
> Input file is startx.1
>
> Change two HYPHEN-MINUSES (code 0x055, 2D) to an em-dash (\(em), if one
> is intended. An en-dash is usually surrounded by a space, while an em-dash
> is used without spaces. "man" (1 byte characters) transforms an en-dash
> (\(en to one HYPHEN-MINUS, and an em-dash to two HYPHEN-MINUSES without
> considering the space around it.
> If "--" are two single "-" (end of options) then use "\-\-".
>
> startx.1:71:startx -- -depth 16
> startx.1:73:startx -- -dpi 100
> startx.1:75:startx -- -layout Multihead
>
> #
>
> Use the word (in)valid instead of (il)legal if not related to legal
> matters.
> See "www.gnu.org/prep/standards".
> Think about translations into other languages!
>
> startx.1:68:the manual page for your X server to determine which arguments
> are legal.
>
> #
>
> Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a
> name for an option.
>
> 57:.RB '--'
> 71:startx -- -depth 16
> 73:startx -- -dpi 100
> 75:startx -- -layout Multihead
>
> #
>
> Wrong distance between sentences.
>
> Separate the sentences and subordinate clauses; each begins on a new
> line. See man-pages(7) ("Conventions for source file layout") and
> "info groff" ("Input Conventions").
>
> The best procedure is to always start a new sentence on a new line,
> at least, if you are typing on a computer.
>
> Remember coding: Only one command ("sentence") on each (logical) line.
>
> E-mail: Easier to quote exactly the relevant lines.
>
> Generally: Easier to edit the sentence.
>
> Patches: Less unaffected text.
>
> The amount of space between sentences in the output can then be
> controlled with the ".ss" request.
>
> 87:is used to start the X session. All discussion of the
>
> #
>
> Split a punctuation mark from a single argument for a two-font macro
>
> 92:.IR .xsession.
>
> #
>
> Output from "test-nroff -man -b -ww -z":
>
>
> [ "test-groff" is a developmental version of "groff" ]
>
> Input file is ./startx.1
>
> Output from test-groff -b -mandoc -dAD=l -rF0 -rHY=0 -t -w w -z :
> an.tmac:/tmp/chk_manuals.temp.Vnx9bq:57: style: .RB expects at least 2
> arguments, got 1
> an.tmac:/tmp/chk_manuals.temp.Vnx9bq:92: style: .IR expects at least 2
> arguments, got 1
>
>
>
> --- startx.1 2023-06-20 23:50:11.0 +
> +++ startx.1.new 2023-06-21 00:13:05.0 +
> @@ -54,7 +54,7 @@ Arguments immediately following the
> command are used to start a client in the same manner as
> .BR xinit (1).
> The special argument
> -.RB '--'
> +.RB ' \-\- '
> marks the end of client arguments and the beginning of server options.
> It may be convenient to specify server options with startx to change on a
> per-session basis the
> @@ -65,14 +65,14 @@ permitted by the
> server and specified in the
> .BR xorg.conf (5)
> configuration. Some examples of specifying server arguments follow; consult
> -the manual page for your X server to determine which arguments are legal.
> +the manual page for your X server to determine which arguments are valid.
> .RS
> .PP
> -startx -- -depth 16
> +startx \-\- \-depth 16
> .PP
> -startx -- -dpi 100
> +startx \-\- \-dpi 100
> .PP
> -startx -- -layout Multihead
> +startx \-\- \-layout Multihead
> .RE
> .PP
> Note that in the Debian system, what many people traditionally put in the
> @@ -84,12 +84,13 @@ instead; this permits the same X environ
> .IR xdm ,
> or
> .I xinit
> -is used to start the X session. All discussion of the
> +is used to start the X session.
> +All discussion of the
> .I .xinitrc
> file in the
> .IR xinit (1)
> manual page applies equally well to
> -.IR .xsession.
> +.IR .xsession .
> Keep in mind that
> .I .xinitrc
> is used only by
Thanks,
Guillem
Bug#1003987: mesa: Texture flicker and corruption with Intel UHD 620 Graphics
Source: mesa Source-Version: 21.3.0~rc1-1 Severity: important Tags: upstream patch Forwarded: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14505 Hi! On Intel UHD 620 Graphics, mesa produces texture flickering and corruption, which was become unbearable with the latest 21.3.x releases. I think these were also present in 21.2.x, but not as prominently. Upstream has a MR (not yet merged) which seems to fix the issue for me (I built the latest mesa packages from sid with that patch). I'd be nice if this could be included. Thanks, Guillem
Bug#982749: apitrace: Switch from libbsd to libmd
Source: apitrace
Source-Version: 9.0+repack-1
Severity: normal
Tags: patch
Hi!
The MD5 functions in libbsd have been superseded by the ones in the
libmd project, and they might be removed in the next SONAME bump. The
current implementations in libbsd are just wrappers for the real
functions from libmd.
Attached a patch fixing this.
Thanks,
Guillem
diff -Nru apitrace-9.0+repack/debian/control apitrace-9.0+repack/debian/control
--- apitrace-9.0+repack/debian/control 2019-11-29 06:21:20.0 +0100
+++ apitrace-9.0+repack/debian/control 2021-02-13 00:10:39.0 +0100
@@ -17,7 +17,7 @@
zlib1g-dev,
libsnappy-dev,
libpng-dev,
- libbsd-dev,
+ libmd-dev,
libprocps-dev,
libgtest-dev,
Standards-Version: 4.4.0
diff -Nru apitrace-9.0+repack/debian/patches/use-system-md5 apitrace-9.0+repack/debian/patches/use-system-md5
--- apitrace-9.0+repack/debian/patches/use-system-md5 2019-11-29 06:17:05.0 +0100
+++ apitrace-9.0+repack/debian/patches/use-system-md5 2021-02-13 00:14:58.0 +0100
@@ -1,10 +1,14 @@
-Description: Use md5 implementation from system libbsd
+Description: Use md5 implementation from system libmd
Forwarded: not-needed
Author: Christopher James Halse Rogers
+---
+ CMakeLists.txt |4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
-@@ -534,9 +534,7 @@ if (CMAKE_EXECUTABLE_FORMAT STREQUAL "EL
+@@ -543,9 +543,7 @@ if (CMAKE_EXECUTABLE_FORMAT STREQUAL "EL
add_definitions (-DHAVE_BACKTRACE=1)
endif ()
@@ -15,14 +19,3 @@
# We use bundled headers for all Khronos APIs, to guarantee support for both
# OpenGL and OpenGL ES at build time, because the OpenGL and OpenGL ES 1 APIs
a/lib/image/image_md5.cpp
-+++ b/lib/image/image_md5.cpp
-@@ -28,7 +28,7 @@
- #include
- #include "image.hpp"
-
--#include "md5.h"
-+#include
-
-
- using namespace std;
diff -Nru apitrace-9.0+repack/debian/patches/use-system-snappy apitrace-9.0+repack/debian/patches/use-system-snappy
--- apitrace-9.0+repack/debian/patches/use-system-snappy 2019-11-29 06:17:05.0 +0100
+++ apitrace-9.0+repack/debian/patches/use-system-snappy 2021-02-13 00:14:58.0 +0100
@@ -6,9 +6,14 @@
Forwarded: not-needed
Author: Christopher James Halse Rogers
+---
+ CMakeLists.txt | 10 +-
+ wrappers/CMakeLists.txt |2 +-
+ 2 files changed, 6 insertions(+), 6 deletions(-)
+
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
-@@ -476,10 +476,10 @@ if (NOT ENABLE_STATIC_SNAPPY)
+@@ -485,10 +485,10 @@ if (NOT ENABLE_STATIC_SNAPPY)
find_package (SNAPPY)
endif ()
if (ENABLE_STATIC_SNAPPY OR NOT SNAPPY_FOUND)
@@ -23,6 +28,15 @@
endif ()
include_directories (${SNAPPY_INCLUDE_DIRS})
+@@ -543,7 +543,7 @@ if (CMAKE_EXECUTABLE_FORMAT STREQUAL "EL
+ add_definitions (-DHAVE_BACKTRACE=1)
+ endif ()
+
+-set (MD5_LIBRARIES bsd)
++set (MD5_LIBRARIES md)
+
+ # We use bundled headers for all Khronos APIs, to guarantee support for both
+ # OpenGL and OpenGL ES at build time, because the OpenGL and OpenGL ES 1 APIs
--- a/wrappers/CMakeLists.txt
+++ b/wrappers/CMakeLists.txt
@@ -79,7 +79,7 @@ target_link_libraries (trace
Bug#944498: libpciaccess0: Can switch from Suggests pciutils to Depends pci.ids
Package: libpciaccess0 Version: 0.14-1 Severity: normal Hi! I've split the pci.ids database into its own source and binary package, which means this package could switch to a Depends (or perhaps a Recommends if that's too much), w/o having to pull in any tools package anymore. Thanks, Guillem
Bug#893366: libwayland-dev: Uninstallable due to conflicting wayland-egl.pc
Package: libwayland-dev Version: 1.14.91-1 Severity: serious Hi! This package ships the file /usr/lib//pkgconfig/wayland-egl.pc which conflicts with the one installed by libegl1-mesa-dev, w/o any Replaces field or similar. The problem also is that the file providing the shared library is also not pulled in by libwayland-dev, so packages that would find the pkg-config file would then fail to build, and they should really not be depending on the shared library directly. Thanks, Guillem
Bug#814313: xorg-server: Using systemd and startx, input does not work anymore
Control: retitle -1 xorg-server: Using startx w/o libpam-systemd, input does not work anymore Hi! On Wed, 2016-02-10 at 18:42:39 +0100, Sven Joachim wrote: > On 2016-02-10 09:39 +0100, Guillem Jover wrote: > > > Source: xorg-server > > Source-Version: 2:1.18.1-1 > > Severity: important > > It would have been better to report the bug against the > xserver-xorg-core binary package, since that includes necessary > information from the bug script which is missing from your report. Sorry about that, I tend to avoid reportbug, so reporting against xserver-xorg-core would not have helped anyway. > > I just logged out and started X again, and no input was working any > > longer (builtin mouse and keyboard, nor hotplugged USB mouse). > > > > On this specific machine I'm using systemd, and I'm starting the X > > server using startx from a Linux console. I've also got the > > xserver-xorg-legacy package installed. This happens as well on another system using sysvinit. Both using the Intel KMS driver. > > I've bisected the packages and it seems this regression got introduced > > in 2:1.18.1-1, as 2:1.18.0-3 works perfectly fine. > > My hunch is that the fix[1] for upstream bug #92894[2] has triggered > this breakage. If I read the code in xorg-wrapper.c correctly, the > version from 1.18.0 would not actually drop root rights even if you have > a KMS driver for your video card(s). Now the KMS detection actually > works, and if you have a kernel graphics driver the wrapper drops root > rights meaning that you _must_ have a working systemd-logind to grant X > access to your input devices. > > Do you have libpam-systemd installed? Ah! I didn't have libpam-systemd installed on neither of the systems (sysvinit and systemd). I just had to restart these systems now anyway, and tried several things. I've now installed libpam-systemd on the system using systemd and things work as expected. For the one using sysvinit, instead I've added needs_root_rights=yes in /etc/X11/Xwrapper.config for now, as I don't want libpam-systemd on that one, this works fine too, and I'll switch to simply fixing the device permissions later on. I guess it would be nice to document this interaction/requirement more explicitly somewhere? Perhaps in the Xorg.wrap man page? But in any case the failing mode is pretty nasty, as the keyboard does not react anymore and you cannot ZAP the server or even switch to a virtual console to terminate it from there, at least the power button here sends ACPI events so the system can be shutdown cleanly. Ideally if root privs are to be dropped, logind is not available, and the input drivers will not have access to the input devices then the server could error out? But I'm not sure if that's architecturally sane. I guess the second best option would be, if logind is not present then the server perhaps should simply not drop root privs. And at least the server could print something on the Xorg.log. (But given that this is due to ignoring Recommends, I guess you might want to lower the severity.) Thanks, Guillem
Bug#814313: xorg-server: Using systemd and startx, input does not work anymore
Source: xorg-server
Source-Version: 2:1.18.1-1
Severity: important
Hi!
I just logged out and started X again, and no input was working any
longer (builtin mouse and keyboard, nor hotplugged USB mouse).
On this specific machine I'm using systemd, and I'm starting the X
server using startx from a Linux console. I've also got the
xserver-xorg-legacy package installed.
I've bisected the packages and it seems this regression got introduced
in 2:1.18.1-1, as 2:1.18.0-3 works perfectly fine.
I've diffed the Xorg.N.log{.old,} files (after stripping the timestamps)
and there's no relevant difference.
Thanks,
Guillem
Re: Removing old unmaintained X drivers
Hi! On Thu, 2013-09-26 at 23:26:22 +0200, Julien Cristau wrote: we (the debian X Strike Force) are thinking of removing the following packages from the archive, unless somebody steps up (soon) to take care of them. I assume here you mean maintaining them in Debian (or perhaps upstream too?). The reason is they see 0 testing, nobody maintains them upstream, if you're lucky people keep some of them building when APIs change, if you're very lucky they get a release with all the build fixes once in a while, and it's likely most of them don't have any users anymore. Several of the below modules are claimed as maintained in upstream's MAINTAINERS file. If that's not the case I guess it would be nice to get that updated so that it's clear what's the status on them and so other people can step up there if they feel like it. While it would probably be easy to get them to stop FTBFS right now, it doesn't seem worth it to keep all of those drivers around with the maintenance overhead that comes with that if nobody's going to notice anyway. Sure, although several of them have newer releases upstream or fixes in master that make them build from source. So please speak up if you want to see one of these in jessie. I'll keep an eye on the tdfx one upstream. If it got to be removed from Debian, I might consider taking over maintainership here. xserver-xorg-video-voodoo Maintained upstream. New release builds. xserver-xorg-video-chips xserver-xorg-video-glint xserver-xorg-video-i128 xserver-xorg-video-i740 xserver-xorg-video-rendition xserver-xorg-video-tdfx xserver-xorg-video-tga xserver-xorg-video-tseng Maintained upstream. Master builds. xserver-xorg-video-s3virge xserver-xorg-video-suncg14 xserver-xorg-video-suncg3 xserver-xorg-video-suncg6 xserver-xorg-video-sunleo xserver-xorg-video-suntcx Unmaintained upstream. New release builds. xserver-xorg-video-apm xserver-xorg-video-ark Unmaintained upstream. Master builds. xserver-xorg-video-newport xserver-xorg-video-s3 xserver-xorg-video-sis Unmaintained upstream. Thanks, Guillem -- 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/20130927172737.ga25...@gaara.hadrons.org
Bug#706114: xfonts-utils: insufficient zlib1g dependency
On Wed, 2013-04-24 at 22:06:55 -0400, Michael Gilbert wrote: So the dependencies are correct. The only problem is due to gsfonts-x11 postinst's script calling: update-fonts-dir → mkfontdir → mkfontscale While the new xfonts-utils package has been unpacked, but not configured. This is either a problem in xfonts-utils's update-fonts-dir, or in debhelper's dh_installxfonts support inserting those snippets. In terms of getting this fixed quickly for wheezy, couldn't that be addressed with a Pre-Depends: xfonts-utils in gsfonts-x11? That would only solve the problem for gsfonts-x11, but not for anything else using dh_installxfonts. I think, to be safe the hack would need to be applied to xfonts-utils's dependencies, which is all kinds of ugly, but at least should always work, at the cost of complicating the upgrade path. I guess the correct solution though, is to change update-fonts-* and any other script in xfonts-utils calling mkfont* from other maintainer scripts, to only run if xfonts-utils itself is configured or being configured, and calling these through xfonts-utils maintainer scripts too, so that if xfonts-utils and something else using it like gsfonts-x11 are both unpacked on the same run, the actual update-fonts-* executions will be delayed until xfonts-utils is itself configured, at which point the scripts should be able to run. I don't think this would be much more difficult to prepare. Regards, Guillem -- 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/20130425083909.ga6...@gaara.hadrons.org
Bug#706114: xfonts-utils: insufficient zlib1g dependency
On Thu, 2013-04-25 at 14:51:29 +0200, Andreas Beckmann wrote: On 2013-04-25 10:39, Guillem Jover wrote: I guess the correct solution though, is to change update-fonts-* and any other script in xfonts-utils calling mkfont* from other maintainer scripts, to only run if xfonts-utils itself is configured or being configured, and calling these through xfonts-utils maintainer scripts too, so that if xfonts-utils and something else using it like gsfonts-x11 are both unpacked on the same run, the actual update-fonts-* executions will be delayed until xfonts-utils is itself configured, at which point the scripts should be able to run. I don't think this would be much more difficult to prepare. Sounds like a job for triggers (but there is currently a dpkg bug that causes it to run triggers for packages that are not configured (or their dependencies are not) Right, sorry, I didn't mention triggers exactly for that reason. Although this one should be easier to switch during jessie, as these packages do not need to await processing from xfonts-utils, which should avoid the cycles that enable that bug. Thanks, Guillem -- 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/20130425172002.ga12...@gaara.hadrons.org
Bug#706114: xfonts-utils: insufficient zlib1g dependency
Control: reassign -1 xfonts-utils/1:7.7~1 On Wed, 2013-04-24 at 22:18:59 +0200, Andreas Beckmann wrote: Package: dpkg-dev,xfonts-utils Version: 1:7.7~1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Control: found -1 1.16.10 during an upgrade test with piuparts I noticed misbehavior of mkfontscale (which was ignored and therefore the upgrade did not fail): Preparing to replace xfonts-utils 1:7.5+2 (using .../xfonts-utils_1%3a7.7~1_amd64.deb) ... Unpacking replacement xfonts-utils ... Preparing to replace gsfonts-x11 0.21 (using .../gsfonts-x11_0.22_all.deb) ... Unpacking replacement gsfonts-x11 ... mkfontscale: /usr/lib/libz.so.1: version `ZLIB_1.2.5.2' not found (required by /usr/lib/x86_64-linux-gnu/libfontenc.so.1) Selecting previously unselected package libijs-0.35. Unpacking libijs-0.35 (from .../libijs-0.35_0.35-8_amd64.deb) ... ... Preparing to replace zlib1g 1:1.2.3.4.dfsg-3 (using .../zlib1g_1%3a1.2.7.dfsg-13_amd64.deb) ... Unpacking replacement zlib1g:amd64 ... The symbols file has ZLIB_1.2.5.2@ZLIB_1.2.5.2 1:1.2.6 but xfonts-utils has Depends: ... , zlib1g (= 1:1.1.4), ... Rebuilding xfonts-utils does not change the dependency, so there seems to be a toolchain problem somewhere. Therefore I'm assigning to both dpkg-dev (for dpkg-shlibdeps) and xfonts-utils. The problem is with libfontenc.so.1, not mkfontscale: $ objdump -p /usr/lib/x86_64-linux-gnu/libfontenc.so.1 | grep ZLIB 0x07e5d032 0x00 04 ZLIB_1.2.5.2 $ objdump -p /usr/bin/mkfontscale | grep ZLIB $ dpkg -s libfontenc1:amd64 | grep '^Depends:' Depends: libc6 (= 2.7), zlib1g (= 1:1.2.6) So the dependencies are correct. The only problem is due to gsfonts-x11 postinst's script calling: update-fonts-dir → mkfontdir → mkfontscale While the new xfonts-utils package has been unpacked, but not configured. This is either a problem in xfonts-utils's update-fonts-dir, or in debhelper's dh_installxfonts support inserting those snippets. Please, feel free to reassign if I missed something broken in dpkg-dev. Thanks, Guillem -- 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/20130424210447.ga16...@gaara.hadrons.org
Re: Bug#693922: dpkg: amd64 dpkg refuses to install i386 package when dependencies are installed
Control: severity -1 whishlist Control: clone -1 -2 Control: reassign -1 xserver-common Control: retitle -1 xserver-common: Please mark as M-A:foreign Control: reassign -2 keyboard-configuration Control: retitle -2 keyboard-configuration: Please mark as M-A:foreign Hi! [ Beware, I've not checked if other binary packages from the producing source package might need marking too. ] On Wed, 2012-11-21 at 23:26:14 +, Noel David Torres Taño wrote: On Miércoles, 21 de noviembre de 2012 20:01:17 Guillem Jover wrote: On Wed, 2012-11-21 at 19:40:38 +, Noel David Torres Taño wrote: Package: dpkg Version: 1.16.9 Severity: important *** Please consider answering these questions, where appropriate *** * What led up to the situation? amd64 system trying to install an i386 package required for multiarch setup of Wine * What exactly did you do (or not do) that was effective (or ineffective)? dpkg -i * What was the outcome of this action? error * What outcome did you expect instead? install *** End of the template - remove these lines *** root@host:~# LANG=C dpkg -l xserver-common keyboard-configuration Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig | -pend | |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) | ||/ Name Version Architecture ||Description +++-=-=-=-=== = ii keyboard-configuration1.87 all system-wide keyboard preferences ii xserver-common 2:1.12.4-3all common files used by various X servers root@host:~# LANG=C dpkg -i xserver-xorg-core_2%3a1.12.4-3_i386.deb (Reading database ... 318831 files and directories currently installed.) Preparing to replace xserver-xorg-core 2:1.12.4-3 (using xserver-xorg-core_2%3a1.12.4-3_i386.deb) ... Unpacking replacement xserver-xorg-core ... dpkg: dependency problems prevent configuration of xserver-xorg-core: xserver-xorg-core depends on xserver-common (= 2:1.12.4-3). xserver-xorg-core depends on keyboard-configuration. dpkg: error processing xserver-xorg-core (--install): dependency problems - leaving unconfigured Processing triggers for libglx-nvidia-alternatives ... Processing triggers for man-db ... Errors were encountered while processing: xserver-xorg-core You can see that dependencies are installed, but dpkg refuses to install xserver-xorg-core That's as expected as per the current spec, arch:all packages are treated as arch:native, so the dependencies are not fulfilled. For now (at least) those packages would need to be marked M-A:foreign to be able to install a foreign xserver-xorg-core, so not a bug in dpkg. What I don't really understand is why you need to install xserver-xorg-core:i386 to be able to install wine:i386? Many thanks. This seems to be a bug in the multiarch documentation instead. What exact documentation? Most of it is mainly on wikis currently, but I think this should be covered. How can I (or where can I read how to) mark as foreign as you suggest? That's something that needs to be done on the source package, so it needs to go through the maintainer. I've reassigned this bug to those packages now. Please note that I need the :all package to fulfill dependencias both for xserver-xorg-core:i386 and for xserver-xorg-core:amd64 Well these are not co-installable, but the marking is needed anyway in case one wants the foreign X server. About wine... I have wine:i386 corerctly installed, but it does not run the games properly without libgl1-nvidia-glx:i386 whose dependencies chain to this. I still don't see why using foreign wine with a foreign libgl1-nvidia-glx would require to install a foreign X server too, AFAIR I've used such setup but w/ a foreign -mesa-glx and mesa-dri package. OTOH wanting to use a foreign X server does not invalidate these bug reports, so I guess this does not matter much. Thanks, Guillem -- 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/20121128165227.gb18...@gaara.hadrons.org
Bug#385575: libgl1-mesa-dri: Is it possible to split up the package into hardware-specific binaries?
On Sun, 2010-04-04 at 22:35:56 +0200, Cyril Brulebois wrote: tag 385575 wontfix thanks Gerrit Jan Baarda gjbaa...@xs4all.nl (01/09/2006): Is it possible to package it more or less like the xserver-xorg-video-* packages, so that only the modules that are actually used need to be installed? I don't think we're going to spend time doing so, tagging the bug wontfix for now. So, would you reconsider if a patch was to be provided? The size issue would be one reason, other reasons would be being able to switch the libglide3 Suggests into a Depends (but I can understand how you might not find this really important :), not requiring libdrm backends for drivers one does not use, and being able to Recommend a dri specific driver from the xorg video driver. thanks, guillem -- 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/20100609202114.ga13...@gaara.hadrons.org
Bug#492099: xserver-xorg-video-glide: glide2 only available on i386.
Hi, On Wed, 2008-07-23 at 22:38:41 +0200, Brice Goglin wrote: Kurt Roeckx wrote: Package: xserver-xorg-video-glide Version: 1.0.1-1 You're build depending on libglide2-dev which is only availableon i386, and have marked the packages as arch any. Can't you use libglide3-dev instead which is available on i386 alpha ia64 amd64? The Glide hardware can work in a non-x86 host, right? That's right. The problem though, is that the libglide3 package in Debian does not support Voodoo 2 boards, which libglide2 does. We have support for Voodoo 2 now in glide3x upstream, but I've not yet packaged that for Debian, and I don't think I'm going to do this close to the freeze. But for lenny+1 though, I'd like to get rid of libglide2 by switching the few remaining packages to ligblide3. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xserver-xorg-video-glide
Hi, On Wed, 2008-06-18 at 20:14:37 +0200, Brice Goglin wrote: On Guillem's request, I've prepared a packaging of the xf86-video-glide driver. This driver is for Voodoo 1 and 2 boards. From what I understand, it does not manage any PCI device (so there's no /usr/share/xserver-xorg/pci/glide.ids). And you'll get better perf if you load the 3dfx kernel driver (so it recommends device3dfx-source). Please somebody review the attached patch. You actually need the module for libglide2 (but you got that right in the package description). I released a new upstream version of it this morning as well, so that it builds with latest kernels with CONFIG_PCI_LEGACY disabled, and few other fixes. Guillem or anybody having such a graphic board, you can try the driver for i386 at: http://people.debian.org/~bgoglin/glide/ Thanks for this! I'll be testing in the coming next days. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481811: Bug in Debian Sid: monitor cannot be reconfigured
reassign 481811 xserver-xorg thanks On Sun, 2008-05-18 at 20:18:54 +0200, Uwe Bugla wrote: Package: dpkg, xserver-xorg I am running the latest Debian Lenny / Sid combination and wanted to adjust a workstation to another monitor. Traditionallly that's done with the following command: dpkg-reconfigure xserver-xorg. That command is not provided by dpkg, it's from debconf (yes, it's a bit missleading). If I run that command, the script ends up with the question whether to emulate a 3-button mouse or not. There is no questioning for graphics card RAM, horizontal and vertical frequency range, colour depth, name of xserver, producer of graphics card and so on. Someone seems to have screwed up the configure script. If you set up Debian Lenny from scratch everything is fine, but if you try to reconfigure the xserver you seem to be lost. This bug appears independently from the type of xserver - it's part of the configure option of the dpkg-Package. If there's any problem, it would be in xserver-xorg debconf support, but I'll leave this decision to the XSF. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465181: xf86-input-tslib: Please rename to xserver-xorg-input-tslib
Package: xf86-input-tslib Version: 0.0.4-3 Severity: wishlist [ XSF CCed ] Hi, Could you please rename the packages (source and binary I guess, to avoid confusion; that will also imply requesting the removal of the old packages from the archive) to xserver-xorg-input-tslib or similar, to follow the current XSF naming scheme? This would be clearer for the users. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#454057: please move dpkg-architecture
Hi, On Wed, 2007-12-05 at 20:02:34 +0100, Aurelien Jarno wrote: Raphael Hertzog a écrit : On Wed, 05 Dec 2007, Julien Cristau wrote: Maybe type-handling could be split with an empty package whose sole purpose is to Provides some virtual packages while type-handling stays the program with its dpkg-dev dependency. I think this solution would be my first preference. I've been meaning to discuss this with the XSF but at some point forgot about it. I'd really like if you guys could switch that package to arch:any (reasons given below). My preference would be for dpkg to allow 'Depends: foo [arch]' in arch:all packages, but failing that, I agree. Right now the support for the [arch] syntax is only in the perl code and not at all in the C part that concerns dpkg. Adding it there is a non-trivial effort and would probably also require changes in apt-based software. The '[arch]' is supported in the perl code but the dependencies are reduced at package build time. The C code is not the problem with this solution (implementing this is not that difficult, although the arch wildcard support would have to be reimplemented in C), the main problem is breaking all programs around that might be parsing the dependency fields, like sbuild, pbuilder, apt-based, etc. Aurélien, what do you think of the idea of change concerning type-handling ? From my point of view, we should get rid of type-handling as soon as possible. This is actually a big and buggy hack to workaround dpkg/apt lacks. Agreed, and that was our main goal when we (although it has been Aurélien who has done all the work) took over that package. Part of the failure is probably on me for not having pushed enough for the arch wildcards... The first think I would like to see, is [os] or [cpu] support in dpkg-dev *enabled* and *allowed* for arch-any packages. This would replace type-handling in 90% of the cases. I suppose you mean the arch wildcards like '[os-any]' and '[any-cpu]', this has been supported since latest part of the etch release which is the most annoying part type-handling is working around and that's the reason it got added then, to be able to easily get rid of type-handling. The only reason we cannnot use it now is sbuild, I sent a mail to Ryan some time ago but he didn't reply. For the [arch] support in binary-all packages, I guess the main use case (if not all) is for metapackages depending on various packages. I don't really see the problem (except the policy, but that can be changed) of using binary-any packages for those metapackages, even if there is no binary files insude them. They are by definition very small, so that won't bloat the archive. I agree. There's probably really few cases where an arch:all needs to Depend on a package only present in a specific architecture. I'm not sure it's worth the effort, also ideally we should have less arch specific packages. If there are still some cases not solved by this approach, I guess the package that should provide the not+sparc package is dpkg. It is always installed on systems, so strange behaviours of apt with virtual packages is avoided. Right, but I'm a bit uneasy on this solution of abusing the dependencies for that purpose. I'll be closing this bug report and the one on type-handling about splitting the package in few days. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415800: xorg-server: bogus patch for xorg.conf manpage
Package: xorg-server Version: 2:1.1.1-20 Severity: minor Tags: patch Hi, There's currently a bogus patch for the xorg.conf manpage. Attached a patch for the patch which fixes this. ragards, guillem --- debian/patches/17_ignoreabi.diff 2006-12-10 20:33:51.0 +0200 +++ debian/patches/17_ignoreabi.diff 2006-09-24 05:42:59.0 +0300 @@ -52,10 +52,10 @@ .B Terminate action and, if found, use XKEYBOARD for processing actions, otherwise the builtin handler will be used. -++ .TP 7 -++ .BI Option \*qIgnoreABI\*q \*q boolean \*q -++ Allow modules built for a different, potentially incompatible version of -++ the X server to load. Disabled by default. ++.TP 7 ++.BI Option \*qIgnoreABI\*q \*q boolean \*q ++Allow modules built for a different, potentially incompatible version of ++the X server to load. Disabled by default. .SH MODULE SECTION The .B Module
Bug#413454: xorg: allow GNU/kFreeBSD console users to start X
Package: xorg
Version: 1:7.1.0-13
Severity: wishlist
Tags: patch
User: [EMAIL PROTECTED]
Usertags: kfreebsd
Hi,
Currently on Debian GNU/kFreeBSD systems a user cannot start X using
the wrapper w/o being root, or changing in Xwrapper.config allowed_users
to anybody (which is a security threat).
The attached patch adds console detection support, and some messages
at build and run time to allow the user to know what failed on
unsupported systems.
regards,
guillem
diff -Nru xorg-7.1.0/debian/local/xserver-wrapper.c xorg-7.1.0/debian/local/xserver-wrapper.c
--- xorg-7.1.0/debian/local/xserver-wrapper.c 2007-02-13 12:02:09.0 +0200
+++ xorg-7.1.0/debian/local/xserver-wrapper.c 2007-03-05 07:05:32.0 +0200
@@ -102,7 +102,12 @@
# include sys/resource.h
#endif
+#if defined(__linux__)
#define VT_MAJOR_DEV 4
+#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
+#include sys/consio.h
+#endif
+
#define X_WRAPPER_CONFIG_FILE /etc/X11/Xwrapper.config
#define X_SERVER_SYMLINK_DIR /etc/X11
#define X_SERVER_SYMLINK /etc/X11/X
@@ -138,10 +143,37 @@
}
static int
-checkSecLevel(SecurityLevel level)
+onConsole()
{
+#if defined(__linux__)
struct stat s;
+ /* see if stdin is a virtual console device */
+ if (fstat(0, s) != 0) {
+(void) fprintf(stderr, X: cannot stat stdin\n);
+return FALSE;
+ }
+ if (S_ISCHR(s.st_mode)
+ ((s.st_rdev 8) 0xff) == VT_MAJOR_DEV
+ (s.st_rdev 0xff) 64) {
+return TRUE;
+ }
+#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
+ int idx;
+
+ if (ioctl(0, VT_GETINDEX, idx) != -1)
+return TRUE;
+#else
+#warning This program needs porting to your kernel.
+ (void) fprintf(stderr, X: unable to determine if running on a console\n);
+#endif
+
+ return FALSE;
+}
+
+static int
+checkSecLevel(SecurityLevel level)
+{
switch (level) {
case RootOnly:
if (getuid() == 0) { /* real uid is root */
@@ -152,16 +184,7 @@
break;
case Console:
if (getuid() == 0) return TRUE; /* root */
-/* see if stdin is a virtual console device */
-if (fstat(0, s) != 0) {
- (void) fprintf(stderr,X: cannot stat stdin\n);
- return FALSE;
-}
-if (S_ISCHR(s.st_mode)
-((s.st_rdev 8) 0xff) == VT_MAJOR_DEV
-(s.st_rdev 0xff) 64) {
- return TRUE;
-}
+if (onConsole()) return TRUE;
break;
case Anybody:
return TRUE;
Bug#202096: xfs: plan for running as non-root user and better FPE handling
Hi, On Mon, 2007-02-19 at 23:20:22 +0100, Brice Goglin wrote: While cleaning the XSF BTS, I found this old wishlist about your plan to run XFs as non-root user. The thread ended in november 2003 but I didn't see anything happening accordingly. Did the idea get abandoned? Should I keep the wishlist open? Yes, I think we should definitely fix this for lenny. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388998: xserver-xorg-video-tdfx: Missing include headers
On Sun, 2006-09-24 at 12:12:43 +0300, Daniel Stone wrote: On Sun, Sep 24, 2006 at 05:22:07AM +0300, Guillem Jover wrote: The problem here is that xserver-xorg-video-tdfx is lacking some included headers, and the getsecs macro does not get expanded, so module ends up with an unresolvable symbol which makes X crash. The error can only be seen on the console. Attached a patch which can be imported into the quilted package. It fixes a missing header for the abs function as well. Hm. xf86_ansic.h is dead and shouldn't be used: you should use stdlib and friends instead. It's being used by the current ati driver as well, I was just following example. ;) regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388998: xserver-xorg-video-tdfx: Missing include headers
tags 388998 patch thanks Hi, The problem here is that xserver-xorg-video-tdfx is lacking some included headers, and the getsecs macro does not get expanded, so module ends up with an unresolvable symbol which makes X crash. The error can only be seen on the console. Attached a patch which can be imported into the quilted package. It fixes a missing header for the abs function as well. regards, guillem Index: xserver-xorg-video-tdfx-1.2.1/src/tdfx_driver.c === --- xserver-xorg-video-tdfx-1.2.1.orig/src/tdfx_driver.c2006-09-24 05:07:32.0 +0300 +++ xserver-xorg-video-tdfx-1.2.1/src/tdfx_driver.c 2006-09-24 05:03:09.0 +0300 @@ -46,6 +46,8 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN * Overlay planes */ +#include stdlib.h + /* * These are X and server generic header files. */ Index: xserver-xorg-video-tdfx-1.2.1/src/tdfx_priv.c === --- xserver-xorg-video-tdfx-1.2.1.orig/src/tdfx_priv.c 2006-09-24 05:07:16.0 +0300 +++ xserver-xorg-video-tdfx-1.2.1/src/tdfx_priv.c 2006-09-24 04:56:41.0 +0300 @@ -4,11 +4,13 @@ #include config.h #endif +#include tdfx.h + #include xf86.h +#include xf86_ansic.h/* For getsecs() */ #include xf86_OSproc.h #include xf86fbman.h #include compiler.h -#include tdfx.h /* Memory layout of card is as follows:
Bug#387597: x11proto-fonts-dev: missing dependency on x11proto-core-dev
Package: x11proto-fonts-dev Version: 2.0.2-4 Severity: important Hi, This package contains only headers, and those include some external ones, which are not represented in the dependencies: #include X11/Xdefs.h #include X11/Xfuncproto.h #include X11/Xmd.h #include X11/Xproto.h All those includes can be found in the x11proto-core-dev package. I'm not setting the severity to RC because, even if this is making xfstt FTBFS, it was my fault to switch to this more fine grained dependency (from libfs-dev). ;) regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321641: libfs-dev: Missing depends on packages providing needed header files
Package: libfs-dev Version: 6.8.2.dfsg.1-4 Severity: serious Some header files in this package include external headers from other packages, but those are not listed in the Dependency field, thus causing other packages to FTBFS. X11/fonts/FS.h: #include X11/fonts/fsmasks.h X11/fonts/FS.h: #include X11/Xdefs.h X11/fonts/FSlib.h: #include X11/Xfuncproto.h $ dpkg -S X11/fonts/fsmasks.h xlibs-static-dev: /usr/X11R6/include/X11/fonts/fsmasks.h $ dpkg -S X11/Xdefs.h x-dev: /usr/X11R6/include/X11/Xdefs.h $ dpkg -S X11/Xfuncproto.h x-dev: /usr/X11R6/include/X11/Xfuncproto.h Please add the required packages (xlibs-static-dev and x-dev) in the Depdency field, or if xlibs-static-dev is supposed to be phased out, move the needed files (or just all files remaining under X11/fonts/) to libfs-dev. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294320: xfree86: fsListFontsWithXInfo lacks sanity check for FS_Error
Package: xfree86
Version: 4.3.0.dfsg.1-10+SVN
Severity: important
Tags: patch
Hi,
This patch fixes an X server segfault when a font server returns a
FS_Error for a fsListFontsWithXInfo request.
This is the case of xfstt, that currently returns a FS_Error for this
request.
This can be tested easily by installing xfstt and then running
xlsfonts -l.
Patch tested and attached.
regards,
guillem
diff -Naurp xc.orig/lib/font/fc/fserve.c xc/lib/font/fc/fserve.c
--- xc.orig/lib/font/fc/fserve.c2005-02-02 08:03:13.0 +0100
+++ xc/lib/font/fc/fserve.c 2005-02-02 08:28:14.0 +0100
@@ -2332,7 +2332,7 @@ fs_read_list_info(FontPathElementPtr fpe
_fs_free_props (binfo-info);
rep = (fsListFontsWithXInfoReply *) fs_get_reply (conn, ret);
-if (rep == 0)
+if (!rep || rep-type == FS_Error)
{
if (ret == FSIO_BLOCK)
return StillWorking;
Bug#260099: xlibmesa-dri: [tdfx_dri] should dlopen() libglide3.so.x, not libglide3.so
On Sat, Aug 14, 2004 at 08:43:38AM +0200, Guillem Jover wrote: As promised on IRC, here comes the patch for this bug. I'll be uploading a fixed glide packages once that is going to be uploaded. Ok, as requested by Branden on IRC I tested this patch. I built r1741 (I got a FTBFS and a fix that I'm filing separately), installed the new xfree86 packages and did a mv /usr/lib/libglide3.so /tmp, restarted X, and did a glxinfo that gave correct hw accelerated info. regards, guillem
Bug#268116: xfree86: may FTBFS if current locale makes sort ordering differ
Package: xfree86 Version: 4.3.0.dfsg.1-6+SVN (r1741) Severity: important Tags: patch Hi, While building r1741 to test the patch on #260099, I got a FTBFS in the MANIFEST check. The problem here is that one sort uses LC_ALL=C and the others does not, so if the current locale is different from C it will use a differenr sorting order. On my build system I had LANG=C, LC_COLLATE=ca_ES and LC_CTYPE=ca_ES. Attached is a trivial patch (against trunk's HEAD) that solves this possible problem, thus not RC severity, although I think it should get into -6. regards, guillem Index: rules === --- rules (revision 1755) +++ rules (working copy) @@ -352,12 +352,12 @@ # Construct MANIFEST files from MANIFEST.$(ARCH).in and # MANIFEST.$(ARCH).all or MANIFEST.all. if expr $(findstring -DBuildFonts=NO,$(IMAKE_DEFINES)) : -DBuildFonts=NO /dev/null 21; then \ - sort -u debian/MANIFEST.$(ARCH).in debian/MANIFEST.$(ARCH); \ + LC_ALL=C sort -u debian/MANIFEST.$(ARCH).in debian/MANIFEST.$(ARCH); \ else \ if [ -e debian/MANIFEST.$(ARCH).all ]; then \ - sort -u debian/MANIFEST.$(ARCH).in debian/MANIFEST.$(ARCH).all debian/MANIFEST.$(ARCH); \ + LC_ALL=C sort -u debian/MANIFEST.$(ARCH).in debian/MANIFEST.$(ARCH).all debian/MANIFEST.$(ARCH); \ else \ - sort -u debian/MANIFEST.$(ARCH).in debian/MANIFEST.all debian/MANIFEST.$(ARCH); \ + LC_ALL=C sort -u debian/MANIFEST.$(ARCH).in debian/MANIFEST.all debian/MANIFEST.$(ARCH); \ fi; \ fi # confirm that the installed file list has not changed
Bug#260099: xlibmesa-dri: [tdfx_dri] should dlopen() libglide3.so.x, not libglide3.so
tags 260099 patch
thanks
Hi,
As promised on IRC, here comes the patch for this bug. I'll be uploading
a fixed glide packages once that is going to be uploaded.
regards,
guillem
diff -Naur xc/lib/GL/mesa/src/drv/tdfx~/tdfx_context.c
xc/lib/GL/mesa/src/drv/tdfx.new/tdfx_context.c
--- xc/lib/GL/mesa/src/drv/tdfx~/tdfx_context.c 2004-08-14 08:24:52.0
+0200
+++ xc/lib/GL/mesa/src/drv/tdfx/tdfx_context.c 2004-08-14 08:22:34.0
+0200
@@ -707,7 +707,7 @@
*/
GLboolean tdfxInitGlide(tdfxContextPtr tmesa)
{
- static const char *defaultGlide = libglide3.so;
+ static const char *defaultGlide = libglide3.so.3;
const char *libName;
void *libHandle;
@@ -719,10 +719,10 @@
switch (tmesa-fxScreen-deviceID) {
case PCI_CHIP_BANSHEE:
case PCI_CHIP_VOODOO3:
- libName = libglide3-v3.so;
+ libName = libglide3_h3.so.3;
break;
case PCI_CHIP_VOODOO5: /* same as PCI_CHIP_VOODOO4 */
- libName = libglide3-v5.so;
+ libName = libglide3_h5.so.3;
break;
default:
{
Bug#260099: xlibmesa-dri: [tdfx_dri] should dlopen() libglide3.so.x, not libglide3.so
Hi, On Mon, Jul 26, 2004 at 23:28:17 +0200, Branden Robinson wrote: On Sun, Jul 18, 2004 at 03:46:03PM +0200, Hendrik Sattler wrote: direct rendering is disabled until libglide3-dev is installed since libglide3.so is dlopened which is (due to Debian policy, I guess) only in package libglide3-dev. Thus, this package needs to Suggest: libglide3-dev and not libglide3 (pul led in by libglide3-dev) unless you get the maintainer to not follow policy, here. Yes, that was caused by glide (2002.04.10-6) fixing #242063, I've reverted that on glide (2002.04.10-8). Hmm. I am thinking the tdfx Mesa DRI module should dlopen the object by its name *including* the shared object major version number. Yes that's what should happen ideally, and I'll not change glide again until the module loads the proper file. After all, if that major version number changes, any object dlopen()ing it will probably need to be aware of that fact, as the interface will have changed in an incompatible way. In my view it's kind of naïve to expect otherwise. The only problem I see is that third party applications may expect those files to be present and to not have a different ABI. But that's of no concern to Debian and we should try to do the correct thing. On the other hand glide is used as well on Windows and DOS so to not incur into DLL hell, =) we have to place the major number in the file itself, and also so we're expected to not break the ABI. regards, guillem
Bug#255270: xfree86: libglide3 has now ia64 and amd64 support
Hi Branden, On Wed, Jul 14, 2004 at 11:19:13AM -0500, Branden Robinson wrote: On Sat, Jun 19, 2004 at 11:58:45PM +0200, Guillem Jover wrote: I've ported libglide3 to amd64 and ia64. So now xfree86 can Build-Depend on libglide3-dev on those arches. I've integrated this patch: $ svn log -r 1640 svn://necrotic.deadbeast.net/xfree86 Oh, sorry to have missed some stuff in the patch. If you and your fellow Glide enthusiasts could test the XFree86 SVN trunk on i386, amd64, ia64, and alpha, I sure would appreciate it. Ok I've build trunk r1640 (trunk r1685 at the time didn't build correclty, suppose it's a known issue) and tested it on i386. Report follows: [EMAIL PROTECTED]:~$ uname -a Linux zulo 2.6.6-zulo #1 Tue May 11 12:05:18 CEST 2004 i586 GNU/Linux [EMAIL PROTECTED]:~$ X -version This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to XFree86@XFree86.Org and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs). XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-6+glide 20040725043259 [EMAIL PROTECTED]) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.6.7-haydn i686 [ELF] Build Date: 25 July 2004 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present OS Kernel: Linux version 2.6.6-zulo ([EMAIL PROTECTED]) (gcc version 2.95.4 20011002 (Debian prerelease)) #1 Tue May 11 12:05:18 CEST 2004 [EMAIL PROTECTED]:~$ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: VA Linux Systems, Inc. OpenGL renderer string: Mesa DRI 20020221 Voodoo4 x86/MMX/3DNow! OpenGL version string: 1.2 Mesa 4.0.4 OpenGL extensions: GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_packed_pixels, GL_EXT_paletted_texture, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_HP_occlusion_test, GL_IBM_rasterpos_clip, GL_MESA_window_pos, GL_NV_texgen_reflection glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 1 24 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0x24 24 tc 1 24 0 r . . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow 0x25 24 tc 1 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x26 24 tc 1 24 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x27 24 tc 1 24 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0x28 24 tc 1 24 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow 0x29 24 tc 1 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2a 24 tc 1 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2b 24 dc 1 24 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0x2c 24 dc 1 24 0 r . . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow 0x2d 24 dc 1 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2e 24 dc 1 24 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2f 24 dc 1 24 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0x30 24 dc 1 24 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow 0x31 24 dc 1 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x32 24 dc 1 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow regards, guillem
Bug#255270: xfree86: libglide3 has now ia64 and amd64 support
Hi,
On Wed, Jul 14, 2004 at 11:19:13AM -0500, Branden Robinson wrote:
On Sat, Jun 19, 2004 at 11:58:45PM +0200, Guillem Jover wrote:
I've ported libglide3 to amd64 and ia64. So now xfree86 can Build-Depend
on libglide3-dev on those arches.
I've integrated this patch:
$ svn log -r 1640 svn://necrotic.deadbeast.net/xfree86
Thanks Branden!
If you and your fellow Glide enthusiasts could test the XFree86 SVN trunk
on i386, amd64, ia64, and alpha, I sure would appreciate it.
Instructions[1] for building the trunk are available.
[1] http://necrotic.deadbeast.net/xsf/XFree86/HACKING.txt
Could someone with an amd64, ia64 or alpha (I'll take care of i386)
and a 3Dfx card with any of the following chipsets:
Voodoo Banshee, Voodoo 3, Voodoo 4 or Voodoo 5
build an xfree86 package from XSF trunk (you should have already a
libglide3{-dev,} build for your arch) and report back if it does
hardware acceleration (glxinfo) or any build problem to this bug
report?
thanks,
guillem
Bug#255270: xfree86: libglide3 has now ia64 and amd64 support
On Sat, Jun 19, 2004 at 11:58:45PM +0200, Guillem Jover wrote: I've ported libglide3 to amd64 and ia64. So now xfree86 can Build-Depend on libglide3-dev on those arches. Attached the patch (against branches/4.3.0/sid) that enables those. Hmm Imake *is not* autoconf... I forgot to enable the real stuff. O: Ok, here is the second patch that should be applied with addition to the first one. I could merge debian/patches/003_linux.cf_and_xfree86.cf.diff with this patch if desired. I've not done so because don't know how do you want to handle this. regards, guillem --- xc.old/config/cf/linux.cf 2004-06-21 04:07:32.0 +0200 +++ xc/config/cf/linux.cf 2004-06-21 03:52:01.0 +0200 @@ -222,11 +222,11 @@ #define HasGlide2 YES #define Glide2IncDir /usr/include/glide # endif /* i386Architecture */ -/* Glide3 only works on alpha and i386. */ -# if defined(i386Architecture) || defined(AlphaArchitecture) +/* Glide3 only works on alpha, amd64, ia64 and i386. */ +# if defined(i386Architecture) || defined(AlphaArchitecture) || defined(ia64Architecture) || defined(x86_64Architecture) #define HasGlide3 YES #define Glide3IncDir /usr/include/glide3 -# endif /* i386Architecture || AlphaArchitecture */ +# endif /* i386Architecture || AlphaArchitecture || ia64Architecture || x86_64Architecture */ /* Enable extended instruction set support. */ # ifdef i386Architecture #define HasX86Support YES --- xc.old/config/cf/xfree86.cf 2004-06-21 04:07:29.0 +0200 +++ xc/config/cf/xfree86.cf 2004-06-21 04:00:19.0 +0200 @@ -477,8 +477,11 @@ vga dummy fbdev vesa # endif -/* DRI tdfx driver needs Glide, which is not available for x86_64 */ -# define TdfxDriDriver /**/ +# if HasGlide3 +# define TdfxDriDrivertdfx +# else +# define TdfxDriDriver/**/ +# endif # define DevelDRIDrivers /**/
Bug#255270: xfree86: libglide3 has now ia64 and amd64 support
Package: xfree86 Version: 4.3.0.dfsg.1-5 Severity: wishlist Tags: patch Hi, I've ported libglide3 to amd64 and ia64. So now xfree86 can Build-Depend on libglide3-dev on those arches. Attached the patch (against branches/4.3.0/sid) that enables those. regards, guillem Index: debian/control === --- debian/control (revision 1553) +++ debian/control (working copy) @@ -4,7 +4,7 @@ Maintainer: Debian X Strike Force debian-x@lists.debian.org Uploaders: Branden Robinson [EMAIL PROTECTED], Fabio M. Di Nitto [EMAIL PROTECTED] Standards-Version: 3.6.1 -Build-Depends: dpkg (= 1.7.0), flex, bison, bsdmainutils, groff, zlib1g-dev | libz-dev, libncurses5-dev | libncurses-dev, libpam0g-dev | libpam-dev, libfreetype6-dev, libpaperg, libstdc++5-dev | libstdc++-dev, tetex-bin, po-debconf, debhelper (= 4.1.16), html2text, libglide2-dev ( 2001.01.26) [i386], libglide3-dev (= 2002.04.10-3) [alpha i386], linux-kernel-headers [alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sh], linux-kernel-headers (= 2.5.999-test7-bk-15) [sparc], libpng12-dev | libpng-dev, libexpat1-dev, libfontconfig1-dev, fontconfig, bzip2, libxft-dev (= 2.1.2), libxrender-dev (= 0.8.3), libxcursor-dev, dbs, m4 +Build-Depends: dpkg (= 1.7.0), flex, bison, bsdmainutils, groff, zlib1g-dev | libz-dev, libncurses5-dev | libncurses-dev, libpam0g-dev | libpam-dev, libfreetype6-dev, libpaperg, libstdc++5-dev | libstdc++-dev, tetex-bin, po-debconf, debhelper (= 4.1.16), html2text, libglide2-dev ( 2001.01.26) [i386], libglide3-dev (= 2002.04.10-7) [alpha i386 ia64 amd64], linux-kernel-headers [alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sh], linux-kernel-headers (= 2.5.999-test7-bk-15) [sparc], libpng12-dev | libpng-dev, libexpat1-dev, libfontconfig1-dev, fontconfig, bzip2, libxft-dev (= 2.1.2), libxrender-dev (= 0.8.3), libxcursor-dev, dbs, m4 Build-Conflicts: cpp-3.3 ( 1:3.3.3-0pre1) Package: lbxproxy
Bug#202096: xfs: plan for running as non-root user and better FPE handling
Hi, Branden and I were talking the other day on IRC to get a consensus on some issue from this mini-plan. Ishikawa, I'll like specially if you could comment on this, if you don't like something we can keep discussing. username = xfontserver || xfntserv homedir = /var/run/$USERNAME logdir = /var/log logfile = $LOGDIR/$DAEMON_NAME.log I'm preparing an ammendment for policy. Once we have nailed this details down I'll send it to debian-policy and once aproved we can upload the packages with the changes. regards, guillem PS: I'm still confused on what's the correct way to call a Japanese person as I think you have the names swapped, sorry for that. ;
Bug#211780: xserver-xfree86: would like package to Suggest libglide2
Package: xserver-xfree86
Version: 4.2.1-11
Severity: wishlist
Tags: patch
One of the few packages using libglide2 is xserver-xfree86, so it would
be nice to have it Suggests libglide2. The module loading dynamically
libglide2 is glide_drv.o.
thanks
guillem
diff -Naur xfree86-4.2.1/debian/control xfree86-4.2.1-patched/debian/control
--- xfree86-4.2.1/debian/control2003-09-20 07:33:32.0 +0200
+++ xfree86-4.2.1-patched/debian/control2003-09-20 07:35:48.0
+0200
@@ -883,7 +883,7 @@
Package: xserver-xfree86
Architecture: alpha arm hppa hurd-i386 i386 ia64 m68k mips mipsel netbsd-i386
powerpc sh3 sh4 sparc
Depends: xserver-common (= 4.2.1-10), ${shlibs:Depends}, ${misc:Depends}
-Suggests: discover, mdetect, read-edid
+Suggests: discover, mdetect, read-edid, libglide2 ( 2001.01.26)
Conflicts: libxfont-xtt
Replaces: xserver-common ( 4.0), libxfont-xtt
Provides: xserver
Bug#211780: xserver-xfree86: would like package to Suggest libglide2
Package: xserver-xfree86
Version: 4.2.1-11
Severity: wishlist
Tags: patch
One of the few packages using libglide2 is xserver-xfree86, so it would
be nice to have it Suggests libglide2. The module loading dynamically
libglide2 is glide_drv.o.
thanks
guillem
diff -Naur xfree86-4.2.1/debian/control xfree86-4.2.1-patched/debian/control
--- xfree86-4.2.1/debian/control2003-09-20 07:33:32.0 +0200
+++ xfree86-4.2.1-patched/debian/control2003-09-20 07:35:48.0 +0200
@@ -883,7 +883,7 @@
Package: xserver-xfree86
Architecture: alpha arm hppa hurd-i386 i386 ia64 m68k mips mipsel netbsd-i386 powerpc
sh3 sh4 sparc
Depends: xserver-common (= 4.2.1-10), ${shlibs:Depends}, ${misc:Depends}
-Suggests: discover, mdetect, read-edid
+Suggests: discover, mdetect, read-edid, libglide2 ( 2001.01.26)
Conflicts: libxfont-xtt
Replaces: xserver-common ( 4.0), libxfont-xtt
Provides: xserver
Bug#209142: xfree86: build depend on libglide3-dev instead of libglide3-alpha-dev
Package: xfree86 Version: 4.2.1-11 Tags: patch Severity: wishlist Hi, I've merged glide and glide3-alpha. Now glide builds on alpha (there is a package built already), glide3-alpha has a RC bug and I want to ask for its removal. But first nothing should depend on it. Could you apply the patch for the next X release, please? thanks, guillem diff -ur xfree86-4.2.1/debian/control xfree86-4.2.1-patched/debian/control --- xfree86-4.2.1/debian/control2003-09-08 01:32:06.0 +0200 +++ xfree86-4.2.1-patched/debian/control2003-09-08 01:40:42.0 +0200 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Branden Robinson [EMAIL PROTECTED] Standards-Version: 3.6.0 -Build-Depends: dpkg (= 1.7.0), cpp-3.2, flex-old, bison, bsdmainutils, groff, zlib1g-dev | libz-dev, libncurses5-dev | libncurses-dev, libpam0g-dev | libpam-dev, libfreetype6-dev, libpaperg, libstdc++5-dev | libstdc++-dev, tetex-bin, po-debconf, debhelper (= 4.1.16), html2text, libglide2-dev ( 2001.01.26) [i386], libglide3-dev ( 2001.01.26) [i386], libglide3-alpha-dev [alpha], kernel-headers-2.4 | hurd | freebsd | netbsd | openbsd +Build-Depends: dpkg (= 1.7.0), cpp-3.2, flex-old, bison, bsdmainutils, groff, zlib1g-dev | libz-dev, libncurses5-dev | libncurses-dev, libpam0g-dev | libpam-dev, libfreetype6-dev, libpaperg, libstdc++5-dev | libstdc++-dev, tetex-bin, po-debconf, debhelper (= 4.1.16), html2text, libglide2-dev ( 2001.01.26) [i386], libglide3-dev (= 2002.04.10-3) [i386 alpha], kernel-headers-2.4 | hurd | freebsd | netbsd | openbsd Build-Conflicts: gcc-3.3 ( 1:3.3.2-0pre1) Package: lbxproxy
Bug#209142: xfree86: build depend on libglide3-dev instead of libglide3-alpha-dev
Package: xfree86 Version: 4.2.1-11 Tags: patch Severity: wishlist Hi, I've merged glide and glide3-alpha. Now glide builds on alpha (there is a package built already), glide3-alpha has a RC bug and I want to ask for its removal. But first nothing should depend on it. Could you apply the patch for the next X release, please? thanks, guillem diff -ur xfree86-4.2.1/debian/control xfree86-4.2.1-patched/debian/control --- xfree86-4.2.1/debian/control2003-09-08 01:32:06.0 +0200 +++ xfree86-4.2.1-patched/debian/control2003-09-08 01:40:42.0 +0200 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Branden Robinson [EMAIL PROTECTED] Standards-Version: 3.6.0 -Build-Depends: dpkg (= 1.7.0), cpp-3.2, flex-old, bison, bsdmainutils, groff, zlib1g-dev | libz-dev, libncurses5-dev | libncurses-dev, libpam0g-dev | libpam-dev, libfreetype6-dev, libpaperg, libstdc++5-dev | libstdc++-dev, tetex-bin, po-debconf, debhelper (= 4.1.16), html2text, libglide2-dev ( 2001.01.26) [i386], libglide3-dev ( 2001.01.26) [i386], libglide3-alpha-dev [alpha], kernel-headers-2.4 | hurd | freebsd | netbsd | openbsd +Build-Depends: dpkg (= 1.7.0), cpp-3.2, flex-old, bison, bsdmainutils, groff, zlib1g-dev | libz-dev, libncurses5-dev | libncurses-dev, libpam0g-dev | libpam-dev, libfreetype6-dev, libpaperg, libstdc++5-dev | libstdc++-dev, tetex-bin, po-debconf, debhelper (= 4.1.16), html2text, libglide2-dev ( 2001.01.26) [i386], libglide3-dev (= 2002.04.10-3) [i386 alpha], kernel-headers-2.4 | hurd | freebsd | netbsd | openbsd Build-Conflicts: gcc-3.3 ( 1:3.3.2-0pre1) Package: lbxproxy
Bug#202096: xfs: plan for running as non-root user and better FPE handling
[ Sorry to follow-up so late, also I'm doing a little bug collage ] To summarize the discussion: On Thu, Jul 24, 2003 at 02:31:49AM +0900, ISHIKAWA Mutsumi wrote: On Sat, Jul 19, 2003 at 12:11:15PM -0500, Branden Robinson wrote: On Sat, Jul 19, 2003 at 12:11:15PM -0500, Branden Robinson wrote: 1) Petition debian-policy for dynamically allocated user id under which to run X font servers. Username possibly xfntserv? Need to be done before using the name, so Mutsumi, could you wait doing this change to the next xfs-xtt upload until we have the -policy aproval? I'm not convinced with xfntserv, it's only a subjective aesthetic opinion. What about fontserv or fontserver, it's a little more descriptive and it may be used by other non-X font servers (if they exist one day :). Where is a good place for home directory of this user ? Home directory for the user is not important things to use this uid. But, I consider that it is better to have determined. I've seen Mutsumi's proposal, and I've looked my system for other daemons using log as the home dir and none appeared. So why not use run, anyway we'll have to create a subdir there as well to be able to create and remove the pid files, and run is more commonly used. So /var/log/fontserver(s) and /var/run/fontserver(s) ? Also it resembles the user name ;. 3) Modify xfs* init scripts to ensure proper ownership of temp directory. Also about the creation of temp dir, we can use what xfs has in its maint scripts. But could we print only when creating (not if it exists) ? because having two or three xfs* will repeat boot messages. 4) Use shared template to store font path elements. [...] 5) dexconf uses these shared templates instead of hardcoding FPEs. Joey Hess pointed out that we only need to use debconf for the above if we need access to this information during pre-configuration. So, unless we have debconfage for FPEs in the font servers or X servers, which I feel we probably shouldn't, the above will be implemented by using /etc. (Likely similar to the way /etc/X11/fonts/*/fonts.alias files currently work.) Do you have any prototype of this new implementation ? regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#202096: xfs: plan for running as non-root user and better FPE handling
[ Sorry to follow-up so late, also I'm doing a little bug collage ] To summarize the discussion: On Thu, Jul 24, 2003 at 02:31:49AM +0900, ISHIKAWA Mutsumi wrote: On Sat, Jul 19, 2003 at 12:11:15PM -0500, Branden Robinson wrote: On Sat, Jul 19, 2003 at 12:11:15PM -0500, Branden Robinson wrote: 1) Petition debian-policy for dynamically allocated user id under which to run X font servers. Username possibly xfntserv? Need to be done before using the name, so Mutsumi, could you wait doing this change to the next xfs-xtt upload until we have the -policy aproval? I'm not convinced with xfntserv, it's only a subjective aesthetic opinion. What about fontserv or fontserver, it's a little more descriptive and it may be used by other non-X font servers (if they exist one day :). Where is a good place for home directory of this user ? Home directory for the user is not important things to use this uid. But, I consider that it is better to have determined. I've seen Mutsumi's proposal, and I've looked my system for other daemons using log as the home dir and none appeared. So why not use run, anyway we'll have to create a subdir there as well to be able to create and remove the pid files, and run is more commonly used. So /var/log/fontserver(s) and /var/run/fontserver(s) ? Also it resembles the user name ;. 3) Modify xfs* init scripts to ensure proper ownership of temp directory. Also about the creation of temp dir, we can use what xfs has in its maint scripts. But could we print only when creating (not if it exists) ? because having two or three xfs* will repeat boot messages. 4) Use shared template to store font path elements. [...] 5) dexconf uses these shared templates instead of hardcoding FPEs. Joey Hess pointed out that we only need to use debconf for the above if we need access to this information during pre-configuration. So, unless we have debconfage for FPEs in the font servers or X servers, which I feel we probably shouldn't, the above will be implemented by using /etc. (Likely similar to the way /etc/X11/fonts/*/fonts.alias files currently work.) Do you have any prototype of this new implementation ? regards, guillem
Bug#167925: xserver-xfree86: [debconf] Recognize xfs-xtt's port number (7110)
Hi, On Tue, Nov 05, 2002 at 08:33:12PM +0100, Wouter wrote: The configuration of xserver-xfree86 always puts the line FontPathunix/:7110# local font server in XF86Config-4. However, the fontserver xfs-xtt (which I believe is standard on Debian), uses port 7110 by default. I think it would be a good feature to have debconf check if there is a server listening on 7110, and use that port. We could create a command named update-xserver-fontpath (for example), to handle adding and removing font paths to the X Server configuration file. It would help when configuring xfs (if X Server provided an empty FontPath option in the configuration file), xfs-xtt and xfstt (I'm its maintainer). regards, guillem
