Re: RFS: chmsee (updated package)
On Tue, Aug 14, 2007 at 10:08:51PM +0800, LI Daobing wrote: Dear mentors, Hello Li... The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/chmsee - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/chmsee/chmsee_1.0.0-1.dsc debian/changelog: [EMAIL PROTECTED]:~/debian/chmsee$ diff -Naur old/chmsee-1.0.0~beta2/debian new/chmsee-1.0.0/debian | wc -l 162 You have changed really many lines in the debian/ directory but you write a changelog of 3 lines in total, you didn't even mention the changes on the build-depends and depends which seems to be quite important for me. debian/copyright: Please reformat this file, so that you everywhere use the same amount of whitespaces etc. That's just for the eye but I think it's important to have nice copyright files... Regards, -- .''`. Mario Iseli [EMAIL PROTECTED] : :' :Debian GNU/Linux developer `. `'` `- Debian - when you have better things to do than fixing a system -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: oggconvert (updated package)
Oleksandr Moskalenko wrote: uploaded Thank you. Again, sorry for my mistake. -- Luca -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
what is a suitable crypto key for a developer?
Hello, I read the pages at[0], [1], [2], [3], [4] but did not find a suitable guide / recommendation for non-english characters. Are foreign (UTF-8) characters accepted into the uid of a key? My uid has a é letter and I am not sure if it will cause trouble. Should I use a e letter instead, despite not being my actual name? Regards. André Felipe Machado [0] http://www.debian.org/devel/join/nm-step2 [1] http://www.debian.org/events/keysigning [2] http://webber.dewinter.com/gnupg_howto/english/GPGMiniHowto-3.html [3] http://www.debian.org/doc/packaging-manuals/developers-reference/ch-developer-duties.en.html#s-key-maint [4] http://www.debian.org/doc/packaging-manuals/developers-reference/ch-new-maintainer.en.html#s-registering -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: what is a suitable crypto key for a developer?
andremachado [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello, I read the pages at[0], [1], [2], [3], [4] but did not find a suitable guide / recommendation for non-english characters. Are foreign (UTF-8) characters accepted into the uid of a key? My uid has a é letter and I am not sure if it will cause trouble. Should I use a e letter instead, despite not being my actual name? Regards. André Felipe Machado Yes you may use the UTF-8 character. As per the relevent standard (current draft) http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-22.txt #5.11. User ID Packet (Tag 13) # #A User ID packet consists of UTF-8 text that is intended to #represent the name and email address of the key holder. By #convention, it includes an RFC 2822 mail name-addr, but there are no #restrictions on its content. The packet length in the header #specifies the length of the User ID. If you use GPG to generate the key, then all should be fine. Please folow the normal UID format (Which GPG will enforce, by default, unless you explicitly override it). If you find that anything breaks due to the UTF-8 encoding, please let us know, as it is a bug. However, other Developers have used UTF-8 in the User ID without problem, so this is unlikely. Disclamer: IANAL. IANADD. This is not an official policy statement. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: irrlicht
Yesterday night I uploaded to mentors a new version of the package. Changes: * debhelper files are now generated from templates so the package version information (except debian/control) is updated automatically by debian/rules. * Added -dbg package * Added -D_REENTRANT * $(version) and $(major) are manually set now (but there's a check that makes sure that include/IrrCompileConfig.h says the same as those two vars) * Fixed build-depends * merged the two binary-arch- build targets * moved headers to include/Irrlicht1.3.1 (with symlink at include/Irrlicht) TO CHECK (comments on this please): * irrlicht seems not to be compiled with zlib/libpng/libjpeg support * -fPIC is only used when building the .so file but not when compiling the source files (is it ok this way?) * whether to use the .pc file or not (personally I see no advantage, what do you think Brandon?) * Should the .chm file be shipped in the -doc package or only the HTML documentation? * what to do with the media/ files in the -examples package (some files are not free like dx's logo, opengl logo; there's also the lucida font in a .png file so I'm not sure it is ok) * lintian complaining about missing soname On 13/08/07, Raphael [EMAIL PROTECTED] wrote: On 10/08/07, Brandon [EMAIL PROTECTED] wrote: 1) It appears that the irrlicht engine is incompatable with the libjpeg engine that comes with debian. I have attached a log with errors. This is from compiling, and then running, 02.Quake3Map. However, after checking the versions, it seems irrlicht comes with the exact same version as debian, 62 (or 6b). I don't know what to make of it. I'll see what I can do. 2) Your examples do not compile with make. It looks like you copied the Makefiles straight across. You'll have to edit them. From the examples directory, there is no ../../bin/Linux, ../../include, or ../../lib. Hmm, ok. 3) It's always nice when libraries have dbg versions. I think all you would have to do is create the dbg package, then strip the libraries of their debug symbols, and use that for the end-user package. Just added the necessary modifications. 4) You are missing some build flags, such as -fPIC and -DREENTRANT. See the policies for more info, and possibly more requirements. http://www.debian.org/doc/debian-policy/ch-files.html -fPIC is already being used by upstream's Makefile. I'll add -D_REENTRANT. About -fPIC I would like to know what to do when building the static lib, because as I said, upstream's Makefile uses it for both, shared and static. -Brandon -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: linux-patch-debianlogo - Display a Debian logo on a framebuffer device at boottime
Hello mentors,
I'm looking for a sponsor for the new version of the linux-patch-debianlogo
package which is available at:
http://pkg-debianlogo.alioth.debian.org/linux-patch-debianlogo_1.7/
http://pkg-debianlogo.alioth.debian.org/linux-patch-debianlogo_1.7/linux-patch-debianlogo_1.7.dsc
Currently linux-patch-debianlogo is maintained by Stefano Melchior and
Emanuele Rocca (both CCed) but I got the explicit permission of Emanuele
Rocca to add myself to Uploaders and get 1.7 uploaded myself.
I'd be glad if someone could sponsor the package, since it adds support for
recent kernel versions. The complete changelog for version 1.7 reads:
linux-patch-debianlogo (1.7) unstable; urgency=low
.
[ Frank S. Thomas ]
* Added support for Linux 2.6.19, 2.6.20, 2.6.21 and 2.6.22.
(Closes: #420246)
* debian/README.Debian: Replaced kernel-patch-debianlogo with
linux-patch-debianlogo and added reference to the tux-with-swirl.png
image in /usr/share/doc/linux-patch-debianlogo.
* Updated debhelper compatibility level from 4 to 5 since this is the
current recommended level.
* debian/control:
- Added myself to Uploaders with permission of Emanuele Rocca.
- Added XS-Vcs-{Svn,Browser} fields to source stanza.
Thanks in advance and regards,
Frank
signature.asc
Description: This is a digitally signed message part.
Re: RFS: gconf-cleaner - GConf database cleaner
On Aug 09 2007, Paul Wise wrote: Some minor issues: AUTHORS file doesn't need to be installed (debian/copyright covers it) Actually, some times it doesn't. You can see for yourself in the xine-lib that I have one contribution of a deinterlacing algorithm and some PowerPC porting, but there is no mention of it in Debian's packages. OTOH, in RPM-based distributions, my name is there. Regards, Rogério Brito. -- Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8 http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
advice on maintainting packages on alioth ?
Hello mentors, In future, I would like to maintain my packages in Mercurial (or git) repositories. It seams the best place for these to be would be alioth, but I'm not sure where is the best place -- should I rather request a private sub-directory or apply for collab-maint membership and upload packages there ? I have some doubts about collab-maint though: Maintenance is unlikely to be collaborative, and I'm not in NM, which pretty much takes care of the point of collab-maint as outlined on the wiki [1]. Also, I'm not sure how readily private hg/git sub-directories are granted to non-DDs. [1] http://wiki.debian.org/CollaborativeMaintenance -- Regards, Thomas Jollans GPG key: 0xF421434B may be found on various keyservers, eg pgp.mit.edu Hacker key http://hackerkey.com/: v4sw6+8Yhw4/5ln3pr5Ock2ma2u7Lw2Nl7Di2e2t3/4TMb6HOPTen5/6g5OPa1XsMr9p-7/-6 signature.asc Description: This is a digitally signed message part.
Re: RFS: gconf-cleaner - GConf database cleaner
On Aug 10 2007, Julien Valroff wrote: Le vendredi 10 août 2007 à 17:32 +1000, Paul Wise a écrit : That was probably CDBS, not dh_installdocs. I don't think it is a bug, because not everyone lists the upstream authors in the copyright file. You are right, but shouldn't they list them in the copyright file? ;-) Paul is right here. Not everybody lists the upstream authors in the copyright file. This is a bug in the packages. Regards, Rogério Brito. -- Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8 http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: gnome-video-arcade
Dear mentors, I am looking for a sponsor for my package gnome-video-arcade. Package name: gnome-video-arcade Version : 0.4.2-1 Upstream Author : Matthew Barnes [EMAIL PROTECTED] URL : https://sourceforge.net/projects/gva/ License : GPLv3 Section : contrib/gnome It builds these binary packages: gnome-video-arcade - a simple xmame front-end for the GNOME Desktop Environment The package appears to be lintian clean. The upload would fix these bugs: 438501 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/contrib/g/gnome-video-arcade - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/contrib/g/gnome-video-arcade/gnome-video-arcade_0.4.2-1.dsc I would be glad if someone uploaded this package for me. Kind regards Francesco Namuri -- Francesco Namuri francesco(at)namuri(dot)it http://namuri.it/ id gpg key: 21A4702A [EMAIL PROTECTED] signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Re: RFC: irrlicht
On 8/17/07, Raphael Geissert [EMAIL PROTECTED] wrote: Yesterday night I uploaded to mentors a new version of the package. Changes: * debhelper files are now generated from templates so the package version information (except debian/control) is updated automatically by debian/rules. * Added -dbg package * Added -D_REENTRANT * $(version) and $(major) are manually set now (but there's a check that makes sure that include/IrrCompileConfig.h says the same as those two vars) * Fixed build-depends * merged the two binary-arch- build targets * moved headers to include/Irrlicht1.3.1 (with symlink at include/Irrlicht) TO CHECK (comments on this please): * irrlicht seems not to be compiled with zlib/libpng/libjpeg support * -fPIC is only used when building the .so file but not when compiling the source files (is it ok this way?) * whether to use the .pc file or not (personally I see no advantage, what do you think Brandon?) * Should the .chm file be shipped in the -doc package or only the HTML documentation? * what to do with the media/ files in the -examples package (some files are not free like dx's logo, opengl logo; there's also the lucida font in a .png file so I'm not sure it is ok) * lintian complaining about missing soname I still see only version 1.3.1-1 of irrlicht, or did you mean to leave it as that? It would make more sense to change it to 1.3.1-2. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: advice on maintainting packages on alioth ?
Hello, On Sat, 18 Aug 2007, Thomas Jollans wrote: In future, I would like to maintain my packages in Mercurial (or git) repositories. It seams the best place for these to be would be alioth, but I'm not sure where is the best place -- should I rather request a private sub-directory or apply for collab-maint membership and upload packages there ? I have some doubts about collab-maint though: Maintenance is unlikely to be collaborative, and I'm not in NM, which pretty much takes care of the point of collab-maint as outlined on the wiki [1]. If the package has an upstream and all that is being maintained on alioth is the packaging aspect then the simplest approach is to put things under collab-maint even if it is not being maintained collaboratively. The point is that it becomes easier: - to find co-maintainers if it becomes necessary - for people to offer patches - if the package is orphaned it is easier to take over - for upstream to figure out what you are doing to their package. Also, I'm not sure how readily private hg/git sub-directories are granted to non-DDs. If the package is in Debian or is soon going to be then you should give it a try. I've found the people at alioth quite helpful! Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
