On Fri, Apr 18, 2014 at 03:02:30PM +0800, Paul Wise wrote:
> On Fri, Apr 18, 2014 at 2:55 PM, Gianfranco Costamagna wrote:
>
> > This is why I stopped caring about the js lintian error on sdlgfx,
> > put a lintian override on debian/souce symlink and I stop caring.
This is NOT what lintian overrides are for! Lintian tells you about
things that are wrong with the package. If you stop caring, that
doesn't make it any less wrong.
Overrides should only be used for cases where lintian is wrong (that is,
when your package is a false positive) and fixing it in lintian is not
reasonable.
Adding override tags just because that makes the package lintian-clean
is a way of hiding problems instead of solving them. We promise our
users that we don't do that.
> > Unless an ftpmaster clearly says what is acceptable and what isn't I
> > stop caring about this stuff, they accepted two new uploads with
> > embedded jquery, so if it is ok for them it is for me!
>
> AFAICT ftp-master position is clear:
>
> https://ftp-master.debian.org/REJECT-FAQ.html
From there:
> Not all QA issues will be noticed
In other words, just because they accept a package doesn't mean they
saw what you were doing and explicitly approved of it.
On Fri, Apr 18, 2014 at 12:18:36AM -0700, Vincent Cheng wrote:
> > Source missing: Your package contains files that need source but do
> > not have it. These include PDF and PS files in the documentation, or
> > auto-generated files. December 2008
>
> I find that the language isn't particularly clear about what to do
> e.g. when you have non-source files (in your source package) that
> aren't actually used (by anything shipped in your binary package).
In many cases, the license of a package requires source for all files,
which means Debian is not allowed to distribute this source package if
the sources to those generated files are not available as well.
In other cases, there isn't a license problem, but it seems reasonable
to me to just have a simple rule that "we distribute source for
everything we offer"; that's what we say in our Social Contract, too.
> It also doesn't touch upon what to do when you have both the source
> and the generated/compiled files/binaries built from that source in
> the same source tarball, and whether you should (or must) purge those
> generated files from your source tarball.
Legally this is never a problem. The source is there, so it's fine.
There's discussion about using such binaries. I think they should
always be rebuilt. This includes files like config.{sub,guess}. Not
everyone agrees with that, however.
> In other words, (from my perspective) there's still some leeway and
> some corner cases where ftpmaster policy isn't crystal clear, and
> hence we still have these recurring discussions on our mailing lists.
The only thing they aren't clear on, AFAICS, is how to handle
non-programmatic works. Things like manually modified PNGs that were
based on a rendering. We were discussing those on this list as well. I
had hoped for a more clear statement from ftpmaster, but didn't see it
(did I miss it? I thought they were going to make a statement about
it.)
> Policy 4.13 uses the keyword "should", not "must" (i.e. allowed and
> not RC-buggy, albeit discouraged). Yes, lintian's "embedded-library"
> tag is on ftpmasters' autoreject list, but maintainers can safely
> override that warning.
Same as above: overrides should not be used to hide actual bugs. Just
because a maintainer doesn't care about a bug doesn't make it any less
buggy.
On Fri, Apr 18, 2014 at 08:29:46AM +0100, Gianfranco Costamagna wrote:
> http://lintian.debian.org/tags/source-is-missing.html
> "Emitted (non-overridden): 6459, overridden: 142, total: 6601"
>
> So do you really want to repackage 6k packages because of this?
> (maybe not really 6k, but I'm sure at least 3k needs a repackage)
Yes, I think that would be a very good idea indeed. It would mean that
we can say with more confidence that we provide sources and it gives our
users the ability to reasonably edit the files.
On the other hand, I don't think this should be a priority. In the case
of Frets On Fire, unless there's a problem with the license, I would
remove the file and upload the change next time the package is uploaded
(unless that is not expected to happen any time soon).
Thanks,
Bas
Attachment:
signature.asc
Description: Digital signature