Bug#636086: [PATCH] Use C.UTF-8 from current libc-bin, rather than our own private en_US.UTF-8
* Niels Thykier ni...@thykier.net, 2011-08-22, 21:44:
+if (-d $LINTIAN_ROOT/locale/C.UTF-8) {
+ $ENV{LOCPATH} = $LINTIAN_ROOT/locale;
+} elsif (-d '/var/lib/lintian/locale/C.UTF-8') {
+ $ENV{LOCPATH} = '/var/lib/lintian/locale';
+}
Hmm, but we never generate C.UTF-8 (if C.UTF-8 is not provided by
libc-bin, then we generate en_US.UTF-8).
Did you mean .../locale/en_US.UTF-8?
+if [ ! -d '/usr/lib/locale/en_US.UTF-8' ] ; then
/usr/lib/locale/en_US.UTF-8 doesn't exist.
Did you mean /usr/lib/locale/C.UTF-8?
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110823112229.ga2...@jwilk.net
Fwd: [rt.debian.org #3361] Please install debhelper on bellini.debian.org (lintian)
Original Message Subject: [rt.debian.org #3361] Please install debhelper on bellini.debian.org (lintian) Date: Tue, 23 Aug 2011 12:22:14 + From: Peter Palfrader via RT r...@rt.debian.org Reply-To: r...@rt.debian.org To: ni...@thykier.net On Mon Aug 22 18:40:11 2011, ni...@thykier.net wrote: Hi We would like to have debhelper installed on bellini. When we update lintian on bellini, we have to run part of the build (to build the user manual etc.) and that involves a few debhelper commands. Added to the metapackage and installed. -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e539b78.6070...@thykier.net
[Draft] Lintian-harness - supporting lintian.d.o-like setups
Hi, It is time for another major lintian branch. This time I am proposing we target making lintian.d.o-like setups easier. To my knowledge, only two of such setups currently exists and both of them were done by (or with the help of) the Lintian Maintainers. Research indicates that Ubuntu in 2008 considered to improve the current situation, but to my knowledge that their work never really further than the blueprint (the spec has a link to the blueprint). As written with big fat letters, the below is a draft and it can be changed. It is based on the a private TODO-list, the Ubuntu Blueprint and from what I picked up from discussions here and there. I hope we can get a good discussion on the topic. After a bit of discussion I will create a wiki-page for the specification. I am also hoping that some of you are willing to invest a bit of time coding or/and testing the solution as it develops. Should you be interested, doc/README.developers in the source code can hopefully get you started. A few parts included are mostly comments for the Lintian Maintainers; on some internal parts (like the part about refactoring/removing unpacked/). Should there be parts you do not understand, please do ask about them. I may have unwillingly assumed you know the internals or the workflow of the current code. :) ~Niels THIS SPECIFICATION IS A DRAFT and is subject to change. This specification aims to provide official support for setting up lintian.debian.org-like instances. This is based on a existing Ubuntu Blueprint[UB] and the private/TODO-file[TODO] in the Lintian source code. [UB] https://wiki.ubuntu.com/LintianHarness [TODO] http://anonscm.debian.org/gitweb/?p=lintian/lintian.git;a=blob;f=private/TODO;h=3936b340b730175ef98bd902785403b69d5437e5;hb=9505109c3006edf6f360da8da2d530c42337ee4f#l92 Requirements Some of these are already supported in the current implementation; they are listed here again for completeness. * A new frontend called lintian-harness - Must have a well-defined purpose and workflow. - Must be well documented. - it should not take a Lintian Maintainer to use it. - Must be cron-friendly - Expected to be the primary use method of the frontend. - Must (continue to) support incremental runs. * The resulting reports must be (re-)brandable. - (i.e.) Lintian may not be checking against the Debian Policy Manual, etc. * The lintian-harness will be shipped in a separate package that depends on the lintian package. * Must support fetching from http(s):// mirrors. Ideas, Issues and Extensions * The remaining scripts in unpack/ could be replaced by making the existing Laboratory code smarter. - reporting/ is one of the last consumers of unpack/ - Zach suggested sync'ing from a mirror would be useful if Lintian was turned into a Static Analysis Framework. * Use locks when running. - Currently you have to manually disable the cron-job if if you are doing an out of band lintian run. * Hooks: - Allow local system specific code to be run (i.e.) after the html site has been updated. - (hopefully) everyone uses the same frontend * Migrate to template-toolkit? - There was some talk about it; it should be done before this spec is implemented. * Adding support for display comment overrides. - This would probably be a good time. * Testing - The lintian frontend itself is used by 300+ tests, so we are fairly certain it is not obviously broken, if there are no test failures. We can unit test some of the code used by lintian-harness, but can we do better and actually test the lintian-harness frontend (in some sane manner)? Proposed Solution = File System Layout -- The website setup currently uses the templates directly from the LINTIAN_ROOT. This complicates updating templates, since LINTIAN_ROOT will be overwritten on upgrades. This can be solved by splitting the setup into four distinct major components: LINTIAN_ROOT, SITE_ROOT, WORK_ROOT and HTML_DIR. * LINTIAN_ROOT is the base of the Lintian installation. Usually this will be /usr/share/lintian. - This is read-only for the lintian processes. * SITE_ROOT is configuration/setup rules for the site. This is not (by design at least) public available via the HTML site. - The local admin/user can deploy site specific templates and configuration here. - This is read-only for the lintian processes. * WORK_ROOT is the root dir for lintian to write its cache and its logs. - This needs to be readable and writable by the lintian processes. * HTML_DIR is where the html site is written on the machine. lintian-harness will generate all the data presented here. - This is write-only for the lintian processes. - lintian-harness may delete HTML_DIR and its entire contents. HTML_DIR is not allowed to be a
Processed: Re: Bug#474590: [frontend] add a parsable reason for overrides and optionally require it
Processing commands for cont...@bugs.debian.org: tags 474590 + patch Bug #474590 [lintian] [frontend] add a parsable reason for overrides and optionally require it Added tag(s) patch. thanks Stopping processing here. Please contact me if you need assistance. -- 474590: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474590 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13141143215299.transcr...@bugs.debian.org
Bug#474590: [frontend] add a parsable reason for overrides and optionally require it
tags 474590 + patch thanks Hi I am considering to the attached patch to the master branch. It solves collecting the override comments and printing them (with --show-overrides). A comment is not carried through to the next override (of same tag); but this is matter of updated file_overrides. Furthermore, any empty line will discard the currently collected comment (if any). If an empty line should be in the comment to be collected, simply add a comment marker with nothing after it[0]. It will not mark override comments with anything special. I wonder if we should extend the Lintian::Output API to get these comments marked with a special marker. Finally (as a side thing), this patch makes lintian pre-compute the pattern-overrides (any override using *). I did consider merging the statistics with the Lintian::Tag::Override; my argument against it is that L::T::Override would then lose its immutability. For non-pattern overrides, Lintian will use its current hash look up, since it has (on average) constant running time. I could not figure out a way to use L::T::Override-overrides (without hash look up) without losing that property. ~Niels [0] This allow people to do: # General comment about the overrides which is not displayed # This will be displayed # # ... and so will this. some-tag: some extra 0001-Collect-comments-from-override-files.patch Description: application/wine-extension-patch
Bug#639018: lintian: Grammar nitpicks in new tags
Package: lintian Version: 2.5.2 Severity: wishlist Hi, First off, I feel bad filing this bug, since I do appreciate the work you put into Lintian and into writing new checks and don't like quibbling over commas and words, but a couple of the new tag phrasings confused me a bit. The tag description of debian-rules-uses-deprecated-makefile says ... appears to include a Makefile, which has been deprecated, implying that _including_ a Makefile (any Makefile at all) has been deprecated. While I know CDBS isn't in favor, I didn't realize it had fallen so far... until I realized the check really means appears to include a Makefile which has been deprecated, i.e., the Makefile is the one that's deprecated. (Or better yet, a Makefile that has been deprecated.) See e.g., http://www.grammar-monster.com/lessons/which_that_who_comma_or_not.htm The tag description for package-has-long-file-name starts with The package has a very long package name...; presumably that should be file name. (The rest of the tag seems a little confused, e.g., the filename length on of the package, but the meaning is clear enough.) Thanks again for providing these new checks... I will now go figure out how source format 3.0 works. -- Geoffrey Thomas geo...@mit.edu -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1108231345300.20...@tyger.mit.edu
[SCM] Debian package checker branch, master, updated. 2.5.2-50-ga702809
The following commit has been merged in the master branch:
commit a702809dfe43f29333a53036fc77ff8e15a2
Author: Niels Thykier ni...@thykier.net
Date: Tue Aug 23 23:38:13 2011 +0200
Improved the descriptions of some tags
diff --git a/checks/filename-length.desc b/checks/filename-length.desc
index eefec1b..e94b9d1 100644
--- a/checks/filename-length.desc
+++ b/checks/filename-length.desc
@@ -7,26 +7,26 @@ Info: This script checks for long package file names
Tag: package-has-long-file-name
Severity: normal
Certainty: certain
-Info: The package has a very long package name. This may complicate
- shipping the package on some media such as CDs, where the filename
- length may be limited.
+Info: The package has a very long filename. This may complicate
+ shipping the package on some media that put restrictions on the
+ length of the filenames (such as CDs).
.
- For architecture dependent package names, the number in the brackets
+ For architecture dependent package, the number in the brackets
represents the filename length on of the package on the architecture
with the longest name known to Lintian.
.
- The tag is emitted based on the longest architecture rather than the
- current architecture.
+ The tag is emitted based on the length of longest architecture name
+ rather than the name of the current architecture.
Ref: http://lists.debian.org/debian-devel/2011/03/msg00943.html
Tag: source-package-component-has-long-file-name
Severity: normal
Certainty: certain
Info: The source package has a component with a very long filename.
- This may complicate shipping the package on some media such as CDs,
- where the filename length may be limited.
+ This may complicate shipping the package on some media that put
+ restrictions on the length of the filenames (such as CDs).
.
- Note for architecture dependent packages, this will tag will be
- triggered for the longest architecture known.
+ Lintian only checks emits this tag once per source package based
+ on the component with the longest filename.
Ref: http://lists.debian.org/debian-devel/2011/03/msg00943.html
diff --git a/checks/rules.desc b/checks/rules.desc
index 034399f..36df500 100644
--- a/checks/rules.desc
+++ b/checks/rules.desc
@@ -64,7 +64,7 @@ Tag: debian-rules-uses-deprecated-makefile
Severity: normal
Certainty: certain
Info: The ttdebian/rules/tt file for this package appears to
- include a Makefile, which has been deprecated. Please refer to the
+ include a Makefile that has been deprecated. Please refer to the
documentation of the providing package for a replacement (if any).
Tag: debian-rules-uses-pwd
diff --git a/debian/changelog b/debian/changelog
index b28e13a..edb2f6b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -37,6 +37,8 @@ lintian (2.5.3) UNRELEASED; urgency=low
be the first dependency if it is only included in the perl
from experimental. Thanks to Dominic Hargreaves for the
report and the patch. (Closes: #637793)
+ * checks/{filenames,rules}.desc:
++ [NT] Improved the descriptions of some tags. (Closes: #639018)
* checks/files:
+ [NT] Added exceptions to extra-license-file for manpages,
static libraries, .pc-, elf and pyshared-data-files. This
--
Debian package checker
--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1qvytg-0001ty...@vasks.debian.org
Processed: limit source to lintian, tagging 639018
Processing commands for cont...@bugs.debian.org:
#lintian (2.5.3) UNRELEASED; urgency=low
#
# * checks/{filenames,rules}.desc:
#+ [NT] Improved the descriptions of some tags. (Closes: #639018)
#
limit source lintian
Limiting to bugs with field 'source' containing at least one of 'lintian'
Limit currently set to 'source':'lintian'
tags 639018 + pending
Bug #639018 [lintian] lintian: Grammar nitpicks in new tags
Added tag(s) pending.
thanks
Stopping processing here.
Please contact me if you need assistance.
--
639018: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639018
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/handler.s.c.131413638218531.transcr...@bugs.debian.org
