Debian Bug report logs - #515214
X can run perfectly well (or even better) without HAL. Please make this a Recommends: at most

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Frank Gevaerts <frank@gevaerts.be>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: X can run perfectly well (or even better) without HAL. Please make this a Recommends: at most

Date: Sat, 14 Feb 2009 22:12:01 +0100

Package: xserver-xorg
Version: 1:7.4~5
Severity: normal

I have no need for packages that have no other function than make a system harder to configure and to understand. HAL is one of those. Since X works perfectly fine without (after adding Option "AutoAddDevices" "off") I'd like to be able to uninstall hal.


-- Package-specific info:
Contents of /var/lib/x11/X.roster:
xserver-xorg

/var/lib/x11/X.md5sum does not exist.

X server symlink status:
lrwxrwxrwx 1 root root 13 2008-11-18 11:36 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 1872144 2009-01-31 20:20 /usr/bin/Xorg

Contents of /var/lib/x11/xorg.conf.roster:
xserver-xorg

VGA-compatible devices on PCI bus:
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)

/etc/X11/xorg.conf does not match checksum in /var/lib/x11/xorg.conf.md5sum.

Xorg X server configuration file status:
-rw-r--r-- 1 root root 1410 2009-02-14 22:04 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section "InputDevice"
	Identifier	"Generic Keyboard"
	Driver		"kbd"
	Option		"XkbRules"	"xorg"
	Option		"XkbModel"	"pc104"
	Option		"XkbLayout"	"us"
EndSection

Section "InputDevice"
	Identifier	"Configured Mouse"
	Driver		"mouse"
EndSection

Section "Device"
	Identifier	"Configured Video Device"
        Driver          "intel"
        #Option "AccelMethod" "XAA"
        Option "AccelMethod" "UXA"
        #Option          "XAANoOffscreenPixmaps"
EndSection

Section "Monitor"
	Identifier	"Configured Monitor"
EndSection

Section "Screen"
	Identifier	"Default Screen"
	Monitor		"Configured Monitor"
	SubSection "Display" 
        	Virtual         3160 1050
        EndSubSection
EndSection
Section "ServerLayout"
	Identifier	"Default Layout"
        Option "AutoAddDevices" "off"
EndSection

Message #14 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Julien BLACHE <jblache@debian.org>

To: 515214@bugs.debian.org

Subject: Please do not depend on HAL, or provide an alternative xserver-xorg package

Date: Fri, 10 Apr 2009 11:05:39 +0200

Hi,

Given that HAL is not strictly needed to run X and given that it pulls
in a metric ton of crap that just doesn't behave [1], it's unfit for
xserver-xorg to Depends: HAL.

Please demote this dependency to a Recommends, or, if it can't be done
due to upgrade concerns, please provide an alternative
xserver-xorg-nohal package.

JB.

[1] I'm concerned this can lead to a number of interesting issues on
HAL-free systems where HAL & friends will just override whatever
policy was set by the admin before they were installed.

-- 
 Julien BLACHE <jblache@debian.org>  |  Debian, because code matters more 
 Debian & GNU/Linux Developer        |       <http://www.debian.org>
 Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 

Message #19 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Alexander Clouter <alex@digriz.org.uk>

To: 515214@bugs.debian.org

Subject: Please do not depend on HAL, or provide an alternative xserver-xorg package

Date: Fri, 10 Apr 2009 13:51:53 +0100

Hi,

I wanted to add my 'vote' to this, adding HAL is a truly horrible 
horrible thing to do.  For a lot of people HAL is a 'nasty' side of 
Linux userland and so far by using Debian, up until now, we have been 
able to avoid it.

HAL is one of those things that show that although the Linux kernel is 
becoming really shiny, the userspace world is heading in a really ugly 
direction.

Please don't force the *whole* Debian community to be part of this.

Cheers

-- 
Alexander Clouter
.sigmonster says: Thyme's Law:
                  	Everything goes wrong at once.

Message #24 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Frank Gevaerts <frank@gevaerts.be>

To: Debian Bug Tracking System <515214@bugs.debian.org>

Subject: this isn't a wishlist

Date: Fri, 10 Apr 2009 16:12:22 +0200

Package: xserver-xorg

xserver-xorg works perfectly well without hal. Depends: is defined as "The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality", so it is clarly wrong.

Please don't subvert the packaging system in this way.

Frank

Message #33 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Frank Gevaerts <frank@gevaerts.be>

To: 515214@bugs.debian.org

Subject: severity

Date: Fri, 10 Apr 2009 17:34:07 +0200

Severity: normal

Can you please explain why this is not a serious bug? Introducing a
dependency on an unneeded package goes against the debian policy.

Just marking this as wishlist/wontfix will leave several systems broken,
and not even providing an explanation for this is downright rude.

Frank


-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Message #36 received at 515214-submitter@bugs.debian.org (full text, mbox, reply):

From: Filipus Klutiero <chealer@gmail.com>

To: 515214-submitter@bugs.debian.org

Subject: Severity

Date: Fri, 10 Apr 2009 11:55:46 -0400

It's your responsibility to show why this would be a bug. If you think 
this is a policy violation, refer to the violated part of policy.

Message #39 received at 515214-submitter@bugs.debian.org (full text, mbox, reply):

From: Frank Gevaerts <frank@gevaerts.be>

To: 515214-submitter@bugs.debian.org

Subject: Re: Severity

Date: Fri, 10 Apr 2009 18:26:10 +0200

On Fri, Apr 10, 2009 at 11:55:46AM -0400, Filipus Klutiero wrote:
> It's your responsibility to show why this would be a bug. If you think  
> this is a policy violation, refer to the violated part of policy.

7.2 says:
   The Depends field should be used if the depended-on package is required
   for the depending package to provide a significant amount of
   functionality. 

   The Recommends field should list packages that would be found together
   with this one in all but unusual installations. 

These are "should" lines, and therefore don't warrant a serious
severity, which is why I didn't set that. 

However, something not going against the letter of the policy doesn't
mean it's not a bug. Several people have explained here why they think
it's a bug and have suggested possible solutions. 

Please explain why you think more explanations are needed.

Frank

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Message #44 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Joerg Jaspert <joerg@debian.org>

To: 515214@bugs.debian.org

Cc: Joerg Jaspert <joerg@debian.org>

Subject: [PATCH] hal depends -> recommends

Date: Sun, 12 Apr 2009 00:54:52 +0200

demote hal dependency to recommend and add a NEWS entry about it.
---
 debian/changelog                |    4 ++++
 debian/control                  |    3 +--
 debian/xserver-xorg.NEWS        |   11 +++++++++++
 debian/xserver-xorg.postinst.in |    4 ++++
 4 files changed, 20 insertions(+), 2 deletions(-)
 mode change 100644 => 100755 debian/xserver-xorg.postinst.in

diff --git a/debian/changelog b/debian/changelog
index bc0a3b5..02f142a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,6 +4,10 @@ xorg (1:7.4+2) UNRELEASED; urgency=low
 
   * Don't discuss removal of xserver-xorg in its description. 
     It remains tied to -core at this point. (closes: #523630).
+
+  * Demote hal Depends: to Recommends:. For that add a NEWS.Debian entry
+    that people have to be careful on upgrades to not lose their input
+    devices (without hal it needs a config option).
 	
  -- Julien Cristau <jcristau@debian.org>  Fri, 10 Apr 2009 14:12:51 +0100
 
diff --git a/debian/control b/debian/control
index 350ebb1..cc2b023 100644
--- a/debian/control
+++ b/debian/control
@@ -86,13 +86,12 @@ Depends:
  xserver-xorg-input-evdev [alpha amd64 arm armeb armel hppa i386 ia64 lpia m32r m68k mips mipsel powerpc sparc],
  xserver-xorg-video-all | xserver-xorg-video-5,
  xserver-xorg-input-all | xserver-xorg-input-4,
- hal (>= 0.5.12~git20090406),
  console-setup (>= 1.29),
  ${shlibs:Depends},
  ${misc:Depends},
  xkb-data (>= 1.4),
  x11-xkb-utils
-Recommends: libgl1-mesa-dri, udev
+Recommends: libgl1-mesa-dri, udev, hal (>= 0.5.12~git20090406)
 Description: the X.Org X server
  This package depends on the full suite of the server and drivers for the
  X.Org X server, as well as providing a configuration infrastructure to manage
diff --git a/debian/xserver-xorg.NEWS b/debian/xserver-xorg.NEWS
index 6987bec..6b6b102 100644
--- a/debian/xserver-xorg.NEWS
+++ b/debian/xserver-xorg.NEWS
@@ -1,3 +1,14 @@
+xserver-xorg (1:7.4+2) unstable; urgency=low
+
+  Starting with this release, hal is no longer a dependency, "only" a
+  recommended package. To ensure working input devices for your X server,
+  either make sure you install hal alongside this package, or add
+  'Option "AutoAddDevices" "off"' in the ServerLayout section of your
+  /etc/X11/xorg.conf (without the '') and configure input devices as you
+  did in the past.
+
+ -- Joerg Jaspert <joerg@debian.org>  Sun, 12 Apr 2009 00:05:02 +0200
+
 xserver-xorg (1:7.4+1) unstable; urgency=low
 
   Starting from this version, input devices are no longer configured
diff --git a/debian/xserver-xorg.postinst.in b/debian/xserver-xorg.postinst.in
old mode 100644
new mode 100755
index 7f75de2..be31457
--- a/debian/xserver-xorg.postinst.in
+++ b/debian/xserver-xorg.postinst.in
@@ -270,6 +270,10 @@ fi
 
 debug_echo "Configuring $THIS_PACKAGE."
 
+if ! [ -x /usr/sbin/hald ] &&  ! grep -q AutoAddDevices "${XORGCONFIG}"; then
+    bomb "Please either install hal or configure your xorg.conf to work without, see NEWS entry for xserver-xorg version 1:7.4+2"
+fi
+
 if [ -n "$FIRSTINST" ] || [ -n "$RECONFIGURE" ]; then
   # BusID
   PRIORITY=low
-- 
1.6.2

Message #51 received at 515214@bugs.debian.org (full text, mbox, reply):

From: David Nusinow <dnusinow@debian.org>

To: 515214@bugs.debian.org

Subject: Re: Bug#515214: [PATCH] hal depends -> recommends

Date: Sun, 12 Apr 2009 19:36:31 -0400

[Message part 1 (text/plain, inline)]

Here's a slight variant on the patch with much stronger wording in the
NEWS entry, and some more detail in debian/changelog. We want to be very
clear that we want people to use hal. I didn't go so far as to say that
not using hal won't be supported in the future, but I did try to get
across that the user is entirely responsible for their input
configuration if they choose not to use hal.

 - David Nusinow

[0001-Demote-hal-Depends-to-Recommends.patch (text/x-patch, inline)]

From 9e594116533cedccf273b216ccdce6585c9696bb Mon Sep 17 00:00:00 2001
From: David Nusinow <dnusinow@debian.org>
Date: Sun, 12 Apr 2009 19:31:26 -0400
Subject: [PATCH] Demote hal Depends: to Recommends:.
 For that add a NEWS.Debian entry that people have to be careful on upgrades
 to not lose their input devices (without hal it needs a config option).
 Thanks Joerg Jaspert.

Require that this config option be set when hal is absent during postinst
---
 debian/changelog                |    6 ++++++
 debian/control                  |    3 +--
 debian/xserver-xorg.NEWS        |   21 +++++++++++++++++++++
 debian/xserver-xorg.postinst.in |    4 ++++
 4 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index bc0a3b5..5d4287e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,6 +4,12 @@ xorg (1:7.4+2) UNRELEASED; urgency=low
 
   * Don't discuss removal of xserver-xorg in its description. 
     It remains tied to -core at this point. (closes: #523630).
+
+  * Demote hal Depends: to Recommends:. For that add a NEWS.Debian entry
+    that people have to be careful on upgrades to not lose their input
+    devices (without hal it needs a config option). Thanks Joerg Jaspert.
+    + Require that this config option be set when hal is absent during
+      postinst
 	
  -- Julien Cristau <jcristau@debian.org>  Fri, 10 Apr 2009 14:12:51 +0100
 
diff --git a/debian/control b/debian/control
index 350ebb1..cc2b023 100644
--- a/debian/control
+++ b/debian/control
@@ -86,13 +86,12 @@ Depends:
  xserver-xorg-input-evdev [alpha amd64 arm armeb armel hppa i386 ia64 lpia m32r m68k mips mipsel powerpc sparc],
  xserver-xorg-video-all | xserver-xorg-video-5,
  xserver-xorg-input-all | xserver-xorg-input-4,
- hal (>= 0.5.12~git20090406),
  console-setup (>= 1.29),
  ${shlibs:Depends},
  ${misc:Depends},
  xkb-data (>= 1.4),
  x11-xkb-utils
-Recommends: libgl1-mesa-dri, udev
+Recommends: libgl1-mesa-dri, udev, hal (>= 0.5.12~git20090406)
 Description: the X.Org X server
  This package depends on the full suite of the server and drivers for the
  X.Org X server, as well as providing a configuration infrastructure to manage
diff --git a/debian/xserver-xorg.NEWS b/debian/xserver-xorg.NEWS
index 6987bec..2221c53 100644
--- a/debian/xserver-xorg.NEWS
+++ b/debian/xserver-xorg.NEWS
@@ -1,3 +1,24 @@
+xserver-xorg (1:7.4+2) unstable; urgency=low
+
+  Starting with this release, hal is a recommended rather than
+  depended-upon package. This is because, although the X server
+  remains capable of configuring input devices without hal, it is
+  strongly recommended that you use this method unless there is a good
+  reason otherwise. Using hal provides the X server with the ability
+  to dynamically and correctly configure input devices while running,
+  and as a result it will be the best supported and most easily
+  maintained method of handling input devices for the forseeable
+  future.
+
+  If you choose to run your system without hal, you will have to take
+  all responsibility for manually configuring your input devices via
+  xorg.conf. To ensure working input devices for your X server when
+  hal is absent, add 'Option "AutoAddDevices" "off"' in the
+  ServerLayout section of your /etc/X11/xorg.conf (without the outer
+  '') and configure input devices as you did in the past.
+
+ -- David Nusinow <dnusinow@debian.org> Sun, 12 Apr 2009 19:24:09 -0400
+
 xserver-xorg (1:7.4+1) unstable; urgency=low
 
   Starting from this version, input devices are no longer configured
diff --git a/debian/xserver-xorg.postinst.in b/debian/xserver-xorg.postinst.in
index 7f75de2..be31457 100644
--- a/debian/xserver-xorg.postinst.in
+++ b/debian/xserver-xorg.postinst.in
@@ -270,6 +270,10 @@ fi
 
 debug_echo "Configuring $THIS_PACKAGE."
 
+if ! [ -x /usr/sbin/hald ] &&  ! grep -q AutoAddDevices "${XORGCONFIG}"; then
+    bomb "Please either install hal or configure your xorg.conf to work without, see NEWS entry for xserver-xorg version 1:7.4+2"
+fi
+
 if [ -n "$FIRSTINST" ] || [ -n "$RECONFIGURE" ]; then
   # BusID
   PRIORITY=low
-- 
1.6.2.2

Message #56 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Gustavo Noronha <kov@debian.org>

To: 515214@bugs.debian.org

Subject: I don't think we need to add complexity to X on Debian

Date: Sun, 12 Apr 2009 22:57:02 -0300

Please do not accept any of the patches. Most users want things to just
work. Anyone who wants to keep their systems hal-free is capable of
configuring xorg accordingly and should be able to make a filler package
using equivs to fulfill the dependency with no need to increase the
complexity for the majority.

Thanks,

-- 
Gustavo Noronha <kov@debian.org>
Debian Project

Message #61 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Robert Grimm <rob@robgri.de>

To: 515214@bugs.debian.org

Subject: Re: I don't think we need to add complexity to X on Debian

Date: Mon, 13 Apr 2009 10:41:49 +0200

[Message part 1 (text/plain, inline)]

On Sun, 12 April 2009, you wrote:
> Please do not accept any of the patches. Most users want things to just
> work. Anyone who wants to keep their systems hal-free is capable of
> configuring xorg accordingly and should be able to make a filler package
> using equivs to fulfill the dependency with no need to increase the
> complexity for the majority.

In my opinion, HAL is unneeded complexity.

Furthermore, the referenced "most users" are perfectly capable to
install recommends. This is the default behavior in Debian.
If they like to install every piece of software, that makes their life
"easier", why wouldn't they install recommends?

Rob

[signature.asc (application/pgp-signature, inline)]

Message #66 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Huy <huy.dao@gmail.com>

To: 515214@bugs.debian.org

Subject: [xserver-xorg] Re: X can run perfectly well (or even better) without HAL. Please make this a Recommends: at most

Date: Mon, 13 Apr 2009 12:48:59 -0400

Package: xserver-xorg
Version: 1:7.4+1

I too wanna chime in, Debian is about choice, and since X works perfectly fine without HAL, there is
no reason to force it on the users.  The users should have the freedom to choose whether they want
to install HAL or not.

Huy

--- System information. ---
Architecture: i386
Kernel:       Linux 2.6.29.1

Debian Release: squeeze/sid
  990 unstable        ftp.us.debian.org


--- Package information. ---
Depends                                    (Version) | Installed
====================================================-+-========================
xserver-xorg-core                  (>= 2:1.5.99.901) | 2:1.6.0-1
xserver-xorg-input-evdev                             | 1:2.2.1-1
xserver-xorg-video-all                               |
 OR xserver-xorg-video-5                             |
xserver-xorg-input-all                               |
 OR xserver-xorg-input-4                             |
hal                          (>= 0.5.12~git20090406) | 0.5.12~git20090406.46dc48-1
console-setup                              (>= 1.29) | 1.32
libc6                                       (>= 2.3) | 2.9-6
debconf                                    (>= 0.5)  | 1.5.26
 OR debconf-2.0                                      |
xkb-data                                    (>= 1.4) | 1.5-2
x11-xkb-utils                                        | 7.4+2




-- 
e10a5ba52ebd2b06b3cb114647d0b2d7149357ece59ebfb787a2a6cb653280ba
Key ID = 0xE024A6F3
Key fingerprint = C9A1 2E1E 1E10 6514 2E7D  8934 08C6 B43F E024 A6F3

Message #71 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Corbin Simpson <mostawesomedude@gmail.com>

To: 515214@bugs.debian.org

Subject: Xorg guy here...

Date: Tue, 14 Apr 2009 08:17:20 -0700

Although I don't ever touch the input subsystem, I figured I'd toss in
my opinion.

HAL and evdev may not be required, but in the future we really don't
want policy and per-device drivers where we don't need them. HAL lets us
make a lot of device configuration simpler when paired with evdev, and
also lets us have one central place for storing policies.

You can disable HAL, but we're moving in that direction regardless.

~ C.

Message #76 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Matthew Johnson <mjj29@debian.org>

To: Robert Grimm <rob@robgri.de>, Gustavo Noronha <kov@debian.org>

Cc: 515214@bugs.debian.org

Subject: Re: I don't think we need to add complexity to X on Debian

Date: Wed, 15 Apr 2009 08:37:15 +0100

[Message part 1 (text/plain, inline)]

On Mon Apr 13 10:41, Robert Grimm wrote:
> On Sun, 12 April 2009, you wrote:
> > Please do not accept any of the patches. Most users want things to just
> > work. Anyone who wants to keep their systems hal-free is capable of
> > configuring xorg accordingly and should be able to make a filler package
> > using equivs to fulfill the dependency with no need to increase the
> > complexity for the majority.
> 
> In my opinion, HAL is unneeded complexity.
> 
> Furthermore, the referenced "most users" are perfectly capable to
> install recommends. This is the default behavior in Debian.
> If they like to install every piece of software, that makes their life
> "easier", why wouldn't they install recommends?

Concur. We _have_ a perfectly good system for saying "please install
this unless you know what you are doing"; it's 'recommends'. It doesn't
force people to hack around the issue (and equivs _is_ hacking around
the issue), but it does get installed by default unless  people know
what they are doing. Not only that, but you also have a metapackage,
which is what people generally install by default. Add a hard depends to
that by all means, but you don't need to _require_ it.

I'm not even likely to want to install it without hal myself, but I see
no reason whatsoever not to allow people a hal-less X if they want.

Matt

-- 
Matthew Johnson

[signature.asc (application/pgp-signature, inline)]

Message #81 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@deuxchevaux.org>

To: 515214@bugs.debian.org, 523960@bugs.debian.org

Subject: equivs is surely not the solution to this problem. "Recommends:" is.

Date: Wed, 15 Apr 2009 20:24:26 +0200

I really can't understand how someone can suggest to fake packages
using equivs instead of using the "Recommends:" header as it's
thought.

The Policy says in 7.2 very clearly "in all but unusual
installations", so nobody can't use users "who just want it work" as
argument. Debian's default is btw. to install recommended packages
anyway. Another reason why users "who just want it work" are _no_
argument against using "Recommends:" header.

X.org not only runs on fat workstations but also on embedded device
where you as less abstraction layers and diskspace used as possible.
Debian always claims to be "the _universal_ operating system" and it
should also package X.org to be universal. Debian is not (a desktop
focussed) Ubuntu.

I herewith vote for demoting hal (#515214) and console-setup (#523960)
to recommends.

		Regards, Axel
-- 
Axel Beckert - abe@deuxchevaux.org, abe@noone.org - http://noone.org/abe/

Message #86 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Julien Cristau <jcristau@debian.org>

To: Axel Beckert <abe@deuxchevaux.org>, 523960@bugs.debian.org

Cc: 515214@bugs.debian.org

Subject: Re: Bug#523960: equivs is surely not the solution to this problem. "Recommends:" is.

Date: Wed, 15 Apr 2009 20:47:03 +0200

On Wed, 2009-04-15 at 20:24 +0200, Axel Beckert wrote:
> I herewith vote for demoting hal (#515214) and console-setup (#523960)
> to recommends.

THIS IS NOT A FUCKING VOTE.

Message #91 received at 515214@bugs.debian.org (full text, mbox, reply):

From: David Nusinow <david@gravitypulls.net>

To: Axel Beckert <abe@deuxchevaux.org>, 523960@bugs.debian.org

Cc: 515214@bugs.debian.org

Subject: Re: Bug#523960: equivs is surely not the solution to this problem. "Recommends:" is.

Date: Wed, 15 Apr 2009 15:09:22 -0400

Axel Beckert wrote:
> I really can't understand how someone can suggest to fake packages
> using equivs instead of using the "Recommends:" header as it's
> thought.
>
> The Policy says in 7.2 very clearly "in all but unusual
> installations", so nobody can't use users "who just want it work" as
> argument. Debian's default is btw. to install recommended packages
> anyway. Another reason why users "who just want it work" are _no_
> argument against using "Recommends:" header.
>   
Thank you so much for repeating exactly what other people have said. 
Given that the XSF must be collectively illterate,  we didn't understand 
them the first dozen or so emails stating this, so the above was clearly 
necessary.

> X.org not only runs on fat workstations but also on embedded device
> where you as less abstraction layers and diskspace used as possible.
> Debian always claims to be "the _universal_ operating system" and it
> should also package X.org to be universal. Debian is not (a desktop
> focussed) Ubuntu.
>   
Note that this is the direction that upstream is heading in. The design 
is conceptually quite simple. The X server asks the system, in this case 
via hal, to enumerate input devices are present and gets them enumerated 
back. It then utilizes that hardware via the kernel rather than driving 
them itself with its own drivers. Note that this system was designed and 
implemented by a Nokia employee for an embedded system. It brings an 
enormous simplification to the overall operating system by putting 
things like keymaps in one place, and only having the kernel driving the 
hardware rather than both the kernel and the X server. It also makes it 
flexible with system changes, allowing hotplugging. Most importantly to 
Debian and the XSF, it means that we don't have to carry around a 
gigantic horrible bunch of shell script just to configure the system. 
All of this is a good thing.

If you object to having the X server depend on external software, you're 
going to have to learn to like it, because the goal has been to decrease 
the amount of OS code that the server needs to duplicate in order to do 
its job. It no longer scans the PCI bus itself, but instead relies on 
libpciaccess to query the OS. It no longer carries its own build system, 
but relies on autotools. All of the video drivers are moving significant 
portions of themselves in to the kernel as well. If you can't deal with 
hal, then you'll have to write a replacement for it that allows the 
server to query the system in a transparent way, and also allows one to 
easily configure device-specific properties. This is something that hal 
currently does very well and the X server can not do otherwise.

All of that said, it's very likely that we will downgrade the depends to 
recommends, just not right now. We have actual important bugs like 
totally broken installs that we want to deal with first.

> I herewith vote for demoting hal (#515214) and console-setup (#523960)
> to recommends.
>   
The BTS is not a voting system.

- David Nusinow

Message #96 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@deuxchevaux.org>

To: David Nusinow <david@gravitypulls.net>

Cc: 523960@bugs.debian.org, 515214@bugs.debian.org

Subject: Re: Bug#523960: equivs is surely not the solution to this problem. "Recommends:" is.

Date: Wed, 15 Apr 2009 22:01:54 +0200

Hi David,

On Wed, Apr 15, 2009 at 03:09:22PM -0400, David Nusinow wrote:
> Axel Beckert wrote:
> >I really can't understand how someone can suggest to fake packages
> >using equivs instead of using the "Recommends:" header as it's
> >thought. [...]
>
> Thank you so much for repeating exactly what other people have said. 

that was my intent.

> Given that the XSF must be collectively illterate, we didn't
> understand them the first dozen or so emails stating this, so the
> above was clearly necessary.

You got me wrong. But you seem to have started counting those mails.
That's good. :-)

> Note that this system was designed and implemented by a Nokia
> employee for an embedded system.

That's an interesting detail!

> [...] This is something that hal currently does very well and the X
> server can not do otherwise.

Thanks for this very detailed explanation. I'm sure many of those who
are (currently) unhappy about HAL and the wontfix for #515214 now
better understand the background of this obviously (still) unpopular
decision.

> All of that said, it's very likely that we will downgrade the
> depends to recommends,

Glad to hear that, anyway. I would suggest to remove the wontfix tag
then. It would cool down the people -- as your statement already does
for those caring to scroll down that far.

Such an explanation instead of a _commentless_ wontfix tag would have
been way better in the first place.

> just not right now. We have actual important bugs like totally
> broken installs that we want to deal with first.

Sure.

> >I herewith vote for demoting hal (#515214) and console-setup (#523960)
> >to recommends.
>
> The BTS is not a voting system.

Surely not, but it's a way to show maintainers that there's yet
another user who is very unhappy about a specific solution respective
that there is demand for another solution. And I obviously managed to
do that.

And happily I also managed to trigger a very informative explanation
about the background to this decision which will surely reduce the
amount of "I dislike the wontfix, too" mails as well as reducing the
wearout of someone's capslock key. ;-)

	Thanks again for that informative reply, Axel
-- 
Axel Beckert - abe@deuxchevaux.org, abe@noone.org - http://noone.org/abe/

Message #101 received at 515214@bugs.debian.org (full text, mbox, reply):

From: sacrificial-spam-address@horizon.com

To: 515214@bugs.debian.org

Cc: sacrificial-spam-address@horizon.com

Subject: console-setup needs to be taken out and shot.

Date: 19 Apr 2009 08:27:02 -0400

Package: xserver-xorg
Version: 1:7.4+1

Just another voice who doesn't care for the amount of cruft that
hal and console-setup drag into my system.  The fact that console-setup
remaps the console fonts and doesn't even provide a way to set it back
to CP437 is particularly egregious.

I have, for now, simply edited /var/lib/dpkg/status and removed the
dependencies, but will have to remember how to satisfy a versioned
dependency with equivs.  (I think it can't be done with a *-dummy
package that Provides: the package.)


Installing hal and console-setup wants to drag in 9417 kB of cruft:
--\ Packages being automatically installed to satisfy dependencies (20)
piA  acl                                           +176kB  <none>     2.2.47-2  
piA  console-setup                                 +1286kB <none>     1.32      
piA  console-terminus                              +692kB  <none>     4.26-2.1  
piA  consolekit                                    +541kB  <none>     0.3.0-2   
piA  hal                                           +1724kB <none>     0.5.12~git
piA  hal-info                                      +487kB  <none>     20090309-1
piA  initramfs-tools                               +430kB  <none>     0.93.2    
piA  klibc-utils                                   +467kB  <none>     1.5.15-1  
piA  libck-connector0                              +115kB  <none>     0.3.0-2   
piA  libklibc                                      +135kB  <none>     1.5.15-1  
piA  libpam-ck-connector                           +127kB  <none>     0.3.0-2   
piA  libpolkit-grant2                              +168kB  <none>     0.9-3     
piA  libsmbios-bin                                 +377kB  <none>     2.0.3.dfsg
piA  libsplashy1                                   +115kB  <none>     0.3.13-4  
piA  libvolume-id1                                 +160kB  <none>     0.141-1
piA  pm-utils                                      +303kB  <none>     1.2.5-2   
piA  policykit                                     +430kB  <none>     0.9-3     
piA  powermgmt-base                                +90.1kB <none>     1.30+nmu1 
piA  radeontool                                    +73.7kB <none>     1.5-5     
piA  udev                                          +979kB  <none>     0.141-1   
piA  uswsusp                                       +479kB  <none>     0.8-1.1+b1
piA  vbetool                                       +61.4kB <none>     1.1-2     

Although some of that is only Recommends: and can be removed, taking it
down to 7528k:

xserver-xorg
    D-> console-setup
	D-> console-terminus
    D-> hal
	D-> hal-info
	D-> acl
	D-> udev
	    D-> libvolume-id1
	D-> libvolume-id1
 	D-> policykit
	    D-> libpolkit-grant2
	    D-> consolekit
	D-> consolekit
	    D-> libck-connector0
	    R-> libpam-ck-connector
	D-> pm-utils
	    D-> powermgmt-base
	    R-> radeontool
	    R-> uswsusp
		D-> libsplashy1
	    R-> vbetool

If we hold out some faint hope that bug #448197 will (after a year and
a half of inaction) be resolved by downgrading the pm-utils dependency
to a recommends, then that takes it down to 7135k.

Message #106 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Pascal Mainini <pascal@impressionet.ch>

To: 515214@bugs.debian.org

Subject: Re: I don't think we need to add complexity to X on Debian

Date: Tue, 21 Apr 2009 11:55:47 +0200

[Message part 1 (text/plain, inline)]

Hi all

knowing that the BTS is *not* a voting system and with deep respect
about the work done in Debian and also in the X-system, i still feel
the need to raise my voice.

As a long term Debian user, running multiple servers and enduser
systems across multiple releases i feel a bit scared about the
current direction. I've always choosen Debian due to its simplicity,
due to the possibility to trim it down to a bare minimum which
fits my needs. As time goes by, i feel this is getting less and
less possible. I absolutely see the point in HAL, DBus, and all the
other technologies, i understand the need for it and i certainly have
nothing agains it. But please, stick to the bare minimum, only depending
on what's really needed and leave everything else to recommendations.
(that's the defininition of "Depends" for me...)

Just my two cents, thanks and kind regards,

Pascal

[signature.asc (application/pgp-signature, attachment)]

Message #111 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Alexander Clouter <alex@digriz.org.uk>

To: 515214@bugs.debian.org

Subject: Re: Bug#523960: equivs is surely not the solution to this problem. "Recommends:" is.

Date: Wed, 22 Apr 2009 13:30:33 +0100

Hi,

Just following up to David Nusinow comment (not directed at him but 
this seems to be where the main defencive stance on this seems to be):
----
> X.org not only runs on fat workstations but also on embedded device
> where you as less abstraction layers and diskspace used as possible.
> Debian always claims to be "the _universal_ operating system" and it
> should also package X.org to be universal. Debian is not (a desktop
> focussed) Ubuntu.
>   
Note that this is the direction that upstream is heading in. The design 
is conceptually quite simple. The X server asks the system, in this case 
via hal, to enumerate input devices are present and gets them enumerated 
back.
----

And for the platforms where hal does not exist?  Xorg is not just 
available for Linux.  I'm all for making it easier for refugee's from 
other OS's to get onto the Linux bandwagon, but the moment you start 
removing choice from those already on the bandwagon, something is going 
seriously wrong.

This is greater than some the Debian 'policy' document, we are stepping 
onto point four in Debian's *social* contract.  Maybe that's just my 
opinion, I read that bit in the social contract as 'choice', others 
might read it differently.

The argument regarding "get used to dependencies...it's the way of the 
world is", that's fine *when* the functionality (such as PCI scanning) 
might have been stripped from Xorg altogether and it simply will not 
compile without it.  The reality is that the Xorg folk know HAL is not 
available on all the platforms Xorg runs on and so it's a compile time 
option.

If you can show us all that HAL is available on *all* platforms where 
Xorg runs and that the Xorg folk are about to make HAL a dependency[1], 
then you probably would get no grief from making Debian match things up 
(hell it work have a non-functioning Xorg which is not an option).  
Currently though the situation is quite different and it turns out that 
even with this automagical detection support compiled in, it can be 
disabled at runtime and people can continue to *choose* to use their 
handcrafted xorg.conf files.

So why are we forcing people to use stuff that is un-needed?  Doing this 
would be no different to forcing people to install Java and Flash when 
Iceweasel is installed because "hey everyone wants to use YouTube". :-/

Remember, with your position you are also harming the embedded and low 
spec'ed machine folk.  I do not think people with small amounts of NAND 
flash for storage space will appreciate having a lot of unnecessary guff 
installed[2].

Debian runs on 11 different architectures, life's not a x86 with 2GB of 
RAM.  I left that 'other' OS eight years ago exactly for these reasons 
as I did not like have the decision making process made by someone else.

If Xorg decide to make HAL an actual dependency, then we will all deal 
with that ourselves (probably in the form of a witchhunt and burning 
down to xorg-hq)...until then there really is no reason why Debian 
should turn to the dark side.

Hell just think about the hammering of the mirrors for all the extra 
package downloading you are causing...  Some people pay for bandwidth.

I (and it seems others too) can see so many arguments against making HAL 
a dependency but only see one in favour of it (and it's not like we are 
turning off any functionality in doing this).  I think you will find 
that the main issue people have is that we think HAL/DBUS (and even what 
acpid has turned into) is fundamentally broken[3].  We have chosen to 
avoid it as Debian has enabled us to have this choice...that's why we 
use Debian.

Cheers

[1] there are already signs that other distros are getting fed up of the 
	ghastliness that HAL has turned into.  What are you going to do 
	when the world starts getting a 'hard on' for DeviceKit instead?
[2] http://www.embeddedarm.com/products/board-detail.php?product=TS-TPC-7390
	ARM + 512MB NAND + LCD screen, and you want HAL on it?
[3] we are too lazy to come up with alternatives, hell this might push 
	us over the edge

-- 
Alexander Clouter
.sigmonster says: You will triumph over your enemy.

Message #116 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Sergey Korobitsin <undertaker@arta.kz>

To: 515214@bugs.debian.org

Subject: hal for Recommends: , not Depends:

Date: Wed, 29 Apr 2009 12:56:29 +0600

I support demoting hal to Recommends. The reason is that Debian was
always the most flexible solution among the binary-based distros for me,
and if we can install less packages to get nessesary functionality, we
better install less. I've read the discussion and I think that using
workaround like equivs is not good, because equivs is usually used in very
special cases. Also, adding a xserver-xorg-nohal may cause unnessesary
maintaing issues. The solution in Subject is the most painless, I think.

-- 
Best regards, Sergey Korobitsin
Arta Software, Astana, KZ
mailto:undertaker{at}arta.kz
xmpp:undertaker@jabber.arta.kz

Message #121 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Artem Chuprina <ran@ran.pp.ru>

To: 515214@bugs.debian.org

Subject: hal for Recommends:, not Depends:

Date: Thu, 30 Apr 2009 11:37:44 +0400

Let me also vote for demoting HAL to Recommends.

So novice users will have it automatically because by default
recommeneded packages are installed, but users whose systems suffer from
HAL (there are very many such users) will not need to install it and
search how to disable it.

Message #128 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: 515214@bugs.debian.org

Subject: Xorg / HAL

Date: Thu, 14 May 2009 17:42:16 +0200

[Message part 1 (text/plain, inline)]

Hi,

just a few thoughts from a HAL co-maintainer:

As no software is bug free (and HAL or D-Bus are certainly no exception), or a
sysadmin has deliberatly decided to disable the D-Bus or HAL service from
starting during boot, I think the Xorg server needs a safe/basic fallback
anyway, if D-Bus or HAL is down and not accessible.
One recent example is [1] or [2].

Leaving the user with no keyboard or mouse in such a case is imho not a sane
behaviour.

I guess it should just assume AutoAddDevices "false" in such a case and use the
settings from xorg.conf (or if they are not set, use a basic us keyboard layout
and mouse)

If Xorg has such a fallback behaviour, demoting hal to recommends should be
certainly possible and you wouldn't even have to bail out in postinst if
AutoAddDevices has not been explictly set.

Cheers,
Michael


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527860
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527872
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #133 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Julien Cristau <jcristau@debian.org>

To: Michael Biebl <biebl@debian.org>, 515214@bugs.debian.org

Subject: Re: Bug#515214: Xorg / HAL

Date: Thu, 14 May 2009 18:51:16 +0200

On Thu, May 14, 2009 at 17:42:16 +0200, Michael Biebl wrote:

> I guess it should just assume AutoAddDevices "false" in such a case and use the
> settings from xorg.conf (or if they are not set, use a basic us keyboard layout
> and mouse)
> 
How can I make a distinction between "hal won't be started" and "hal
takes a while to start"?  Assuming NoAutoAddDevices if hal isn't there
when we start up means getting duplicated events whenever it shows up.

(also, xorg.conf devices are currently set up before the hal stuff, so
it's not clear -to me anyway- how to make this work without changing the
dix/ddx interface)

Cheers,
Julien

Message #138 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Julien Cristau <jcristau@debian.org>

Cc: 515214@bugs.debian.org

Subject: Re: Bug#515214: Xorg / HAL

Date: Thu, 14 May 2009 20:56:47 +0200

[Message part 1 (text/plain, inline)]

Julien Cristau wrote:
> On Thu, May 14, 2009 at 17:42:16 +0200, Michael Biebl wrote:
> 
>> I guess it should just assume AutoAddDevices "false" in such a case and use the
>> settings from xorg.conf (or if they are not set, use a basic us keyboard layout
>> and mouse)
>>
> How can I make a distinction between "hal won't be started" and "hal
> takes a while to start"?

I guess you can't. But do you want to wait (possibly indefinitly) for hal to
show up, leaving the user without a usable keyboard/mouse? Is your concern, that
during bootup, hal takes to long to start and is not yet available when X starts?
Wouldn't something like a 10sec timeout within Xorg help here?

  Assuming NoAutoAddDevices if hal isn't there
> when we start up means getting duplicated events whenever it shows up.

I thought, if NoAutoAddDevices is used, that Xorg ignores devices reported via
hal? Or maybe I'm just misunderstanding what you mean with duplicated events.

> (also, xorg.conf devices are currently set up before the hal stuff, so
> it's not clear -to me anyway- how to make this work without changing the
> dix/ddx interface)

Can't comment on that.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #143 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Julien Cristau <jcristau@debian.org>

To: Michael Biebl <biebl@debian.org>

Cc: 515214@bugs.debian.org

Subject: Re: Bug#515214: Xorg / HAL

Date: Fri, 15 May 2009 00:34:41 +0200

On Thu, May 14, 2009 at 20:56:47 +0200, Michael Biebl wrote:

> Julien Cristau wrote:
>   Assuming NoAutoAddDevices if hal isn't there
> > when we start up means getting duplicated events whenever it shows up.
> 
> I thought, if NoAutoAddDevices is used, that Xorg ignores devices reported via
> hal? Or maybe I'm just misunderstanding what you mean with duplicated events.
> 
Hrm yes you're right.  But since at the point where xorg.conf is
processed, we don't know whether hal will report anything, this is not
an easy plan.  We could start up with the default xorg.conf devices,
then if any hal device shows up, disable the default ones.  But that
sounds very fragile, and gets us back into the evdev vs kbd keycodes
mix, which we had so much fun with when input hotplug got first enabled
(clients not refreshing keymaps correctly, or not refreshing their grabs.
I'd rather not go back there.
Going back to look at the xorg.conf devices if nothing shows up on the
hal connection after a timeout also sounds like it'd bring its amount of
pain too.
I'm more interested in trying to figure out why people's session die on
dbus restart, which so far look like client bugs leading to X restarts
in the middle of an upgrade, and which probably need to be fixed
regardless.

Cheers,
Julien

Message #148 received at 515214@bugs.debian.org (full text, mbox, reply):

From: Pierre Ynard <linkfanel@yahoo.fr>

To: David Nusinow <david@gravitypulls.net>

Cc: 515214@bugs.debian.org, 523960@bugs.debian.org

Subject: Re: Bug#523960: equivs is surely not the solution to this problem. "Recommends:" is.

Date: Tue, 29 Sep 2009 10:33:38 +0200

Hello David,

> All of that said, it's very likely that we will downgrade the depends
> to recommends, just not right now. We have actual important bugs like
> totally broken installs that we want to deal with first.

It's been 5 months since then, could you please give us an update on
this?

I'm sure that some people have refrained from upgrading X.org because of
this, but this is getting to the point of ridiculous for them.

Regards,

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."

Message #153 received at 515214-close@bugs.debian.org (full text, mbox, reply):

From: Julien Cristau <jcristau@debian.org>

To: 515214-close@bugs.debian.org

Subject: Bug#515214: fixed in xorg 1:7.5~2

Date: Sat, 28 Nov 2009 19:34:49 +0000

Source: xorg
Source-Version: 1:7.5~2

We believe that the bug you reported is fixed in the latest version of
xorg, which is due to be installed in the Debian FTP archive:

libglu1-xorg-dev_7.5~2_all.deb
  to main/x/xorg/libglu1-xorg-dev_7.5~2_all.deb
libglu1-xorg_7.5~2_all.deb
  to main/x/xorg/libglu1-xorg_7.5~2_all.deb
x11-common_7.5~2_all.deb
  to main/x/xorg/x11-common_7.5~2_all.deb
xbase-clients_7.5~2_all.deb
  to main/x/xorg/xbase-clients_7.5~2_all.deb
xlibmesa-gl-dev_7.5~2_all.deb
  to main/x/xorg/xlibmesa-gl-dev_7.5~2_all.deb
xlibmesa-gl_7.5~2_all.deb
  to main/x/xorg/xlibmesa-gl_7.5~2_all.deb
xlibmesa-glu_7.5~2_all.deb
  to main/x/xorg/xlibmesa-glu_7.5~2_all.deb
xorg-dev_7.5~2_all.deb
  to main/x/xorg/xorg-dev_7.5~2_all.deb
xorg_7.5~2.dsc
  to main/x/xorg/xorg_7.5~2.dsc
xorg_7.5~2.tar.gz
  to main/x/xorg/xorg_7.5~2.tar.gz
xorg_7.5~2_i386.deb
  to main/x/xorg/xorg_7.5~2_i386.deb
xserver-xorg-input-all_7.5~2_i386.deb
  to main/x/xorg/xserver-xorg-input-all_7.5~2_i386.deb
xserver-xorg-video-all_7.5~2_i386.deb
  to main/x/xorg/xserver-xorg-video-all_7.5~2_i386.deb
xserver-xorg_7.5~2_i386.deb
  to main/x/xorg/xserver-xorg_7.5~2_i386.deb
xutils_7.5~2_all.deb
  to main/x/xorg/xutils_7.5~2_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 515214@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Julien Cristau <jcristau@debian.org> (supplier of updated xorg package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Sat, 28 Nov 2009 20:10:31 +0100
Source: xorg
Binary: x11-common xserver-xorg xserver-xorg-video-all xserver-xorg-input-all xorg xorg-dev xlibmesa-gl xlibmesa-gl-dev xlibmesa-glu libglu1-xorg libglu1-xorg-dev xbase-clients xutils
Architecture: source all i386
Version: 1:7.5~2
Distribution: experimental
Urgency: low
Maintainer: Debian X Strike Force <debian-x@lists.debian.org>
Changed-By: Julien Cristau <jcristau@debian.org>
Description: 
 libglu1-xorg - transitional package for Debian etch
 libglu1-xorg-dev - transitional package for Debian etch
 x11-common - X Window System (X.Org) infrastructure
 xbase-clients - miscellaneous X clients - metapackage
 xlibmesa-gl - transitional package for Debian etch
 xlibmesa-gl-dev - transitional package for Debian etch
 xlibmesa-glu - transitional package for Debian etch
 xorg       - X.Org X Window System
 xorg-dev   - the X.Org X Window System development libraries
 xserver-xorg - the X.Org X server
 xserver-xorg-input-all - the X.Org X server -- input driver metapackage
 xserver-xorg-video-all - the X.Org X server -- output driver metapackage
 xutils     - X Window System utility programs metapackage
Closes: 515214 523960 558236
Changes: 
 xorg (1:7.5~2) experimental; urgency=low
 .
   * Drop xorg-dev dependency on libxkbui-dev, which has no users.
   * Update xorg-dev long description.  There are no static-only X libs
     nowadays.
   * xorg-dev: don't depend on libxevie-dev.
   * xserver-xorg-video-all: don't depend on -intel on non-linux.
   * Switch hal dependency to a recommends, and make it kfreebsd-only (closes:
     #515214).
   * Only install the hal fdi and callout on kfreebsd.
   * Add 'Old Changelog' in debian/changelog to make lintian happy.
   * Add ${misc:Depends} to all packages' Depends fields.
   * Drop dependency on console-setup, xserver-xorg-core now pulls in
     keyboard-configuration (closes: #558236, #523960).
   * Depend on xserver-xorg-core 1.7.
   * xserver-xorg.NEWS: /etc/default/console-setup moved to
     /etc/default/keyboard.  Also note that evdev is Linux-only.
   * x11-common.NEWS: fix syntax (lintian).
   * x11-common.templates: use "for internal use" instead of "internal use
     only" in Description (lintian).
   * Add lintian overrides for xorg, x11-common and xserver-xorg.
   * Bump Standards-Version to 3.8.3.
Checksums-Sha1: 
 20c067cf6a514b48c8792cddf1da1df9d234a37f 1711 xorg_7.5~2.dsc
 137f6ce49391dad2d6d6f496fd413a870226e2dd 880728 xorg_7.5~2.tar.gz
 32cff6c8ccf3510f3ee7b2aa75bba0a878e4a371 278866 x11-common_7.5~2_all.deb
 ea84c8724c0efa5cf65229aa37f28d8d02fd815b 30688 xorg-dev_7.5~2_all.deb
 dc99a12c075e6b9b3205cbe0295bee24e9d809aa 30296 xlibmesa-gl_7.5~2_all.deb
 d500132d3480f9003f81f5900947f05aa95f9b93 30302 xlibmesa-gl-dev_7.5~2_all.deb
 9ae284f045a2c75767555325fe22ddd918bb7439 30298 xlibmesa-glu_7.5~2_all.deb
 5ccd3cb9a9ffd21d92294cc25f10005fdc5eef71 30288 libglu1-xorg_7.5~2_all.deb
 f57fe626109323ab44f92aeb9a46a92e82ed20cd 30298 libglu1-xorg-dev_7.5~2_all.deb
 dc3f1dfab538142c33046ba458dec2690b063ce2 36674 xbase-clients_7.5~2_all.deb
 9547c7e7a0cdef47a6d44aca3cd7d8f5103b4362 36774 xutils_7.5~2_all.deb
 28942141d1910b6b61190dd91efdf81da72a0a1f 51442 xserver-xorg_7.5~2_i386.deb
 4f30bffd996a2cce7d344cd2c67143e0175820a3 30498 xserver-xorg-video-all_7.5~2_i386.deb
 e0f3b93235f2d1cc4948c6f7f30ed94f449a7a39 30356 xserver-xorg-input-all_7.5~2_i386.deb
 00b2dc8b21688e1e6c1c5b3df983ba815354300a 30864 xorg_7.5~2_i386.deb
Checksums-Sha256: 
 7bb0856d0f6029398a637123136f21f0ab957c3fa82e52bab69d4ed98128afac 1711 xorg_7.5~2.dsc
 6abf24f5c3c785f63c17856d7b14cb1f366365f080e729a65029b6bb23d328ab 880728 xorg_7.5~2.tar.gz
 da51fa11445fe6c60811819e70251684278a1f0c0a9e5223aa21372f083b5e47 278866 x11-common_7.5~2_all.deb
 7e860e78a2623de9a4665430f4df8f17334c5f100b5722f7ddec8f1ead2ed336 30688 xorg-dev_7.5~2_all.deb
 117b45ba57b0409de838c2bc305659b3120c49fed88b4a5e8f02bf064dfb1e08 30296 xlibmesa-gl_7.5~2_all.deb
 dd6b0f1dbf1fbf99f9251eb6a569830f7aeb64b1f50e79b5ebb3851b1f797d61 30302 xlibmesa-gl-dev_7.5~2_all.deb
 caa979107d9b7219402b0a3bc6dc3ae17c0dffde52f5eaf800d99ba2d7494455 30298 xlibmesa-glu_7.5~2_all.deb
 40abf1bc33a8fd8c3074824a0e27fbada0fabf3e4d39401f5807866c19aed2a0 30288 libglu1-xorg_7.5~2_all.deb
 f2608d3a3b97113cba7716c4a17d53c133a4f477a6e9c7d6f54969fad862ebec 30298 libglu1-xorg-dev_7.5~2_all.deb
 e399edee01c9e65cec281899eb4e1516f8f395429ee0e4d304d8d2909f7b3be9 36674 xbase-clients_7.5~2_all.deb
 8915d2601bf38b678a44bab29a2a089b76f803b164baeb68cc77a5555f4cf145 36774 xutils_7.5~2_all.deb
 797ff06d8158d8fec37a7b8bf7bb9b113ab150a01bcb4ab9713ea5db3f759af5 51442 xserver-xorg_7.5~2_i386.deb
 a44f74bb0895ba6be04a195c4faa3637ff985662520158035ecfaab3ce800da1 30498 xserver-xorg-video-all_7.5~2_i386.deb
 1df51e3532baa574d519e9338d8d87b904008cb964b44777a0de32f6add12813 30356 xserver-xorg-input-all_7.5~2_i386.deb
 5fae13de05837af5cdc000f1dfd420536dc4f5c81c62c39f530fc381d300e2f6 30864 xorg_7.5~2_i386.deb
Files: 
 a8cd3bbdc5eceb85ab7e68e25436ce85 1711 x11 optional xorg_7.5~2.dsc
 ab99965f4a891aa26494b6357833dd22 880728 x11 optional xorg_7.5~2.tar.gz
 7a9b05763ea0448c18c315cb583657f7 278866 x11 optional x11-common_7.5~2_all.deb
 bbd22968b32d7a57dc7ccd5f466c6f59 30688 x11 optional xorg-dev_7.5~2_all.deb
 d0e7d8ff6de412bd54c10856d9bd96b0 30296 libs optional xlibmesa-gl_7.5~2_all.deb
 400db5377d248b259d0a467e922bb3ce 30302 libdevel optional xlibmesa-gl-dev_7.5~2_all.deb
 5451cf1cf06f944b8840b1b12959e37a 30298 libdevel optional xlibmesa-glu_7.5~2_all.deb
 0efd000b5b63de05d7854acee3f3f5d1 30288 libs optional libglu1-xorg_7.5~2_all.deb
 f89e008bd399795b7701d5b256d94bfc 30298 libdevel optional libglu1-xorg-dev_7.5~2_all.deb
 6522e41e7c2178713abeb796982dc5c1 36674 x11 optional xbase-clients_7.5~2_all.deb
 b8ede0d8cde7389037f326f272e1d219 36774 x11 optional xutils_7.5~2_all.deb
 9a310b3abbe5dfed3e625f0aabe9aaa4 51442 x11 optional xserver-xorg_7.5~2_i386.deb
 c49fe66f87d15f1cab8c453592e3cbe1 30498 x11 optional xserver-xorg-video-all_7.5~2_i386.deb
 885c2cb5d2e8b0231d2693ca07b8a21d 30356 x11 optional xserver-xorg-input-all_7.5~2_i386.deb
 a4b421094ac4feb6704127a11a9d119f 30864 x11 optional xorg_7.5~2_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJLEXe0AAoJEDEBgAUJBeQMf4wP/ivcZLpDj7xUoRP6cvIIsT1l
Bx9xeCeF/bb2RWO1x1nkGwJ+m98noRa3qupabLpo/sbHolBVhSI8qqNyNfs4BxWa
xaIP1olwvHX7iN58/Ko8nieHhe17+SUNLfkTdcAGQ7B54OIbjptj8GS8DqshAjGa
HmOm2WwOK82yI/I8tZSGu+7o9QYXPzTBZF3ugRO1SGDdWZYsYjBuqgfwcZYfW9k0
GC3NGatdvC1jdeKJFq4wZ+YQ9aZSQaW7allim11c212OiN/Nsl+WchwhxqaA8Xrh
YnKhpmE3LNN53a+kQzlcjIaQNSj98no2C55St8hii8mjxDXRvocuHSH4ucKj3Rd6
u4nPHYQpzb0SOd+i+Uoz2hzgDz29cRRYiIKpUjRGt9PaIfvUb9huYpAF3vbGpkWU
xJ6VeezjWRGIoRvmRCZZNOt4NUIfmZqMjT3y+UgYL5iSMbfLRNQOiZqgHiPt9naJ
Wa1sVvfG8NmkHZqsHn+jR7lCVjo2HwWkQFSkLGf+SpdRHnikPTGnkiG+Ga9KL8Qz
y0DQNMEVKJyXRtde4Oa5lykkI2FTHVjXWZQSgvikgwA7xq8bqAvppVq2N18iVDRN
kpa09ZBTcxK8k9TbT8MlGu/xfXmuhFbdy//RafCTTGLzidJrrslkVQm3mO0btMEI
5BaydsoDID2+Xh4Go810
=2jdy
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.