Bug#816076: wicd-daemon: upgrade reconfigures static ethernet interface, and kills ssh sessions.

[Andrew Vaughan]

Hi Vincent.

I was just about to update this bug after purging wicd today.

On 20 April 2016 at 19:58, Vincent Lefevre  wrote:
>
> Probably the same bug as bug 557156 (from 2009!). The problem is that
> wicd-daemon tries to reconfigure the ethernet interface even though
> it is configured not to connect to it automatically (which should be
> and is the default). A workaround is to remove eth0 from the wicd
> configuration.
>

As far as I am aware, I have never touched the wicd config files.  And a
package shouldn't ship with a config that will break an otherwise valid
configuration belonging to a different package on package upgrade.
Certainly not without _big_ warnings, and certainly not for a package
pulled in by recommendations from a relatively common metapackage.
(I included a copy of the relevant config files at the bottom of the
original bug report).

Now for the new stuff.  Today I removed wicd and related packages.
I'm pretty sure I purged the config files.  To cut a long story short,
purging wicd and related packages resulted in eth0 having it's IPv4
address removed.  Eth0 was still up with a IPv6 address.  But the
machine was no longer reachable over IPv4.  Probably just a
different variant of the same underlying buggy behaviour.

Thanks for your work on Debian.

Andrew V.

Bug#816076: wicd-daemon: upgrade reconfigures static ethernet interface, and kills ssh sessions.

[Andrew Vaughan]

On 7 March 2016 at 04:16, Axel Beckert <a...@debian.org> wrote:
> Hi Andrew,
>
> Andrew Vaughan wrote:
>> My home server is a headless box, administered from a vnc session tunnelled
>> over ssh.  It has no wifi adaptor, just a single ethernet port that is
>> statically configured via /etc/network/interfaces.
>
> So why are you using wicd at all? I don't see why you need wicd in
> such a setup.
>

Wicd was automatically installed because lxde recommends wicd |
network-manager-gnome.

Yes, I could just remove wicd, but that would be working around what I
view as buggy behaviour in wicd-daemon.  If relatively common
meta-packages like lxde are going to pull in services like wicd-daemon
via recommends, then those services must behave sanely if the user
never touches their config.

Network-manager-gnome is also installed because gnome-core recommends
it.  I wonder whether we have races between them?

>> This behaviour is wrong on so many levels.
>>
>> 1. A package upgrade should never bring down an existing in-use interface
>> without asking the user/admin first.
>
> I agree here mostly. It's though only a real issue if the interface
> doesn't come up again with the same IP afterwards.
>

Even if it comes up with the same ip address it is a potential data loss bug.
eg a ssh user has unsaved work in some console application, when the
connection is lost.  There is no easy way to reconnect to the console
application. This may result in data loss.

>> Wicd-daemon should not assume that just because it is installed it
>> owns all the network interfaces.
>
> I disagree here. In Debian, it's common that NetworkManager and
> similar tools manage those interfaces from /etc/network/interfaces
> which are not listed (or maybe also those which are on "auto").

Nowhere in the package description does wicd say that it will attempt
to automatically maintain an active internet connection without any
prior user/admin interaction/config.

In principle, I don't have a problem with it trying to automatically
configure interfaces that have no existing config.  But if I were to
run a virtualisation script that adds a virtual interface, then starts
a virtual machine, is wicd going to see the new interface and try to
configure that, and hence race the the startup of the virtual machine?
 If I plugin a usb wireless adaptor is it going to blindly attempt to
connect to any available wifi network, even if no wifi network has
ever been configured on this device?  If the user were to attempt to
use network-manager gnome to change an existing wifi connection, are
the 2 going to fight over which one gets to configure the
wifi-adapter?

But regardless, if it hasn't been explicitly given permission to
change network configs, then it should respect the existing config of
any interfaces that are up before it starts, or that the user or admin
configures using other tools, including whilst it is running.
Certainly installing/reinstalling/upgrading wicd-daemon shouldn't
touch any network configuration that was made with other tools,
without the admin or user having done something to give wicd
permission to manage network config.

On a related note (the following typed manually from memory, so only
approximate)

ifdown eth0

do something for 30 sec (like edit /etc/network/interfaces )

ifup eth0

error: file in use. can't bring up eth0

ifdown eth0

error: eth0 not up

Not sure whether that was network-manager or wicd that brought eth0
up, but it could be an head-scratching time for an admin who had never
noticed that they were installed.   And it should have better
integration with ifup/down, so that both tools are on the same page as
to what the interface status is and preferably what the interface
status is supposed to be.

>
>> I have been through basically the same problems with network-manager in the
>> past.  Issues like this are why so many people are hostile to that package.
>
> Indeed. That's why I'm using wicd, too. It was though worse with
> NetworkManager back then since usually, the network interface stayed
> down afterwards. That got fixed in the meanwhile, though, IIRC.
>

I remember un-installing network-manager a few times, only for
dependencies to try to pull it back in.

Andrew

Bug#816076: wicd-daemon: upgrade reconfigures static ethernet interface, and kills ssh sessions.

[Andrew Vaughan]

Package: wicd-daemon
Version: 1.7.4+tb2-1
Severity: serious

Dear Maintainer,

My home server is a headless box, administered from a vnc session tunnelled
over ssh.  It has no wifi adaptor, just a single ethernet port that is
statically configured via /etc/network/interfaces.

During today's package update my ssh connection died partway through, during
setup of wicd-daemon.  Last line was "Installing new version of config file
/etc/wicd/encryption/templates/wpa2-peap ..."

Then ssh refused to re-connect.

I finally got re-connected after discovering that wicd-daemon had
reconfigured eth0 to a different ip address.

(Note that if this had been a remote box, then I might not have been able to
discover the new ip address.  Potentially this might lead require in person
intervention in such cases).

This behaviour is wrong on so many levels.

1. A package upgrade should never bring down an existing in-use interface
without asking the user/admin first.  (There is a reason that ssh takes care to
not kill the existing session during package upgrades.  Consider what would
have happened if that had been a normal ssh session, and aptitude had
stalled part way through asking for user input).

2. I don't think I have ever actually used wicd.  Wicd-daemon should not
assume that just because it is installed it owns all the network interfaces.
It should only be touching interfaces it has configured/or the the user/admin
requests that it configure.

3. Even if it needs to reconfigure all interfaces, and even if we assume that
is owns all the network interfaces, it _must_ respect the admins static
configuration in /etc/network/interfaces , unless the user/admin specifically
requests it to reconfigure that interface.

Personally I think it should respect any and all pre-exisiting interfaces,
unless and until the admin/user asks for them to be changed.  That means
no touching of any interfaces it hasn't configured, including any interfaces
that the user/admin might have configured in non-standard ways, including
interactively.

I have reproduced the above problem using "aptitude reinstall wicd-daemon",
so it is definitely caused by installing the current version of wicd-daemon.

I have been through basically the same problems with network-manager in the
past.  Issues like this are why so many people are hostile to that package.

Thanks for your work on Debian.

Andrew V.






For reference, in case these help.


# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.40
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 192.168.1.1 203.12.160.35 203.12.160.36



# ifconfig
eth0: flags=4163  mtu 1500
inet 192.168.1.55  netmask 255.255.255.0  broadcast 192.168.1.255
inet6 fe80::a2b3:ccff:fee2:5ad3  prefixlen 64  scopeid 0x20
ether a0:b3:cc:e2:5a:d3  txqueuelen 1000  (Ethernet)
RX packets 342875  bytes 75660357 (72.1 MiB)
RX errors 0  dropped 60907  overruns 0  frame 0
TX packets 302442  bytes 162293744 (154.7 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device interrupt 18

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 0  (Local Loopback)
RX packets 31913079  bytes 22201337028 (20.6 GiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 31913079  bytes 22201337028 (20.6 GiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0



# ls -al /etc/wicd/
total 40
drwxr-xr-x   4 root root  4096 Feb 27 14:45 .
drwxr-xr-x 171 root root 12288 Feb 27 14:45 ..
-rw-r--r--   1 root root   927 Nov  4  2014 dhclient.conf.template
-rw-r--r--   1 root root   931 Dec 22  2014 dhclient.conf.template.default
drwxr-xr-x   3 root root  4096 Nov  4  2014 encryption
-rw---   1 root root   485 Feb 27 14:45 manager-settings.conf
drwxr-xr-x   6 root root  4096 Nov  4  2014 scripts
-rw---   1 root root   320 Feb 27 14:45 wired-settings.conf
-rw---   1 root root 0 Feb 27 14:45 wireless-settings.conf



# cat /etc/wicd/wired-settings.conf
[wired-default]
ip = None
broadcast = None
netmask = None
gateway = None
search_domain = None
dns_domain = None
dns1 = None
dns2 = None
dns3 = None
beforescript = None
afterscript = None
predisconnectscript = None
postdisconnectscript = None
encryption_enabled = None
default = True
dhcphostname = 
lastused = True



# cat /etc/wicd/manager-settings.conf
[Settings]
backend = external

Bug#545335: FTBFS on at least powerpc and sparc

[Andrew Vaughan]

On Mon, 7 Sep 2009, Luk Claes wrote:
 Package: vtk
 Version: 5.2.1-9
 Severity: serious

 Hi

 Please look into why vtk fails to build from source on at least the
 powerpc and sparc buildds.

 There are quite some java packages waiting on vtk to be able to migrate
 to testing.

 Cheers

 Luk

The failure on powerpc looks like another instance of cmake looking for
/usr/lib/jvm/default-java/jre/lib/powerpc/libjawt.so 
while openjdk6 provides 
/usr/lib/jvm/default-java/jre/lib/ppc/libjawt.so [1].

The sparc failure is a gcc-4.3 ice [2].  cc-ing debian-gcc, hopefully someone 
there can take a look.


[1] http://lists.debian.org/debian-java/2009/09/msg7.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544674

[2] 
https://buildd.debian.org/fetch.cgi?pkg=vtk;ver=5.2.1-9;arch=sparc;stamp=1251744017
[ 35%] Building CXX object 
Graphics/CMakeFiles/vtkGraphics.dir/vtkButterflySubdivisionFilter.o
In file included from /usr/include/c++/4.3/fstream:783,
 from 
/build/buildd-vtk_5.2.1-9-sparc-UYc7Ay/vtk-5.2.1/Common/vtkIOStream.h:36,
 from 
/build/buildd-vtk_5.2.1-9-sparc-UYc7Ay/vtk-5.2.1/Common/vtkSystemIncludes.h:40,
 from 
/build/buildd-vtk_5.2.1-9-sparc-UYc7Ay/vtk-5.2.1/Common/vtkIndent.h:24,
 from 
/build/buildd-vtk_5.2.1-9-sparc-UYc7Ay/vtk-5.2.1/Common/vtkObjectBase.h:43,
 from 
/build/buildd-vtk_5.2.1-9-sparc-UYc7Ay/vtk-5.2.1/Common/vtkObject.h:41,
 from 
/build/buildd-vtk_5.2.1-9-sparc-UYc7Ay/vtk-5.2.1/Filtering/vtkAlgorithm.h:32,
 from 
/build/buildd-vtk_5.2.1-9-sparc-UYc7Ay/vtk-5.2.1/Filtering/vtkPolyDataAlgorithm.h:37,
 from 
/build/buildd-vtk_5.2.1-9-sparc-UYc7Ay/vtk-5.2.1/Graphics/vtkInterpolatingSubdivisionFilter.h:30,
 from 
/build/buildd-vtk_5.2.1-9-sparc-UYc7Ay/vtk-5.2.1/Graphics/vtkButterflySubdivisionFilter.h:45,
 from 
/build/buildd-vtk_5.2.1-9-sparc-UYc7Ay/vtk-5.2.1/Graphics/vtkButterflySubdivisionFilter.cxx:15:
/usr/include/c++/4.3/bits/fstream.tcc: In member function 'virtual typename 
std::basic_filebuf_CharT, _Traits::int_type std::basic_filebuf_CharT, 
_Traits::underflow()':
/usr/include/c++/4.3/bits/fstream.tcc:331: internal compiler error: 
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions.

Cheers 
Andrew



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#502813: dhelp: /etc/cron.weekly/dhelp fails to rebuild index

[Andrew Vaughan]

Package: dhelp
Version: 0.6.13
Severity: serious

Hi

/etc/cron.weekly/dhelp fails to rebuild /var/lib/dhelp/documents.index, 
after deleting it.  Running it manually produces no error message. 

Severity serious since this a significant regression from 0.6.12.

Downgrading to 0.6.12 fixes the problem.  (As an aside 0.6.12 
/etc/cron.weekly/dhelp now takes 8m 44sec to rebuild the index.  This is 
the same machine where 0.6.12 was taking 150 mins a month ago.  This may 
render the changes that 0.6.13 introduced unnecessary).

Thanks for your work in Debian.

Andrew V.


-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dhelp depends on:
ii  doc-base  0.8.16 utilities to manage online documen
ii  libcommandline-ruby1.80.7.10-10  Ruby library to write command-line
ii  libdata-page-perl 2.00-4 Help when paging through sets of r
ii  libdb-ruby1.8 [libdb4.2-r 0.6.5-2Interface to Berkeley DB for Ruby 
ii  libgettext-ruby1.81.91.0-1.1 Gettext for ruby1.8
ii  libhtml-parser-perl   3.56-1+b1  A collection of modules that parse
ii  liblocale-gettext-perl1.05-4 Using libc functions for internati
ii  libtemplate-perl  2.19-1.1lenny1 template processing system written
ii  liburi-perl   1.35.dfsg.1-1  Manipulates and accesses URI strin
ii  perl-modules  5.10.0-15  Core Perl modules
ii  pstotext  1.9-4  Extract text from PostScript and P
ii  ruby1.8   1.8.7.72-1 Interpreter of object-oriented scr
ii  swish++   6.1.5-1Simple Document Indexing System fo
ii  xpdf-utils3.02-1.4   Portable Document Format (PDF) sui

Versions of packages dhelp recommends:
ii  epiphany-gecko [www-bro 2.22.3-4+b1  Intuitive GNOME web browser - Geck
ii  galeon [www-browser]2.0.6-2  GNOME web browser for advanced use
ii  iceape-browser [www-bro 1.1.12-1 Iceape Navigator (Internet browser
ii  iceweasel [www-browser] 3.0.3-2  lightweight web browser based on M
ii  konqueror [www-browser] 4:3.5.9.dfsg.1-5 KDE's advanced file manager, web b
ii  w3m [www-browser]   0.5.2-2+b1   WWW browsable pager with excellent

Versions of packages dhelp suggests:
ii  apache2-mpm-prefork [httpd]   2.2.9-10   Apache HTTP Server - traditional n
pn  catdvinone (no description available)
ii  html2text 1.3.2a-5   advanced HTML to text converter
ii  info2www  1.2.2.9-24 Read info files with a WWW browser
pn  man2html  none (no description available)
ii  w3m   0.5.2-2+b1 WWW browsable pager with excellent

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#427697: Fwd: Re: Bug#427697: Is sbackup maintained? If not, what to do?

[Andrew Vaughan]

Forgot to cc the bug report.  Apologies to anyone who gets this twice.

--  Forwarded Message  --

Subject: Re: Bug#427697: Is sbackup maintained? If not, what to do?
Date: Friday 16 May 2008 13:07
From: Andrew Vaughan [EMAIL PROTECTED]
To: [EMAIL PROTECTED]

On Friday 16 May 2008 10:20, Charles Plessy wrote:
 Since the revitalisation of sbackup is expected after the freezing of
 Lenny, we have to solve the most important bugs of the current version
 of sbackup. I do not know enough of python for helping on bug #427697
 (the gid of the backups). If Aziz provides a patch, I can prepare a NMU
 for this one, #479826 (using su-t-root-X as su wrapper) and #431936
 (tranlations). I can also make the package non-native (as it has anyway
 been suggested on this list for NMUs).

 By the way, can somebody suggest an appropriate gid ?

There is the adm group, but please think very carefully about the security of
private/privileged information.

I'm not familiar with sbackup, but if its backuping mode 0600 files, then the
resulting backups should be readably only by the original owner or root,
unless explicitly configured otherwise.

HTH




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#417673: All acronis images on my FAT32 are truncated to from 4294966784 bytes 0 after running dosfsck

[Andrew Vaughan]

Hi Peter

On Tuesday 25 March 2008 00:30, Peter Koek wrote:
 I am searching for an update for the dosfstools in which this bug is
 fixed. I am using dosfstools-2.11-8.fc7. I have a FAT32 partition on
 which I keep all my acronis disk images, however after using dosfsck all
 my images are now truncated from 4294966784 bytes to 0. I have searched
 the web for this problem, and I found this was a really old bug, the
 first reports I found where 3 years old.

This bug was fixed in Debian in version 2.11-2.2. You can download 
fixed .debs from http://packages.debian.org/lenny/dosfstools.  If nobody 
has already done so, please do report this bug to the fedora bug tracking 
system.

Andrew V.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#470118: tetex-base: Transitional package that should depend and/or recommend tex-foo.

[Andrew Vaughan]

Package: tetex-base
Version: 2007-13
Severity: serious

Hi

From the description

 teTeX is no longer developed upstream, and has been replaced by the TeX
 Live collection.  This is a transitional package to bring former teTeX 
 users a decent selection of TeX Live packages.  It  can be safely removed 
 (unless some external packages still depend on tetex-base).

However the package does not depend or recommend any packages, and so
doesn't provide a decent selection of TeX Live packages.

Thanks for you work in Debian.
Andrew V.


-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-486
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#466036: lmodern: etch-lenny upgrade fails

[Andrew Vaughan]

Hi Frank

On Sunday 17 February 2008 05:14, Frank Küster wrote:
 Andrew Vaughan [EMAIL PROTECTED] wrote:
  During aptitude upgrade, lmodern 1.010x-4 fails to install.  The
  relevant output is quoted below.  I have snapshotted the vm, so let me
  know if you need help tracking this down.

 The output of

 dpkg -l tetex-*
 dpkg -l texlive-* | grep -v ^un

 would be helpful. I think it needs to conflict with etch's teTeX, or
 depend on lenny's TeXLive.

 Thanks for reporting, Frank

Looking at the changelog.

 lmodern  (1.01-1) experimental; urgency=low
   [...]
   * add dependency on tex-common = 1.1 to get a working dh_installtex
 --priority option
That dependency bump seems to have been lost as lmodern 1.010x-4 still 
depends on tex-common = 0.7.

Andrew V.


$ dpkg -l tetex-*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name  Version   Description
+++-=-=-
ii  tetex-base3.0.dfsg.3-5etch1 Basic TeX input files of teTeX
ii  tetex-bin 3.0-30The teTeX programs
ii  tetex-doc 3.0.dfsg.3-5etch1 The documentation component of the 
Debian te
un  tetex-doc-nonfree none(no description available)
un  tetex-eurosym none(no description available)
ii  tetex-extra   3.0.dfsg.3-5etch1 Additional TeX input files of teTeX
un  tetex-french  none(no description available)
un  tetex-nonfree none(no description available)


$ dpkg -l texlive-* | grep -v ^un
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name  VersionDescription
+++-=-==-

Bug#466232: libopenssl-ruby1.8: Fails to install (etch-lenny upgrade)

[Andrew Vaughan]

Package: libopenssl-ruby1.8
Version: 1.8.6.111-4
Severity: serious
Justification: Fails to install

Hi

During a test dist-upgrade etch-lenny (on a different machine)

Unpacking replacement libopenssl-ruby1.8 ...
dpkg: error processing 
/var/cache/apt/archives/libopenssl-ruby1.8_1.8.6.111-4_i386.deb (--unpack):
 trying to overwrite `/usr/lib/ruby/1.8/drb/ssl.rb', which is also in package 
libruby1.8
dpkg: regarding .../libruby1.8_1.8.6.111-4_i386.deb containing libruby1.8:
 libruby1.8 conflicts with libopenssl-ruby1.8 ( 1.8.6)
 libopenssl-ruby1.8 (version 1.8.5-4etch1) is installed.
dpkg: error processing /var/cache/apt/archives/libruby1.8_1.8.6.111-4_i386.deb 
(--unpack):
 conflicting packages - not installing libruby1.8
Preparing to replace libxslt1-dev 1.1.19-1 (using 
.../libxslt1-dev_1.1.22-1_i386.deb) ...

I note that you do depend on libruby1.8 = 1.8.6.111, so that normally 
libruby1.8 would be upgraded first, however libruby1.8 conflicts with 
libopenssl-ruby1.8  1.8.6, ie with the version currently installed.

Thanks for your work in Debian.

Andrew V.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#466036: lmodern: etch-lenny upgrade fails

[Andrew Vaughan]

Package: lmodern
Version: 1.010x-4
Severity: serious

Hi

I'm starting to test upgrades etch - lenny in a virtual machine.

During aptitude upgrade, lmodern 1.010x-4 fails to install.  The relevant
output is quoted below.  I have snapshotted the vm, so let me know if you 
need help tracking this down.

Thanks for your work in Debian

Andrew V.


Setting up lmodern (1.010x-4) ...
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time...
updmap-sys failed. Output has been stored in
/tmp/updmap.gCOe3392
Please include this file if you report a bug.

Sometimes, not accepting conffile updates in /etc/texmf/updmap.d
causes updmap-sys to fail.  Please check for files with extension
.dpkg-dist or .ucf-dist in this directory

dpkg: error processing lmodern (--configure):
 subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
 lmodern
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install.  Trying to recover:
Setting up lmodern (1.010x-4) ...
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time...
updmap-sys failed. Output has been stored in
/tmp/updmap.KCdg3769
Please include this file if you report a bug.

Sometimes, not accepting conffile updates in /etc/texmf/updmap.d
causes updmap-sys to fail.  Please check for files with extension
.dpkg-dist or .ucf-dist in this directory

dpkg: error processing lmodern (--configure):
 subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
 lmodern

$ sudo cat /tmp/updmap.KCdg3769
Password:
updmap-sys: This is updmap-sys, version 1107552857-debian
updmap-sys: using transcript file `/var/lib/texmf/web2c/updmap-sys.log'

updmap is creating new map files using the following configuration:

  config file: `/var/lib/texmf/web2c/updmap.cfg'
  dvips output directory: `/var/lib/texmf/fonts/map/dvips/updmap'
  pdftex output directory: `/var/lib/texmf/fonts/map/pdftex/updmap'
  dvipdfm output directory: `/var/lib/texmf/fonts/map/dvipdfm/updmap'

  prefer outlines: `true'
  texhash enabled: `false'
  download standard fonts (dvips): `false'
  download standard fonts (pdftex): `true'
  download standard fonts (dvipdfm): `true'

updmap-sys: Scanning for LW35 support files

!!! ERROR! The map file `dvips35.map' has not been found at all.

Either put this file into the right place or remove the
reference from the configuration files - see
update-updmap(1).

$ sudo find /etc -name *-dist
$ sudo find / -name dvips35.map
/usr/share/texmf-tetex/fonts/map/dvips/tetex/dvips35.map
$ ls -l /usr/share/texmf-tetex/fonts/map/dvips/tetex/dvips35.map
-rw-r--r-- 1 root root 8125 2005-01-09 09:54 
/usr/share/texmf-tetex/fonts/map/dvips/tetex/dvips35.map
$ 

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.18-6-686 (SMP w/1 CPU core)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lmodern depends on:
ii  defoma   0.11.10-0.2 Debian Font Manager -- automatic f
ii  tex-common   1.10common infrastructure for building
ii  xfonts-utils 1:1.0.1-1   X Window System font utility progr

lmodern recommends no packages.

-- no debconf information






-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#417673: /sbin/fsck.vfat incorrectly truncates files

[Andrew Vaughan]

tags 417673 + patch
thanks

Hi

The attached patch stolen from 
http://patches.ubuntu.com/d/dosfstools/dosfstools_2.11-2.1ubuntu3.patch
fixes #417673 for me.  

Release team is this too late for etch r0?

Andrew V.

diff -pruN 2.11-2.1/debian/changelog 2.11-2.1ubuntu3/debian/changelog
--- 2.11-2.1/debian/changelog	2006-12-19 05:08:31.0 +
+++ 2.11-2.1ubuntu3/debian/changelog	2006-12-19 05:08:20.0 +
@@ -1,3 +1,28 @@
+dosfstools (2.11-2.1ubuntu3) feisty; urgency=low
+
+  * Fix a hang when dosfsck runs out of names for renamed files.
+- Print an error message instead of doing an infinite loop.
+- Using the file extension for more available names.
+Thanks to Onno Benschop for providing the initial fix.
+Closes: LP#68153.
+
+ -- Stefan Potyra [EMAIL PROTECTED]  Tue, 19 Dec 2006 03:20:37 +0100
+
+dosfstools (2.11-2.1ubuntu2) feisty; urgency=low
+
+  * Fix some integer overflows in check.c and fat.c which resulted in 
+large files (close to 32-bit limit) being errorenously truncated
+to 0 bytes. Closes LP#62831.
+
+ -- Stefan Potyra [EMAIL PROTECTED]  Tue, 19 Dec 2006 02:21:45 +0100
+
+dosfstools (2.11-2.1ubuntu1) dapper; urgency=low
+
+  * Applied patch from Fred (launchpad bug 17960) to correct issue where
+dosfsck cannot truncate a file if another file shares its clusters.
+
+ -- Daniel Silverstone [EMAIL PROTECTED]  Mon,  3 Apr 2006 19:05:57 +0100
+
 dosfstools (2.11-2.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -pruN 2.11-2.1/dosfsck/check.c 2.11-2.1ubuntu3/dosfsck/check.c
--- 2.11-2.1/dosfsck/check.c	2005-03-12 15:08:43.0 +
+++ 2.11-2.1ubuntu3/dosfsck/check.c	2006-12-19 05:08:20.0 +
@@ -305,14 +305,14 @@ static void truncate_file(DOS_FS *fs,DOS
 static void auto_rename(DOS_FILE *file)
 {
 DOS_FILE *first,*walk;
-int number;
+unsigned long int number;
 
 if (!file-offset) return;	/* cannot rename FAT32 root dir */
 first = file-parent ? file-parent-first : root;
 number = 0;
 while (1) {
-	sprintf(file-dir_ent.name,FSCK%04d,number);
-	strncpy(file-dir_ent.ext,REN,3);
+	sprintf(file-dir_ent.name, FSCK%04d, number / 1000);
+	sprintf(file-dir_ent.name, %03d, number % 1000);
 	for (walk = first; walk; walk = walk-next)
 	if (walk != file  !strncmp(walk-dir_ent.name,file-dir_ent.
 	  name,MSDOS_NAME)) break;
@@ -321,6 +321,9 @@ static void auto_rename(DOS_FILE *file)
 	return;
 	}
 	number++;
+	if (number  999) {
+		die(Too many files need repair.);
+	}
 }
 die(Can't generate a unique name.);
 }
@@ -450,10 +453,10 @@ static int check_file(DOS_FS *fs,DOS_FIL
 	break;
 	}
 	if (!(file-dir_ent.attr  ATTR_DIR)  CF_LE_L(file-dir_ent.size) =
-	  clusters*fs-cluster_size) {
-	printf(%s\n  File size is %u bytes, cluster chain length is  %lu 
+	  (unsigned long long)clusters*fs-cluster_size) {
+	printf(%s\n  File size is %u bytes, cluster chain length is  %llu 
 	  bytes.\n  Truncating file to %u bytes.\n,path_name(file),
-	  CF_LE_L(file-dir_ent.size),clusters*fs-cluster_size,
+	  CF_LE_L(file-dir_ent.size),(unsigned long long)clusters*fs-cluster_size,
 	  CF_LE_L(file-dir_ent.size));
 	truncate_file(fs,file,clusters);
 	break;
@@ -469,20 +472,20 @@ static int check_file(DOS_FS *fs,DOS_FIL
 		else clusters2++;
 	restart = file-dir_ent.attr  ATTR_DIR;
 	if (!owner-offset) {
-		printf(   Truncating second to %lu bytes because first 
-			is FAT32 root dir.\n, clusters2*fs-cluster_size );
+		printf(   Truncating second to %llu bytes because first 
+			is FAT32 root dir.\n, (unsigned long long)clusters2*fs-cluster_size );
 		do_trunc = 2;
 	}
 	else if (!file-offset) {
-		printf(   Truncating first to %lu bytes because second 
-			is FAT32 root dir.\n, clusters*fs-cluster_size );
+		printf(   Truncating first to %llu bytes because second 
+			is FAT32 root dir.\n, (unsigned long long)clusters*fs-cluster_size );
 		do_trunc = 1;
 	}
 	else if (interactive)
-		printf(1) Truncate first to %lu bytes%s\n
-		  2) Truncate second to %lu bytes\n,clusters*fs-cluster_size,
-		  restart ?  and restart : ,clusters2*fs-cluster_size);
-	else printf(  Truncating second to %lu bytes.\n,clusters2*
+		printf(1) Truncate first to %llu bytes%s\n
+		  2) Truncate second to %llu bytes\n,(unsigned long long)clusters*fs-cluster_size,
+		  restart ?  and restart : ,(unsigned long long)clusters2*fs-cluster_size);
+	else printf(  Truncating second to %llu bytes.\n,(unsigned long long)clusters2*
 		  fs-cluster_size);
 	if (do_trunc != 2 
 		(do_trunc == 1 ||
@@ -494,12 +497,13 @@ static int check_file(DOS_FS *fs,DOS_FIL
 		if (this == curr) {
 			if (prev) set_fat(fs,prev,-1);
 			else MODIFY_START(owner,0,fs);
-			MODIFY(owner,size,CT_LE_L(clusters*fs-cluster_size));
+			MODIFY(owner,size,CT_LE_L((unsigned long long)clusters*fs-cluster_size));
 			if (restart) return 1;
 			while (this  0  this != -1) {
 			set_owner(fs,this,NULL);

Bug#417673: /sbin/fsck.vfat not fixed by binNMU + Sarge _is_ affected

[Andrew Vaughan]

reopen 417673
found 417673 2.11-2
thanks

Hi

Firstly apologies for incorrectly stating that sarge isn't affected 
in my initial report.  I realise that this has caused people to 
waste time focusing on the differences between the sarge and etch 
versions.

On Thursday 05 April 2007 19:32, Florian Weimer wrote:
 I tend to assume that the bug is not exposed on sarge because sarge
 doesn't fsck vfat file systems, right?

Actually sarge will fsck vfat partitions.  But my initial quick reboot
and ls -l test was flawed.  dosfstools wasn't actually installed in my
sarge partition.  

iff dosfstools is installed, fsck.vfat automatically truncates the test 
file.  I have also reproduced this manually (see bottom listing).

I have also tested dosfstools 2.11-2.1+b1.  The binNMU does not fix the
problem.

HTH, and sorry for the incorrect sarge info.

Andrew V.

===
[etch]

$ dpkg -l dosfstools |grep ii
ii  dosfstools 2.11-2.1+b1Utilities to create and check MS-DOS FAT 
filesystems
$ cat /var/log/fsck/checkfs
Log of fsck -C -V -R -A -a
Fri Apr  6 07:23:03 2007

fsck 1.40-WIP (14-Nov-2006)
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /mnt/p4-backup-root] fsck.ext3 -a -C0 /dev/hda6
/dev/hda6: clean, 23207/128520 files, 400468/514048 blocks
[/sbin/fsck.vfat (1) -- /mnt/p4-shared] fsck.vfat -a /dev/hda8
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
/sarge_test
  File size is 4294966784 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
Performing changes.
/dev/hda8: 61 files, 950193/2076388 clusters
fsck died with exit status 1

Fri Apr  6 07:23:04 2007

$ sudo umount /dev/hda8
$ sudo fsck.vfat -av /dev/hda8
dosfsck 2.11 (12 Mar 2005)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID MSDOS5.0
Media byte 0xf8 (hard disk)
   512 bytes per logical sector
 16384 bytes per cluster
32 reserved sectors
First FAT starts at byte 16384 (sector 32)
 2 FATs, 32 bit entries
   8305664 bytes per FAT (= 16222 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 16627712 (sector 32476)
   2076388 data clusters (34019540992 bytes)
63 sectors/track, 255 heads
63 hidden sectors
  66476907 sectors total
/sarge_test
  File size is 0 bytes, cluster chain length is  0 bytes.
  Truncating file to 0 bytes.
Reclaiming unconnected clusters.
Checking free cluster summary.
Free cluster summary wrong (1126195 vs. really 1388339)
  Auto-correcting.
Performing changes.
/dev/hda8: 61 files, 688049/2076388 clusters
$ sudo mount /dev/hda8
$ cp /mnt/p4-games/tmp/MS-Virtual-PC/sarge1/Sarge\ Hard\ Disk.vhd 
/mnt/p4-shared/sarge_test
$ ls -l /mnt/p4-shared/sarge_test
-rwxr-xr-x 1 andrew andrew 4294966784 2007-04-06 07:45 /mnt/p4-shared/sarge_test
$ sudo umount /dev/hda8
$ sudo fsck.vfat -av /dev/hda8
dosfsck 2.11 (12 Mar 2005)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID MSDOS5.0
Media byte 0xf8 (hard disk)
   512 bytes per logical sector
 16384 bytes per cluster
32 reserved sectors
First FAT starts at byte 16384 (sector 32)
 2 FATs, 32 bit entries
   8305664 bytes per FAT (= 16222 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 16627712 (sector 32476)
   2076388 data clusters (34019540992 bytes)
63 sectors/track, 255 heads
63 hidden sectors
  66476907 sectors total
/sarge_test
  File size is 4294966784 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
Reclaiming unconnected clusters.
Checking free cluster summary.
Performing changes.
/dev/hda8: 61 files, 950193/2076388 clusters
$ sudo fsck.vfat -av /dev/hda8
dosfsck 2.11 (12 Mar 2005)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID MSDOS5.0
Media byte 0xf8 (hard disk)
   512 bytes per logical sector
 16384 bytes per cluster
32 reserved sectors
First FAT starts at byte 16384 (sector 32)
 2 FATs, 32 bit entries
   8305664 bytes per FAT (= 16222 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 16627712 (sector 32476)
   2076388 data clusters (34019540992 bytes)
63 sectors/track, 255 heads
63 hidden sectors
  66476907 sectors total
/sarge_test
  File size is 0 bytes, cluster chain length is  0 bytes.
  Truncating file to 0 bytes.
Reclaiming unconnected clusters.
Checking free cluster summary.
Free cluster summary wrong (1126195 vs. really 1388339)
  Auto-correcting.
Performing changes.
/dev/hda8: 61 files, 688049/2076388 clusters
$ sudo mount /dev/hda8
$ ls -l /mnt/p4-shared/sarge_test
-rwxr-xr-x 1 andrew andrew 0 2007-04-06 07:45 /mnt/p4-shared/sarge_test



[sarge]

$ cp 

Bug#417673: /sbin/fsck.vfat: Incorrectly truncates files of 4294966784 bytes length during boot.

[Andrew Vaughan]

Package: dosfstools
Version: 2.11-2.1
Severity: critical
File: /sbin/fsck.vfat
Justification: causes serious data loss

/sbin/fsck.vfat truncates files of 4294966784 bytes length.

The file system on /dev/hda8 was checked immediately before reboot using the 
GUI tool 
in Windows 2000.  As the output /var/log/fsck/checkfs shows /sbin/fsck.vfat 
decided 
during boot that the filesystem was inconsistent and automatically truncated 
the file.  
Note that it hasn't actually released the clusters yet.  The clusters seem to 
be freed 
during when fsck is run at the next boot.

Also shown below is the result of manually copying an equivalant file, and 
manually 
running fsck.vfat is sufficent to reproduce the problem.

A quick test shows that Sarge does not truncate the file during boot.
 
Thanks for your work in Debian

Andrew V.



$ cat /var/log/fsck/checkfs
Log of fsck -C -V -R -A -a
Wed Apr  4 17:23:06 2007

fsck 1.40-WIP (14-Nov-2006)
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /mnt/p4-backup-root] fsck.ext3 -a -C0 /dev/hda6
/dev/hda6: Superblock last mount time is in the future.  FIXED.
/dev/hda6: clean, 19738/128520 files, 313092/514048 blocks
[/sbin/fsck.vfat (1) -- /mnt/p4-shared] fsck.vfat -a /dev/hda8
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
/Sarge Hard Disk.vhd
  File size is 4294966784 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
Performing changes.
/dev/hda8: 63 files, 950195/2076388 clusters
fsck died with exit status 1

Wed Apr  4 17:23:07 2007


$ cp /mnt/p4-games/tmp/MS-Virtual-PC/sarge1/Sarge\ Hard\ Disk.vhd 
/mnt/p4-shared/sarge_test

$ ll /mnt/p4-shared/
total 4194368
[...]
-rwxr-xr-x 1 andrew andrew  0 2007-03-29 18:32 Sarge Hard Disk.vhd
-rwxr-xr-x 1 andrew andrew 4294966784 2007-04-04 17:34 sarge_test

$ sudo umount /dev/hda8

$ sudo fsck.vfat -a /dev/hda8
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
/sarge_test
  File size is 4294966784 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
/Sarge Hard Disk.vhd
  File size is 0 bytes, cluster chain length is  0 bytes.
  Truncating file to 0 bytes.
Free cluster summary wrong (864049 vs. really 1126193)
  Auto-correcting.
Performing changes.
/dev/hda8: 64 files, 950195/2076388 clusters

$ sudo fsck.vfat -a /dev/hda8
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
/sarge_test
  File size is 0 bytes, cluster chain length is  0 bytes.
  Truncating file to 0 bytes.
Free cluster summary wrong (1126193 vs. really 1388337)
  Auto-correcting.
Performing changes.
/dev/hda8: 64 files, 688051/2076388 clusters


-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)

Versions of packages dosfstools depends on:
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries

dosfstools recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#413961: Upgrading udev only updates initrd of running kernel.

[Andrew Vaughan]

Package: udev
Version: 0.105-3
Severity: serious
Justification: Possibility of breakage after udev upgrade, reboot to different 
kernel.

Hi

Upgrading a system with multiple kernels installed I noticed that only the 
running 
kernel has its initrd rebuilt.

Setting up udev (0.105-3) ...
Installing new version of config file /etc/udev/persistent.rules ...
update-initramfs: Generating /boot/initrd.img-2.6.18-4-686

$ ls -ltr /boot |grep init
-rw-r--r-- 1 root root 4374462 2006-11-26 02:58 initrd.img-2.6.17-2-686.bak
-rw-r--r-- 1 root root 4333704 2007-03-04 22:33 initrd.img-2.6.18-4-486
-rw-r--r-- 1 root root 4480292 2007-03-04 22:36 initrd.img-2.6.18-4-686.bak
-rw-r--r-- 1 root root 4480559 2007-03-07 18:25 initrd.img-2.6.18-4-686
 
Both kernels are from debian and are in grub/menu.lst.  (I will report the bug
about failure to clean up the old -2.6.17-2-686.bak image seperately). 

My main concern is that the sequence, install new/alternate kernel, upgrade 
udev, reboot to new/alternate kernel, could result in boot failures or other
problems, if the difference between udev versions is significant.  

If you are satisfied that the above won't cause problems, please feel free to
downgrade.  

Thanks for your work in Debian.
Andrew

-- Package-specific info:
-- /etc/udev/rules.d/:
/etc/udev/rules.d/:
total 4
lrwxrwxrwx 1 root root  20 2005-07-17 16:46 020_permissions.rules - 
../permissions.rules
lrwxrwxrwx 1 root root  22 2006-10-31 12:31 025_logitechmouse.rules - 
../logitechmouse.rules
lrwxrwxrwx 1 root root  13 2005-07-17 16:46 udev.rules - ../udev.rules
lrwxrwxrwx 1 root root  25 2006-10-31 10:07 z20_persistent-input.rules - 
../persistent-input.rules
lrwxrwxrwx 1 root root  19 2006-10-31 10:07 z20_persistent.rules - 
../persistent.rules
-rw-r--r-- 1 root root 301 2006-10-31 10:08 z25_persistent-net.rules
lrwxrwxrwx 1 root root  33 2006-10-31 10:07 z45_persistent-net-generator.rules 
- ../persistent-net-generator.rules
lrwxrwxrwx 1 root root  12 2006-10-31 10:07 z50_run.rules - ../run.rules
lrwxrwxrwx 1 root root  16 2006-10-31 10:07 z55_hotplug.rules - 
../hotplug.rules
lrwxrwxrwx 1 root root  15 2006-10-31 08:07 z60_hdparm.rules - ../hdparm.rules
lrwxrwxrwx 1 root root  29 2006-10-31 10:07 z75_cd-aliases-generator.rules - 
../cd-aliases-generator.rules
lrwxrwxrwx 1 root root  12 2007-02-19 16:26 z99_hal.rules - ../hal.rules

-- /sys/:
/sys/block/hda/dev
/sys/block/hda/hda1/dev
/sys/block/hda/hda2/dev
/sys/block/hda/hda3/dev
/sys/block/hdb/dev
/sys/block/hdb/hdb1/dev
/sys/block/hdb/hdb2/dev
/sys/block/hdc/dev
/sys/block/hdc/hdc1/dev
/sys/block/hdd/dev
/sys/block/hdd/hdd1/dev
/sys/block/ram0/dev
/sys/block/ram10/dev
/sys/block/ram11/dev
/sys/block/ram12/dev
/sys/block/ram13/dev
/sys/block/ram14/dev
/sys/block/ram15/dev
/sys/block/ram1/dev
/sys/block/ram2/dev
/sys/block/ram3/dev
/sys/block/ram4/dev
/sys/block/ram5/dev
/sys/block/ram6/dev
/sys/block/ram7/dev
/sys/block/ram8/dev
/sys/block/ram9/dev
/sys/class/input/input0/event0/dev
/sys/class/input/input1/event1/dev
/sys/class/input/input2/event2/dev
/sys/class/input/mice/dev
/sys/class/misc/agpgart/dev
/sys/class/misc/device-mapper/dev
/sys/class/misc/psaux/dev
/sys/class/misc/snapshot/dev
/sys/class/ppdev/parport0/dev
/sys/class/printer/lp0/dev
/sys/class/usb_device/usbdev1.1/dev
/sys/class/usb_device/usbdev1.2/dev
/sys/class/usb_device/usbdev1.3/dev
/sys/class/usb/lp0/dev
/sys/devices/pci:00/:00:07.2/usb1/1-0:1.0/usbdev1.1_ep81/dev
/sys/devices/pci:00/:00:07.2/usb1/1-1/1-1:1.0/usbdev1.2_ep81/dev
/sys/devices/pci:00/:00:07.2/usb1/1-1/1-1:1.1/usbdev1.2_ep82/dev
/sys/devices/pci:00/:00:07.2/usb1/1-1/usbdev1.2_ep00/dev
/sys/devices/pci:00/:00:07.2/usb1/1-2/1-2:1.0/usbdev1.3_ep01/dev
/sys/devices/pci:00/:00:07.2/usb1/1-2/1-2:1.0/usbdev1.3_ep82/dev
/sys/devices/pci:00/:00:07.2/usb1/1-2/usbdev1.3_ep00/dev
/sys/devices/pci:00/:00:07.2/usb1/usbdev1.1_ep00/dev

-- Kernel configuration:


-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)

Versions of packages udev depends on:
ii  debconf [debconf-2.0]   1.5.11   Debian configuration management sy
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries
ii  libselinux1 1.32-3   SELinux shared libraries
ii  libvolume-id0   0.105-3  libvolume_id shared library
ii  lsb-base3.1-23   Linux Standard Base 3.1 init scrip

udev recommends no packages.

-- debconf information:
  udev/new_kernel_needed: false
  udev/reboot_needed:


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#400129: nvidia-glx: fails to uninstall: dpkg-divert error

[Andrew Vaughan]

severity 400129 normal
tag 400129 + unreproducible
thanks

On Friday 24 November 2006 11:10, Randall Donald wrote:
  $ sudo dpkg --purge nvidia-glx
  (Reading database ... 291706 files and directories currently
  installed.) Removing nvidia-glx ...
  dpkg-divert: rename involves overwriting `/usr/lib/libGL.so' with
different file `/usr/lib/nvidia/libGL.so.xlibmesa', not allowed
  dpkg: error processing nvidia-glx (--purge):
   subprocess post-removal script returned error exit status 2
  Errors were encountered while processing:
   nvidia-glx
 
 
  nvidia-glx does purge if I remove libgl1-mesa-dev first.

 Hmm, I wonder if this has to do with the file created by the init
 script. I'll try to reproduce this tonight.

Hi Randall

I thought that this might also be present in the -legacy packages, since the 
packaging is similar.  When I couldn't reproduce it there, your comments 
about the init script caused me to try to reproduce it again.  I can't 
reproduce this now.  

I'm guessing that the root cause was probably somewhere in the mixture of 
semi-current and obsolete nvidia-* packages on the system at boot time.  

When I booted i had the following packages installed:
  nvidia-glx 1.0.8776-1
  nvidia-kernel-2.6.18-1-486 1.0.8776+2
  nvidia-kernel-legacy-source 1.0.7184-1
  nvidia-kernel-source 1.0.8774-2
  nvidia-kernel-2.6.17-2-486 1.0.8774-2+2.6.17-8   (built locally IIRC) 
  nvidia-kernel-2.6.17-2-686 1.0.8774-2+2.6.17-8   (built locally IIRC)

Before filing the bug report at severity:serious I removed the obsolete 
nvidia packages, upgraded to the latest nvidia-glx, purged nvidia-glx (by 
first removing libgl1-mesa-dev), reinstalled both packages and confirmed 
that I could still reproduce the bug.  However at no stage did I actually 
reboot.  Most (all?) output in the bug report came from the last round of 
tests.

Unless you or someone else can reproduce it, or the above gives you some new 
clue, I suggest closing.  (I should be able to restore a backup from 
earlier this week if anyone really wants to pursue this).

HTH
Andrew V.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#400129: nvidia-glx: fails to uninstall: dpkg-divert error

[Andrew Vaughan]

Package: nvidia-glx
Version: 1.0.8776-2
Severity: serious

Hi

When attempting to remove or purge nvidia-glx.


$ sudo dpkg --purge nvidia-glx
(Reading database ... 291706 files and directories currently installed.)
Removing nvidia-glx ...
dpkg-divert: rename involves overwriting `/usr/lib/libGL.so' with
  different file `/usr/lib/nvidia/libGL.so.xlibmesa', not allowed
dpkg: error processing nvidia-glx (--purge):
 subprocess post-removal script returned error exit status 2
Errors were encountered while processing:
 nvidia-glx

$ /usr/sbin/dpkg-divert --list |grep nvidia
diversion of /usr/lib/libGL.so to /usr/lib/nvidia/libGL.so.xlibmesa by 
nvidia-glx

$ dpkg -l |grep nvidia
pH  nvidia-glx  1.0.8776-2 NVIDIA binary XFree86 4.
ii  nvidia-kernel-2.6.18-1-486  1.0.8776+2 NVIDIA binary kernel mod
ii  nvidia-kernel-common20051028+1 NVIDIA binary kernel mod
ii  nvidia-settings 1.0+20060516-3 Tool of configuring the

$ dpkg -l | grep mesa
ii  libgl1-mesa-dev 6.5.1-0.4  A free implementation of
ii  libgl1-mesa-dri 6.5.1-0.4  A free implementation of
ii  libgl1-mesa-glx 6.5.1-0.4  A free implementation of
ii  libglu1-mesa6.5.1-0.4  The OpenGL utility libra
ii  libglu1-mesa-dev6.5.1-0.4  The OpenGL utility libra
ii  mesa-common-dev 6.5.1-0.4  Developer documentation
ii  mesa-utils  6.3.2-2.1  Miscellaneous Mesa GL ut
ii  xlibmesa-gl 7.1.0-7transitional package for
ii  xlibmesa-gl-dev 7.1.0-7transitional package for


nvidia-glx does purge if I remove libgl1-mesa-dev first.

Thanks for your work in Debian.

Andrew V.


-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-486
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)

Versions of packages nvidia-glx depends on:
ii  libc62.3.6.ds1-8 GNU C Library: Shared libraries
ii  libx11-6 2:1.0.3-3   X11 client-side library
ii  libxext6 1:1.0.1-2   X11 miscellaneous extension librar
ii  nvidia-kernel-1.0.8776   1.0.8776+2  NVIDIA binary kernel module for Li
ii  x11-common   1:7.1.0-7   X Window System (X.Org) infrastruc

nvidia-glx recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#363324: (no subject)

[Andrew Vaughan]

Hi Randall, Hi Phillipe

Philippe Cloutier wrote
 I'm not sure what you mean by since there won't be any modules in
 testing, but I hope the following answers your question. There are two
 things that would make me close this report: 1) linux-2.6 is updated,
 and both nvidia-graphics-modules-i386 and nvidia-graphics-drivers are
 still ready to be updated simultaneously 2) nvidia-graphics-drivers is
 forced in testing.


Both nvidia-graphics-drivers and nvidia-graphics-drivers-legacy are 
currently free of RC bugs, and old enough.

Is there any reason not ask on -release for them to be pushed into testing?

Andrew V.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#383860: x86 binary packages built from pre-release source package

[Andrew Vaughan]

Package: nvidia-graphics-drivers-legacy
Version: 1.0.7182-1
Severity: serious

Hi Donald

The x86 binary packages aren't built from the uploaded source package.

They appear to have been built from a pre-release version of the package 
that was available for testing before the final version was uploaded. 

This can be easily seen by comparing the changelog of in the source and 
binary packages.

The AMD binary packages don't appear to be affected.

Cheers
Andrew V.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-486
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#345891: needs update for new archive key

[Andrew Vaughan]

Hi

Further things to consider.  Apologies if I these have already been handled.

1. Dec 2006 Etch releases.  Jill downloads and burns etch install cd.
   Jan 2007, old archive key expires, new archive key issued.
   Jan 2008, old archive key expires, new archive key issued.
   Mar 2008, Jill tries to install from the cd created in Dec 2006.  

   Will that work?

   Will that work if all debian-archive-keys were revoked/replaced in
   mid 2007?

2. security.d.o will (presumably) also be signed. 
   Will that be using the same key?

   Using separate keys might make updating after a key compromise simpler.
   (You could use the not-compromised key to sign both package lists
   temporarily).

Andrew

PS I also prefer debian-archive-keyring/debian-archive-keys.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]