Incorrect use of dpkg conffile suffixes and lintian checks
Hi folks, I noticed earlier today that many packages are creating copies of conffiles in their maintainer scripts with the extension ".dpkg-bak", which is not an extension used or removed by dpkg: % grep EXT lib/dpkg.h #define DEBEXT ".deb" #define OLDDBEXT "-old" #define NEWDBEXT "-new" #define REMOVECONFFEXTS"~", ".bak", "%", \ #define DPKGTEMPEXT".dpkg-tmp" #define DPKGNEWEXT ".dpkg-new" #define DPKGOLDEXT ".dpkg-old" #define DPKGDISTEXT".dpkg-dist" #define REASSEMBLETMP "reassemble" DEBEXT A lot of scripts are copying the rm_conffile script from http://wiki.debian.org/DpkgConffileHandling which adds a .dpkg-bak suffix to old conffiles. Are such names allowed? Why can't .dpkg-old be used instead? If so, this is going to cause problems with programs like run-parts(1) which do not take this case into account when excluding dpkg conffile cruft, and so will run or read files which they should not use. If this is not permitted behaviour, could we add a lintian check? If it is permitted behavour, can run-parts and the dpkg documentation be updated to match this and document its use, respectively? A check on the packages in the lintian lab on gluck shows quite a lot of matches. If this is truly buggy, I'd like to mass file bugs to fix this issue. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[rfc] mass-mod old ita/itp bugs back to rfa/rfp?
i noticed that there exist many ita/itp bugs that are much older than two month. would it make sense to set them back to rfa/rfp? if so how many days would be good to be the "too old" edge value? click this to get a quick overview: :-D http://debian.binera.de/wnpp/?type%5B%5D=ITA&type%5B%5D=ITP&sort=age;desc sebastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [rfc] mass-mod old ita/itp bugs back to rfa/rfp?
Sebastian Pipping wrote: > i noticed that there exist many ita/itp bugs that are much older than > two month. would it make sense to set them back to rfa/rfp? > if so how many days would be good to be the "too old" edge value? There is already a process that does that, though it takes into account any follow-up on the bug report to reset the timer which you clearly don't... > click this to get a quick overview: :-D > http://debian.binera.de/wnpp/?type%5B%5D=ITA&type%5B%5D=ITP&sort=age;desc Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [rfc] mass-mod old ita/itp bugs back to rfa/rfp?
* Sebastian Pipping <[EMAIL PROTECTED]> [2008-01-19 18:18]: > i noticed that there exist many ita/itp bugs that are much older than > two month. would it make sense to set them back to rfa/rfp? > if so how many days would be good to be the "too old" edge value? > > click this to get a quick overview: :-D > http://debian.binera.de/wnpp/?type%5B%5D=ITA&type%5B%5D=ITP&sort=age;desc This web page is great. It would be good to also show the submitter of the bug in a column. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [rfc] mass-mod old ita/itp bugs back to rfa/rfp?
Rafael Laboissiere wrote: http://debian.binera.de/wnpp/?type%5B%5D=ITA&type%5B%5D=ITP&sort=age;desc This web page is great. It would be good to also show the submitter of the bug in a column. noted for todo. sebastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#461583: ITP: libdc1394v2 -- As the maintainer for libdc1394 didn't answer for many months, we (developers of libdc1394) would like to get involved also with maintaining the package.
Package: wnpp Severity: urgent Owner: Peter Antoniac <[EMAIL PROTECTED]> As the maintainer for libdc1394 didn't answer for many months, we (developers of libdc1394) would like to get involved also with maintaining the package. Moreover, the maintainer didn't follow our recommandations not to pack the libdc1394 version 2.0 until we release it (and he packed it at RC7). It will be also better for the stability of the package if the developers have also something to say in the packaging. For example, we have releases the new version with doxygen generated web pages, pdf's and ps documentation, so there is more documentation available for the developers. We also think that what is now called libdc1394-examples should be called -utils, as the binaries are more like utilities for the library. We have already done some packaging and testing using the Ubuntu PPA tools, and you can already see the fruits of our work here: http://launchpadlibrarian.net/11427933/libdc1394v2_2.0.1-1ubuntu1.dsc and the source is here: http://launchpadlibrarian.net/11427931/libdc1394v2_2.0.1.orig.tar.gz with the diffs available here: http://launchpadlibrarian.net/11427932/libdc1394v2_2.0.1-1ubuntu1.diff.gz You can also check our PPA builded packages here: https://launchpad.net/~libdc1394-dev/+archive and the Ubuntu project team link is here: https://launchpad.net/libdc1394 * Package name: libdc1394v2 Version : 2.0.1 Upstream Author : Peter De Schrijver (p2) <[EMAIL PROTECTED]> * URL : http://sourceforge.net/projects/libdc1394 * License : LGPL Programming Lang: C Description : The maintainer failing to responde. As the maintainer for libdc1394 didn't answer for many months, we (developers of libdc1394) would like to get involved also with maintaining the package. Moreover, the maintainer didn't follow our recommandations not to pack the libdc1394 version 2.0 until we release it (and he packed it at RC7). It will be also better for the stability of the package if the developers have also something to say in the packaging. For example, we have releases the new version with doxygen generated web pages, pdf's and ps documentation, so there is more documentation available for the developers. We also think that what is now called libdc1394-examples should be called -utils, as the binaries are more like utilities for the library. We have already done some packaging and testing using the Ubuntu PPA tools, and you can already see the fruits of our work here: http://launchpadlibrarian.net/11427933/libdc1394v2_2.0.1-1ubuntu1.dsc and the source is here: http://launchpadlibrarian.net/11427931/libdc1394v2_2.0.1.orig.tar.gz with the diffs available here: http://launchpadlibrarian.net/11427932/libdc1394v2_2.0.1-1ubuntu1.diff.gz You can also check our PPA builded packages here: https://launchpad.net/~libdc1394-dev/+archive and the Ubuntu project team link is here: https://launchpad.net/libdc1394 -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.16.13-xenU (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [rfc] mass-mod old ita/itp bugs back to rfa/rfp?
Luk Claes wrote: i noticed that there exist many ita/itp bugs that are much older than two month. would it make sense to set them back to rfa/rfp? if so how many days would be good to be the "too old" edge value? There is already a process that does that, though it takes into account any follow-up on the bug report to reset the timer which you clearly don't... good point. i'll come back with better data :-) sebastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debburn-devel] libburnia/libisofs/cdrskin in Debian.
First of all Simon, thank you for the packages. I'm the upstream maintainer, and am also mostly maintaining the Ubuntu libburnia packages. Although I am not a Debian developer, Goedson Paixao is interested in maintaining those, with mine and probably George's help. George, interested? :) I'll check the packages in a few days, and see if there's anything I think should be changed. Once again thank you for your work. Kind regards, Mario -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: net-tools maintenance status
Bernd Eckenfels wrote: > There are a few bugs open, marked as "help needed" it would be nice if > anybody would help with those, instead of ranting. Of course that would be nice, but it's not an answer to my question. Also, more than two years ago I did write code to solve the IPv4/IPv6 truncation issue. However, you (kinda) rejected it with a vague comment and refused to tell me in what way it should be improved. I'd rather not work on other bugs if there's a chance the work gets ignored again. Finally, last month, the IPv4 part of the bug got fixed. > I had multiple persons offering to take over the project and nobody > contributed any work before. And? > I actually have two new people supporting my in the project (upstream) and i > am quite responsive to them. Because they help. That's nice to hear. > Besides that, my plan is to have an 1.65 upstream release which is basically > the Debian version (since that version is quite ok, must of the open bugs Isn't that the same plan as two years ago? > are kernel/technology related. As you can read in the archives the last few > attempts to help me with those ended with the inresponsiveness of net > developers (those consider net-tools obsolted by iproute). Please CC me, I'm not in the list. Greetings, Olaf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
loosing dependencies
Currently, the `fortunes' package depends on either `fortune-mod' or `fortune-min': $ apt-cache show fortunes Package: fortunes ... Source: fortune-mod Version: 1:1.99.1-3 Provides: fortune-cookie-db Depends: fortune-mod (>= 9708-12), fortunes-min ... Does it make sense, provided that the fortune files may as well be read by M-x fortune in Emacs, or even by a plain `less'? And more generally, does it make sense for a pure-data package to have non-empty Depends:? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: loosing dependencies
On Sun, Jan 20, 2008 at 02:01:51AM +0600, Ivan Shmakov wrote: > Currently, the `fortunes' package depends on either > `fortune-mod' or `fortune-min': > > $ apt-cache show fortunes > Package: fortunes > ... > Source: fortune-mod > Version: 1:1.99.1-3 > Provides: fortune-cookie-db > Depends: fortune-mod (>= 9708-12), fortunes-min > ... > > Does it make sense, provided that the fortune files may as well > be read by M-x fortune in Emacs, or even by a plain `less'? Probably not, it seems to me that you are right, and that this dependency should be relaxed. > And more generally, does it make sense for a pure-data package > to have non-empty Depends:? I can imagine that there are cases in which data is really specific to a particular application, but that doesn't seem to be the case here. Could you please file a bug report against the fortune package? -Ralf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#461617: ITP: wordpress-fr -- award winning weblog manager (French language version)
Package: wnpp Severity: wishlist Owner: Lionel Elie Mamane <[EMAIL PROTECTED]> * Package name: wordpress-fr Version : 2.3.2 Upstream Author : WordPress Francophone team (http://www.wordpress-fr.net/) * URL : http://fr.wordpress.org/ * License : GPLv2, pieces MIT Programming Lang: PHP Description : award winning weblog manager (French language version) WordPress is a full featured web blogging tool: * Instant publishing (no rebuilding) * Comment pingback support with spam protection * Non-crufty URLs * Zillions of themes and plugins * And much more . This package contains the French language translations and themes Not a second copy of the whole code. Just the translations and translated default theme. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
biet dau ban can ma chung toi khong biet
Bán nhà mặt tiền tại Kiên Lương. - Nhà mặt tiền số 853 Trương công Định - Kiên Lương -KG. - DT: 7x23; DTXD: 5x20. - Gần Trường cấp 3, Khu an ninh cực tốt, tiện mở quán cà phê, kinh doanh giải trí,nhà trọ, văn phòng đại diện v.v... -Mặt tiền hướng tây. - Giá 430.000.000đ giấy tờ hợp lệ. Liên hệ:số 853 Trương công Định - Kiên Lương -KG.ĐT: 0773 755099 - DĐ: 0984 741755 Cần người có thiện chí. Còn thương lượng. Nếu email nầy có làm phiền cho người đọc cho tôi được xin lỗi. - Tại sao đàn ông lại thích nhìn phụ nữ có mái tóc dài hơn? Khám phá tại Yahoo! Hỏi & Đáp
Re: Bug#461583: ITP: libdc1394v2 -- As the maintainer for libdc1394 didn't answer for many months, we (developers of libdc1394) would like to get involved also with maintaining the package.
On Sat, Jan 19, 2008 at 12:41:48PM -0500, Peter Antoniac wrote: > As the maintainer for libdc1394 didn't answer for many months, we > (developers of libdc1394) would like to get involved also with maintaining > the package. Moreover, the maintainer didn't follow our recommandations not > to pack the libdc1394 version 2.0 until we release it (and he packed it at > RC7). Peter de Schrijver is alive but apparently doesn't have time to respond to email. I have NMUd coriander 2.0.0~rc5 and libdc1394 2.0.0~rc7, but I uploaded them to experimental. I have already offered to take over maintainership, but haven't heard either a "no" or a "yes" from Peter. > It will be also better for the stability of the package if the > developers have also something to say in the packaging. For example, we have > releases the new version with doxygen generated web pages, pdf's and ps > documentation, so there is more documentation available for the developers. > We also think that what is now called libdc1394-examples should be called > -utils, as the binaries are more like utilities for the library. We have > already done some packaging and testing using the Ubuntu PPA tools, and you > can already see the fruits of our work here: [...] Unless Peter de Schrijver responds, I'll be happy to have a look at your packages and upload them to unstable if they are in good shape. From a quick glance, it looks OK, but I'd name the source package libdc1394-22 though. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Future Debian package candidate web pages: present and future
can anybody provide a HTTP request cron job for me? what i need is a call to http://debian.binera.de/wnpp/cron_sync_list.php5 every 30 minutes. the way i could set this with my current ISP would require 48 single cron jobs and that's too much. so i'm asking for help. please contact me if you can do this. please do not setup the cron before coordinating with me so we don't end up with 20 crons running a race :-) thanks in advance, sebastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#461634: ITP: python-mdp -- Modular toolkit for Data Processing
Package: wnpp Severity: wishlist Owner: Yaroslav Halchenko <[EMAIL PROTECTED]> * Package name: python-mdp Version : 2.1 Upstream Author : Pietro Berkes and Tiziano Zito * URL : http://mdp-toolkit.sourceforge.net/ * License : LGPL Programming Lang: Python Description : Modular toolkit for Data Processing Python data processing framework. Implemented algorithms include: Principal Component Analysis (PCA), Independent Component Analysis (ICA), Slow Feature Analysis (SFA), Independent Slow Feature Analysis (ISFA), Growing Neural Gas (GNG), Factor Analysis, Fisher Discriminant Analysis (FDA), and Gaussian Classifiers. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (900, 'testing'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#461638: ITP: jnethack -- NetHack patched to translate to Japanese
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: jnethack Version: 3.4.3+3.4.3-0.9 Upstream Author: JNetHack Project URL: http://sourceforge.jp/projects/jnethack/ License: Nethack General Public License Description: NetHack patched to translate to Japanese. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Future Debian package candidate web pages: present and future
found someone. sebastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#461651: loosing dependencies
Package: fortunes Version: 1:1.99.1-3 Currently, the `fortunes' package depends on either `fortune-mod' or `fortune-min': $ apt-cache show fortunes Package: fortunes ... Source: fortune-mod Version: 1:1.99.1-3 Provides: fortune-cookie-db Depends: fortune-mod (>= 9708-12), fortunes-min ... $ It probably doesn't make sense, provided that the fortune files may as well be read by, e. g., M-x fortune in Emacs, or even by `less'. Could this dependency be relaxed, please? The following line may be added as well, if it's necessary: Conflicts: fortune-mod (<< 9708-12) [Cc: to debian-devel, since the discussion was started there.] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: loosing dependencies
> Ralf Treinen <[EMAIL PROTECTED]> writes: >> Currently, the `fortunes' package depends on either `fortune-mod' or >> `fortune-min': [...] >> Does it make sense, provided that the fortune files may as well be >> read by M-x fortune in Emacs, or even by a plain `less'? > Probably not, it seems to me that you are right, and that this > dependency should be relaxed. ACK. >> And more generally, does it make sense for a pure-data package to >> have non-empty Depends:? > I can imagine that there are cases in which data is really specific > to a particular application, but that doesn't seem to be the case > here. But, well, one may probably find some uses for that data even outside of that application? I hardly believe that there're data that's completely useless without a particular application or applications, be it icons, sounds, or LUTs for a particular scientific code. The only situation where I see it's appropriate for an `Architecture: all' package to contain an another package in it's `Depends:' is where the package also provides scripts which require that other package to be run. > Could you please file a bug report against the fortune package? Done [1]. [1] http://bugs.debian.org/461651 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
loosing dependencies: Depends: on logrotate
Since I've already started this thread, I'm going to ask for opinions on the one more issue with the current (Etch, at least) dependencies in Debian to bother me. Is `logrotate' really necessary for those 46 packages or so in Etch to include it in their `Depends:'? Debian Policy reads: --cut: www.debian.org/doc/debian-policy/ch-relationships.html-- The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. The Depends field should also be used if the postinst, prerm or postrm scripts require the package to be present in order to run. Note, however, that the postrm cannot rely on any non-essential packages to be present during the purge phase. --cut: www.debian.org/doc/debian-policy/ch-relationships.html-- My opinion is that since `logrotate' is not required neither for the maintainer scripts in order to run, nor ``for the depending package to provide a significant amount of functionality'', this dependency should be either relaxed (to `Recommends:' or `Suggests:') or discarded completely. (And there're packages which provide a `logrotate.d/' file, but don't list `logrotate' as a dependency. Among these are `dpkg' and `apache2.2-common'.) I've already discussed on this matter [1]. The reasons for having such a dependency stated to me were, AIUT, as follows: * ``packages should not facilitate users to shoot themselves in the foot by filling up the logging partition''; yet there're a plenty of ways to do it whether `logrotate' is installed or not; I expect for the software to grant me freedom, not to revoke it in order to save me from but the very dumb mistakes; * since `logrotate' is `Priority: important', lightweight enough and it ``is the standard log rotation mechanism in Debian (including documentation in Debian policy)'', it would be there anyway, whether the dependency would be in place or not; but Debian Policy, AIUI, only mandates that the Debian packages must support `logrotate', not that the Debian users must actually use it! and isn't the absense of `logrotate' in the system a clear sign of that the user knows what he or she's doing? [1] http://bugs.debian.org/422968 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
