Re: Using Quilt with a new package
Le Tue, Nov 02, 2010 at 01:02:25PM +0100, Daniel Lombraña González a écrit : After that, I kept reading about git-buildpackage and it seems that it should be more easy to maintain those differences between the upstream version and the deb one using patches. However, I don't know how I have to do this, as I have been trying it out, and as far as I have get is to create the debian/patches folder (using gbp-pq) with a patch that removes that instruction. However, when building the package using git-buildpackage in the master branch (not in patch-queue/master) the resulting package does not have applied the patch, which is wrong. Is it possible to apply automatically those patches when building the package? (FYI I have tried the 3.0 version, and I don't get it working either, probably because I'm doing something wrong). Dear Daniel, If you would like the quilt patches in debian/patches to be applied at build time and unapplied at clean time, you can have a look at the quilt make command for CDBS in /usr/share/cdbs/1/rules/patchsys-quilt.mk or Debhelper's dh --with quilt. By ‘quilt patches’ I mean that they will need to be listed in debian/patches/series. There is an even simpler solution, /usr/share/cdbs/1/rules/simple-patchsys.mk, but it is deprecated (which makes me sad). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101103070026.ge20...@merveille.plessy.net
Re: RFS: dalle
Hello, On Wednesday 03 November 2010 at 01:23:13, Alberto Fernández wrote: Dear mentors, I am looking for a sponsor for my package dalle. * Package name: dalle Version : 0.10.11 Upstream Author : Alberto Fernández Martínez inf...@gmail.com * URL : http://dalle.sourceforge.net * License : GPL3 Section : utils It builds these binary packages: dalle - File management tool The upload would fix these bugs : 599851 [...] I'm not a DD, but here's my review for your package: The review is about the Debian package source, I haven't reviewed how the program works. * Lintian: I: dalle source: missing-debian-source-format - You shopuld have the file debian/source/format indicating your package source format. Now, it's recommended switching to 3.0 (quilt). * Lintian: W: dalle: latest-debian-changelog-entry-changed-to-native - In your changelog the dalle version is 0.10.11. Dalle is not a Debian native program, so it should be 0.10.11-1 to indicate the Debian revision. - Moreover, I don't know if you should keep the previous changes before uploading the Debian. Maybe someone else can help us int this point... * debian/rules: - Delete comment lines that are not your own comments like Sample debian/rules - You can install files with the file debian/install, so you can delete cp lines and your debian/rules will be more simple. - You can install manpages with files dalle.manpages or putting them in debian directory with namepacke.1 (or the corresponding number) * debian/control - Some spelling mistakes in the long description: splited - split, Dalle support - Dalle suports * debian/dalle-doc.files, dalle-doc.docs - What are these files for? You have the debian/docs file that seems to do what you want. * debian/docs - You are installing the file formatos_soportados.txt. I think this file name should be in English as well as its content. * debian/dirs - Using debian/install, maybe you won't need this file. * debian/dalle-gtk.desktop - The comment is in Spanish, it should be en English. I hope my advises help you :-) If any other person from the list see a mistake in my review, reviews of my review are welcomed! Cheers. -- Mònica Normalment, només se'ns reconeix el dret de pensar quan pensem dins d'un dels corrents que cada època considera legítims; és a dir quan pensem el menys possible. Manuel de Pedrolo signature.asc Description: This is a digitally signed message part.
Re: RFS: dalle
On Wed, Nov 03, 2010 at 10:55:49AM +0100, Mònica wrote: * debian/control - Some spelling mistakes in the long description: splited - split, Dalle support - Dalle suports ^^^ supports -- Jonathan Wiltshire 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101103094905.ga5...@lupin.powdarrmonkey.net
package transition question
Hi all, I'm facing a problem and thought maybe someone here has a solution or could point me into the right direction: The package openswan currently has version 2.4.12 in Lenny whereas in Squeeze version 2.6.28 will appear. As the version number suggest this means some deep changes, also concerning the configuration parameters in the according config files. With the new version comes an external configuration parsing program which checks for config errors and warns accordingly. Normally this shouldn't be such a great issue as major version changes may break configs but as this package's purpose is secure VPN access we want to take care that the program is not restarted without proper configuration. We first thought about aborting the installation in postinst when the config would not run but this would leave the package in a weird state as the new binaries would have already been unpacked. Aborting in preinst is also unfeasable because we do not have the program installed yet so we can't check if the config is ok or not. Our current idea is to do the installation, run the program in postinst to check for config errors and if we find some we issue a warning message and cease to restart the daemon - or does anybody have a better idea? Kind regards Harald Jenny -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101103105927.gb3...@harald-has.a-little-linux-box.at
Re: RFS: mediadownloader
On 11/02/2010 09:51 PM, Fernando Lemos wrote: Hi, On Tue, Nov 2, 2010 at 6:32 PM, Marco Bavagnolilil.dei...@gmail.com wrote: I fixed most of the warning, but 1 of them and 1 information with a spelling error are still there. I run lintian -Ii on the .deb, as result I got this: W: mediadownloader: new-package-should-close-itp-bug Please fix this, it's quite simple. Your changelog should contain an entry (and generally only that entry) that says something like Initial release (Closes #1234) where 1234 is the number of the ITP bug report you filed in the BTS. I think I finally fixed all and thanks to you all for your patience. I also added debian/watch file that contain this: version=3 http://sf.net/googleimagedown/mediadownloader-v(.*)-src\.tar\.gz the url on sf.net is this: http://sourceforge.net/projects/googleimagedown/files/ and source is named like mediadownloader_v1.4.2-src.tar.gz Is the watch file content correct ? I: mediadownloader: spelling-error-in-binary ./usr/bin/mediadownloader informations information It would be better to fix this. Just grep the source for informations, change it, make a quilt patch and warn upstream about the spelling mistake so that you can drop that patch in future releases. Regards, I found the spelling errors. I the about dialog window of the application, there is the GPL3 license text as in http://www.gnu.org/licenses/gpl-3.0.txt don't know if I can change it :) As there is only that spelling error, and if the watch regexp is correct, may I upload to mentors ? thanks a lot in advance best regards Marco -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cd14d0f.1070...@gmail.com
Re: RFS: mediadownloader
Hey, On Wed, Nov 3, 2010 at 9:52 AM, Marco Bavagnoli lil.dei...@gmail.com wrote: the url on sf.net is this: http://sourceforge.net/projects/googleimagedown/files/ and source is named like mediadownloader_v1.4.2-src.tar.gz Is the watch file content correct ? Take a look at uscan(1), there are examples for SourceForge projects. Anyways, if it is working, you can use uscan do download the newest version (uscan --force-download). I: mediadownloader: spelling-error-in-binary ./usr/bin/mediadownloader informations information I found the spelling errors. I the about dialog window of the application, there is the GPL3 license text as in http://www.gnu.org/licenses/gpl-3.0.txt don't know if I can change it :) Well, the original license doesn't have the spelling mistake, so I guess you can correct it. Please let upstream know too. Regards, -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktima6sm3qic8_mtp-rkdjuulwsbwecaurzzsq...@mail.gmail.com
Re: RFS: wicd-client-kde
I've uploaded tha package again. I think i've corrected all the mistakes mentioned in previous emails. I've also added provides: wicd-client in debian/control. I am still wainting upstream response about changing the name to wicd-qt, but till then i would be glad if someone makes a new review of the package. I also have a question. If we (me, mentors, sponsors, DD, upstream...) finally decide to change the name i guess i should send a new itp bug with the new name and close this one, shouldn't I? Thanks, iker P.S. @David: I cc you because i don't know if you are subscribed to debian-mentors
Re: RFS: wicd-client-kde
Hi, 2010/11/3 Iker Salmón San Millán sha...@esdebian.org: I also have a question. If we (me, mentors, sponsors, DD, upstream...) finally decide to change the name i guess i should send a new itp bug with the new name and close this one, shouldn't I? I believe you can just rename the ITP. Regards, -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik-yjwlv=mcsyoupp1zepuckgiy5mwjtcytk...@mail.gmail.com
Re: package transition question
On Wed, Nov 03, 2010 at 11:59:27AM +0100, Harald Jenny wrote:
[...]
Our current idea is to do the installation, run the program in
postinst to check for config errors and if we find some we issue a
warning message and cease to restart the daemon - or does anybody
have a better idea?
Basically the same, just more reusable, would be to check the
configuration as part of the start/restart/reload sections of the
new version's initscript. I believe this is the same mechanism
Apache has been using for years to help prevent killing httpd when
you try to reload a broken configuration without validating its
syntax (or when some of its dependent pieces may have gone missing).
Obviously this still leaves the admin in the unfortunate position of
having to solve his configuration problem on the spot or roll back
to a previous package version.
Alternatives would be (more user friendly) come up with a
configuration translator if all existing options can have a 1-to-1
transform/mapping to new options or syntax, or (less user friendly)
change package names with the new version and upload a final-ish
package of the old version which displays loud messages about what
the new package name is and how to manually transition to it.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101103122558.gq8...@yuggoth.org
Re: RFS: minidlna
Hi Michael,
Sorry for the delay, but I've been awfully busy over the week end.
Michael Tautschnig wrote:
It seems like a clever thing to do in {pre,post}inst: there's no need to
create a default minidlna user:group if something else is already set in
the default file; I'm just unsure if it should create the user:group
found in the default file if they do not exist already (if they do not
exist, they were most likely removed by the user manually, and
re-creating them silently as system users seems like a bad idea).
And in postrm, I would not remove any user:group except
minidlna:minidlna, which was normally created by preinst.
Is this what you had in mind? I'll implement those changes, and upload a
new version soon.
Well, actually I would have been ok with the naive usecreate/remove whatever
the user specified in defaults; but you're absolutely right, you could and
should be more careful here. I think it would be fine to abort in case user
and
group are not equal to minidlna and do not exist.
I just uploaded a new version (1.0.18-3) [1] that addresses all the
issues you've pointed out to me (except the missing license headers,
I'll ask upstream about that).
I hope I didn't miss anything, but please let me know if there are any
problems left.
Cheers,
--
Benoît Knecht
---
[1] http://mentors.debian.net/debian/pool/main/m/minidlna
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101103124904.ga26...@debian.lan
Re: RFS: fldiff (ITA package)
Hello, I had a look at your package, here are a few remarks. Please note that I am not a DD, so I won't be able to upload your package. My advice may also be incomplete and/or incorrect, but let's hope not. - Your orig.tar.gz file seems to differ from the one in unstable. You should use the same one ; if you need to make changes affecting the upstream part of your package (ie everything except debian/*), this should be done separately. As you are using the 3.0 (quilt) format, this should be recorded under debian/patches. - Changing the source format while adopting a package makes your upload longer to review, so you it will probably be harder to find a sponsor. - I believe that debian/rules can be simplified a lot if you use the 'dh $@' technique. Regards, -- Etienne Millon signature.asc Description: Digital signature
Re: RFS: mediadownloader
I uploaded the new package to mentors without any lintian warnings. Thanks to you all here the link http://mentors.debian.net/debian/pool/main/m/mediadownloader/ Regards Marco -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cd167a7.3020...@gmail.com
Re: Using Quilt with a new package
On Wed, Nov 3, 2010 at 3:00 AM, Charles Plessy ple...@debian.org wrote: Le Tue, Nov 02, 2010 at 01:02:25PM +0100, Daniel Lombraña González a écrit : After that, I kept reading about git-buildpackage and it seems that it should be more easy to maintain those differences between the upstream version and the deb one using patches. However, I don't know how I have to do this, as I have been trying it out, and as far as I have get is to create the debian/patches folder (using gbp-pq) with a patch that removes that instruction. However, when building the package using git-buildpackage in the master branch (not in patch-queue/master) the resulting package does not have applied the patch, which is wrong. Is it possible to apply automatically those patches when building the package? (FYI I have tried the 3.0 version, and I don't get it working either, probably because I'm doing something wrong). Paul is right, it's best to get upstream to make a change so you don't need patches, but in case they don't the easiest way is to use source 3.0 (quilt) format [1]. That should automatically apply and keep track of packages for you with no need to change rules files or add depends. I don't know what problem you're having, but the following command: mkdir debian/source ; echo '3.0 (quilt)' debian/source/format would create a file named format in debian/source in your package. The content of the file should be '3.0 (quilt)'. Now you should just use quilt normally. For example quilt new my_new_patch.patch quilt add src/file_i_want_to_change.c [edit the file] quilt refresh you now should have your patch in debian/patches along with a file named series in debian/patches that contains the name of your patch. You can find better how tos on the internet, but that should be it. [1] http://wiki.debian.org/Projects/DebSrc3.0 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=oxuwkeds8a=gwd2irxa+jtp4j4vsax7r3u...@mail.gmail.com
Re: RFS: sciteproj
On Fri, 29 Oct 2010 15:41:33 +0200 Andreas Ronnquist gus...@gusnan.se wrote: On Fri, 29 Oct 2010 10:23:31 +0200 Michael Tautschnig m...@debian.org wrote: Hi Andreas, Sorry for a somewhat late reply. [...] First, please allow me to ask whether you also contacted the maintainer of SciTE in Debian, Michael Vogt, about this package. IMHO it would make way more sense if this was coordinated instead of being uploaded by a third person like myself. Concerning your package, I'd have the following change requests before it could be sponsored (at least in case I should still sponsor your upload): - debian/copyright: Instead of this You should have received a copy ... you should say On Debian systems, the complete text of the GNU General Public License can be found in `/usr/share/common-licenses/GPL-3' - debian/docs: You don't want to ship CMakeLists.txt and GPL3.txt - debian/watch: The URL is broken, you'll have to use http://sf.net/sciteproj/sciteproj_(.+)\.tar\.gz (but because of #581169 this isn't fully up-to-date right now). Hope this helps, Michael Thanks Michael! I have fixed these items in a new upload to mentors, and mailed Michael Vogt with links to the RFS and this thread. best regards -- Andreas Rönnquist gus...@gusnan.se I have done another upload, version 0.3.15 - I hadn't updated the version number in the man-page I provide, and some minor GTK updates (added -DGTK_DISABLE_DEPRECATED, and fixed the minor problems that that threw at me.) The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/sciteproj - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/sciteproj/sciteproj_0.3.15-1.dsc best regards -- Andreas Rönnquist gus...@gusnan.se -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101103150046.360483cc.gus...@gusnan.se
Re: RFS: wicd-client-kde
El 3 de noviembre de 2010 13:05, Iker Salmón San Millán sha...@esdebian.org escribió: I am still wainting upstream response about changing the name to wicd-qt, but till then i would be glad if someone makes a new review of the package. Here is the response: Well technically this is a KDE App, which heavily depends on the KDE libs, not only on Qt, and is designed to integrate in the KDE desktop. If you call it wicd-qt, it might be misleading if someone doesn't want any kdelibs dependencies for whatever reason. So I do not recommend using wicd-qt for the package name, but instead wicd-kde, like your potential mentor said, for consistency. About the binary name, I don't plan to change it to wicd-kde, because it doesn't contains/substitute the wicd daemon, I think it's important that the users understand it's just a client for the daemon. So the package wicd-gtk depends on gtk (and not GNOME) and provides the wicd-client binary. And the package wicd-kde depends on kde (and not only Qt) and would provide the wicd-client-kde binary. (I can't call it wicd-client obviously so I just add -kde at the end) That makes sense to me. I don't know what to do now. I have to correct the description of the package just to make clear that not only depends on qt it also depends on kdelibs Cheers Iker
Re: package transition question
On Wed, Nov 3, 2010 at 8:26 PM, The Fungi fu...@yuggoth.org wrote: Alternatives would be (more user friendly) come up with a configuration translator if all existing options can have a 1-to-1 transform/mapping to new options or syntax, You can use Config::Model to facilitate such configuration upgrades. The maintainers / upstream of it are enthusiastic and would probably give you help to implement this. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimrb3kdau2bwqmixacpfp86bok7_n0oau18k...@mail.gmail.com
Re: RFS: wicd-client-kde
On Wed, 3 Nov 2010 15:03:17 +0100, Iker Salmón San Millán wrote: El 3 de noviembre de 2010 13:05, Iker Salmón San Millán sha...@esdebian.org escribió: I am still wainting upstream response about changing the name to wicd-qt, but till then i would be glad if someone makes a new review of the package. Here is the response: Well technically this is a KDE App, which heavily depends on the KDE libs, not only on Qt, and is designed to integrate in the KDE desktop. If you call it wicd-qt, it might be misleading if someone doesn't want any kdelibs dependencies for whatever reason. So I do not recommend using wicd-qt for the package name, but instead wicd-kde, like your potential mentor said, for consistency. wicd-kde is fine then. About the binary name, I don't plan to change it to wicd-kde, because it doesn't contains/substitute the wicd daemon, I think it's important that the users understand it's just a client for the daemon. So the package wicd-gtk depends on gtk (and not GNOME) and provides the wicd-client binary. The wicd-client binary is just a wrapper, that runs wicd-curses or wicd-gtk, depending on whether X is available or not. wicd-gtk is really a separate client, /usr/bin/wicd-gtk . Also /usr/bin/wicd-curses is a client, and /usr/bin/wicd-cli is another. I see /usr/bin/wicd-client-kde failing being consistent here :-) Anthony, would it be possible for you to reconsider this decision, and call it /usr/bin/wicd-kde? That makes sense to me. I don't know what to do now. I have to correct the description of the package just to make clear that not only depends on qt it also depends on kdelibs Yes, please, correct the package description. Other than this, the package seemed fine to me earlier today. I'll have a more careful check as soon as the binary name issue is solved. Kindly, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Using Quilt with a new package
Scott Howard showard...@gmail.com writes: On Wed, Nov 3, 2010 at 3:00 AM, Charles Plessy ple...@debian.org wrote: Le Tue, Nov 02, 2010 at 01:02:25PM +0100, Daniel Lombraña González a écrit : After that, I kept reading about git-buildpackage and it seems that it should be more easy to maintain those differences between the upstream version and the deb one using patches. However, I don't know how I have to do this, as I have been trying it out, and as far as I have get is to create the debian/patches folder (using gbp-pq) with a patch that removes that instruction. However, when building the package using git-buildpackage in the master branch (not in patch-queue/master) the resulting package does not have applied the patch, which is wrong. Is it possible to apply automatically those patches when building the package? (FYI I have tried the 3.0 version, and I don't get it working either, probably because I'm doing something wrong). Paul is right, it's best to get upstream to make a change so you don't need patches, but in case they don't the easiest way is to use source 3.0 (quilt) format [1]. That should automatically apply and keep track of packages for you with no need to change rules files or add depends. I don't know what problem you're having, but the following command: mkdir debian/source ; echo '3.0 (quilt)' debian/source/format would create a file named format in debian/source in your package. The content of the file should be '3.0 (quilt)'. Now you should just use quilt normally. For example quilt new my_new_patch.patch quilt add src/file_i_want_to_change.c [edit the file] quilt refresh That won't work, at least not the verry first time. The verry first time you need to use 'QUILT_PATCHES=debian/patches quilt ...'. When you unpack a source with dpkg-source it does this for you. An alternative way to create a new patch and from my point of view easier is to - just edit files - debuild / dpkg-buildpackage till you are happy + creates debian/patches/debian-changes-version - quilt rename [-P debian-changes-version] my-cool-new-feature.patch - $EDITOR debian/patches/my-cool-new-feature.patch + add patch description to the premade header you now should have your patch in debian/patches along with a file named series in debian/patches that contains the name of your patch. You can find better how tos on the internet, but that should be it. [1] http://wiki.debian.org/Projects/DebSrc3.0 And if you want to have patches unapplied add unapply-patches to debian/source/local-options. MfG Goswin -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq0eif7m@frosties.localdomain
Re: RFS: wicd-client-kde
Hi, The wicd-client binary is just a wrapper, that runs wicd-curses or wicd-gtk, depending on whether X is available or not. wicd-gtk is really a separate client, /usr/bin/wicd-gtk . Also /usr/bin/wicd-curses is a client, and /usr/bin/wicd-cli is another. I see /usr/bin/wicd-client-kde failing being consistent here :-) Anthony, would it be possible for you to reconsider this decision, and call it /usr/bin/wicd-kde? Ah, I didn't know that. I've never even noticed there was a wicd-gtk binary ;) Put it that way, it indeed makes more sense to call the binary wicd-kde. So I can do that upstream, but I haven't planned a new release anytime soon because I just released a new one a couple of days ago. But if needed, I can make a patch and Iker could use it? Anthony
Re: RFS: fldiff (ITA package)
Hi! Tanks for your interest. - Your orig.tar.gz file seems to differ from the one in unstable. You should use the same one ; if you need to make changes affecting the upstream part of your package (ie everything except debian/*), this should be done separately. As you are using the 3.0 (quilt) format, this should be recorded under debian/patches. Yes, I know. I've tested to improve the package. I put the original source package. - I believe that debian/rules can be simplified a lot if you use the 'dh $@' technique. I look at this: I know this technique. Regards! I. De Marchi -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimqt1v5ja5ggm6y3r9qdwkpnv9wx+eb0t409...@mail.gmail.com
Re: RFS: wicd-client-kde
2010/11/3 Anthony Vital yesmic...@gmail.com Ah, I didn't know that. I've never even noticed there was a wicd-gtk binary ;) Put it that way, it indeed makes more sense to call the binary wicd-kde. So I can do that upstream, but I haven't planned a new release anytime soon because I just released a new one a couple of days ago. But if needed, I can make a patch and Iker could use it? Anthony No problem for me anthony I have addeed to the package the patchs i sent to you, so another one is not a problem for me. Iker
Re: RFS: hotot
* instead of overriding dh_installman, you could just as well have a line debian/hotot.1 in the debian/manpages file (it wouldn't work that easily with the Changelog, as you'd have to move it eg. to debian/upstream_changelog/changelog so it can be added to debian/docs without renaming. i'd say it's a matter of taste which solution one prefers.) No need to rename the changelog, you could also use dh_installchangelogs to install the upstream changelog. Paul signature.asc Description: OpenPGP digital signature
Re: RFS: wicd-client-kde
On Wed, 3 Nov 2010 17:29:00 +0100, Anthony Vital wrote: [..] Put it that way, it indeed makes more sense to call the binary wicd-kde. So I can do that upstream, but I haven't planned a new release anytime soon because I just released a new one a couple of days ago. But if needed, I can make a patch and Iker could use it? Sure, not a problem. I'll wait for a new package from Iker :-) Kindly, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFS: wicd-client-kde
I don't know if you want a particular format for the patch, but here's one. Anthony rename_binary_wicd-kde.patch Description: Binary data
Re: RFS: mediadownloader
Marco Bavagnoli lil.dei...@gmail.com writes: I also added debian/watch file that contain this: version=3 http://sf.net/googleimagedown/mediadownloader-v(.*)-src\.tar\.gz Unless you want to match an empty version, the above specification should be more restrictive: version=3 http://sf.net/googleimagedown/mediadownloader-v(.+)-src\.tar\.gz Could you please show where you got the ‘(.*)’ from? It has been around in many places for a long time, but is IMO a mistake and should be fixed in any documentation. -- \ “If you pick up a starving dog and make him prosperous, he will | `\ not bite you. This is the principal difference between a dog | _o__)and a man.” —Mark Twain, _Pudd'n'head Wilson_ | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874obyhx6e@benfinney.id.au
Re: RFS: dalle
El mié, 03-11-2010 a las 10:55 +0100, Mònica escribió: Thanks very much for your help. I've just uploaded a fixed package with your suggestions. Hello, On Wednesday 03 November 2010 at 01:23:13, Alberto Fernández wrote: Dear mentors, I am looking for a sponsor for my package dalle. * Package name: dalle Version : 0.10.11 Upstream Author : Alberto Fernández Martínez inf...@gmail.com * URL : http://dalle.sourceforge.net * License : GPL3 Section : utils It builds these binary packages: dalle - File management tool The upload would fix these bugs : 599851 [...] I'm not a DD, but here's my review for your package: The review is about the Debian package source, I haven't reviewed how the program works. * Lintian: I: dalle source: missing-debian-source-format - You shopuld have the file debian/source/format indicating your package source format. Now, it's recommended switching to 3.0 (quilt). I don't know why lintian didn't warn this to me ? * Lintian: W: dalle: latest-debian-changelog-entry-changed-to-native - In your changelog the dalle version is 0.10.11. Dalle is not a Debian native program, so it should be 0.10.11-1 to indicate the Debian revision. - Moreover, I don't know if you should keep the previous changes before uploading the Debian. Maybe someone else can help us int this point... I was not sure if dalle should be a native program. Now I'm sure no. * debian/rules: - Delete comment lines that are not your own comments like Sample debian/rules - You can install files with the file debian/install, so you can delete cp lines and your debian/rules will be more simple. - You can install manpages with files dalle.manpages or putting them in debian directory with namepacke.1 (or the corresponding number) Rules cleaned :) * debian/control - Some spelling mistakes in the long description: splited - split, Dalle support - Dalle suports It's my horrible English. I must practice. * debian/dalle-doc.files, dalle-doc.docs - What are these files for? You have the debian/docs file that seems to do what you want. Deleted. * debian/docs - You are installing the file formatos_soportados.txt. I think this file name should be in English as well as its content. Translated. Pending to translate NEWS. * debian/dirs - Using debian/install, maybe you won't need this file. Replaced by debian/install * debian/dalle-gtk.desktop - The comment is in Spanish, it should be en English. The comment is now in English and localized to Spanish to. I hope my advises help you :-) Thank you. If any other person from the list see a mistake in my review, reviews of my review are welcomed! Is there someone with experience packaging CLI apps to review the package? Cheers. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1288823034.4189.9.ca...@localhost
Re: RFS: mediadownloader
On 11/03/2010 11:14 PM, Ben Finney wrote: Marco Bavagnolilil.dei...@gmail.com writes: I also added debian/watch file that contain this: version=3 http://sf.net/googleimagedown/mediadownloader-v(.*)-src\.tar\.gz Unless you want to match an empty version, the above specification should be more restrictive: version=3 http://sf.net/googleimagedown/mediadownloader-v(.+)-src\.tar\.gz I fixed this and reupload to mentors Could you please show where you got the ‘(.*)’ from? It has been around in many places for a long time, but is IMO a mistake and should be fixed in any documentation. I got that here: http://www.debian.org/doc/maint-guide/ch-dother.en.html#s-watch thanks Marco -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cd1f26c.3010...@gmail.com
English localisation help for Debian package maintainers (was: RFS: dalle)
Alberto Fernández inf...@gmail.com writes: It's my horrible English. I must practice. […] The comment is now in English and localized to Spanish to. Feel free to request help with English-language localisation on the appropriate forum URL:http://lists.debian.org/debian-l10n-english/ for any of your Debian packaging work. -- \ “The best way to get information on Usenet is not to ask a | `\ question, but to post the wrong information.” —Aahz | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4kugd5f.fsf...@benfinney.id.au
Re: Open RFS lacking (further) responsei
On Tue, 2 Nov 2010, Michael Tautschnig wrote: [...] I think that, as far as false positives: we should just reply to all the messages. For better or for worse, people will look at mailing list archives and get a feel for what our community is like. (That's my opinion, anyway.) It's clear to me that the source code to this cron job should be somewhere public. Let's see... Okay, published: http://gitorious.org/debian-mentors-mailing-list-summary/debian-mentors-mailing-list-summary [...] Thanks a lot for sharing! One immediate note: The script only takes this October's archives, we'll not get any data for November, etc... !? Yeah, it's a total hack. It's past midnight right now, so I'll just reply to your mail rather than fix it. (The right solution is to keep the october mbox around, download November, and cat them together.) Patches welcome! (-: Or else I'll get to it within a day or two. Even if we should almost always reply, wouldn's some blacklist (probably using message ids) still make sense? I'd at least like to see suscribe (Age: 5 days) blacklisted. Yeah, I do see what you mean now. (Maybe there can be an email address that you reply-to called pretend-it-was-replied-to-on-debian-ment...@rose.makesad.us and the script will see you reply, effectively blacklisting it.) -- Asheesh. -- Q: How many supply-siders does it take to change a light bulb? A: None. The darkness will cause the light bulb to change by itself. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1011040023560.7...@rose.makesad.us
Re: Open RFS lacking (further) response
On Wed, 3 Nov 2010, Charles Plessy wrote: Le Mon, Nov 01, 2010 at 11:00:23PM -0400, Asheesh Laroia a écrit : On Sun, 31 Oct 2010, Charles Plessy wrote: RFS has something similar in concept to pull requests. How about including in the RFS emails a link to the most relevant diff in the web interface of the VCS where the package is stored ? This will help to have the changes seen by many eyes. I think that is a great idea, so long as it's an updated package RFS. Do you see a way to make the idea work for all RFSs? (Honest question; trying to get a sense of what you mean.) Obviously, it will not work if the package is not a VCS, so it does not apply to all RFS. But we can encourage it by showing examples, for instance in the RFS template. From URLs like the one below, people can easily figure out the correct one for their package: Diff between revisions 5120 and 5399 of the imagej package: http://svn.debian.org/wsvn/debian-med/?op=compcompare[]=%2ftrunk%2fpackages%2fimagej%2ftr...@5120compare[]=%2ftrunk%2fpackages%2fimagej%2ftr...@5399 Diff between the tags debian/0.1.8-1 and debian/0.1.9-1 of the samtools package: http://git.debian.org/?p=debian-med/samtools.git;a=commitdiff;h=debian/0.1.9-1;hp=debian/0.1.8-1 That makes a lot of sense! I see what you mean. -- Asheesh. -- ROMEO: Courage, man; the hurt cannot be much. MERCUTIO: No, 'tis not so deep as a well, nor so wide as a church-door; but 'tis enough, 'twill serve.
