Re: Build-Depends-Indep, please review
Hello, I thought Build-Depends-Indep is for build-deps that are not needed by clean target. -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0xEDDDA1B7 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: Digital signature
Re: RFS: dalle
On Friday 05 November 2010 at 00:26:51, Alberto Fernández wrote: El jue, 04-11-2010 a las 10:11 +0100, Mònica escribió: On Wednesday 03 November 2010 at 23:23:54, Alberto Fernández wrote: El mié, 03-11-2010 a las 10:55 +0100, Mònica escribió: [...] I don't know why lintian didn't warn this to me ? lintian -i -I --show-overrides package If you use debuild you can use its configuration file .devscripts: DEBUILD_LINTIAN=yes DEBUILD_LINTIAN_OPTS=-i -I --show-overrides I was using dpkg-buildpackage and calling lintian manually with -i -v --pedantic. I've switched to debbuild. Excuse me. I forgot the --pedantic option. It should be: $ lintian -i -I --show-overrides --pedantic package or if you use debuild, in .devscripts add: DEBUILD_LINTIAN=yes DEBUILD_LINTIAN_OPTS=-i -I --show-overrides --pedantic -- Mònica signature.asc Description: This is a digitally signed message part.
Re: RFS: lightspeed (updated package)
El Sun, 31 Oct 2010 10:38:38 +0100
Ansgar Burchardt ans...@43-1.org escribió:
Hi,
Tony Palma xbyt...@gmail.com writes:
Ansgar Burchardt ans...@43-1.org escribió:
Tony Palma xbyt...@gmail.com writes:
I am looking for a sponsor for the new version 1.2a-8 of my
package lightspeed.
I did take a brief look at your package (not a full review) and
here are some comments:
· debian/changelog: What change does
* Obsolete package removed since 1.2a-6. Closes: #601353
refer to?
I reassigned to the 'Changed ftgl-dev to libftgl-dev package.'.
Okay, that is easier to understand.
· You use the new source format 3.0 (quilt), but all changes to
the upstream source are stored in a single large diff. They
should be split into individual patches.
· It would be nice if generated files such as ./configure were not
included in the diff, but generated at build-time instead. This
makes the diff much shorter and easier to review.
· You build depend on autotools-dev, but seem not to replace
config.{guess,sub} with more recent versions.
The large diff is generated by autoconf and automake, since the last
update of helper files was on 2006-02-23. What is more recommended
in this case, let it or split it or using dpkg-source
--extend-diff-ignore to remove some files from the diff?
One advantage of the new source format is that it encourages
maintainers to separate changes to the upstream source in several
patches providing changes for a specific feature (bug fix). This
makes it easier for upstream developers to review changes and apply
them. For lightspeed, there are quite a lot of changes: i18n support,
porting to Gtk2, use of FTGL for fonts, ... Ideally these would be
applied upstream[1] or split in several patches.
Without using this feature, there is (IMO) not much advantage over the
old source format.[2]
[1] But the project of Sourceforge looks not really alive. You
might want to ask the current maintainer to take over the project and
maintain it upstream as well.
[2] You can also use 3.0 (quilt) similar to the 1.0 format by
including all changes in a single diff, see the
--single-debian-patch option for dpkg-source.
About the generated files: as I said, I would exclude the changes to
./configure and friends and instead just run autoconf/automake in
debian/rules to regenerate them (if required). How you exclude them
is left to you: just rm the files in the clean target or add an
option for dpkg-source to debian/source/options.
In any case, it is recommended to update config.{guess,sub}. I think
you did intend to do this (the package build-depends on
autotools-dev), but you still need to copy the files in debian/rules.
See also file:///usr/share/doc/autotools-dev/README.Debian.gz.
Regards,
Ansgar
PS: I think we could continue discussing on the list, no need to
switch to private mail.
I notified the author and upload the package to mentors with a very
large patch(build-update.diff). Now I'm using
dh $@ --with autotools_dev
and their respectives overrides, to manage the updates of
config.{guess,sub}.
Regards, Tony Palma.
signature.asc
Description: PGP signature
RFS: tictactoe
Dear mentors, I am looking for a sponsor for my package tictactoe. * Package name: tictactoe Version : 0.8.1-6 Upstream Author : Daniel Lichtenberger daniel.lichtenber...@gmx.net * URL : http://perplex.schmumpf.de/dev/tictactoe/ruby/ (unavailable) * License : GLP-2 Section : games It builds these binary packages: tictactoe - tic-tac-toe game written in Ruby The package appears to be lintian clean. The upload would fix these bugs: 553080 My motivation for maintaining this package is: I like contribute to Debian The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tictactoe - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tictactoe/tictactoe_0.8.1-6.dsc I would be glad if someone uploaded this package for me. Kind regards Innocent 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/aanlkti=cgm7o77ea1xy9fn8r0mujmtfoj3bg79+gw...@mail.gmail.com
Re: RFS: tictactoe
Il giorno ven, 05/11/2010 alle 15.35 +0100, Innocent De Marchi ha scritto: Dear mentors, I am looking for a sponsor for my package tictactoe. * Package name: tictactoe Version : 0.8.1-6 Upstream Author : Daniel Lichtenberger daniel.lichtenber...@gmx.net * URL : http://perplex.schmumpf.de/dev/tictactoe/ruby/ (unavailable) Just a quick tip: if it's unavailable, 1) do you really think it is worth reporting it? 2) since you refer to this address in debian/changelog too, where did _you_ download the tarball from? If I interpret whois info correctly, that website is unavailable (=cybersquatted) at least since 1 year. I'm not a Debian Developer, but I would guess that asking sponsorship for a package apparently dead upstream almost automatically implies one of the following: 1) being sure that upstream will eventually come back to life 2) taking over the role of upstream (including making releases downloadable somewhere) bye Pietro signature.asc Description: This is a digitally signed message part
Re: RFS: tictactoe
On Fri, Nov 05, 2010 at 04:09:20PM +0100, Pietro Battiston wrote: Just a quick tip: if it's unavailable, 1) do you really think it is worth reporting it? 2) since you refer to this address in debian/changelog too, where did _you_ download the tarball from? If I interpret whois info correctly, that website is unavailable (=cybersquatted) at least since 1 year. Moreover, your debian/watch file (pasted below) is only a comment. Uscan cannot use it to find new upstream version, so it is as bad as a lintian override. -- # Compulsory line, this is a version 3 file version=3 # The current maintainer of fldiff, #Ernesto Nadir Crespo Avila ecre...@debianvenezuela.org, #is apparently not active anymore. #The web page is #http://perplex.schmumpf.de/dev/tictactoe/ruby/ #is unavailable now # Uncomment to examine a Webserver directory -- -- Etienne Millon signature.asc Description: Digital signature
Re: RFS: minidlna
Hi Michael, Once again, thanks for your careful review, I greatly appreciate it. Michael Tautschnig wrote: I've spotted a two more minor issues which you might want to correct nevertheless as we'll have to wait for the license-header fix anyway to make this code distributable. - Once you get the copyright information for linux/*.h you will want to add this to debian/copyright as well. Absolutely, thanks for reminding me. - You can make debian/minidlna.prerm almost empty as the #DEBHELPER# will be replaced with the proper stopping code anyway (see debian/minidlna/DEBIAN/prerm after building the package). Great, I didn't know that. I'll fix this right away. For now, I'm waiting for upstream to address the licensing issue, so I won't upload a new version until then. But I'm still fixing things locally and if anyone notices other issues with the package, please do point them out. I'm hoping my next upload will be the one :) Thanks to all who reviewed this package so far (whether they commented here or not). Cheers, -- Benoît Knecht -- 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/20101105165015.ge12...@debian.lan
RFS: wicd-kde
Dear mentors, I am looking for a sponsor for my package wicd-kde. * Package name: wicd-kde Version : 0.2.1-1 Upstream Author : Anthony Vital anthony.vi...@gmail.comyesmic...@gmail.com * URL : http://gitorious.org/wicd-client-kde * License : GPL-v3 Section : kde It builds these binary packages: wicd-kde - Wired and wireless network manager - KDE client The package appears to be lintian clean. The upload would fix these bugs: 602049 My motivation for maintaining this package is: I am using this program since the first releases and works quite well. I also want to start mantaining some packages and i think this package is a good start for it. I am in contact with the upstream author and he also would be glad to have his program in debian oficial repositories and he is going to help me fixing posible bugs if appear. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/w/wicd-kde - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/w/wicd-kde/wicd-kde_0.2.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards Iker Salmón San Millán
Re: RFS: wicd-kde
On Fri, 5 Nov 2010 19:33:24 +0100, Iker Salmón San Millán wrote: Dear mentors, Iker, I am looking for a sponsor for my package wicd-kde. * Package name: wicd-kde Version : 0.2.1-1 Upstream Author : Anthony Vital anthony.vi...@gmail.comyesmic...@gmail.com * URL : http://gitorious.org/wicd-client-kde * License : GPL-v3 Section : kde It builds these binary packages: wicd-kde - Wired and wireless network manager - KDE client There was no need to make a new RFS. I'll have a look and sponsor it, as I already told you ;-) 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-kde
sorry about that. It was just to be... i don't know... proper? Thanks, anyway Regards Iker El 5 de noviembre de 2010 19:44, David Paleino da...@debian.org escribió: On Fri, 5 Nov 2010 19:33:24 +0100, Iker Salmón San Millán wrote: Dear mentors, Iker, I am looking for a sponsor for my package wicd-kde. * Package name: wicd-kde Version : 0.2.1-1 Upstream Author : Anthony Vital anthony.vi...@gmail.comyesmic...@gmail.com * URL : http://gitorious.org/wicd-client-kde * License : GPL-v3 Section : kde It builds these binary packages: wicd-kde - Wired and wireless network manager - KDE client There was no need to make a new RFS. I'll have a look and sponsor it, as I already told you ;-) 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
Re: RFS: dalle
El jue, 04-11-2010 a las 10:11 +0100, Mònica escribió: On Wednesday 03 November 2010 at 23:23:54, Alberto Fernández wrote: 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. :-) 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 -i -I --show-overrides package If you use debuild you can use its configuration file .devscripts: DEBUILD_LINTIAN=yes DEBUILD_LINTIAN_OPTS=-i -I --show-overrides Now you have another lintian warning: I: dalle source: debian-watch-file-is-missing So, you should add a watch file. * 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 :) In case you don't know it, you can make packages with dh $@. Your debian/rules would be sitll nore simple. You can read about it in the Debian New Maintainers' Guide [1]. * debian/control - Some spelling mistakes in the long description: splited - split, Dalle support - Dalle suports It's my horrible English. I must practice. Me too :-) I hope my advises help you :-) Thank you. Not at all! I love helping :-) 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. [1] http://www.debian.org/doc/maint-guide/ I've uploaded the package again with dh $@. Note: the Spanish version of maint-guide doesn't contain the new dh $@ section -- 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/1288988517.4069.25.ca...@localhost
Re: Sponsors and ‘UNRELE ASED ’ suite (was: RFS: Didjvu, Djvusmooth, Ocrodjvu, Pybtex)
Hi Ben (2010.11.05_23:18:41_+0200) Is this common practise among sponsors? It is for debian-python. I don't have any experience with other SVN-using teams. If the above convention (the sponsor will change ‘UNRELEASED’ to the appropriate suite name before re-building) is common, is it documented anywhere? No idea about documentation, I've just been told to do this on the IRC channel. The closest is: * After upload, tag the latest revision running svn-buildpackage --svn-tag-only into 'package-foo' directory. from http://python-modules.alioth.debian.org/python-modules-policy.html Yes, it does mean the sponsoree has to state which suite is desired. But it saves on a lot of untagging and retagging in each round of review, and makes it a little easier to know the state of things when reading the repo. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- 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/20101105215758.gn29...@bach.rivera.co.za
Re: Sponsors and ‘UNRELE ASED ’ suite (was: RFS: Didjvu, Djvusmooth, Ocrodjvu, Pybtex)
On Sat, Nov 06, 2010 at 08:18:41AM +1100, Ben Finney wrote: Moving this non-Python part of the discussion to ‘debian-mentors’. Stefano Rivera stef...@rivera.za.net writes: First, we don't tag releases until they are uploaded. You can leave the changelog entry as UNRELEASED, and the sponsor will fix that and tag on upload. Is this common practise among sponsors? No, it's merely the convention of the Python application/modules teams in the SVN repository. This workflow (UNRELEASED until ready, tagged after upload) helps keep the package entropy tracker sane while multiple contributors are committing changes. I was under the impression that the maintainer should create the package exactly as it should be uploaded into Debian, and the sponsor can expect to make no modifications before re-building. So I always put the intended target suite in the changelog entry. Wheras this is the convention of the mentors list, where it's accepted that a .dsc should be presented with zero or little modification required. -- Jonathan Wiltshire 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 signature.asc Description: Digital signature
Re: Sponsors and ‘UNRELEASED’ suite
Jonathan Wiltshire deb...@jwiltshire.org.uk writes: On Sat, Nov 06, 2010 at 08:18:41AM +1100, Ben Finney wrote: Stefano Rivera stef...@rivera.za.net writes: First, we don't tag releases until they are uploaded. You can leave the changelog entry as UNRELEASED, and the sponsor will fix that and tag on upload. Is this common practise among sponsors? No, it's merely the convention of the Python application/modules teams in the SVN repository. This workflow (UNRELEASED until ready, tagged after upload) helps keep the package entropy tracker sane while multiple contributors are committing changes. Ah, right. Yes, this is exactly what I do with packages while they aren't yet released to a sponsor. I guess I misread Stefano's advice as meaning that the package would be created with ‘UNRELEASED’ as the suite name and the sponsor would need to change it in the package before re-building for Debian. Stefano Rivera stef...@rivera.za.net writes: Hi Ben (2010.11.05_23:18:41_+0200) Is this common practise among sponsors? It is for debian-python. I don't have any experience with other SVN-using teams. […] Yes, it does mean the sponsoree has to state which suite is desired. But it saves on a lot of untagging and retagging in each round of review, and makes it a little easier to know the state of things when reading the repo. Okay, so this is only about the state of the package in the VCS, not about packages built prospectively for inspection by a sponsor. Thanks for the clarification. And thanks for using the term “sponsoree” instead of some of the mangled terms that have been used recently for that role :-) -- \ “I used to think that the brain was the most wonderful organ in | `\ my body. Then I realized who was telling me this.” —Emo Philips | _o__) | Ben Finney pgp28F73TP1Q5.pgp Description: PGP signature
Re: RFS: tictactoe
On Fri, Nov 5, 2010 at 11:35 PM, Etienne Millon etienne.mil...@gmail.com wrote: Moreover, your debian/watch file (pasted below) is only a comment. Uscan cannot use it to find new upstream version, so it is as bad as a lintian override. That is the correct thing to do when it is not possible to automatically find new versions with uscan. -- 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/aanlktin0votvdc1k=z1nrmrhzmdjgp4-++rqx_6=n...@mail.gmail.com
