Re: Debian Games Team
--- Eddy Petriºor [EMAIL PROTECTED] escribió: Can ome packaging can be done for non-free games? (I am thinking about a wrapper over the pristine installers/data/ to make the games installable through apt-get). To be honest, I'm not particulary interested in non-free software at all, including games, but I have nothing against it if we decide as a group to do so. In my oppinion there's so much work to do about free games that I don't think it's a good idea giving away our time to non-free projects. Of course, there's the usual balance to consider between freeness and users-friendliness, but, as it has happened to other kinds of programs in more critical areas, I think it might better to concentrate in improving free games than in packaging non-free stuff, and in the long term it might give better results. Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Games Team
On 13-Jan-2006, Miriam Ruiz wrote: --- Eddy Petriºor [EMAIL PROTECTED] escribió: Can ome packaging can be done for non-free games? To be honest, I'm not particulary interested in non-free software at all, including games, but I have nothing against it if we decide as a group to do so. In my oppinion there's so much work to do about free games that I don't think it's a good idea giving away our time to non-free projects. Seconded. This Debian user would be much better pleased by Debian's efforts going to improving the packaging and coordination of free software games. -- \I took it easy today. I just pretty much layed around in my | `\ underwear all day. ... Got kicked out of quite a few places, | _o__) though. -- Bug-Eyed Earl, _Red Meat_ | Ben Finney [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: RFS: knmap -- Kde interface to nmap
On Thursday 12 January 2006 23:53, Andrew Vaughan wrote: Hi Ciao! Please provide a one sentence description of nmap. This will help users decide whether they are interested in this package. A good Idea! The new description is: Knmap is a KDE-based interface to the 'nmap' facility available at http://www.insecure.org/nmap. . The main Knmap window provides for the entry of nmap options and the display of nmap-generated output. . Nmap (Network Mapper) is a utility for network exploration or security auditing. It supports ping scanning (determine which hosts are up), many port scanning techniques, version detection, and TCP/IP fingerprinting. . Homepage: http://sourceforge.net/projects/knmap Today, the up stream author, released a new version of knmap: 2.0 The 2.0 package is available: http://www.knio.it/debian/knmap/ Thanks Andrew Thanks you!! Claudio -- ~~MaXeR ~~ Home: http://www.knio.it Community http://www.debianizzati.org - http://guide.debianizzati.org GnuPG Key: 0x34337C08 pgpszXKwFLX1v.pgp Description: PGP signature
Re: Debian Games Team
On 1/13/06, Ben Finney [EMAIL PROTECTED] wrote: Can ome packaging can be done for non-free games? Seconded. This Debian user would be much better pleased by Debian's efforts going to improving the packaging and coordination of free software games. I agree that free software is the priority, but I don't feel that packaging efforts would be wasted. In any case some experience is gathered and supporting games like Unreal Tournament, NWN, is not that hard as they release more rarely than free ones, imho. PS: I would love to have more free games like quake, but let's face it, games still are majorly non-free land (I felt this the most when I changed primary arch to ppc). -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: RFS: knmap -- Kde interface to nmap
On Fri, 13 Jan 2006 22:15, Claudio Moratti wrote: On Thursday 12 January 2006 23:53, Andrew Vaughan wrote: Please provide a one sentence description of nmap. This will help users decide whether they are interested in this package. A good Idea! The new description is: Knmap is a KDE-based interface to the 'nmap' facility available at http://www.insecure.org/nmap. . The main Knmap window provides for the entry of nmap options and the display of nmap-generated output. . Nmap (Network Mapper) is a utility for network exploration or security auditing. It supports ping scanning (determine which hosts are up), many port scanning techniques, version detection, and TCP/IP fingerprinting. . Homepage: http://sourceforge.net/projects/knmap Thanks Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: easychem take 2
Hello *, On Thu, Jan 12, 2006 at 09:34:14PM -0500, Chris Peterman wrote: I was wondering if anyone would be willing to sponsor easychem for me. I might be interested in sponsoring this, please allow me some comments on your packaging: - Build-Depends on locales? Seems superfluous, same for docbook-xml, and indeed the package builds fine without them - the pointer to the upstream homepage in the long description should be differently formatted, please see bug#339826 - you use a home-grown patch system to update PREFIX in the upstream Makefile, but this updating could easily be done via a make flag à la make PREFIX=/usr (/usr seems sensible from my reading of the source, please check the single occurence of PREFIX in easychem.c) - in the light of improved library handling needed as mentioned in http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html you could try also passing GTK_LIBS=-L/usr/X11R6/lib -lgtk-x11-2.0 to make, this will allow to drop the Depends on some packages that aren't directly needed for running easychem - patching the upstream Makefile to add an install target that only installs a single file seems overkill, you might want to simply install that file via the install target of debian/rules - all in all it seems no changes to upstream's Makefile are required and thus you could also drop your whole patching system including the patches/ subdir - so some things that could be dropped in debian/rules: the complete configure*, patch* and unpatch* targets, the make install and the dh_installexamples call (as there are no examples to be installed) - fr.mo is generated, but not installed by upstream Makefile, so manual action seems needed once more - did you see http://lists.debian.org/debian-devel/2006/01/msg00815.html? - while generating the manpage the web will be accessed for loading the external entity docbookx.dtd. However, if this fails the manpage will still be identically generated, but a warning will be printed - several files don't show a newline at the end You see, you seem to be jumping unnecessarily through some hoops. Your (and your sponsor's) life could be made easier, even though your current packaging already works... ;) HTH, Flo signature.asc Description: Digital signature
[OT] Keysigning in Bariloche?
Hi, sorry for the OT, but I didn't know where it would be on-topic. I'll be in Bariloche, Patagonia, Argentina during the next week (till January 21st). If there's someone that's travelling there and is interested in keysigning, please send me a mail and we'll arrange it. -- Love, Marga
RFS: libsimpledb -- C++ ODBC database API
Hello, I am searching for an sponsor for my libsimpledb package. * Package name: libsimpledb Version : 1.5 Upstream Author : Russell Kliese [EMAIL PROTECTED] * URL : http://simpledb.sourceforge.net/ * License : LGPL-2.1 Description : C++ ODBC database API The SimpleDB API is a C++ API designed to encapsulate the ODBC API functionality in an object oriented manner. The API has been tested to work with both MySQL and PostgreSQL on a Debian Linux platform. ITP: #336141 Debian source and binary package: http://jonas.capi2name.de/debian-upload/libsimpledb/ Greets, Jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: knmap -- Kde interface to nmap
Hi, Claudio... On Friday 13 January 2006 12:15, Claudio Moratti wrote: Today, the up stream author, released a new version of knmap: 2.0 The 2.0 package is available: http://www.knio.it/debian/knmap/ I have taken a look at the package and would generally sponsor the upload. Minor things that I would like to have fixed: debian/docs: [WISHLIST] The README is absolutely useless. Please don't install it. debian/knmap.1: [INFO] Thanks for creating a man page. Did you send it upstream so it can be included in future distributions of knmap? debian/patches: [QUESTION/HINT] You are changing a whole lot of the autoconf parts. Does this have to do with some transitions going on? Usually just the config.guess and config.sub are altered in Debian packages and those are directly in the diff.gz (without the need to use dpatch). Just curious. Otherwise the package looks good. Christoph -- Never trust a system administrator who wears a tie and suit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Games Team
Miriam Ruiz wrote: Hi, Hi Miriam We've been recently talking about creating a group to maintain games in Debian in a collaborative way. As a starting point, I've created a mailing list in alioth for coordination, and also for create discussion threads about the main problems related to game development and games packages in Debian. You can join that list at: [...] You're welcome to join the group, or say whatever you think about this project. I think it's a marvellous idea as gaming is one of the aspects that is IMHO still underrepresented in Debian :-) Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: RFS: knmap -- Kde interface to nmap
On Friday 13 January 2006 15:48, Christoph Haas wrote: Hi, Claudio... On Friday 13 January 2006 12:15, Claudio Moratti wrote: Today, the up stream author, released a new version of knmap: 2.0 The 2.0 package is available: http://www.knio.it/debian/knmap/ I have taken a look at the package and would generally sponsor the upload. Minor things that I would like to have fixed: debian/docs: [WISHLIST] The README is absolutely useless. Please don't install it. Normally I include all the documentation (if license is compatible with Debian)... But this README is...ehm... very useless... removed! debian/knmap.1: [INFO] Thanks for creating a man page. Did you send it upstream so it can be included in future distributions of knmap? No, I forgot to send it... I'm doing it now! debian/patches: [QUESTION/HINT] You are changing a whole lot of the autoconf parts. Does this have to do with some transitions going on? Usually just the config.guess and config.sub are altered in Debian packages and those are directly in the diff.gz (without the need to use dpatch). Just curious. My first sponsor, Florian Ernst, taught me about libtoolization... I relibtoolize every package, if necessary, in order to have a correct and minimal Depencend field... this is the reason ;-) I uploaded the fixed package! Otherwise the package looks good. Thank you :D Christoph Cheers, Claudio -- ~~MaXeR ~~ Home: http://www.knio.it Community http://www.debianizzati.org - http://guide.debianizzati.org GnuPG Key: 0x34337C08 pgp73dZK3pmyV.pgp Description: PGP signature
RFS: GOPchop
Hi, I'm looking for a sponsor for the GOPchop MPEG2 editor. I debianized and added man pages for it some time back, but never got the ball rolling for inclusion in the repository. Paul Wise recently took some interest and suggested that this is the place to go first. http://gopchop.sourceforge.net/ The ITP is Bug #232082 Current released version of GOPchop is 1.1.7 * Package name: gopchop Version : 1.0.0 Upstream Author : Kees Cook [EMAIL PROTECTED] * URL : - * License : GPL Description : GOP-accurate cuts-only editor for MPEG2 video files GOPchop is a cuts-only editor which allows editing sections out of MPEG2 files without re-encoding the resulting frames. The typical use is manually editing commercials out of recorded television programs. Another application is splitting .VOB files from dual-layer DVD rips so that the content can be re-authored such that each half will fit on one single-layer DVD recordable. -- John. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Extra debian repository
Am Samstag, den 14.01.2006, 06:05 +1100 schrieb Matthew Palmer: On Fri, Jan 13, 2006 at 08:04:01PM +0200, Mugurel Tudor wrote: - the repository created is a trivial one (something like deb http://server/dir1/dir2 dir3/), and dir3 containes the packages involved and the Packages.gz (created with dpkg-scanpackages) Hint: use apt-ftparchive. It's a lot tidier. Or have a look at http://wiki.debian.org/HowToSetupADebianRepository for a list of solutions to prepare a Debian repository. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: knmap -- Kde interface to nmap [uploaded]
On Friday 13 January 2006 19:40, Claudio Moratti wrote: On Friday 13 January 2006 15:48, Christoph Haas wrote: debian/patches: [QUESTION/HINT] You are changing a whole lot of the autoconf parts. Does this have to do with some transitions going on? Usually just the config.guess and config.sub are altered in Debian packages and those are directly in the diff.gz (without the need to use dpatch). Just curious. My first sponsor, Florian Ernst, taught me about libtoolization... I relibtoolize every package, if necessary, in order to have a correct and minimal Depencend field... this is the reason ;-) I thought I understood at least the reason to include diffs for a config.guess and config.sub. But IMHO relibtooling is only needed when certain libraries are in a state of transitions. Could you (or Florian (or anyone)) shed some light on this procedure and the whys? I have never seen this being used as a common procedure for packages and would like to learn. I uploaded the fixed package! Me, too. :) Another minor issue: the .desktop file makes knmap show up in the Applications menu rather than in the Internet (Network) menu. Perhaps the upstream could reconsider this classification. Christoph -- Never trust a system administrator who wears a tie and suit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
relibtoolizing when necessary (was: RFS: knmap -- Kde interface to nmap [uploaded])
Hello *,
On Fri, Jan 13, 2006 at 09:10:32PM +0100, Christoph Haas wrote:
On Friday 13 January 2006 19:40, Claudio Moratti wrote:
On Friday 13 January 2006 15:48, Christoph Haas wrote:
debian/patches: [QUESTION/HINT]
You are changing a whole lot of the autoconf parts. Does this have
to do with some transitions going on? Usually just the config.guess
and config.sub are altered in Debian packages and those are directly
in the diff.gz (without the need to use dpatch). Just curious.
My first sponsor, Florian Ernst, taught me about libtoolization...
I relibtoolize every package, if necessary, in order to have a correct
and minimal Depencend field...
this is the reason ;-)
I thought I understood at least the reason to include diffs for a
config.guess and config.sub. But IMHO relibtooling is only needed when
certain libraries are in a state of transitions. Could you (or Florian (or
anyone)) shed some light on this procedure and the whys? I have never seen
this being used as a common procedure for packages and would like to
learn.
I gave some pointers on relibtoolizing to my sponsees after vorlon
called for improved library handling as mentioned in
http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html.
Especially KDE applications seem to be prone to depend on a plethora
of packages they don't really need for functioning due to the admin/
subdir as shipped by kdevelop, so relibtoolizing can save a great deal
here.
For example let's take a look a keurocalc, a package I sponsored for
Claudio. This is the wdiff between before and after proper
relibtoolization:
| Depends: [-kdelibs4c2-] {+kdelibs4c2a+} (= [-4:3.4.2-1), libart-2.0-2
| (= 2.3.16), libaudio2,-] {+4:3.4.3-1),+} libc6 (= 2.3.5-1),
| [-libfam0, libfontconfig1 (= 2.3.0), libfreetype6 (= 2.1.5-1),-]
| libgcc1 (= [-1:4.0.1), libice6 | xlibs ( 4.1.0), libidn11 (=
| 0.5.18), libjpeg62, libpng12-0 (= 1.2.8rel),-] {+1:4.0.2),+}
| libqt3-mt (= 3:3.3.5), [-libsm6 | xlibs ( 4.1.0),-] libstdc++6 (=
| [-4.0.2), libx11-6 | xlibs ( 4.1.0), libxcursor1 ( 1.1.2),
| libxext6 | xlibs ( 4.1.0), libxft2 ( 2.1.1), libxi6 | xlibs (
| 4.1.0), libxinerama1, libxrandr2 | xlibs ( 4.3.0), libxrender1 (
| 1:0.9.0-1), libxt6 | xlibs ( 4.1.0), zlib1g (= 1:1.2.1)-]
| {+4.0.2-4)+}
(well, ok, this also includes the g++ transition, but I guess you'll
get the point)
20 Depends were saved, including libfreetype6 which stood at the
beginning of Steve's mail, resulting in a fine and clean
| Depends: kdelibs4c2a (= 4:3.4.3-1), libc6 (= 2.3.5-1), libgcc1 (=
| 1:4.0.2), libqt3-mt (= 3:3.3.5), libstdc++6 (= 4.0.2-4)
which actually is all that package really really needs. All the other
Depends were just unnecessarily pulled in.
Of course, maintainers shouldn't relibtoolize just for the sake of it,
but sometimes it's truly worth the effort.
HTH,
Flo
signature.asc
Description: Digital signature
RFS: GNU Shishi
Since last time, I have removed the GFDL manual from the package. The
package is still lintian clean. I believe I fixed all problems
discussed in this thread, but please double check. Is it possible to
upload this into unstable?
Package name: shishi
Version : 0.0.23
ITP : #344586
URL or Web page : http://josefsson.org/shishi/
License : GPL
Description : Shishi is an implementation of Kerberos 5
Shishi is an implementation of the Kerberos 5 network authentication
system.
.
Shishi can be used to authenticate users in distributed systems.
.
Shishi contains a library ('libshishi') that can be used by
application developers to add support for Kerberos 5. Shishi
contains a command line utility ('shishi') that is used by users to
acquire and manage tickets (and more). The server side, a Key
Distribution Center, is implemented by 'shishid'. Of course, a
manual documenting usage aspects as well as the programming API is
included.
.
Shishi currently supports AS/TGS exchanges for acquiring tickets, the
AP exchange for performing client and server authentication, and
SAFE/PRIV for integrity/privacy protected application data exchanges.
.
Shishi is internationalized; error and status messages can be
translated into the users' language; user name and passwords can be
converted into any available character set (normally including
ISO-8859-1 and UTF-8) and also be processed using an experimental
Stringprep profile.
.
Most, if not all, of the widely used encryption and checksum types
are supported, such as 3DES, AES and HMAC-SHA1.
Debian packages:
http://josefsson.org/shishi/debian/
Thanks,
Simon
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Depending on non-buggy versions?
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: I am wondering if my package should depend/build-depend on a special minimum version of another package, if my package fails to work with earlier buggy versions of the packages I depend on. If you require a minimal version, you should have a versioned (build-)depenancy. (Unless stable already has the required version, you don't need to support installing your package on older versions that that.) If there was a buggy version that was only in unstable for a short time, you don't need to do anything special about it other than requesting binNMUs if needed. If the buggy version is still in stable or testing, you should have a dependancy or conficts to avoid it. Cases between the second and third can be handled either way. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: relibtoolizing when necessary (was: RFS: knmap -- Kde interface to nmap [uploaded])
On Friday 13 January 2006 21:52, Florian Ernst wrote: Hello *, On Fri, Jan 13, 2006 at 09:10:32PM +0100, Christoph Haas wrote: [cut] Of course, maintainers shouldn't relibtoolize just for the sake of it, but sometimes it's truly worth the effort. HTH, Flo The situation was the same for knmap... I think that is a good pratice when the Depends contains unneeded packages.. Normally I relibtoolize packages that needs this procedure... ;-) Cheers PS: Thanks to Christoph for the sponsorship :D Claudio -- ~~MaXeR ~~ Home: http://www.knio.it Community http://www.debianizzati.org - http://guide.debianizzati.org GnuPG Key: 0x34337C08 pgp6wnURYFsyU.pgp Description: PGP signature
Re: relibtoolizing when necessary (was: RFS: knmap -- Kde interface to nmap [uploaded])
On Fri, 13 Jan 2006, Florian Ernst wrote: I thought I understood at least the reason to include diffs for a config.guess and config.sub. But IMHO relibtooling is only needed when certain libraries are in a state of transitions. Could you (or Florian (or autotools dev maintainer hat on You should always relibtoolize. The only exception are for packages for which upstream uses Debian libtool from sid. /autotools dev maintainer hat on Debian libtool does many things that are much saner for Debian than up-to-date upstream libtool. And non-up-to-date libtool from anywhere is always a Bad Idea. Of course, maintainers shouldn't relibtoolize just for the sake of it, but sometimes it's truly worth the effort. Unless the package already uses Debian libtool from upstream, it ain't for the sake of it... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: GOPchop
On Fri, 2006-01-13 at 10:57 -0800, John R. Hogerhuis wrote: Hi, I'm looking for a sponsor for the GOPchop MPEG2 editor. I debianized and added man pages for it some time back, but never got the ball rolling for inclusion in the repository. Paul Wise recently took some interest and suggested that this is the place to go first. http://gopchop.sourceforge.net/ Where is the source package (diff.gz/orig.tar.gz) located again? -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: RFS: knmap -- Kde interface to nmap [uploaded]
On Fri, Jan 13, 2006 at 09:10:32PM +0100, Christoph Haas wrote: On Friday 13 January 2006 19:40, Claudio Moratti wrote: On Friday 13 January 2006 15:48, Christoph Haas wrote: debian/patches: [QUESTION/HINT] You are changing a whole lot of the autoconf parts. Does this have to do with some transitions going on? Usually just the config.guess and config.sub are altered in Debian packages and those are directly in the diff.gz (without the need to use dpatch). Just curious. My first sponsor, Florian Ernst, taught me about libtoolization... I relibtoolize every package, if necessary, in order to have a correct and minimal Depencend field... this is the reason ;-) I thought I understood at least the reason to include diffs for a config.guess and config.sub. But IMHO relibtooling is only needed when certain libraries are in a state of transitions. There are *always* libraries in a state of transition in Debian. Using the Debian libtool means limiting those transitions to packages which have a valid reason for depending on the transitioning library, instead of giving us transitions that ripple through all the indirect reverse-dependencies. Just to be clear, relibtoolizing should only need to be a one-time thing. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
