Bug#761057: missing license in debian/copyright
if relevant) I propose both embedded and display licensing for the man pages following what is done for docbook using that slightly modified BSD documentation license (subject to Rafael's agreement as author of those man pages) and also for the doxygen-generated files. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606340: This bug not completely fixed in 2:2.13.0-5
To follow up on my previous report, I have now had success with xserver-xorg-video-intel/2:2.13.0-5 on the 32-bit 945GME system. To recount the sequence of events, I originally encountered the error with the 2:2.13.0-5 version when trying to use apt-get install xserver-xorg-video-intel on a working Debian testing install without a subsequent reboot. I then followed advice in this bug thread to downgrade to 2:2.13.0-2. I couldn't get that to work, however, so as a last resort I tried a reboot, and it worked. That required reboot for 2:2.13.0-2 has been niggling at me ever since so today I tried 2:2.13.0-5 again, and it worked. I then tried a reboot, and 2:2.13.0-5 continued to work. So my working hypothesis to explain what I encountered is rebooting is sometimes necessary to get recent versions of xserver-xorg-video-intel to work. Anyhow, if any Debian user encounters the (EE) No devices detected error for xserver-xorg-video-intel, I would highly recommend trying a reboot to see if that solves the issue. To replicate the issue I encountered, I suggest following exactly the same sequence of events that I did which is (1) to do an expert minimal install of Debian without X (i.e., drop all tasks from tasksel), and (2) for that working minimal install, try installing xserver-xorg-video-intel without subsequent rebooting. If the (EE) No devices detected error is encountered (like happened for me) and further rebooting solves it, then that would confirm the hypothesis. Assuming the hypothesis is correct, one solution to the issue which I think would justify closing this bug report would be to warn users about the reboot requirement with an install warning message for xserver-xorg-video-intel. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606340: This bug not completely fixed in 2:2.13.0-5
I confirm the issue still exists for xserver-xorg-video-intel/2:2.13.0-5 for at least one Intel-based system (32-bit 945GME) but also does not exist for another Intel-based system (64-bit g33). Both systems had the same monitor (ASUS VH198T). The 945GME was connected with DVI while the g33 was connected with VGA. In both cases the other alternative connection (VGA for the 945GME or DVI for the g33) is not available. For the 945GME the tail of the server log was (II) Primary Device is: PCI 00@00:02:0 (EE) No devices detected. Fatal server error: no screens found If I downgrade the 945GME system to 2:2.13.0-2, that error message disappears, and X on that system works normally. More hardware details for the 945GME that fails with 2:2.13.0-5 but which succeeds with 2:2.13.0-2: Linux meadowlark 2.6.32-5-686 #1 SMP Wed Jan 12 04:01:41 UTC 2011 i686 GNU/Linux 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) (This is the 32-bit ASUS Eee box [b202 version] with dvi connection to a ASUS VH198T LCD monitor. The chipset for this box is identified everywhere but the Linux space as the 945GSE chipset). More hardware details for the g33 that succeeds with the 2:2.13.0-5 version of the driver: Linux raven 2.6.32-5-amd64 #1 SMP Fri Dec 10 15:35:08 UTC 2010 x86_64 GNU/Linux 00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 02) 00:02.1 Display controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 02) (This is a 64-bit generic white box desktop PC built about 3 years ago with ASUS P5K-V motherboard with VGA connection to a ASUS VH198T LCD monitor.) Both systems are running Debian testing. When I first got the failure on the 945GME (during the initial Debian testing install for the system), I compared the log in detail with the g33 log. The logs were essentially identical until the above error message occurred for the 945GME. There were no obvious error messages with similar time stamp in any other file in /var/log. So it seemed pretty hopeless until I discovered the workaround suggested in this thread to downgrade (from 2:2.13.0-5 in my case) to 2:2.13.0-2. For what it is worth, the guy who sold me this used 945GME never had issues with it on Ubuntu, but I don't know what version of Ubuntu was the last he tried, or whether this issue (whatever it is) was in his future if he had hung on to the box and done further Ubuntu upgrades as time progressed. I would be happy to send any further data from any of the 945GME (using 2:2.13.0-2 or 2:2.13.0-5) or g33 (using 2:2.13.0-5) systems to help track down what the problem is. I am very happy that the workaround of downgrading to 2:2.13.0-2 makes it possible to use the 945GME system, but obviously that workaround is not a permanent solution. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588983: python-feedvalidator: errors out with ImportError: No module named ....
Package: python-feedvalidator
Version: 0~svn1022-1
Severity: grave
Tags: l10n
Justification: renders package unusable
The issue is that with Debian squeeze /etc/default/locale now defines
LANGUAGE. On my system that file looks like this
# File generated by update-locale
#LANG=en_CA.UTF-8
LANGUAGE=en_CA:en
The result is that LANGUAGE string is supplied as an environment
variable to all users which kills feedvalidator completely.
Here is the locale and the associated typical error for one of the
users on this system:
barb...@raven locale |grep LANG
LANG=en_CA.UTF-8
LANGUAGE=en_CA:en
barb...@raven feedvalidator highlights.atom
Validating file:///home/barbara/linuxlinks/loll/highlights.atom
Traceback (most recent call last):
File /usr/bin/feedvalidator, line 101, in module
main()
File /usr/bin/feedvalidator, line 97, in main
run()
File /usr/bin/feedvalidator, line 47, in run
from feedvalidator.formatter.text_plain import Formatter
File /usr/lib/pymodules/python2.6/feedvalidator/formatter/text_plain.py,
line 9, in module
from base import BaseFormatter
File /usr/lib/pymodules/python2.6/feedvalidator/formatter/base.py, line 12,
in module
lang = __import__('feedvalidator.i18n.%s' % LANGUAGE, globals(), locals(),
LANGUAGE)
ImportError: No module named en_CA:en
A quick look at the package list for python-feedvalidator indicates
the only i18n module there is called en.py. Indeed a workaround for
this issue is to set the LANGUAGE environment variable as follows:
LANGUAGE=en
before running feedvalidator. But unless people figure that out,
this bug means that nobody can use feedvalidator which is why I
have classified this as a grave error.
A quick look at en.py indicates it contains english error messages for
feedvalidator. If there is no prospect of translating those to
other languages, then I suggest simply importing that module
directly in /usr/lib/pymodules/python2.6/feedvalidator/formatter/base.py
without fooling around with LANGUAGE at all. Otherwise, you could do
something more complicated like use only the first two characters
of LANGUAGE to identify the language and store those in LA and
use that variable instead, but then if it fails to import
LA.py, fall back to en.py.
But without one of those fixes, python-feedvalidator will be broken
for everybody who is not aware of the LANGUAGE=en workaround.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages python-feedvalidator depends on:
ii python 2.6.5-5 An interactive high-level object-o
ii python-libxml2 2.7.7.dfsg-4 Python bindings for the GNOME XML
ii python-rdflib 2.4.2-1+b1 RDF library containing an RDF trip
ii python-support 1.0.9automated rebuilding support for P
python-feedvalidator recommends no packages.
python-feedvalidator suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#311357: Upgrade of 386 version of the 2.6.8 kernel breaks via-rhine
On 2005-06-07 17:48+0900 Horms wrote: On Sun, Jun 05, 2005 at 01:11:54PM +0200, Norbert Tretkowski wrote: severity 311357 grave thanks * Alan W. Irwin wrote: This is a confirmation of the bad problem with the via-rhine module for the latest version of the 386 version of the 2.6.8 kernel. Sounds like a RC bug, so I'm setting it's severity to grave. I upgraded today from kernel-image-2.6.8.2-386 version 2.6.8-13 to 2.6.8-16, and my network card (D-link 10/100 DFE-530TX) that is controlled by the via-rhine module immediately quit working Too bad this bug didn't get realized when -16 was in unstable... looks like it's too late to fix this for 3.1r0. True, there was some late minute package shiffling which meant that -16 ended up going straight into sarge. Unfortunately now we have this bug. A similar thing seems to have happened with 2.4.27 and some neftilter symbols. It partly my fault (in the sense that I uploaded the packages) and partly a process issue. I do appologise for any inconvenience and I'll try and get updates together over the next few days. But we have clearly missed the boat for 3.1r0. Hi Horms: Thanks for acknowledging the via-rhine problem that has gotten into 3.1r0. For Debian sarge users it sounds like you have plans to fix version 2.6.8-16 which is excellent. But until that happens, and for on-going Debian testing users like me what kernel 2.6 solution do you recommend for all those who require via-rhine for their networking? For example, do you (or anybody else paying attention to this bug thread) know whether the via-rhine problems also occur for kernel-image-2.6.11 (currently in unstable)? Alan __ Alan W. Irwin email: [EMAIL PROTECTED] phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
