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. > 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 not the main developer of the software (Amit Seal Ami > <amitseal...@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. > 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. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄⠀⠀⠀⠀