Bug#1066807: nvtop now eligible to be in main?

[Ken Harris]

Package: nvtop
Severity: wishlist

Dear Maintainer,

The program nvtop (currently version 3.0.1-1 in bookworm=stable) is in
"contrib" rather than "main", despite being licensed under the GNU GPL.

The copyright file explains that this is because "it is only useful in
combination with the proprietary NVIDIA drivers in non-free".

This was true in version 1.  Since then, nvtop version 2 added support for AMD
GPUs (and retconned the "nv" to mean "Neat Videocard"), and version 3 added
support for Intel GPUs, so I believe it's now perfectly usable with only free
software.

The Policy Manual says packages in main "must not require or recommend a
package outside of main for compilation or execution".  nvtop depends on only 4
packages (libc6, libncursesw6, libsystemd0, libtinfo6), all of which are in
"main", and it lists no "recommends/suggests/enhances" packages.  All of the
Build-Depends packages appear to be in main, as well.

Also, the Debian package description is still "Interactive NVIDIA GPU process
monitor", while the upstream description is now "GPU & Accelerator process
monitoring for AMD, Apple, Huawei, Intel, NVIDIA and Qualcomm".

thanks,


-- System Information:
Debian Release: 12.4
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-15-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1032775: ola: Bootstrap is a dependency of OLA, but bootstrap.min.css isn't found by OLA

[Ken Harris]

Package: ola
Version: 0.10.9.nojsmin-1
Severity: normal

Dear Maintainer,

Debian OLA 0.10.9 now includes the correct version of Angular, but the
(new) UI still isn't usable, as "bootstrap.min.css" is a 404.

Bootstrap (libjs-bootstrap) is a Debian package dependency of OLA, but
there doesn't seem to be any mechanism for bootstrap.min.css to end up
in a place where OLA (the web server) knows how to find it.  When I
visit the URL , I see all text in the
default browser font, down the left side of the window, with the
contents of all possible dialog boxes appended below that.

Running these two commands fixes the problem:

sudo mkdir /usr/share/olad/www/new/libs/bootstrap/css/
sudo cp /usr/share/javascript/bootstrap/css/bootstrap.min.css 
/usr/share/olad/www/new/libs/bootstrap/css/

I'm not a Debian maintainer so I don't know what the proper fix is.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-3-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ola depends on:
ii  adduser3.130
ii  libc6  2.36-8
ii  libgcc-s1  12.2.0-14
ii  libjs-angularjs1.8.2-2
ii  libjs-bootstrap3.4.1+dfsg-3
ii  libjs-jquery   3.6.1+dfsg+~3.5.14-1
ii  libncurses66.4-2
ii  libola10.10.9.nojsmin-1
ii  libprotobuf32  3.21.12-1+b2
ii  libstdc++6 12.2.0-14
ii  libtinfo6  6.4-2
ii  lsb-base   11.5
ii  sysvinit-utils [lsb-base]  3.06-2

ola recommends no packages.

Versions of packages ola suggests:
ii  bash-completion  1:2.11-6

-- no debconf information

Bug#1016447: reportbug: olad includes Angular 1.3.14, but Debian replaces this with a dependency on 1.8.2 (which isn't compatible)

[Ken Harris]

Package: ola
Version: 0.10.8.nojsmin-2
Severity: normal

Dear Maintainer,

When visiting the "New" local OLA server at
, clicking on the page for any Universe
only shows the first tab.  Clicking any other tab (Faders, Keypad,
etc) sends you back to the home page.

OLA includes a copy of Angular 1.3.14 at ola/olad/www/new/libs/, but
Debian's package removes this and replaces it with a dependency on
package "libjs-angularjs", which is currently at version 1.8.2, and
incompatible with OLA's Angular 1.3.14 interface.

Replacing the "angular.min.js" and "angular-route.min.js" symlinks in
this package with the original files (from ola's upstream repo) fixes
the problem completely.



-- System Information:
Debian Release: 11.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-14-amd64 (SMP w/12 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ola depends on:
ii  adduser  3.118
ii  libc62.33-7
ii  libgcc-s110.2.1-6
ii  libjs-angularjs  1.8.2-2
ii  libjs-bootstrap  3.4.1+dfsg-2
ii  libjs-jquery 3.5.1+dfsg+~3.5.5-7
ii  libncurses6  6.2+20201114-2
ii  libola1  0.10.8.nojsmin-2
ii  libprotobuf233.12.4-1
ii  libstdc++6   10.2.1-6
ii  libtinfo66.2+20201114-2
ii  lsb-base 11.1.0

ola recommends no packages.

Versions of packages ola suggests:
ii  bash-completion  1:2.11-2

-- no debconf information

Bug#474207: Examples don't compile

[Ken Harris]

Milan,

 Actually cl-mcclim does depend on cl-flexichain, but newer version is
 required.  I'll fix the dependency.

Great.

 This is a warning about use of a deprecated SBCL function in cl-clx-sbcl
 package.  It's (still) harmless, just select [ACCEPT] and the
 compilation should proceed fine.

Oh, OK.  If this can't be fixed, there should probably be a note in
the Debian documentation.

I got it to work!  Huzzah.  Or at least, it started now.  (I guess all
the signals and errors I see when playing with it should be filed as
new bugs.)

Thanks!


- Ken



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

Bug#474207: Examples don't compile

[Ken Harris]

Hi Milan,

 [Sorry for the late answer, I suffered from the I'll look at it in the
 next few days syndrome.]

No problem.

 I can't reproduce *this* bug with cl-mcclim 0.9.6 (just uploaded to the
 archive) and sbcl 1.0.17.  Would you please check whether cl-mcclim
 0.9.6 works better for you?

I upgraded just now and tried again.

First, it failed because cl-flexichain wasn't installed.  Apparently
it's used by cl-mcclim but the Debian package isn't a dependency.

After I installed that, and tried compiling the examples, it compiled
for a pretty long time, but eventually still gave an error.  The last
compiling message was:


; compiling (DEFUN FAST-COPY-PIXARRAY ...)

; /var/cache/common-lisp-controller/1000/sbcl/clx/dependent.fasl written
; compilation finished in 0:00:01

debugger invoked on a ASDF:COMPILE-WARNED in thread #THREAD initial
thread {1002705A51}:
  erred while invoking #COMPILE-OP NIL {1003FEA781} on
  #CLX-SOURCE-FILE dependent {1003CD2BA1}

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [TRY-RECOMPILING] Try recompiling dependent
  1: [RETRY  ] Retry performing #ASDF:COMPILE-OP NIL {1003FEA781} on
   #CLX-SYSTEM::CLX-SOURCE-FILE dependent {1003CD2BA1}.
  2: [ACCEPT ] Continue, treating #ASDF:COMPILE-OP NIL {1003FEA781}
   on
   #CLX-SYSTEM::CLX-SOURCE-FILE dependent {1003CD2BA1}
   as having been successful.
  3: [ABORT  ] Exit debugger, returning to top level.

((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE))
 #unavailable argument
 #unavailable argument
 #ASDF:COMPILE-OP NIL {1003FEA781}
 #CLX-SYSTEM::CLX-SOURCE-FILE dependent {1003CD2BA1})
0]


I haven't really done any sbcl/mcclim debugging to speak of, so let me
know if there's anything else I can provide to help figure this out.


- Ken



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

Bug#474207: Examples don't compile

[Ken Harris]

Package: cl-mcclim-examples
Version: 0.9.5.dfsg.1-1

The README.debian says to run (asdf:oos 'asdf:load-op :clim-examples).
 I started SBCL, ran this line, and it compiled a bunch of things, and
then I got:

...
... (many compiling ... lines removed)
...
; compiling (DEFUN MAKE-CONDITION-VARIABLE ...)
; compiling (DEFUN CONDITION-WAIT ...)
; compiling (DEFUN CONDITION-NOTIFY ...)

; /var/cache/common-lisp-controller/1000/sbcl/mcclim/Lisp-Dep/mp-sbcl.fasl
written
; compilation finished in 0:00:00

debugger invoked on a TYPE-ERROR in thread #THREAD initial thread
{10027EBA51}:
  The value :LOCKED is not of type (OR NULL SB-THREAD:THREAD).

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY ] Retry performing #ASDF:LOAD-OP NIL {1002DCD6C1} on
  #ASDF:CL-SOURCE-FILE mp-sbcl {10029A4581}.
  1: [ACCEPT] Continue, treating #ASDF:LOAD-OP NIL {1002DCD6C1} on
  #ASDF:CL-SOURCE-FILE mp-sbcl {10029A4581} as having been
  successful.
  2: [ABORT ] Exit debugger, returning to top level.

(SB-THREAD:GET-MUTEX
 #unavailable argument
 #unavailable argument
 #unavailable argument)
0]

Kernel:
Linux monolith 2.6.24-1-amd64 #1 SMP Thu Mar 27 16:52:38 UTC 2008
x86_64 GNU/Linux

Lisp:
ii  sbcl 1:1.0.15.0-1 A Common Lisp compiler and
development system


- Ken



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

Bug#471598: SBCL can't find CLC package

[Ken Harris]

Package: sbcl
Version: 1:1.0.15.0-1


SBCL doesn't have the CLC package available (shouldn't it,
automatically?), but I suspect this is a symptom of bigger problems.


The most visible place I see this is SLIME.  If I try to start SLIME
(with inferior-lisp-program = sbcl), I get:


(progn (load /usr/share/common-lisp/source/slime/swank-loader.lisp
:verbose t) (funcall (read-from-string swank-loader:init)) (funcall
(read-from-string swank:start-server) /tmp/slime.3
:coding-system iso-latin-1-unix))

This is SBCL 1.0.15.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at http://www.sbcl.org/.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
*
; loading #P/usr/share/common-lisp/source/slime/swank-loader.lisp

debugger invoked on a SB-INT:SIMPLE-READER-PACKAGE-ERROR in thread
#THREAD initial thread {10024C4A91}:
  SB-INT:SIMPLE-READER-PACKAGE-ERROR at 5087 (line 129, column 45) on
#SB-SYS:FD-STREAM for file
/usr/share/common-lisp/source/slime/swank-loader.lisp {10024CF721}:
package CLC not found

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

(SB-IMPL::READ-TOKEN
 #SB-SYS:FD-STREAM for file
/usr/share/common-lisp/source/slime/swank-loader.lisp {10024CF721}
 #\c)
0]


For comparison, if I set inferior-lisp-program to clisp, it starts
just fine.  If I start up CLISP, the CLC package is available right
away.

My kernel is Linux xyz 2.6.24-1-amd64 #1 SMP Mon Feb 11 13:47:43 UTC
2008 x86_64 GNU/Linux

Versions of other Lisp-related packages:
ii  cl-swank   1:20080223-2   Superior LISP Interaction Mode for Emacs (Li
ii  common-lisp-co 6.14   Common Lisp source and compiler manager
ii  slime  1:20080223-2   Superior LISP Interaction Mode for Emacs


The weird install seen in bug #471147 occurred here, too.  It almost
seems like SBCL isn't getting installed at all, and it's just dumb
luck that anything at all works -- but I don't understand Lisp on
Debian well enough to even know what to look for.



- Ken



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

Bug#471598: More info

[Ken Harris]

My libc(s):

ii  libc62.7-9
GNU C Library: Shared libraries
ii  libc6-i386   2.7-9
GNU C Library: 32bit shared libraries for AM

OK, it looks like all three of the SBCL is horribly borken bugs
(471598, 471147, 469015) are caused by a longstanding kernel bug
exposed by gcc-4.3, which libc6 started using as of 2.7-9.
(Coincidentally, this was front page news on slashdot today.)

Discussion of the issue:
http://lhealy.livejournal.com/9795.html

Root bug in Debian (I think):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469058

It looks like 2.6.25 will fix this, and we might have a backport to
2.6.24 even (though it's a critical bug and the patch was posted
almost 2 weeks ago and there's been no apparent action since).


- Ken



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

Bug#430493: python-opengl: PyOpenGL for Python2.5

[Ken Harris]

Package: python-opengl
Version: 2.0.1.09.dfsg.1-0.3
Severity: normal

The Debian python-opengl package is for for Python =2.4, 2.5.
I'd like it available for Python 2.5, as well.  This should be a
really easy upgrade: I've used PyOpenGL with Python2.5 (on other
platforms), and it works great.  The only change needed should be
the version dependency.  (Though I'm not sure how exactly it works:
it already says XS-Python-Version: all, but seems to build into
a .deb with 2.5.)

(Why are so many Debian Python packages 2.5?  I thought the new
Python policy made it ridiculously easy to make one package that
worked with all recent Python versions.)

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.21-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages python-opengl depends on:
ii  freeglut3 [libglut3]  2.4.0-5.1  OpenGL Utility Toolkit
ii  libgl1-mesa-glx [libgl1]  6.5.2-5A free implementation of the OpenG
ii  libglu1-mesa [libglu1]6.5.2-5The OpenGL utility library (GLU)
ii  libglut3  3.7-25 the OpenGL Utility Toolkit
ii  python2.4.4-6An interactive high-level object-o
ii  python-central0.5.14 register and build utility for Pyt
ii  python-numeric24.2-8 Numerical (matrix-oriented) Mathem
ii  ttf-bitstream-vera1.10-7 The Bitstream Vera family of free 

python-opengl recommends no packages.

-- no debconf information


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

Bug#426365: python-avahi: Should require python-dbus

[Ken Harris]

Package: python-avahi
Version: 0.6.19-2
Severity: normal

If I start Python and import avahi, I get:

$ python
Python 2.4.4 (#2, Apr 25 2007, 22:41:41) 
[GCC 4.1.3 20070423 (prerelease) (Debian 4.1.2-4)] on linux2
Type help, copyright, credits or license for more information.
 import avahi
Traceback (most recent call last):
  File stdin, line 1, in ?
  File /var/lib/python-support/python2.4/avahi/__init__.py, line 22, 
in ?
import dbus
ImportError: No module named dbus
 

Apparently it needs python-dbus.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.21-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages python-avahi depends on:
ii  libavahi-common-data  0.6.19-2   Avahi common data files
ii  python2.4.4-6An interactive high-level object-o
ii  python-gdbm   2.4.4-1GNU dbm database support for Pytho
ii  python-glade2 2.10.4-2   GTK+ bindings: Glade support
ii  python-support0.6.4  automated rebuilding support for p

python-avahi recommends no packages.

-- no debconf information


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

Bug#379350: Clisp can't find libraries like CL-PPCRE

[Ken Harris]

Package: clisp
Version: 2.38-8

In SBCL, I can say (require :cl-ppcre) and it works.  In CLISP,
however, it says LOAD: A file with name CL-PPCRE does not exist.

CL-PPCRE's webpage says it works under both SBCL and CLISP.  Nothing I
can find has led me to believe that there's any reason Debian's CLISP
wouldn't work with Debian's CL-PPCRE.

Other Lisp libraries I've tried, like (require :aserve), also work in
SBCL but not CLISP.  (Portable Aserve, upstream, also claims to work
with CLISP.)

Maybe I'm missing something crucial about how to load libraries in
CLISP, but this seems like the common case that one can expect to
work.  I saw nothing in the CLISP or CL-PPCRE docs that look relevant,
either in the upstream docs or the Debian package docs.

Thanks!


- Ken


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

Bug#341525: Nope

[Ken Harris]

With the latest slune (1.0.11-1), I still get the same crash.


- Ken

Bug#354757: Gazpacho for Python 2.4

[Ken Harris]

Package: gazpacho
Version: 0.6.5-1

Right now, gazpacho on Debian requires Python 2.3.  But it would be
great if we could use Gazpacho for Python2.4 programs!  This is a
request to package gazpacho in Debian for python2.4.

Not only does Python 2.4 have some nice language features, but a lot
of other libraries are appearing in Debian (and elsewhere) that are
for Python 2.4 only.  For example, the latest DBUS bindings only work
with Python 2.4 (http://bugs.debian.org/346491).

Ubuntu has a package of this
(http://packages.ubuntu.com/dapper/devel/gazpacho); I don't
know how compatible, if at all, Ubuntu's packages are with Debian.

Thanks!


- Ken

Bug#353597: PyOpenGL for Python2.4

[Ken Harris]

Package: python-opengl
Version: 2.0.1.09-1.1

The python-opengl virtual package is currently only filled by
python2.3-opengl.  It would be great if there was a version of OpenGL
in Debian for Python 2.4.

Not only does Python 2.4 have some nice language features, but a lot
of other libraries are appearing in Debian (and elsewhere) that are
for Python 2.4 only.  For example, the latest DBUS bindings only work
with Python 2.4 (http://bugs.debian.org/346491).

Ubuntu has a package of this
(http://packages.ubuntu.com/hoary/python/python2.4-opengl); I don't
know how compatible, if at all, Ubuntu's packages are with Debian.

Thanks!


- Ken

Bug#275759: Not fixed

[Ken Harris]

I have ttf-freefont 20051102-2 installed now -- one version newer than
the version that claims to fix this bug -- and in gucharmap, the
FreeSerif arrows are definitely pointing in the wrong directions
still.


- Ken

Bug#337293: Solution?

[Ken Harris]

I took a look at this again, and I got it to work!  (Writing this from
2.6.14-2-k7 now.)

The problem for me was hinted at above, in the line You can do 'mount
-o bind / /mnt; ls /mnt/dev' to see what's there.  /dev/.static/dev/
may contain an alias of this -- apparently the important word in this
sentence is may.  I did the simpler one (ls /dev/.static/dev/), and
it looked OK, so I stopped looking at that; when I tried the other
one, /mnt/dev/ was empty.  I created 'console' and 'null' in there
with mknod, and rebooted, and it came up just fine.

Another page I found that discusses this, and exactly what you need:
http://www.disaggregate.com/blog/technicalweblog/archives/12.html

Does this help anybody/everybody else?


- Ken

Bug#341525: Slune crashes if sound enabled

[Ken Harris]

Package: slune
Version: 1.0.10-1
Severity: normal

Slune starts fine, but if I set Hardware Options - Music to on,
when I click back, it dies, printing this to the terminal window I
started it from:

* Slune * Using sound system SDL_mixer
Traceback (most recent call last):
  File /usr/games/slune, line 152, in ?
slune.gui_gl.MainScreen()
  File /usr/share/games/slune/gui_gl.py, line 590, in MainScreen
action = gui_idler.idle()
  File idler.pyx, line 133, in _soya.Idler.idle
  File /usr/share/games/slune/gui_gl.py, line 530, in begin_round
for event in soya.process_event(): current_menu.process_event(event)
  File /usr/lib/python2.3/site-packages/soya/widget.py, line 675, in
process_event
self.choices[self.selected].mouse_click(event[1])
  File /usr/lib/python2.3/site-packages/soya/widget.py, line 592, in
mouse_click
if self.action: self.action()
  File /usr/share/games/slune/gui_gl.py, line 286, in back_h_option
import slune.sound; reload(slune.sound)
  File /usr/share/games/slune/sound.py, line 40, in ?
init  = sound4soya.init
AttributeError: 'module' object has no attribute 'init'
* Soya3D * Quit...
Vertex3f: 1

Bug#337293: Not RAID/SATA

[Ken Harris]

It isn't RAID or SATA.  I have this problem, and my boot hardware is
about as common and bare-bones as one could expect: IDE, one partition
(and one swap partition), average-ish x86 motherboard and processor
(A7M266 with an Athlon).

The only thing remotely non-standard here is the XFS root partition. 
(You guys running weird root filesystems, too?)


- Ken

Bug#337293: More clues?

[Ken Harris]

Hi.  I got exactly the same error message when trying to boot
linux-image-2.6.14-1-k7, and have a somewhat different system.

I installed it with apt-get under 2.6.12 (previous
linux-image-2.6-k7).  The installation seems to go fine:

--8--
Setting up linux-image-2.6.14-1-k7 (2.6.14-2) ...
Using /usr/sbin/mkinitrd.yaird to build the ramdisk.
Full list of probed ramdisk generating tools : /usr/sbin/mkinitrd.yaird.
Searching for GRUB installation directory ... found: /boot/grub .
Testing for an existing GRUB menu.list file... found: /boot/grub/menu.lst .
Searching for splash image... none found, skipping...
Found kernel: /boot/vmlinuz-2.6.14-1-k7
Found kernel: /boot/vmlinuz-2.6.12-1-k7
Found kernel: /boot/vmlinuz-2.6.9
Found kernel: /boot/memtest86.bin
Updating /boot/grub/menu.lst ... done


Setting up linux-image-2.6-k7 (2.6.14-2) ...
--8--

I do have a /dev/.static/dev/console device file.

My fstab looks like this (non-comment lines):

--8--
/dev/hda2   /   xfs defaults0   1
/dev/hda1   noneswapdefaults0   2
proc/proc   procdefaults0   0
/dev/cdroms/cdrom0  /media/cdrom0   hfsplus,udf,iso9660
defaults,ro,user,noauto 0   0
/dev/cdroms/cdrom1  /media/cdrom1   hfsplus,udf,iso9660
defaults,ro,user,noauto 0   0
--8--

And I have no aic7xxx SCSI controller, so that's probably not it.  :-)
 (I have a SCSI card, but not that one, and I have no disks on it
currently -- my only disk right now is plain old IDE.)

I'll try some of the other things you suggested later (when I reboot).
 I can see about dumping some relevant files in a public place, too.


- Ken

Bug#255825: Status?

[Ken Harris]

Hi everybody,

Upstream resolved this as not a bug 10 months ago.  They say it's
something that should be done by the sysadmin, which to me means the
distro-specific installer.

All of my PyGTK programs (like straw, meld, and gazpacho) have been
broken for ages because of this.

From comment 2 of the upstream bug, I've found that you can run these
programs by running them from a terminal window like:
PYTHONPATH=/usr/lib/python2.3/site-packages/ meld.  Gustavo Carneiro
(upstream PyGTK guy) says that setting PYTHONPATH globally is the
correct fix.  (I don't know how to do that for a Debian package, else
I'd contribute a patch.)

Then again, I think I must be missing something.  Presumably if so many
packages were so broken for so long, people would be screaming bloody
murder.  So maybe apt has managed to get my system into a weird state
where PyGTK doesn't work.

But regardless, a Debian important bug that was forwarded upstream and
marked not a bug there should be resolved downstream *somehow*.  :-)


The only other similar bug report I could find is for straw:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=170873archive=yes --
says it's a python-gnome2 problem, and that programs should be able to
run without PYTHONPATH set.  I didn't see a relevant python-gnome2 bug
report, though.


What's the status of this bug?


Thanks,

- Ken



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

Bug#255825: Status?

[Ken Harris]

Hi,

Thanks for responding so promptly!

(I'm just guessing which email addresses I'm supposed to be sending this
to.  Let me know if I guessed wrong.)


Since I knew to look in /usr/local, I strace'd meld for any file
accesses in there.

It looks like part of PyGtkGLExt was causing my problems.  Even after it
was uninstalled, it left empty folders
in /usr/local/lib/python2.3/site-packages/gtk-2.0/.  Once I deleted
them, meld (and the others) works fine.

(I guess no more OpenGL from PyGTK for me.  Oh well.)

So go ahead and close this, because it isn't technically Debian's fault.
(Though it is a really strange-looking bug.  I wonder if it wouldn't be
possible to print a more informative error message.)

Thanks for the pointers, though!  You made my day.  :-)


- Ken




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

Bug#304233: Rhythmbox MP3s

[Ken Harris]

Hi,

I've been seeing this, too.  It's only in Rhythmbox that MP3s don't
play: Totem (with either gstreamer or xine) works, and from the Terminal
(using gstreamer) works.  Very strange...

FWIW, it's only MP3 that's broken; FLAC and Ogg Vorbis files still play
fine.

cheers,


- Ken



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

Bug#299536: Backslash escape codes not parsed by Syck

[Ken Harris]

Package: python-syck
Version: 0.42-7

Backslash escapes, like \0 aren't parsed correctly: it's parsed as the
2-char string r'\0', when it should be the 1-char string '\0' (=chr(0)).

If you escape it as \x00 it does work, however.  It's just the \0 escape
that isn't working.

Possibly other backslash-escaped escape codes aren't done correctly,
either...

Demonstration:
 import syck
 syck.load(r'- \0')
['\\0']

Expected result: ['\x00'] ('\x00' is pythonese for '\0')




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

Bug#284742: Not-a-bug, and already-fixed-upstream

[Ken Harris]

My analysis, the short version: not-a-bug, and already-fixed-upstream.
Long version:

The first one sounds like a bug in your program, not a bug in wxWidgets
2.5.3.  It looks like you made a non-Unicode build of wxWidgets
yourself, and wrote code that worked there, but broke on Unicode-enabled
wxWidgets.  Specifically:

The _T() macro (it's another name for wxT()) should be used for all
literal strings.  What you did is define a string literal without using
it (bad), and then try to apply _T() to that macro.  With ANSI builds,
_T() does nothing, so it happened to work; with Unicode builds, it
prepends L (abc - Labc), and prepending an L to a macro changes its
name, so it didn't work.  Fix: wrap all your string literals with _T()
or wxT() (e.g,. #define VERSION wxT(0.1)) and you'll be OK.

The second one sounds like a fixed bug in wxWidgets.  See version 1.41
of [1] -- it was fixed in the checkin from *just* after wx2.5.3.
(Darn.)  In the meantime, you can always wrap the string literals in
_T() yourself (every time you run wxrc).

[1]: http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/utils/wxrc/wxrc.cpp


Cheers.




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

Bug#284943: wx.Printout broken

[Ken Harris]

Ah, good to hear this is already being fixed.

I'd looked on the wiki and mailing list archives and IRC channel, and it
didn't seem to be heard of before, apart from this Debian bug report.
If it's already being replaced by gnomeprint, that of course would be
even better than fixing the current implementation.

I'm not in a super hurry, nor am I terribly curious about why it broke.
As long as printing in wxPython on GTK+ works for, say, wxPython 2.6,
I'm happy.

Thanks for responding.


- Ken



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

Bug#293251: Crashes if you try to parse YAML with an invalid alias

[Ken Harris]

Package: python-syck
Version: 0.42-5

If you try to parse a YAML file with Syck that has an alias that hasn't
been defined, it crashes.

It works fine if all references are defined:

 syck.load(---
... - a stuff
... - *a)
['stuff', 'stuff']

If a file has a bad reference, boom:

 syck.load(---
... - a stuff
... - *b)
Segmentation fault

Expected behavior: it should raise an exception, so the programmer can
catch it and deal with it.  (Python programs should never crash!)


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages python-syck depends on:
ii  python2.3.4-6An interactive high-level
object-o
ii  python2.3-syck0.42-5 YAML parser kit -- Python
2.3 bind

-- no debconf information




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

Bug#293252: Asterisks not escaped properly by ydump.py

[Ken Harris]

Package: python-syck
Version: 0.42-5

ydump doesn't escape asterisks correctly.  Asterisks are used by YAML to
indicate aliases, so if you have a text string that starts with an
asterisk, it needs to be escaped.

What ydump does currently (wrong):
 ydump.dump('*YAML*')
'--- *YAML*\n'

(I'm not sure this is even valid YAML.  It certainly doesn't mean 'the
string *YAML*.)

The correct output should be something like: '--- *YAML*\n' (there are
probably several correct ways to escape it).

(This is especially nasty because Syck crashes if you try to use an
alias that hasn't been defined, and *YAML* looks like an alias to it.)


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages python-syck depends on:
ii  python2.3.4-6An interactive high-level
object-o
ii  python2.3-syck0.42-5 YAML parser kit -- Python
2.3 bind

-- no debconf information




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

Bug#293084: More characters not serialized correctly by ydump.py

[Ken Harris]

Package: python-syck
Version: 0.42-5

Hello again!

After trying to use ydump/syck some more, I ran into the problem that
'?' characters aren't escaped correctly, it seems.  I decided to write a
short program to try all the ASCII characters and see which don't work:

import syck, ydump
for i in xrange(128):
c = chr(i)
try:
assert syck.load(ydump.dump(c)) == c
except:
print failed for chr(%d) = '%s' % (i,c)

On my computer, this generates:

failed for chr(0) = ''
failed for chr(10) = '
'
failed for chr(32) = ' '
failed for chr(33) = '!'
failed for chr(44) = ','
failed for chr(62) = ''
failed for chr(63) = '?'
failed for chr(91) = '['
failed for chr(93) = ']'
failed for chr(123) = '{'
failed for chr(124) = '|'
failed for chr(125) = '}'
failed for chr(126) = '~'

(These may look familiar: they have special meanings in YAML, and are
listed on the YAML reference card at http://yaml.org/refcard.html.)

I think this could be fixed (as before) by simply adding these
characters to the needsSingleQuote() function; a simple (but probably
not optimal) way to do it would be to add the lines:

if data[0] in ['\n',' ','!',',','','?','[',']','{','|','}','~']:
return 1

(chr(0) seems to be dumped correctly, but Syck refuses to load a string
that contains '\0'.  I have no idea know how hard this would be to fix.
I'll file a separate bug for this.)

While I'm at it, I tried putting other special names from the YAML
reference card through syck/ydump, and these also failed:
- 'null' (upper-, lower-, and title-case only)
- '.inf' (upper-, lower-, and title-case only)
- '.nan' (upper-, lower-, and title-case only)

These should also be fairly easy to fix in needsSingleQuote().


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages python-syck depends on:
ii  python2.3.4-6An interactive high-level
object-o
ii  python2.3-syck0.42-5 YAML parser kit -- Python
2.3 bind

-- no debconf information




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