Re: RFS: upnp-router-control
Hi Daniele, There is anyone that can sponsor it? Please fix the lintian errors and warnings: W: upnp-router-control source: out-of-date-standards-version 3.8.3 (current is 3.8.4) E: upnp-router-control: copyright-contains-dh_make-todo-boilerplate W: upnp-router-control: new-package-should-close-itp-bug Some more comments: 1. It looks like except for the get-orig-source target, you are using a standard build process. And it even looks like this target isn't used anymore. You might remove all targets from the rules and replace it with a simple: %: dh $@ 2. debian/dirs is probably not necessary in your case. 3. You might add debian/source/format 3.0 (quilt) to switch to the new Debian format. Thanks, Jochen -- 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/4beaaaf6.9060...@scram.de
Re: RFS: gdisk (updated package)
Le lundi 03 mai 2010 à 10:17 +0800, Paul Wise a écrit : 2010/5/3 Guillaume Delacour g...@iroqwa.org: I am looking for a sponsor for the new version 0.6.7-1 of my package gdisk. I'm not sponsoring extra packages at the moment, nor do I have GPT hardware, but here is a review: You should never ever manually add dependencies on a library, always leave that up to the shlibs mechanism. You might want to consider adopting debhelper 7 and DEP-5: https://penta.debconf.org/dc9_schedule/events/418.en.html http://dep.debian.net/deps/dep5/ Absolutely true, i have removed the libpopt0 dependency in debia/control. Having these options in the g++ flags is a bad idea: -L/opt/local/lib -L/usr/local/lib I agree, i have reported this upstream. The upstream README includes installation instructions, please ask upstream to separate that out into README.install since it is useless to users of packages. Suggested upstream. The upstream CHANGELOG file looks like it should be renamed to NEWS: http://www.gnu.org/prep/standards/standards.html#NEWS-File http://www.gnu.org/prep/standards/standards.html#Change-Logs Suggested upstream too. The upstream manual page suggests that gdisk is beta and is fairly buggy. Should you mention this in the package description? Should such buggy software really be in Debian? I have intention to modify the long description field in debian/control to indicate that gdisk is still beta software. As there is only software based on libparted (parted and gparted ?) that can handle GPT partitions, it could be a good and actively maintained alternative. Keeping it in the Debian archive is worth and could increase the maturity by community testing and reporting. I sometimes use gdisk on my desktop (i don't manipulate the GPT partition table of my unique desktop) and never had problem for the moment. dh_installman installs manual pages in a policy-compliant way, no need to do it manually. I have modified debian/rules to use dh_installman only. crc32.* are GPLv2+ while the rest seems to be GPLv2, you should probably document that in debian/copyright. debian/copyright updated. gdisk is available in several other distributions, you can use 'whohas gdisk' to find out where. There don't appear to be any bugs/patches, but you should check for them now and then. I don't know the whohas, really interesting utility. Thanks for all your advices and for reviewing the package. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFS: upnp-router-control
2010/5/12 Jochen Friedrich joc...@scram.de: Hi Daniele, There is anyone that can sponsor it? Please fix the lintian errors and warnings: W: upnp-router-control source: out-of-date-standards-version 3.8.3 (current is 3.8.4) E: upnp-router-control: copyright-contains-dh_make-todo-boilerplate W: upnp-router-control: new-package-should-close-itp-bug Some more comments: 1. It looks like except for the get-orig-source target, you are using a standard build process. And it even looks like this target isn't used anymore. You might remove all targets from the rules and replace it with a simple: %: dh $@ 2. debian/dirs is probably not necessary in your case. 3. You might add debian/source/format 3.0 (quilt) to switch to the new Debian format. I've uploaded a new version of the package. Please see if it's OK. -- Daniele DnaX Napolitano https://launchpad.net/~dnax88 http://dnax.netsons.org/ -- 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/aanlktilpej6lttzilgvgigdwjr2ff1trratvpy0kp...@mail.gmail.com
RFS: gnustep-make (updated package, RC bug fixes)
Dear mentors, I am looking for a sponsor for the new version 2.4.0-1 of my package gnustep-make. It builds these binary packages: gnustep-common - Common files for the core GNUstep environment gnustep-make - Basic GNUstep Makefiles gnustep-make-doc - Documentation for GNUstep-make The upload would fix these bugs: 560359 (RC), http://savannah.gnu.org/bugs/index.php?27222 (also RC in my opinion as it causes many GNUstep packages in Debian to violate the policy). http://fsa-bg.org/~yavorescu/gnustep/gnustep-make_2.4.0-1.dsc -- 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/877hn8dhzq.gnus_not_unix!%ya...@gnu.org
Re: RFS: gnustep-make (updated package, RC bug fixes)
Il giorno Wed, 12 May 2010 22:42:33 +0300 Yavor Doganov ya...@gnu.org ha scritto: I am looking for a sponsor for the new version 2.4.0-1 of my package gnustep-make. Uploaded. -- .''`. : :' : Luca Falavigna dktrkr...@debian.org `. `' `- signature.asc Description: PGP signature
Re: RFS: gnustep-base (updated package)
Il giorno Mon, 10 May 2010 16:14:24 +0300 Yavor Doganov ya...@gnu.org ha scritto: I am looking for a sponsor for the new version 1.19.3-3 of my package gnustep-base. Uploaded. Also, could you please consider including patch I prepared for Ubuntu? http://patches.ubuntu.com/g/gnustep-base/gnustep-base_1.19.3-1ubuntu1.patch It will save a lot of build time on their buildds, and I think lucas' GRID too, as conditions are the same :) -- .''`. : :' : Luca Falavigna dktrkr...@debian.org `. `' `- signature.asc Description: PGP signature
Taking over maintaining a package
Hello all - Once i have permission to take over maintaining a package -- what do I do from there? -Danny
Re: Taking over maintaining a package
On Wednesday 12 May 2010 16:03:24 danny.rodrig...@comcast.net wrote: Once i have permission to take over maintaining a package -- what do I do from there? Determine if the package is maintained in a VCS somewhere (probably alioth). If so, get (an alioth account and) write permissions to the VCS. Check out the latest version (HEAD) and also the last version uploaded to Sid. If not, download the source package from Sid. Subscribe to your package on the PTS. Find upstream. Introduce yourself on their communication medium of choice. See if any of the developers have feedback on the Debian package, especially if they use Debian but not your package. Start following development or at least release schedules. Does upstream have an new non-crashy version available? (This need not be a release, but it shouldn't be the tip of their development tree. If so, update the packaging to use upstream's new version. Run it through lintian (from Sid preferably, but the version from backports is usually good enough) and piuparts. For each complaint, either fix the packaging or be prepared to defend your decision not to. Update the changelog not only with the upstream version bump, but also any changes you made to satisfy lintian/piuparts. If not, you might not need to make a release right now. Study the packaging, perhaps alter it so it can build packages directly from the upstream VCS, for possible uploads to experimental. Check bugs.d.o for any issues. If you can fix them, do so, and record it in the Changelog. If they need to go upstream, forward them. If you have the skills, get involved in fixing upstream bugs, too; particularly the ones coming from the Debian BTS. Install the new package and become user 0. Confirm the package is ready to be shared, with others and upload to mentors. Fill out the template completely, send it over here and wait for a review. Once you've got something in Sid, check your bugs again. See if you can marked some as fixed in a particular version, or close some as invalid completely. Consider preparing a package for stable-updates if you can fix bugs affecting stable the risk is low. Consider preparing a package for backports. ... Anything I missed, -mentors? -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Taking over maintaining a package
On Thu, May 13, 2010 at 5:38 AM, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: snip excellent response Anything I missed, -mentors? Check the PTS page and click all the links there, looking for issues. If appropriate, check for a screenshot on screenshots.d.n and upload one if there isn't one. Audit the debtags on debtags.alioth.d.o and add/remove tags as appropriate. Join the upstream development team. Run 'whohas packagename' to find out which distributions have the software in them. Then look at their bugs, patches and so on. For Ubuntu you can just look at the PTS page links. -- 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/aanlktinutsbs2fyt0epm6kh_j7wfwka52ltqs4ivj...@mail.gmail.com
Re: Which how to for apt-get repository on CentOS?
Finally it works! The problem was that if you have a tag in the control file like Conflicts: with no value it will not warn you and will tell you (far) downstream that something is wrong with dependencies but that is all. So the problem was simply a Conflicts: with no values. Removed it and it all works now. Thanks to all for your patience and advice. -- IV On Mon, May 10, 2010 at 11:29 PM, Ignacio Valdes ival...@hal-pc.org wrote: This is a vexing problem. The things that are supposed to fix all the below do not. -- IV On Mon, May 10, 2010 at 2:04 PM, Ignacio Valdes ival...@hal-pc.org wrote: Checked my server logs and found the following. Packages.gz exists but that's not what the client is looking for: [Mon May 10 18:41:47 2010] [error] [client 75.223.92.226] File does not exist: /var/packages/dists/karmic/Release.gpg [Mon May 10 18:41:47 2010] [error] [client 75.223.92.226] File does not exist: /var/packages/dists/karmic/main/i18n [Mon May 10 18:41:48 2010] [error] [client 75.223.92.226] File does not exist: /var/packages/dists/karmic/main/binary-i386/Packages.bz2 [Mon May 10 18:41:48 2010] [error] [client 75.223.92.226] File does not exist: /var/packages/dists/karmic/main/binary-i386/Packages.lzma On Mon, May 10, 2010 at 9:50 AM, Ignacio Valdes ival...@hal-pc.org wrote: That improved things, but I am now getting E: Problem parsing dependency Conflicts E: Error occurred while processing astronaut-wv-server-beta (NewVersion1) E: Problem with MergeList /var/lib/apt/lists/174.143.201.52_dists_karmic_main_binary-i386_Packages E: The package lists or status file could not be parsed or opened. Browsing to here though shows that the Packages file can be opened or read at least through http http://174.143.201.52/ubuntu/dists/karmic/main/binary-i386/Packages On Mon, May 10, 2010 at 3:00 AM, Bernhard R. Link brl...@debian.org wrote: * Ignacio Valdes ival...@hal-pc.org [100510 06:48]: Using the following article: http://www.jejik.com/articles/2006/09/setting_up_and_managing_an_apt_repository_with_reprepro/ I have with reprepro generated test apt-get repository at: http://174.143.201.52/ubuntu/ The files are present and I have placed in my local machine in /etc/apt/sources.list.d/astronaut.list file which contains: ## Astronaut Ubuntu APT repository deb http://174.143.201.52/ubuntu karmic main deb-src http://174.143.201.52/ubuntu karmic main However the repository seems invisible. I try apt-get install astronaut-wv-server-beta and it cannot find it as well as a apt-cache search astronaut doesn't find anything. I may have misconfigured something but I am not sure what as it seems visible. Looking at the documentation you gave a link to, that Virtual host entry seems to place things in the root directory. I.e. you most likely need deb http://174.143.201.52/ karmic main deb-src http://174.143.201.52/ karmic main Hochachtungsvoll, Bernhard R. Link -- 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/aanlktiloaa_qnwfaeinay2lnvbezbx-et-b7q4g3r...@mail.gmail.com -- 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/aanlktikrebro8sucl-uin_uxbsv0kpguovbbpqmt4...@mail.gmail.com -- 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/aanlktilcb8wvtykrhnp-m6ov9be85q86efv6czogh...@mail.gmail.com -- 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/aanlktikl5cbtpqu235h8skyk9m_e5sqlb2gd7mycf...@mail.gmail.com
Re: RFS: gnustep-base (updated package)
Luca Falavigna wrote: Uploaded. Thanks! Unfortunately it failed to build almost everywhere, because gnustep-make's dependency on gnustep-common is too loose. I'll request give-backs once -make is installed on all archs, and will fix this with the next upload. Also, could you please consider including patch I prepared for Ubuntu? http://patches.ubuntu.com/g/gnustep-base/gnustep-base_1.19.3-1ubuntu1.patch Hmm, how come that gnustep-base-common is in Build-Depends-Indep? Are such things allowed in theory and practice? It seems to me that there will be a bootstrap issue, e.g. for new ports. Or maybe not, since -common is arch:all and buildds use -B. I'm not sure, but it doesn't look very elegant to me. Anyway, some time ago a different solution was proposed: http://lists.gnu.org/archive/html/gnustep-dev/2010-02/msg00035.html I'll test it and if it works, will ask upstream to comment/consider the patch for inclusion. -- 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/8739xwctpf.gnus_not_unix!%ya...@gnu.org
