RFS: Need help packaging MMS (My Media System) and get it into Debian
Hi there! For over 3 years now I help out on a multimedia-project named MMS - 'My Media System' - fka: 'Mpeg Menu System V2' (see: mms.sunsite.dk). It's a multimedia system running with several input and output devices (SDL, Dxr3, FF-DVB), providing Audio, Pictures, Movie, Games, TV, EPG ... For now it only was available if one compiles it ... So we realy would like to see it as part of debian, as we think it's stable, tested and well documented. I started packaging (with the help of the web and some maintainers of VDR) but am new to packaging at all ;) So here's my wish: Is someone here willing to help packaging (maintaining the deb?) and show me a way on how to get it into Debian? My main focus right now is to get MMS packaged ... there are some questions coming up regarding this. I think for debian the package (apart from as it is now) should be split up into a 'mms-common' and various output-related 'mms-output'-packages. Getting it into Debian would help a lot easy down the usage cause of easy installation! Anyone here willing to help? A testing deb for edgy (cause of an article in a computer-magazin which should come up) and the corresponding sources (both created with pbuilder, tested with lintian and test-compiled in sid) could be downloaded from www.prodeia.de/mms We even just corrected some things in the upstream to reflect filesystem standards (like putting config-files changed at runtime into /var/lib/mms, putting recreateable files into /var/cache/mms, etc. ...) The Wiki and forum could be reached from mms.kicks-ass.org Thx and Lg Roman -- Prodeia * Projektdienstleistung, Beratung, Organisation -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: podget
Dave Vehrs wrote: http://mentors.debian.net/debian/pool/main/p/podget/podget_0.5.8.dsc * do not build a native package. * don't use two empty lines as seperator in changelog, one is just enough. * debhelper (= 4.0.0) is over-precise, debhelper (= 4) is just enough. * remove the empty lines at the end of control * dirs is empty, remove it, same with docs. * remove the useless commented stuff in rules. * if you don't use the configure: target, remove it completely. * you strongly recommend to really use the dh_* calls in binary-indep:, and not doing things on your own. look at the dh_make templates if unsure what i mean. * remove the empty lines at the end of rules. if you fix the things above, i'm sponsoring the package. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: podget
Hello Dave, It builds these binary packages: podget - Podcast aggregrator/downloader optimized for cron The package is lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/podget - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/podget/podget_0.5.8.dsc I would be grateful if someone would upload this for me. I've checked it out, and have the following comments: * The package is Debian native, but the software is not Debian specific. The customary way to package software that has an upstream is to use the non-native packaging, which makes the package consist of a .orig.tar.gz from upstream and a .diff.gz for Debian. This clearly separates what modifications are done by Debian. There's a bit of text about this in the FAQ: http://people.debian.org/~mpalmer/debian-mentors_FAQ.html * The upstream tarball contains a debian dir. This is not desirable at all; there have been quite some discussions on this list about that. Please ask upstream to not release tarballs with a debian dir in it. Keeping the debian dir in upstream cvs is not a problem, as long as its clearly separate and not in released code. * debian/docs and debian/dirs are empty, they can be removed. * debian/rules looks good, but you make a bit of a mix between invoking the debhelper tools and doing things directly (mkdir, dpkg-deb, etc). I wonder why not use the existing debhelper tools, like dh_installdeb ? thanks for your work! Thijs signature.asc Description: This is a digitally signed message part
Re: RFS: podget
Daniel Baumann wrote: * you strongly recommend to really use the dh_* calls in binary-indep:, and not doing things on your own. look at the dh_make templates if unsure what i mean. jftr: this should have been 'i strongly recommend'. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
distclean is not executed after building the package...
Hello Mentors, I was thinking the distlean: target from the debian/rules is executed after building the package, but it seems not, because my debian/rules is 8-- #!/usr/bin/make -f # # Rules for making the tdapp-defaults package # Copyright (C) 2006 Michelle Konzack [EMAIL PROTECTED] # SHELL = /bin/bash XTOOLS:= $(patsubst %-blackwhite,%,$(notdir $(wildcard themes/blackwhite/*-blackwhite))) L10N := $(filter-out C,$(patsubst %.po,%,$(notdir $(wildcard l10n/*.po THEMES:= $(filter-out blackwhite,$(patsubst %.theme,%,$(notdir $(wildcard themes/*.theme LANG_PO := $(patsubst %.po,%,$(notdir $(wildcard po/*.po))) PKGVERS := $(shell head -n1 debian/changelog |sed 's/.*app-defaults\ (//;s/).*//') SRCVERS := $(patsubst tdapp-defaults-%,%,$(notdir $(PWD))) YEAR := $(shell date +%Y) RECOMMEND := xbmbrowser, xcolorsel, xfontsel, xterm, bitmap, pixmap SUBDIRS := . datadir l10n man po themes user clean: dh_testdir dh_clean distclean: clean distclean-make distclean-make: dh_testdir make distclean config: dh_testdir make maintainer-config make config build: config build-make build-make: dh_testdir make build install: install-debian install-make install-debian: dh_testdir dh_installdirs install-make: dh_testdir make install binary: binary-indep binary-arch binary-indep: install-make dh_testdir dh_installchangelogs dh_installdocs --all changelog README README.Policy TODO dh_installman dh_installmenu dh_install dh_compress dh_fixperms dh_installdeb dh_gencontrol dh_md5sums dh_builddeb # make distclean binary-arch: # Nothing to do here snip .PHONY: clean distclean distclean-make config build build-make install install-debian install-make binary binary-indep binary-arch 8-- if I put the make distclean after the dh_builddeb I get a clean source back... Any ideas what is happen to me? Oh yes, the whole package is building fine now... Thanks, Greetings and nice Day Michelle Konzack -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
patch does not more work...
Hello *, I have a weired problem with: 8-- patch -t -N -R --dry-run doc/Xdialog.man debian/xdialog.man.diff patch -t -N -R doc/Xdialog.man debian/xdialog.man.diff patch: Can't create file /tmp/xterm2713/poVisMLt : No such file or directory make: [clean-patched] Fehler 2 (ignoriert) 8-- Never I have seen patch using something like /tmp/xterm2713/poVisMLt. Any suggestions? Thanks, Greetings and nice Day Michelle Konzack -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: distclean is not executed after building the package...
also sprach Michelle Konzack [EMAIL PROTECTED] [2007.01.11.1802 +0100]: I was thinking the distlean: target from the debian/rules is executed after building the package, but it seems not, bad thinking, good observation. it would be a bug otherwise. next time, please don't dump lines and lines of unrelated makefile stuff into emails. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems NP: Masters Of Reality / Deep In The Hole signature.asc Description: Digital signature (GPG/PGP)
Gjay Bcoys On Bqed Swucking MGONSTERCOCK At Home
Hey, man! :) Pqretty Wlhore Ddeepthroating MOINSTERCOCK Gkets Flacial Ave! :) http://own.joifpen.com/ Prornstar Julia Baond As Cxop Jzerks Riides GIGANTCOCQK Your fortune is not something to find but to unfold.People say that life is the thing, but I prefer reading. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Library sonames and unstable libraries
On Wed, Jan 10, 2007 at 12:29:21AM -0500, Hubert Chan wrote: Assuming that I want to publish some at least partially useful packages (for a start, much of the use will be via python bindings rather than linking against the .so) until upstream has committed to an soname policy, and made a stable release, would it be acceptable to use experimental for this (ie where the package is otherwise policy-clean but doesn't have clean soname bumps during the tracking of SVN snapshots) or should I stick to having this in my private webspace (and losing autobuilding, bugtracking and other bits and pieces of functionality)? I believe that packages in experimental must still follow policy, so you shouldn't use experimental unless you figure out how to handle the sonames. If use will be limited to the Python bindings, you may be able to get away with making the C libraries private and sticking them in /usr/lib/mapnik, at least for now. (And, you would probably skip out on the -dev package.) Otherwise, your options are probably to just use your own private webspace, or make the library into a static library. Again, thanks for comments. Actually I could use an soname of libmapnik.so.0d for now (idea from Josselin Mouette's talk that I recently watched the video of :) which I can increment to my heart's content until upstream makes a release with an soname. As I understand it moving from libmapnik.so.0d (package name libmapnik0d) or for that matter libmapnik.so.1d to a future official libmapnik.so.0 shouldn't be a problem should it - the ordering of sonames doesn't matter? Cheers, Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: patch does not more work...
Hello *, I have a weired problem with: 8-- patch -t -N -R --dry-run doc/Xdialog.man debian/xdialog.man.diff patch -t -N -R doc/Xdialog.man debian/xdialog.man.diff patch: Can't create file /tmp/xterm2713/poVisMLt : No such file or directory make: [clean-patched] Fehler 2 (ignoriert) 8-- Never I have seen patch using something like /tmp/xterm2713/poVisMLt. Have you set $TMP, $TMPDIR or the like (to /tmp/xterm2713 ...); in other words, does something like mktemp still work? Best, Michael pgpWQo2oaSbCG.pgp Description: PGP signature
Re: patch does not more work...
Hello Michael, Am 2007-01-11 19:33:24, schrieb Michael Tautschnig: Have you set $TMP, $TMPDIR or the like (to /tmp/xterm2713 ...); in other words, does something like mktemp still work? Best, Michael - END OF REPLIED MESSAGE - Maybe it is an XTerm bug... Normaly I set TMPDIR in my .bashrc or .xsession but it seems, that Etch does not use it and it is erased from the environement... If I run a XTerm and set manualy TMPDIR then all is working fine... Currently I am updating to a newer version... Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
RFS: fbxkb
Dear mentors, I am looking for a sponsor for my package fbxkb. * Package name: fbxkb Version : 0.6-1 Upstream Author : Anatoly Asviyan [EMAIL PROTECTED] * URL : http://fbxkb.sf.net * License : GPL like Section : x11 It builds these binary packages: fbxkb - X11 keyboard indicator and switcher The package is lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/f/fbxkb - Source repository: deb-src http://mentors.debian.net/debian ustable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/f/fbxkb/fbxkb_0.6-1.dsc I would be glad if someone uploaded this package for me. Kind regards Vadim Vatlin -- Vatlin V.G. signature.asc Description: Digital signature
Re: RFS: fbxkb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Vadim, - -=| Vadim Vatlin, 11.01.2007 22:41 |=- * Package name: fbxkb Version : 0.6-1 Upstream Author : Anatoly Asviyan [EMAIL PROTECTED] * URL : http://fbxkb.sf.net * License : GPL like Section : x11 It builds these binary packages: fbxkb - X11 keyboard indicator and switcher The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/f/fbxkb I would be glad if someone uploaded this package for me. I can't sponsor the package, but I have some small comments (some of which may well be wrong). * You seem to heavily patch the manpage. The original manpage looks like it is taken from another binary (fbpanel). Please remember to send changes upstream. * You don't invoke make clean in your debian/rules' clean target. To see why this is bad, try building the package twice with dpkg-buildpackage (not pbuilder). * config.h is included in the diff, although it is generated as part of the build process. It'd be better if you simply remove in the clean target of debian/rules (and send patch upstream so make clean does this too) * Why do you build-depend on autotools-dev? I see to auto* usage in debian/rules - just simple ./configure; make. Did you try building the package with pbuilder without autotools-dev? Overall I'd be very glad to see this package in Debian and use it. Gnome's keyboard applet uses layout names instead of flags and this makes it hard to quickly see what is the active layout. Kind regards, dam - -- Damyan Ivanov Modular Software Systems [EMAIL PROTECTED] phone +359(2)928-2611, 929-3993 fax +359(2)920-0994 mobile +359(88)856-6067 [EMAIL PROTECTED]/Gaim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFpq4YHqjlqpcl9jsRAtk5AJsElTxeVFcC0yn+F4DPsfXmkaqQhACfUkIq 5En1nd8VetQbq2Kr3WFaXU4= =dUQj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: RFS: Legends: The Game
Hi Daniel, Legends is non-free so it's only distributed as a binary package. The .deb we created just packages the game data in a .deb format. It was created with dpkg -b ./debian legends_linux-0.4.1.42.deb where ./debian contained: ./DEBIAN/control ./DEBIAN/postinst ./DEBIAN/postrm ./usr/ ./usr/games/ ./usr/games/legends/ ./usr/games/legends/ReadMe.txt ./usr/games/legends/ReadMe_legals.txt ./usr/games/legends/show/ ./usr/games/legends/show/ui/ ./usr/games/legends/show/defaults.cs ./usr/games/legends/show/scripts/ ./usr/games/legends/show/main.cs ./usr/games/legends/show/ui.unf ./usr/games/legends/show/scripts.unf ./usr/games/legends/ReadMe_QuickStart.txt ./usr/games/legends/legends/ ./usr/games/legends/legends/data/ ./usr/games/legends/legends/data.unf ./usr/games/legends/legends/prefs/ ./usr/games/legends/legends/prefs/mapcycle.cs ./usr/games/legends/legends/prefs/adminuserlist.cs ./usr/games/legends/legends/scripts/ ./usr/games/legends/legends/main.cs ./usr/games/legends/legends/interiors.unf ./usr/games/legends/legends/scripts.unf ./usr/games/legends/legends/voices.unf ./usr/games/legends/legends/sounds.unf ./usr/games/legends/legends/missions.unf ./usr/games/legends/OPENAL32.DLL ./usr/games/legends/LinLegends ./usr/games/legends/main.cs ./usr/games/legends/libSDL-1.2.so.0 ./usr/games/legends/libSDL-1.3.so.0 ./usr/games/legends/common/ ./usr/games/legends/common/edit/ ./usr/games/legends/common/edit.unf ./usr/games/legends/common/main.cs ./usr/games/legends/common/client/ ./usr/games/legends/common/server.unf ./usr/games/legends/common/server/ ./usr/games/legends/common/client.unf ./usr/games/legends/common/ui.unf ./usr/games/legends/ispawn ./usr/games/legends/runlegends ./usr/games/legends/update ./usr/games/legends/lindedicated ./usr/games/legends/libvorbis.so.0 ./usr/games/legends/default.keybinds.txt ./usr/games/legends/libopenal.so ./usr/games/legends/legends.ico ./usr/games/legends/linux.txt ./usr/games/legends/libogg.so.0 So, there is no .dsc or orig.tar.gz. Although you can do $ ar x legends_linux-0.4.1.42.deb data.tar.gz to get what would be the orig.tar.gz You can just create such a snapshot tar.gz and produce based on this the debs. Sorry, I don't understand what this means. This is my first attempt at building a .deb.
Re: Library sonames and unstable libraries
On Thu, 11 Jan 2007 17:32:49 +, Dominic Hargreaves [EMAIL PROTECTED] said: Actually I could use an soname of libmapnik.so.0d for now (idea from Josselin Mouette's talk that I recently watched the video of :) which I can increment to my heart's content until upstream makes a release with an soname. As I understand it moving from libmapnik.so.0d (package name libmapnik0d) or for that matter libmapnik.so.1d to a future official libmapnik.so.0 shouldn't be a problem should it - the ordering of sonames doesn't matter? Yes, I think that's correct. But although the ordering of sonames doesn't matter technically, it does matter from a human standpoint. It may be confusing for someone to find out that, say, libmapnik.so.5d is older than libmapnik.so.0. So you may want to call your sonames something like .0.0.d, and just bump the minor revision number (so you always keep the initial 0). Or maybe you want to use an soname like .0.debian (instead of just .0.d), to make it more explicitly clear that it's a Debian name. Anyways, one reason that I would suggest not to do that is because every time you bump the soname, you also need a new binary package name, which means that the package will have to sit in the NEW queue for who-knows-how-long. But that's just my opinion, and if you are willing to put up with that, that's up to you. -- Hubert Chan [EMAIL PROTECTED] -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: Legends: The Game
On Fri, Jan 12, 2007 at 09:15:28AM +1100, Tim Hessint wrote: So, there is no .dsc or orig.tar.gz. There needs to be a source package in a Debian upload. A source package consists of a .dsc plus the files it references. Until you have a source package, there's no way your package can be uploaded, into non-free or any other part of Debian. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: Legends: The Game
Tim Hessint wrote: Legends is non-free so it's only distributed as a binary package. The .deb we created just packages the game data in a .deb format. It was created with it does not make any difference if the stuff in the orig.tar.gz are binary-only files which are just copied, or, if the files are source code which need to be compiled: there have to be the package sources available (orig.tar.gz, diff.gz and dsc file). Sorry, I don't understand what this means. This is my first attempt at building a .deb. just to make sure that we are talking about the same things: did you read the debian new maintainer guide, available at: http://www.us.debian.org/doc/manuals/maint-guide/ -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: fbxkb
Vadim Vatlin wrote: http://mentors.debian.net/debian/pool/main/f/fbxkb/fbxkb_0.6-1.dsc in addition to what damyan has already pointed out: * the suggests on menu is bogus. * do not use french-spacing in long description * remove the useless whitespaces at the end of the two last lines of the long description. * the build-depends on autotools-dev is not needed here. * remove the two whitespaces at the end of Upstream Author: and Copyright: line. * no french spacing in copyright * installing README through docs doesn't make any sense, it's an empty file * remove the useless commented stuff in rules * this is not needed: ---snap--- # These are used for cross-compiling and for saving the configure script # from having to guess our platform (since we know it already) DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) ---snap--- * you should pass CFLAGS to ./configure * remove the unused dh_* calls which are not required in your package, e.g. dh_installexamples. if you fix above things, i'm happy to sponsor your package. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: RFS: Legends: The Game
Thanks for the link to the new maintainers guide. It'll be a week or two before I get chance to rebuild the package. What's the best way to proceed after I've made the package according to that guide? Should we post a new RFS here or in devel-games, or just reply to this. I'm still unsure as to whether this will be accepted into Debian. It's a fairly large package for Debian to add to its mirrors, especially as it's non-free. I haven't been able to find any other non-free games in Debian (I'm not a Debian user BTW...nobody's perfect ;) ), so it'd be nice to know the likelihood of acceptance before I rewrite the script that creates all our packages. Thanks for your help
Re: RFS: fbxkb
Thanks for help. I have corrected the package. -- Vatlin V.G signature.asc Description: Digital signature
Re: RFS: fbxkb
On 00:24:25 Янв 12, 2007, Daniel Baumann wrote: I have corrected the package and uploaded it once more. Please check it out again. If some mistakes remain, let me know, please. -- Vatlin V.G signature.asc Description: Digital signature
