Bug#676784: Policy §10.5 and .jar file noticeable exception
On Tue Aug 06 13:38, Eugene Zhukov wrote: Can it simply be except if it is a .jar file in parenthesis instead of vague in the sense that it is meant to be uncompressed with...? We want to write policy to be general and not have 100s of special exceptions. In this case what is special is not that it's a jar file, but that the user isn't meant to interact with it using standard compressed file tools. This is not a state unique to jar files. Even if there aren't any other known cases now, we want to write policy in a way that can apply to them in the futuer. Matt signature.asc Description: Digital signature
Bug#703376: javahelper: Remove Maven support from jh_makepkg
On Tue Apr 09 18:00, Thomas Koch wrote: Niels Thykier: I am planning on a rewrite of jh_makepkg and have therefore not applied your patch as-is. I wasn't aware (forgot) about jh_makepkg and just had a look at it. I don't think we should have 2 dh-make-* style programs in the java team: jh_makepkg and mh_make. It's already enough logic duplication between dh-make, dh-make- perl, dh-make-php, dh-make-drupal, gem2deb, python-stdeb, haskell-devscripts, Well, mh_make just does maven packages, whereas jh_makepkg (was intended) to cover all the common options. Perhaps they should be merged, but that's up to the mh folks. Only having mh_make would be sad, I think. Matt signature.asc Description: Digital signature
Bug#539315: executable-not-elf-or-script test should know about jars
On Sat Jun 09 16:06, Colin Watson wrote: On Sat, Jun 09, 2012 at 03:58:26PM +0100, Colin Watson wrote: I tried to arrange that the general design should be amenable to a non-Linux implementation. That said, it's true that nobody has so far got round to coming up with one. I would expect it to be fairly trivial to write a Hurd implementation, seeing as binfmt_misc is really just a special case of translators; I don't know what it would take to implement it on kFreeBSD. An alternative, incidentally, would be to use a small shim which looks something like this (entirely untested): If I have an executable jar, how do I make the kernel invoke this instead if I just try and exec it? (This is the main issue with it working on kfreebsd) I have tried making jar files with a shbang line at the start, which (IIRC) works fine on openjdk, but not with gcj. Unfortunately, freebsd is also the platform that doesn't have working openjdk yet... Matt signature.asc Description: Digital signature
Bug#539315: executable-not-elf-or-script test should know about jars
On Sat Jun 09 12:08, Niels Thykier wrote: There are is also Policy §10.5: A symbolic link pointing to a compressed file should always have the same file extension as the referenced file. (For example, if a file foo.gz is referenced by a symbolic link, the filename of the link has to end with .gz too, as in bar.gz.) Jar files are zip files, so it should most likely be considered a compressed file. I notice that (e.g.) sat4j violates this and uses /usr/bin/sat4j to point to a jar file in /usr/share/java (with a .jar extension). I don't want to disagree with Niels' point about binfmt-misc, but I do think the fact that jar files are zip files here is coincidental. People are not meant to interact with them as zip files, they are meant to load them as Java libraries or programs. Using zip (and not elf, or something else) as the packaging format is an implementation detail. If executable jars via binfmt-misc is allowed then they certainly should be on the path without a .jar extension - users should invoke them without any need to know they are written in Java. Matt signature.asc Description: Digital signature
Bug#673276: lintian: please add check to detect incompatible java bytecode versions
This is somewhat complicated by the fact that on kfreebsd we still don't have openjdk, so we're using GCJ/GIJ, which is really a 1.5 implementation. If GCJ/GIJ can run 1.6 bytecode then absolutely this check should be 1.6 and you can ignore the rest of this mail. If it cannot, then it's more complicated, since we do have libraries and programs which actually just can't run on freebsd, since the do require 1.6, so there's no reason those should use 1.5 bytecode. OTOH, anything that can use 1.5 _should_ use 1.5, particularly if it's a program that depends on default-jdk, since that's GCJ/GIJ on kfreebsd. This is further complicated by the fact that library packages don't depend on the runtime. A bullet-proof solution might look like: (depends: default-jdk = 5) || (depends: openjdk-6 = 6) || (is library = 6) but maybe we don't care that much? Matt signature.asc Description: Digital signature
Bug#634089: jh_manifest causes CRC error
On Fri Jan 06 13:26, tony mancill wrote: Thank you for in-depth look into this bug. Niels or Matthew, any concerns with me preparing an upload? Go right ahead Thanks, Matt Thanks, tony On 01/05/2012 08:14 PM, Wookey wrote: This seems to me to be a serious problem blocking all java-helper-using packages So, I took a look at what's going on and found the following: --snip-- We can fix it by explicitly removing and recreating it: verbose_print(Updating manifest in $jar); $zip-removeMember( 'META-INF/MANIFEST.MF' ) unless($new_manifest); $zip-removeMember( 'META-INF/' ); $mem = $zip-addString($var, 'META-INF/MANIFEST.MF'); $mem-desiredCompressionMethod(COMPRESSION_DEFLATED); $zip-addDirectory( 'META-INF/' ); # This on the other hand may fail. $zip-overwrite() == AZ_OK or error(Writing modified jar ($jar) failed$ which I hope is an acceptable fix. Patch attached. signature.asc Description: Digital signature
Bug#646514: javahelper: jh_repack fails if folders *.jar exist
On Mon Oct 24 18:46, Andrew Ross wrote: If a package contains folders whose names match *.jar then jh_repack fails with messages like: rm: cannot remove `./branding/core/core.jar': Is a directory The find command should probably be changed to: find . -name '*.jar' -type f -print0 | xargs -0 rm -f I was not expecting anyone to have directories named like that. Fair enough, that seems like a sensible change. Matt signature.asc Description: Digital signature
Bug#609806: nxproxy prepared for build on Alioth
On Wed Jun 01 12:10, Mike Gabriel wrote: I have placed NX libs + NX proxy (upstream source is NoMachine, versions are 3.5.0-x) into collab-maint on Alioth: git clone ssh://git.debian.org/git/collab-maint/nxcomp.git git clone ssh://git.debian.org/git/collab-maint/nxcompext.git git clone ssh://git.debian.org/git/collab-maint/nxcompshad.git git clone ssh://git.debian.org/git/collab-maint/nxproxy.git Reinhard Tartler let me know that it would be Ok for you if the Pkg-X2go team takes over the maintenance of NX related code in Debian. If so, could you please document this in this bug report? Yes, that's correct. CC'd to both bug reports. Be my guest (-: Matt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#432838: Status
On Mon Nov 22 18:59, Simon Fondrie-Teitler wrote: Hi, What is the status of this? There does not seem to have been any progress since your last email in 2007. Is it OK if I take over the ITP? Well, I've not done anything with the upstream code either since then, but be my guest. Matt signature.asc Description: Digital signature
Bug#599078: php5: Upstream bug http://bugs.php.net/51026 propably present
Package: php5 Version: 5.3.2 Severity: important (I actually only reproduced this on an ubuntu system, however, I can't see why it would be any different) Upstream bug http://bugs.php.net/51026 means that mysql/ssl doesn't work in 5.3.0, 5.3.1 and 5.3.2. They've fixed it for 5.3.3, but squeeze currently has 5.3.2. It's a pretty major regression, so we should consider fixing it in squeeze, although I've not filed it as Serious. The patch fixing it would seem to be http://svn.php.net/viewvc/?view=revisionamp;revision=297688 Matt -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595947: monkeysphere: Monkeysphere proxycommand does not support IPv6
Package: monkeysphere Version: 0.31-1 Severity: important When using ssh + monkeysphere connecting to a dual stack (IPv4 + IPv6) host I am connected using IPv4, not IPv6, regardless of passing -6 to ssh. Connecting to an IPv6-only host appears to fail completely, as does connecting to an IPv6 address explicitly. Monkeysphere should prefer v6 to v4 for dual stack hosts and should work with v6-only hosts and addresses. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages monkeysphere depends on: ii adduser 3.112 add and remove users and groups ii gnupg 1.4.10-4 GNU privacy guard - a free PGP rep ii libcrypt-openssl-rsa-perl 0.25-1+b1 Perl module providing basic RSA fu ii lockfile-progs0.1.13 Programs for locking and unlocking ii perl [libdigest-sha-perl] 5.10.1-13 Larry Wall's Practical Extraction Versions of packages monkeysphere recommends: ii cron 3.0pl1-111 process scheduling daemon ii netcat 1.10-38 TCP/IP swiss army knife -- transit ii netcat-traditional [netcat] 1.10-38 TCP/IP swiss army knife ii openssh-client 1:5.5p1-4 secure shell (SSH) client, for sec ii socat1.7.1.2-4 multipurpose relay for bidirection ii ssh-askpass 1:1.2.4.1-9 under X, asks user for a passphras Versions of packages monkeysphere suggests: pn monkeysphere-validation-agent none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593351: Fixed in git
tags 593351 pending thanks Will be in 0.33 Matt signature.asc Description: Digital signature
Bug#593627: java-common: please use openjdk as default jdk on powerpcspe
On Sun Aug 22 14:41, Sebastian Andrzej Siewior wrote: * Niels Thykier | 2010-08-21 16:13:34 [+0200]: Personally I am okay with doing it and it is the intention of the Java Team to make openjdk the default on all architectures. The question is if we should do it now or after Squeeze (CC'ed the release team) for their comments. The problem with the default-jdk is that most architectures have openjdk as default. Some packages however don't build with default-jdk != openjdk. One of them on top of my head is jffi without openjdk-6 [0] with [1]. Then that's a bug, that package must build-depend on openjdk specifically. The problem with packages like default-jdk is that they pull in different packages on different systems leading to different behaviors and bugs. I don't like it :) default-jdk is there so that whenever we add a new arch to openjdk, or have to remove it, we don't have to update every single java package from openjdk [foo, bar, baz] | gcj-4.4 [quux]. Most java packages work with all the jdks we support and don't need to know about architecture-specific issues. Matt signature.asc Description: Digital signature
Bug#592265: Causes FTBFS of other packages
Package: javahelper Version: 0.32 Severity: grave Despite what the man page says, you can't call jar -u -f -m you have to use ufm for sun jar. This bug will cause javahelper-using packages to FTBFS. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages javahelper depends on: ii bsdmainutils 8.0.11 collection of more utilities from ii dctrl-tools 2.14 Command-line tools to process Debi ii debhelper 7.4.20 helper programs for debian/rules ii devscripts2.10.64scripts to make the life of a Debi ii dpkg-dev 1.15.7.2 Debian package development tools ii libarchive-zip-perl 1.30-2 Perl module for manipulation of ZI javahelper recommends no packages. Versions of packages javahelper suggests: ii cvs 1:1.12.13-12 Concurrent Versions System pn gawknone (no description available) pn tofrodosnone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591874: javahelper: jh_build does not specify -source, gcj gets it wrong
Package: javahelper Version: 0.32 Severity: important Because gcj _still_ defaults to 1.4 source format and jh_build doesn't specify anything when building, something using default-java will ftbfs on kfreebsd or hppa if it uses 1.5 source featuress. Always specifying: -source 6 -target 5 _should_ be safe on all VMs, so we should do that. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages javahelper depends on: ii bsdmainutils 8.0.11 collection of more utilities from ii dctrl-tools 2.14 Command-line tools to process Debi ii debhelper 7.4.20 helper programs for debian/rules ii devscripts2.10.64scripts to make the life of a Debi ii dpkg-dev 1.15.7.2 Debian package development tools ii fastjar 2:0.98-3 Jar creation utility ii python2.5.4-9An interactive high-level object-o ii python-debian 0.1.16 Python modules to work with Debian ii python-scriptutil 1-1Python module which provides the f javahelper recommends no packages. Versions of packages javahelper suggests: ii cvs 1:1.12.13-12 Concurrent Versions System pn gawknone (no description available) pn tofrodosnone (no description available) ii unzip 6.0-4De-archiver for .zip files pn zip none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591521: fastjar does not put Manifest-Version into a supplied manifest file
Package: fastjar Version: 2:0.95-4 Severity: normal If you use fastjar -cfm foo.jar manifest the manifest file does not have the Manifest-Version added or suitable blank lines at the end. Openjdk's jar does put these lines in there. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages fastjar depends on: ii libc6 2.7-18lenny2 GNU C Library: Shared libraries ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime fastjar recommends no packages. fastjar suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589550: fetch-crl: package fails to install
Perhaps this would work alternatively: update-rc.d fetch-crl-boot start 20 0 6 . stop 20 0 1 2 3 4 5 6 . /dev/null 0 and 6 don't start any processes... Matt signature.asc Description: Digital signature
Bug#588379: using jh_depends when a .jar exists in one than one package
tag 588379 wontfix thanks Hi Scott, I'm the other Javahelper maintainer, On Sun Jul 11 11:12, Scott Howard wrote: Processing is a java package which compiles java code, so it depends on the jdk. The package won't build unless tools.jar is explicitly in the classpath at build time (I'm not too familiar with that package, i work with arduino so I don't know what happens if tools.jar isn't in the classpath at runtime for processing). The question I have is - if the Class-Path: in the jar manifest contains just tools.jar - how is this loaded by the JVM? I would expect it wouldn't know where to look. If you explicitly list the path to tools.jar, then it'll only load the one from that JVM - and hence you should depend on just that. I expect what you actually want to do is either list both in the manifest or select it at runtime and hence don't need it in the manifest (and, I see below, this latter is what you do). My view is that this really is a corner case and the automated tools like jh_depends are designed for the common case, so the easiest solution may be to just list the depends yourself. Maybe we can use javahelper to define one classpath during build time and another for runtime? (I've tried but haven't found how to do it yet using jh_build and setting CLASSPATH and/or using .classpath, and I haven't tested if the package would even work - just a theory) I have a feeling that having a different classpath than the build time classpath isn't that good of an idea, especially when upstream's wrapper for launching the .jar [3] does the following: Well, your wrapper here is setting the classpath, so you don't need it to be in the jar. The other option would be to use jh_build to build (doesn't upstream have a build system?) and then jh_classpath to remove the classpath, then you can put the depends in manually and have the wrapper script (as it does) set the classpath at runtime. This might be a really unique case, but I guess the quirk would be if tools.jar is found in the classpath to include either the openjdk OR sun jdk since the file exists in both and only one is installed during build time (the one in main). I'd understand if it's too much to change and maintain the change for the few java packages that would depend on tools.jar, I'll defer to your experience and opinion. Yeah, I think that's probably the case here, but thanks for asking about it - it's certainly an interesting case! Matt signature.asc Description: Digital signature
Bug#574029: jh_manifest utf8 errors - workaround
On Sat May 01 17:40, Eric Lavarde wrote: On 01/05/10 17:16, Eric Lavarde wrote: Very last thing: the workaround with override_jh_manifest doesn't seem to work for me, jh_manifest gets called and happily fails... Sorry to reply to myself but I found another workaround. Just add the following to debian/rules: JH_MANIFEST_ARGS := -V Looks like you are using CDBS not dh7, so you will need to do this. Also looks like it might be a bug with the library I'm using, so I might punt it to them. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#574029: jh_manifest utf8 errors
On Tue Apr 27 09:57, Picca Frédéric-Emmanuel wrote:
I really could do with seeing the manifest from either of your packages - I
suspect that there is non-utf8 data in there. Without seeing it though I
can't
reproduce or suggest a fix. (I'm afraid I can't read winmail.dat)
sorry for such a late answer.
Attached the faulty manifest file, the one from ATKWidget-4.0.6.jar.
Hmm, this is very weird, I cannot reproduce this failure either by manually
running jh_manifest, or building the package in a clean chroot (via cowbuilder)
- it builds just fine.
it seems that this MANIFEST is not in unix format.
That should not be a problem.
the error is still:
Traceback (most recent call last):
File /usr/bin/jh_manifest, line 264, in module
updatejar(j, tempmanifest, args)
File /usr/bin/jh_manifest, line 78, in updatejar
manifest = parseManifest(tempdir + /META-INF/MANIFEST.MF, None,
manifest)
File /usr/bin/jh_manifest, line 164, in parseManifest
manifest[section][i.strip()] = sec[i].strip().replace('\n ','')
File /usr/lib/pymodules/python2.5/debian/deb822.py, line 179, in
__getitem__
value = value.decode(self.encoding)
File /usr/lib/python2.5/encodings/utf_8.py, line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xf3 in position 5:
unexpected end of data
This is really weird, since none of the manifests I have after building, nor
the one you sent me, contain a byte with the value f3 (according to hexdump).
I have two more questions: what locale are you building in, and could you run
the following command after you get a build failure (either of you):
for j in `find debian -name *.jar `;
do
rm -rf META-INF;
jar xf $j META-INF/MANIFEST.MF;
hexdump -C META-INF/MANIFEST.MF | grep -i f3;
done
For me this returns no results - ie, none of the manifests contain a byte 0xf3.
I know this isn't really helping with getting javahelper working for you.
There's an easy work around though - you're probably not actually using any
jh_manifest features, so you could just add:
override_jh_manifest:
to your debian/rules file (assuming dh7) and it will skip running it at all.
This should be fine.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
Bug#574029: jh_manifest utf8 errors
On Mon Apr 19 14:09, Eric Lavarde - Debian wrote: Matthew Johnson said: I really could do with seeing the manifest from either of your packages - I suspect that there is non-utf8 data in there. Without seeing it though I can't reproduce or suggest a fix. (I'm afraid I can't read winmail.dat) Matt As I wrote in my email, there is no manifest to share! jh_manifest only gets called because I'm using CDBS, I have no debian/manifest or debian/package.manifest file. You do - all jars embed a manifest, the upstream build system may embed more data. extract META-INF/MANIFEST.MF from your jar files (or send me the jars) Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#574029: jh_manifest utf8 errors
I really could do with seeing the manifest from either of your packages - I suspect that there is non-utf8 data in there. Without seeing it though I can't reproduce or suggest a fix. (I'm afraid I can't read winmail.dat) Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#577068: Why does bash make itself unconditionally /bin/sh?
Package: bash Version: 4.0-7 Severity: serious Having just had an argument on IRC about /bin/sh diversions, it appears that the situation in Sid has changed again since I last looked at it. As I understood the discussions at Debconf last year and on this list, dash is now essential and the default /bin/sh. Bash is still essential and the default interactive shell. It can optionally (based on a debconf question at install time, or some other criteria on upgrades) provide /bin/sh should people want the old behaviour. I've been happily using dash for system shell scripts and bash interactively for a while and have been looking forward to that being the default. Having inspected an up-to-date sid chroot, it would appear that both bash and dash are now essential and bash is diverting /bin/sh to itself with /bin/sh.distrib pointing to dash. No amount of dpkg-reconfigure -plow gave me the option to change it. This seems like a regression which kinda makes all the effort on dash and bashims a little pointless.. It looks like this was introduced in 4.0-7 which fixes #546516. Thanks, Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#575941: nope
severity 575941 wishlist tag 575941 wontfix thanks As you pointed out, it's not meant to be run manually, you need a client and server to do the negotiation for you. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#561414: FTBFS [hppa]: GC Warning
reassign 561414 gcj-4.4-jdk thanks Sorry I haven't replied to this, I never saw an email about it.. That error is from javadoc in gcj-4.4-jdk, so I'm reassigning the bug to that package. given the bug is quite old, I don't know whether it's been fixed already, in which case libmatthew-java just needs giving back. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#565728: javahelper: jh_linkjars does not pull jars of transitiv dependencies
On Mon Jan 18 11:37, Thomas Koch wrote: if a package depends on libxerxes2-java, then linkjars will pull the jars of libxerxes2-java, but will not pull the jars of libjaxp1.3-java, which is a dependency of libxerxex2-java. Do you really need libjaxp1.3-java just to build against libxerxes2-java? At the moment I've added --transitive as an option, but not as default. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#569563: javahelper: provide command jh_installasjar
tag 569563 wontfix thanks On Fri Feb 12 13:50, Thomas Koch wrote: The command jh_installasjar should take a directory, a name, a version, a package name and optionally a manifest file or manifest entries, then - jar the specified directory directly into debian/PACKAGE/usr/share/java/NAME-VERSION.jar - create the symlink NAME.jar The command could also be called by jh_build. Creating jars should be part of the build step, not part of the install or binary step and writing to debian/PACKAGE should be part of the binary step, not part of the build step. In some cases this won't work, since debian/rules build is not guaranteed to be run with fakeroot. If you are using jh_build or a proper build system such as ant, maven or make then they should be creating the jar for you. If not, then in your custom build: target this is spelt: jar fm jar manifest dir and then listing the jar in debian/package.jlibs. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#568848: ircd-hybrid: Default channel mode of +t is annoying
Package: ircd-hybrid
Version: 7.2.2.dfsg.2-6
Severity: wishlist
Tags: patch
The default channel mode of +t is annoying since if you've not registered with
chanserv and all the ops disconnect (or are deopped) before changing it, then
you can never set the topic again. I've attached a patch which I hope changes
this.
Matt
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Index: ircd-hybrid-7.2.2.dfsg.2/modules/core/m_join.c
===
--- ircd-hybrid-7.2.2.dfsg.2.orig/modules/core/m_join.c 2010-02-08 08:51:56.663782322 +
+++ ircd-hybrid-7.2.2.dfsg.2/modules/core/m_join.c 2010-02-08 08:52:34.918962780 +
@@ -244,15 +244,14 @@
if (flags CHFL_CHANOP)
{
chptr-channelts = CurrentTime;
- chptr-mode.mode |= MODE_TOPICLIMIT;
chptr-mode.mode |= MODE_NOPRIVMSGS;
sendto_server(client_p, source_p, chptr, CAP_TS6, NOCAPS, LL_ICLIENT,
-:%s SJOIN %lu %s +nt :@%s,
+:%s SJOIN %lu %s +n :@%s,
me.id, (unsigned long)chptr-channelts,
chptr-chname, source_p-id);
sendto_server(client_p, source_p, chptr, NOCAPS, CAP_TS6, LL_ICLIENT,
-:%s SJOIN %lu %s +nt :@%s,
+:%s SJOIN %lu %s +n :@%s,
me.name, (unsigned long)chptr-channelts,
chptr-chname, source_p-name);
/*
@@ -261,7 +260,7 @@
sendto_channel_local(ALL_MEMBERS, NO, chptr, :%s...@%s JOIN :%s,
source_p-name, source_p-username,
source_p-host, chptr-chname);
- sendto_channel_local(ALL_MEMBERS, NO, chptr, :%s MODE %s +nt,
+ sendto_channel_local(ALL_MEMBERS, NO, chptr, :%s MODE %s +n,
me.name, chptr-chname);
}
else
Index: ircd-hybrid-7.2.2.dfsg.2/modules/m_lljoin.c
===
--- ircd-hybrid-7.2.2.dfsg.2.orig/modules/m_lljoin.c 2010-02-08 08:55:35.555809801 +
+++ ircd-hybrid-7.2.2.dfsg.2/modules/m_lljoin.c 2010-02-08 08:56:06.206869883 +
@@ -204,14 +204,13 @@
if (flags CHFL_CHANOP)
{
-chptr-mode.mode |= MODE_TOPICLIMIT;
chptr-mode.mode |= MODE_NOPRIVMSGS;
sendto_channel_local(ALL_MEMBERS, NO, chptr,
- :%s MODE %s +nt,
+ :%s MODE %s +n,
me.name, chptr-chname);
sendto_one(uplink,
- :%s MODE %s +nt,
+ :%s MODE %s +n,
me.name, chptr-chname);
}
Bug#561177: RFS: cobertura
On Mon Feb 01 21:15, Miguel Landaeta wrote: - is there any reason why you are depending on openjdk rather than default-jdk? If not, you should depend on default-jdk. You should also probably include the other virtual packages (java6-runtime etc) - ditto, you should build-dep on default-jdk This was just laziness on my part. It is already fixed to depend on the correct packages. cobertura source package now Build-Depend on default-jdk-builddep and the binary packages Depend on default-jre-headless | java2-runtime-headless | java2-runtime. (haven't looked at the package yet, but) you should build-dep on default-jdk, not default-jdk-builddep (it's very badly named, I plan to get this fixed), and you should also include java5-runtime-headless and java6- in the alternates list. - (biggest issue here): Apache 1.1 licenced code seems not to be linkable with GPL-2+ licenced code: http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses and you have both in cobertura. You should probably raise this with upstream and see what they say. Upstream clarify this in her website (http://cobertura.sourceforge.net/license.html ): The use of the Apache Software License in Cobertura is very straight forward. Cobertura includes a set of ant tasks which can be used to call Cobertura. Ant itself is licensed under the Apache Software License, Version 2.0. Because ant tasks are loaded directly into the runtime of ant, and the GPL is incompatable with all versions of the Apache Software License, ant tasks can not be licensed under the GPL. For this reason, the Cobertura ant tasks are licensed under the Apache Software License, Version 1.1. And because these ant tasks are not GPL-compatable, but the rest of Cobertura is GPL, when these ant tasks invoke Cobertura they must do so by exec'ing a new JVM. If this is not clear, what's the correct thing to do? Contact upstream? debian-legal? Ah, thank you, yes, this is perfectly correct, you should paste that into debian/copyright so everyone knows what is going on (particularly the FTP masters when they do the same review in the NEW queue) Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#561177: RFS: cobertura
On Tue Feb 02 11:35, Charles Plessy wrote: Dear Miguel, this information is outdated as the GPL version 3 is compatible with the Apache License version 2.0, see: http://www.apache.org/licenses/GPL-compatibility.html Yes, but the files in question are licenced under Apache 1.1, so this does not help. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#561177: RFS: cobertura
On Tue Jan 26 22:06, Miguel Landaeta wrote: The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/cobertura - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/cobertura/cobertura_1.9.3+dfsg-1.dsc Hi, I've reviewed the package and have a few comments (some of which need changing, others are a matter of style). - any reason you're not using dh --with ant or --with javahelper and are doing everything by hand? - the API doc in cobertura-doc should still be located in /usr/share/doc/cobertura/api - Is cobertura really providing a library? If so, would it be better to split out a libcobertura-java package for things to depend on. If not, do you need the API and to have the jar in /usr/share/java? - is there any reason why you are depending on openjdk rather than default-jdk? If not, you should depend on default-jdk. You should also probably include the other virtual packages (java6-runtime etc) - ditto, you should build-dep on default-jdk - standards-version has just been changed to 3.8.4 - there are still files in etc/dtds/ with the copyright notice: !-- Portions (C) International Organization for Standardization 1986:^M Permission to copy in any form is granted for use with^M conforming SGML systems and applications as defined in^M ISO 8879, provided this notice is included in all copies.^M which it's not clear is DFSG-free (in particular it doesn't seem to provide permission to distribute modified versions on derivative works) - (biggest issue here): Apache 1.1 licenced code seems not to be linkable with GPL-2+ licenced code: http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses and you have both in cobertura. You should probably raise this with upstream and see what they say. - cobertura-doc suggests cobertura-java, but the other package is just cobertura -- Matthew Johnson signature.asc Description: Digital signature
Bug#560869: FTBFS: failures in jh_manifest
reassign 560869 javahelper tag 560869 pending thanks On Sat Dec 12 23:24, Cyril Brulebois wrote: Package: libmatthew-java Version: 0.7.2-2 Severity: serious Justification: FTBFS This is a bug in javahelper, I've just fixed it in git and I'll upload (yet another) new version. Should just need requeueing on the buildd once javahelper 0.26 is in the archive. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#559986: FTBFS: default-jdk-builddep: Depends: gcj-jdk but it is not going to be installed
On Fri Dec 11 05:59, Matthias Klose wrote: I would prefer to see gjdoc being removed for the release, if possible. for the packages build-depending it for now, just remove it from the b-d's and make sure that javadoc is used instead of gjdoc. If for some reason, you need it explicitely, maybe b-d on gcj-jdk | gjdoc. The list of packages are: aspectj babel jaminid jesd jmdns libcsv-java libjibx-java mina trilead-ssh2 weirdx And the reason that my packages depend on gjdoc is for dh_javadoc, which is not provided by anything else. However, I think it would be better to move that to javahelper (and fix it up in the mean time, since it's a bit shonky anyway) I can do that, and migrate jsed, libcsv-java, trilead-ssh2 and weirdx, which due to a bug I found and fixed in dh_javadoc I suspect of being the only packages using it. If someone wants to file a bug against them and/or javahelper about this then I'll be more likely to remember (-: Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#559688: ITP: pescetti -- Bridge Pseudo-duplimate generator
Package: wnpp Severity: wishlist Owner: Matthew Johnson mj...@debian.org X-Debbugs-CC: debian-de...@lists.debian.org Source package: pescetti Binary package(s): pescetti Version: 0.5-1 Licence: GPL-2 Author: Matthew Johnson s...@matthew.ath.cx Homepage: http://www.matthew.ath.cx/projects/pescetti/ Description: Bridge Pseudo-duplimate generator Generates random bridge hands or hands matching a certain specification with a given probability. Produces hand records and dealing sheets to allow duplication of the hands without a duplimate machine. . Pescetti can interface with the dds double dummy solver to produce analysis for the hand records. . Provides conversion or import from dds-format and pbn files. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559255: whirlpool: should this package be removed?
severity 559255 normal reassign 559255 ftp.debian.org retitle 559255 RM: whirlpool -- RoM thanks On Thu Dec 03 03:22, Simon McVittie wrote: whirlpool seems like a possible candidate for removal from Debian: * RC-buggy (calculates wrong hashes for 8k data, making it basically useless) * low popcon (36 installations, 9 votes) * alternatives exist (at least libcrypto++-utils, md5deep and jacksum) Concur, please remove Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#558109: Proposal for java-vars.mk
tag 558109 pending patch thanks Hi Zack, how does this look? http://mjj29.matthew.ath.cx/debian-upload/javatools/java-vars.mk Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#395372: [policy] relax or expand the binaries in /usr/bin restriction (2.3)
On Mon Sep 21 08:40, Michael Koch wrote: I second this proposal to include /usr/games in 2.3. Thirded! /usr/games is just another incarantion of /usr/bin and should be explicitely allowed to nt confuse people. We should just reference policy/the FHS. Binaries should be allowed by d-j policy anywhere that they are allowed by normal policy. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#543109: salliere: FTBFS: make: *** [binary-indep] Error 1
reassign javahelper retitle javahelper: fails to track dependencies on binary packages from the same source thanks On Fri Sep 18 10:23, Nicolas Van Wambeke wrote: We've addressed this in Ubuntu [1]. [2] is a debdiff against debian 0.7.1-1 which fixes the issue. This is a bug in javahelper, I'm reassigning it to there. I may not be able to fix it until mid next week, however, since I'm moving house. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#540615: weirdx: FTBFS because of missing Build-Depends: gjdoc
On Sun Aug 09 08:40, Torsten Werner wrote: Package: weirdx Version: 1.0.32-4 Severity: serious Justification: 7 your package uses dh_javadoc in debian/rules but does not declare a Build-Depends: gjdoc which is the package that ships dh_javadoc. s how come it built in my sid cowbuilder then? Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#539315: lintian: Lintian should not warn about executable jars
Package: lintian Severity: wishlist debian-java policy is being updated to allow executable jar files as long as they depend on jarwrapper, which implements a binfmt_misc wrapper to run them. Currently lintian produces an executable-not-elf-or-script warning about such files. I am detecting jar files using the zip magic bytes (since they are zip files) and the existence of a META-INF/MANIFEST.MF file inside. Matt -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lintian depends on: ii binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina ii diffstat1.45-2 produces graph of changes introduc ii dpkg-dev1.14.25 Debian package development tools ii file4.26-1 Determines file type using magic ii gettext 0.17-4 GNU Internationalization utilities ii intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf ii libparse-debianchan 1.1.1-2 parse Debian changelogs and output ii libtimedate-perl1.1600-9 Time and date functions for Perl ii liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin ii man-db 2.5.2-4 on-line manual pager ii perl [libdigest-sha 5.10.0-10Larry Wall's Practical Extraction lintian recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534542: RM: fcoretools -- RoM; broken and broken runtime/inline build system
Package: ftp.debian.org Severity: normal Please remove fcoretools Thanks, Matt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521760: Reopening and reassigning
reopen 521760 reassign 521760 sun-java6 retitle 521760 alternative link problems with java when upgrading packages thanks Right, looks like there's a definite bug here, but it's equally still definitely nothing to do with jarwrapper, so I'm reassigning it to sun-java6. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#526489: Time to orphan eclipse? (Bug#526489: eclipse: should this package be orphaned?)
On Mon Jun 15 16:32, Andreas Tille wrote: On Mon, 15 Jun 2009, Jens Kapitza wrote: I can offer my time but i think i need some help. About half a year ago I offered sponsoring packages to push things but I have basically zero Java experience and can only check about Debian policy and stuff - not really stress test whether the installed packages are really working. I can sponsor and do have Java experience (although won't be using Eclipse). Eclipse is also a fairly complicated package from what I remember, so may take some time for anyone to grok, Java experience or not. Jens, and anyone else who is interested in this, do you want to send me any questions you have? Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#495637: [ant] Dangling symlink in ant package
I still see this, any chance it could be fixed? Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#530110: jarwrapper: bashism in /bin/sh script
tag 530110 pending thanks Fixed in git, thanks, Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#518529: gmrun hangs when history contains long string
I can also confirm this issue. Patch looks ok, but I've not tried it. I could test debs at some point. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#523809: help with avbin packaging
Hi Andrew, I'd quite like to see avbin available in Debian, can I help at all with packaging / uploading it? Thanks, Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#526399: [fretsonfire] Crash when starting 'Credits'
tag 526399 pending thanks On Fri May 01 00:27, Roland Clobus wrote: --- Please enter the report below this line. --- The song 'defy' is missing. The song is needed when starting the Credits from the main menu in the program. I have a patch in svn that changes it from defy to sectoid/Feelings. Of course, that's only 'Recommended' from fretsonfire-game, but I couldn't work out how to ignore the error or have it without music at all. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#515214: I don't think we need to add complexity to X on Debian
On Mon Apr 13 10:41, Robert Grimm wrote: On Sun, 12 April 2009, you wrote: Please do not accept any of the patches. Most users want things to just work. Anyone who wants to keep their systems hal-free is capable of configuring xorg accordingly and should be able to make a filler package using equivs to fulfill the dependency with no need to increase the complexity for the majority. In my opinion, HAL is unneeded complexity. Furthermore, the referenced most users are perfectly capable to install recommends. This is the default behavior in Debian. If they like to install every piece of software, that makes their life easier, why wouldn't they install recommends? Concur. We _have_ a perfectly good system for saying please install this unless you know what you are doing; it's 'recommends'. It doesn't force people to hack around the issue (and equivs _is_ hacking around the issue), but it does get installed by default unless people know what they are doing. Not only that, but you also have a metapackage, which is what people generally install by default. Add a hard depends to that by all means, but you don't need to _require_ it. I'm not even likely to want to install it without hal myself, but I see no reason whatsoever not to allow people a hal-less X if they want. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#522616: ITP: live-f1 -- Formula 1 live timing
Package: wnpp Severity: wishlist Owner: Matthew Johnson mj...@debian.org X-Debbugs-CC: debian-de...@lists.debian.org Source package: live-f1 Binary package(s): live-f1 Version: 0.2.7-1 Licence: GPL-2 Author: Scott James Remnant sc...@netsplit.com Homepage: Description: Formula 1 live timing Command line program for monitoring live timing from Formula 1 races. Requires a free account on the Formula 1 website. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521967: FTBFS: Fail to build with libitext-java 2.1.4
tag 521967 pending thanks Thanks Damien, I've applied the patch upstream, I'll make an upload soon. Source file cx/ath/matthew/salliere/PDFTablePrinter.java is using old iText 1.x API. Some of this methods has been removed from iText 2.1.x : Table#setSpaceInsideCell Table#setDefaultVerticalAlignment Table#setDefaultCellBorder #include rant about transitions in java at the moment Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#521844: Please include pretty-print postscript generator script
On Tue Mar 31 11:21, Joerg Dorchain wrote: More importantly though, can you confirm the licence it is distributed under? You aren't the original author, so they obviously licenced it to you some how. From the comments of the file I'd read public domain. My source was from FreeBSD (e.g. http://www.freebsdsoftware.org/security/opieprint.html) From this I assume the licence allows redistribution and modification. The comments in the file unfortunately don't say anything regarding what licence it's being distributed under. The default assumption in any berne-convention country (aka, basically anywhere) has to be that all rights are reserved by the author. I've asked the freebsd guys what they do to check software before going into their archive, but if I could have a statement from you that your changes are licenced under the BSD or expat licences (which are basically PD) I can chase the original author to get a statement from him, or get something from the BSD guys Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#521760: fastjar: Failed upgrade 2:0.95-1 - 2:0.97-3
On Mon Mar 30 16:25, Matthias Klose wrote: Looking at the bug report more closely, the root cause might actually be something to do with: update-alternatives: warning: alternative /usr/lib/jdk1.1/bin/jar.1.gz (part of link group jar.1.gz) doesn't exist. Removing from list of alternatives. Could this be caused by a package not from the archive which was installed in /usr/lib/jdk1.1 and has since been removed, but which left alternatives around? ok, I didn't see the jdk1.1 link. that maybe indeed the root cause. Then, maybe just close it? Hi, thanks for submitting this bug, but as you can see above, I think it might be related to some unofficial package which has left things around. Sadly, I can't really do much to fix that, so unless you disagree I'm going to close this bug. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#521844: Please include pretty-print postscript generator script
On Mon Mar 30 14:58, Joerg Dorchain wrote: please consider the attached script for inclusion as contributed code for otpw. It is a bit rough cut, but gives a nice CC-Card sized password list that carries easily in you wallet. Hi, looks quite good, but the integration with otpw-gen could do with a little work, I might work on that. More importantly though, can you confirm the licence it is distributed under? You aren't the original author, so they obviously licenced it to you some how. I'll definitely consider including it though, and will push it upstream. Thanks, Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#521760: fastjar: Failed upgrade 2:0.95-1 - 2:0.97-3
Hi Matthias, Do you have any reason to believe that jarwrapper breaks fastjar? I have no idea how it possibly could; the maintainer scripts just cass update-binfmts, but the problem would seem to be: update-alternatives: error: alternative jar.1.gz can't be slave of jar: it is a master alternative. All I have to do with fastjar is depend on it and call it. Don't forget that when you reassign I don't get the email unless you CC me, I just see that a bug number has been assigned to my package. Looking at the bug report more closely, the root cause might actually be something to do with: update-alternatives: warning: alternative /usr/lib/jdk1.1/bin/jar.1.gz (part of link group jar.1.gz) doesn't exist. Removing from list of alternatives. Could this be caused by a package not from the archive which was installed in /usr/lib/jdk1.1 and has since been removed, but which left alternatives around? Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#510634: [Pkg-cups-devel] Bug#510634: cups doesn't allow introspection in dbus config file
On Mon Mar 23 15:39, Martin Pitt wrote: Hello Matthew, Matthew Johnson [2009-01-03 22:36 +]: The cups config file for dbus doesn't allow introspection requests. Because all it does is send signals this isn't an RC issue, but it should have working introspection for those signals. As far as I can see, cups does not need any D-BUS configuration at all, since it does not provide any service. It only sends signals, which are allowed by default anyway. Thus I'm going to drop the file entirely. Or am I missing something? It should have working introspection so that clients can wont out what signals it sends out and what their syntax is. Signals are all declared in an interface and emitted from an object. That object should provide introspection if queried containing the interface with the signals (but in this case no methods). If that doesn't exist, it's an upstream problem, but even if it does exist at the moment it can't be queried because of the config file issue, which is what this bug is about. Hope that's clearer, Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#510634: [Pkg-cups-devel] Bug#510634: cups doesn't allow introspection in dbus config file
On Mon Mar 23 17:12, Martin Pitt wrote: Hello Matthew, Matthew Johnson [2009-03-23 15:14 +]: It should have working introspection so that clients can wont out what This is find, I presume. Um... yes (-: Signals are all declared in an interface and emitted from an object. That's what I meant, there is nothing to query *against*. cupsd does not provide any d-bus object. It opens the bus, fires the signal, and tears it down again. It's really very primitive. So with no d-bus service being present, I still don't see a way how to write a policy for it? I see, well, that's a bug which should be sent upstream. At the moment then it makes little difference as you say. When/if upstream have a valid dbus implementation though, there should also be a policy file which allows it. The reason for filing the bug in the first place is that this is a change in behaviour caused in the process of fixing a security issue. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#519603: imdb-get fails due to HTML layout changes
tag 519603 +pending thanks On Fri Mar 13 11:30, Brian Murray wrote: The HTML layout of pages at the imdb changed and now searching fails without returning any results. This can be recreated by using a command like: A patch was submitted by an Ubuntu user to http://launchpad.net/bugs/313260. I've tested the patch it resolves the issue. Thanks, I've already got this applied upstream, I'll do a release and push it through unstable. matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#519681: RM: wound-up -- RoM; buggy and unsupported
Package: ftp.debian.org Upstream no longer support this and it seems quite buggy, so please remove it. -- Matthew Johnson signature.asc Description: Digital signature
Bug#519682: RM: gbib -- RoM; uses gtk1.2
Package: ftp.debian.org Upstream is dead, so this won't get ported to gtk2, so please remove. -- Matthew Johnson signature.asc Description: Digital signature
Bug#506131: shouldn't this be closed now?
seeing as how 1.1.17 has been uploaded Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#519415: unavailable dependency: fretsonfire-songs-muldjord
tag 519415 pending severity 519415 normal thanks On Thu Mar 12 13:12, Éric Araujo wrote: I cannot upgrade fretsonfire on Sid since some time because of a missing dependency, fretsonfire-songs-muldjord. It is marked unavailable. Is it a non-free package? Perhaps it should be moved to a suggest. It's in NEW, just be patient. For now, grab just fretsonfire-game from unstable, fretsonfire is just a metapackage. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#458504: Bug updates
fixed 478444 1.3.110.dfsg-1 fixed 426457 1.3.110.dfsg-1 fixed 446713 1.3.110.dfsg-1 fixed 458504 1.3.110.dfsg-1 retitle 427164 Can't use libraries under .fretsonfire/songs found 427164 1.3.110.dsfg-1 found 458506 1.3.110.dsfg-1 thanks 478444 fixed in latest upload. 458504 seems to work fine in 1024x600 in latest upload. 427164 still a problem in the latest release \-: 458504 still a problem, but with a slightly different signature than the one in the bug report, I get: open /dev/sequencer or /dev/snd/seq: No such file or directory open /dev/sequencer or /dev/snd/seq: No such file or directory Fatal Python error: (pygame parachute) Segmentation Fault Aborted Possibly a pygame problem. 446713, 426457 : I cannot reproduce these, I believe they are fixed, but since I couldn't reproduce the originals I cannot be sure. If you believe them to still be a problem, then please reopen them. -- Matthew Johnson signature.asc Description: Digital signature
Bug#516992: whoops, closed the wrong bug
reopen 516992 thanks Damn, Typoed the Closes: line. Reopening 516992, closing 516912 instead. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#517922: splashy: Postinst fails on etch-lenny upgrade
On Tue Mar 03 09:52, Luis Mondesi wrote: Sorry about this. We knew some people will run into weirder scenarios than we could anticipate at the time of the fix. Here is a work around: Sure, I fixed it in the obvious fashion, but I thought you'd probably want to know, or at least it should be mentioned the BTS for anyone else who looks. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#517922: splashy: Postinst fails on etch-lenny upgrade
Package: splashy Version: 0.3.2 Severity: important I'm upgrading etch to lenny. First I get this: Warning: Old themes directory moved to /etc/splashy/themes.old Unpacking replacement splashy ... dpkg: error processing /var/cache/apt/archives/splashy_0.3.13-3_amd64.deb (--unpack): trying to overwrite `/etc/splashy/themes', which is also in package splashy-themes Processing triggers for man-db ... Errors were encountered while processing: /var/cache/apt/archives/splashy_0.3.13-3_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) $ apt-cache policy splashy splashy-themes splashy: Installed: 0.3.2 Candidate: 0.3.13-3 Version table: 0.3.13-3 0 500 http://ftp.uk.debian.org lenny/main Packages *** 0.3.2 0 100 /var/lib/dpkg/status splashy-themes: Installed: 0.4 Candidate: 0.4 Version table: *** 0.4 0 500 http://ftp.uk.debian.org lenny/main Packages 100 /var/lib/dpkg/status Then, if I re-run apt-get dist-upgrade I get: Preparing to replace splashy 0.3.2 (using .../splashy_0.3.13-3_amd64.deb) ... /etc/splashy/themes.old already exist, please remove this directory or file dpkg: error processing /var/cache/apt/archives/splashy_0.3.13-3_amd64.deb (--unpack): subprocess pre-installation script returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/splashy_0.3.13-3_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Then, if I rm -rf /etc/splashy/themes.old I get: mv: cannot stat `/etc/splashy/themes': No such file or directory dpkg: error processing /var/cache/apt/archives/splashy_0.3.13-3_amd64.deb (--unpack): subprocess pre-installation script returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/splashy_0.3.13-3_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Aside from the conflict (which isn't great), it should definitely behave well with different combinations of /etc/splashy/themes* existing or not. -r System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.20-rc6-mm3 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages splashy depends on: ii libc6 2.7-18GNU C Library: Shared libraries ii libglib2.0-0 2.16.6-1 The GLib library of C routines ii libmagic1 4.26-1File type determination library us ii libsplashy00.3.2 Library to draw splash screen on b ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages splashy recommends: ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip Versions of packages splashy suggests: ii initramfs-tools 0.92o tools for generating an initramfs ii splashy-themes0.4A complete user-space boot splash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516912: Please upgrade to fretsonfire 1.3.110
On Wed Feb 25 00:00, Hew McLachlan wrote: Package: fretsonfire Severity: wishlist Please upgrade to fretsonfire 1.3.110 Changelog: http://fretsonfire.svn.sourceforge.net/viewvc/fretsonfire/trunk/changelog.txt Source: http://downloads.sourceforge.net/fretsonfire/FretsOnFire-1.3.110.tar.gz I'm looking at it now Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#516654: default-jdk: Fails to provide java command
On Sun Feb 22 23:28, Axel K. Stammler wrote: This package's name sounds as if it would provide the default Debian Java development kit, but that's exactly what the package doesn't do. In fact, I find it difficult to use aptitude search java or anything similar to find out which package to install to be able to do Are you sure it does not? I mean, the default-jdk package it self doesn't but it depends on a whole bunch of packages which eventually do. Here I have: Package: default-jdk Depends: default-jre (= 1.5-30), java-gcj-compat-dev (= 1.0.77-4) Package: default-jre Depends: default-jre-headless (= 1.5-30), java-gcj-compat (= 1.0.77-4) Package: default-jre-headless Depends: java-common, java-gcj-compat-headless (= 1.0.77-4) and then: $ dpkg -L java-gcj-compat-headless | grep bin/java$ /usr/lib/jvm/java-1.5.0-gcj-4.3-1.5.0.0/bin/java /usr/lib/jvm/java-1.5.0-gcj-4.3-1.5.0.0/jre/bin/java which it adds as alternatives for /usr/bin/java (among others) in its postinst. So unless something weird has happened, apt-get install default-jdk should really have left you with a /usr/bin/java Can you check for me that you have java-gcj-compat-headless installed, it contains those files and that /usr/bin/java and /etc/alternatives/java exist and look sane? the output of update-alternatives --list java would also be useful. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#513675: lirc: manual page beautification
tag 513675 pending thanks On Sat Jan 31 10:09, Philipp Matthias Hahn wrote: debian/patches/04_man_pages is missing the conversion for --allow-simulate, I have included the full patch instead of giving a patch to a patch: I've also attached my debian/patches/22_man_pages2 patch which - formats references to programs in bold - formats references to files in italic - formats references to option-names in bold - formats references to manual-pages in bold(roman). Thanks, I've applied the patches to svn. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#510590: javahelper: missing jar error
On Sat Jan 03 14:30, Johan Henriksson wrote: maho...@eros:~/javaproj/ev$ java-propose-classpath startImServ.jar java.io.FileNotFoundException: /usr/share/java/ant-bootstrap.jar (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:137) at java.io.FileInputStream.init(FileInputStream.java:96) at sun.tools.jar.Main.run(Main.java:223) at sun.tools.jar.Main.main(Main.java:1044) if this is not a bug then it needs an explanatory message Hmm, that's very odd. It _looks_ like the loop which iterates over /usr/share/java and lists them can't open one of the files. Can you tell mee if /usr/share/java/ant-bootstrap.jar is a broken symlink? If not, can you run: bash -x java-propose-classpath startImServ.jar? and send me the output? Thanks. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#65285: wontfix?
On Tue Feb 17 11:44, Marian Such wrote: Do you mind if I ask why this was tagged WONTFIX without any comment? Well, I must confess I have no idea, since I adopted this package last year and the bug was tagged wontfix in 2004. I've CC'd Phil (the previous maintainer) to see if he wishes to shed any light on the matter Is it still an issue? Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#506131: Hm
On Mon Feb 09 15:02, Peter Rabbitson wrote: Interesting... Never actually heard of this before, but you are right indeed. Ok then comes the question - may we have the deb file by some alternative means? Either experimental or a manual download... We certainly could, however... Unless the unfreeze is indeed around the corner (unlikely with debian :) Ask me that again on Saturday (-; Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#469397: ITP: xbmc -- XBox Media Center Linux Port
On Sat Jan 10 13:34, Andres Mejia wrote: Hello, Were you still going to create Debian packages for xbmc? If not, I'll be willing to take over this ITP. I'm already working with upstream in getting xbmc in a state where packages can be uploaded to Debian. In fact, I'm a part of their team and have direct commit access to their SVN. By all means take it over. Last time I looked it was in no means suitable for uploading. If you can change this, then go ahead. If you can also fix all the obvious segfaults, even better (- Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#510636: libosso: Has a dbus config file which circumvents all security messages on the system bus
On Sun Jan 04 16:37, Riku Voipio wrote: On Sat, Jan 03, 2009 at 10:53:08PM +, Matthew Johnson wrote: libosso1 ships /etc/dbus-1/system.d/libosso.conf which turns off all the security checks on the system bus by allowing all messages from everyone to everyone else. This is bad mkay? I believe this kind of open dbus communication is not needed by any of the maemo apps in debian, so we can just drop the conffile. You will also need to ensure that they all have the appropriate config file to work with the fixed version of DBus (either try the one in experimental which has this fix or we will soon make available the version which will be uploaded to unstable/testing). Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#510698: odccm: DBus config file doesn't list all neccessary rules and will be broken by the fix for 503532
Package: odccm Version: 0.11.1-2 Severity: serious Justification: Blocks the fix for CVE-2008-4311 The config file doesn't allow introspection, which is not enabled by default, it was only working because off a bug in dbus. It's recommended that you use send_destination to allow all messages to your service. In addition, you should not use send_interface without send_destination. It's likely that all these rules could just be collapsed to one send_destination rule to solve both problems. This is a blocker for the CVE, so please fix quickly. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510636: libosso: Has a dbus config file which circumvents all security messages on the system bus
On Sun Jan 04 13:40, Thijs Kinkhorst wrote: Hi, Matthew, Tags: security libosso1 ships /etc/dbus-1/system.d/libosso.conf which turns off all the security checks on the system bus by allowing all messages from everyone to everyone else. This is bad mkay? As I understand it, Maemo is a kind of handheld device platform. I do not understand yet how this would be a security issue on such a device, can you clarify? Well, it's in Debian main, so anyone can install it and if they do so all security is instantly disabled on the system bus. It's not something which should be encouraged, even on a handheld device. Anyway, there's no reason to do that since people should just write the correct rules anyway. I'm told that Maemo has two users anyway, root and user. This will break any separation between them on the system bus. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#510709: smart-notifier: DBus configuration file doesn't allow introspection and will be broken by the fix to 503532
Package: smart-notifier Version: 0.28-1 Severity: serious Justification: blocks fix for CVE-2008-4311 smart-notifier should explicitly allow introspection in it's config file. It's recommended to use send_destination= to allow all messages of any type to your service. In addition you should not use send_interface without send_destination. Having a single send_destination rule will solve both these issues. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508032: DBus plan for Lenny
Hi guys, I'm looking to come up with a plan for DBus in Lenny. The relevant bug is #508032. A quick synopsis of the problem is that until recently DBus was shipped with a default configuration on the system bus which allowed more message than was intended. 1.2.10 fixes this but unfortunately it breaks numerous other bits of software which relied on this (mainly introspection). There is also a 'permissive' release which merely logs when there would be a problem but still lets them through. It does not actually fix the problem, however. If we do want to fix the problem properly then all the packages which rely on the broken behaviour will also need to be fixed. This should be as simple as just adding a few lines to their system bus config files. I've attached a list of packages which would be affected. The shorter list (*-files*, also has a list of versions in lenny and sid and migration excuses. Sorry if there's a better way to do that than I've found!) is those packages which already drop a file in /etc/dbus-1/system.d, which should be everything. There is a small possibility that there is a package which does not currently have a config file but which should. The longer list is rdepends of libdbus-1-3, it will definitely not be anything not on this list. Opinions? Matt -- Matthew Johnson Masayuki Hatta (mhatta) mha...@debian.org cups (U) Moray Allan mo...@debian.org gpe-bluetooth (U) Michael Biebl bi...@debian.org consolekit (U) dhcdbd (U) hal (U) knetworkmanager network-manager (U) network-manager-applet (U) policykit (U) powersave Julien BLACHE jbla...@debian.org pommed Phil Blundell p...@debian.org gpe-bluetooth (U) Debian Bluetooth Maintainers pkg-bluetooth-maintain...@lists.alioth.debian.org bluez-utils Debian CUPS Maintainers pkg-cups-de...@lists.alioth.debian.org cups Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org system-config-printer (U) system-tools-backends (U) Debian GPE team pkg-gpe-maintain...@lists.alioth.debian.org gpe-bluetooth (U) Debian Maemo Maintainers pkg-maemo-maintain...@lists.alioth.debian.org libosso osso-gwconnect Debian OLPC debian-olpc-de...@lists.alioth.debian.org sugar Debian VoIP Team pkg-voip-maintain...@lists.alioth.debian.org mumble Debian/Ubuntu wpasupplicant Maintainers pkg-wpa-de...@lists.alioth.debian.org wpasupplicant Sebastian Dröge sl...@debian.org avahi (U) hal (U) Edd Dumbill e...@debian.org bluez-utils (U) Filippo Giunchedi fili...@debian.org bluez-utils (U) Soren Hansen so...@ubuntu.com network-manager-openvpn network-manager-vpnc Mario Iseli ma...@debian.org bluez-utils (U) Matthew Johnson mj...@debian.org bluemon Simon Kelley si...@thekelleys.org.uk dnsmasq Anand Kumria wildf...@progsoc.org yum Jonny Lamb jonnyl...@jonnylamb.com libosso (U) odccm osso-gwconnect (U) Roger Leigh rle...@debian.org cups (U) Jeff Licquia licq...@debian.org cups (U) Patrick Matthäi patrick.matth...@web.de mumble (U) Kyle McMartin k...@debian.org wpasupplicant (U) Loic Minier l...@dooz.org avahi (U) libosso (U) osso-gwconnect (U) system-tools-backends (U) Kel Modderman k...@otaku42.de wpasupplicant (U) Josselin Mouette j...@debian.org system-config-printer (U) system-tools-backends (U) Kenshi Muto km...@debian.org cups (U) Thorvald Natvig sli...@users.sourceforge.net mumble (U) Patrick Patterson ppatt...@debian.org pathfinder Martin Pitt mp...@debian.org cups (U) Martin-Éric Racine q-f...@iki.fi cups (U) Andres Salomon dilin...@debian.org yum (U) Otavio Salvador ota...@debian.org system-config-printer system-tools-backends (U) Niv Sardi xa...@debian.org system-tools-backends (U) Riccardo Setti gisk...@debian.org galago-daemon network-manager (U) Riccardo Setti gisk...@autistici.org dhcdbd (U) Sjoerd Simons sjo...@debian.org avahi (U) dhcdbd (U) hal (U) Jonas Smedegaard d...@jones.dk sugar (U) Jose Carlos Garcia Sogo js...@debian.org system-tools-backends Brian Sutherland ji...@web.de smart-notifier Philippe De Swert philippedesw...@scarlet.be gpe-bluetooth (U) Reinhard Tartler siret...@tauware.de wpasupplicant (U) Enrico Tassi gareuselesi...@debian.org network-manager-pptp Utopia Maintenance Team pkg-utopia-maintain...@lists.alioth.debian.org avahi consolekit dhcdbd hal network-manager network-manager-applet policykit Riku Voipio riku.voi...@iki.fi libosso (U) osso-gwconnect (U) Matthew Wilcox wi...@debian.org kerneloops Neil Williams codeh...@debian.org gpe-bluetooth trying to update avahi from 0.6.22-3 to 0.6.23-3 avahi is not yet built on alpha: 0.6.23-2 vs 0.6.23-3 (missing 27 binaries) avahi is waiting for libdaemon libdaemon is in freeze; contact debian-release if update is needed avahi is in freeze; contact debian-release if update is needed info: avahi has
Bug#510432: imapproxy
We are BSPing in Cambridge this weekend, if you need this uploaded, let me know Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#510432: imapproxy
On Sat Jan 03 14:08, Matthew Johnson wrote: We are BSPing in Cambridge this weekend, if you need this uploaded, let me know Hmm... I sent this because bts.turmzimmer says: 10-Mar-2007: ifvoid: maintainer waiting for sponsor However, since the bug was added on 1st jan this seems unlikely (-: Do ignore (-: Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#510628: bluemon: DBus config doesn't allow Introspection
Package: bluemon Version: 1.4-3 Severity: normal The fix to #503532 which is required for Lenny will also break this. Upload coming shortly to fix -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510633: powersaved: Doesn't enable introspection in dbus config file
Package: powersaved Version: 0.15.20-3 Severity: serious The fix for #503532 means that powersaved will stop responding to introspection because it is not allowed in the config file. There may be other problems which I haven't checked yet, but this bug definitely needs to be fixed. Anyone fixing this should check that all methods which should be allowed are allowed in the configuration. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510634: cups doesn't allow introspection in dbus config file
Package: cups Version: 1.3.8-1lenny4 Severity: normal The cups config file for dbus doesn't allow introspection requests. Because all it does is send signals this isn't an RC issue, but it should have working introspection for those signals. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510636: libosso: Has a dbus config file which circumvents all security messages on the system bus
Package: libosso Version: 2.15.debian.1-1 Severity: grave Tags: security libosso1 ships /etc/dbus-1/system.d/libosso.conf which turns off all the security checks on the system bus by allowing all messages from everyone to everyone else. This is bad mkay? -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510636: libosso: Has a dbus config file which circumvents all security messages on the system bus
This looks like a candidate for removing from Lenny along with the rdeps, there's been several people involved in Maemo who think that it's probably not ready for Debian yet. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#448404: libpam-paperauth
I'd be interested to know what advantages this has over libpam-otpw (which was designed by Markus Khun who has a rather less dubious reputation in the security community than Gibson does) Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#484560: Please check 1.8.9-2
Hi, I've just been reviewing the ipmitool bugs list and no one has verified whether this is still an issue in 1.8.9. On inspection of the code you patch appears to already be applied, so I assume it's already been fixed. Could you check for me when you have the time and let me know. Thanks, Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#509237: /var/lib/initramfs-tools
(background, Manoj asked for opinions on #debian) I think I agree that the stuff under /var/lib/initramfs-tools is internal state specific to initramfs-tools and should be purged by initramfs-tools. (as distinct from the initrd itself, which is what the user/linux-image/kernel-package asked to be created). Since it can be reproduced without kernel-package (using debian images or make; make install) it's definitely not filed against the right package atm. I'd have expected downgrading to minor and reassigning it back to initramfs-tools, but I'll leave that to the maintainers to sort out. Some snipped from IRC when we were discussing it: 17:24 mjj29 I think minor against initramfs-tools seems reasonable 17:25 Manoj now, arguably, if the liunx-image runs update-initramfs on install, it should run it again on removal, but that is a separate bug 17:25 mjj29 the initramfs doesn't belong to initramfs-tools -- but the sha1sum does, and the initramfs won't stop working if it's removed 17:25 mjj29 initramfs-tools might just get a little confused, but that's fine 17:26 mjj29 install initramfs-tools; install linux-image-foo; purge initramfs-tools; install initramfs-tools 17:26 mjj29 should leave you in the same situation as 17:26 mjj29 install linux-image-foo; install initramfs-tools -- Matthew Johnson signature.asc Description: Digital signature
Bug#456037: Fenix: not 64 bit clean, should it be out of Lenny?
On Sat Dec 13 05:07, Miriam Ruiz wrote: Fenix isn't in Etch. Dropping it from Lenny would remove a game, and a related framework (this seems to be the complete list): Unless we find a way to make it work in 64 bits, either we reduce the arch to i386 only -which is something I don't like doing at all-, or we remove it from Lenny. I'm not exactly sure that the code is of a very high quality. It's a pity for pixfrogger, but maybe porting it to python or C++ would be easier than to fix Fenix XD Well, restricting it to all the 32bit archs, presumably. I don't think that's necessarily a problem given it's not been released on other archs yet, so it's not a regression. I definitely think that at this point the options are 'drop completely' and 'drop from 64bit archs' and the latter is clearly preferable (of course if people think it's just generally bad, then dropping completely is reasonable) I assume this has been forwarded upstream? Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#508511: ITP: maven-debian-helper -- Helper tools for
On Thu Dec 11 22:57, Torsten Werner wrote: Description : Helper tools for building Debian packages with Maven . This package makes it possible to use Maven for building Debian packages. Hi Torsten, I'd really like to integrate Maven support into Javahelper properly. How best can these two packages integrate? Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#507760: Regression: no longer reports some sdr/Temperatures
On Thu Dec 04 11:58, Cyril Brulebois wrote: Cyril Brulebois [EMAIL PROTECTED] (04/12/2008): I might have a look at the history between both versions to see what caused this. Bleh, huge diff. :) Anyway, first guess was correct, the following (source) debdiff allows me to get the same results as with 1.8.8-3. I'll leave it to you to ask upstream why/whether that code deletion was on purpose/needed for some reasons. :) Can you try http://mjj29.matthew.ath.cx/ipmitool_1.8.9-3_i386.changes I'll upload soon Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#507003: initiatorname.iscsi should maybe not be in /etc
On Tue Dec 02 22:04, Peter Palfrader wrote: On Sun, 30 Nov 2008, Matthew Johnson wrote: Hi, I have what I think is a patch which will move it to /var/lib/open-iscsi/initiatorname.iscsi (attached). I could NMU it (and I have a source package prepared), but I'd like some confirmation (I don't have appropriate hardware) that it DTRT first. I think this patch is broken. While it moves the file around it doesn't actually make any of the iscsi things use the new location. it changes the init script which passes it on the command line. The changelog suggests this is how it was moved from /etc/initiatorname.iscsi to /etc/iscsi/initiatorname.iscsi I'd rather this bug get a lenny-ignore tag and is properly fixed without the danger of breakage for the next release. That too Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#507003: initiatorname.iscsi should maybe not be in /etc
On Tue Dec 02 23:47, Peter Palfrader wrote: On Tue, 02 Dec 2008, Matthew Johnson wrote: On Tue Dec 02 22:04, Peter Palfrader wrote: On Sun, 30 Nov 2008, Matthew Johnson wrote: Hi, I have what I think is a patch which will move it to /var/lib/open-iscsi/initiatorname.iscsi (attached). I could NMU it (and I have a source package prepared), but I'd like some confirmation (I don't have appropriate hardware) that it DTRT first. I think this patch is broken. While it moves the file around it doesn't actually make any of the iscsi things use the new location. it changes the init script which passes it on the command line. The Where? looking at the source the path seems to be a compile time default. Yeah, but a default for the command line argument: usr/iscsid.c:77 -i, --initiatorname=[path] read initiatorname from file (INITIATOR_NAME_FILE ).\n\ :334 char *initiatorname_file = INITIATOR_NAME_FILE; :359 initiatorname_file = optarg; However, you are absolutely right that while the init script faffs around a lot with the file, it doesn't actually pass it to anything. However, with my patch it would end up in the initramfs in the right place. Anyway, lenny-ignore would be even less work for me (-: Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#506631: gpg-agent problems in enigmail
I'd be interested in knowing what caused that line to be added to gpg.conf, since I've only ever seen gpg-agent used with environment variables. I think the bug here is the non-functioning 'use gpg-agent' tickbox, which is not RC. If a package automatically updates gpg.conf and then leaves it in a non-functioning state, that's a potentially RC issue. In which case this bug should be cloned and the new one left at RC and this one downgraded. I'll have a little look myself, but any other confirmation of how that setting was created would be good. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#478717: could be closed?
Since this seems to be a kernel issue on hppa surely the ruby part of the bug report can be closed? Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#507003: initiatorname.iscsi should maybe not be in /etc
tag 507003 patch thanks Hi, I have what I think is a patch which will move it to /var/lib/open-iscsi/initiatorname.iscsi (attached). I could NMU it (and I have a source package prepared), but I'd like some confirmation (I don't have appropriate hardware) that it DTRT first. Matt -- Matthew Johnson diff -urN open-iscsi-2.0.870~rc3/debian/changelog open-iscsi-debian/changelog --- open-iscsi-2.0.870~rc3/debian/changelog 2008-11-30 18:06:46.0 + +++ open-iscsi-debian/changelog 2008-11-30 18:15:38.0 + @@ -1,3 +1,11 @@ +open-iscsi (2.0.870~rc3-0.4) unstable; urgency=medium + + * Non-maintainer upload. + * Use /var/lib/open-iscsi/initiatorname.iscsi rather than +/etc/iscsi/initiatorname.iscsi (Closes: #507003) + + -- Matthew Johnson [EMAIL PROTECTED] Sun, 30 Nov 2008 18:10:41 + + open-iscsi (2.0.870~rc3-0.3) unstable; urgency=low * Non-maintainer upload. diff -urN open-iscsi-2.0.870~rc3/debian/extra/initramfs.hook open-iscsi-debian/extra/initramfs.hook --- open-iscsi-2.0.870~rc3/debian/extra/initramfs.hook 2008-11-30 18:06:46.0 + +++ open-iscsi-debian/extra/initramfs.hook 2008-11-30 18:15:38.0 + @@ -23,7 +23,7 @@ . /usr/share/initramfs-tools/hook-functions copy_exec /usr/sbin/iscsistart /sbin -cp /etc/iscsi/initiatorname.iscsi $DESTDIR/etc +cp /var/lib/open-iscsi/initiatorname.iscsi $DESTDIR/etc cp /etc/iscsi/iscsi.initramfs $DESTDIR/etc for x in crc32c libcrc32c iscsi_tcp libiscsi scsi_transport_iscsi; do diff -urN open-iscsi-2.0.870~rc3/debian/open-iscsi.init open-iscsi-debian/open-iscsi.init --- open-iscsi-2.0.870~rc3/debian/open-iscsi.init 2008-11-30 18:06:46.0 + +++ open-iscsi-debian/open-iscsi.init 2008-11-30 18:15:38.0 + @@ -12,7 +12,7 @@ DAEMON=/usr/sbin/iscsid ADM=/usr/bin/iscsiadm PIDFILE=/var/run/iscsid.pid -NAMEFILE=/etc/iscsi/initiatorname.iscsi +NAMEFILE=/var/lib/open-iscsi/initiatorname.iscsi [ -x $DAEMON ] || exit 0 diff -urN open-iscsi-2.0.870~rc3/debian/open-iscsi.postinst open-iscsi-debian/open-iscsi.postinst --- open-iscsi-2.0.870~rc3/debian/open-iscsi.postinst 2008-11-30 18:06:46.0 + +++ open-iscsi-debian/open-iscsi.postinst 2008-11-30 18:15:38.0 + @@ -15,10 +15,15 @@ # But only if configuration in /etc/iscsi is untouched if [ -f /etc/initiatorname.iscsi ] ; then -if grep -q ^GenerateName=yes /etc/iscsi/initiatorname.iscsi ; then -mv /etc/initiatorname.iscsi /etc/iscsi/initiatorname.iscsi - chmod 600 /etc/iscsi/initiatorname.iscsi +if grep -q ^GenerateName=yes /var/lib/open-iscsi/initiatorname.iscsi ; then +mv /etc/initiatorname.iscsi /var/lib/open-iscsi/initiatorname.iscsi + chmod 600 /var/lib/open-iscsi/initiatorname.iscsi fi + +if [ -f /etc/iscsi/initiatorname.iscsi ] ; then +if grep -q ^GenerateName=yes /var/lib/open-iscsi/initiatorname.iscsi ; then +mv /etc/iscsi/initiatorname.iscsi /var/lib/open-iscsi/initiatorname.iscsi + chmod 600 /var/lib/open-iscsi/initiatorname.iscsi fi if [ -d /var/lib/open-iscsi ]; then diff -urN open-iscsi-2.0.870~rc3/debian/rules open-iscsi-debian/rules --- open-iscsi-2.0.870~rc3/debian/rules 2008-11-30 18:06:46.0 + +++ open-iscsi-debian/rules 2008-11-30 18:15:38.0 + @@ -114,7 +114,7 @@ install -m 755 usr/iscsistart $(CURDIR)/debian/open-iscsi/usr/sbin install -m 755 utils/iscsi_discovery $(CURDIR)/debian/open-iscsi/usr/sbin install -m 755 utils/iscsi-iname $(CURDIR)/debian/open-iscsi/usr/sbin - install -m 644 debian/initiatorname.iscsi $(CURDIR)/debian/open-iscsi/etc/iscsi/initiatorname.iscsi + install -m 644 debian/initiatorname.iscsi $(CURDIR)/debian/open-iscsi/var/lib/open-iscsi/initiatorname.iscsi install -m 644 etc/iscsid.conf $(CURDIR)/debian/open-iscsi/etc/iscsi # initramfs stuff signature.asc Description: Digital signature
Bug#506631: gpg-agent problems in enigmail
On Sun Nov 30 17:12, Matthew Johnson wrote: I'd be interested in knowing what caused that line to be added to gpg.conf, since I've only ever seen gpg-agent used with environment variables. If a package automatically updates gpg.conf and then leaves it in a non-functioning state, that's a potentially RC issue. In which case this bug should be cloned and the new one left at RC and this one downgraded. OK, it looks like seahorse (in Etch) munges gpg-agent-info setting in gpg.conf. I _think_ it's meant to remove it on exit, but obviously if it's been killed (or the machine crashed) and then not restarted before upgrade, this will be left in the user's gpg.conf. The version of seahorse in Lenny doesn't seem to do this, but I'm really not sure what to do about these left over values. Seahorse in Lenny could be made to remove them when started as that user, but this doesn't solve the problem of people changing to other gpg agents. I've CC'd the seahorse maintainers for input. I'd reassign it to seahorse, but I'm not sure on the severity or even which version should have the bug assigned to it. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#506266: www.debian.org: links to devref from manuals page broken (404)
Package: www.debian.org Severity: normal http://www.debian.org/doc/devel-manuals#devref has links to the devref, none of which work. For exampple: http://www.debian.org/doc/manuals/developers-reference/index.en.html when it should be: http://www.debian.org/doc/manuals/developers-reference/ (or a number of other URIs) Matt -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503890: Proposed fix for 503890
tag 503890 pending thanks Hi Richard, thanks for the bug report. I'm currently preparing a 0.17 release of javatools which should hopefully fix this bug. Given we are so close to the release I will just upload, if you can have a look while it's waiting to migrate to testing and confirm that jh_manifest and jh_depends (which I assume you meant, rather than jh_installlibs, which doesn't touch the manifest file) do the right thing, that would be great. Thanks, Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#503781: dbus-java: java bytecode / java runtime version
close 503781
thanks
On Tue Oct 28 09:26, Matthias Klose wrote:
Package: dbus-java
Version: 2.5-4
Severity: serious
User: [EMAIL PROTECTED]
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
Yes, and it depends on only openjdk-6-jre.
First of all, thanks for introducing a java-runtime6 virtual package. I
should add this automatic detection to jh_depends to produce an
appropriate alternate depends.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
Or if an appropriate depends already exists. Please take care not to
have false positives when filing RC-severity bugs this close to a
release (or at all).
Thanks,
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
