Bug#121132: A script that may help in the mean time
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
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 # 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 However, if I run the following: $ cd /usr/src/modules/kqemu/ $ debian/rules build $ debian/rules ARCH=x86_64 binary-modules # 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 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
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
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
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
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
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]