On Tue, Jan 22, 2019 at 5:41 PM Adam Borowski <kilob...@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 > > <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. > > 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
