On Monday 01 June 2009 02:06:03 Felix Arreola Rodriguez wrote: > I wish talk English, too many documentation, I can't understand all... Sry when this is a little bit too harsh, but this any valid excuse if you want to create a debian package. As I said before: Try to get a co maintainer who can read english. Most stuff in debian is quite bureaucratic and you must read a lot of documentation.
> > Your key seems not to be trusted by many people. You should think about > > creating a new one[1] and get some signatures by some debian developers. > > With that you can get a debian maintainer[2] and upload new versions of > > your packages by yourself. A good idea is to seperate the certification > > (main key) from the signatur key. You have currently both in your main > > key (see the SC in the usage by calling `gpg --edit-key 223D869A`). > > Ok, about my gpg key. I have some sign from my friends, but, I don't > understand waht you mean with "seperate the certification key". I'm some > new in the gpg world. The default is to create a master key which can be used to sign and certificate (aka create signatures on your key/other keys). You don't need to do that, but I just wanted to give a small hint. This has nothing todo with this package/ITP. > > Now to your package. Your tar.gz differs from the one I get from > > upstream. Never ever to that without calling your version 1.5+dfsg1-1 > > instead of 1.5-1 and provide a debian/prune-tarball.sh script. Don't > > forget to add information about what and why the package was manipulated. > > > > 3747bb55b8dce55afc585b1ccb557297 Mupen64Plus-1-5-src.tar > > 15f026b6658c7deda1385840d7376065 mupen64plus_1.5.orig.tar > > c224b045d343ff02f6f933d328861b01 Mupen64Plus-1-5-src.tar.gz > > 5c8aac7b0456e04099ba843bc4e484db mupen64plus_1.5.orig.tar.gz > > > > This alone is a reason to ignore your package and never look at it again. > > As it seems that you have not changed the files inside the package their > > is no reason to create a modified tar.gz. The only change is the name > > of the toplevel directory. Please don't do that. dpkg-source is > > intelligent enough to do that modification by itself when it unpacks the > > source package. So please use the tar.gz from upstream without any > > modifications if the source tar.gz doesn't violates the dfsg - otherwise > > create a dfsg clean version and rename your version number as told above. > > Rename Mupen64Plus-1-5-src.tar.gz to mupen64plus_1.5.orig.tar.gz and > > replace your old mupen64plus_1.5.orig.tar.gz with that one. Afterwards > > rebuild your package with `debuild -sa` and reupload it to mentors to > > override the tar.gz on mentors. This will not work when you uploaded it > > to the archives. > > > > `lsdiff -z mupen64plus_1.5-2.diff.gz` shows that you modified files > > outside of the debian directory. Don't to that. If you need to modify > > such files then use patches. A good idea is to use quilt[3] for that. > > > > Your debian directory is really messy. Please remove example files: > > $ rm debian/*.ex debian/*.EX > > Ok, all of this, i don't have idea. I'm talk spanish, and I'm trying to > understand this. I made too many mistakes, I know. Please don't argue with your mother-tongue. I never learnt english in school and it isn't my mother-tongue. If you have specific questions about something I said then please ask them. > > You don't close this bug with "Initial release (Closes: #513322)" in the > > first entry of your changelog. > > The package was made before I own the bug. I forget to change this. If you would have uploaded the package even without owning the bug then you would have "fixed" the bug without marking it as such. Please keep in mind to close bugs by writing their number in the changelog. The format should be: (Closes: #123456) for debian bugs (Closes LP: #123456) for bugs in ubuntu. Please also subscribe to the ubuntu bugtracker[1]. > > You tell that you build the gtk version of the packe but don't depend > > strictly on it - please remove the " | libqt4-dev" from the build > > depends. > > Oh, I was thinking in making 2 packages, One with the libgtk and another > with qt4, so, I think that I can use the same source. So, in this case, > I will make two sources seperate. Removed. If you wanted to do that you had to depend on both (without the | which would mean that you only need one of them and not both when building). > > Many useless dependencies. Fix the build scripts or read many things > > about -Wl,--as-needed (see dpkg-shlibdeps warnings). > > Useless dependencies? I will check this one. > > > You don't have a debian/watch file. Try: > > =============================== > > version=3 > > > > opts="uversionmangle=s/-/./" \ > > http://code.google.com/p/mupen64plus/downloads/list \ > > http://mupen64plus.googlecode.com/files/Mupen64Plus-(.*).src\.tar.gz > > > > =============================== > > and test it with `uscan --debug`. > > debian/watch? I don't even know about this one. This file is used to check the upstream for new versions. Search for debian external health status. > > You use debhelper 7 and call `dh_clean -k`. Don't do that. It is > > not allowed anymore. Replace this call with `dh_prep` (without the -k). > > You are also removing top level directory stamp files with rm. > > Please don't do that either. dh_clean will do it for you. > > mmm... > > > Plugins gets installed in /usr/share, Shouldn't they go to > > /usr/lib/mupen64plus (arch dependent files aren't allowed in /usr/share)? > > I supose that the plugins are not arch dependent files, but, it's true, > the path it's not ok. They are arch dependend. They are compiled for a specific architecture thus they must get moved out of /usr/share (you will not be able to run a amd64 plugin on ppc for example). > > Why does it conflicts with mupen64(-bin)? I cannot find files which > > would conflict with it and I doubt that there are runtime conflicts. > > Because mupen64(-bin) is an older version of mupen64, and I think that > they should not be together. > I find this packages in another unoffical's repos. But they dont share any files at all - their is no need to conflict here. Both can be used on the same machine. I am not sure about unofficial packages conflicts in the policy. Maybe you should check it. > Again, more time to work in this one. You will receive a mail about a git repo on alioth. Their was one for mupen64plus thus I asked the owner to import your stuff and maybe fix one or two things. Something I forgot: You have to add "XS-Autobuild: true" to a non-free package to enable the build infrastructure of debian[2]. [1] https://bugs.launchpad.net/ubuntu/+source/mupen64plus [2] http://lists.debian.org/debian-devel-announce/2006/11/msg00012.html -- Robert Wohlrab -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
