[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

In any case, a script needs to declare a hashbang with an explicit
interpreter -- even though shells can execute a script without such a
hashbang, relying on this is not allowed in Debian as it'd be unreliable if
the user's shell is something weird.

I am changing contents of usr/bin/brightness-controller to  "python usr/share/brightness-controller/init.py"
init.py calls other python files in usr/share/brightness-controller/ui and usr/share/brightness-controller/util, so I want init.py
to be in usr/share/brightness-controller/ as well. Otherwise I will need to import them across directories which I want to avoid.
> I am not the main developer of the software (Amit Seal Ami
> <amitsealami@gmail.com> is), but am one of the major contributors. My
> name is included in the list of contributors under
> /usr/share/brightness-controller/about.py.

All copyright holders (ie, contributors with non-trivial parts) need to be
listed or at least referred to.

The name of the other contributors has been added. 
> Can I edit the package description (to remove license information,
> etc.) and release the next version? Would that work, or do I have to
> make another RFS for it?

Yeah, please do.  You're not supposed to bump the version number while doing
so (unless there's a really good reason), and neither you need another RFS.
You can update this one until an upload to the archive has actually happened.

> And, this is not compatible with Python 3 yet.

That's good for Buster but it'll need to be updated after.
I hope that we would be able to port to Python 3 before the support for Python 2 ends.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄⠀⠀⠀⠀ 
Archisman 

Reply to: