Re: RFC: avr-evtd
Le Tue, Sep 16, 2008 at 02:16:19AM -0300, Rogério Brito a écrit : I would be glad if someone uploaded this package for me or provided me with constructive criticism. Hi Rogério, I had a look to your package. I am not very familiar with that kind of software, so I will only make comments on the packaging. * Although Upstream does not seem to be active since two years, I would anyway recommend to publish your patches on SF.net. At least it could be useful to other distros, or encourage people to prepare a new release. If you like the idea, then I suggest that once it is done you add the URL to the patch on SF.net in the header of the patch. * Some of your patches fix coding style (whitespaces, DOS carriage returns, indentation). Consider that they may create a small work overhead to people who may have to investigate the package, for instance if there is a security issue while you are in vacation. They will also make it uneasy to exchange patches with Upstream or other distros when these patches are applied after the coding-style ones. * To fully comply with Policy 3.8.0, you can copy /usr/share/doc/quilt/README.source or mention it in debian/README.source. * If you have free time, like the idea and want to help it gain momentum, you can consider converting your copyright file to the format detailed in http://wiki.debian.org/Proposals/CopyrightFormat. to the format. * Upstream chose -Os for compilation. -O2 in Debian is not strictly mandatory, so if you find that sticking to -Os helps, you can. * Upstream's makefile has some instructions (-DMIPS) if it detects mips CPU. You do not do the same test in debian/rules (an you do not use Upstream's makefile). Is it intentional? Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#461513: cdbs: requires aclocal.m4 to be present in order to generate it
Hi there! I admit that in my case it is a cornercase: it is an old package that necessitates the autotools to be ran again with newer versions in order to build. I do this with the DEB_AUTO_UPDATE* variables of CDBS. I placed a fake aclocal.m4 to force DEB_AUTO_UPDATE_ACLOCAL=1.10 to take effect. All of this comes of course from the fact that the package seems abandonned upstream. Actually, for other reasons I ended up thinking that it is not suitable for Debian unless somebody revives it upstream. This discussion and also the CDBS documentation CDBS can be asked to update Autoconf, Automake, and Libtool generated files, but this behavior is likely to break the build system and is strongly discouraged make me feel than a piece of source code i've got suffers of something not clearly understandable by me. (It have a bootstrap.sh file which runs autoheader aclocal automake --foreign --add-missing autoconf and of course no aclocal.m4). Could you point me to an explanation of what is wrong with such kind of source code? Why it's considered to be so complex for a package build system. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
deb/debian suffixes in packages
Hi -mentors! I failed to find the correct meaning of deb/debian suffixes in some version strings of packages in Debian archive. Are they stand for seriously modified code? I found 292 examples in Debian unstable. (aptitude search ?version(deb) --display-format=%p - %V --disable-columns | wc -l) -- Eugene V. Lyubimkin aka JackYF signature.asc Description: OpenPGP digital signature
Re: deb/debian suffixes in packages
On Tue, 16 Sep 2008 18:14:04 +0300, Eugene V. Lyubimkin wrote: Hi -mentors! Hello, IANADD, nor a mentor :) I failed to find the correct meaning of deb/debian suffixes in some version strings of packages in Debian archive. Are they stand for seriously modified code? I found 292 examples in Debian unstable. (aptitude search ?version(deb) --display-format=%p - %V --disable-columns | wc -l) Usually, these prefixes are mostly used: debian ds dfsg $vcs (i.e. svn, bzr, cvs, ...) The first two usually mean that the original tarball has ben repacked not for license issues: stale files, build-generated files, .svn/CVS/.bzr/$vcs directories, [..] dfsg is appended when the original tarball is repacked with the removal of files which cannot be distributed by Debian, or, at maintainer's choice, non-free files (i.e. suitable for non-free), but not absolutely needed by the program itself so, instead of making the whole package non-free, just those bits are dropped, and the whole package con go to main/contrib. $vcs is added when... well, when it's a snapshot from a repository :) There might be other suffixes used, but these are the first coming to mind. HTH, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: cdbs: how to move file after install target?
Jack Bates wrote: install:: mv -i $(DEB_DESTDIR)/usr/bin/scripts/phpcs-svn-pre-commit $(DEB_DESTDIR)/usr/share/subversion/hook-scripts/phpcs - but it has no effect: The script is still installed at /usr/bin/scrips/phpcs-svn-pre-commit It is unclear from your post, does your `mv' actually invoked? If it doesn't, then probably you wrote your install rule *after* buildcore.mk inclusion. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deb/debian suffixes in packages
David Paleino wrote: On Tue, 16 Sep 2008 18:14:04 +0300, Eugene V. Lyubimkin wrote: [snip] I failed to find the correct meaning of deb/debian suffixes in some version strings of packages in Debian archive. Are they stand for seriously modified code? I found 292 examples in Debian unstable. (aptitude search ?version(deb) --display-format=%p - %V --disable-columns | wc -l) Usually, these prefixes are mostly used: debian ds dfsg $vcs (i.e. svn, bzr, cvs, ...) The first two usually mean that the original tarball has ben repacked not for license issues: stale files, build-generated files, .svn/CVS/.bzr/$vcs directories, [..] dfsg is appended when the original tarball is repacked with the removal of files which cannot be distributed by Debian, or, at maintainer's choice, non-free files (i.e. suitable for non-free), but not absolutely needed by the program itself so, instead of making the whole package non-free, just those bits are dropped, and the whole package con go to main/contrib. $vcs is added when... well, when it's a snapshot from a repository :) Thank you for answer. May be, it's reasonable to add this info (after formatting) to devreference? -- Eugene V. Lyubimkin aka JackYF signature.asc Description: OpenPGP digital signature
Re: deb/debian suffixes in packages
On Tue, 16 Sep 2008 18:32:58 +0300, Eugene V. Lyubimkin wrote: Thank you for answer. You're welcome, that's what -mentors is for! May be, it's reasonable to add this info (after formatting) to devreference? Sure it would help new packagers :) File a bug to develeopers-reference (reportbug developers-reference), if you wish. However, I'd wait for someone more experienced to reply :) David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: deb/debian suffixes in packages
Eugene V. Lyubimkin wrote: Thank you for answer. May be, it's reasonable to add this info (after formatting) to devreference? I believe it's not a policy but a somewhat common used practice. You are free to use *any* revision suffixes in your packages because revisions itself have only one (pure technical) meaning: they are one part of vesrion numbering scheme. Not more, not less. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deb/debian suffixes in packages
On Tue, 16 Sep 2008 19:45:11 +0400, Al Nikolov wrote: Eugene V. Lyubimkin wrote: Thank you for answer. May be, it's reasonable to add this info (after formatting) to devreference? I believe it's not a policy but a somewhat common used practice. And, in fact, I believe adding the most common suffixes to the devref shouldn't be a policy but, as you said, a common used practice. And, well, that's called Developers' *Reference*, not Policy :) David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: deb/debian suffixes in packages
Al Nikolov wrote: Eugene V. Lyubimkin wrote: Thank you for answer. May be, it's reasonable to add this info (after formatting) to devreference? I believe it's not a policy but a somewhat common used practice. You are free to use *any* revision suffixes in your packages because revisions itself have only one (pure technical) meaning: they are one part of vesrion numbering scheme. Not more, not less. Shouldn't devreference describe common used practices? It's not a policy, after all. -- Eugene V. Lyubimkin aka JackYF signature.asc Description: OpenPGP digital signature
Re: deb/debian suffixes in packages
Eugene V. Lyubimkin wrote: Shouldn't devreference describe common used practices? It's not a policy, after all. OTOH, devreference is not a collection of common used practices (what is may be sad), but a overview of the recommended procedures and the available resources IMHO, whict is more suitable for such things inclusion into is Debian Wiki. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deb/debian suffixes in packages
On Tue, 16 Sep 2008 20:07:00 +0400, Al Nikolov wrote: Eugene V. Lyubimkin wrote: Shouldn't devreference describe common used practices? It's not a policy, after all. OTOH, devreference is not a collection of common used practices (what is may be sad), but a overview of the recommended procedures and the available resources IMHO, whict is more suitable for such things inclusion into is Debian Wiki. AFAICT, using the proper suffix to describe *why* the upstream source tarball has been repacked *should* be in the *recommended* procedures. But, well, that's IMHO. David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Advice about first package building (from sources)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi mentors, I have read the main documentation about pbuilder but i haven't seen if it is possible to build a package from upstream sources. In all examples, the command is like pbuilder build ???.dsc What is the correct method to build a package from upstream sources ? I thought to build a virtual host (KVM), install all packages needed, import all sources (upstream with all files needed to build package) and run the dpkg-buildpackage command... All this to keep a clean and stable Debian on my laptop ;) Is there another method and where can i found documentation ? Thanks. - -- Laurent Guignard, Registered as user #301590 with the Linux Counter Site : http://www.famille-guignard.org Blog : http://blog.famille-guignard.org Projet : http://sicontact.sourceforge.net GULL de Villefranche sur Saône : http://www.cagull.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI0AnDjcKpXFc/7oYRArtzAJwOjGDTFeow+S518mrxhJlpNWBwkQCeOWss JiKOsI2Wp4JPIRP8FGLETMA= =hvqh -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: nemesis (updated package)
2008/9/12 Bernhard R. Link [EMAIL PROTECTED]: * William Vera [EMAIL PROTECTED] [080911 21:28]: I am looking for a sponsor for the new version 1:1.4beta3-1 of my package nemesis. The history of versions is quite disturbing: 1.32+1.4beta3-1 1.32+1.4beta3-2 1:1.4-1 1:1.4beta3-1 Yes, because upstream's tarball, I used a epoch for update 1.32+1.4beta3-2 to 1.4-1 Some recomendation? I see two problems here: 1) the epoch for 1.4 Epochs often cause more problems than they solve, one should not use them too lightweight, as you will never be able to get rid of them again. That 1.4 is after 1.32 (and not 28 releases before) means that upstream seems to use some strange numbering sheme based on decimal fractions. There are good chances this will happen again in the future, so instead of using an epoch, normalizing that to usual natural numbers by making that a 1.40 could have expressed the situation more clearly (and avoid similar problems in the future). But alas, it is to late, the epoch is in the archive, it can never ever go away now... I agree, I see now that problem is the epoch 2) 1.4beta3 coming after 1.4 That sounds strange. Usually beta releases come before the final release (to be expressed in Debian version numbers either by ~ or by the oldversion-newbeta trick), so having this after 1.4 looks very strange to me. If you take a look at the dates at the download site, you see that this feeling seems to be right: nemesis-1.4beta3.tar.gz 29-Oct-2003 19:12 nemesis-1.4beta3.zip07-Oct-2004 02:02 nemesis-1.4.tar.gz 07-Oct-2004 04:29 nemesis-1.4.zip 07-Oct-2004 04:47 nemesis-1.4.zip.asc 07-Oct-2004 04:47 nemesis-1.4.tar.gz.asc 07-Oct-2004 04:49 So your new version seems to actually be almost a year older than the previous one and is the version you just replaced in the previous entry. You have reason, I follow the uscan ouput and that is why I thought it was the latest version. If you do not want uscan to tell you in error that there is an newer upstream version if there is none, just tell it to Debianize the versions there, by adding an opts=uversionmangle=s/beta/~beta/ i.e make debian/watch look like the following (two lines): version=3 opts=uversionmangle=s/beta/~beta/ http://sf.net/nemesis/nemesis-(.*)\.tar\.gz Yes thanks, I appreciate your help, can see the package with the watch file fixed at debian mentors: http://mentors.debian.net/debian/pool/main/n/nemesis/nemesis_1.4-2.dsc Hochachtungsvoll, Bernhard R. Link Regards! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- William Vera [EMAIL PROTECTED] PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Advice about first package building (from sources)
On Tue, 16 Sep 2008 21:32:19 +0200 Laurent Guignard [EMAIL PROTECTED] wrote: I have read the main documentation about pbuilder but i haven't seen if it is possible to build a package from upstream sources. In all examples, the command is like pbuilder build ???.dsc What is the correct method to build a package from upstream sources ? $ make dist $ sudo pbuilder create $ sudo pbuilder login In a separate terminal window: $ sudo cp foo-1.2.3.tar.gz /path/to/pbuilder/1234/ Back in the original terminal window (inside the chroot) # tar -xzf foo-1.2.3.tar.gz # apt-get install bar-dev etc. # ./configure # make All this to keep a clean and stable Debian on my laptop ;) Basically, all you need is to create a static chroot - you could do that with debootstrap instead of pbuilder. Then chroot into that environment and do whatever you need to do to get the source and the dependencies. You can then retain this chroot for later use if you use a simple debootstrap method. You might want to use the common method of putting such chroots in a new /jails/ directory. The entire build tree needs to be duplicated and all dependencies re-installed inside the chroot. It needs quite a large amount of space. The debootstrap itself is usually 180Mb, plus the build tree and all the duplicated build dependencies (including the build tools like autoconf etc.) Is there another method and where can i found documentation ? $ man debootstrap pbuilder is a convenient wrapper for disposable chroots that is designed for package building. What you want sounds more like a fixed chroot jail and that is best done with debootstrap (in exactly the same way as pbuilder does when you ask it to create a pbuilder .tgz.) -- Neil Williams http://www.linux.codehelp.co.uk pgpWHAOMltzTd.pgp Description: PGP signature
CDBS duplicate docs installation
Hello Mentors I have a problem trying to update a package using cdbs, that's appears duplicate installations of the docs files, in /usr/doc/foo and /usr/share/docs/foo and that obviously give me a lintian errors, the package is scrot and is in mentors: http://mentors.debian.net/debian/pool/main/s/scrot/ I appreciate your help Thanks Regards -- William Vera [EMAIL PROTECTED] PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deb/debian suffixes in packages
Le Tue, Sep 16, 2008 at 08:07:00PM +0400, Al Nikolov a écrit : OTOH, devreference is not a collection of common used practices (what is may be sad), but a Le Tue, Sep 16, 2008 at 06:14:40PM +0200, David Paleino a écrit : AFAICT, using the proper suffix to describe *why* the upstream source tarball has been repacked *should* be in the *recommended* procedures. Hi, the best way to figure out is to send a patch and see if it is accepted ;) Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDBS duplicate docs installation
Le Tue, Sep 16, 2008 at 07:11:59PM -0500, William Vera a écrit : Hello Mentors I have a problem trying to update a package using cdbs, that's appears duplicate installations of the docs files, in /usr/doc/foo and /usr/share/docs/foo Hi, it is probably that debhelper installs the docs (README AUTHORS ChangeLog TODO) in /usr/share/docs/foo and the makefile in /usr/doc/foo (see Makefile.am). The file names of the docs are generic enough that Debhelper guesses them. Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDBS duplicate docs installation
Hello 2008/9/16 Charles Plessy [EMAIL PROTECTED]: Le Tue, Sep 16, 2008 at 07:11:59PM -0500, William Vera a écrit : Hello Mentors I have a problem trying to update a package using cdbs, that's appears duplicate installations of the docs files, in /usr/doc/foo and /usr/share/docs/foo Hi, it is probably that debhelper installs the docs (README AUTHORS ChangeLog TODO) in /usr/share/docs/foo and the makefile in /usr/doc/foo (see Makefile.am). The file names of the docs are generic enough that Debhelper guesses them. Thanks, that appears it is the problem, so I guess just need patch Makefile.am I'm correct? Regards Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- William Vera [EMAIL PROTECTED] PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDBS duplicate docs installation
Le Tue, Sep 16, 2008 at 08:56:45PM -0500, William Vera a écrit : 2008/9/16 Charles Plessy [EMAIL PROTECTED]: it is probably that debhelper installs the docs (README AUTHORS ChangeLog TODO) in /usr/share/docs/foo and the makefile in /usr/doc/foo (see Makefile.am). The file names of the docs are generic enough that Debhelper guesses them. Thanks, that appears it is the problem, so I guess just need patch Makefile.am I'm correct? Patches are a higher work overhead than we suspect. If you are not in a hurry, I would recommend to ask Upstream he can change the path to the docs. That would make him do the work for you ;) Other alternatives to patching are to delete $(CURDIR)/debian/yourpackage/usr/doc, or to try to override the path at build time. If you chose to patch, I suggest that you forward it upstream and indicate this in the patch header. Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Pure-ftpd bug or ftp client's bug?
Hi, mentors Tom Pfeifer report a bug against curlftpfs [1]. I tried and find out why the problem occurs. I open 2 terminal, here named console1 and console2 Console1 I login to ftp by user user and password pass, use pasv mode to transfer file, then run command stor file Console2 I run command *cat file1G | nc 192.168.10.40 ftp_data_port_listen_at_server* Console1 I run command site chmod 644 file1 Console2 Press Ctrl-C to interrupt file transfer. Debug pure-ftpd === Trying 192.168.10.40... Connected to 192.168.10.40. Escape character is '^]'. 220-- Welcome to Pure-FTPd [privsep] [TLS] -- 220-You are user number 1 of 50 allowed. 220-Local time is now 02:32. Server port: 21. 220-This is a private system - No anonymous login 220 You will be disconnected after 15 minutes of inactivity. user user 331 User user OK. Password required pass pass 230-User user has group access to: user 230 OK. Current directory is /home/user pasv 227 Entering Passive Mode (192,168,10,40,211,12) stor file 150 Accepted data connection site chmod 600 file Connection closed by foreign host. Debug vsftpd === Connection closed by foreign host. Trying 192.168.10.40... Connected to 192.168.10.40. Escape character is '^]'. 220 (vsFTPd 2.0.5) user user 331 Please specify the password. pass pass 230 Login successful. pasv 227 Entering Passive Mode (192,168,10,40,115,28) stor file 150 Ok to send data. site chmod 600 file 226 File receive OK. 200 SITE CHMOD command ok. quit 221 Goodbye. Connection closed by foreign host. The Problem == The Problem is when file transfer is not finished, site chmod 600 file make pure-ftpd broken the connection. The question is, who should response for this bug? curlftpfs or pure-ftpd? [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499153 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDBS duplicate docs installation
Thanks :) 2008/9/16 Charles Plessy [EMAIL PROTECTED]: Le Tue, Sep 16, 2008 at 08:56:45PM -0500, William Vera a écrit : 2008/9/16 Charles Plessy [EMAIL PROTECTED]: it is probably that debhelper installs the docs (README AUTHORS ChangeLog TODO) in /usr/share/docs/foo and the makefile in /usr/doc/foo (see Makefile.am). The file names of the docs are generic enough that Debhelper guesses them. Thanks, that appears it is the problem, so I guess just need patch Makefile.am I'm correct? Patches are a higher work overhead than we suspect. If you are not in a hurry, I would recommend to ask Upstream he can change the path to the docs. That would make him do the work for you ;) Other alternatives to patching are to delete $(CURDIR)/debian/yourpackage/usr/doc, or to try to override the path at build time. If you chose to patch, I suggest that you forward it upstream and indicate this in the patch header. Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- William Vera [EMAIL PROTECTED] PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: avr-evtd
Hi, Charles. Thank you very much for your reply. On Sep 16 2008, Charles Plessy wrote: Le Tue, Sep 16, 2008 at 02:16:19AM -0300, Rogério Brito a écrit : I would be glad if someone uploaded this package for me or provided me with constructive criticism. Hi Rogério, I had a look to your package. I am not very familiar with that kind of software, so I will only make comments on the packaging. It's a program for the Kurobox that you sent me. :-) Thanks you very much once again. * Although Upstream does not seem to be active since two years, I would anyway recommend to publish your patches on SF.net. At least it could be useful to other distros, or encourage people to prepare a new release. Right. I have already contacted upstream, but he is not that responsive. :-( I offered help to getting things in a sourceforge repository and he told me that he will make me a member of the project. I just don't know how many privileges I will have there. :-( If you like the idea, then I suggest that once it is done you add the URL to the patch on SF.net in the header of the patch. Nice. * Some of your patches fix coding style (whitespaces, DOS carriage returns, indentation). Consider that they may create a small work overhead to people who may have to investigate the package, for instance if there is a security issue while you are in vacation. They will also make it uneasy to exchange patches with Upstream or other distros when these patches are applied after the coding-style ones. Right. I will produce another version of the package without them. I really got mad because the coding is not that good (could be simplified) and I have already stepped up to be upstream. * To fully comply with Policy 3.8.0, you can copy /usr/share/doc/quilt/README.source or mention it in debian/README.source. Right, but I have one question: quilt/README.source just seems to be teaching people how to work with quilt... * If you have free time, like the idea and want to help it gain momentum, you can consider converting your copyright file to the format detailed in http://wiki.debian.org/Proposals/CopyrightFormat. to the format. Yes, I like this proposal and I have free time. Done. * Upstream chose -Os for compilation. -O2 in Debian is not strictly mandatory, so if you find that sticking to -Os helps, you can. Yes, I agree. I think that in this embedded system, each byte that we can save will be a huge advantage to serve files. I'm looking for optimizing things for throughput and compiling some packages with -Os is a good thing. Actually, compiling things with -Os should be the recommended setting in Debian, since less code often means that there are fewer L1-i cache misses, and those misses can be quite costly. When things don't even fit into the L2 cache, things get quite bad in terms of performance and this is quite possibly the case with people running Desktops with zillions of little processes. I'm still conservative and am writing this with fluxbox and mutt. :-) Call me old-fashioned. Anyway, it's done for the package. * Upstream's makefile has some instructions (-DMIPS) if it detects mips CPU. You do not do the same test in debian/rules (an you do not use Upstream's makefile). Is it intentional? Yes, it was intentional. I don't know if the method that upstream uses is a good thing for Debian, and we will soon have mips and mipsel and I'm unsure of how to proceed. Things work fine on powerpc. I think that I will postpone this for now, but include the checks in a future release of the package. A new version was just uploaded to mentors.debian.net. Thanks for your review, 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: scrot (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.8-8 of my package scrot. It builds these binary packages: scrot - command line screen capture utility The package appears to be lintian clean. The upload would fix these bugs: 492502 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/scrot - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/scrot/scrot_0.8-8.dsc I would be glad if someone uploaded this package for me. Kind regards William Vera -- William Vera [EMAIL PROTECTED] PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]