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#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#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-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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#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-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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#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#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#500440: ITP: fcoretools -- Tools for examining and hinting the IO scheduler
Package: wnpp Severity: wishlist Owner: Matthew Johnson [EMAIL PROTECTED] X-Debbugs-CC: [EMAIL PROTECTED] Source package: fcoretools Binary package(s): fcoretools Version: 1.0-1 Licence: GPLv2 Author: Dave Plonka [EMAIL PROTECTED] Homepage: http://net.doit.wisc.edu/~plonka/packages.html This package provides two tools for manipulating the IO scheduler: fincore is a command that shows which pages (blocks) of a file are in core memory. It is particularly useful for determining the contents of the buffer-cache. fadvise is a command used to give file advisory information to the operating system. Its --dontneed option is particularly useful in that it causes the files' pages (blocks) to be evicted from the buffer-cache. -- Matthew Johnson signature.asc Description: Digital signature
Bug#443212: ITP: freeipmi -- a free implementation of the ipmi standard
On Sat Sep 13 18:27, Aníbal Monsalve Salazar wrote: Jean Parpaillon packaged version 0.6.5-1. Would you allow him to take over this ITP? I seem to have lost some discussion I remember having about this, but sure, go ahead. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#435702: x2x debian package
On Sat Aug 23 12:01, Ralf Treinen wrote: you announced on Dec 13, 2007, interest to adopt the x2x package. Are you still intending to do so? There are quite some open bugs against x2x that would require a caring maintainer. I could easily do a QA upload for #485530 but it would obviously be better if someone who uses that package adopts it. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274451 Hi, I've had a look over the outstanding bugs and while I do use x2x occasionally, I don't think there's many I could fix. The new upstream release looks flakey too. So I don't think I'd be able to do much if I did adopt. That FTBFS claims to be a post-lenny problem, so there's no rush, but feel free to do a QA upload now anyway. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#491805: RFS: sqlline
On Sun Aug 17 17:42, Cyril Brulebois wrote: Damien Raude-Morvan [EMAIL PROTECTED] (13/08/2008): Cyril, did you have time to sponsor this package (if it's ok for you, of course)? Here are some comments: - I assume libjline-java will pull the needed java machinery so you don't have to depend on a java runtime environment; is that correct? Java library packages don't depend on JREs, Java applications that use them. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#491626: RFS : Mina
On Sat Aug 02 01:30, Damien Raude-Morvan wrote: - changelog: since it's not been uploaded to Debian yet, can you combine the changelog entries into just one. Pretty much changelog entries should correspond to uploads (and obviously the debian revision will be 1) It has been uploaded to my personnal debian repository and maybe (and _had been_, regarding Apache and FTP logs) installed by some debian users. Using -1 for first Debian upload don't seems enforced by debian-policy and I prefer keeping history of want has been uploaded to mentors and to my personnal repository. Did you agree with that ? Sure, in that case it's fine, but the -3 is the one which closes the ITP bug (-: I've upload a new version on m.d.o : http://mentors.debian.net/debian/pool/main/m/mina/ Everything else is fine, I'll upload it once you move the Closes: up to the most recent entry Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#491626: RFS : Mina
On Tue Jul 29 19:29, Damien Raude-Morvan wrote: I would be glad if someone uploaded this package for me. Hi Damian, I've had a look over your package and may be able to sponsor it. I have a few comments first though, and I agree with the comments on short descriptions. - changelog: since it's not been uploaded to Debian yet, can you combine the changelog entries into just one. Pretty much changelog entries should correspond to uploads (and obviously the debian revision will be 1) - Licence for the packaging: you say it is licenced under the 'GPL'. You should give the version of the GPL and note that the Apache licence is not compatible with the GPLv2[0]. In general it is recommended for packaging to be the same licence as the package, or a permissive one such as BSD or X11/expat. - .vsd files: There seem to be a number of files under core/src/doc which file(1) claims are Microsoft office documents. Are these used for anything? Given you are stripping the tarball anyway you could probably remove them? - Other licence files: I assume these apply to the jars you stripped out? It's not required, but it might be nice to strip them too to avoid confusion as to why they aren't in debian/copyright I've also had a look at sqlline: - if (as README.Debian suggests) it is only useful with a jdbc driver it should probably depend (or at the very least recommend) a jdbc driver. I'd Depend on all of them as alternatives (those that are packaged). - debian/copyright claims BSD licence, but the LICENSE in the tarball says GPLv2, which is it? Both packages build and are lintian/pbuilder clean though, which is good. Matt 0. http://www.fsf.org/licensing/licenses/ -- Matthew Johnson signature.asc Description: Digital signature
Bug#238904: RFS: commons-vfs
On Mon Jul 21 00:57, Damien Raude-Morvan wrote: I've just uploaded a new version to mentors.debian.net, you should dget that. Looks good, I've uploaded Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#238904: RFS: commons-vfs
On Sun Jul 20 01:09, Damien Raude-Morvan wrote: Dear mentors, I am looking for a sponsor for my package commons-vfs. Hi Damian, I will be happy to upload your package, which is in pretty good shape. There are two things I need you to fix first though. Your debian/changelog targets UNRELEASED at the moment. If you would like me to upload it, please change this to unstable. Secondly, you have: Package: libcommons-vfs-java Section: devel Please change this to Section: libs. Other than that, it is in good shape and I will be happy to upload Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#489587: ITP: python-scriptutil -- Python module which provides the functionality of find and grep
Package: wnpp Severity: wishlist Owner: Matthew Johnson [EMAIL PROTECTED] X-Debbugs-CC: [EMAIL PROTECTED] Source package: python-scriptutil Binary package(s): python-scriptutil Version: 1 Licence: BSD Author: Muharem Hrnjadovic Homepage: http://hrnjad.net/src/7/scriptutil.py Description: Python module which provides the functionality of find and grep This package contains a python module which provides a recursive find on the filesystem and searching within those files. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418889: xserver-xorg-video-nouveau_0.0.10~git+20080702+48c2116-1_i386.change s ACCEPTED
On Sun Jul 06 21:29, Chris Lamb wrote: I have thus prepared new versions of the packages with correct versioning using new upstream snapshots: http://chris-lamb.co.uk/debian/drm-snapshot_2.3.1%2bgit%2b20080706%2b401f77a-1.dsc http://chris-lamb.co.uk/debian/xserver-xorg-video-nouveau_0.0.10~git%2b20080706%2bb1f3169-1.dsc Uploading as we speak M -- Matthew Johnson signature.asc Description: Digital signature
Bug#418889: Fw: xserver-xorg-video-nouveau_0.0.10~git+20080602+e034616-1_i386.change s REJECTED
On Thu Jul 03 01:54, Chris Lamb wrote: Joerg Jaspert wrote: rejected, there is a license issue to clarify before this can enter main. This is now sorted upstream. I have placed updated packages at: http://chris-lamb.co.uk/debian/xserver-xorg-video-nouveau_0.0.10~git%2b20080702%2b48c2116-1.dsc http://chris-lamb.co.uk/debian/drm-snapshot_2.3.1~git%2b20080703%2b301d984-1.dsc They fix a few other things, including a missing binary dependency on quilt (#487260). I am using these right now, and have tested the migration from the non-free nvidia driver. Uploaded Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#418889: Packaging nouveau
On Fri Jun 06 06:47, Chris Lamb wrote: ssh://[EMAIL PROTECTED]/git/pkg-xorg/lib/drm-snapshot ssh://[EMAIL PROTECTED]/git/pkg-xorg/driver/xserver-xorg-video-nouveau I prefer git+ssh:// They should appear on Gitweb in a few hours. Let me know if I've done anything silly; I'm not used to this particular Git workflow. I get some odd errors: after git clone it prints: Warning: Remote HEAD refers to nonexistent ref, unable to checkout. and doesn't checkout a head. I then have to do: git checkout xserver-xorg-video-nouveau-0.0.10-git+20080602+e034616-1 to get a checkout. git checkout -b master creates a new branch correctly named, I think if someone commits to that it will DTRT, but I could be wrong. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#418889: Packaging nouveau
tag 418889 pending thanks On Mon Jun 02 14:38, Chris Lamb wrote: I forgot to close this ITP bug in xserver-xorg-video-nouveau's changelog; so I have updated both packages. They are both at the same URL. I have uploaded the packages. Next thing to do is install the packaging in the XSF repository, I suppose. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#418889: Packaging nouveau
On Sun Jun 01 04:10, Chris Lamb wrote: Hi Matthew, I can't see anything else obvious, I shall email debian-x and ask whether it should be maintained in the XSF repositories. Excellent; I saw your post and have incorporated the following changes: * Rename source package libdrm-snapshot = drm-snapshot. * Remove X.Org endorsements from xserver-xorg-video-nouveau package description. So as I see it, the two issues that remain are: I had a conversation about this with jcristau on IRC: 21:56 -!- Irssi: Starting query in oftc with jcristau 21:56 jcristau hi 21:57 jcristau one question about the nouveau packages, how do you get your libdrm-snapshot coinstallable with libdrm2? 21:57 mjj29 hi 21:57 mjj29 you don't 21:57 mjj29 I believe 21:57 mjj29 hence the conflicts/replaces/provides 21:58 jcristau then you have a problem 21:58 jcristau because the x server depends on libdrm2 21:58 jcristau i'll reply to the mail 21:58 mjj29 libdrm-snapshot should provide libdrm2 21:58 jcristau that won't help 21:58 mjj29 (it doesn't yet) 21:59 mjj29 because it's versionned? 21:59 jcristau yes 21:59 mjj29 ah, I was wondering if that would be a problem 21:59 mjj29 so, either it needs to be coinstallable, or it just needs to be libdrm2? 21:59 mjj29 would you be happy with the latter solution? 21:59 jcristau yes, see my mail 22:00 jcristau it needs checking that the removed symbols aren't used by anything 22:00 mjj29 cool 22:00 mjj29 we will probably do that then 22:03 jcristau is there a plan to package a mesa snapshot for the dri driver too at some point? 22:03 mjj29 that's for the 3D stuff? 22:03 jcristau yes 22:04 mjj29 upstream don't want 3D to be packaged anywhere yet 22:04 jcristau ok 22:04 mjj29 even in exp. 22:04 jcristau fair enough 22:06 jcristau feel free to ask on the list or #debian-x if you need anything from us 22:06 mjj29 sure 22:07 jcristau oh, and i forgot: your xsfbs copy could be updated :) 22:07 mjj29 ah, thanks So, in summary we want to use libdrm2. Have you looked at the removed symbols thing? 2. Maintainer/Uploaders field = At the very least it should be maintained in a shared VCS and I should be added as an uploader. Agree 100%. As the owner of the ITP, I defer this decision to you. I am perfectly happy with it being in the XSF repositories, but I do not have commit access there. Do you happen to know the procedure for joining? I don't, I'm not a member. I'm happy just to have commit access to a repository on alioth or somewhere else. We could possible coordinate with RAOF and have different branches in the same repository or something. If you want to just setup something, I'll go with whatever. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#418889: Packaging nouveau
On Sat May 31 00:03, Chris Lamb wrote:
Matthew Johnson wrote:
Excellent. I shall have time tonight or over the weekend to review and
upload these, although I will touch base with the XSF before doing so.
Sorry about the short delay.. here we go:
Cool
These are almost certainly not 100% ready-for-upload. I can think of three
issues/topics currently:
* Relationship with libdrm package -- I've gone with creating seperately
named binary packages in the style of libdrm-snapshot{2,-dev}, etc., for
reasons discussed on the debian-x list.
Yup, I agree with this.
However, I seem to have been misinformed about how the
Replaces/Conflicts/Provides trick works (or am doing something silly) as
my attempts to construct a package that can replace the libdrm2 package
whilst still providing it were unsuccessful - attempting to install the
resulting package kept trying to remove X.Org. (Currently, each package
currently just Replaces: its non-snapshot counterpart.)
I believe you need all three. Conflicts causes the other one to be
removed, Provides causes dependencies on all the others to be satisfied.
* The Build-Depends for xserver-xorg-video-nouveau currently contains:
Build-Depends: [...], libdrm-snapshot-dev, [...]
Should this (and/or the linux-nouveau-modules binary dependency) be
versioned to ensure that the X driver and kernel module do not get
horribly out of sync? I would not like to annoy upstream with
unreproducable issues resulting from disparate versions (even if they do
compile).
I agree
* Maintainer/Uploaders field -- this is currently just set to me, *purely*
to keep Lintian happy and to force discussion. If the package is to
maintained in the XSF, this should probably change to:
Maintainer: Debian X Strike Force [EMAIL PROTECTED]
Uploaders: Matthew Johnson [EMAIL PROTECTED], $ME
At the very least it should be maintained in a shared VCS and I should
be added as an uploader.
I can't see anything else obvious, I shall email debian-x and ask
whether it should be maintained in the XSF repositories.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
Bug#418889: Nouveau packaging
Dear X maintainers, I'm considering uploading packages for the Nouveau drivers to experimental. The summary of the discussion is attached to bug #418889. The packages were adapted by Chris Lamb from Christopher Rogers' Ubuntu PPA packages. The current packages are at: http://chris-lamb.co.uk/debian/libdrm-snapshot_2.3.1~git%2b20080530%2b6e8a2cf-1.dsc http://chris-lamb.co.uk/debian/xserver-xorg-video-nouveau_0.0.10~git%2b20080526%2be034616-1.dsc They need Replaces/Conflits/Provides fixing. Would you like this maintained as part of the XSF and do you have any other comments before I upload them? Thanks, Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#418889: Packaging nouveau
On Fri May 30 07:54, Chris Lamb wrote:
Chris Lamb wrote:
I'm would definately like to see these in experimental - it would certainly
ween a large number of my friends from the non-free NVIDIA driver. More
importantly, I'm willing to help out to make this happen.
So what is the next steps?
I have prepared some packages for upload which introduce binary packages
with a libdrm-snapshot{2,-dev,-dbg} naming scheme (the libdrm source package
already uses experimental for its 2.3.0-branch releases). I have been
testing them on my desktop for a few days now with no Debian-specific issues.
All that is missing is a quick copyright check (which I will do later today)
and I will upload somewhere public.
Excellent. I shall have time tonight or over the weekend to review and
upload these, although I will touch base with the XSF before doing so.
Thanks,
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
Bug#418889: Any upload to experimental pending?
On Sat May 10 17:23, Vincent Bernat wrote: Hi Matthew! Is there any upload to experimental pending for nouveau driver? It seems pretty functional now. Not from me, I'm afraid I've never had quite enough time to do so. I was talking to the person who has packaged it in ubuntu, but he thought there would need to be some things done with the XSF to make it work. If it's in an easier to integrate state I can have another look at it Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#480074: ITP: libjna-java -- Dynamically access native libraries from Java without JNI.
On Wed May 07 21:58, Tiago Saboga wrote: * Package name: libjna-java Version : 3.0.2 Upstream Author : Timothy Wal [EMAIL PROTECTED] * URL : http://jna.dev.java.net/ * License : LGPL Programming Lang: C, Java Description : Dynamically access native libraries from Java without JNI. This is just awesome. Let me know if you need a sponsor, I'd be happy to upload Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#478690: ITP: jit -- Just-in-time compilation support for GNU R
On Wed Apr 30 06:54, Dirk Eddelbuettel wrote: * Package name: jit Isn't this a bit generic? would rjit, r-jit or jit-r be better? Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#364606: RFH: lirc -- infra-red remote control support
close 364606 0.8.2-2 thanks Stefan and I have uploaded a new version fixing all of the RC bugs and many of the other ones. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#470621: ITP: nxcl -- NX X compression client library
On Thu Mar 13 10:20, Roberto C. Sánchez wrote: On Thu, Mar 13, 2008 at 03:08:39PM +0100, Michael Biebl wrote: Just curious: One of the major complaints about NX (iirc) and the reason why it wasn't packaged for Debian yet, is that it basically was a fork of the complete Xorg/Xfree86 sources (which understandably didn't make our security team happy). Is nxcl a reimplementation that solves this problem? Does it allow to implement the NX server as an extension for Xorg? Yes. Thay also fork openssh, CUPS and other stuff. The submitter is advised to check the mailing list archives of the pkg-nx group on Alioth. I'm aware of this, however, the cups/X fork is only for the server side. On the client side there is normally an SSH fork involved, but I'm working with the freenx people who have a patch to nxproxy so that it doesn't need nxssh. These ITPs are for an NX client with the above patches so that openssh can be used rather than nxssh. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#470623: ITP: nxproxy -- NX X compression proxy
Package: wnpp Severity: wishlist Owner: Matthew Johnson [EMAIL PROTECTED] X-Debbugs-CC: [EMAIL PROTECTED] Source package: nxproxy Binary package(s): nxproxy Version: 3.1.0-2-1 Licence: GPL Author: NoMachine Homepage: http://www.nomachine.com/ Description: NX X compression library NX provides a differential X compression library for X11. . This package provides the X proxy binary. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470622: ITP: qtnx -- NX client for QT
Package: wnpp Severity: wishlist Owner: Matthew Johnson [EMAIL PROTECTED] X-Debbugs-CC: [EMAIL PROTECTED] Source package: qtnx Binary package(s): qtnx Version: 0.9-1 Licence: GPL Author: Homepage: Description: NX client for QT NX is a differential X compression protocol for X11. . This package provides the QT client. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470624: ITP: nxcomp -- NX X compression library
Package: wnpp Severity: wishlist Owner: Matthew Johnson [EMAIL PROTECTED] X-Debbugs-CC: [EMAIL PROTECTED] Source package: nxcomp Binary package(s): libxcomp3 libxcomp-dev Version: 3.1.0-6-1 Licence: GPL Author: NoMachine Homepage: http://www.nomachine.com/ Description: NX X compression library NX provides a differential X compression library for X11. . This package provides the compression library. Description: NX X compression library---headers NX provides a differential X compression library for X11. . This package provides the compression library headers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470621: ITP: nxcl -- NX X compression client library
Package: wnpp Severity: wishlist Owner: Matthew Johnson [EMAIL PROTECTED] X-Debbugs-CC: [EMAIL PROTECTED] Source package: nxcl Binary package(s): libnxcl1 libnxcl-dev libnxcl-bin Version: 0.9-1 Licence: GPL Author: Seb James [EMAIL PROTECTED] Homepage: http://freenx.berlios.de/ Description: NX X compression client library NX provides a differential X compression system for X11. . This package provides the client library. Description: NX X compression client library---headers NX provides a differential X compression system for X11. . This package provides the client library headers. Description: NX X compression client library---runtime NX provides a differential X compression system for X11. . This package provides the runtime binaries for the nx client libraries. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469397: ITP: xbmc -- XBox Media Center Linux Port
Package: wnpp Severity: wishlist Owner: Matthew Johnson [EMAIL PROTECTED] X-Debbugs-CC: [EMAIL PROTECTED] Source package: xbmc Binary package(s): xbmc Version: 0.0~02032008 Licence: GPLv2 Author: Various Homepage: http://xbmc.org/ Description: XBox Media Center Linux Port A media center originally written for the XBox and then ported to linux. I intend to upload this to experimental to start with. The linux port of it is just that. It's also designed for installation to a single directory, not installation on a unix system. I'll need to hack round that first. The version number is a CVS snapshot. I need to improve the long description before uploading. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466694: ITP: trilead-ssh2 -- Java SSH libarary
Package: wnpp Severity: wishlist Owner: Matthew Johnson [EMAIL PROTECTED] X-Debbugs-CC: [EMAIL PROTECTED] Source package: trilead-ssh2 Binary package(s): libtrilead-ssh2-java Version: 211-1 Licence: BSD Author: Trilead AG Homepage: //www.trilead.com/Products/Trilead-SSH-2-Java/ Description: Java SSH libarary Trilead SSH for Java is a freely available open-source library which implements the SSH-2 protocol in pure Java (tested on J2SE 1.4.2 and 5.0). It allows one to connect to SSH servers from within Java programs. It supports SSH sessions (remote command execution and shell access), local and remote port forwarding, local stream forwarding, X11 forwarding, SCP and SFTP. There are no dependencies on any JCE provider, as all crypto functionality is included. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418889: RFP: nouveau -- an Open Source 3D drivers for nVidia cards
owner 418889 ! thanks There are already packages for Ubuntu available in one of their personal archives for testing. I've contacted the maintainer and we will be working to get them uploaded to experimental. In the mean time you can try the packages available here: https://launchpad.net/~raof/+archive Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#435702: O: x2x -- Link two X displays together, simulating a multiheaded display
I use x2x on occasion and would like to see it maintained. I could adopt it myself, but if Mikhail would like to maintain it, that's even better, and I will happily sponsor. Mikhail: is there a more recent upstream release than the one in Debian? Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#432027: ipmitool
Hi Noah, Are you still interested in ipmitool? We also have some servers on which we use it so I was going to offer to adopt it. I also have been meaning to package freeipmi (http://bugs.debian.org/443212) which in our experiences segfaults in a different set of circumstances (-: Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#364606: RFH: lirc -- Linux Infra-red Remote Control support
Hi, I use lirc, so am very interested in it being maintained. I'll certainly sponsor anything that needs uploading. Perhaps we could be added to the alioth group? Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#428311: Packages awaiting sponsorship (fsvs)
On Sun Dec 09 09:59, Philipp Marek wrote: On Sunday 09 December 2007 Matthew Johnson wrote: Hi, I noticed your RFS and would be happy to sponsor the package. It looks in pretty good shape, I'm just trying it out here. How much do you use it? had any problems? (I have an ulterior motive, I'm wondering about using it in a production system). If that would be considered a Good Thing(TM), I'd like to take the debian/ subdirectory on board, ie. put it along the sources. The vict^H^H^H^Hvolunteer could even have commit access :-) It's usually considered good practice to keep the debian packaging separate from the upstream source; our source distribution provides: - an orig.tar.gz, which is the upstream tarball verbatim (if possible) - a diff.gz which is any debian patches and the contents of the debian/ directory. However, we would certainly like to work closely with you as upstream. Sheldon is the maintainer, so it's up to him where he keeps the debian packaging, if he'd like to keep it in your VCS so you can both work in it, that's absolutely fine, but I'd suggest having it separate to the upstream source, so that both can be released independently. It's nice to have a responsive upstream maintainer (-: Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#428311: Packages awaiting sponsorship (fsvs)
On Sun Dec 09 16:11, Philipp Marek wrote: On Sunday 09 December 2007 Matthew Johnson wrote: However, we would certainly like to work closely with you as upstream. Sheldon is the maintainer, so it's up to him where he keeps the debian packaging, if he'd like to keep it in your VCS so you can both work in it, that's absolutely fine, but I'd suggest having it separate to the upstream source, so that both can be released independently. That I don't understand ... how does the release cycle depend on where the debian data is? Debian releases won't coincide exactly with upstream releases. We need to do integration tests after you release and may well release more frequent debian revisions than upstream releases to either fix bugs ahead of your release cycle or change things which are unrelated to anything outside debian. This is particularly true when fsvs becomes part of a stable debian release. If there are any security or other critical bugs, fixes to these will be backported to the version in stable, we don't use new upstream releases to fix stable. These bugs will be fixed in the debian diff and the upstream tarball will remain the same. This allows us to more easily audit that the changes to the stable distribution are the minimum possible to fix the bug. Even the packages which I am both upstream and maintainer for I keep the upstream sources separate from the debian packaging. What my question aims at: I already have a make-release script; if there'd be something like change version number in debian/... (and/or something else), it would be no more work - and the debian package could be easier kept up-to-date. I'm not averse to something like that (actually you have to add a new changelog entry), but you don't want to have to make a new upstream release every time something changes in the debian packaging, so they would have to be structured in such a way that they are released separately. For reference, we have a lot of tools to make this easier such as svn-buildpackage. This will automatically get the upstream tarball from a different directory and integrate the debian dir in svn with it to create the debian source package and then build it. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#428311: Packages awaiting sponsorship (fsvs)
On Sun Dec 09 16:46, Philipp Marek wrote: On Sunday 09 December 2007 Matthew Johnson wrote: Debian releases won't coincide exactly with upstream releases. ... The only thing I'd ask for would be to take the current version, and the changed description (no longer aims for ... it is, I decided :-) before uploading that in main. Sheldon, if you change the description and check everything still works with 1.1.11, then send me a new source package I'll upload it. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#428311: Packages awaiting sponsorship (fsvs)
On Sun Dec 09 21:39, Sheldon Hearn wrote: On Sunday 09 December 2007 18:41:27 Matthew Johnson wrote: Sheldon, if you change the description and check everything still works with 1.1.11, then send me a new source package I'll upload it. It never rains, it pours. :-) We now have two people offering to sponsor the package: Mario and Matthew. Matthew, Mario had some criticisms for my package, so I've copied you in. I've also copied in the author, who's taken an interest in the effort Well, I don't mind either way who sponsors. Mario's suggestions are all good ones and what I would do in my own packages I just wouldn't necessarily call them show stoppers. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#428311: Packages awaiting sponsorship (fsvs)
Hi, I noticed your RFS and would be happy to sponsor the package. It looks in pretty good shape, I'm just trying it out here. How much do you use it? had any problems? (I have an ulterior motive, I'm wondering about using it in a production system). Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#443212: ITP: freeimpi -- a free implementation of the ipmi standard
Package: WNPP Severity: wishlist Owner: Matthew Johnson [EMAIL PROTECTED] Package name: freeimpi Version : 0.4.4 Upstream Author : Albert Chu [EMAIL PROTECTED] and various others URL or Web page : http://www.gnu.org/software/freeipmi/ Licence : GPLv2 Description : free implementation of the IPMI protocol FreeIPMI provides in-band and out-of-band IPMI software based on the IPMI v1.5/2.0 specification. The software has been written with a number of useful features for large HPC environments. Initial packages for testing can be found at http://mjj29.matthew.ath.cx/debian-upload/freeipmi/ Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#441833: ITP: wound-up -- Puzzle game
Package: wnpp Severity: wishlist * Package name: wound-up Version : 1.0.2 Upstream Author : Adam Biltcliffe, Martin O'Leary, Carrie Oliver, Richard Thomas * URL : http://www.pyweek.org/e/psyduck_revenge/ * License : CCv3.0 by-sa Programming Lang: Python Description : Arcade/Puzzle game involving cogs and elves You embody the racial consciousness of a tribe of elves. It is your charge, your sacred duty to lead your children to a life of safety and prosperity. However, an evil mastermind, by the name of Dr Bucket McEvilpants, with an axe to grind has kidnapped some of your elves and deviously imprisoned them inside his clockwork gumball machines! For the sake of all things you must recover your elf-folk: but your resources are limited, and time is the most precious of them all. I have initial packages at http://mjj29.matthew.ath.cx/debian-upload/wound-up/ Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#432838: ITP: mpdalarm - An alarm clock for MPD
Package: wnpp Severity: wishlist * Package name: mpdalarm Version : 0.1 Upstream Author : [EMAIL PROTECTED] * URL : http://www.matthew.ath.cx/projects/mpdalarm/ * Licence : GPL v2 Description : An alarm clock using MPD MPDAlarm uses at and mpc to control MPD as an alarm clock. Rather than just starting the music at a specified time, however, mpdalarm will gradually fade in the music over a period of time allowing you to wake up more naturally. It also supports fading out slowly as you go to sleep. -- Matthew Johnson signature.asc Description: Digital signature
Bug#432838: (no subject)
tag 413405 + pending tag 432838 + pending thanks I have built the packages for mpdalarm and will upload them once DAM creates my account. Until then they are available at http://mjj29.matthew.ath.cx/debian-upload/mpdalarm/ Matt -- Matthew Johnson -- Matthew Johnson signature.asc Description: Digital signature
Bug#382568: ITP: classpath-generics -- Experimental Java 5 runtime libraries
noowner retitle 382568 RFP: classpath-generics -- Experimental Java 5 runtime libraries thanks As of 0.95 (which is not yet in Debian, so I've not closed this bug yet) generics are the default. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#383316: Final Packages?
On Sun May 13 01:40, Miriam Ruiz wrote: My suggestion about the dependencies: I don't like the core game depending on the song packages, we could make a virtual package called fretsonfire that depended on everything we want for a newbie player, like kde or gnome packages, and have a package with just the game so that the user is not forced to have the songs if they don't want to? The other option would be to add a recommends for all the song packages we keep on doing. I've just rebuilt the packages and updated svn to match so that we now have: fretsonfire - empty metapackage depending on fretsonfire-game and fretsonfire-songs-sectoid fretsonfire-game - the package formerly known as fretsonfire; recommends fretsonfire-songs-sectoid fretsonfire-songs-sectoid - the songs package; depends on fretsonfire-game So, if you apt-get install fretsonfire you get a working setup with songs. You can alternatively just install fretsonfire-game if you don't want the songs. svn is up to date both with working get-orig-source targets which rebuild the tarballs appropriately. Since I'm removing one of the songs from the songs package (as per debian-legal), both have .dfsg version numbers. Signed packages and source are at http://mjj29.matthew.ath.cx/debian-upload/fretsonfire/ or they can be built from svn. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#383316: Could you please forward this proposed license to Teosto? (was: Re: Choosing a license for Frets on Fire songs)
On Tue May 15 17:25, Jason A. Spiro wrote: But one question: Do those license terms allow the songs to be distributed in a separate Debian package from the primary fretsonfire package? No, it will have to be amended to allow this as was suggested elsewhere in this thread. What if the song package Depends on fretsonfire?[1] What if it Recommends it?[2] I think our current model has fretsonfire-data-foo depending on fretsonfire. If the licence says these songs may only be used with fretsonfire and it's derivatives then that's clear whatever the package manager says. How about: http://creativecommons.org/licenses/by-nd-nc/1.0/legalcode with 4. d. added saying: You may not publicly display, publicly perform, or publicly digitally perform the Work except as part of the game and you may not distribute the Work except with the intention of it being used with the Game. and 1. g.: The Game means the game Frets on Fire or a derivative work of Frets on Fire. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#383316: [EMAIL PROTECTED]: Re: Sectoid Frets on Fire tracks]
Excellent, it looks like we'll get some songs we can ship. For reference, his songs are listed here: http://www.keyboardsonfire.net/?songs under 'Sectoid'. They are all very good. In terms of packaging, we probably want to have them as a separate source package (I think), which produces a binary package which fretsonfire depends on. Something like fretsonfire-data-sectoid? We could then have fretsonfire-data-inkila in non-free for the songs from upstream. They are both arch-all packages, so don't necessarily need to be split, but it's a lot nicer for upgrades. This is also why I favour a split source package, so that upgrades don't involve uploading and pushing copies of the songs. Matt - Forwarded message from Carlos Viola [EMAIL PROTECTED] - From: Carlos Viola [EMAIL PROTECTED] To: Matthew Johnson [EMAIL PROTECTED] Subject: Re: Sectoid Frets on Fire tracks Ok, I´m very happy with this, as soon I lincense the songs I´ll tell you and you can put the songs freely in Debian, it´s true honour to contribute with your team. More thanks. Sectoid. 2007/5/10, Matthew Johnson [EMAIL PROTECTED]: On Thu May 10 10:31, Carlos Viola wrote: Hello Matt, I´m sorry if I don´t fully understand you, my english level is not too high ;) I think you're question me for the author of the songs, well if it's your question I composed and played them personally That was my question, which leads onto a further question. I hope you have heard of Debian (http://www.debian.org/). It's one of the more popular distributions of Linux. Since Frets on Fire runs on Linux, and is a very excellent game, we would like it included in Debian and I am one of the people trying to do this. However, the songs that come with the game we aren't allowed to use (for complicated copyright reasons). Therefore, I would like to use your songs as the songs which come with Frets on Fire on Debian. This means anyone running Debian (or derivatives, like Ubuntu) would see and play your songs first. The reason I'm asking you is that because Debian's goal is to be completely free for everyone to use, share and build upon; in order for this to happen you would need to put your songs under a free licence. Just putting them up on the internet doesn't actually give people permission to copy and use them, there needs to be a statement saying that people have permission. The best licence for Debian would be the MIT licence. Wikipedia describes it here: http://en.wikipedia.org/wiki/MIT_Licence, and has translations to a number of languages if any would be easier for you to understand. Also, if you would like this email translated into another language then I'll see what I can do; I've written quite a lot here, so I understand. Anyway, to summarise, would you be willing to licence the tracks which you composed, played and fretted under a free licence (such as the one I linked to) so that we can put them in Debian for all our users to play in Frets on Fire? Thanks a lot, Matt -- Matthew Johnson -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGQuw62XtckeYvo1gRAr9jAJ4ggBcaOy+ZEo/p4LiU/NxPULz1twCg1tTa bDF9JVaP3++bt0qU2+Sp4gg= =9tfU -END PGP SIGNATURE- - End forwarded message - -- Matthew Johnson signature.asc Description: Digital signature
Bug#383316: [EMAIL PROTECTED]: Re: Sectoid Frets on Fire tracks]
On Fri May 11 11:20, Matthew Johnson wrote: In terms of packaging, we probably want to have them as a separate source package (I think), which produces a binary package which fretsonfire depends on. Something like fretsonfire-data-sectoid? We could then have fretsonfire-data-inkila in non-free for the songs from upstream. I have packaging for this now at http://mjj29.matthew.ath.cx/fretsonfire-data-sectoid.debian.tar.gz, which includes a get-orig-source target to create the source tarball. I've also updated the fretsonfire packaging in svn to depend on it. I'll add the sectoid packaging to svn if people agree with this approach Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#383316: [EMAIL PROTECTED]: Sectoid´s Frets on Fire Song Pack]
Excellent. Packaging updated to use this link. It still needs repackaging to a tarball, but it's just a straight copy now. I shall have a look at fonts tonight, but we might be good to go. I shall also forward the question about the derivative song to debian-legal. Matt - Forwarded message from Carlos Viola [EMAIL PROTECTED] - From: Carlos Viola [EMAIL PROTECTED] To: Matthew Johnson [EMAIL PROTECTED] Subject: Sectoid´s Frets on Fire Song Pack Hello Matt, I´ve added the file License.txt with que MIT license agreement, and put the license text in the comments of the .ogg files too. I think I´ve well done, if I forget something or I´ve done it wrong please tell me (I´m newbie in license stuff). Well, here is the link: http://www.nivel21.net/personal/sectoid/fretsonfire/Sectoid_Frets_on_Fire_Song_Pack.zip I have a little question: The song Ryu´s theme is a heavy metal version of the Ryu´s Song in the famous videogame Street Fighter 2, the song is completely made by me, but it´s a version of another, I don´t know if there is a problem with this. I suppose you need my name or email to put somewhere in the credits, I give you information about me if you need it. Name : Carlos Viola Iborra Musician´s Nickname : Sectoid Nacionality : Spain E-mail: (this) [EMAIL PROTECTED] Thanks a lot, I´m waiting your reply. Sectoid. - End forwarded message - -- Matthew Johnson signature.asc Description: Digital signature
Bug#383316: Derivative works for songs
For the Frets on Fire arcade game which we are packaging I have found an original artist willing to licence his works under the MIT licence. Four of the five songs are completely original works; the fifth, however, whilst being an original composition is inspired by another song. The email I have from the artist is below; I think that probably this counts as a derivative work, and hence would need permission from the original author, but I am not sure. Obviously debian-legal are not lawyers, but I would appreciate your opinions. I could just leave it out to be on the safe side, I could leave it in, hope that the ftp-masters accept it and hope that nothing comes of it or I could try and get an opinion from someone like SPI. What do you think is the best way to proceed? Thanks, Matt - Forwarded message from Carlos Viola [EMAIL PROTECTED] - From: Carlos Viola [EMAIL PROTECTED] To: Matthew Johnson [EMAIL PROTECTED] Subject: Sectoid´s Frets on Fire Song Pack Hello Matt, I´ve added the file License.txt with que MIT license agreement, and put the license text in the comments of the .ogg files too. I think I´ve well done, if I forget something or I´ve done it wrong please tell me (I´m newbie in license stuff). Well, here is the link: http://www.nivel21.net/personal/sectoid/fretsonfire/Sectoid_Frets_on_Fire_Song_Pack.zip I have a little question: The song Ryu´s theme is a heavy metal version of the Ryu´s Song in the famous videogame Street Fighter 2, the song is completely made by me, but it´s a version of another, I don´t know if there is a problem with this. I suppose you need my name or email to put somewhere in the credits, I give you information about me if you need it. Name : Carlos Viola Iborra Musician´s Nickname : Sectoid Nacionality : Spain E-mail: (this) [EMAIL PROTECTED] Thanks a lot, I´m waiting your reply. Sectoid. - End forwarded message - -- Matthew Johnson signature.asc Description: Digital signature
Bug#383316: [EMAIL PROTECTED]: Re: Sectoid Frets on Fire tracks]
On Fri May 11 17:13, Miriam Ruiz wrote: I have packaging for this now at http://mjj29.matthew.ath.cx/fretsonfire-data-sectoid.debian.tar.gz, which includes a get-orig-source target to create the source tarball. I've also updated the fretsonfire packaging in svn to depend on it. I'll add the sectoid packaging to svn if people agree with this approach I wonder if it would be better to just recommend it, instead on depending on it. We should also create some Provides: name for all the packages including FoF songs, i guess. I think we should depend on some songs package. A also don't think we need provides; would there be any reason _not_ to have the sectoid songs installed? I don't see any need to introduce a virtual package here for depends/provides. fretsonfire depends fretsonfire-data-sectoid fretsonfire-data-* depends fretsonfire and optionally fretsonfire (recommends/suggests) fretsonfire-data-* should be fine. We should also include the tutorial song somewhere, don't we? I was intending this to be in the main fretsonfire package (as it is at the moment). Matt -- Matthew Johnson University of Cambridge PhD Student signature.asc Description: Digital signature
Bug#383316: Final Packages?
Right, I've gone through the fonts. There aren't really any similar ones, so I've found one which will work for both (ttf-mgopen; MgOpenCosmeticaRegular.ttf) and looks fine. I've therefore updated the packaging to remove all the fonts, depend on this and vera and symlink them in debian/rules. I've also added the sectoid songs to svn at svn.debian.org/svn/pkg-games/packages/trunk/fretsonfire-data-sectoid and I've added a patch to stop it trying to initialise amanith. Thus, I think we are good to go finally! I have built both packages and have signed sources and binaries available here: http://mjj29.matthew.ath.cx/debian-upload/fretsonfire/ I'd appreciate someone doing a clean install and making sure it all goes smoothly and then we need to find someone to upload. The only outstanding issue is whether one of the sectoid songs is usable (it might count as a derivative work). If so I can easily rebuild the tarball to remove that one. Matt -- Matthew Johnson University of Cambridge PhD Student signature.asc Description: Digital signature
Bug#383316: Final Packages?
On Fri May 11 22:33, Miriam Ruiz wrote: I've also added the sectoid songs to svn at svn.debian.org/svn/pkg-games/packages/trunk/fretsonfire-data-sectoid and I've added a patch to stop it trying to initialise amanith. Unconditionally or depending on whether it is available or not? Unconditionally. It's not in Debian, and users would have to remove all the .png files as well before it actually used amanith. If they are that determined they can de-patch it themselves. Anyway, I've noticed you have a circular dependency between fretsonfire and fretsonfire-data-sectoid that should be removed. Both cannot depend on each other at the same time. I was wondering, what if someone wants to play, but with their own songs instead of those, do they really need to have them installed? I don't think fretsonfire should depend on fretsonfire-data-sectoid, just recommend it. Hmm.. OK, I guess dropping it to recommends solves both those problems. I just don't like the idea of 'apt-get install fretsonfire' not giving you any songs. The policy manual allows for circular depends, but the debian-doc FAQ cites both directions of single dependency in different cases. If they use aptitude then they get the recommends anyway. I'll update svn. Matt signature.asc Description: Digital signature
Bug#423081: ITP: jarwrapper
Package: wnpp Severity: wishlist Owner: Matthew Johnson [EMAIL PROTECTED] * Package name: jarwrapper Version : 0.1 Upstream Author : Matthew Johnson [EMAIL PROTECTED] * URL : Native Package * License : GPL Description : execute jars with binfmt_misc uses binfmt-support to register a jar wrapper for making jars executable and running them, even if they don't have the extension of .jar. Combined with Class-Path and Main-Class attributes of jars it allows installing jars directly to $PATH as any name. signature.asc Description: Digital signature
Bug#423081: ITP: jarwrapper
tags 423081 pending retitle 423081 ITP: jarwrapper -- run executable jar files using binfmt_misc thanks I have a deb for this at http://mjj29.matthew.ath.cx/debian-upload/jarwrapper which I nee sponsoring. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#383316: Repackaging tarball
On Tue May 01 12:01, Miriam Ruiz wrote: I seriously doubt it, but we might try. In any case we should have a preplacement available, even if it's a different one than the original. Maybe it would be wise to give upstream an option to have a say in the decision too? Sure I still expect that at some point in the future, amanith developers will put the code GPL, and then the usage of amanith will be optional (it seems the graphics are cuter with svg than with png). Would it be possible to do it in a way so that, if amanith is available, it uses it, otherwise it uses png graphics? Probably, but it will be more work. I don't see any real reason why if amanith is packaged we shouldn't use it all the time. I also had to install python-pyogg; I'm not 100% sure why, but it seems sensible thing to depend on anyway (even when it does work without, it's heavier on the memory usage, according to the docs). Then we should depend on vorbis-tools too or that is not neccesary? No need. python-pyogg depends on liboog; it doesn't need vorbis-tools. Matt signature.asc Description: Digital signature
Bug#383316: Repackaging tarball
On Tue May 01 12:50, Miriam Ruiz wrote: --- Matthew Johnson [EMAIL PROTECTED] escribió: Probably, but it will be more work. I don't see any real reason why if amanith is packaged we shouldn't use it all the time. To give users the option. Less dependencies, lighter install. Also being able to give upstream a optimal patch. Is it that much work? well, we're shipping a load of png files as it is, I'm not sure that amanith instead is much of a lose. I also don't buy 'less dependencies' as a reason---users don't have to care about that, apt does it all for them. I'm also not sure the users want or need the option, svg+amanith is almost always better than png; when it isn't, they probably don't want to be playing FoF on that machine, it's so under powered. I can't imagine the overhead of amanith is all that noticeable. It wouldn't be a lot of work to dynamically detect amanith (they already dynamically detect other things), but since they already have an if (png) png else svg code, just using that and fixing the one init line will be easier. Matt signature.asc Description: Digital signature
Bug#383316: Repackaging tarball
On Tue May 01 13:20, Miriam Ruiz wrote: --- Matthew Johnson [EMAIL PROTECTED] escribió: On Tue May 01 12:50, Miriam Ruiz wrote: well, we're shipping a load of png files as it is, I'm not sure that amanith instead is much of a lose. I also don't buy 'less dependencies' as a reason---users don't have to care about that, apt does it all for them. I'm also not sure the users want or need the option, svg+amanith is almost always better than png; when it isn't, they probably don't want to be playing FoF on that machine, it's so under powered. I can't imagine the overhead of amanith is all that noticeable. I'd like to have the option of not using amanith for myself at least :) fair enough then (-: Yup I guess... anyway there's something inside me that keeps telling me that it would be better to do the best, not the easier. This is Debian, it's not just a matter of having it done, but having it done in the best way we can. I'd rather prefer to have the if (amanith) svg else png code instead, I guess. Am I too perfectionist? no, sure, I just wasn't sure there was any point (or demand). I was expecting either never amanith, use pngs if there or always amanith depending whether it was in Debian, so the hack case doesn't arise. If we actually want to offer the choice, then fine. Matt signature.asc Description: Digital signature
Bug#383316: Stage lighting
The new version of FoF has stage effects and lighting during the song. I've updated rules so that stage.ini is installed, however with the PNG files it seems to get the scaling wrong and as such you can't see the notes you are meant to be playing. The attached patch fixes this, although possibly the correct fix is generating the pngs differently. We either need to apply this while we are distributing pngs, or get upstream to fix this somehow. Matt --- stage.ini.old 2007-05-01 16:43:26.400039341 +0100 +++ stage.ini 2007-05-01 16:45:28.322987334 +0100 @@ -110,8 +110,8 @@ yres = 256 xpos = -0.87 ypos = -0.75 -xscale = 3.0 -yscale = 3.0 +xscale = 1.0 +yscale = 2.0 src_blending = one dst_blending = one foreground = 1 @@ -135,8 +135,8 @@ yres = 256 xpos = -0.69 ypos = -0.8 -xscale = 3.0 -yscale = 3.0 +xscale = 1.0 +yscale = 2.0 angle= -12.0 src_blending = one dst_blending = one @@ -161,8 +161,8 @@ yres = 256 xpos = -0.48 ypos = -0.83 -xscale = 3.0 -yscale = 3.0 +xscale = 1.0 +yscale = 2.0 angle= -16.0 src_blending = one dst_blending = one @@ -187,8 +187,8 @@ yres = 256 xpos = 0.83 ypos = -0.75 -xscale = 3.0 -yscale = 3.0 +xscale = 1.0 +yscale = 2.0 src_blending = one dst_blending = one foreground = 1 @@ -212,8 +212,8 @@ yres = 256 xpos = 0.64 ypos = -0.84 -xscale = 3.0 -yscale = 3.0 +xscale = 1.0 +yscale = 2.0 angle= 12.0 src_blending = one dst_blending = one @@ -238,8 +238,8 @@ yres = 256 xpos = 0.46 ypos = -0.9 -xscale = 3.0 -yscale = 3.0 +xscale = 1.0 +yscale = 2.0 angle= 19.0 src_blending = one dst_blending = one signature.asc Description: Digital signature
Bug#383316: Repackaging tarball
Wanting to play with the new version I started doing the dfsg packaging. I've hence updated the version number in the changelog to be .dfsg and updated the get-orig-source rule in debian/rules to remove all the songs we can't distribute. Miry, any update on suitable fonts? On a similar note, does anyone fancy approaching these people to see if they would licence their FoF track appropriately: http://scenerychannel.com/fof.html ? Matt signature.asc Description: Digital signature
Bug#383316: Repackaging tarball
On Mon Apr 30 21:02, Miriam Ruiz wrote: --- Matthew Johnson [EMAIL PROTECTED] escribió: Wanting to play with the new version I started doing the dfsg packaging. I've hence updated the version number in the changelog to be .dfsg and updated the get-orig-source rule in debian/rules to remove all the songs we can't distribute. Miry, any update on suitable fonts? data/title.ttf: copyright by Astigmatic One Eye ( http://www.astigmatic.com/freeware.html ) The typefaces on this page have been designed for you to use and enjoy free of charge. Use them in your Personal and Commercial projects and designs. We only ask that you do not redistribute the fonts themselves or create derivative products, whether other fonts, stickers, stencils, or other alphabet products (for free or profit) to others without our permission. If you have a question about our policy, or wish to license for these purposes, please feel free to contact us at [EMAIL PROTECTED] We should ask them if they are happy to licence it appropriately. You never know. data/default.ttf: copyright by 1001 Free Fonts: http://www.1001freefonts.com/ It's hard to know exactly which font it is, who owns the copyright or what the license is, but I guess it might not be DFSG-free. Whatever font we decide to use, it won'T be really very similar to the original ones, but I cannot think of anything better. http://www.1001freefonts.com/winfonts/firestarter.zip -- this is pretty similar, and has a contact address we could try to get licenced appropriately as well. On a similar note, does anyone fancy approaching these people to see if they would licence their FoF track appropriately: http://scenerychannel.com/fof.html ? Do we know if we can consider the tutorial as not being a song? if it's not a song, and the authors license it as DFSG-free, that would be enough for the moment. We might put FoF in main and tell people to get the songs from whenever they want, as they do with .AVIs, .MP3s or .SWFs. We could even consider putting the rest of the songs in non-free, but it's not inmediate how. The most important thing for me right now is putting the program in main. I believe they have said we can consider it not a song. BTW, my latest trial of the program showed me an error, as it seems FoF is trying to use amanith, do you get the same error too? We should ask upstream if they changed something. Yup, (after my last email) I fixed it by commenting out Svg.py:240. It seems it's not using amanith when the pngs are there, but still trying to initialise it and failing. Commenting the initialisation works because it's never actually called. I also had to install python-pyogg; I'm not 100% sure why, but it seems sensible thing to depend on anyway (even when it does work without, it's heavier on the memory usage, according to the docs). Matt signature.asc Description: Digital signature
Bug#421431: ITP: libcsv-java CSV parsing library for java
Package: wnpp Severity: wishlist Owner: Matthew Johnson [EMAIL PROTECTED] * Package name: libcsv-java Version : 2.0 Upstream Author : Bruce Dunwiddie [EMAIL PROTECTED] * URL : http://sourceforge.net/projects/javacsv/ * License : LGPL Programming Lang: Java Description : CSV IO library for Java Java CSV is a small fast open source java library for reading and writing CSV and plain delimited text files. All kinds of CSV files can be handled, text qualified, Excel formatted, etc. signature.asc Description: Digital signature
Bug#421432: ITP: salliere duplicate bridge scorer
Package: wnpp Severity: wishlist Owner: Matthew Johnson [EMAIL PROTECTED] * Package name: salliere Version : 0.1 Upstream Author : Matthew Johnson [EMAIL PROTECTED] * URL : http://www.matthew.ath.cx/projects/salliere/ * License : GPL Programming Lang: Java Description : Bridge duplicate scorer Salliere is a scoring program for duplicate bridge. It will take a file of pair numbers and contracts then score and match point them for duplicate bridge. It will then produce nicely tabulated overall results and board-by-board results. signature.asc Description: Digital signature
Bug#421431: ITP: libcsv-java CSV parsing library for java
tags 421431 pending thanks I have packages for this for which I need a sponsor to upload: http://mjj29.matthew.ath.cx/debian-upload/libcsv-java/ Matt signature.asc Description: Digital signature
Bug#421432: ITP: salliere duplicate bridge scorer
tags 421432 pending thanks I have packages for this for which I need a sponsor to upload: http://mjj29.matthew.ath.cx/debian-upload/salliere/ Matt signature.asc Description: Digital signature
Bug#383316: Could you please forward this proposed license to Teosto? (was: Re: Choosing a license for Frets on Fire songs)
On Thu Apr 26 21:16, Jason Spiro wrote: I don't know much about how to write licenses, and this is the first one I have ever written. I figured that everything after the subject to the following conditions: would automatically override the initial permissions I gave. I guess I was wrong? This is a very very good reason not to write your own. debian-legal always advises against doing so. How about using: http://creativecommons.org/licenses/by-nd-nc/1.0/legalcode with 4. d. added saying: You may not distribute, publicly display, publicly perform, or publicly digitally perform the Work except as part of the game. and 1. g.: The Game means the game Frets on Fire or a derivative work of Frets on Fire. This would, of course, have to be renamed something else, but it is good to make as small modifications as possible. It would also need t be run past debian-legal and Teosto's legal team. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#383316: Could you please forward this proposed license to Teosto? (was: Re: Choosing a license for Frets on Fire songs)
On Thu Apr 26 16:25, Jason Spiro wrote: Copyright (C) year copyright holders Permission is hereby granted, free of charge, to any person obtaining a copy of this work (the Work) to use, modify, copy, publish, distribute, publicly perform, and/or sublicense copies of the Work, and/or to charge a fee for the physical act of transferring copies, and/or to offer warranty protection for a fee, and/or to permit persons to whom the Work is furnished to do all of the aforementioned actions, subject to the following conditions: * Persons distributing the Work to the general public may only do so if the Work is distributed and/or bundled with game software. * No person may musically rearrange the Work or modify the lyrics of the Work unless that person obtains permission to do so from either the author or the copyright holder. This contradicts Permission is hereby granted, ... to use, modify, above. May I suggest using a CCby licence and adding 'may only be distributed with the game' rather than cobbling together your own inconsistent one... Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#383316: FoF package for Debian
On Thu Apr 12 17:13, Jason Spiro wrote: All, do you agree it would be a good idea to upload: * a fretsonfire package, * and another package with two or three Debian-Free songs packaged for fretsonfire into unstable for now? Frets on Fire is a popular game (the current Windows FOF installer has been downloaded more than 230,000 times[1]) and it'd be good to get it into Debian even before this issue is resolved. :-) If so, which songs? I suggest we pick any few Free songs (some of the ones at http://keyboardsonfire.net/?songs surely are Free, I can ask the webmaster if you want) that aren't too difficult to for newbies to succeed at. I agree it would be good to get it into Debian ASAP. The way I can see this going is: a program package, a free data package and a package in non-free with all the upstream songs in. The licence will need to be changed to one which we can at least distribute with before that last happens. The problem with the free data package is finding good songs which are actually free. What I have found from the keyboardsonfire.net songs is that they mostly fall into (at least one of) a few categories: 1. frets only (no audio files) 2. not free (often random commercial songs people are blatantly violating the copyright for and a quick poll of the site indicates no licence information in either the downloads or anywhere on the website) 3. don't have a proper guitar track -- this really does spoil the gameplay. I've not found a good solution short of actually recording the guitar separately 4. The frets are just not very goo d(not well timed, interesting etc). I wouldn't say any of those were appropriate for distributing as our main set of data files. Even the ones which the original artist has posted them, we will have to go to them and get them licenced under a properly free licence which allows modification, which some of them may not want (it's certainly not the case that by posting them on keyboardsonfire.net they grant such). For the song and the frets authors. Asking the webmaster is likely to be pointless, he's not the copyright holder, if there isn't an explicit copyright licence in the download for all the frets and audio we have to go back to them anyway. If you've found any appropriate songs which you think pass all of those, do let me know. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#383316: Choosing a license for Frets on Fire songs
On Tue Mar 27 20:54, Jason Spiro wrote: 2007/3/27, Don Armstrong [EMAIL PROTECTED]: On Tue, 27 Mar 2007, Jason Spiro wrote: Maybe if debian-legal or I wrote the license (I have never written a license before, but maybe I could modify the MIT license) we could get Teosto to agree on more liberal terms than we would get if Teosto wrote one? The following is what I would use if I were to license my own compositions[1] for distribution in Debian: I'm sure you realize Teosto would consider the BSD license far too liberal, and forbid it. :-) Seriously, do you think my idea of writing a license has merit? Such a licence would not get the songs in main, though. I imagine it would fail DFSG 6 and possibly 3. It would get them in non-free though which would allow the rest of the game in contrib or, if we managed to find some free songs to go with it, in main. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#383316: Choosing a license for Frets on Fire songs
On 3/28/07, Andrew Donnellan [EMAIL PROTECTED] wrote: On 3/28/07, Don Armstrong [EMAIL PROTECTED] wrote: Well, it actually seems rather strange to me for an organization which is designed to protect artists disallowing artists from determining how their own works are licensed, so I'm trying to give them the benifit of the doubt here. Do they really? That would mean that all the copyright holders would have given them exclusive licensing rights. Yes that's the contract you have to sign to be part of Teosto (which you have to do if you ever want to make a living in Finland as a musician). I haven't read the full bug log, but has anyone contacted the composers directly? Yes, we have. They are part of the upstream team and their contract forbids them from releasing _anything_ which is not under a licence Teosto agree with. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#415701: ITP: rt3.6-commandbymail
Package: wnpp Severity: wishlist * Package name: rt3.6-commandbymail Version : 0.05 Upstream Author : Jesse Vincent jesse at bestpractical.com * URL : http://search.cpan.org/src/JESSE/RT-Extension-CommandByMail-0.05/ * License : GPL v2 Programming Lang: Perl Description : lets request-tracker accept commands via email CommandByMail allows commands to be sent to the Request Tracker in emails. These are similar to those used by debbugs and allow tickets to be closed, reassigned, moved between queues and other commands. -- Matthew Johnson signature.asc Description: Digital signature
Bug#415440: RFP: jftp -- JFtp is a java gui client fro ftp, smb, sftp (as in scp) and nfs with some extra functions like http spider, ssh shell, ...
On Tue, Mar 20, 2007 at 10:15:35AM +0100, David Hansmann wrote: Hi, this was my first try to create a .deb and get it in mentors.debian.org - it doesn't follow the rules so it wasn't acceptable for unstable (and I didn't have the time to clear the tons of issues such as source code location requirements and so on ;) So you could safely ignore and/or take everything you want from the package (except the outdated code of course). I've uploaded a full .tar.gz containing the latest changes at http://j-ftp.sourceforge.net/j-ftp-1.50-pre2.tar.gz So, the first thing to note is that Debian packages are always built from source. Here you include the source for the net.sf.jftp stuff, but also a pile of compiled class files belonging to other libraries. I don't know which approach would be better, make the .tar.gz-structure more like a .deb or to keep the whole thing separated. The correct way to package something for Debian is to have the upstream and packaging completely separate. So, you would release tarballs which have no idea that Debian exists and I would add the packaging on top of that. There are some things which you can do to make it easier though. 1. Publish a source-only tarball with non-executable files in it 2. Add a GPL header to every file or move LICENCE to COPYING (the normal filename) and in LICENCE explicitly say which files are under the GPL. LICENCE should also give the licences which all the images and other data are under and the upstream authors of everything if you are not the author. For example: src/images/org/javalobby/icons/COPYRIGHT just says All images and icons Copyright(C) 1998 Dean S. Jones, there is no statement that you are even allowed to distribute these. 3. Have the tarball unpack to the directory packagename-version/ 4. List all the required external libraries for compilation and execution (these will also have to be Debian packaged if they are not) 5. Use a build system which searches for the libraries in the standard location (jars in /usr/share/java/) 6. Use a build system which installs into the standard locations and will install to $DESTDIR/standard/path/ - wrapper (which loads the jars from /usr/share/java) to /usr/bin/jftp - jar to /usr/share/java/jftp-$VERSION.jar - docs to /usr/share/doc/jftp/ I'm going to CC this to the bug log so that people know that I'm interested and there's some record of what we're doing here. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#414686: ITP: limpam-otpw -- A one-time password system for PAM
Package: wnpp Severity: wishlist Package name: libpam-otpw Version : Upstream Author : Markus Kuhn * URL : http://www.cl.cam.ac.uk/~mgk25/download/otpw-1.3.tar.gz * License : GPL2 Description : A One-time password system for PAM-compatible login programs. The OTPW package consists of the one-time-password generator otpw-gen plus two verification routines otpw_prepare() and otpw_verify() that can easily be added to programs such as login or ftpd on POSIX systems. For platforms that support the Pluggable Authentication Method (PAM) interface, a suitable wrapper is included as well. Login software extended this way will allow reasonably secure user authentication over insecure network lines. The user carries a password list on paper. The scheme is designed to be robust against theft of the paper list and race-for-the-last-letter attacks. Cryptographic hash values of the one-time passwords are stored for verification in the user’s home directory. See http://www.cl.cam.ac.uk/~mgk25/otpw.html for more details and why OTPW is superior to alternative OTP schemes such as OPIE. -- Matthew Johnson signature.asc Description: Digital signature
Bug#414686: ITP: limpam-otpw -- A one-time password system for PAM
I of course mean Version: 1.3. I have packages built at http://mjj29.matthew.ath.cx/debian-upload/otpw/ for which I need to find a sponsor Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#413405: ITP: libmatthew-java -- A collection of Java libraries
Package: wnpp Severity: wishlist * Package name: libmatthew-java Version : 0.4 Upstream Author : [EMAIL PROTECTED] * URL : http://www.matthew.ath.cx/projects/java/ * Licence : GPL v2 Description : A collection of Java Libraries Package: libunixsocket-java Description: Unix socket API and bindings for Java These bindings allow you to connect to Unix Sockets from within Java programs. Package: libmatthew-io-java Description: Extra IO library for Java This library provides classes to pipe a stream through an external program, print DOM trees and split an output stream so that it also goes to a file. Package: libmatthew-debug-java Description: Debugging library for Java This package provides a debugging library for Java, including a generic utility class for providing nicely formatted dumps of byte arrays (similar to the hexdump utility). Package: libcgi-java Description: CGI library for Java This library allows CGI scripts to be written in Java. The library provides access to all the standard CGI variables including POST/GET. It also makes it easy to create input forms in HTML documents. -- Matthew Johnson http://www.matthew.ath.cx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413406: ITP: imdb-tools -- Lookup film details on IMDB
Package: wnpp Severity: wishlist * Package name: imdb-tools Version : 0.3 Upstream Author : [EMAIL PROTECTED] * URL : http://www.matthew.ath.cx/projects/imdb-tools/ * License : GPL v2 Description : Lookup film details on IMDB The IMDB tools lookup film details on www.imdb.com, cache them and associate the details with filenames. -- Matthew Johnson http://www.matthew.ath.cx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383316: FretsOnFire
On Mon, 12 Feb 2007, Jason Spiro wrote: The explanation Miriam had seems rather odd---if they copyright holders agree to licence them the agency which was linked to should have nothing to do with it. OTOH, if they are using songs which aren't original by them, there could be a problem. What explanation? What agency? Ah, it was sent to -games and not the bug: In a previous mail: Oh, and about the songs used in the game, I'm afraid we can't give those up for redistribution due to the regulations of the Finnish Composers' Copyright Society (http://www.teosto.fi/teosto/webpages.nsf/mainpages/etusivu_englanti?opendocument). We would have to buy a licence from them to allow the songs to be redistributed, even for free-of-charge distribution. In my opinion it's insane, but those are the rules. So I guess the Debian package will have to be made so that it downloads the songs from our webserver upon installation. Would that work okay? If the authors licence them for redistribution then teosto should have nothing to do with it, but I'm not au fait with the finer points of Finnish copyright law. Matt -- Matthew Johnson http://www.matthew.ath.cx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383316: FretsOnFire
Hi Jason, I've also been looking at this, I posted a couple of times to debian-legal for advice. On Fri, 9 Feb 2007, Jason Spiro wrote: I am not sure about the miscellaneous data. I assume the authors wanted to license it under the full Creative Commons Attribution 2.5 license legal code[3] which does not seem to be Debian-free[4]. What is in the copying.txt is not the CC-by-2.5, it's a summary which doesn't contain all the problematic clauses. There are two options: either upstream wanted what's in the copying.txt, in which case debian-legal recommend asking them to change to expat; or they wanted the actual CC-by-2.5, which is not DFSG-free and we'd need to convince them to use expat, GPL or something similar. == What to do about the rest == I propose we politely ask upstream if they could get the license for the songs and miscellaneous data changed to the GPL. This would make things very simple. If not, perhaps they could GPL the tutorial and miscellaneous data, and allow the songs to be freely used and noncommercially distributed by anyone. AFAIK this would allow the main game to get into main, and the songs to get into Debian non-free. It would also allow many other free Unixes to redistribute the game and the songs. The game would probably have to go into contrib in that case since it really depends on the songs; unless we can get a few other songs in the main package and have them as -extras in non-free. I've been asking around about getting some songs done. It's unclear to me why the songs aren't redistributable. Are the copyright holders of the songs also upstream? or are they a third party? If they are upstream, convincing them to relicence them would be good. The explanation Miriam had seems rather odd---if they copyright holders agree to licence them the agency which was linked to should have nothing to do with it. OTOH, if they are using songs which aren't original by them, there could be a problem. Matt -- Matthew Johnson http://www.matthew.ath.cx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383316: FretsOnFire
I've updated the debian/rules to use install -m so that everything is the right mode and it builds a package without lintian warnings now. I was looking back over the ITP and it says Frets On Fire depends on a library called amanith that is licensed under QPL, so it's not DFSG-free. The todo/changelog says 'remove dependency on amanith' though. Does it now not use amanith at all? or could we use it with amanth and use svgs rather than pngs? Do we want to do this? Matt -- Matthew Johnson http://www.matthew.ath.cx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383316: FretsOnFire
On Thu, 1 Feb 2007, Miriam Ruiz wrote: I've temporarily placed my current debian/ directory for Frets on Fire at: http://users.alioth.debian.org/~baby-guest/fretsonfire/debian.tgz New one here: http://mjj29.matthew.ath.cx/fretsonfire-debian.tar.gz I've updated a bunch of stuff in the debian directory (see the changelog) and done some general tidying. The only lintian errors left are that a bunch of data files are install executable, these should be changed either when creating the orig.tar.gz, or in the install target by using install -m rather than cp. I'm sorry I cannot add it to SVN yet due to some firewall here :( Do you want me to do that? To get the orig.tar.gz file, which must be re-created because the code must be fetched from a different .tgz than the data, see the get-orig-function in debian/rules. The orig is nearly 30 Mb so I won't upload mine. also, upstream's website is currently broken, and some of the links now go via sourceforge's mirror pages. 5) Once we know which data we'll include, separate package in two: fretsonfire/any and fretsonfire-data/all Are we going to compile the python files then? it currently works fine without doing so on mine (as a -all package). Matt -- Matthew Johnson http://www.matthew.ath.cx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383316: FretsOnFire
On Fri, 2 Feb 2007, Miriam Ruiz wrote: I'm sorry I cannot add it to SVN yet due to some firewall here :( Do you want me to do that? Yes, please! :) Done, packages/trunk/fretsonfire. I've also set the mergeWithUpstream property for svn-buildpackage to do its magic. Please, put me as uploader instead of maintainer, and set the maintainer field to: Maintainer: Debian Games Team pkg-games-devel@lists.alioth.debian.org done -- Matthew Johnson http://www.matthew.ath.cx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383316: packaging and licence update
I just found this game and would have filed an ITP myself... except there already is one! How is the packaging going? any progress or ETA? Matt -- Matthew Johnson http://www.matthew.ath.cx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335005: ITA: gbib
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 retitle 335005 ITA: gbib -- user-friendly editor and browser for BibTeX databases owner 335005 ! thanks I intend to adopt this package Matt - -- Matthew Johnson http://www.matthew.ath.cx/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFn7YVpldmHVvob7kRAvqSAJ0X5Xq2lXhPUKBRw0ORYPFExuP9IACg5M4r 389/2Iczh26BNTVrvPXNKS4= =EB9z -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365641: ITA: id3ren
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 retitle 365641 ITA: id3ren -- id3 tagger and renamer thanks I intend to adopt this package. Upstream hasn't had an update for a long time, so I'll look at the outstanding bug and try and fix it before uploading a package with me as the maintainer. Matt - -- Matthew Johnson http://www.matthew.ath.cx/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFcD2mpldmHVvob7kRAp0+AKCEzPXvnjqfOyb+zWSb7hGTsrfGOACg3DCh zDaAudiSyylX/Vf7Vc6vEio= =NYyk -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335005: Interested in adopting
Are you still looking for someone to adopt gbib? Having just found it, it looks really useful, so I'm keen to see it maintained in Debian. I'd be willing to adopt the package. Matt -- Matthew Johnson http://www.matthew.ath.cx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382568: ITP: classpath-generics -- Experimental Java 5 runtime libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 retitle 382568 ITP: classpath-generics -- Experimental Java 5 runtime libraries owner 382568 ! thanks I intend to package the current CVS head of the generics branch as a library which can be installed alongside classpath. I'll also supply some wrappers for the main 1.5-compliant VMs to use classpath. Matt - -- Matthew Johnson http://www.matthew.ath.cx/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFZXPvpldmHVvob7kRAg9zAJ9yTeEp7oj/B79uCyiLponRyqcxzwCaAjzE C1HRhrOL6IhV8o9BtmyyDA0= =QRkG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
