Re: RFS: tictactoe
On Fri, Nov 5, 2010 at 11:35 PM, Etienne Millon 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
Re: Sponsors and ‘UNRELEASED’ suite
Jonathan Wiltshire writes: > On Sat, Nov 06, 2010 at 08:18:41AM +1100, Ben Finney wrote: > > Stefano Rivera 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 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: 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 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 ‘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: 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: 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 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 > > > > > > > * 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: 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 > > > > * 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
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 > * 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: 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
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 , #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: 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 > * 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
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 * 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: lightspeed (updated package)
El Sun, 31 Oct 2010 10:38:38 +0100 Ansgar Burchardt escribió: > Hi, > > Tony Palma writes: > > Ansgar Burchardt escribió: > >> Tony Palma 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 . > > 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
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: 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