Bug#440607: ITP: steam-powered -- Valve's steam game content delivery system
Package: wnpp Severity: wishlist Owner: Michael Gilbert [EMAIL PROTECTED] * Package name: steam-powered Version : 6 Upstream Author : Michael Gilbert * URL : no website * License : GPL Programming Lang: shell Description : Valve's steam game content delivery system This package is a wrapper that makes it easy to install and run Valve's Steam program via wine. The intent will be for this package to be a part of the contrib archive. A preliminary version of the package has been uploaded to debian-mentors for review and testing, [1]. There has already been some interesting discussion on the mentors list. Please read [2], [3], and [4] to get up to speed. I am looking forward to the discussion and getting this package added to the archive. Steam (www.steampowered.com) is a game content delivery system developed by Valve software (http://www.valvesoftware.com). This is a windows application, which is supported on your Debian system via wine (http://www.winehq.org). Not all steam games work at this time, but many do. Games that work very well include half-life, counter-strike, half-life 2, and counter-strike: source. More information about steam can be found at http://www.steampowered.com. [1] http://mentors.debian.net/debian/pool/contrib/s/steam-powered/ [2] http://lists.debian.org/debian-mentors/2007/08/msg00592.html [3] http://lists.debian.org/debian-mentors/2007/08/msg00599.html [4] http://lists.debian.org/debian-mentors/2007/08/msg00601.html Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (400, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: steam-powered
Michael Gilbert [EMAIL PROTECTED] writes: The users *are* free to choose the software that's out there. The Debian project is also free to refuse to choose what software it distributes. the key word is distribution. the question is whether the part of the software to be added to the archive is distributable. for steam-powered, all of the software in the package is fully GPL'd, and thus freely redistributable under the terms of the GPL. I don't think that was in question. This sub-thread is discussing whether we *want* software in Debian whose only purpose is to sell non-free software. Software must be DFSG-free to be in Debian. Not all DFSG-free software must be distributed by Debian. -- \ Truth would quickly cease to become stranger than fiction, | `\ once we got as used to it. -- Henry L. Mencken | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: normalize-audio (updated package)
Hello, On Mon, 03 Sep 2007, Joachim Reichel wrote: I am looking for a sponsor for the new version 0.7.7-2 of my package normalize-audio. I haven't checked this in detail but a quick look shows additional build-dependencies: Build-Depends: debhelper (= 5), dpatch, autotools-dev, libaudiofile-dev, libmad0-dev, mpg321, vorbis-tools, flac as compared with: Build-Depends: debhelper (= 5), autotools-dev, libaudiofile-dev, libmad0-dev, vorbis-tools As far as I could see the build does not depend on mpg321, vorbis-tools or flac as no audio files are being converted during the build. Regards, Kapil. -- signature.asc Description: Digital signature
Re: RFS: steam-powered
2007/9/3, Ben Finney [EMAIL PROTECTED]: Michael Gilbert [EMAIL PROTECTED] writes: The users *are* free to choose the software that's out there. The Debian project is also free to refuse to choose what software it distributes. the key word is distribution. the question is whether the part of the software to be added to the archive is distributable. for steam-powered, all of the software in the package is fully GPL'd, and thus freely redistributable under the terms of the GPL. I don't think that was in question. This sub-thread is discussing whether we *want* software in Debian whose only purpose is to sell non-free software. I for one would prefer not to concentrate too much in adding that kind of software to Debian, and even less in trying to promote it if there's no real demand for it beforehand. Of course if someone is willing to do the job and there's demand for it and Debian in general sees it OK, it's OK for me. It would be nice to launch the flame to debian-devel in advance, just in case. Anyway, even if the Team as a group decides to invest some effort into those kind of programs, I'll concentrate myself in DFSG-free stuff and, the most, some other slightly less free, but not that much. So, my personal vote, just speaking for myself, is that I'm not willing to devote a single second of my time supporting those programs Software must be DFSG-free to be in Debian. Not all DFSG-free software must be distributed by Debian. Agreed Miry
RFS: Piklab - IDE for PIC-microcontroller development
Piklab is an integrated development environment for applications based on Microchip PIC and dsPIC microcontrollers similar to the MPLAB environment. Support for several compiler and assembler toolchains is integrated. The GPSim simulator, the ICD1 programmer, the ICD2 debugger, the PICkit1 and PICkit2 programmers, the PicStart+ programmer, and most direct programmers are supported. A command-line programmer and debugger is also available. Piklab is an application for the KDE desktop. Homepage: http://piklab.sourceforge.net/ Packages: http://mentors.debian.net/debian/pool/main/p/piklab/ DSC File: http://mentors.debian.net/debian/pool/main/p/piklab/piklab_0.14.5-1.dsc As usual, feedback is welcome :) Miry
does anyone work on SMSer ?
Hello ,.. i wish to create a debian package for SMSer by guySoft i didn't found an itp for it but maybe someone is working and didn't send one ;-) -- -- Could you at least use man ? Jabka Atu (aka mha13/Mashrom Head) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: steam-powered
On Monday 03 September 2007 11:29:17 Miriam Ruiz wrote: I for one would prefer not to concentrate too much in adding that kind of software to Debian, and even less in trying to promote it if there's no real demand for it beforehand. Very well said, Miriam. There are similar issues with other applications which rely on non-free services to work correctly. GmailFS is a prime example for this. Instead of promoting clients for provider-specific services, Debian should promote standard interfaces to services and free implementations thereof, and free clients to access them. This gives users more choice, and as business people would say, provide a safer investment for the future. We already have free multiplayer frameworks in Debian. Let's promote those as they in turn promote running free games on them. Another issue with Steam specifically is that it doesn't allow users to be located in countries which were erased from the USA proprietary variant of the world map (http://www.valvesoftware.com/terms.html). I would say that this renders even the downloader non-DFSG-free, but that's probably for -legal to decide. Josef -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: xpn
Dear mentors, I am looking for a sponsor for my package xpn. * Package name: xpn Version : 0.7.0-3 Upstream Author : Antonio Caputo [EMAIL PROTECTED] * URL : http://xpn.altervista.org/index-en.html * License : GPLv2 Section : net It builds these binary packages: xpn- GTK based news reader, written in python The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/x/xpn - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/x/xpn/xpn_0.7.0-3.dsc I would be glad if someone uploaded this package for me. Beside the above standard text i want to give a more detailed description of the debianic part of the package. Originally XPN runs out of its own directory where all program files and the user data are stored. Fortunately the program provides an option to store user data in home directory. Thus i have done the following: - made storing user data in home directory standard by using a shell script for start XPN (xpn.sh) - added a simple man page to comply to policy - added a desktop file and converted icon to xpm format for smooth menu integration - created a symlink from /usr/bin/xpn to /usr/share/xpn/xpn.sh When putting the shell script directly into /usr/bin, the program isn't running (See README file in original source) Of course one can ask, why putting xpn to /usr/share and not to /usr/lib. I was unsure in this point, so i read FHS chapter 4. After comparing http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA and http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA i concluded to use /usr/share, because the python files are architecture independent (as far as a python interpreter is available, of course). As this is my first debian package, comments are most welcome. Kind regards Michael Krauss signature.asc Description: PGP signature
Re: RFS: xpn
Hi, Michael Krauss wrote: - dget http://mentors.debian.net/debian/pool/main/x/xpn/xpn_0.7.0-3.dsc IANADD, therefore i cannot upload you package, but anyways some comments: Major problems: * xpn appears to be the first package you release, therefore it must not have a debian revision higher then -1. This has an affect on debian/changelog which should only contain one version. * the script that launches xpn is installed without the executable bit set. this is an error, cause it makes it impossible to start xpn without adding the flag manually. * README.Debian must not be present if it does not contain any useful information for the users. It should be removed. Minor problems: * debian/changelog has a useless empty line at EOF * debian/rules contains some not neccessary empty lines Best Regards Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xpn
Hi, Major problems: * xpn appears to be the first package you release, therefore it must not have a debian revision higher then -1. This has an affect on debian/changelog which should only contain one version. I don't remember that there was a consensus about whether unreleased versions should be kept in the changelog (link appreciated if someone knows better). This will depend on the sponsor's preference, and thus I wouldn't consider it a major problem (but IANADD either). Regards, Jan signature.asc Description: Digital signature
Re: RFS: xpn
On Mon, 03 Sep 2007, Jan C. Nordholz wrote: * xpn appears to be the first package you release, therefore it must not have a debian revision higher then -1. This has an affect on debian/changelog which should only contain one version. I don't remember that there was a consensus about whether unreleased versions should be kept in the changelog (link appreciated if someone knows better). This will depend on the sponsor's preference, and thus I wouldn't consider it a major problem (but IANADD either). I guess it shouldn't be a problem to start real Debian life with a revision higher than -1, but you have to take care that the .changes file contains a reference to the .orig.tar.gz so that it is uploaded, otherwise it will be missing. But I never tried it. Best wishes Norbert --- Dr. Norbert Preining [EMAIL PROTECTED]Vienna University of Technology Debian Developer [EMAIL PROTECTED] Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- HAGNABY (n.) Someone who looked a lot more attractive in the disco than they do in your bed the next morning. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xpn
Jan C. Nordholz wrote: I don't remember that there was a consensus about whether unreleased versions should be kept in the changelog (link appreciated if someone knows better). This will depend on the sponsor's preference, and thus I wouldn't consider it a major problem (but IANADD either). Hmm. Well i have no link, cause i don't know that there has been any different opinions on this. It might not be a technical problem, but as the changelog is part of what the users _can_ see it might not be a good idea to publish something thats not available to anyone, but the developer. To say: If there is something you don't wanna show the user, why would you want to tell him, that it exists? Just to nag him? Apart from this: I don't think that Michael did this by intension. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: New ccontrol package, 0.9.1+20060806-4
Hello mentors! I have a new ccontrol package ready for upload. Once again it is a minor change from the last version: * Force-disable GCC stack protection as it is incompatible with the current dietlibc (Ubuntu #109157). * Don't ignore errors in $(MAKE) distclean. The first change will fix an unavoidable segfault at startup on Ubuntu. Is there a name for that, FTRAA - Fails To Run At All? The second is a change suggested by Lintian for the clean target. It should be a nice safe upload for Debian and a lifesaving fix on Ubuntu which I just found out is well on its way into freeze. Here it is: http://mentors.debian.net/debian/pool/main/c/ccontrol/ccontrol_0.9.1+20060806-4.dsc I originally emailed my regular sponsor, Amaya, but this time didn't get an immediate reply -- so I'm posting to mentors. This fix is important for Ubuntu so I'd like to get it into Debian ASAP so it can be synced. Please CC me on replies. -- \0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Advocate needs
Hi all! I have develop program (http://qstardict.ylsoftware.com) and maintain Debian package for them. Now I want to put them to Debian. Can anyone to be my advocate? -- Alexander Rodin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Advocate needs
Hi, * Alexander Rodin [EMAIL PROTECTED] [2007-09-03 16:18]: I have develop program (http://qstardict.ylsoftware.com) and maintain Debian package for them. Now I want to put them to Debian. Can anyone to be my advocate? You don't need an advocate if you don't want to become an official Debian developer. If you just want your package in Debian you need a sponsor who uploads your package for you. Have a look at: http://mentors.debian.net/cgi-bin/maintainer-intro Kind regards Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. http://people.debian.org/~nion/sponsoring-checklist.html pgp39z3ou1viA.pgp Description: PGP signature
Re: Advocate needs
On Mon, Sep 03, 2007 at 06:15:24PM +0400, Alexander Rodin wrote: Hi all! I have develop program (http://qstardict.ylsoftware.com) and maintain Debian package for them. Now I want to put them to Debian. Can anyone to be my advocate? Hi Alexander, Where are the debian sources? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Advocate needs
В Пнд, 03/09/2007 в 16:29 +0200, Nico Golde пишет: Hi, * Alexander Rodin [EMAIL PROTECTED] [2007-09-03 16:18]: I have develop program (http://qstardict.ylsoftware.com) and maintain Debian package for them. Now I want to put them to Debian. Can anyone to be my advocate? You don't need an advocate if you don't want to become an official Debian developer. If you just want your package in Debian you need a sponsor who uploads your package for you. Have a look at: http://mentors.debian.net/cgi-bin/maintainer-intro Kind regards Nico Thanks! -- Alexander Rodin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Advocate needs
В Пнд, 03/09/2007 в 10:19 -0400, Justin Pryzby пишет: On Mon, Sep 03, 2007 at 06:15:24PM +0400, Alexander Rodin wrote: Hi all! I have develop program (http://qstardict.ylsoftware.com) and maintain Debian package for them. Now I want to put them to Debian. Can anyone to be my advocate? Hi Alexander, Where are the debian sources? Justin Hi, Justin! There is a Debian sources: http://qstardict.ylsoftware.com/files/qstardict-0.07-debian-sources.tar.bz2 . But this have some problem: written by me manpage qstardict.1 don't installs... Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xpn
Am Montag, den 03.09.2007, 14:50 +0200 schrieb Norbert Preining: On Mon, 03 Sep 2007, Jan C. Nordholz wrote: * xpn appears to be the first package you release, therefore it must not have a debian revision higher then -1. This has an affect on debian/changelog which should only contain one version. I don't remember that there was a consensus about whether unreleased versions should be kept in the changelog (link appreciated if someone knows better). This will depend on the sponsor's preference, and thus I wouldn't consider it a major problem (but IANADD either). I guess it shouldn't be a problem to start real Debian life with a revision higher than -1, but you have to take care that the .changes file contains a reference to the .orig.tar.gz so that it is uploaded, otherwise it will be missing. But I never tried it. I used to do this for several packages I provided via my personal page before they were added to the Debian distribution. We (my sponsor and me) never had problems with this. In the OPs case, I would suggest to use the - -v option for a .changes file over -1 to -3|uploaded revision - -sa option for including the .orig.tar.gz as documented in dpkg-buildpackage(1). @Michael: Tell your sponsor, when you used these options! Most sponsors rebuild the package and the -v and -sa options are not used by default. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xpn
Hi, Hmm. Well i have no link, cause i don't know that there has been any different opinions on this. It might not be a technical problem, but as the changelog is part of what the users _can_ see it might not be a good idea to publish something thats not available to anyone, but the developer. To say: If there is something you don't wanna show the user, why would you want to tell him, that it exists? Just to nag him? Why should I try to hide the normal course of development? I don't see the necessity to create extra loops (reformatting the changelog after each intermediate package creation that is not uploaded) for me to jump through. Have a look at this[1] thread, for example... that's not the full discussion I remember, but I can't find it at the moment. Apart from this: I don't think that Michael did this by intension. Hm, hard to tell. Oh, and for more real-world examples... ] [EMAIL PROTECTED]:/usr/share/doc$ find . -name changelog.Debian.gz | xargs zgrep -i UNRELEASED Regards, Jan [1] http://lists.debian.org/debian-mentors/2007/07/msg00238.html signature.asc Description: Digital signature
review: qstardict (Re: Advocate needs)
On Mon, Sep 03, 2007 at 07:12:18PM +0400, Alexander Rodin wrote: В Пнд, 03/09/2007 в 10:19 -0400, Justin Pryzby пишет: On Mon, Sep 03, 2007 at 06:15:24PM +0400, Alexander Rodin wrote: Hi all! I have develop program (http://qstardict.ylsoftware.com) and maintain Debian package for them. Now I want to put them to Debian. Can anyone to be my advocate? Hi Alexander, Where are the debian sources? Hi, Justin! There is a Debian sources: http://qstardict.ylsoftware.com/files/qstardict-0.07-debian-sources.tar.bz2 . But this have some problem: written by me manpage qstardict.1 don't installs... Some comments. You're the upstream author; why don't you include the manpage upstream instead of in the .diff.gz? I realize that manpages for graphical programs are difficult to write well. Does your program accept keystrokes? Does it have any other help file? Is debian/dirs really necessary? It's probably best if this is handled by upstream install scripts, and debian foo used only as a fallback. Your changelog has two Initial release entries. The second should (by convention) instead read New upstream release.. Since you're the upstream author you can include sub-bullets with the major changes for that release. The copyright file should specify under which versions of the GPL the content is licensed and ideally include the full GPL header (but not the full GPL). doc-base isn't for listing manpage; see dh_installman for how to fix that. Section: universe/devel doesn't make sense for Debian. At least the manpage and rules files should probably have some of their comments removed. Perhaps not all of them though. The only advantage to not removing comments is to easily be able to diff to new templates... +install: build +binary-arch: build install I really wish the redundant dependancy on build was either not specified in the template or that someone would explain to me what purpose it serves. But I already reported it as bug #358722 and apparently knowbody nos. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: normalize-audio (updated package)
Hi, I am looking for a sponsor for the new version 0.7.7-2 of my package normalize-audio. I haven't checked this in detail but a quick look shows additional build-dependencies: Build-Depends: debhelper (= 5), dpatch, autotools-dev, libaudiofile-dev, libmad0-dev, mpg321, vorbis-tools, flac as compared with: Build-Depends: debhelper (= 5), autotools-dev, libaudiofile-dev, libmad0-dev, vorbis-tools As far as I could see the build does not depend on mpg321, vorbis-tools or flac as no audio files are being converted during the build. the reason for the Build-Depends is the configure script. If these packages are not present at build time, the configure script does not generate the default settings needed to call these tools. You can still supply the necessary command line arguments for the enconder/decoder on the command line, but it is quite convenient to have working defaults. Joachim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: normalize-audio (updated package)
Hi Kevin, I am looking for a sponsor for the new version 0.7.7-2 of my package normalize-audio. I haven't checked this in detail but a quick look shows additional build-dependencies: Build-Depends: debhelper (= 5), dpatch, autotools-dev, libaudiofile-dev, libmad0-dev, mpg321, vorbis-tools, flac as compared with: Build-Depends: debhelper (= 5), autotools-dev, libaudiofile-dev, libmad0-dev, vorbis-tools I think you do need dpatch though ... Did you confuse both stanzas? Kapil listed them in reverse order: I *added* the dpatch dependency. Separately, in the control file, is it still necessary to keep: Replaces: normalize Conflicts: normalize since normalize was removed from unstable back in Jan. 2005? I guess it is possible that a system was built back in 2004, or off of an old install disk, and that that system had normalize installed and is still using it. Just wondering how long it makes sense to keep Conflicts/Replaces statements for packages no longer in the archives Good point. Since they are not a large burden, it prefer to keep them for now -- unless someone has a good point to drop them. Is there a general consensus? I couldn't find anything in the docs. Regards, Joachim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian .orig.tar.gz vs. upstream tar.gz
Hi, Kapil Hari Paranjape [EMAIL PROTECTED] wrote: On Mon, 27 Aug 2007, Jörg Sommer wrote: Do *not* get the upstream .tar.gz which may have changed for some mysterious reason. I don't think the upstream tar.gz have changed, but your orig.tar.gz is not the same as the upstream tar.gz. This happens if the orig.tar.gz was repacked to rename the top directory to package-version. dpkg-buildpackage -S does this as described by Policy C.4. Section C.4 describes how to unpack the source without dpkg-source not how it is repacked by dpkg-buildpackage Right, but it's said there that you find a directory package-version.orig. A simple program may fail, when it follows the instructions in section C.4. Bye, Jörg. -- Wer in einem gewissen Alter nicht merkt, dass er hauptsächlich von Idioten umgeben ist, merkt es aus einem gewissen Grunde nicht. (Curt Goetz) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: review: qstardict (Re: Advocate needs)
Thank you! You're the upstream author; why don't you include the manpage upstream instead of in the .diff.gz? I realize that manpages for graphical programs are difficult to write well. Does your program accept keystrokes? Does it have any other help file? I don't include manpage into program sources because it doesn't accept any command line options. Is debian/dirs really necessary? It's probably best if this is handled by upstream install scripts, and debian foo used only as a fallback. Your changelog has two Initial release entries. The second should (by convention) instead read New upstream release.. Since you're the upstream author you can include sub-bullets with the major changes for that release. The copyright file should specify under which versions of the GPL the content is licensed and ideally include the full GPL header (but not the full GPL). doc-base isn't for listing manpage; see dh_installman for how to fix that. Section: universe/devel doesn't make sense for Debian. At least the manpage and rules files should probably have some of their comments removed. Perhaps not all of them though. The only advantage to not removing comments is to easily be able to diff to new templates... +install: build +binary-arch: build install I really wish the redundant dependancy on build was either not specified in the template or that someone would explain to me what purpose it serves. But I already reported it as bug #358722 and apparently knowbody nos. I have fix all this bugs and check package using lintian. -- Alexander Rodin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: review: qstardict
On Mon, 03 Sep 2007 21:55:07 +0400 Alexander Rodin [EMAIL PROTECTED] wrote: You're the upstream author; why don't you include the manpage upstream instead of in the .diff.gz? I realize that manpages for graphical programs are difficult to write well. Does your program accept keystrokes? Does it have any other help file? I don't include manpage into program sources because it doesn't accept any command line options. ? What has that got to do with anything ? A manpage tells a user what a program does without having to run the program - e.g. when interrogating a system over SSH or if X has just died for whatever reason. There is a reason why manpages are necessary for executables and it has nothing to do with what any one particular executable can or cannot actually do. It is about providing information on what the user can do when faced with problems or when the user just needs information without a GUI. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpG6Rgeq8xfj.pgp Description: PGP signature
Re: RFS: xpn
Am Mon, 03 Sep 2007 17:39:54 +0200 schrieb Daniel Leidert: Am Montag, den 03.09.2007, 14:50 +0200 schrieb Norbert Preining: On Mon, 03 Sep 2007, Jan C. Nordholz wrote: * xpn appears to be the first package you release, therefore it must not have a debian revision higher then -1. This has an affect on debian/changelog which should only contain one version. I don't remember that there was a consensus about whether unreleased versions should be kept in the changelog (link appreciated if someone knows better). This will depend on the sponsor's preference, and thus I wouldn't consider it a major problem (but IANADD either). I guess it shouldn't be a problem to start real Debian life with a revision higher than -1, but you have to take care that the .changes file contains a reference to the .orig.tar.gz so that it is uploaded, otherwise it will be missing. But I never tried it. I used to do this for several packages I provided via my personal page before they were added to the Debian distribution. We (my sponsor and me) never had problems with this. In the OPs case, I would suggest to use the This issue seems to be seen controversial. I had chosen the normal revisions because of this page, linked from the Instructions for Maintainers page: http://people.debian.org/~codehelp/#sponsor in particular the second item in the requirements section. - -v option for a .changes file over -1 to -3|uploaded revision How should i use this option exactly? In the newest .changes file only the last log entry is included by default. Using -v1 includes the complete changelog into the .changes file. That is strange, because the man page says: Use changelog information from all versions *strictly* later than version. Well, for the next upload i will use -v1 to include the whole changelog. - -sa option for including the .orig.tar.gz That makes sense. Kind regards, Michael Krauss signature.asc Description: PGP signature
Re: RFS: xpn
Hi, Am Mon, 03 Sep 2007 14:27:40 +0200 schrieb schoenfeld / in-medias-res: Major problems: * xpn appears to be the first package you release, therefore it must not have a debian revision higher then -1. This has an affect on debian/changelog which should only contain one version. there seem to exist different opinions on this issue. I will change it, if necessary. See other mail too. * the script that launches xpn is installed without the executable bit set. this is an error, cause it makes it impossible to start xpn without adding the flag manually. Are you sure, that the executable bit isn't set? Here i get the following: [EMAIL PROTECTED]:~$ ls -l /usr/share/xpn/xpn.sh -rwxr-xr-x 1 root root 559 2007-09-03 20:41 /usr/share/xpn/xpn.sh What looks like i expected. And the program is executable. * README.Debian must not be present if it does not contain any useful information for the users. It should be removed. Done. Minor problems: * debian/changelog has a useless empty line at EOF Done. I am always afraid of that kind of program, which expects a new line at the end of a file. I am sorry. * debian/rules contains some not neccessary empty lines Deleted some. Only the empty lines between two make targets remain. Kind Regards, Michael Krauss signature.asc Description: PGP signature
Re: RFS: xpn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jan C. Nordholz wrote: Why should I try to hide the normal course of development? I don't see I agree that this *is* suboptimal. But it should not be part of normal development cycle to create extra revisions that you do not release, should it? IMHO it makes sense for some developer-only changelog, but the debian/changelog has gotten a file, which is shown to the users often and it might seem odd to them if versions therein do not exist. the necessity to create extra loops (reformatting the changelog after each intermediate package creation that is not uploaded) for me to jump Well you are right in this point. But I seem to develope my packages in another way then you. Cause i only start a new changelog entry, if i really uploaded something through my sponsor to the archive. Hm, hard to tell. Oh, and for more real-world examples... Yeah yeah. I think you are right if you say, that it *is* used and that its okay to be used (even though i don't agree with it), but i would not recommend it either, cause I think there are a lot of sponsors that just will not upload such packages. This opinion results from the fact, that I have seen more people criticizing multiple changelog entries/versions for just a single release, then people that say that it is okay. - -Patrick -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG3Ft5TKIzE6LY9r8RAu3qAKCM3OKsROlvo/OU7nkjr/HnFDoO7gCfazg/ PcJpWBo4fjf4hwaz6aIx6/o= =wdo7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: steam-powered
This sub-thread is discussing whether we *want* software in Debian whose only purpose is to sell non-free software. like i said before, the purpose of the package is to help the average user to easily run the software of their choice on linux. steam does include a store, but it is by no means the only purpose for the software. Software must be DFSG-free to be in Debian. Not all DFSG-free software must be distributed by Debian. if someone is willing to package and maintain it, then why not? i thought the goal was for debian to be the universal operating system. how can the system be universal if software is refused because it is used to run non-dfsg software? if that is the case, then one should reject wine, iceweasel, gcc, and any other software that could be used to run non-dfsg software. as i understand it, to become a debian developer, one has to agree to adhere to the social contract (even if it doesn't fully conform to one's personal feelings -- it is after all for the greater good of the debian project). hence, your argument needs to be made in the context of the social contract, and it is very clear that the contrib and non-free archives are to be supported by debian for those users who require the use of non-dfsg works. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xpn
Hi, Are you sure, that the executable bit isn't set? Here i get the following: [EMAIL PROTECTED]:~$ ls -l /usr/share/xpn/xpn.sh -rwxr-xr-x 1 root root 559 2007-09-03 20:41 /usr/share/xpn/xpn.sh What looks like i expected. And the program is executable. ] dpkg-deb -c xpn_*deb [...] -rw-r--r-- root/root 559 2007-09-03 21:42 ./usr/share/xpn/xpn.sh No, it isn't. You are calling dh_fixperms in your debian/rules... I guess you'll have to tell it not to modify the permissions of that file. Regards, Jan signature.asc Description: Digital signature
Re: RFS: steam-powered
I for one would prefer not to concentrate too much in adding that kind of software to Debian, and even less in trying to promote it if there's no real demand for it beforehand. there is demand. 90% of computer users play games, and steam has a lot of users (3 million players per month [1]). having an easy to install package will ease their transition to an alternative operating system. So, my personal vote, just speaking for myself, is that I'm not willing to devote a single second of my time supporting those programs although i personally disagree (i think free and non-free software can and should coexist equally), i do understand your viewpoint. i will take full responsibility for the package. if it becomes RC-buggy or goes unfixed, i would understand if it were removed from the archive -- of course i will work hard to make sure that doesn't happen. i will not need much support except for someone willing to upload the package. We're not really discussing whether such a package should belong to Debian or not, that's not our task and in any case that kind of discussion should be taken to debian-devel instead. We're not even discussing whether such a package should belong to contrib or to non-free, that discussion should be better handled in debian-legal. And of course, if someone is willing to maintain such a package, it's not gonna be me who forbid them to do so. ok, i will take the discussion to the appropriate lists. i have been trying to address the concerns as they have been brought up on this list. [1] http://www.steampowered.com/v/index.php?area=statscc=US -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Advice on HTML docs
homebank was the subject of an RFS some time ago and had problems with non-GPL licenced SVG images (which, I admit, I completely missed). These were fixed and I uploaded a new upstream version provided by the maintainer but it was rejected because there is no source for the HTML documentation. rejected, the source of doc/*.html is missing. If you look into the files you see a Generator Metatag pointing at GuideML. According to wikipedia (http://en.wikipedia.org/wiki/GuideML) thats a meta-language used to generate files out of it. The history is this: The HTML docs were (once upon a time) created using an Amiga application before the port to Ubuntu/Debian. Upstream now maintain the docs using text editors rather than automated tools - upstream just haven't removed the generator meta tags. The maintainer put a note to this effect in README.Debian prior to the rejection. The docs themselves are nicely done and there is no good reason to recommend one of the standard automated documentation tools which would tend to produce a less polished output overall. README.Debian in the rejected package contains: homebank for Debian --- Homebank is a project born for the amiga, now the author has migrated it to GTK+, the primary development target is linux, but the roadmap previews a macOS port (quite done) and a window$ port. PATCHES TO HTML DOCUMENTATION - If you want to contribute enhancing the html feel free to send patches to the upstream author or to the maintainers of homebank. Consider that the documentation is made using a normal text editor, so a simple patch is fine. -- Francesco Namuri [EMAIL PROTECTED] Mon, 20 Aug 2007 00:57:09 +0200 Does Debian really need to ask upstream for a new release with the meta tags tweaked when there is notice that a normal text editor is used for the docs? The generator tag is historical - an artefact of the original migration from Amiga. OK, README.Debian could be a bit more explicit I know, but what else can / should be done to allow homebank into Debian without requiring a new upstream release? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp2ECDkw3rY2.pgp Description: PGP signature
Re: RFS: normalize-audio (updated package)
On Mon, Sep 03, 2007 at 12:09:41AM +0200, Joachim Reichel wrote.. I am looking for a sponsor for the new version 0.7.7-2 of my package normalize-audio. http://mentors.debian.net/debian/pool/main/n/normalize-audio/normalize-audio_0.7.7-2.dsc You need to complete the debian/copyright a little more as it does not even reference GPL v2, which it is. See the package tnef for an example. A good habit is to run licensecheck -r . from the working directory on every package you work on. A bit picky on my part, but remove the: ## All lines beginning with `## DP:' are a description of the patch. line in debian/patches/*.dpatch files. It just takes up space. You might also consider slightly more verbose descriptions in each patch just to make it easier on yourself (or the next maintainer) a few years from now. Also, make sure to pass on the patches to upstream. Other than that, looking O.K. although I'm unable to build it right now because pbuilder can't seem to pull down the packages: libvorbis0a libvorbisenc2 libvorbisfile3 from the ftp.us.debian.org archives. I'll try again in a little bit. Regards, Kevin -- Kevin Coyner GnuPG key: 1024D/8CE11941 signature.asc Description: Digital signature
Re: RFS: xpn
Michael Krauss wrote: Are you sure, that the executable bit isn't set? Yes. Here i get the following: [EMAIL PROTECTED]:~$ ls -l /usr/share/xpn/xpn.sh -rwxr-xr-x 1 root root 559 2007-09-03 20:41 /usr/share/xpn/xpn.sh That is why you should use something like pbuilder etc. to test your packaging, cause its bad to test things in an environment where other conditions might be met. Just sidenoted. Done. I am always afraid of that kind of program, which expects a new line at the end of a file. I am sorry. Well, i think not everybody finds that bad. I find it ugly. Thats why i told you to better remove it. * debian/rules contains some not neccessary empty lines Deleted some. Only the empty lines between two make targets remain. Yeah, fine. Those empty lines between the targets are good. I just thought that those empty lines in between commands in a target are silly, or double-empty lines. So well: I have checked your new version -4 and I'm afraid that it builds up a bogus link to the binary. You must not use absolute pathes in the links, as this will fail on systems other then the one were the package is built (and ofcourse it will not work after removing the src directory)- I would recommend you to use dh_link. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xpn
Am Montag, den 03.09.2007, 20:59 +0200 schrieb Michael Krauss: Am Mon, 03 Sep 2007 17:39:54 +0200 schrieb Daniel Leidert: Am Montag, den 03.09.2007, 14:50 +0200 schrieb Norbert Preining: [..] I guess it shouldn't be a problem to start real Debian life with a revision higher than -1, but you have to take care that the .changes file contains a reference to the .orig.tar.gz so that it is uploaded, otherwise it will be missing. But I never tried it. I used to do this for several packages I provided via my personal page before they were added to the Debian distribution. We (my sponsor and me) never had problems with this. In the OPs case, I would suggest to use the This issue seems to be seen controversial. I had chosen the normal revisions because of this page, linked from the Instructions for Maintainers page: http://people.debian.org/~codehelp/#sponsor in particular the second item in the requirements section. This sounds like the common way and it is similar to what I suggested. - -v option for a .changes file over -1 to -3|uploaded revision How should i use this option exactly? In the newest .changes file only the last log entry is included by default. Using -v1 includes the complete changelog into the .changes file. That is strange, because the man page says: Use changelog information from all versions *strictly* later than version. Yes, it says version, not Debian revision. The options expects the full version, including the upstream version and the Debian revision. Say you have 1.2.3-0mk1 private 1.2.3-1 released to mentors 1.2.3-2 released to mentors 1.2.3-3 released to Debian then use `-v1.2.3-0mk1'. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Advice on HTML docs
Neil Williams [EMAIL PROTECTED] writes: These were fixed and I uploaded a new upstream version provided by the maintainer but it was rejected because there is no source for the HTML documentation. rejected, the source of doc/*.html is missing. If you look into the files you see a Generator Metatag pointing at GuideML. According to wikipedia (http://en.wikipedia.org/wiki/GuideML) thats a meta-language used to generate files out of it. The history is this: The HTML docs were (once upon a time) created using an Amiga application before the port to Ubuntu/Debian. Upstream now maintain the docs using text editors rather than automated tools - upstream just haven't removed the generator meta tags. The maintainer put a note to this effect in README.Debian prior to the rejection. I think the only problem may be that the note isn't in the place they looked. I have a package with a similar problem (openafs-doc) and it was approved, but I put the note to that effect in debian/copyright, which is the file that the ftp-masters review for these sorts of issues and which is the place to note the provenance and licensing of the source. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xpn
Hi Patrick, Well you are right in this point. But I seem to develope my packages in another way then you. Cause i only start a new changelog entry, if i really uploaded something through my sponsor to the archive. I usually do it that way, too. But there are cases when I have to create intermediate packages anyway, e.g. preparing a new major version which I'd like to test at work before I consider it ready for upload... installing something on 100+ computers is easier if you create .deb's and throw them into a private repository - and I wouldn't mind increasing the version number after each test cycle if the number of new changelog entries warrants it. If the point is that users shouldn't see changelog entries which they've never seen the corresponding package version to, then we should start merging all changes made during a number of uploads to experimental in one single big blob when a new upload to unstable is made - the users of unstable have never seen those experimental versions, so we have to artificially make it look like they have never happened? I, too, remember there was a quite strong opposition - but I'm still searching for the thread. (Besides, I wouldn't call the Debian changelog a user-exposed file - its contents are often quite cryptic to the casual user (updated po files... rediffed patch foo and blorb, minor changes to work nicely with libbar...), and the more experienced can live with a few more interspersed numbers. ;) ) Regards, Jan signature.asc Description: Digital signature
Re: RFS: libsbc (updated package)
2007/8/9, Krzysztof Burghardt [EMAIL PROTECTED]:
2007/7/28, Krzysztof Burghardt [EMAIL PROTECTED]:
I am looking for a sponsor for the new version 0.0cvs20070728-1
of my package libsbc.
It builds these binary packages:
libsbc-dev - Development files for subband codec (SBC) library
libsbc0- Subband codec (SBC) library
sbcinfo- Subband codec (SBC) analyzer
The package appears to be lintian clean.
The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/libsbc
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/l/libsbc/libsbc_0.0cvs20070728-1.dsc
I would be glad if someone uploaded this package for me.
I'm still looking for sponsor. This is really small library and
changes aren't too big:
* New upstream checkout
* Add debian/get-orig-source.sh
* Add autotools clean rules
* Fixed dependency to use ${binary:Version} instead of ${Source-Version}
* Changed package build rules to not ignore make clean return code
This little package is waiting for its sponsor for 1 month. Anyone?
With regards,
--
Krzysztof Burghardt [EMAIL PROTECTED]
http://www.burghardt.pl/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: eprints
Le Thu, Aug 30, 2007 at 03:17:18PM +0100, David C Tarrant a écrit : Dear mentors, I am looking for a sponsor for my package eprints. Making Research Freely Available - For many years we have been helping researchers and their institutions to provide free online access to their research output (documents, multimedia and data). Dear David, did you find a sponsor? If not, you can also try your luck on the debian-science mailing list. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
