Upload just to fix a watch file?
Hi mentors. Since the upstream website has been redesigned, the watch file for one of my packages[1] has stopped working. The fix is a trivial one-line patch, so I was wondering if such a minor change could warrant a new upload. Thanks in advance. [1] http://dehs.alioth.debian.org/report.php?package=beef -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. pgpHPJ2Ti76QY.pgp Description: PGP signature
Re: Upload just to fix a watch file?
Andrea Bolognani e...@kiyuko.org writes: Since the upstream website has been redesigned, the watch file for one of my packages[1] has stopped working. Which leaves your package with a new bug: a ‘debian/watch’ file that no longer works. Right? The fix is a trivial one-line patch, so I was wondering if such a minor change could warrant a new upload. Many critical security bug fixes are trivial one-line patches. Why would the size of the patch be a factor in whether you should make a new release? Yes, certainly fixing any bug (even one not yet reported) is enough justification for making a new release. -- \“Intellectual property is to the 21st century what the slave | `\ trade was to the 16th.” —David Mertz | _o__) | Ben Finney pgppOnO5wPmHM.pgp Description: PGP signature
Re: Upload just to fix a watch file?
Hi! Andrea Bolognani schrieb: Since the upstream website has been redesigned, the watch file for one of my packages[1] has stopped working. The fix is a trivial one-line patch, so I was wondering if such a minor change could warrant a new upload. IMHO this doesn't warrant an upload; but if you want to make sure that everyone is aware, that you are aware, you might fill a bug report against your package tagging it pending. Best Regards, Alexander signature.asc Description: OpenPGP digital signature
Re: Upload just to fix a watch file?
Ben Finney wrote: Andrea Bolognani e...@kiyuko.org writes: Since the upstream website has been redesigned, the watch file for one of my packages[1] has stopped working. Which leaves your package with a new bug: a ‘debian/watch’ file that no longer works. Right? The fix is a trivial one-line patch, so I was wondering if such a minor change could warrant a new upload. Many critical security bug fixes are trivial one-line patches. Why would the size of the patch be a factor in whether you should make a new release? Yes, certainly fixing any bug (even one not yet reported) is enough justification for making a new release. No. The cost of wasting buildd and user time has to be factored in. Not any bug is worth of making a new release for. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upload just to fix a watch file?
Felipe Sateler schrieb: No. The cost of wasting buildd and user time has to be factored in. Not any bug is worth of making a new release for. Not to forget bandwidth / transfer volume for our mirror network. Even for arch: all packages uploads are not always justified. Best Regards, Alexander -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upload just to fix a watch file?
On Thu, 14 May 2009 18:11:38 +1000 Ben Finney ben+deb...@benfinney.id.au wrote: Andrea Bolognani e...@kiyuko.org writes: Since the upstream website has been redesigned, the watch file for one of my packages[1] has stopped working. Which leaves your package with a new bug: a ‘debian/watch’ file that no longer works. Right? Right. The fix is a trivial one-line patch, so I was wondering if such a minor change could warrant a new upload. Many critical security bug fixes are trivial one-line patches. Why would the size of the patch be a factor in whether you should make a new release? Yes, certainly fixing any bug (even one not yet reported) is enough justification for making a new release. The main difference I can see is that this bug only affects the Debian ifrastructure, as opposed to a security bug, which affects users. I don't think it is worth it to upload a new version of a package just to fix a small bug which doesn't affect users at all, but I wanted to hear some opinions. I will go the way suggested by Alexander, i.e. report a bug myself and tag it as pending. But I'll be sure to contact you once I need a sponsor to upload a new version of beef ;) -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. pgpB7ve1Fm58A.pgp Description: PGP signature
Re: Upload just to fix a watch file?
On Thu, May 14, 2009 at 3:03 PM, Andrea Bolognani e...@kiyuko.org wrote: Since the upstream website has been redesigned, the watch file for one of my packages[1] has stopped working. The fix is a trivial one-line patch, so I was wondering if such a minor change could warrant a new upload. No, however here are some other things you could consider doing: Update the package for Standards-Version 3.8.1. Look at the one bug mentioned in launchpad (you may consider it invalid though): https://bugs.launchpad.net/ubuntu/+source/beef/+bug/302898 Tell upstream about the spelling error: http://lintian.debian.org/full/e...@kiyuko.org.html Write a patch for the gcc warning on powerpc/s390 and send upstream: https://buildd.debian.org/fetch.cgi?pkg=beef;ver=0.0.6-2;arch=powerpc;stamp=1205980460 https://buildd.debian.org/fetch.cgi?pkg=beef;ver=0.0.6-2;arch=s390;stamp=1205978679 Drop the Makefile patch and instead use make PREFIX=debian/beef/usr MANDIR=. DOCDIR=... http://patch-tracking.debian.net/patch/misc/view/beef/0.0.6-2/Makefile Write a test suite and send it upstream. Write an article for debaday.debian.net about it. -- 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
Re: Upload just to fix a watch file?
On Thu, 14 May 2009 17:22:06 +0800 Paul Wise p...@debian.org wrote: On Thu, May 14, 2009 at 3:03 PM, Andrea Bolognani e...@kiyuko.org wrote: Since the upstream website has been redesigned, the watch file for one of my packages[1] has stopped working. The fix is a trivial one-line patch, so I was wondering if such a minor change could warrant a new upload. No, however here are some other things you could consider doing: Update the package for Standards-Version 3.8.1. I'll look at it. Look at the one bug mentioned in launchpad (you may consider it invalid though): https://bugs.launchpad.net/ubuntu/+source/beef/+bug/302898 I'm aware of that bug, and I'm annoyed by it, but I can't really do anything about it: the language is called Brainfuck, and while I'm aware the name can result offensive to some people, it's the only correct name for the programming language supported by Beef. Tell upstream about the spelling error: http://lintian.debian.org/full/e...@kiyuko.org.html I'm upstream for Beef, so no need to tell anyone else, I guess ;) Write a patch for the gcc warning on powerpc/s390 and send upstream: https://buildd.debian.org/fetch.cgi?pkg=beef;ver=0.0.6-2;arch=powerpc;stamp=1205980460 https://buildd.debian.org/fetch.cgi?pkg=beef;ver=0.0.6-2;arch=s390;stamp=1205978679 I'll look at it. Drop the Makefile patch and instead use make PREFIX=debian/beef/usr MANDIR=. DOCDIR=... http://patch-tracking.debian.net/patch/misc/view/beef/0.0.6-2/Makefile Yeah, why not? The less patches the better. Write a test suite and send it upstream. I won't write a test suite for Beef, or otherwise improve it, since I plan to rewrite it on top of the Cattle library[1] as soon as said library is mature enough. The library, however, already has a test suite. Write an article for debaday.debian.net about it. I'm not sure my English is up to the task... Moreover, being both upstream author and Debian maintainer, am I not a little too biased? ;) [1] http://www.kiyuko.org/software/cattle -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. pgpzyOfCIVmcr.pgp Description: PGP signature
Re: Upload just to fix a watch file?
On Thu, May 14, 2009 at 5:48 PM, Andrea Bolognani e...@kiyuko.org wrote: Write a test suite and send it upstream. I won't write a test suite for Beef, or otherwise improve it, since I plan to rewrite it on top of the Cattle library[1] as soon as said library is mature enough. The library, however, already has a test suite. moo...@#*$t!%%!#%end OF COW Write an article for debaday.debian.net about it. I'm not sure my English is up to the task... Moreover, being both upstream author and Debian maintainer, am I not a little too biased? ;) Fair enough, though the debian-l10n-english list might be able to help you fix up any spelling and grammar issues (they review package descriptions too). Also, I don't think debaday has more of an issue with lack of content than any issue with upstream/Debian maintainers submitting articles. -- 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
Re: RFS: cconv -- A iconv based simplified-traditional chinese conversion tool
Hi Dne Tue, 12 May 2009 23:26:40 +0800 Vern Sun s5u...@gmail.com napsal(a): on 二, 2009-05-12 at 17:02 +0800, Michal Čihař wrote: - you should split the library to libcconv0 and rename devel package to libcconv-dev - please write useful description, pointing user to url is not a useful description done - cconv man page is obviously generated, you should include it's sources and generate it during build I use asciidoc to generate manpage, fixed. - Vcs-* fields are for debian packaging not for upstream - README.Debian is useless - why do you install empty file NEWS? clear Reuploaded. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/cconv - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/cconv/cconv_0.5.2-1.dsc There are still some things: - static library and libtool script should go to devel package (*.la, *.a) - are all those versioned build depends really needed? - I don't think that iconv based is important information which should be as first in short description. Either remove it completely or move it to the end. - there is no need for creating postinst for library package - lintian --pendantic: P: libcconv0: copyright-refers-to-symlink-license usr/share/common-licenses/GPL P: cconv: copyright-refers-to-symlink-license usr/share/common-licenses/GPL P: libcconv-dev: copyright-refers-to-symlink-license usr/share/common-licenses/GPL -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
RFS: fpm2 (updated package)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for the new version 0.75-1 of my package fpm2. The upload would fix those bugs: #516196 Blowfish selftest failed: At startup password prompt. Please try again. Severity: important #493317 DEFAULTS is no longer the default on start-up Severity: wishlist It builds the binary package: fpm2 Description: a password manager with GTK+ 2.x GUI Figaro's Password Manager 2 (FPM2) is a program that allows you to securely store the passwords. Passwords are encrypted with the AES-256 algorithm. . If the password is for a web site, FPM2 can keep track of the URLs of your login screens and can automatically launch your browser. In this capacity, FPM2 acts as a kind of bookmark manager. You can teach FPM2 to launch other applications, and optionally pass hostnames, usernames or passwords to the command line. . FPM2 also has a password generator that can choose passwords for you. It allows you to determine how long the password should be, and what types of characters (lower case, upper case, numbers and symbols) should be used. You can even have it avoid ambiguous characters such as a capital O or the number zero. The package is lintian clean. The package can be found on mentors.debian.net: - - dget http://mentors.debian.net/debian/pool/main/f/fpm2/fpm2_0.75-1.dsc I would be glad if someone uploaded this package for me. :-) Kind regards Wen-Yen Chuang - -- My GPG key is signed by Debian Developer Masayuki Hatta. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoL8JgACgkQdEpXpumNYVmlWQCdHeUdoe2A2iRaW9Qgximp9x3X xbQAoInvclnEQ5n7YYLTmbZOELmfk7Ft =ZUi8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: hwinfo (updated package)
Hi! William Vera schrieb: I am looking for a sponsor for the new version 15.3-2 of my package hwinfo. Uploaded; many thanks for your contribution! Best regards, Alexander -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: cconv -- A iconv based simplified-traditional chinese conversion tool
on 四, 2009-05-14 at 18:11 +0800, Michal Čihař wrote: - are all those versioned build depends really needed? as you said cconv man page is obviously generated, you should include it's sources and generate it during build. most of the depends are used for generate man page. - there is no need for creating postinst for library package the problem is lintian show error if I deleted the postinst: E: libcconv0: postinst-must-call-ldconfig usr/lib/libcconv.so.0.0.0 N: N:The package installs shared libraries in a directory controlled by the N:dynamic library loader. Therefore, the package must call ldconfig in N:its postinst script. N: N:Refer to Debian Policy Manual section 8.1.1 (ldconfig) for details. N: N:Severity: serious, Certainty: certain please tell me what I am doing wrong. thanks. -- Vern 2009-05-14 signature.asc Description: Digital signature
Re: RFS: cconv -- A iconv based simplified-traditional chinese conversion tool
Hi Dne Thu, 14 May 2009 19:19:19 +0800 Vern Sun s5u...@gmail.com napsal(a): on 四, 2009-05-14 at 18:11 +0800, Michal Čihař wrote: - are all those versioned build depends really needed? as you said cconv man page is obviously generated, you should include it's sources and generate it during build. most of the depends are used for generate man page. I'm talking about versions, not about dependencies. - there is no need for creating postinst for library package the problem is lintian show error if I deleted the postinst: E: libcconv0: postinst-must-call-ldconfig usr/lib/libcconv.so.0.0.0 N: N:The package installs shared libraries in a directory controlled by the N:dynamic library loader. Therefore, the package must call ldconfig in N:its postinst script. N: N:Refer to Debian Policy Manual section 8.1.1 (ldconfig) for details. N: N:Severity: serious, Certainty: certain please tell me what I am doing wrong. thanks. You miss call to dh_makeshlibs. Consider switching to dh, which will do all jobs for you. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: RFS: macchanger-gtk (updated package) -- fixed URL in watch file
On Tue, May 12, 2009 at 22:47, Alejandro Garrido Mota garridom...@gmail.com wrote: 2009/5/13 LI Daobing lidaob...@gmail.com: Hello, On Tue, May 12, 2009 at 11:09, Alejandro Garrido Mota garridom...@gmail.com wrote: Dear mentors, I am looking for a sponsor for the new version 1.1-4 of my package macchanger-gtk. It builds these binary packages: macchanger-gtk - a GTK+ interface for GNU/MACchanger The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/macchanger-gtk - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/macchanger-gtk/macchanger-gtk_1.1-4.dsc I would be glad if someone uploaded this package for me. undocumented changes in README: $ debdiff macchanger-gtk_1.1-3.dsc macchanger-gtk_1.1-4.dsc | diffstat README | 2 +- macchanger-gtk-1.1/debian/changelog | 6 ++ macchanger-gtk-1.1/debian/watch | 2 +- 3 files changed, 8 insertions(+), 2 deletions(-) Please, check again. I fix the problem uploaded. -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: libmemcached
On Wed, May 13, 2009 at 02:35, Monty Taylor mord...@inaugust.com wrote: LI Daobing wrote: 2. /usr/bin/memstat in libmemcached-tools is conflict with the same file in memstat package[1], one solution is install it as memstat.libmemcached and document this in README.Debian http://packages.qa.debian.org/m/memstat.html Done. README.Debian should be installed to libmemcached-tools instead of libmemcached-dev. 3. consider remove the .la file if you already have a .pc file. Is that a policy/best practice for library packages? ok, consider there is no conclusion here. you can keep this file there. :) thanks. -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: cconv -- A iconv based simplified-traditional chinese conversion tool
on 四, 2009-05-14 at 19:54 +0800, Michal Čihař wrote: I'm talking about versions, not about dependencies. sorry about my poor english. - are all those versioned build depends really needed? i am not sure about this, but i have removed the versions. - static library and libtool script should go to devel package (*.la, *.a) done - I don't think that iconv based is important information which should be as first in short description. Either remove it completely or move it to the end. completely removed - there is no need for creating postinst for library package fixed - lintian --pendantic: P: libcconv0: copyright-refers-to-symlink-license usr/share/common-licenses/GPL P: cconv: copyright-refers-to-symlink-license usr/share/common-licenses/GPL P: libcconv-dev: copyright-refers-to-symlink-license usr/share/common-licenses/GPL fixed reuploaded. the package can be found on mentors.debian.net: - dget http://mentors.debian.net/debian/pool/main/c/cconv/cconv_0.5.2-1.dsc thanks again. -- Vern 2009-05-14 signature.asc Description: Digital signature
RFS: drgeo (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.1.0-3 of my package drgeo. It builds these binary packages: drgeo - An interactive geometry software This is the Gtk interactive geometry software. It allows one to create geometric figure plus the interactive manipulation of such figure in respect with their geometric constraints. It is usable in teaching situation with students from primary or secondary level. . Dr. Geo comes with a complete set of tools arranged in different categories: . * points * lines * geometric transformations * numeric function * macro-construction * DGS object - Dr. Geo Guile Script * DSF - Dr Geo Scheme Figure, it is interactive figure defined in a file and evaluated with the embedded Scheme interpretor, awesome! * Export facilities in the LaTeX and EPS formats The package appears to be lintian clean. The upload would fix these bugs: 526728 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/drgeo - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/drgeo/drgeo_1.1.0-3.dsc I would be glad if someone uploaded this package for me. Kind regards Francisco M. Garcia Claramonte -- Francisco M. García Claramonte franciscomanuel.gar...@hispalinux.es GPG: public key ID 556ABA51 signature.asc Description: Esta parte del mensaje está firmada digitalmente
RFS: ampache (updated package)
Dear mentors, I am looking for a sponsor for the new version 3.5+svn2078-1 of my package ampache. I have contacted my usual sponsor and he is unable to sponsor ampache at this time due to other commitments. Here is a summary of some of the new features. - Video Streaming Support - Access Control List Wizard / Simplification - IPv6 Support on all Access Lists and IP related operations - Corrected Multi-Byte Character Support - Up to date Translations in 14 different languages - Optional Lyrics Support - Basic Tag Support (allowing multiple genres per song) - Countless Optomizations / Caching to speed up the interface - Vastly Improved API with simplified configuration and setup - Standardized UI should give users a more consistent experience - Enable Last.FM plug-in by default - Ability to Run Add/Verify catalog operations starting at a specific Sub Directory rather then indexing the whole catalog It builds these binary packages: ampache- web-based audio file management system Lintian complains of the following problems. 1) Lintian gives a false positive for gz-file-not-gzip. I conversed with Russ Allbery (Lintians maintainer) and this is a known bug in lintian and will be fixed with the next upload of lintian. 2) Lintian complains of font-in-non-font-package usr/share/ampache/www/modules/captcha/FreeMono-Medium.ttf. FreeMono-Medium.ttf (as far as I can tell) is not currently packaged for Debian. I am looking into packaging FreeMono-Medium.ttf for Debian. The upload would fix these bugs: 526475 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/ampache - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/ampache/ampache_3.5+svn2078-1.dsc I would be glad if someone uploaded this package for me. Kind regards Charlie Smotherman signature.asc Description: This is a digitally signed message part
Re: RFS: cconv -- A iconv based simplified-traditional chinese conversion tool
Hi Dne Thu, 14 May 2009 21:09:03 +0800 Vern Sun s5u...@gmail.com napsal(a): reuploaded. the package can be found on mentors.debian.net: - dget http://mentors.debian.net/debian/pool/main/c/cconv/cconv_0.5.2-1.dsc Uploaded, thanks. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: RFS: libmemcached
LI Daobing wrote: On Wed, May 13, 2009 at 02:35, Monty Taylor mord...@inaugust.com wrote: LI Daobing wrote: 2. /usr/bin/memstat in libmemcached-tools is conflict with the same file in memstat package[1], one solution is install it as memstat.libmemcached and document this in README.Debian http://packages.qa.debian.org/m/memstat.html Done. README.Debian should be installed to libmemcached-tools instead of libmemcached-dev. Doh. Fixed. 3. consider remove the .la file if you already have a .pc file. Is that a policy/best practice for library packages? ok, consider there is no conclusion here. you can keep this file there. :) Alright. Keeping it there for now - but I'll make sure to follow the ongoing conversation. New version with fixes above pushed to mentors. Monty -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: libmemcached
LI Daobing lidaob...@gmail.com writes: 3. consider remove the .la file if you already have a .pc file. Is that a policy/best practice for library packages? ok, consider there is no conclusion here. you can keep this file there. :) But there seems to be a preference to remove it if rdepends don't need it. Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: architecture wildcards, type-handling, etc.
Dear reader of debian-mentors, I read the following, following a discussion on debian-devel, which I do not understand. On Thu, May 14, 2009 at 04:26:56PM +0200, Cyril Brulebois wrote: brian m. carlson sand...@crustytoothpaste.ath.cx (14/05/2009): I've worked on FTBFS-with-new-GCC bugs before, and realized only after putting significant work into the bug that the package didn't build on amd64, only on i386. Therefore, I think that the package should have a proper list of archs that prevents this problem. P-a-s is fine for the buildds, but if you actually want people to volunteer to fix bugs on your package, you shouldn't make it harder on them. Which is why people are expected to: - Make their packages FTBFS ASAP in the build system, to make it obvious it's not intended to even be tried on $archs. - Then get the P-a-s entry added. Could that a bit be explainend? I do not understand the following: Assuming I have a package, which I know it is only working under i386 and amd64, but has the bug that it builds correctly on another architecture (but is then not usable there), does this mean, that I should not put only i386 and amd64 in Architecture field, but instead nevertheless let any by in the Architechture field, but then on build time, let the build fail on say powerpc? Many thanks Salvatore btw, what p-a-s mean in this context? signature.asc Description: Digital signature
RFS: krecipes (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.0~beta2-1 of my package krecipes. It builds these binary packages: krecipes - recipes manager for KDE krecipes-data - recipes manager for KDE - data files krecipes-doc - recipes manager for KDE - documentation Krecipes is a KDE application designed to manage recipes. It can help you to do your shopping list, search through your recipes to find what you can do with available ingredients and a diet helper. It can also import or export recipes from files in various format (eg RecipeML or Meal-Master) or from databases. The package appears to be almost (see below) lintian clean. The upload would fix these bugs: 473367, 478030, 513860 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/k/krecipes - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/k/krecipes/krecipes_1.0~beta2-1.dsc I would be glad if someone uploaded this package for me. I have to give you some background information. Maintainer for krecipes is actually Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org. Unfortunately, this is list is mostly dead except from forwarded messages from BTS or PTS. A number of mails I (and others) sent there got no response. Krecipes has not been maintained for over 2 years and the MIA team has requested the removal of the only Uploader a couple of months ago (#513860). Therefore, I would consider krecipes effectively orphaned, allthough not officially. Are there any formal steps I should undertake to take over maintainership for this package? Upstream has been dead for 2 years as well, but got recently revived by a different maintainer who released a new version that fixes the long-standing RC bug (#478030) that has kept krecipes out of Lenny. I have packaged the new version and fixed a number of other issues. The only complaint lintian still has is W: krecipes-data: icon-size-and-directory-name-mismatch usr/share/apps/krecipes/icons/crystalsvg/48x48/actions/categories.png 32x32 I don't consider this severe enough to start and fiddle with changing of binary files. Instead, I will try to get this fixed upstream. If this does not happen for some reason I will wait for the 3.0 (quilt) format to be accepted by ftp-master. Also, dh_shlibdeps is complaining about a ton of unnecessary dependencies. I have not yet tried to investigate where those are coming from. Kind regards Matthias Julius -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug 510765 won't appear as closed
Can someone help me understand why 510765 keeps on appearing on liferea's bug page? It's been closed in all the relevant versions, and the little graph on the left shows nothing but green boxes, but everything (the bts, the pts, my qa page) show liferea as having 1 open rc bug. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug 510765 won't appear as closed
Rodrigo Gallardo wrote: Can someone help me understand why 510765 keeps on appearing on liferea's bug page? It's been closed in all the relevant versions, and the little graph on the left shows nothing but green boxes, but everything (the bts, the pts, my qa page) show liferea as having 1 open rc bug. Hi, AFAIK, the correct way of closing bugs is a mail to #-cl...@bugs.debian.org or #-d...@bugs.debian.org. By making a versioned done- (Version: 123-1 as first line), you can also tell from which version the bug is fixed. Regards, OdyX -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug 510765 won't appear as closed
found 510765 1.4.1-1 found 510765 1.4.23-1 close 510765 thanks On Thu, 14 May 2009, Rodrigo Gallardo wrote: Can someone help me understand why 510765 keeps on appearing on liferea's bug page? It's been closed in all the relevant versions, and the little graph on the left shows nothing but green boxes, but everything (the bts, the pts, my qa page) show liferea as having 1 open rc bug. Because it's not -done. In order for a bug to be shown as resolved two things has to be true: 1) the bug has to have been marked as done, either by a message to nnn-d...@b.d.o explaining why it should be closed, or a message to control with 'close ' (deprecated, because it doesn't tell the submitter that it was fixed, but I'm using it in this message.) 2) the bug has to be either fixed or absent in the distribution which you're querying for all architectures the bts cares about. Finally, if you don't know why it's not being fixed, feel free to ask here or in #debbugs on irc.debian.org; mucking with the found/fixed versions when the bug was actually found in that version generally isn't a good idea. Don Armstrong -- Judge if you want. We are all going to die. I intend to deserve it. -- a softer world #421 http://www.asofterworld.com/index.php?id=421 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug 510765 won't appear as closed
Rodrigo Gallardo wrote: Can someone help me understand why 510765 keeps on appearing on liferea's bug page? It's been closed in all the relevant versions, and the little graph on the left shows nothing but green boxes, but everything (the bts, the pts, my qa page) show liferea as having 1 open rc bug. I guess you didn't close the bug. Only marked it fixed. See: http://www.debian.org/Bugs/server-control#fixed Paul signature.asc Description: OpenPGP digital signature
Re: Bug 510765 won't appear as closed
On Thu, May 14, 2009 at 01:24:29PM -0700, Don Armstrong wrote: On Thu, 14 May 2009, Rodrigo Gallardo wrote: Can someone help me understand why 510765 keeps on appearing on liferea's bug page? Because it's not -done. Thanks, I get it now. Finally, if you don't know why it's not being fixed, feel free to ask here or in #debbugs on irc.debian.org; mucking with the found/fixed versions when the bug was actually found in that version generally isn't a good idea. So, what exactly is the use case for fixed? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug 510765 won't appear as closed
On Thu, 14 May 2009, Rodrigo Gallardo wrote: On Thu, May 14, 2009 at 01:24:29PM -0700, Don Armstrong wrote: Finally, if you don't know why it's not being fixed, feel free to ask here or in #debbugs on irc.debian.org; mucking with the found/fixed versions when the bug was actually found in that version generally isn't a good idea. So, what exactly is the use case for fixed? fixed is there for cases where you've already -done'ed the bug, and want to directly modify the fixed list (say you forgot to mention that you fixed it in the changelog, or made a mistake, or someone found it improperly, or...) In most normal cases, you shouldn't need to use the fixed, found, notfixed, or notfound commands directly. [Mails to n...@b.d.o with a Version: psuedoheader do found (and reopen if appropriate), and mails to nnn-d...@b.d.o with a Version: pseudoheader do fixed and done.] Don Armstrong -- We have to face the fact that either all of us are going to die together or we are going to learn to live together and if we are to live together we have to talk. -- Eleanor Roosevelt http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upload just to fix a watch file?
Andrea Bolognani e...@kiyuko.org writes: On Thu, 14 May 2009 18:11:38 +1000 Ben Finney ben+deb...@benfinney.id.au wrote: Andrea Bolognani e...@kiyuko.org writes: The fix is a trivial one-line patch, so I was wondering if such a minor change could warrant a new upload. Many critical security bug fixes are trivial one-line patches. Why would the size of the patch be a factor in whether you should make a new release? Yes, certainly fixing any bug (even one not yet reported) is enough justification for making a new release. The main difference I can see is that this bug only affects the Debian ifrastructure, as opposed to a security bug, which affects users. I don't think it is worth it to upload a new version of a package just to fix a small bug which doesn't affect users at all, but I wanted to hear some opinions. So, at least it's clear that the size of the patch for fixing the bug is not really relevant to whether the change is worth making a new release. I will go the way suggested by Alexander, i.e. report a bug myself and tag it as pending. But I'll be sure to contact you once I need a sponsor to upload a new version of beef ;) That won't get you too far; I'm not a DD :-) -- \ “Faith, n. Belief without evidence in what is told by one who | `\ speaks without knowledge, of things without parallel.” —Ambrose | _o__) Bierce, _The Devil's Dictionary_, 1906 | Ben Finney pgpAXVOBGAV20.pgp Description: PGP signature
Re: Error when intend update libnet0-dev to libnet1-dev (nemesis package)
On Mon, Feb 9, 2009 at 5:50 PM, Barry deFreese bdefre...@debian.org wrote: William Vera wrote: Hi mentors some clue about this error? Thanks 2008/7/11 William Vera bi...@billy.com.mx: Hello Mentors I intend update the Build-Depends at nemesis package, libnet0-dev to libnet1-dev (just changed at the debian/control), but in the build crash: checking for libnet_build_ip in -lnet... no ERROR! Libnet library not found, go get it from http://www.packetfactory.net/projects/libnet/ or use the --with-libnet-* options, if you have it installed in unusual place touch configure-stamp dh_testdir dh_testroot dh_clean -k dh_installdirs /usr/bin/make DESTDIR=`pwd`/debian/nemesis install I have installed libnet1 and libnet1-dev: bi...@lab:~/lab/nemesis-1.4$ dpkg -l |grep libnet ii libnet-dbus-perl 0.33.6-1+b1 Extension for the DBus bindings ii libnet-ssleay-perl 1.33.01-1 Perl module for Secure Sockets Layer (SSL) ii libnet1 1.1.2.1-2 library for the construction and handling of ii libnet1-dev 1.1.2.1-2 development files for libnet bi...@lab:~/lab/nemesis-1.4$ The config.log is in: http://pastebin.com/m748eda86 I appreciate any clue. Thanks in advance Regards -- William Vera bi...@billy.com.mx PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 Hi, Hello Sorry to dig up an ancient e-mail but I'm on the hunt to remove libnet0. :) Yes, configure.in is looking for libnet_build_ip in /usr/lib/libnet.so (or whatever the lib is) (It does this in AC_CHECK_LIB(net, libnet_build_ip...). What I did was change this to check for libnet_build_ipv4 instead. Which passes this test. (You can run objdump -T /usr/lib/libnet.so with the libnet1 libs installed to see what functions you could pick from). libnet_build_ipv4 appears be the better option y tried with this option and works (that part) It also then checks for libnet0 v 1.0.2 later in configure.in by grepping /usr/include/libnet.h which in itself is pathetic but just changing the grep line to check for 1.1 instead of 1.0.2a fixes that also. Y changed that too, and works but fail when configure: make[1]: se ingresa al directorio `/home/billy/lab/nemesis/nemesis-1.4' Making install in src make[2]: se ingresa al directorio `/home/billy/lab/nemesis/nemesis-1.4/src' gcc -DHAVE_CONFIG_H -I. -I.. -D_BSD_SOURCE -D__BSD_SOURCE -D__FAVOR_BSD -DHAVE_NET_ETHERNET_H -I/usr/local/include -I/sw/include -g -Wall -funroll-loops -pipe -c nemesis-arp.c nemesis-arp.c: In function ‘arp_initdata’: nemesis-arp.c:84: error: ‘ARPhdr’ has no member named ‘ar_sha’ nemesis-arp.c:85: error: ‘ARPhdr’ has no member named ‘ar_spa’ nemesis-arp.c:86: error: ‘ARPhdr’ has no member named ‘ar_tha’ nemesis-arp.c:87: error: ‘ARPhdr’ has no member named ‘ar_tpa’ nemesis-arp.c: In function ‘arp_validatedata’: nemesis-arp.c:98: error: ‘ARPhdr’ has no member named ‘ar_spa’ nemesis-arp.c:98: error: ‘ARPhdr’ has no member named ‘ar_tpa’ nemesis-arp.c:107: warning: passing argument 1 of ‘libnet_select_device’ from incompatible pointer type nemesis-arp.c:107: error: too many arguments to function ‘libnet_select_device’ nemesis-arp.c:152: error: ‘ARPhdr’ has no member named ‘ar_sha’ nemesis-arp.c:154: error: ‘ARPhdr’ has no member named ‘ar_tha’ nemesis-arp.c:159: error: ‘ARPhdr’ has no member named ‘ar_sha’ nemesis-arp.c: In function ‘arp_cmdline’: nemesis-arp.c:242: error: ‘ARPhdr’ has no member named ‘ar_tpa’ nemesis-arp.c:256: error: ‘ARPhdr’ has no member named ‘ar_sha’ nemesis-arp.c:273: error: ‘ARPhdr’ has no member named ‘ar_tha’ nemesis-arp.c:306: error: ‘ARPhdr’ has no member named ‘ar_tha’ nemesis-arp.c:310: error: ‘ARPhdr’ has no member named ‘ar_spa’ make[2]: *** [nemesis-arp.o] Error 1 make[2]: se sale del directorio `/home/billy/lab/nemesis/nemesis-1.4/src' make[1]: *** [install-recursive] Error 1 make[1]: se sale del directorio `/home/billy/lab/nemesis/nemesis-1.4' make: *** [install] Error 2 dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit status 2 bi...@nous:~/lab/nemesis/nemesis-1.4$ So, any idea? I would appreciate any help Thanks in advance! Regards! Of course the package still doesn't build with libnet1 and needs much more work. Is upstream still active on this package at all? Looking at the sourceforge page it doesn't seem to be. Thanks! Barry deFreese -- William Vera bi...@billy.com.mx PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
