First Debian package. #106
Conversation
|
Obtained a package for Ubuntu 18.04 with command line below. Get out of the docker run --rm -it -v $PWD:/up ubuntu:bionic bash -c 'set -euxv ; \
apt-get update ; apt-get install -y --no-install-recommends git \
build-essential devscripts debhelper fakeroot \
dh-python python3 python3-pip \
python3-setuptools python3-gi python3-xlib python3-dbus \
gir1.2-gtk-3.0 gir1.2-wnck-3.0 ; \
bash /up/quicktile/recompile_local_debian_package.sh'Packages get written into a |
|
Thanks. I'm a little uncomfortable blindly accepting something I know so little about, but I do plan to accept this. Could you link me to the resources that taught you to do this?
For 0.4.1 or 0.4.2, I was planning to switch from ePyDoc to Sphinx to get rid of the last (optional) dependency on Python 2 and enable major refactoring to use language constructs ePyDoc doesn't understand (mainly non-comment type annotations). At that point, I'll either have Sphinx generate a man page or add help2man as a build-time dependency. That said, a quick skim through what you're proposing to add doesn't show anything that's likely to need to change except the dependency on |
Sure. First, I have years of experience in working out things cleanly and simply when people are lost in a mess. It's part of my added value as an independent hands-on software consultant. I did if for a number of clients small and big. Debian packaging looks like a moving target where lot of efforts have been invested in many directions. I don't claim to know it well, just figured out a configuration picking the patterns observed in existing software, with reuse and simplicity in mind, tested until it works, and can be refined. The base spirit as I understand it is sound. Debian's goal is to allow to package a lot of programs with as few boilerplate as possible. With the years they included a lot of heuristics in the tools so that most package that follow a known pattern are easy to compile (autotools, cmake, python modules, etc). Also, tools help making sure every debian-specific changes are cleanly separated from the pristine upstream package. To avoid a mess, tools include many sanity checks, but since practices change a lot it's hard to find up-to-date and consistent information. Now, the references:
I got a list of relevant packages to look into, using the line below: apt-file find /etc/xdg/autostart/ | cut -f 1 -d : | while read a ; do apt-file list $a | egrep -i '([^o]py)' ; doneThose hinted me about the main rule in grep -rI buildsystem=pybuild */debian/rules
caffeine-2.9.4/debian/rules: dh $@ --with python3,bash-completion --buildsystem=pybuild
python-xlib-0.23/debian/rules: dh $@ --with python2,python3 --buildsystem=pybuild
quicktile-0.4.0gtk3/debian/rules: dh $@ --with python3 --buildsystem=pybuild
xcffib-0.8.1/debian/rules: dh $@ --with python2,python3 --buildsystem=pybuild
The
Good!
Thanks for the feedback. The first person that will benefit from the package is my 15-year old son. After superswitcher he'll have quicktile on his laptop. Thanks to you for doing the hard work. Maybe we should consider installing Anyway, thanks again. |
In other words, it's sort of like the time I asked my professor about researching back in university and got an answer that boiled down to "No, you're not missing anything and you've basically got it down. Our systems for sharing research with each other really are an appallingly inefficient mess that boils down to 'fight your way to knowing the correct jargon and then Google it'." Thanks for confirming that I'm not just missing something and giving me a more directed way to get started. I'll take a look at it as soon as I've gotten some more urgent stuff out of the way, so it may be a week or two.
That's another thing I've been meaning to get back to for a while. |
Now it gets philosophical. The world is just as it is. Wishing it was better can be helpful or not, depending on the context. If you can install a "on-off switch" on those kind of wishes, then suddenly you get better when those wishes were a handicap. Anyway, I have updated my branch to adjust the script that generates packages. These are still local packages, but at least they are gathered by distro, with a |
It's more that I was caught in the grips of "They're professionals. They do this all the time. It can't possibly be this un-optimized. I must be missing something." |
|
@fidergo-stephane-gourichon this is brillant, anyway you could upload the .deb file somewhere public? :) |
|
Thanks @kbsali for the feedback. Will try, tonight. @ssokolow what do you think of a "github action" that would generate packages? I can prepare one on my fork then share with you via a PR. |
|
@fidergo-stephane-gourichon thanks a lot! I managed to compile the deb file with your docker command (you are just missing a little space here |
|
Thanks @kbsali for reporting. Regarding fakeroot I corrected the comment above. Regarding mkdir and echo I adjusted the order. |
|
@fidergo-stephane-gourichon My main concern with a GitHub action is the risk that either I or people using it will grow too comfortable with it and it'll hold back the creation of a proper PPA. |
|
Firstly, thanks @ssokolow for this Christmas present! Thanks @fidergo-stephane-gourichon for the work to make it into a Debian package. I've found I need to manually install Other than that, it appears to be working for me under Ubuntu 18.04 Also @fidergo-stephane-gourichon if you build "artifacts" with a github action, then you're only a few steps away from making it a PPA. The generated debian files ( |
I had actually hoped to have it out in time for Christmas, but said New Years because I suspected (correctly) that I'd get bogged down with unexpected delays. |
|
Oh, it just occurred to me that you have |
Sounds like a great thing to automate once I finish reviving ITAD Importer (and possibly finishing whipping up Minimum Viable Products for certain helper utilties I need) and come back to this to write the functional test harness. At the moment, However, once that's done, my plan is to have the harness iterate through a bunch of different WMs and, if necessary, different desktop configurations, spinning up an Xvfb or Xephyr instance for each one and then performing QuickTile operations and checking for correct results. That should give me the confidence necessary to even offer Continuous Deployment to a PPA from HEAD if I so choose. |
|
Just created #107, another regression introduced by branch gtk3_port. |
|
With luck, I should have an 0.4.0 release candidate ready by the end of tomorrow that this can be rebased and merged onto. |
The "Maintainer" of a Debian package is the person who will be bugged with automated e-mails from the Debian project, (if this package ever goes as far). Hence not putting original author here. Ref https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
…er consider whether they should commit first.
cmd complaine, but at least this allows to build a package for older distros like Ubuntu 18.04.
|
Rebased on top of current Running locally works. Building package succeeds but fails to start: |
fidergo-stephane-gourichon
force-pushed
the
feature_debian_package
branch
from
34b5ae2
to
f63840f
Compare
|
That's usually a bug in setuptools that causes it to fail to plumb together the See if |
That does not complain. And this works: python3 -m quicktile --daemonizeIs a fix is to be done your side? |
|
I never understood why it happens in the first place. From my perspective, setuptools looks like a confusing, over-engineered mess for 99% of use-cases, but The advice I always gave was to Failing that, the generated #!/usr/bin/python3
# EASY-INSTALL-ENTRY-SCRIPT: 'QuickTile==0.4','console_scripts','quicktile'
__requires__ = 'QuickTile==0.4'
import re
import sys
from pkg_resources import load_entry_point
if __name__ == '__main__':
sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
sys.exit(
load_entry_point('QuickTile==0.4', 'console_scripts', 'quicktile')()
)...and replacing it with this should make it work: #!/usr/bin/python3
from quicktile.__main__ import main
main() |
|
Hhm, could not reproduce. The actual cause might be that I mistakenly installed the package for 18.04 instead of the 19.10 I'm using. Anyway, there were nothing related to quicktile in /usr because I tend to never to things like find /usr/ -iname "*quicktile*"
/usr/share/doc/quicktile
/usr/share/doc/quicktile/quicktile
/usr/share/applications/quicktile.desktop
/usr/lib/python3.6/dist-packages/QuickTile-0.4.egg-info
/usr/lib/python3.6/dist-packages/quicktile
/usr/bin/quicktile
# dpkg --purge quicktile
(Lecture de la base de données... 447762 fichiers et répertoires déjà installés.)
Suppression de quicktile (0.4.0gtk3-1) ...
Purge des fichiers de configuration de quicktile (0.4.0gtk3-1) ...
Traitement des actions différées (« triggers ») pour gnome-menus (3.32.0-1ubuntu1) ...
Traitement des actions différées (« triggers ») pour desktop-file-utils (0.24-1ubuntu1) ...
Traitement des actions différées (« triggers ») pour mime-support (3.63ubuntu1) ...
# find /usr/ -iname "*quicktile*"
(no output)Anyway, package work now. Ok to rebase this branch onto your merged master. |
|
|
|
There. Merged and tagged as the final commits of Next goal on this topic: Integrating it into the testing routine and Travis-CI builds to make sure it doesn't break. |
|
Hmm. I just noticed something from opening the generated It looks like it's mistaking source files for documentation and making copies to be installed to |
|
Indeed. This is the result of the content of |
|
Looks like the latest commit plus these hints go towards a correct way: pip3 install sphinx_autodoc_typehints sphinxcontrib.autoprogram
make html
sphinx-build -b html -d _build/doctrees . _build/html
Running Sphinx v2.4.0
loading translations [en]... done
making output directory... done
loading intersphinx inventory from https://pycairo.readthedocs.io/en/latest/objects.inv...
loading intersphinx inventory from https://dbus.freedesktop.org/doc/dbus-python/objects.inv...
loading intersphinx inventory from https://lazka.github.io/pgi-docs/Gtk-3.0/objects.inv...
loading intersphinx inventory from https://lazka.github.io/pgi-docs/Gdk-3.0/objects.inv...
loading intersphinx inventory from https://lazka.github.io/pgi-docs/GdkX11-3.0/objects.inv...
loading intersphinx inventory from https://lazka.github.io/pgi-docs/GLib-2.0/objects.inv...
loading intersphinx inventory from https://docs.python.org/3/objects.inv...
loading intersphinx inventory from https://www.sphinx-doc.org/en/master/objects.inv...
loading intersphinx inventory from https://lazka.github.io/pgi-docs/Wnck-3.0/objects.inv...
building [mo]: targets for 0 po files that are out of date
building [html]: targets for 22 source files that are out of date
updating environment: [new config] 22 added, 0 changed, 0 removed
reading sources... [100%] usage
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
preparing documents... WARNING: unsupported theme option 'badge_branch' given
WARNING: unsupported theme option 'canonical_url' given
done
writing output... [100%] usage
generating indices... genindex py-modindexdone
highlighting module code... [100%] test_quicktile
writing additional pages... searchdone
copying images... [100%] wrench.png
copying static files... ... done
copying extra files... done
dumping search index in English (code: en)... done
dumping object inventory... done
build succeeded, 2 warnings.
The HTML pages are in _build/html.
Build finished. The HTML pages are in _build/html. |
|
I'll need to look into Debian policy on what kind of docs are and aren't supposed to go into A quick look at some of the packages in my own |
|
Sphinx, sphinx_autodoc_typehints, and sphinxcontrib.autoprogram will also let you build and preview the beginnings of a manpage using (cd docs; make man)
man -l docs/_build/man/quicktile.1 |
|
I've pushed another commit towards including the correct doc. Package now includes html and man page! Here are some warning I noticed during docker build: |
You'll have to open a new PR. GitHub won't let me re-merge this one.
I have perfectionist tendencies. That's what happens when I get into my doc-writing. (I'm actually still not satisfied with parts of it.)
I think you might be running an older version of the Alabaster theme than I am. Both of those theme options are listed at https://alabaster.readthedocs.io/en/latest/customization.html and neither of those warnings appear in either my local build or the Travis-CI build which produces the live site. |
This goes a good way to fix #105.
Thank you for your attention.