Bug#121132: A script that may help in the mean time

2010-01-02 Thread Chris Mortimore
Hey folks,

Sorry for breathing new life into this kind of old bug, but this whole wildcard 
thing was something I was looking for myself.  Basically, as an interim 
solution, I've written some rather hackish Perl that does the job for me using 
'apt-cache search' to do the wildcard matching.  While not wonderful, it works 
quite nicely for me and I thought I'd share it just in case it helps anybody 
else who stumbles across this bug page (like I did).

The attached script is configured for stable (priority 500) with my own local 
repo (priority 1000), volatile, backports.org and unofficial multimedia (all 
default priority 10), defined in %repos.  %pins then defines the packages I 
want in each %repo entry to be pinned, in this instance, all linux-2.6.30 and 
openoffice packages from backports, clamav from volatile, and a few things from 
multimedia.  @pinkeys and @repokeys just holds the hash keys so the script 
knows which bits to process and which to ignore (if any).  The preferences get 
written to stdout, so you can check it before writing a file.

Usual disclaimer, works fine for me, may not for you, do what you like with it, 
may kill your dog, not my fault, etc.

Cheers,

Chris Mortimore

#!/usr/bin/perl

# Package pins
#   Format: key = souce ID (from %repos)
#   value = [package,package,package]:[priority]
my %pins = (
backports, 
linux-.*2.6.30.*,.*openoffice.org.*,ttf-opensymbol,uno-libs3,ure:600,
volatile, .*clamav.*:600,
multimedia, .*acroread.*,libdvdcss2,w32codecs:600,
);
# Keys of %pins to process
@pinkeys = (backports, volatile, multimedia);

# Repo definitions
#   Format: key = ID used in pins
#   value = [release pin]:[default priority]
my %repos = (
debian, l=Debian,a=stable:500,
security, l=Debian-Security:500,
local, l=Local:1000,
volatile, l=debian-volatile:10,
multimedia, l=Unofficial Multimedia Packages:10,
backports, l=Backports.org archive:10,
);
# Keys of %repos to process
@repokeys = (debian, security, local, volatile, multimedia, 
backports);

# Process %pins
foreach my $pin (@pinkeys) {
my ($tmppkgs, $priority) = split(:, $pins{$pin});
my ($release, undef) = split(:, $repos{$pin});
my @pkglist = split(,, $tmppkgs);
my @pkgs = ;

# Resolve wildcards
foreach my $pkg (@pkglist) {
$pkg = ^$pkg\$;
foreach my $line (`apt-cache --names-only search $pkg`) {
$line =~ s/\n//g;
my ($name, undef) = split( , $line);
push(@pkgs, $name);
}
}

# Make a preferences entry
foreach my $pkg (@pkgs) {
next if($pkg =~ m/^$/);
printf(Package: $pkg\nPin: release $release\nPin-Priority: 
$priority\n\n);
}
printf(\n);
}

# Process %repos
foreach my $pin (@repokeys) {
my ($release, $priority) = split(:, $repos{$pin});
printf(Package: *\nPin: release $release\nPin-Priority: 
$priority\n\n);
}



Bug#505439: kqemu-source: Fails to build under amd64

2008-11-12 Thread Chris Mortimore
Package: kqemu-source
Version: 1.3.0~pre9-12
Severity: grave
Tags: patch
Justification: renders package unusable


When running the following:

$ m-a -t build kqemu
SNIP
# Build the module
./configure --kernel-path=/lib/modules/2.6.24-etchnhalf.1-amd64/build
Source path   /usr/src/modules/kqemu
C compilergcc
Host C compiler   gcc
make  make
host CPU  x86_64

kernel sources/lib/modules/2.6.24-etchnhalf.1-amd64/build
kbuild type   2.6
/usr/bin/make
make[2]: Entering directory `/usr/src/modules/kqemu'
make -C /lib/modules/2.6.24-etchnhalf.1-amd64/build M=`pwd` modules
make[3]: Entering directory `/usr/src/linux-headers-2.6.24-etchnhalf.1-amd64'
CC [M]  /usr/src/modules/kqemu/kqemu-linux.o
make[4]: *** No rule to make target `/usr/src/modules/kqemu/kqemu-mod-x86.o', 
needed by `/usr/src/modules/kqemu/kqemu-mod.o'.  Stop.
make[3]: *** [_module_/usr/src/modules/kqemu] Error 2
make[3]: Leaving directory `/usr/src/linux-headers-2.6.24-etchnhalf.1-amd64'
make[2]: *** [kqemu.ko] Error 2
make[2]: Leaving directory `/usr/src/modules/kqemu'
make[1]: *** [binary-modules] Error 2
make[1]: Leaving directory `/usr/src/modules/kqemu'
make: *** [kdist_build] Error 2
BUILD FAILED!

If I don't use m-a and run the following:

$ cd /usr/src/modules/kqemu/
$ debian/rules build
$ debian/rules binary-modules
The same error as before

However, if I run the following:

$ cd /usr/src/modules/kqemu/
$ debian/rules build
$ debian/rules ARCH=x86_64 binary-modules
SNIP
# Build the module
./configure --kernel-path=/usr/src/linux
Source path   /usr/src/modules/kqemu
C compilergcc
Host C compiler   gcc
make  make
host CPU  x86_64

kernel sources/usr/src/linux
kbuild type   2.6
/usr/bin/make
make[1]: Entering directory `/usr/src/modules/kqemu'
make -C /usr/src/linux M=`pwd` modules
make[2]: Entering directory
`/usr/src/linux-headers-2.6.24-etchnhalf.1-amd64'
cp /usr/src/modules/kqemu/kqemu-mod-x86_64.o
/usr/src/modules/kqemu/kqemu-mod.o
  LD [M]  /usr/src/modules/kqemu/kqemu.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC  /usr/src/modules/kqemu/kqemu.mod.o
  LD [M]  /usr/src/modules/kqemu/kqemu.ko
make[2]: Leaving directory `/usr/src/linux-headers-2.6.24-etchnhalf.1-amd64'
make[1]: Leaving directory `/usr/src/modules/kqemu'
# Install the module
SNIP

So, I reckon debian/rules isn't setting ARCH properly.  This very humble patch
for debian/rules fixes this, but someone should probably make sure it does it
in a Debian-approved way, rather than my hackish way:

diff -Naur debian.old/rules debian/rules
--- debian.old/rules2008-11-12 11:04:05.0 +
+++ debian/rules2008-11-12 11:02:20.0 +
@@ -64,7 +64,7 @@
   
# Build the module
./configure --kernel-path=$(KSRC)
-   $(MAKE)
+   $(MAKE) ARCH=$(DEB_BUILD_GNU_CPU)
  
# Install the module
install -D -m 0644 kqemu.ko
debian/$(PACKAGE)-$(KVERS)/lib/modules/$(KVERS)/misc/kqemu.ko

The build log from m-a and patch are also attached.

Cheers,

Chris Mortimore

diff -Naur debian.old/rules debian/rules
--- debian.old/rules	2008-11-12 11:04:05.0 +
+++ debian/rules	2008-11-12 11:02:20.0 +
@@ -64,7 +64,7 @@
 
 	# Build the module
 	./configure --kernel-path=$(KSRC)
-	$(MAKE)
+	$(MAKE) ARCH=$(DEB_BUILD_GNU_CPU)
 
 	# Install the module
 	install -D -m 0644 kqemu.ko debian/$(PACKAGE)-$(KVERS)/lib/modules/$(KVERS)/misc/kqemu.ko


Bug#436560: fluxbox: Double entry in KDM menu

2007-08-14 Thread Chris Mortimore
Just to add to the info, this occurs on both i386 and amd64.

I also discovered that this does NOT occur with ratpoison, it only appeared 
once in my KDM menu.

Cheers,

Chris

On Wednesday 08 August 2007 12:33, Dmitry E. Oboukhov wrote:
 reassign 436560 kdebase
 thanks

 I've installed kdm and few WM (icewm, twm, fluxbox) and all of them are
 twice displayed in kdm menu. Obviously it is kdm's bug.

 CM Installed fluxbox using aptitude install fluxbox, and it appears
 twice CM in the KDM sessions menu, once as Fluxbox and once as
 FluxBox.  Both CM seem to have the same functionality.

 CM The Fluxbox entry seems to be supplied by the
 CM /usr/share/xsessions/fluxbox.desktop file, but I cannot see where the
 CM other entry is coming from.

 CM Nothing major, just a slightly cluttered sessions menu.

 CM Running an Etch system with security updates, debian-volatile and
 CM debian-multimedia.


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



Bug#436560: fluxbox: Double entry in KDM menu

2007-08-08 Thread Chris Mortimore
Subject: fluxbox: Double entry in KDM menu
Package: fluxbox
Version: 0.9.14-1.2
Severity: minor

Installed fluxbox using aptitude install fluxbox, and it appears twice
in the KDM sessions menu, once as Fluxbox and once as FluxBox.  Both
seem to have the same functionality.

The Fluxbox entry seems to be supplied by the
/usr/share/xsessions/fluxbox.desktop file, but I cannot see where the
other entry is coming from.

Nothing major, just a slightly cluttered sessions menu.

Running an Etch system with security updates, debian-volatile and 
debian-multimedia.

Cheers,

Chris Mortimore

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

Versions of packages fluxbox depends on:
ii  libc62.3.6.ds1-13 GNU C Library: Shared libraries
ii  libfontconfig1   2.4.2-1.2generic font configuration library
ii  libgcc1  1:4.1.1-21   GCC support library
ii  libice6  1:1.0.1-2X11 Inter-Client Exchange library
ii  libsm6   1:1.0.1-3X11 Session Management library
ii  libstdc++6   4.1.1-21 The GNU Standard C++ Library v3
ii  libx11-6 2:1.0.3-7X11 client-side library
ii  libxext6 1:1.0.1-2X11 miscellaneous extension librar
ii  libxft2  2.1.8.2-8FreeType-based font drawing librar
ii  libxinerama1 1:1.0.1-4.1  X11 Xinerama extension library
ii  libxpm4  1:3.5.5-2X11 pixmap library
ii  libxrandr2   2:1.1.0.2-5  X11 RandR extension library
ii  libxrender1  1:0.9.1-3X Rendering Extension client libra
ii  menu 2.1.33   generates programs menu for all me

fluxbox recommends no packages.

-- no debconf information


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



Bug#415959: psemu-drive-cdrmooby: Windows don't close when they should

2007-03-26 Thread Chris Mortimore
Hi Ryan,

Sorry, didn't realise it was a known issue.  I'll keep my eye out for the 
fix :)

Cheers,

Chris

On Monday 26 March 2007 20:27, Ryan Schultz wrote:

 Known. Planned fix is to do a GTK2 interface for CDRMooby, though I'll try
 to take a look at the FLTK stuff and see if there's an easy fix.

 Thanks!


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



Bug#415959: psemu-drive-cdrmooby: Windows don't close when they should

2007-03-23 Thread Chris Mortimore
Subject: psemu-drive-cdrmooby: Windows don't close when they should
Package: psemu-drive-cdrmooby
Version: 2.8+o-2
Severity: normal

When you try and close the windows associated with CDRMooby2, they don't 
actually close.  It seems that it is always the last window it plans to show 
stays.  I've used the following test cases:

Case 1:  Choose to configure CDRMooby2 from within PCSX using the menus, and 
click OK in the config window.  The window stays.
Case 2:  Again, open the CDRMooby2 config window, and compress an image using 
bz.index or .Z.table compression.  The compression progress bar appears, then 
disappears as expected, and a dialog box appears saying Done.  Dialog box 
closes, but closing the config window fails.
Case 3:  Choose Run CD from within PCSX, and choose an image ending in .iso 
(eg, disc1.iso).  The file selection box disappears, and a warning appears 
about the plugin not supporting ISO9660 images.  Clicking OK doesn't remove 
the warning box.  The game plays OK though.
Case 4:  Choose Run CD from within PCSX again, and choose an image ending 
in .bin.  The file selection box stays.  The game still loads.

If you need any more information, please get in contact with me.

Regards,

Chris Mortimore

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

Versions of packages psemu-drive-cdrmooby depends on:
ii  libbz2-1.0  1.0.3-6  high-quality block-sorting file 
co
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries
ii  libfltk1.1  1.1.7-3  Fast Light Toolkit shared 
librarie
ii  libgcc1 1:4.1.1-21   GCC support library
ii  libportaudio0   18.1-4   Portable audio I/O - shared 
librar
ii  libstdc++6  4.1.1-21 The GNU Standard C++ Library v3
ii  libx11-62:1.0.3-6X11 client-side library
ii  libxext61:1.0.1-2X11 miscellaneous extension 
librar
ii  zlib1g  1:1.2.3-13   compression library - runtime

psemu-drive-cdrmooby recommends no packages.

-- no debconf information


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



Bug#414970: openoffice.org-calc: solver doesn't follow constraints

2007-03-15 Thread Chris Mortimore
Package: openoffice.org-calc
Version: 2.0.4.dfsg.2-5
Severity: important

When using the solver to do linear programming, it always (at least when I've 
used it) gives answers outwith the constraints set.  For example, for a 3 day 
weighted average forecast, the formula is:
Ft = A*Dt-1 + B*Dt-2 + C*Dt-3
where A, B and C need to be between 0 and 1, and A+B+C=1.
Putting this into the solver, it was bringing up the optimum values to be 
things like 1.1, -0.8, and A+B+C was always bigger than 1, clearly 
outwith the constraints set.

I can provide the spreadsheet if you cannot reproduce the problem at your end.

On a side note, this is when I have assume linear model set.  If I unset 
assume linear model, the solver always says Iteration time out and doesn't 
give a solution.

Regards,

Chris Mortimore

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

Versions of packages openoffice.org-calc depends on:
ii  libc6 2.3.6.ds1-13   GNU C Library: Shared libraries
ii  libgcc1   1:4.1.1-21 GCC support library
ii  libstdc++64.1.1-21   The GNU Standard C++ Library v3
ii  libstlport4.6c2   4.6.2-3STLport C++ class library
ii  libufsparse   1.2-7  collection of libraries for 
comput
ii  openoffice.org-core   2.0.4.dfsg.2-5 OpenOffice.org office suite 
archit

openoffice.org-calc recommends no packages.

-- no debconf information


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