Bug#920039: RFS: brightness-controller/2.2.3 [ITP]
On Tue, Jan 22, 2019 at 5:41 PM Adam Borowski <kilobyte@angband.pl> wrote:
> On Tue, Jan 22, 2019 at 04:57:20PM +0530, Archisman Panigrahi wrote:
> > I am not sure about the native package issue. Has it got something to
> > do with /debian/source/format? I did not exactly understand what is
> > the difference between native and quilt, so went for native. Any
> > suggestion is welcome.
>
> The "native" format is adequate only when there's no separate upstream (and
> often not even then); in this case you are packaging Amit's software that
> has proper releases, tarballs, and all proper trappings.
>
> The packaging is supposed to be composed of two pieces:
> * the upstream (.orig) tarball
> * a packaging tarball, that includes the debian/ dir and a (possibly empty)
> patch series
>
> This was somewhat different with the 1.0 format, but you don't want it --
> even if you (like me) despite quilt, the "3.0 (quilt)" format with a single
> patch is strictly better than 1.0.
I am now using 3.0 (quilt). I have uploaded a new release (under the same
version number), please check.
There is some lintian error
"debian-changelog-version-requires-debian-revision". Is it due to the fact
that the debian/changelog in .orig.tar.gz
says it was released for bionic (Ubuntu 18.04) while I changed it to
unstable while packaging?
I am not sure why this error appeared.
>
>
> No such executable file is needed to run this software. The
> > /usr/bin/brightness/controller calls the file
> > /usr/share/brightness-controller/init.py (which has been marked
> > executible with chmod +x), which can calls python to run itself.
>
> Yeah, but you're supposed to install the executable into /usr/bin. What
> your current package does is a text file without the +x bit, that's not
> going to work. In some complex cases it might be reasonable to have a
> wrapper but here I don't see a reason to not install to /usr/bin directly
Reply to: