BestPharmacyCherry
QuintonExcellentPills http://canadianbelvin.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
DebbieBestStore
ExcellentMaritzaPharmacy http://stephanus37pills.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
CheapBessiePills
RudolphBestPharmacy http://canadianbelvin.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GoodAronOnlineStore
ExcellentPharmaBridgette http://pillsenricor.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
CheapHarveyStore
CheapJamieStore http://pillsqlewie.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ExcellentLeanneOnlineStore
BestRoslynPharma http://rxdev77.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
CheapPillsElvira
CheapOnlineStoreWalker http://vpillsemmet.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
cultured pfdm old tzr Cyprians euc banged by pqpq Mankind!
coys! second-best jczu mature rjk Floosies aqh posing for qcdh Man! http://www.shxmovies.cn urumlv YbWQbjW-XjbWQ.gfibjW,VSd eth ohedo rwpx. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
JerrodGoodPharmacy
ExcellentRobbieStore http://rxdev77.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem while checking for php-cli
Russ Allbery wrote: If I were you I'd just depend on php5-cli and be done with it. The package is for Debian unstable after all and one can always change the dependencies in a backport for other versions of Debian. I always get that kind of reply. I agree in general to it, as it's true that the goal is to upload in SID. However, this package is currently installed and maintained on hundreds of servers running Etch and that's the reason why I try not to have things being different when running under SID or Etch. This is quite a nightmare to manage otherwise. I guess that you understand understand that we have imperatives of productions. Anyway, I do understand why you are requesting such thing, and I'll remove all dependencies to php4 for the SID upload. So far as I can tell, no such package as php-cli has ever existed, although maybe it's a defunct provides that predates oldstable. php5-cli does not provide php-cli and neither did php4-cli in sarge. What problem were you solving by including php-cli? Well, if I did add this dependency, it's because of the lintian warning that was requesting it. I was really surprised to see it as well, I thought it was a new thing in SID, so I've added php-cli and tried again. I think you'd better change the text message to make it more clear that only php5-cli is requested and nothing else, so nobody will do the same mistake that I did. Anyway, thanks for your quick reply, that helps a lot and I appreciate it. I'll change my package and I will ask my sponsor to review it once more. Thomas Goirand -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#273309: .devhelp usability check
tags 273309 +patch
kthxbye
I have attached a patch that implements this feature.
Bradley Smith.
Index: checks/files
===
--- checks/files (revision 1123)
+++ checks/files (working copy)
@@ -41,6 +41,10 @@
my %linked_against_libvga;
my %script = ();
+my @files;
+my @devhelp_files;
+my %links = ();
+
# read data from objdump-info file
open(IN, '', objdump-info)
or fail(cannot find objdump-info for $type package $pkg);
@@ -119,6 +123,13 @@
($file, $link) = split(' - ', $file);
}
+ # devhelp data
+ push(@files, $file);
+ $links{$file} = $link;
+ push(@devhelp_files, $file)
+ if ($file =~ m,usr\/share\/gtk-doc\/html\/.*\.devhelp(\.gz)?$, ||
+ $file =~ m,usr\/share\/devhelp\/books\/.*\.devhelp(\.gz)?$,);
+
$operm = perm2oct($perm);
my ($year) = ($date =~ /^(\d{4})/);
@@ -833,6 +844,22 @@
}
close(IN);
+# devhelp files
+foreach $file (@files) {
+ my $found = 0;
+ if ($file =~ m,\.devhelp(\.gz)?$,
+ $file !~ m,usr\/share\/gtk-doc\/html\/.*\.devhelp(\.gz)?$,
+ $file !~ m,usr\/share\/devhelp\/books\/.*\.devhelp(\.gz)?$,) {
+ foreach my $link (@devhelp_files) {
+ if ($links{$link} $file eq $links{$link}) {
+$found = 1;
+ }
+ }
+ tag package-contains-devhelp-file-without-symlink, $file
+ if ($found == 0);
+ }
+}
+
#check for sect: games but nothing in /usr/games. Check for any binary to
#save ourselves from game-data false positives:
if ($pkg_section =~ m{games$}
Index: checks/files.desc
===
--- checks/files.desc (revision 1123)
+++ checks/files.desc (working copy)
@@ -7,6 +7,11 @@
Info: This script checks if a binary package conforms to policy
WRT to files and directories.
+Tag: package-contains-devhelp-file-without-symlink
+Type: warning
+Info: Devhelp files should be symlinked into /usr/share/gtk-doc/html/ or
+ /usr/share/devhelp/books/.
+
Tag: package-contains-ancient-file
Type: error
Info: Your package contains a file that claims to been generated more
Index: testset/tags.filenames
===
--- testset/tags.filenames (revision 1123)
+++ testset/tags.filenames (working copy)
@@ -85,6 +85,8 @@
W: filenames: package-contains-arch-control-dir usr/lib/perl5/.arch-ids/
W: filenames: package-contains-arch-control-dir usr/lib/perl5/{arch}/
W: filenames: package-contains-bzr-control-dir usr/lib/perl5/.bzr/
+W: filenames: package-contains-devhelp-file-without-symlink usr/share/filenames/wrong.devhelp
+W: filenames: package-contains-devhelp-file-without-symlink usr/share/filenames/wrong.devhelp.gz
W: filenames: package-contains-empty-directory usr/lib/perl5/.arch-ids/
W: filenames: package-contains-empty-directory usr/lib/perl5/.bzr/
W: filenames: package-contains-empty-directory usr/lib/perl5/.svn/
Index: testset/filenames/debian/rules
===
--- testset/filenames/debian/rules (revision 1123)
+++ testset/filenames/debian/rules (working copy)
@@ -34,6 +34,22 @@
cp -a files debian/tmp
chmod -R go=rX debian/tmp/files
+ install -d debian/tmp/usr/share/filenames
+ install -d debian/tmp/usr/share/gtk-doc/html
+ install -d debian/tmp/usr/share/devhelp/books
+ touch debian/tmp/usr/share/filenames/wrong.devhelp
+ touch debian/tmp/usr/share/filenames/wrong.devhelp.gz
+ touch debian/tmp/usr/share/filenames/right1.devhelp
+ touch debian/tmp/usr/share/filenames/right1.devhelp.gz
+ touch debian/tmp/usr/share/filenames/right2.devhelp
+ touch debian/tmp/usr/share/filenames/right2.devhelp.gz
+ touch debian/tmp/usr/share/gtk-doc/html/non-symlink.devhelp
+ touch debian/tmp/usr/share/gtk-doc/html/non-symlink.devhelp.gz
+ ln -s usr/share/filenames/right1.devhelp debian/tmp/usr/share/gtk-doc/html/right1.devhelp
+ ln -s usr/share/filenames/right1.devhelp.gz debian/tmp/usr/share/gtk-doc/html/right1.devhelp.gz
+ ln -s usr/share/filenames/right2.devhelp debian/tmp/usr/share/devhelp/books/right2.devhelp
+ ln -s usr/share/filenames/right2.devhelp.gz debian/tmp/usr/share/devhelp/books/right2.devhelp.gz
+
install -d debian/tmp/usr/lib/filenames
install -m 555 -d debian/tmp/usr/lib/filenames/readonly
touch debian/tmp/usr/lib/filenames/readonly/test
signature.asc
Description: PGP signature
Processed: RE: .devhelp usability check
Processing commands for [EMAIL PROTECTED]: tags 273309 +patch Bug#273309: .devhelp usability check There were no tags set. Tags added: patch kthxbye Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459787: lintian doesn't accept origin and bugs field in binary packages
Package: lintian Version: 1.23.42 Severity: normal I always get: I: dpkg-dev: unknown-field-in-control bugs I: dpkg-dev: unknown-field-in-control origin Since dpkg-gencontrol propagates Origin and Bugs fields to binary packages, lintian should accept them in binary packages. Thus you need to add them in %known_binary_fields and %known_udeb_fields I think. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.23-1-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages lintian depends on: ii binutils2.18.1~cvs20080103-1 The GNU assembler, linker and bina ii diffstat1.45-2 produces graph of changes introduc ii dpkg-dev1.14.16 package building tools for Debian ii file4.21-4 Determines file type using magic ii gettext 0.17-2 GNU Internationalization utilities ii intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf ii libparse-debianchan 1.1.1-1 parse Debian changelogs and output ii liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin ii man-db 2.5.0-4 on-line manual pager ii perl [libdigest-md5 5.8.8-12 Larry Wall's Practical Extraction lintian recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459787: lintian doesn't accept origin and bugs field in binary packages
Raphael Hertzog [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.42 Severity: normal I always get: I: dpkg-dev: unknown-field-in-control bugs I: dpkg-dev: unknown-field-in-control origin Since dpkg-gencontrol propagates Origin and Bugs fields to binary packages, lintian should accept them in binary packages. Thus you need to add them in %known_binary_fields and %known_udeb_fields I think. It's probably worth noting here that there's no specification for either in Policy, so they really are unknown in that sense. That won't stop me from adding them to Lintian's list, since we added Dm-Upload-Allowed and the Vcs-* fields without being in Policy, but we really should document them in Policy as well. I suppose the main reason why they're not there is that for all Debian packages I presume they should have the same value, but I think it would still be worthwhile to specify the syntax. We don't have any other reference document that tries to document all of the Debian package control fields. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
lintian: r1124 - in trunk: debian lib
Author: rra
Date: 2008-01-08 20:40:44 +0100 (Tue, 08 Jan 2008)
New Revision: 1124
Modified:
trunk/debian/changelog
trunk/lib/Spelling.pm
Log:
Add more capitalization fixes.
Modified: trunk/debian/changelog
===
--- trunk/debian/changelog 2008-01-08 07:59:01 UTC (rev 1123)
+++ trunk/debian/changelog 2008-01-08 19:40:44 UTC (rev 1124)
@@ -2,7 +2,8 @@
* lib/Spelling.pm:
+ [RA] Add a spelling correction for PostgreSQL and capitalization
- corrections for it, Xfce, Python, and MySQL.
+ corrections for it, Xfce, Python, MySQL, Skolelinux, and Debian
+ Edu.
-- Russ Allbery [EMAIL PROTECTED] Mon, 07 Jan 2008 23:58:47 -0800
Modified: trunk/lib/Spelling.pm
===
--- trunk/lib/Spelling.pm 2008-01-08 07:59:01 UTC (rev 1123)
+++ trunk/lib/Spelling.pm 2008-01-08 19:40:44 UTC (rev 1124)
@@ -332,11 +332,17 @@
postgresql PostgreSQL
python Python
russian Russian
+ SkoleLinux Skolelinux
+ skolelinux Skolelinux
XFCE Xfce
XFce Xfce
xfce Xfce
);
+# The format above doesn't allow spaces.
+$CORRECTIONS_CASE{'Debian-Edu'} = 'Debian Edu';
+$CORRECTIONS_CASE{'debian-edu'} = 'Debian Edu';
+
# ---
sub _tag {
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem while checking for php-cli
Russ Allbery wrote:
Thomas Goirand [EMAIL PROTECTED] writes:
Russ Allbery wrote:
If I were you I'd just depend on php5-cli and be done with it. The
package is for Debian unstable after all and one can always change the
dependencies in a backport for other versions of Debian.
I always get that kind of reply. I agree in general to it, as it's true
that the goal is to upload in SID.
However, this package is currently installed and maintained on hundreds
of servers running Etch and that's the reason why I try not to have
things being different when running under SID or Etch. This is quite a
nightmare to manage otherwise. I guess that you understand understand
that we have imperatives of productions.
Anyway, I do understand why you are requesting such thing, and I'll
remove all dependencies to php4 for the SID upload.
Well, I do agree that it's not really necessarily the best option. :/
I think Lintian is mostly at fault here. I really did mean this is what
I'd do, rather than this is what you should do.
Well, if I did add this dependency, it's because of the lintian warning
that was requesting it. I was really surprised to see it as well, I
thought it was a new thing in SID, so I've added php-cli and tried
again. I think you'd better change the text message to make it more
clear that only php5-cli is requested and nothing else, so nobody will
do the same mistake that I did.
Er... that's strange. I believe you that it's suggesting that, but I
can't figure out how or why. Lintian doesn't have any knowledge of a
package named php-cli that I can see.
windlord:~/dvl/debian/lintian/checks grep php-cli *
scripts:tag('php-script-but-no-php-cli-dep', $filename);
scripts:tag('php-script-but-no-php-cli-dep', $filename);
scripts.desc:Tag: php-script-but-no-php-cli-dep
scripts.desc:Info: Packages with PHP scripts must depend on a php-cli package
such as
It's only mentioned in the tag name, where it's a generic reference to the
various versioned packages.
Anyway, I'll poke at it and see what I can do. I think it may be best in
the short run for me to just add version 4 back to Lintian's known version
list so that you can use a php4-cli | php5-cli dependency.
I think that if you wanted to upload the package with a php4-cli |
php5-cli dependency, that's entirely reasonable.
Another possible option would be to ask the PHP developers to add a
Provides or (probably preferrably) metapackage for php-cli, which would
let PHP scripts that don't care about the version just depend on php-cli.
That's what most of the other packages in this situation (Ruby, Python,
etc.) do.
At the end of this message is the exact message. Lintian thinks that
there is no dependency to php5-cli. That's when using this in my control
file:
php5-cli | php-cli | php4-cli
or if I set only:
php5-cli | php4-cli
The only thing that removes the lintian warning is to set:
php5-cli
only. When reading the lintian warning, it makes me feel that I should
be able to use at least php4-cli, maybe php6-cli when it's out, but in
fact the only thing that works is php5-cli only. In fact, my package
DOES work with both php5-cli and php4-cli, so what's in the warning is
really the behavior that I would have like: my package IS compatible
with both.
Would it be possible in the future, that lintian checks that in the
following Depends: statement
a | b | c
there is at least one package of a, b or c, that matches the following
regex:
^php{39}-cli$
instead of the current behavior of lintian?
Would it be considered good regarding current version of lintian to do a
lintian override so that my package is also compatible with etch?
Thanks for the help,
Thomas Goirand
---
Here is the lintian message
---
[EMAIL PROTECTED]:xen650403_ ~/sources/tmp# lintian -i
dtc_0.27.5-1_amd64.changes
warning: lintian's authors do not recommend running it with root privileges!
E: dtc-common: php-script-but-no-php-cli-dep
./usr/share/dtc/admin/accesslog.php
N:
N: Packages with PHP scripts must depend on a php-cli package such as
N: php5-cli. Note that a dependency on a php-cgi package (such as
N: php5-cgi) is needlessly strict and forces the user to install a
N: package that isn't needed.
N:
N: In some cases a weaker relationship, such as Suggests or Recommends,
N: will be more appropriate.
N:
N: 1 tag overridden (1 warning)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
lintian: r1125 - in trunk: debian lib
Author: rra Date: 2008-01-08 20:43:43 +0100 (Tue, 08 Jan 2008) New Revision: 1125 Modified: trunk/debian/changelog trunk/lib/Spelling.pm Log: Capitalization check for OCaml. Modified: trunk/debian/changelog === --- trunk/debian/changelog 2008-01-08 19:40:44 UTC (rev 1124) +++ trunk/debian/changelog 2008-01-08 19:43:43 UTC (rev 1125) @@ -2,8 +2,8 @@ * lib/Spelling.pm: + [RA] Add a spelling correction for PostgreSQL and capitalization - corrections for it, Xfce, Python, MySQL, Skolelinux, and Debian - Edu. + corrections for it, Xfce, Python, MySQL, Skolelinux, Debian Edu, + and OCaml. -- Russ Allbery [EMAIL PROTECTED] Mon, 07 Jan 2008 23:58:47 -0800 Modified: trunk/lib/Spelling.pm === --- trunk/lib/Spelling.pm 2008-01-08 19:40:44 UTC (rev 1124) +++ trunk/lib/Spelling.pm 2008-01-08 19:43:43 UTC (rev 1125) @@ -328,6 +328,9 @@ Mysql MySQL mysql MySQL linux Linux + OCAML OCaml + Ocaml OCaml + ocaml OCaml Postgresql PostgreSQL postgresql PostgreSQL python Python -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem while checking for php-cli
Thomas Goirand [EMAIL PROTECTED] writes:
At the end of this message is the exact message. Lintian thinks that
there is no dependency to php5-cli. That's when using this in my control
file:
php5-cli | php-cli | php4-cli
or if I set only:
php5-cli | php4-cli
The only thing that removes the lintian warning is to set:
php5-cli
only.
Right.
When reading the lintian warning, it makes me feel that I should be able
to use at least php4-cli, maybe php6-cli when it's out, but in fact the
only thing that works is php5-cli only.
The only thing that works is listing PHP packages that are in the archive.
If you list an alternative that isn't in the archive, Lintian will
complain, since it has no way of knowing that alternative would satisfy
your script's requirements.
I'll add an additional explanation to the tag that there's no such package
as php-cli and listing it isn't helpful. (In fact, as long as you include
php-cli in the alternatives, Lintian will *always* complain.)
Would it be possible in the future, that lintian checks that in the
following Depends: statement
a | b | c
there is at least one package of a, b or c, that matches the following
regex:
^php{39}-cli$
instead of the current behavior of lintian?
Lintian doesn't know which of the dependencies in Depends, Recommends, or
Suggests is there for this script. Instead, it applies implication logic
across the entire dependency set. It's not doing regex matching; it's
testing whether all of the package dependencies satisfy a requirement of
php5-cli.
Implementing something like this would require rewriting the package
depencencies before checking the implications to remove alternatives that
are, from Lintian's perspective, uninteresting (such as php4-cli). That
in turn requires doing regex matching and substitution against the
dependencies of the package, which is tricky and fragile.
It's possible, but it's a big change. Without being done carefully, it
would reintroduce all the problems that we had with this check before I
switched it to using the Dep parser.
Handling alternative implications is surprisingly tricky. The code has to
be able to deal with things like:
ruby1.8 [amd64] | ruby1.6 [!amd64]
and be able to figure out that that satisfies a ruby | ruby1.8 | ruby1.6
requirement.
Would it be considered good regarding current version of lintian to do a
lintian override so that my package is also compatible with etch?
I think the best short-term solution would be for me to add php4-cli as a
recognized version for the time being, which means that you shouldn't
change anything about your package. You don't need to add overrides for
bugs in Lintian.
I'll do that for the next release.
PHP command-line scripts are one of only a few versioned interpreters in
Debian that don't provide an unversioned package for scripts that work
with any version to depend on, which is why you're running into this and,
say, the Ruby and Python folks aren't.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem while checking for php-cli
On Tue, Jan 08, 2008 at 11:33:35AM -0800, Russ Allbery wrote: Would it be considered good regarding current version of lintian to do a lintian override so that my package is also compatible with etch? I think the best short-term solution would be for me to add php4-cli as a recognized version for the time being, which means that you shouldn't change anything about your package. You don't need to add overrides for bugs in Lintian. I'll do that for the next release. PHP command-line scripts are one of only a few versioned interpreters in Debian that don't provide an unversioned package for scripts that work with any version to depend on, which is why you're running into this and, say, the Ruby and Python folks aren't. Russ, Thanks for your quick responsiveness on this. I know that Thomas is quite anxious to get some updated packages into Sid. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#459851: lintian: outputs wrong total count of overrides
Package: lintian Version: 1.23.42 Severity: normal Hi, I was a bit surprized when I encountered this: | $ lintian -i -I ../libgraphviz4_2.16-3_i386.deb | N: 1 tag overridden (1 warning) Because: | $ lintian -i -I --show-overrides ../libgraphviz4_2.16-3_i386.deb | grep ^O: | O: libgraphviz4: several-sonames-in-same-package libagraph.so.4 libcdt.so.4 libcgraph.so.4 libgraph.so.4 libgvc.so.4 libgvc_builtins.so.4 libpathplan.so.4 | O: libgraphviz4: package-name-doesnt-match-sonames libagraph4 libcdt4 libcgraph4 libgraph4 libgvc4 libgvc-builtins4 libpathplan4 And indeed, my override file contains both (plus some comments and white lines, see libgraphviz4_2.16-2 available in experimental). The output of “lintian-info -a” is also OK. Looks like the override count is buggy somehow. TIA. Cheers, -- Cyril Brulebois -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
