How To Install Templates In Kali

Instaloader

Instaloader is a Python iii application with a unmarried dependency (Python'due south requests). This makes it a relatively simple package, however not as straightforward as only packaging upwardly a beat out script would be. Because of the learning opportunities and simplicity, this makes it a good introduction parcel.

Instaloader Code Overview

The showtime thing we practice is look at the application's GitHub folio. A few things stand out which we accept a notation of:

What we notice here is some information that volition come in handy later:

The tool contains a setup.py script
It has a release
The license is MIT based

We'll be digging into each of these more later, for at present information technology is just information to know.

Setting Upward The Surroundings

We will assume that we have already followed our documentation on setting upwards a packing environment.

Permit'southward prepare our directories now for this bundle:

          [email protected]:~$ mkdir -p ~/kali/packages/instaloader/ ~/kali/upstream/ [email protected]:~$

Everything that relates to us building a package will be using ~/kali/. In there will exist two sub folders:

packages/ volition be a source code of the package we are going to create
upstream/ will be a compressed file of the source lawmaking of the application (ideally from a tag version release which nosotros saw before)

Downloading Tag Releases

Because we are making a new package from scratch, nosotros'll manually download the version of the tool we want to packet up. If we were updating a package (and it was packaged correctly), there is a process to aid speed it upwardly. Still, this will be covered in another guide.

Going to the GitHub's release page, we can run into the latest version (which at the time of writing is 4.four.iv). Here is the option to download instaloader-v4.4.iv-windows-standalone.zip, likewise as Source Code (zero), and Source Code (tar.gz). Nosotros are interested in the tar.gz choice.

Nosotros volition employ wget and make sure to format its name appropriately according to Debian's standards for source packages (take note of .orig.tar.gz):

          [email protected]:~$ wget https://github.com/instaloader/instaloader/archive/v4.iv.4.tar.gz -O ~/kali/upstream/instaloader_4.4.4.orig.tar.gz [e-mail protected]:~$

If at that place isn't a tag release for the software (or it hasn't had an release in some fourth dimension), we tin use the latest git commit. This is covered in another guide. However, it is preferred to use a tag release when bachelor.

Creating Package Source Code

We need to switch paths to the working location of the bundle:

          [e-mail protected]:~$ cd ~/kali/packages/instaloader/ [e-mail protected]:~/kali/packages/instaloader$

We are at present going to create a new blank git repository:

          [email protected]:~/kali/packages/instaloader$ git init Initialized empty Git repository in /abode/kali/kali/packages/instaloader/.git/ [email protected]:~/kali/packages/instaloader$

If we wanted to, we can confirm this past looking at "status" and "log":

          [email protected]:~/kali/packages/instaloader$ git condition On branch chief  No commits yet  null to commit (create/copy files and apply "git add" to track) [email protected]:~/kali/packages/instaloader$ [electronic mail protected]:~/kali/packages/instaloader$ git log fatal: your current co-operative 'principal' does not take any commits even so [email protected]:~/kali/packages/instaloader$

Corking. Everything is empty; we have a clean working area.

Nosotros can now import the upstream version into our packing source code by using the file downloaded from wget before. Because of the filename format, gbp is able to detect the values instaloader as the package name, and iv.four.4 as the version. We just press enter to accept the default values:

          [electronic mail protected]:~/kali/packages/instaloader$ gbp import-orig ~/kali/upstream/instaloader_4.4.4.orig.tar.gz What will be the source package proper name? [instaloader] What is the upstream version? [iv.iv.4] gbp:info: Importing '/home/kali/kali/upstream/instaloader_4.4.four.orig.tar.gz' to branch 'upstream'... gbp:info: Source package is instaloader gbp:info: Upstream version is 4.4.iv gbp:info: Successfully imported version 4.4.4 of /domicile/kali/kali/upstream/instaloader_4.4.iv.orig.tar.gz [email protected]:~/kali/packages/instaloader$

If we wanted to check everything is okay, in one case again, we can use git to exercise so:

          [email protected]:~/kali/packages/instaloader$ git status On co-operative chief nothing to commit, working tree clean [email protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ git log commit 494f71875f10f8d1da69a8edf2fc75300e4485b9 (HEAD -> master, tag: upstream/4.4.four, upstream) Author: Joseph O'Gorman <[email protected]>      New upstream version 4.iv.4 [email protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ git branch -5 * master       494f718 New upstream version 4.iv.4   pristine-tar 439fe30 pristine-tar information for instaloader_4.four.four.orig.tar.gz   upstream     494f718 New upstream version 4.4.4 [email protected]:~/kali/packages/instaloader$

Then there is now an automated commit created in the master branch (which is the electric current active co-operative, shown by the *), as well as two other branches:

pristine-tar which is metadata from the import
upstream which is the source code of the awarding, without whatever of our package modifications

We are creating a Kali parcel, and we don't apply the master branch, but rather kali/master. Then let's switch:

          [email protected]:~/kali/packages/instaloader$ git checkout -b kali/master Switched to a new branch 'kali/chief' [email protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ git co-operative -D master Deleted branch master (was 494f718). [email protected]:~/kali/packages/instaloader$ [electronic mail protected]:~/kali/packages/instaloader$ git co-operative -v * kali/chief  494f718 New upstream version 4.4.4   pristine-tar 439fe30 pristine-tar data for instaloader_4.4.four.orig.tar.gz   upstream     494f718 New upstream version 4.4.iv [email protected]:~/kali/packages/instaloader$

Now we tin can generate the necessary files required to build a Debain-based packet and likewise remove whatsoever example files created. During the procedure, we will be asked if its:

Unmarried binary
Curvation-Independent
Library
Python

We are going to keep information technology simple, and go with "Due southingle". And then accept what's on the screen with Y. If you would like more data about when to utilise what choice, please see the manpage for dh_make.:

          [electronic mail protected]:~/kali/packages/instaloader$ dh_make --file ~/kali/upstream/instaloader_4.iv.4.orig.tar.gz -p instaloader_4.4.four Type of packet: (single, indep, library, python) [southward/i/l/p]? Maintainer Name     : Joseph O'Gorman Email-Address       : [e-mail protected] Date                : Thu, 02 Jul 2020 17:59:47 -0400 Packet Name        : instaloader Version             : 4.4.4 License             : blank Package Type        : single Are the details right? [Y/north/q] Currently in that location is non top level Makefile. This may require additional tuning Washed. Delight edit the files in the debian/ subdirectory now. [email protected]:~/kali/packages/instaloader$ [electronic mail protected]:~/kali/packages/instaloader$ rm debian/*.docs debian/README* debian/*.ex debian/*.EX [email protected]:~/kali/packages/instaloader$

Nosotros use --file to say where the orig.tar.gz file is. If the file was one directory back (../), this would not be needed, however as we accept created a separate location for the file it is.

If you would similar to encounter what got generated when using dh_make, nosotros tin utilize git:

          [email protected]:~/kali/packages/instaloader$ git status On branch kali/master Untracked files:   (employ "git add <file>..." to include in what will exist committed)         debian/  nothing added to commit but untracked files nowadays (use "git add" to track) [email protected]:~/kali/packages/instaloader$ [e-mail protected]:~/kali/packages/instaloader$ ls -R debian/ debian/: changelog  control  copyright  rules  source  debian/source: format [email protected]:~/kali/packages/instaloader$

A quick overview of each of those files:

changelog - tracks when the parcel gets an update (including why and by who). This is responsible for the package version
command - is the metadata for the package (oftentimes seen with apt)
copyright - what is under what license. The bundle can be nether something different to the work we have put in to create the packet
rules - how to install the package
source/format - is the source parcel format

At this point, we take the base packaging files in place, and information technology feels like a good idea to commit before starting some real work:

          [email protected]:~/kali/packages/instaloader$ git add debian/ [email protected]:~/kali/packages/instaloader$ [e-mail protected]:~/kali/packages/instaloader$ git commit -m "Initial packaging files" [kali/master 52042da] Initial packaging files  5 files changed, 93 insertions(+)  create mode 100644 debian/changelog  create fashion 100644 debian/command  create fashion 100644 debian/copyright  create mode 100755 debian/rules  create style 100644 debian/source/format [email protected]:~/kali/packages/instaloader$

We now need to edit most of these to make certain the information is accurate. We tin use what we plant on GitHub to supply the correct info into the debian/ files:

License
Dependencies
Maintainers
Description

Collecting Information

License/Maintainers

For this bundle, its direct forrard. GitHub has given us a helping hand, and detected the license equally MIT. Nosotros can also see there is a license file:

          [electronic mail protected]:~/kali/packages/instaloader$ cat LICENSE The MIT License (MIT)  Copyright (c) 2016-2019 Alexander Graf and André Koch-Kramer. ... [email protected]:~/kali/packages/instaloader$

Reading the license, we can see in that location are two authors which are given credit also: Alexander Graf and André Koch-Kramer. However, we don't accept a method of contact for them. We continue to explore the rest of the git repository, looking for something which may give us more than authors so nosotros can requite credit to them. There isn't a fixed structure in place, however in that location are some things to check and await out for:

README* - authors may put contact data here
- A few examples could be: README, README.txt, README.Physician README.MKDOCS, or Readme.txt
AUTHOR* - They may have a dedicated file for author information
CREDIT* - They may have a dedicated file to who they requite credit to
LICENSE* - Similar mentioned above, the license file may give author information
docs/ - They may identify all their documentation in a separate binder
The "master" starting point of the application may have comments at the top of the file - in this, instaloader.py
Git commits - git --no-pager log -s --format="%ae" | sort -u

For our package, we can see:

          [email protected]:~/kali/packages/instaloader$ ls AUTHORS.dr.  debian  deploy  docs  instaloader  instaloader.py  LICENSE  Pipfile  Pipfile.lock  README.rst  setup.py  exam [electronic mail protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ ls docs/ as-module.rst    codesnippets      contributing.rst  installation.rst  logo.svg   requirements.txt             _templates basic-usage.rst  codesnippets.rst  favicon.ico       logo_heading.png  Makefile   sphinx_autodoc_typehints.py  troubleshooting.rst cli-options.rst  conf.py           alphabetize.rst         logo.png          README.md  _static [email protected]:~/kali/packages/instaloader$

As it turns out, there is: AUTHORS.md, docs/, instaloader.py, and README.rst, so nosotros take a few places to look at. Starting with AUTHORS.doctor, we can come across the authors proper noun and their method of contact:

          [electronic mail protected]:~/kali/packages/instaloader$ cat AUTHORS.md Authors =======  Instaloader is written by  - Alexander Graf (@aandergr) - André Koch-Kramer (@Thammus) - Lars Lindqvist (@e5150) [email protected]:~/kali/packages/instaloader$

So rather than an email accost, it appears to be a username (could exist only for GitHub, or a generic Net handle). This is plenty for us to become frontward (even though its not ideal).

Another trick we could try is looking to run into if they used a "legit" e-mail address with git:

          [email protected]:~/kali/packages/instaloader$ git clone https://github.com/instaloader/instaloader/ /tmp/instaloader [electronic mail protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ cd /tmp/instaloader/ [email protected]:/tmp/instaloader$ git --no-pager log -s --format="%ae" | sort -u | grep -5 '@users.noreply.github.com' ... [e-mail protected]:/tmp/instaloader$ [email protected]:/tmp/instaloader$ cd ~/kali/packages/instaloader/ [email protected]:~/kali/packages/instaloader$

Information technology doesn't appear and then. Was worth a try!

Dependencies/Maintainers

We need to see what is required to be installed on the machine in lodge for the application to work. Either pre-installed or will be installed using the application.

Some starting places to look at for this information:

README*
SETUP*
INSTALL*
docs/

There is a README for this awarding, only information technology just says how to install the application, rather than how to build it/compile from source:

          [email protected]:~/kali/packages/instaloader$ grep -C three -i install README.rst  ::      $ pip3 install instaloader      $ instaloader profile [profile ...]  [email protected]:~/kali/packages/instaloader$

Exploring the pip pick is something we could practice, simply out of scope for this guide.

Side by side we spot setup.py, which contains a lot of useful information:

          [email protected]:~/kali/packages/instaloader$ cat setup.py #!/usr/bin/env python3 ... if sys.version_info < (iii, 5):     sys.exit('Instaloader requires Python >= 3.five.')  requirements = ['requests>=two.4']  if platform.system() == 'Windows' and sys.version_info < (3, 6):     requirements.append('win_unicode_console') ...     url='https://instaloader.github.io/',     license='MIT',     author='Alexander Graf, André Koch-Kramer',     author_email='[email protected], [electronic mail protected]',     description='Download pictures (or videos) along with their captions and other metadata '                 'from Instagram.',     long_description=open(os.path.join(SRC, 'README.rst')).read(),     install_requires=requirements,     python_requires='>=3.5', ... [email protected]:~/kali/packages/instaloader$

We managed to get the following information from this:

From the shebang, we can see its Python 3 (#!/usr/bin/env python3).
We can see it wants Python 3.five or higher
Nosotros tin can see information technology wants requests and for information technology to be v2.four or higher
We tin can see if its on Windows, it requires another dependency, but nosotros are Linux, and then not the instance
We can encounter the program's dwelling URL
We can run into the license (MIT)
We can see the authors and their e-mail addresses
We can become a clarification of the program

Handy!

When packing, we are building a standalone package, which needs to be able to install offline. Something else which needs to be kept in mind, other systems package management systems, such as Python'southward pip, or ruby'due south gems. Whatsoever of these dependencies also need to exist in the main OS bundle management. In our case, nosotros demand Python'southward requests.

We have two ways of searching for it. We can use either:

pkg.kali.org
apt-enshroud

But we also need to know what we are searching for. In that location is a naming convention, but if you lot are united nations-sure, doing multiple searches may help:

requests
python-requests
python3-requests

We will stick with the control line option for the time being.

Doing just requests gives a little besides many results:

          [email protected]:~/kali/packages/instaloader$ apt-cache search requests | wc -l 561 [email protected]:~/kali/packages/instaloader$

So we need to do better to shorten the list, by just searching the short version of the clarification (we will comprehend this more than afterward, simply its the visible function of the output):

          [email protected]:~/kali/packages/instaloader$ apt-cache search --names-only requests | wc -l nineteen [e-mail protected]:~/kali/packages/instaloader$ [e-mail protected]:~/kali/packages/instaloader$ apt-cache search --names-only python-requests python-requests-cache-doc - persistent cache for requests library (medico) python-requests-doctor - elegant and simple HTTP library for Python (Documentation) python-requests-mock-doc - mock out responses from the requests bundle - doc python-requests-oauthlib-doc - module providing OAuthlib auth back up for requests (Common Documentation) python-requests-toolbelt-medico - Utility belt for python3-requests (documentation) [email protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ apt-cache search --names-only python-requests | grep -vi 'physician' [email protected]:~/kali/packages/instaloader$

Afterward removing the documentation from the results, we don't get whatsoever results. So on with the adjacent search!:

          [e-mail protected]:~/kali/packages/instaloader$ apt-cache search --names-only python3-requests python3-requests - elegant and elementary HTTP library for Python3, built for human beings python3-requests-cache - persistent enshroud for requests library (Python 3) python3-requests-file - File transport adapter for Requests - Python 3.X python3-requests-futures - library for asynchronous HTTP requests (Python iii) python3-requests-kerberos - Kerberos/GSSAPI hallmark handler for python-requests - Python 3.x python3-requests-mock - mock out responses from the requests packet - Python 3.10 python3-requests-ntlm - Adds back up for NTLM authentication to the requests library python3-requests-oauthlib - module providing OAuthlib auth support for requests (Python 3) python3-requests-toolbelt - Utility chugalug for advanced users of python3-requests python3-requests-unixsocket - Use requests to talk HTTP via a UNIX domain socket - Python 3.ten python3-requestsexceptions - import exceptions from bundled packages in requests. - Python three.x [email protected]:~/kali/packages/instaloader$

The first outcome, python3-requests, looks exactly right! We can expect closer:

          [email protected]:~/kali/packages/instaloader$ apt-enshroud testify python3-requests Package: python3-requests Source: requests Version: 2.23.0+dfsg-ii ... [email protected]:~/kali/packages/instaloader$

And we can see its version is 2.23.0, which is higher than than 2.4, so nosotros don't need to update the package. This will be covered in another guide when required.

Maintainers

While doing the other parts, we accept discovered the authors and maintainers of the software, and then we don't need to practice anything extra for this.

Clarification

At that place are two descriptions that nosotros need to supply, a long clarification and a short description. When we expect at the GitHub page we tin run into an well-nigh section that nosotros can use for the curt description. For the long clarification, nosotros can use the description in the README.

Nosotros likewise have a value from the setup.py.

Editing Package Source Code

Now that nosotros take that data copied down, we can start to populate the files in the debian/ binder we created with dh_make.

More than information on the subject field can be constitute on the Debian documentation.

Changelog

If we followed the documentation on setting upward a packaging surround, the just values we volition need to alter would be distribution (from unstable to kali-dev), version (from 4.4.iv-1 to 4.four.iv-0kali1) and the log entry:

          [email protected]:~/kali/packages/instaloader$ cat debian/changelog instaloader (4.4.4-1) unstable; urgency=medium    * Initial release (Closes: #nnnn)  <nnnn is the problems number of your ITP>   -- Joseph O'Gorman <[email protected]>  Thu, 02 Jul 2020 17:59:47 -0400 [email protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ vim debian/changelog [email protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ cat debian/changelog instaloader (four.4.4-0kali1) kali-dev; urgency=medium    * Initial release   -- Joseph O'Gorman <[e-mail protected]>  Thu, 02 Jul 2020 17:59:47 -0400 [e-mail protected]:~/kali/packages/instaloader$

Control

This file is the metadata for the packet, and contains a lot of data.

More information on the bailiwick can exist plant on the Debian documentation.

Out of the box, it volition look a little like this:

          [email protected]:~/kali/packages/instaloader$ cat debian/command Source: instaloader Section: unknown Priority: optional Maintainer: Joseph O'Gorman <[e-mail protected]> Build-Depends: debhelper-compat (= 12) Standards-Version: 4.5.0 Homepage: <insert the upstream URL, if relevant> #Vcs-Browser: https://salsa.debian.org/debian/instaloader #Vcs-Git: https://salsa.debian.org/debian/instaloader.git  Packet: instaloader Compages: whatsoever Depends: ${shlibs:Depends}, ${misc:Depends} Description: <insert up to 60 chars description>  <insert long description, indented with spaces> [email protected]:~/kali/packages/instaloader$

So we can see a few things that demand updating:

Section - we set up this to be misc, or if nosotros know for sure it should exist another department based off of the sections in Debian testing nosotros can gear up information technology to that section
Maintainer - we switch to be the Kali team, rather than an private
Uploaders - this is the individual(s) who are responsible for packaging up the application
Build-Depends - what packages are required to BUILD the package
Homepage - where is the tool located on the Internet
Vcs-Browser - package source code to view online
Vcs-Git - package source lawmaking location
Compages - what machines can this work on
Depends - what other packages are required for this package to piece of work
Description - short and long description

Nearly of this we take now figured out from before, so it should make it easier to fill in. We went ahead and created a remote empty git repository on our GitLab business relationship. In our example, this is the end result:

          [e-mail protected]:~/kali/packages/instaloader$ vim debian/control [email protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ cat debian/control Source: instaloader Section: misc Priority: optional Maintainer: Kali Developers <[email protected]> Uploaders: Joseph O'Gorman <[electronic mail protected]> Build-Depends: debhelper-compat (= 12),                dh-python,                python3-all,                python3-requests,                python3-setuptools, Standards-Version: 4.v.0 Homepage: https://instaloader.github.io/ Vcs-Browser: https://gitlab.com/kalilinux/packages/instaloader Vcs-Git: https://gitlab.com/kalilinux/packages/instaloader.git  Parcel: instaloader Architecture: all Depends: ${python3:Depends},          ${misc:Depends},          python3-requests, Description: Download media along with their metadata from Instagram  Downloads public and private profiles, hashtags, user stories, feeds    and saved media  Downloads comments, geotags and captions of each post.  Automatically detects profile proper noun changes and renames the target    directory appropriately  Allows fine-grained customization of filters and where to store    downloaded media [email protected]:~/kali/packages/instaloader$

Annotation: The Build-Depends & Depends are indented with tabs (and cease with commas), but the Description is spaces.

In that location is a lot going on here, then lets point out a few things

Something to keep in heed with the formatting of the long descriptions, at most every 70 characters in (to the nearest whole word), we would put a new line, to help keep the formatting nether control.

Now onto the dependencies, of which we have: Build & Package. For the build-dependencies of Python 3 nosotros will accept to take four things:

debhelper-compat
dh-python
python3-all
python3-setuptools

In a separate guide there will be an explanation as to why these are included, all the same simply the start ii are going to be a staple of Python 3 packaging as the latter two are for more specific cases.

In our application, we have some other one, python3-requests, which we got from setup.py and that is a requirement from the application. Typically, if there was not a setup.py file, nosotros would not need to include python3-requests in our "Build-Depends". However, due to the setup.py file, we volition demand to include python3-requests in both the "Build-Depends" likewise as the package "Depends". This ensures these packages are always on the organisation when nosotros install our bundle (particularly handy when using "sbuild").

The debhelper-compat level determines how the package will be built. The higher the compat level, the newer the version. Newer versions have sure menial tasks done automatically, so this should non be lowered.

The package dependencies are relatively straightforward. We get rid of the ${shlibs:Depends} every bit we are packaging upwards a Python tool, and instead replace it with the python3 depends version ${python3:Depends}. We also ensure that python3-requests is included as the tool requires this. No other dependencies are needed by this tool, so we are washed.

The final thing we need to ensure nosotros alter is the compages from any to all, as this tool can exist installed on all architectures.

Copyright

Everything that gets created has an original author. They control what happens with it and information technology needs to be respected. We can call out this in the copyright file.

More data on the subject area can be found on the Debian documentation and here.

Below is the skeleton template output (with comments removed):

          [email protected]:~/kali/packages/instaloader$ grep -five '#' debian/copyright Format: https://www.debian.org/doctor/packaging-manuals/copyright-format/1.0/ Upstream-Name: instaloader Upstream-Contact: <preferred name and accost to reach the upstream project> Source: <url://example.com>  Files: * Copyright: <years> <put writer'due south name and email hither>            <years> <likewise for some other writer> License: <special license>  <Put the license of the package here indented past i infinite>  <This follows the format of Clarification: lines in control file>  .  <Including paragraphs>  Files: debian/* Copyright: 2020 Joseph O'Gorman <[e-mail protected]> License: GPL-2+  This parcel is free software; you tin can redistribute it and/or change  information technology under the terms of the GNU Full general Public License as published past  the Free Software Foundation; either version ii of the License, or  (at your option) whatsoever later on version.  .  This bundle is distributed in the hope that information technology will be useful,  but WITHOUT Whatever WARRANTY; without even the implied warranty of  MERCHANTABILITY or Fettle FOR A PARTICULAR PURPOSE.  See the  GNU Full general Public License for more details.  .  You should take received a copy of the GNU General Public License  along with this program. If not, see <https://world wide web.gnu.org/licenses/>  .  On Debian systems, the complete text of the GNU General  Public License version 2 tin be constitute in "/usr/share/common-licenses/GPL-2".  [email protected]:~/kali/packages/instaloader$

The original tool's author has buying on their work, and the work nosotros have put into creating the parcel belongs to united states. Subsequently updating information technology, information technology looks like the following:

          [email protected]:~/kali/packages/instaloader$ vim debian/copyright [e-mail protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ cat debian/copyright Format: https://world wide web.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: instaloader Source: https://github.com/instaloader/instaloader  Files: * Copyright: 2016-2020 Alexander Graf <[email protected]>            2016-2020 André Koch-Kramer <[email protected]> License: MIT  Files: debian/* Copyright: 2020 Joseph O'Gorman <[email protected]> License: MIT  License: MIT  The MIT License  Permission is hereby granted, gratuitous of charge, to any person obtaining a copy  of this software and associated documentation files (the "Software"), to bargain  in the Software without restriction, including without limitation the rights to  apply, re-create, modify, merge, publish, distribute, sublicense, and/or sell copies  of the Software, and to permit persons to whom the Software is furnished to do  so, subject to the following weather condition:  .  The above copyright notice and this permission observe shall be included in all  copies or substantial portions of the Software.  .  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, Express OR  Implied, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO Event SHALL THE  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR Whatever CLAIM, Amercement OR OTHER  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE  SOFTWARE.  [e-mail protected]:~/kali/packages/instaloader$

Nosotros altered the following:

We removed an optional parameter (Upstream-Contact), as that is touched on in the copyright file.
We put in the homepage of the awarding to Source
Put the ii authors name and addresses from setup.py. The dates came from the LICENSE file
Rather than putting the whole block of MIT license text directly after, we placed it towards the end of the file, and gave a header to information technology.
We replaced the GPL-2+ used as default for the packaging department with the same MIT license, which is used in the application. This is the standard for Debian packages (packaging work should match the application'due south license).

Rules

This file is a Makefile, for building the Debian package.

More data on the subject can be establish on the Debian documentation.

The output of the template looks like the following:

          [email protected]:~/kali/packages/instaloader$ true cat debian/rules #!/usr/bin/brand -f # See debhelper(7) (uncomment to enable) # output every command that modifies files on the build system. #export DH_VERBOSE = 1   # encounter Characteristic AREAS in dpkg-buildflags(i) #export DEB_BUILD_MAINT_OPTIONS = hardening=+all  # see ENVIRONMENT in dpkg-buildflags(1) # package maintainers to suspend CFLAGS #export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic # package maintainers to suspend LDFLAGS #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--every bit-needed   %:   dh [email protected]   # dh_make generated override targets # This is example for Cmake (See https://bugs.debian.org/641051 ) #override_dh_auto_configure: # dh_auto_configure -- #  -DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH)  [email protected]:~/kali/packages/instaloader$

And so there are a lot of items which are pre-commented out, that may be handy for debugging & troubleshooting. Other than the shebang (#!/usr/bin/brand -f), there is only two other lines which are currently in use:

          %:   dh [email protected]

Which is a wildcard (%), and feed in all the arguments into dh.

What needs to go here now starts to depend on the programme and how complex information technology is. As our program is a python awarding nosotros are going to have to tell information technology to build with python3. We also demand to tell it to use pybuild to build, equally we have a setup.py file included in the source of the application. If there was not a setup.py file, we would not add this flag. We also need to tell PyBuild the name of the application. This looks like:

          [email protected]:~/kali/packages/instaloader$ vim debian/rules [e-mail protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ cat debian/rules #!/usr/bin/make -f  #export DH_VERBOSE = 1 export PYBUILD_NAME=instaloader  %:         dh [electronic mail protected] --with python3 --buildsystem=pybuild [email protected]:~/kali/packages/instaloader$

NOTE: It uses TAB for indentation, as its a Makefile.

Watch

An additional file which we highly recommend to include is a watch file. This points to upstream, and is then used to detect if there is a more than recent version of the application than what is packaged. This is useful when doing updates to packages.

For more information, and example formats, please run across the Debian wiki. Using this wiki, we can encounter in that location is an example for GitHub which is where our project is stored - github.com/instaloader/instaloader/:

          version=4 opts=filenamemangle=due south/.+\/v?(\d\S+)\.tar\.gz/<project>-$ane\.tar\.gz/ \   https://github.com/<user>/<project>/tags .*/v?(\d\Due south+)\.tar\.gz

So lets now modify it to fit our needs:

          [e-mail protected]:~/kali/packages/instaloader$ vim debian/watch [e-mail protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ cat debian/watch version=4 opts=filenamemangle=s/.+\/5?(\d\S+)\.tar\.gz/instaloader-$1\.tar\.gz/ \   https://github.com/instaloader/instaloader/tags .*/v?(\d\S+)\.tar\.gz [electronic mail protected]:~/kali/packages/instaloader$

NOTE: This has two spaces for any indentation

So allow'south exercise a quick check to see if its working right:

          [electronic mail protected]:~/kali/packages/instaloader$ uscan -vv --no-download ... uscan info: Plant the following matching hrefs on the web folio (newest first):    /instaloader/instaloader/archive/v4.4.4rc3.tar.gz (iv.4.4rc3) index=4.4.4rc3-i    /instaloader/instaloader/annal/v4.iv.4rc2.tar.gz (4.4.4rc2) index=four.4.4rc2-1    /instaloader/instaloader/annal/v4.4.4rc1.tar.gz (4.4.4rc1) index=4.4.4rc1-i    /instaloader/instaloader/archive/v4.four.4.tar.gz (four.4.four) index=4.4.iv-1    /instaloader/instaloader/archive/v4.4.3.tar.gz (4.4.iii) index=4.4.3-1 ...     $newversion  = 4.iv.4rc3     $lastversion = four.four.4 ... uscan: Newest version of instaloader on remote site is iv.4.4rc3, local version is iv.four.4 uscan:    => Newer package available from       https://github.com/instaloader/instaloader/annal/v4.4.4rc3.tar.gz uscan info: Scan finished [email protected]:~/kali/packages/instaloader$

Looks like its not! Its correctly detected all the versions, only its not sorted the club correctly (due to the release candidate). Nosotros know this past going to the release page:

Looking back at the Debian wiki, there is a department chosen Common mistakes:

Non mangling upstream versions that are alphas, betas or release candidates to make them sort before the final release. The solution is to use "uversionmangle" like this:

          opts=uversionmangle=south/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\d*)$/$one~$2/

However, we need to edit information technology a bit to fit Instaloader. This tin be figured out through trial and error using the in a higher place uversionmangle as the base.

Let's run across how information technology works:

          [email protected]:~/kali/packages/instaloader$ vim debian/lookout man [email protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ cat debian/watch version=4 opts=uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|blastoff|a)\d*)$// \   https://github.com/instaloader/instaloader/tags .*/v?(\d\S+)\.tar\.gz [e-mail protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ uscan -vv --no-download ... uscan info: Newest version of instaloader on remote site is 4.4.4, local version is 4.4.4 uscan info:    => Package is upward to engagement for from       https://github.com/instaloader/instaloader/annal/v4.4.4.tar.gz uscan info: Scan finished [electronic mail protected]:~/kali/packages/instaloader$

Success!

.Install & Helper-Scripts

Everything nosotros accept washed so far would just exist for edifice the packet, but nosotros haven't said how to install the awarding.

          [email protected]:~/kali/packages/instaloader$ vim debian/instaloader.install [electronic mail protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ true cat debian/instaloader.install instaloader.py usr/share/instaloader/ instaloader usr/share/instaloader/ [email protected]:~/kali/packages/instaloader$

NOTE: In that location is no leading slash in the target directory

We can become forward with this, but it may not behave like nosotros were expecting. This is because we don't have anything in $PATH, and so if we went to the control line and tried typing in instaloader.py its not going to piece of work (also information technology has the file extension, .py). The solution is to create a helper-script, which is placed into $PATH (and we include in the .install file):

          [email protected]:~/kali/packages/instaloader$ mkdir -p debian/helper-script/ [email protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ vim debian/helper-script/instaloader [email protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ cat debian/helper-script/instaloader #!/bin/sh exec python3 /usr/share/instaloader/instaloader.py "[electronic mail protected]" [email protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ vim debian/instaloader.install [electronic mail protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ cat debian/instaloader.install instaloader.py usr/share/instaloader/ instaloader usr/share/instaloader/ debian/helper-script/instaloader usr/bin/ [electronic mail protected]:~/kali/packages/instaloader$

With that, all the necessary debian/ files are added. Fourth dimension to build!

Packing Upwards

Time to bundle everything into a file. We are going to use sbuild to create the package. This has its pros and cons. One of the pros is that if it builds hither, it will too build elsewhere every bit its meant for build daemons. The downwards side is, it volition require access to a network repository as it volition endeavour and handle detecting and installing any dependencies missing in the chroot, making it slower to build.

If you don't want to utilise sbuild, simply drop information technology from the arguments (east.chiliad. gbp buildpackage), However, you will exist required and then to install what's in debian/control in the Build-Depends section (due east..one thousand sudo apt install -y dh-python python3-all python3-setuptools python3-requests).

So lets give sbuild a endeavor:

          [email protected]:~/kali/packages/instaloader$ gbp buildpackage --git-builder=sbuild gbp:error: Can't determine packet type: Failed to read changelog: can't go HEAD:debian/changelog: fatal: path 'debian/changelog' exists on disk, but not in 'HEAD' [electronic mail protected]:~/kali/packages/instaloader$

Oops! Nosotros haven't committed our changes to git. Shame on the states.

If we wanted to, we could bypass this past doing gbp buildpackage --git-builder=sbuild --git-export=WC, which would let the states to exam out our values in debian/ before committing to it, rather than cluttering up the git history with various debugging/troubleshooting commits. Then when we have our parcel in a working state, nosotros can and then commit to git, and attempt again, like and so:

          [email protected]:~/kali/packages/instaloader$ git status On branch kali/master Untracked files:   (use "git add <file>..." to include in what will be committed)         debian/  nil added to commit but untracked files present (employ "git add" to track) [e-mail protected]:~/kali/packages/instaloader$ [electronic mail protected]:~/kali/packages/instaloader$ git add debian/ [e-mail protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ git commit -m "Initial release" [kali/master 10a9e96] Add debian/ files  8 files changed, 94 insertions(+)  create fashion 100644 debian/changelog  create mode 100644 debian/command  create mode 100644 debian/copyright  create mode 100755 debian/helper-script/instaloader  create mode 100644 debian/instaloader.install  create style 100755 debian/rules  create mode 100644 debian/source/format  create fashion 100644 debian/watch [e-mail protected]:~/kali/packages/instaloader$

Allow's try and build again:

Annotation: Y'all may not get the following error (as information technology depends on how "clean" your OS is):

          [email protected]:~/kali/packages/instaloader$ gbp buildpackage --git-builder=sbuild gbp:info: Exporting 'HEAD' to '/home/kali/kali/build-area/instaloader-tmp' gbp:info: Moving '/dwelling/kali/kali/build-area/instaloader-tmp' to '/home/kali/kali/build-area/instaloader-4.4.4' gbp:info: Performing the build dh clean --with python3 --buildsystem=pybuild dh: error: unable to load addon python3: Can't locate Debian/Debhelper/Sequence/python3.pm in @INC (you lot may demand to install the Debian::Debhelper::Sequence::python3 module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.xxx.3 /usr/local/share/perl/5.30.3 /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.xxx /usr/share/perl/5.30 /usr/local/lib/site_perl) at (eval 25) line 1. Brainstorm failed--compilation aborted at (eval 25) line ane. make: *** [debian/rules:vii: clean] Error 255 E: Failed to clean source directory /abode/kali/kali/build-area/instaloader-4.4.iv (/home/kali/kali/build-expanse/instaloader_4.four.four-0kali1.dsc) gbp:error: 'sbuild' failed: it exited with 1 [email protected]:~/kali/packages/instaloader$

If yous see the higher up error, this is because dh-python is missing from our Os. We can quickly fix this by doing:

          [electronic mail protected]:~/kali/packages/instaloader$ sudo apt install -y dh-python [email protected]:~/kali/packages/instaloader$

So, ane more try and building:

          [electronic mail protected]:~/kali/packages/instaloader$ gbp buildpackage --git-builder=sbuild gbp:info: Exporting 'Caput' to '/home/kali/kali/build-area/instaloader-tmp' gbp:info: Moving '/home/kali/kali/build-surface area/instaloader-tmp' to '/habitation/kali/kali/build-area/instaloader-4.4.4' gbp:info: Performing the build dh make clean --with python3 --buildsystem=pybuild ...  +------------------------------------------------------------------------------+ | Parcel contents                                                             | +------------------------------------------------------------------------------+  ...  Install lintian build dependencies (apt-based resolver) -------------------------------------------------------  ...  E: instaloader source: source-is-missing docs/_static/bootstrap-4.ane.3.bundle.min.js Due west: instaloader: binary-without-manpage usr/bin/instaloader I: instaloader source: testsuite-autopkgtest-missing  I: Lintian run was successful. ...  +------------------------------------------------------------------------------+ | Summary                                                                      | +------------------------------------------------------------------------------+  Build Compages: amd64 Build Type: full Build-Infinite: 2460 Build-Fourth dimension: 5 Distribution: kali-dev Host Architecture: amd64 Install-Time: 37 Job: /home/kali/kali/build-area/instaloader_4.4.four-0kali1.dsc Lintian: warn Auto Architecture: amd64 Package: instaloader Package-Fourth dimension: 45 Source-Version: 4.4.4-0kali1 Space: 2460 Status: successful Version: 4.4.four-0kali1 -------------------------------------------------------------------------------- Finished at 2020-07-03T15:51:09Z Build needed 00:00:45, 2460k disk infinite  [email protected]:~/kali/packages/instaloader$

The output here is very long, so we take truncated it, but we tin can see its being built successfully. Even with an fault, warning, and data from lintian!

Let's double check to see what got created:

          [e-mail protected]:~/kali/packages/instaloader$ ls ~/kali/build-surface area/instaloader* /home/kali/kali/build-area/instaloader_4.iv.4-0kali1_all.deb          /home/kali/kali/build-area/instaloader_4.4.4-0kali1.debian.tar.xz /dwelling/kali/kali/build-surface area/instaloader_4.4.4-0kali1_amd64.build      /home/kali/kali/build-area/instaloader_4.4.4-0kali1.dsc /home/kali/kali/build-area/instaloader_4.4.4-0kali1_amd64.buildinfo  /abode/kali/kali/build-area/instaloader_4.4.4.orig.tar.gz /home/kali/kali/build-area/instaloader_4.4.4-0kali1_amd64.changes [e-mail protected]:~/kali/packages/instaloader$

We have output!

Making Lintian Happy

For more information, run into Debian's documentation.

To fix this error E: instaloader source: source-is-missing docs/_static/bootstrap-four.ane.3.bundle.min.js, which will make sure the package is a higher standard, we tin can resolve this by expanding the minified JavaScript (Beautifier/Unminify) file and put it into a new directory in debian/ called missing-sources:

          [electronic mail protected]:~/kali/packages/instaloader$ apt-enshroud search beautifier js ... jsbeautifier - JavaScript unobfuscator and beautifier ... [e-mail protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ sudo apt install -y jsbeautifier [e-mail protected]:~/kali/packages/instaloader$ [e-mail protected]:~/kali/packages/instaloader$ mkdir -p debian/missing-sources/ [email protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ js-adorn docs/_static/bootstrap-4.i.3.bundle.min.js > debian/missing-sources/bootstrap-4.i.iii.packet.js [email protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ git add debian/missing-sources/ [email protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ git commit -m "Unminify JS to make lintian happy" [email protected]:~/kali/packages/instaloader$

We can now rebuild the package with the same control and see that it was successful with no error

          [email protected]:~/kali/packages/instaloader$ gbp buildpackage --git-builder=sbuild ...  +------------------------------------------------------------------------------+ | Bundle contents                                                             | +------------------------------------------------------------------------------+  ...  Install lintian build dependencies (apt-based resolver) -------------------------------------------------------  ...  Westward: instaloader: binary-without-manpage usr/bin/instaloader I: instaloader source: testsuite-autopkgtest-missing  I: Lintian run was successful. ... [email protected]:~/kali/packages/instaloader$

A way we can improve this package is to automate this stage by unminify the JavaScript file, but this will be covered in another guide.

Manual Install

Allow's now give our package a test drive:

          [email protected]:~/kali/packages/instaloader$ sudo apt install ~/kali/build-area/instaloader_4.4.4-0kali1_all.deb Selecting previously unselected package instaloader. (Reading database ... 154513 files and directories currently installed.) Preparing to unpack .../instaloader_4.4.4-0kali1_all.deb ... Unpacking instaloader (iv.4.4-0kali1) ... Setting upwards instaloader (iv.4.iv-0kali1) ... Processing triggers for kali-menu (2020.3.0) ... [email protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ instaloader usage: instaloader.py [--comments] [--geotags]                [--stories] [--highlights] [--tagged] [--igtv]                [--login YOUR-USERNAME] [--fast-update]                profile | "#hashtag" | %%location_id | :stories | :feed | :saved instaloader.py --help [e-mail protected]:~/kali/packages/instaloader$

Success!

This is looking good (non perfect), and eagle eye spotters may be able to spot why (in the output) - at that place is the file extension in the output (instaloader.py), even so the command used to call it doesn't take it (instaloader). We are going to need to either patch the application or notice a dissimilar way to phone call the awarding to address this. But this will be covered in another guide.

Allow's now brand sure everything is in git locally, before we push button it out to the remote repository (the i nosotros defined in debian/control):

          [email protected]:~/kali/packages/instaloader$ git condition On co-operative kali/master nothing to commit, working tree clean [email protected]:~/kali/packages/instaloader$ [e-mail protected]:~/kali/packages/instaloader$ git branch -five * kali/master  10a9e96 Unminify JS to make lintian happy   pristine-tar 439fe30 pristine-tar data for instaloader_4.4.four.orig.tar.gz   upstream     494f718 New upstream version iv.4.4 [email protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ git remote -v [electronic mail protected]:~/kali/packages/instaloader$

Nosotros don't (notwithstanding) have a remote repository setup, so we go to GitLab and create a new projection earlier continuing.

Afterwards:

          [electronic mail protected]:~/kali/packages/instaloader$ git remote add origin [electronic mail protected]:kalilinux/packages/instaloader.git [email protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ git remote -5 origin  [electronic mail protected]:kalilinux/packages/instaloader.git (fetch) origin  [e-mail protected]:kalilinux/packages/instaloader.git (push) [e-mail protected]:~/kali/packages/instaloader$

Now we need to send our local work to the new remote repository (and don't forget the tags):

          [email protected]:~/kali/packages/instaloader$ git button --all Enumerating objects: 95, done. Counting objects: 100% (95/95), done. Delta compression using up to ii threads Compressing objects: 100% (88/88), done. Writing objects: 100% (95/95), 291.sixteen KiB | 7.46 MiB/due south, done. Full 95 (delta 1), reused 0 (delta 0), pack-reused 0 remote: remote: To create a merge request for pristine-tar, visit: remote:   https://gitlab.com/kalilinux/packages/instaloader/-/merge_requests/new?merge_request%5Bsource_branch%5D=pristine-tar remote: remote: To create a merge request for upstream, visit: remote:   https://gitlab.com/kalilinux/packages/instaloader/-/merge_requests/new?merge_request%5Bsource_branch%5D=upstream remote: To gitlab.com:kalilinux/packages/instaloader.git  * [new branch]      kali/main -> kali/master  * [new branch]      pristine-tar -> pristine-tar  * [new branch]      upstream -> upstream [email protected]:~/kali/packages/instaloader$ [email protected]:~/kali/packages/instaloader$ git button --tags Enumerating objects: 1, washed. Counting objects: 100% (1/1), done. Writing objects: 100% (1/one), 172 bytes | 172.00 KiB/s, washed. Full one (delta 0), reused 0 (delta 0), pack-reused 0 To gitlab.com:kalilinux/packages/instaloader.git  * [new tag]         upstream/iv.4.4 -> upstream/iv.4.4 [email protected]:~/kali/packages/instaloader$

At this point at present, a ticket can be opened upwards on the Kali Linux bug tracker, with a suggestion of the tool & bundle which yous take created, and our tool team will handle it from in that location.