Bug#1017951: lintian: Recognize cherry-picked patches as forwarded upstream

[Jeremy Bicha]

Source: lintian
Version: 2.115-2

I use this packaging workflow where I have fetched an upstream git remote:
gbp pq import
git cherry-pick -x 123456
gbp pq export

This creates Debian patches that have this line

(cherry picked from commit 12345)

Although this doesn't strictly follow DEP-3, I think it complies with
the general idea and I don't think these patches should get tagged as
patch-not-forwarded-upstream

https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Debian/Patches/Dep3.pm#L88

Thank you,
Jeremy Bicha

Bug#924082: more dh-sequences

[Jeremy Bicha]

On Sat, Mar 9, 2019 at 9:27 AM Chris Lamb  wrote:
> https://salsa.debian.org/lintian/lintian/commit/f8887189f6bafcf799889b271ce30e8cd7311c03
>
> 
> Support dh-sequence-{gir,gnome,python3} virtual packages as satisfying 
> various build-dependencies. (Closes: #924082)
> 

We can grep through the Packages list to find more dh-sequence provides.
dh-python also provides dh-sequence-pypy and dh-sequence-python2
cli-common-dev provides dh-sequence-cli
debhelper provides dh-sequence-dwz, dh-sequence-installinitramfs,
dh-sequence-systemd
libdbi-perl provides dh-sequence-perl-dbi
libimager-perl provides dh-sequence-perl-imager
scour provides dh-sequence-scour

Thanks,
Jeremy Bicha

Bug#924082: lintian: missing-build-dependency triggered for dh-sequence

[Jeremy Bicha]

Source: lintian
Version: 2.10.0

debhelper 12 supports a new special dh-sequence- build-depends feature
[1]. For instance, a Build-Depends on dh-sequence-gnome (a virtual
package provided by gnome-pkg-tools) will automatically pass the
'--with gnome' option to dh without needing that to be specified in
debian/rules.

The lintian tags need to be updated for this. For instance, here's the
lintian errors I got with totem 3.32.0-1 targeted at experimental. The
final error "missing-build-dependency gnome-pkg-tools" triggered an
auto-reject.


E: totem source: missing-build-dependency-for-dh_-command dh_python3
=> dh-python
E: totem source: missing-build-dependency-for-dh_-command
dh_girepository => gobject-introspection
E: totem source: missing-build-dependency gnome-pkg-tools


So if you find the dh_python3 helper is being used, a Build-Depends on
dh-sequence-python3 should satisfy the requirement.

If you can, I'm requesting that this issue be fixed for Buster since a
growing number of packages will be using dh-sequence.

[1] https://manpages.debian.org/unstable/dh#OPTIONS

Thanks,
Jeremy Bicha

Bug#921449: lintian: stop saying that GTK is misspelled

[Jeremy Bicha]

Source: lintian
Version: 2.5.124
Severity: minor

GTK+ is now GTK so I suggest dropping these 2 lines:
https://salsa.debian.org/lintian/lintian/blob/master/data/spelling/corrections-case#L54-55

I don't really think it's worth complaining about GTK+ since I believe
GTK3 needs to still identify itself as GTK+.

References

https://gitlab.gnome.org/GNOME/gtk/issues/1439

Thanks,
Jeremy Bicha

Bug#920536: lintian: fails to build because of test failure

[Jeremy Bicha]

Source: lintian
Version: 2.5.124
Severity: serious
Tags: ftbfs

lintian fails to build as seen in Ubuntu and with Reproducible Builds.
The latest upload was not a source-only upload so there isn't a
failure on the buildds.

https://tests.reproducible-builds.org/debian/rb-pkg/lintian.html
https://launchpad.net/ubuntu/+source/lintian/2.5.124/+build/16320548

Build log excerpt


 Tags do not match
# --- t/tags/tests/legacy-libbaz/tags 2019-01-24 22:47:53.0 +
# +++ 
/build/1st/lintian-2.5.124/debian/test-out/tags/tests/legacy-libbaz/tags.actual.parsed.sorted
2020-02-28 21:47:32.0 +
# @@ -33,8 +33,12 @@
#  I: libbaz1-dev: package-contains-empty-directory usr/include/
#  I: libbaz1-dev: wrong-section-according-to-package-name libbaz1-dev
=> libdevel
#  I: libbaz1: binary-has-unneeded-section
usr/lib/ma-dir/perl/version/auto/Foo/Foo.so .comment
# +I: libbaz1: file-references-package-build-path usr/lib/libbaz1.so.1.0.3b
# +I: libbaz1: file-references-package-build-path usr/lib/libbaz3.so.1.0.3b
# +I: libbaz1: file-references-package-build-path usr/lib/libfoo2.so.1.0.3b
#  I: libbaz1: no-md5sums-control-file
#  I: libbaz1: symbols-file-missing-build-depends-package-field
# +I: libbaz2-dbg: file-references-package-build-path
usr/lib/debug/usr/lib/libbaz2.so.1.0.3b
#  I: libbaz2-dbg: no-md5sums-control-file
#  I: libbaz2-dbg: wrong-section-according-to-package-name libbaz2-dbg => debug
#  I: libbaz2-dev: no-md5sums-control-file
#   Failed test 'Lintian tags match for legacy-libbaz'
#   at /build/1st/lintian-2.5.124/lib/Test/Lintian/Run.pm line 334.
# Looks like you failed 1 test of 1.


Thanks,
Jeremy Bicha

Bug#920314: lintian: vcs-field-has-unexpected-spaces has false positives

[Jeremy Bicha]

On Thu, Jan 24, 2019 at 3:43 AM Chris Lamb  wrote:
>   * Can you confirm that "hg clone  -b foo" works? If so, we
> should update Policy to (at least) also permit "-b branchname"
> or "[branchname]" for Mercurial repos.

The manpage suggests that -b works for hg, but hg is rare enough in
Debian that I'm not personally interested in updating policy for it.

I agree with the suggestions here that none of these are currently
valid according to Debian Policy. Could you please update the Lintian
extended description for this tag to link to
https://www.debian.org/doc/debian-policy/ch-controlfields.html#version-control-system-vcs-fields
?
Once that's done, feel free to close this bug.

Thanks,
Jeremy Bicha

Bug#920314: lintian: vcs-field-has-unexpected-spaces has false positives

[Jeremy Bicha]

Source: lintian
Version: 2.5.123

I think all of these are false positives except for rust-num-cpus.

https://lintian.debian.org/tags/vcs-field-has-unexpected-spaces.html

In particular, -b or --branch should be allowed for Vcs-Git (but not
Vcs-Browser). One usecase is tot have a separate branch for each
Debian series.

Because you can then use
git clone https://salsa.debian.org/gnome-team/atk.git -B debian/jessie

It looks like hg works the same way.

Thanks,
Jeremy Bicha

Bug#918444: lintian: Guile-2.2 object files triggger several warnings and errors

[Jeremy Bicha]

Source: lintian
Version: 2.5.119
X-Debbugs-CC:guile-...@packages.debian.org

It looks like the Guile 2.2 object files are reported as errors and warnings for
- binary-from-other-architecture
- shared-lib-without-dependency-information
- unstripped-binary-or-object

An example package is aisleriot . (You can also easily switch the
Build-Depends in buster from guile-2.2-dev to guile-2.0-dev to
compare.)

Maybe it would be helpful to exclude .go and .gox files from these checks?

Note 1
-
lintian isn't the only thing that has trouble with these unusual
files. See https://bugs.debian.org/907061 for dh_strip.

Note 2
-
These are not to be confused with .go files from the Go programming language.
I guess Go tends to put their files in /usr/share/
and Guile puts its files in /usr/lib/

Thanks,
Jeremy Bicha

Bug#917345: lintian: Include debhelper-compat method in description of setting compat level

[Jeremy Bicha]

Source: lintian
Version: 2.5.118

The description of tags like
package-uses-experimental-debhelper-compat-version and
package-uses-deprecated-debhelper-compat-version suggest 2 different
ways of setting the debhelper compat level.

It should instead suggest the new debhelper-compat Build-Depends
method which looks like it is now the recommended way to set the
compat level, regardless of whether you use compat level 12 yet.

See https://manpages.debian.org/unstable/debhelper#COMPATIBILITY_LEVELS

Thanks,
Jeremy Bicha

Bug#917344: lintian: debhelper compat 12 is no longer experimental

[Jeremy Bicha]

Source: lintian
Version: 2.5.118

debhelper 12 was released this week. With this release, compat level
12 is now the recommended compat level. [1]

Therefore, I suggest bumping data/debhelper/compat-level
recommended=12
experimental=13

[1] 
https://manpages.debian.org/unstable/debhelper#Supported_compatibility_levels

Thanks,
Jeremy Bicha

Bug#916497: package-contains-documentation-outside-usr-share-doc should ignore /usr/share/help

[Jeremy Bicha]

Source: lintian
Version: 2.5.116

Please have the package-contains-documentation-outside-usr-share-doc
check ignore /usr/share/help/ .

https://lintian.debian.org/full/pkg-gnome-maintain...@lists.alioth.debian.org.html#deja-dup
and some other GNOME packages are getting this tag emited for
contribute pages.

Many GNOME projects install user help to /usr/share/help/ (It was
intended to be cross-desktop but KDE ended up not implementing it
yet.) Since it is a widely used documentation directory, emitting this
tag is wrong here.

Thanks,
Jeremy Bicha

Bug#909267: library-not-linked-against-libc: downgrade from error

[Jeremy Bicha]

Chris, see https://bugs.debian.org/896012

Thanks,
Jeremy Bicha

Bug#909267: library-not-linked-against-libc: downgrade from error

[Jeremy Bicha]

On Thu, Sep 20, 2018 at 6:18 PM Russ Allbery  wrote:
> Maybe exclude shared libraries linked with glib (and whatever the Qt
> equivalent is)?

One package that triggers this tag a lot is samba and it doesn't use glib or qt.

https://lintian.debian.org/maintainer/pkg-samba-ma...@lists.alioth.debian.org.html#samba

Thanks,
Jeremy Bicha

Bug#909267: library-not-linked-against-libc: downgrade from error

[Jeremy Bicha]

Source: lintian
Version: 2.5.103
X-Debbugs-CC: naes...@gmail.com, s...@debian.org

We noticed that library-not-linked-against-libc is triggered for
several GNOME packages. [1]

smcv had these comments
--
"I think that tag is too high-priority tbh. In frameworks like GLib
and Qt it's far from unusual to do everything with higher-level
functions and not use libc directly at all, and -Wl,--as-needed turns
that into no dependency.

In the parts of Debian that are not GNOME the tag triggers a lot less
often, because -Wl,--as-needed seems to be mostly a GNOME meme?

if someone is upset about that tag, I think it's fine to objdump -Tx
the offending object, say 'look, it has all the DT_NEEDED it needs'
and override the tag. Bonus penguin points if you write an autopkgtest
that dlopens it to prove that it's possible, I suppose."

-
So I'm requesting that the tag be downgraded from error. Please also
downgrade the description where it claims a library to not use libc is
only theoretical and not very likely.

[1] 
https://lintian.debian.org/maintainer/pkg-gnome-maintain...@lists.alioth.debian.org.html

Thanks,
Jeremy Bicha

Bug#908911: lintian: Allow dir-or-file-in-etc-opt to be overridable

[Jeremy Bicha]

Source: lintian
Version: 2.5.103
Affects: chrome-gnome-shell

chrome-gnome-shell ships a file in /etc/opt/ [1] so that it integrates
with Google Chrome. Google Chrome installs to /opt/ and uses /etc/opt/
for configuration. Although this stirred up a bit of controversy [2]
in Debian, it seems to me like this is acceptable for Debian. (Despite
chrome-gnome-shell's name, it also integrates with Firefox and
Chromium.)

I tried to set a lintian override but it looks like this tag is listed
as non-overridable in profiles/debian/ftp-master-auto-reject.profile

According to https://bugs.debian.org/840235 it is not actually a
ftp-master autoreject any more.

[1] https://lintian.debian.org/tags/dir-or-file-in-etc-opt.html
[2] https://bugs.debian.org/888549

Thanks,
Jeremy Bicha

Bug#907734: package-contains-documentation-outside-usr-share-doc false positive

[Jeremy Bicha]

On Mon, Sep 10, 2018 at 5:17 AM Chris Lamb  wrote:
> > What about cross-gcc-dev, equivs, jekyll, and the fwupd and grub
> > signed templates?
>
> Those are covered in Git already, no?

Oh, I don't read perl regex very well. :)

Jeremy

Bug#907734: package-contains-documentation-outside-usr-share-doc false positive

[Jeremy Bicha]

On Mon, Sep 10, 2018 at 4:53 AM Chris Lamb  wrote:
> > I think there are some examples where "template" would be needed to
> > avoid false positives.
> >
> > https://lintian.debian.org/tags/package-contains-documentation-outside-usr-share-doc.html
>
> Looks like we are only currently (ie. in Git) missing ones ending
> in .d. I have added these here:

What about cross-gcc-dev, equivs, jekyll, and the fwupd and grub
signed templates?

Jeremy

Bug#907734: package-contains-documentation-outside-usr-share-doc false positive

[Jeremy Bicha]

On Mon, Sep 10, 2018 at 4:22 AM Chris Lamb  wrote:
> I made it somewhat more generic; I don' think it should match
> "templates" anywhere, at least for the time being. Applied in Git (with
> test), pending upload:

I think there are some examples where "template" would be needed to
avoid false positives.

https://lintian.debian.org/tags/package-contains-documentation-outside-usr-share-doc.html

Thanks,
Jeremy

Bug#908442: lintian: package-contains-documentation-outside-usr-share-doc still false positives

[Jeremy Bicha]

Package: lintian
Version: 2.5.101
Severity: minor
X-Debbugs-CC: r...@debian.org

This is a follow-up from https://bugs.debian.org/907734
https://salsa.debian.org/lintian/lintian/commit/f6941026e6c0

Please make the template check more generic. I suggest looking for the
string "template" anywhere in the path name instead of just
"/templates/".

My specific test case is:
I: gnome-builder: package-contains-documentation-outside-usr-share-doc
usr/share/gnome-builder/plugins/autotools_templates/resources/CONTRIBUTING.md
I: gnome-builder: package-contains-documentation-outside-usr-share-doc
usr/share/gnome-builder/plugins/autotools_templates/resources/README.md

Thanks,
Jeremy Bicha

Bug#897213: lintian: Please remove dependency-on-python-version-marked-for-end-of-life until after Buster releases

[Jeremy Bicha]

> Just out of interest, do you have any concrete examples?

See https://bugs.debian.org/894560 which was clearly wrong because it
still had lots of rdepends for the py2 library.

For a recent example of where several py2 libraries were dropped with
apparently almost no complaints, see the python-xstatic* packages from
https://qa.debian.org/developer.php?email=openstack-devel%40lists.alioth.debian.org

Personally, I don't have a problem with unused Python2 libraries being
dropped now (the debian-devel conversations don't have full consensus
either way). The pygame example is relatively rare and easily fixed.

Thanks,
Jeremy Bicha

Bug#895674: lintian: maybe-not-arch-all-binnmuable emitted for (= ${source:Version})

[Jeremy Bicha]

On Sat, Apr 14, 2018 at 5:49 PM, Chris Lamb <la...@debian.org> wrote:
> I don't see how any of these (*) are useful to some wishing to
> uncover hidden problems with their packages.

I guess I'd want to know if the source format were not 3.0 (quilt) but
that's a rare enough issue that it's probably not worth the noise.
I'll go ahead and turn off classification on my system.

Thanks,
Jeremy Bicha

Bug#895674: lintian: maybe-not-arch-all-binnmuable emitted for (= ${source:Version})

[Jeremy Bicha]

On Sat, Apr 14, 2018 at 3:32 PM, Chris Lamb <la...@debian.org> wrote:
>   
> https://salsa.debian.org/lintian/lintian/commit/800b1344880b70995c5a26754d2a891ae0ef7d5d
>
> … in particular:
>
>  At this time, please do not attempt to "fix" the problem.  It
>  is not clear what the solution is (if any at all).  Nor is it clear
>  that this is something that will be supported.

Note that that text was *removed* from the tag description in that commit (!!).

> So, alas, changes may even be incorrect (!). I am unsure, hence
> tagging as moreinfo for the time being.
>
> (As an aside, how come you show classification checks? Surely they
> are far too noisy/useless..? I also wonder if this should be an
> X "experimental" tag instead as that would have been less strange.)

I thought some of the classification tags were useful. Do you have a
list of all the classification checks to help me reconsider? I don't
show experimental tags.

This particular tag is problematic because it encourages people who
see the tag to change the packaging so that the tag isn't emitted. ( I
have done that in several packages but will undo it as I touch the
packages again and notice.)

Thanks,
Jeremy Bicha

Bug#895674: lintian: maybe-not-arch-all-binnmuable emitted for (= ${source:Version})

[Jeremy Bicha]

Source: lintian
Version: 2.5.82

Test Case

When I build gnome-shell, lintian emits this:

C: gnome-shell source: maybe-not-arch-all-binnmuable gnome-shell ->
gnome-shell-common

But gnome-shell depends on
gnome-shell-common (= ${source:Version}),

I am told that is a correct dependency relationship despite some of
the confusing Lintian descriptions.

I have however been changing these to (>= ${source:Version}) which
makes the lintian output go away.

https://salsa.debian.org/gnome-team/gnome-shell

Thanks,
Jeremy Bicha

Bug#895574: lintian: binary-compiled-with-profiling-enabled test fails on Ubuntu's armhf

[Jeremy Bicha]

Source: lintian
Version: 2.5.81

Ubuntu runs its autopkgtests for all of its supported architectures.
One of lintian's tests (binary-compiled-with-profiling-enabled) fails
when the autopkgtest is run on armhf.

armhf is a bit different than the other Ubuntu architectures because
it uses a different kind of virtualization (sorry I don't remember the
details); not sure if that's relevant here or not.

You can see the test failures at
http://autopkgtest.ubuntu.com/packages/l/lintian/bionic/armhf

I'm letting you know that this issue prevents Ubuntu from being able
to automatically sync lintian, but instead we need to maintain a
manual diff. See http://ubuntudiff.debian.net/?query=-FPackage+lintian

Thanks,
Jeremy Bicha

Bug#889814: lintian: Improve long description of epoch-change-without-comment

[Jeremy Bicha]

To help reduce the need to use an epoch later, I think we should
recommend packages with date-based numbering use a version number
prefixed with something like 0~. For instance, the current version of
fonts-noto-color-emoji in Debian is 0~20180102-1. This could possibly
be a Lintian warning if a date-based format is detected for a new
Debian package.

Some packages can avoid the use of an epoch by using an epoch only for
the specific packages that need an epoch by manipulating
dh_gencontrol. For instance, this is done in fonts-ubuntu to use
epochs only for the transitional packages (which we'll be able to drop
in a few months).

https://salsa.debian.org/fonts-team/fonts-ubuntu/blob/debian/unstable/debian/rules

This trick is probably only useful when a package changes names (like
gcompris will probably become a transitional package depending on
gcompris-qt soon and only the gcompris package needs the epoch).

Thanks,
Jeremy Bicha

Bug#885974: lintian: warn about non-git Vcs fields

[Jeremy Bicha]

On Mon, Jan 1, 2018 at 1:49 AM, Russ Allbery <r...@debian.org> wrote:
> I would hold off on complaining about anonscm.  I'm pretty sure someone
> will find a way to keep it going and redirecting, similar to the intention
> with the mailing lists.

Should we warn now about any non-git vcs hosted at Debian?

Because even if there are redirects, it would be a bit wrong to have
Vcs-Svn actually point to a git repo…

> (I host most of mine on my own infrastructure), and if someone wants to
> use Bzr or Subversion, I'm not sure that Lintian nagging them is going to
> change their mind.

What about QA packages? Maybe those at least should be using git
hosted with Debian.

Thanks,
Jeremy Bicha

Bug#885974: lintian: warn about non-git Vcs fields

[Jeremy Bicha]

Source: lintian
Version: 2.5.66

I think it's time for Lintian to warn about Vcs fields other than Git.

It looks like this was mentioned at https://bugs.debian.org/884503 but
no separate bug was filed for it. That bug points to
https://lists.debian.org/debian-devel/2015/12/msg00383.html . I think
the impression there was that it wasn't important enough to add to
lintian then.

An important difference now is that the Debian project plans to stop
offering any active VCS hosting except for git soon.

Here's some wording suggestions. Feel free to modify.

Modify vcs-field-bitrotted (warning)
Any *.debian.org repo except salsa.debian.org

All version control system hosting provided by Debian is expected to
become read-only on 1 May 2018 except for git hosting at
https://salsa.debian.org/ . For more information, see
https://wiki.debian.org/Salsa .

Add vcs-field-other-than-git (warning or info)

After 1 May 2018, Debian will not offer any version control system
hosting other than git. While maintainers are free to use other
version control systems hosted elsewhere, most potential contributors
are familiar with git.

Thanks,
Jeremy Bicha

Bug#885106: lintian: Please update dh_commands for scour 0.36

[Jeremy Bicha]

Package: lintian
Version: 2.5.65

Please update data/debhelper/dh_commands since dh_scour is now
provided by python3-scour only as of scour 0.36-1 published today.

This fixes this wrong lintian error:
missing-build-dependency-for-dh-addon scour => python-scour

Thanks,
Jeremy Bicha

Bug#884870: lintian: vcs-field-has-unexpected-spaces and vcswatch don't agree

[Jeremy Bicha]

Source: lintian
Version: 2.5.65

I changed webkit2gtk's Vcs-Git field from
Vcs-Git: https://anonscm.debian.org/git/pkg-webkit/webkit.git

to
Vcs-Git: https://anonscm.debian.org/git/pkg-webkit/webkit.git -b wk2/unstable

in order to satisfy
https://qa.debian.org/cgi-bin/vcswatch?package=webkit2gtk

which complained that it couldn't find the current debian/changelog in
HEAD. (Maybe it's time to change HEAD, but this bug is also a problem
for experimental and Stable Update branches.)

Now, I think (lintian's website is recovering from a typo) that this
now causes lintian to emit vcs-field-has-unexpected-spaces

I think the " -b BRANCHNAME" suffix should be considered valid syntax
for Vcs-Git.

Thanks,
Jeremy Bicha

Bug#880115: lintian: Please add bionic as known Ubuntu distribution

[Jeremy Bicha]

Source: lintian
Version: 2.5.57

Something like this but for bionic (future Ubuntu 18.04 LTS)
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=3053db3

Thanks,
Jeremy Bicha

Bug#873520: lintian: Check for bad-distribution in debian/changelog too

[Jeremy Bicha]

On Tue, Oct 17, 2017 at 7:23 PM, Chris Lamb <la...@debian.org> wrote:
> However, unless I'm missing something this would mean that every
> time you built a package locally as part of regular development it
> would emit this tag.

I don't see that as a problem, but I really don't like seeing packages
with UNRELEASED changelogs in Debian.

Thanks,
Jeremy Bicha

Bug#873520: lintian: Check for bad-distribution in debian/changelog too

[Jeremy Bicha]

Source: lintian
Version: 2.5.52

I was surprised to see that pyjunitxml 0.6-1.2 was accepted into
Debian unstable with its debian/changelog still set to UNRELEASED. I
guess the uploader managed to generate a valid .changes file.

https://tracker.debian.org/news/859782

lintian already has a check for bad-distribution-in-changes-file

I request that a bad-distribution-in-debian-changelog check be added.

I think this would make a good candidate for dak auto-reject too.

Thanks,
Jeremy Bicha

Bug#829047: lintian: javalib-but-no-public-jars for transitional packages

[Jeremy Bicha]

On Sun, Jul 31, 2016 at 11:03 AM, Niels Thykier  wrote:
> I fear you may have a bug in your package.  A transitional package
> should use "transitional package" and not "transitional dummy package"
> in their description.

Maybe you missed this commit?

https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=6c531ba

The short description does include "transitional package". I like the
idea of getting rid of the unnecessary "dummy" so perhaps that could
be an additional lintian check?

We'd also need to update https://wiki.debian.org/Renaming_a_Package

Jeremy

Bug#693918: lintian: Add test for missing keywords

[Jeremy Bicha]

Package: lintian
Version: 2.5.10.2
Severity: wishlist

Keywords is a relatively new addition to the desktop entry spec that
improves the ability to find apps by typing in related words. GNOME
Shell, Unity, and Software Center currently support Keywords. Also,
GNOME Shell 3.6 no longer uses the Comment field for searching so
the discoverability since GNOME 3.4 will likely regress a bit until
developers add keywords to their .desktop files.

I'd like to see a lintian test that reports when a package includes a
.desktop without Keywords (except for .desktop files that have
NoDisplay=true; set). GNOME developers will probably take care of
adding keywords for GNOME 3.8 core apps but this should help increase
developer awareness for other apps.

https://live.gnome.org/GnomeGoals/DesktopFileKeywords
http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
https://mail.gnome.org/archives/desktop-devel-list/2012-November/msg00066.html

Jeremy

- -- System Information:
Debian Release: wheezy/sid
  APT prefers raring-updates
  APT policy: (500, 'raring-updates'), (500, 'raring-security'), (500,
'raring'), (100, 'raring-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386


-- 
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/CAAajCMY=jtqbr_ucm1rs5jqda4tzesyhrukcyrv9mqq7uhe...@mail.gmail.com