Bug#832585: RFS: gammaray/2.5.0-1 [RC] -- Tool for examining the internals of Qt application

[Tiago Ilieve]

Gianfranco,

On 27 July 2016 at 08:34, Gianfranco Costamagna
 wrote:
> Vcs-Git: https://anonscm.debian.org/pkg-kde/kde-extras/gammaray.git
> Vcs-Browser: 
> https://anonscm.debian.org/gitweb/?p=pkg-kde/kde-extras/gammaray.git
>
> they seem both wrong, please fix (the second one needs /cgit/, the first 
> /git/)

The first one gives a 404 error, but the "/git" URL[1] works for both
web and git clone access. This was fixed by Alexander Wirt earlier
this year, as "I now gives you either git smart http transport or the
cgit website of the project, depending on what you are asking for."[2]

I find this quite useful, as you don't have to worry about a single
'c' in the entire URL.

Regards,
Tiago.

[1]: https://anonscm.debian.org/git/pkg-kde/kde-extras/gammaray.git
[2]: https://lists.debian.org/debian-devel/2016/01/msg00333.html

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Dealing with "duplicate-font-file" lintian warning

[Tiago Ilieve]

Hi Dimitry,

On 22 July 2016 at 17:05, Dmitry Bogatov  wrote:
> `apt-get install dh-linktree`. Usage is simple, documentation is good,
> but you can take a look as example at cdist_4.2.1-1.

Thank you. That did the trick[1].

> Unfortunately, dh-linktree is not magic, and you have manually
> specify, what you want to replace with symlinks.

Actually is almost like magic. :-)

Regards,
Tiago.

[1]: https://anonscm.debian.org/git/collab-maint/grip.git/commit/?id=1cf2b0f

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Dealing with "duplicate-font-file" lintian warning

[Tiago Ilieve]

Hi,

I'm updating the "grip" package (bug #832000[1]), which resulted in
the following lintian warning:

W: grip: duplicate-font-file
usr/share/grip/grip/static/octicons/octicons.ttf also in
fonts-octicons

Is there a helper to deal with this kind of issue? Like the
"sphinxdoc"[2] one, which automatically replaces embedded JS files to
their respective links? Or should I manually declare a dependency on
"octions" package and symlink the correspondent font files[3] (as
there's also other files besides the ".tff")?

Regards,
Tiago.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832000
[2]: 
https://anonscm.debian.org/git/python-modules/packages/python-social-auth.git/commit/?id=0f00412
[3]: https://packages.debian.org/sid/all/octicons/filelist

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: more recent version with python3 support

[Tiago Ilieve]

Hi Herbert,

On 12 July 2016 at 16:46, Herbert Fortes  wrote:
> This new version has support for python3, as
> said in setup.py, so I created debian/*.install
> files and edited debian/control and debian/rules.

What are the contents of "debian/*.install" files?

I have packaged a Python library which has support for both Python 2
and 3 and didn't needed "debian/*.install" files[1]. It has two binary
packages, "python-*" and "python3-*", under "debian/control"[2] and
"PYBUILD_NAME" environment variable defined in "debian/rules"[3]
(which is required[4] by Pybuild).

Regards,
Tiago.

[1]: 
https://anonscm.debian.org/git/collab-maint/python-path-and-address.git/tree/debian?id=0a933ff
[2]: 
https://anonscm.debian.org/git/collab-maint/python-path-and-address.git/tree/debian/control?id=0a933ff
[3]: 
https://anonscm.debian.org/git/collab-maint/python-path-and-address.git/tree/debian/rules?id=0a933ff
[4]: https://wiki.debian.org/Python/Pybuild#debian.2Frules

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: add missing pristine-tar

[Tiago Ilieve]

Hi Nico,

On 20 May 2016 at 08:10, Nico Schlömer  wrote:
> Thanks for the hint.
> Unfortunately, it's not working dpt picks up an older version that already
> is in pristine-tar and adds another commit for it (bug?), but leaves out the
> version for which there is no pristine-tar.
>
> Any other suggestions?

I'm not really sure if I understood your problem, but "pristine-tar
commit" accepts a last optional argument where you specify the git
branch/tag for which the tarball corresponds to. From the manpage:

pristine-tar [-vdk] [-m message] commit tarball [upstream]

This way you can add pristine-tar information for any tarball that you
may have, be it the latest or an older one. E.g.:

pristine-tar commit ../upstream-tarball-1.1.orig.tar.gz

or

pristine-tar commit ../upstream-tarball-1.0.orig.tar.gz upstream/v1.0

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Binaries under "/usr/lib/"

[Tiago Ilieve]

Giulio,

On 18 May 2016 at 07:15, Giulio Paci  wrote:
> One approach that usually fits my needs is the one proposed by Thibaut 
> Paumard [1], that I am reproposing here with minimal changes:

Thanks for sharing this pretty detailed case. As my issue with
"pythonpy" was way more simpler, I ended up updating the new path in
its bash-completion file[2] (and cleaning it, removing unneeded
entries).

Of course your suggestions are useful for more complex packages and
your contribution here will not be in vain.

Regards,
Tiago.

[1]: https://lists.debian.org/debian-mentors/2012/04/msg00012.html
[2]: 
https://anonscm.debian.org/git/collab-maint/pythonpy.git/tree/debian/patches/0002-fix-bash-completion.patch?id=fb1165d

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Bug#823478: python3-protobuf3

[Tiago Ilieve]

Jonathon,

On 18 May 2016 at 05:52, Jonathon Love  wrote:
>> umh, you force pushed everything, master, upstream and pristine-tar
>> branches.  WHY?  what did you do?
>
> oh, sorry, i never intended for you to look at that repo, assuming you'd
> look at the debian-mentors one.

This is something I've seen on "debian-mentors" mailing list more than
one time and we should urge people to don't do it: if you pushed
changes to a public repository please, never, ever "--force" a new
push. It's OK if you are doing this on a private location for yourself
(as the forced push won't affect anyone else), but it doesn't make any
sense to mention a repository in a public mailing list and then assume
that no one would clone/fetch it.

I know exactly what Mattia felt. :-(

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Binaries under "/usr/lib/"

[Tiago Ilieve]

Hi Ben,

On 17 May 2016 at 21:06, Ben Finney  wrote:
> How many process calls are there? The ideal solution IMO is to:

Not much of them. In my case, there's just one. I was thinking about a
corner case, where there would be multiple process calls, possible
making a patch like this somewhat hard to maintain.

> * Make the location of application-private binaries configurable at
>   build time, with a simple one-point-of-truth (e.g. a Makefile
>   variable).
>
> * Patch every call to those application-private binaries to use the
>   configured location.
>
> * Submit that patch upstream, explaining why it's superior behaviour.
>
> * Maintain the patch in Debian for the (short?) time while upstream
>   incorporates the patch.

Thanks for your input. I like your suggestions, as they look pretty
straightforward, but this is how this is being done for other
packages? I was looking at § 9.1.1 File System Structure[1] from the
Debian Policy Manual and it states that the need to put object files,
internal binaries and libraries under "/lib{,32}" and "/usr/lib{,32}"
is a requirement - however, it doesn't says how this should be done.

So, even appreciating your suggestions, I would like to hear from some
maintainers that are used to do this on their packages. This way we
can possible mix both some battle-tested approaches and your nice tips
as well.

Regards,
Tiago.

[1]: https://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Binaries under "/usr/lib/"

[Tiago Ilieve]

Hi Mattia,

(Moving the discussion from BTS to "debian-mentors" mailing list.)

On 15 May 2016 at 20:25, Mattia Rizzolo  wrote:
> In this case the binary should go into /usr/lib instead.  That place
> exist exactly for this reason:
> "/usr/lib includes object files, libraries, and internal binaries that
> are not intended to be executed directly by users or shell scripts"
> http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA

This is interesting, as I wasn't aware of it. Thanks for pointing this
reference.

> Given that in your case you say the binary is not called by anything
> else than the application itself, then why keep it in /usr/bin?

As "/usr/lib/" is not part of $PATH, how should we deal with this?
Patch every process call to the internal binaries in the upstream
source? Or is there an easier way to work around this?

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#823742: RFS: hdf-compass/0.6.0b5-1 [ITP]

[Tiago Ilieve]

Mattia,

On 15 May 2016 at 16:24, Mattia Rizzolo  wrote:
> * d/hdf-compass.lintian-overrides
>   + bad habit doing lintian overrides without a comment.  But I can't
> imagine a reason to override binary-without-manpage.  That one just
> needs fixing, and hiding it behind an override doesn't help it.
>
> (...)
>
> FTR, what I veto against is the override for binary-without-manpage,
> that IMHO is plain wrong, even if I know several others DDs who are ok
> with that).

There's one use case I can think of where overriding a
"binary-without-manpage" is fine: if the executable isn't supposed to
be used by the end-user, only as an external command called from the
application itself. I had to do this with "pythonpy"[1], as it uses an
executable called "pycompleter" to provide its bash-completion
feature.

Can't say if this is what is happening here, as I didn't reviewed the
package. Anyway, I guess worth mentioning this kind of corner cases as
an exception for a rule.

Regards,
Tiago.

[1]: 
https://anonscm.debian.org/git/collab-maint/pythonpy.git/tree/debian/pythonpy.lintian-overrides?id=308b0f2

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: request more advice: lintian warnings and python-tldp + ldp-docbook-stylesheets

[Tiago Ilieve]

Martin,

On 28 April 2016 at 07:51, Gianfranco Costamagna
 wrote:
> yep, for signing on github, just sign it, and in "releases" tab you should 
> have some "upload additional files"
> where you can upload it (I'm going through my memory)

This process is documented on wiki.d.o[1], although worth mentioning
Paul Wise concerns about this method[2].

Regards,
Tiago.

[1]: https://wiki.debian.org/Creating%20signed%20GitHub%20releases
[2]: https://lists.debian.org/debian-devel/2016/04/msg00277.html

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#819681: RFS: python-django-gravatar2/1.4.0-1 [ITP]

[Tiago Ilieve]

Nicolas,

On 20 April 2016 at 03:49, Nicolas Dandrimont  wrote:
> Tiago, when replying to a RFS, please use the bug report rather than the
> mailing list.

Yeah, I've only noticed this after my last message in the thread. Now
I figured that this happened because I've replied his second message,
which hadn't the bug address in the "Reply-To:" header.

Thanks for the reminder.

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#821236: RFS: netsed/1.2-2

[Tiago Ilieve]

Hi Mats,

I've reviewed your package. It's in a good state, but there's a few
things you might wanna take a look at:

* debian/control:
  - Is "dpkg-dev" really a dependency?
  - Please run "wrap-and-sort -a" to sort the build dependencies.
  - The URL in "Vcs-Browser" can be the same as "Vcs-Git". The newer
(in Vcs-Git) is much better to use in a browser than the "gitweb" one.

* debian/copyright: please take a look at the copyright years. For
instance, yours is defined as "2010" in there, but looking at the
changelog it should be something like "2011-2016"?

* debian/docs: are you sure the "TODO" file should be part of the
package? It looks like documentation for developers, not end-users.

* debian/patches/series: empty file that should be removed.

* debian/rules:
  - debhelper compatibility was raised to 9, but there are comments in
there referencing the changes made to support the version 8 that
should be removed.
  - "export CPPFLAGS CFLAGS LDFLAGS" and those variable definitions
should be removed.
  - Hardening should be added with "export DEB_BUILD_MAINT_OPTIONS =
hardening=+all". This will fix "hardening-no-pie" and
"hardening-no-bindnow" lintian complaints.

* debian/watch: is not working, yelding an error "1.sig failed: 400 URL
must be absolute". Changing "\1" to "$1" in
"opts=pgpsigurlmangle=s|(.*).tar.gz$|\1.sig|" allows the signature to
be downloaded, but uscan fails to check it with "uscan warn: FAIL
Checking OpenPGP signature (no upstream tarball downloaded)." Are you
sure the key in "debian/upstream/signing-key.asc" is right?

Please let me know if you have doubts with any of these points.

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#820900: RFS: [ITP] python-hashids/1.1.0-1

[Tiago Ilieve]

Gianfranco,

On 14 April 2016 at 09:25, Gianfranco Costamagna
 wrote:
> apt-get install check-all-the-things -t experimental

Thank you. I didn't knew that it was available on experimental only.

$ sudo apt install check-all-the-things
(...)
Need to get 566 MB of archives.
After this operation, 2,344 MB of additional disk space will be used.
Do you want to continue? [Y/n]

But with this size, I really hope it check *all the things*.

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#820900: RFS: [ITP] python-hashids/1.1.0-1

[Tiago Ilieve]

Paul,

On 14 April 2016 at 01:17, Paul Wise  wrote:
> check-all-the-things and lintian print a number of things that could
> be polished.

What are you seeing on lintian? I hasn't showed anything besides
"debian-watch-may-check-gpg-signature" (using
display-experimental/display-info/pedantic) to me.

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#820900: RFS: [ITP] python-hashids/1.1.0-1

[Tiago Ilieve]

Hi Edward,

Nice job! A simple and properly packaged Python library. I have
absolutely nothing to ask to be changed.

I'd upload it if I had upload rights... :-)

P.s.: I see that you have an "@debian.org" address in your DDPO page.
Aren't you a DD anymore?

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Bug#819681: RFS: python-django-gravatar2/1.4.0-1 [ITP]

[Tiago Ilieve]

Hi Pierre-Elliott,

On 11 April 2016 at 14:05, Pierre-Elliott Bécue  wrote:
> In that case, if the main branch wasn't `master` the issue would be the
> same, yet you'd need the `-b` option. That's my view of explicit V.S.
> implicit, you'd have something working based on an assumed behaviour.

There's no issue, as the repository from which you are cloning from
has the information about what the default branch is. This has been
discussed here a couple weeks ago[1][2].

> Actually, truth is when I answered to you I forgot one main reason I
> switched to .install files : this variable was messing with my package
> mailman3-core{,-doc}, which name didn't contain python/python3 in front. So
> I thought this variable was more an issue that a help, but for a library, it
> works fine, so I can use it directly and avoid .install files.

I see. But mailman3 is a much more complex package, isn't it? I prefer
to start choosing simplicity and only picking any needed workarounds
later.

> sbuild.

Interesting. I've never used it and tend to use chroot-based
approaches only to make sure the package isn't suffering from FTBFS
issues. On a daily basis I use dpkg-buildpackage inside a VM or
container (been using Docker for this lately) with sid/unstable.

> My first packages didn't contain any tests. The first one with tests I had
> was mailman3-core, which needs for the tests running a basic mailman3 server
> installed, this is not really compatible with the way the tests are done in
> packaging.

I'm not sure if DEP-8 tests can run daemons, but you can take a look
at Debian CI[3]. Maybe it helps you in this matter.

> This one is a django library, that requires settings to be installed. Same
> issue.
>
> I tried to deal with these, but it's really painful. So either there is a
> way for django packages to do it properly or I'd rather not do the test part
> in the packaging process.

I've been a Django developer for a couple years in the past, but
shamefully I'm not (and wasn't at the time) well-versed in testing
libraries for it. Not being able to help you with that, I'd suggest
you to ask about it on "debian-python" mailing list if you like.

> It allows to check for updates in an easier way and I don't see any benefit
> in taking sources from upstream page instead of using pypi.

You can easily check for new releases on GitHub[4] as well.

The issue here is that they aren't exactly the same. I've download
tarballs from both of them and diff'ed the two directories:

Common subdirectories: github-django-gravatar-1.4.0/django_gravatar
and pypi-django-gravatar2-1.4.0/django_gravatar
Only in pypi-django-gravatar2-1.4.0/: django_gravatar2.egg-info
Only in github-django-gravatar-1.4.0/: example_project
Only in github-django-gravatar-1.4.0/: .gitignore
Only in pypi-django-gravatar2-1.4.0/: PKG-INFO
Only in github-django-gravatar-1.4.0/: RELEASING.rst
Only in github-django-gravatar-1.4.0/: requirements.txt
diff github-django-gravatar-1.4.0/setup.cfg
pypi-django-gravatar2-1.4.0/setup.cfg
2a3,8
>
> [egg_info]
> tag_build =
> tag_date = 0
> tag_svn_revision = 0
>
Only in github-django-gravatar-1.4.0/: tox.ini
Only in github-django-gravatar-1.4.0/: .travis.yml

As you see, files like "tox.ini", which could help you to run the
tests, are missing from PyPI. There's not really a problem in
packaging anything from PyPI, but I guess that's no better place to
fetch release tarballs if they come straight from the upstream
repository, right?

> When I tried to dput I've been refused it because 1.4.0-1 was already on the
> server. That's the only way I found. Maybe I did something wrong.

Maybe you uploaded again before mentors.d.n processed the first
upload? There's an waiting time ("How long will it take until my
upload is available to sponsors?" from its Q[5]) between the upload
and the package actually being available in there. I'm suggesting this
because mentors.d.n even store different versions of the package, even
when you did not bump its version. You can always use the delete
button from its web interface as well.

> Yeah, that was to have a clean history, but I admit this practice is rude.
> I'll definitely avoid it.

Thanks for considering my request about this. I appreciate.

Regards,
Tiago.

[1]: https://lists.debian.org/debian-mentors/2016/04/msg00057.html
[2]: https://lists.debian.org/debian-mentors/2016/04/msg00060.html
[3]: https://ci.debian.net/doc/
[4]: https://github.com/twaddington/django-gravatar/releases
[5]: http://mentors.debian.net/qa

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#820733: RFS: Series/1.0 [ITP] -- Keep track of your favourite TV series

[Tiago Ilieve]

Hi Sartore,

On 11 April 2016 at 16:36, Sartore Giorgio (Mani)  wrote:
> Dear mentors,
>
> I am looking for a sponsor for my package "series":
>
> Package name: series
> Version : 1.0
> Upstream Author : Sartore Giorgio 
> URL : https://github.com/Mani-GS/series.git
> License : GPL 3
>
> It builds those binary packages:
>
> series - keep track of your favourite TV series

Actually this isn't a Debian package. It's an upstream repository for
an application that can possibly be packaged for Debian. In this case,
you do not want a Request for Sponsorship (RFS) but a Request for
Package (RFP).

Anyway, the repository itself is less than 12 hours old and the
application probably doesn't have any userbase besides the upstream
author, which is you. I would like to ask you to close this bug and
open a new one when the package is more mature and have a few more
users.

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Bug#819681: RFS: python-django-gravatar2/1.4.0-1 [ITP]

[Tiago Ilieve]

Pierre-Elliott,

On 7 April 2016 at 12:27, Pierre-Elliott Bécue  wrote:
> You're right, but I'm an "explicit is better than implicit guy". :)

I guess this is not a case of "explicit vs. implicit". Imagine the
entire line as an URL:

https://github.com/P-EB/python-django-gravatar2.git%20-b%20master

Of course you wouldn't have a problem if you copy-and-pasted it
(before escaping the spaces) on the command line, as the "-b master"
would be interpreted as arguments to "git clone". But, if you copy and
pasted on another client, e.g. a GUI Git client (which I've seen
people using), the URL may be interpreted like above (after escaping)
and the cloning process will fail.

Not to mention that this is expected to be in machine-readable form,
which may not be aware that someone is passing Git command line
arguments along the URL.

> I thought it'd be better to keep them, but, okay.

They are mostly related to building projects written in C, so there's
little use for a pure-Python one, as you are not "saving them for
later".

> I'm not in fond of PYBUILD_NAME thing since I met a lot of trouble with it.
> If that's recommended I'll put it but I'm more a ".install" files guy.

Imagine that you would be doing by hand what is expected to be
automated by Pybuild.

> I do not have any issue to build multiple times, but I'll follow your
> advice.

Are you building with pbuilder or something like that? I've used
dpkg-buildpackage and it complained in the second time I ran it.

> I'm really uncomfortable with tests un packaging for python apps, but I can
> try to remove the override. Anyway, I'm using pybuild, hence the pypi
> package fits better and a good way to have a snapshot of upstream's work.

Why uncomfortable with tests in packaging? They can help to make sure
that newer versions aren't introducing regressions.

I didn't understood why PyPI packages would fit better than snapshots
(tarball releases) from the upstream repository.

> Thank you very much for all these advice.

Glad to help. You're welcome.

On 7 April 2016 at 12:51, Pierre-Elliott Bécue  wrote:
> I uploaded a new version of the package. It should be visible soon, and
> accessible also via
>
> dget -x 
> http://mentors.debian.net/debian/pool/main/p/python-django-gravatar2/python-django-gravatar2_1.4.0-2.dsc

You shouldn't bump the version of the package yet, as it was never
uploaded to the archive. Until the first upload, it will be "X.Y.Z-1",
no matter how many changes you did to it. Then you can bump the
version in the following revisions, but only after every upload, not
after every change in the packaging work.

P.s.: I've seen that you pushed changes with "--force" to the Git
repository. Please don't do that when you already shared it with other
people. They will not be able to merge/pull easily (as there are
annoying merge conflicts in the changed files) and will be harder to
analyze what you really did (which is the primary feature of every
version control system), as there will be no visible difference in the
history.

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#820029: RFS: grip/4.1.0-1 [ITP]

[Tiago Ilieve]

Mattia,

On 7 April 2016 at 06:34, Mattia Rizzolo  wrote:
> Oops, I completely forgot to tag, actually!
>
> pushed :)
>
> Usually I do it before uploading but boo

No problem. Thanks again! :-)

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Bug#819681: RFS: python-django-gravatar2/1.4.0-1 [ITP]

[Tiago Ilieve]

Hi Pierre-Elliott,

On 7 April 2016 at 07:03, Pierre-Elliott Bécue  wrote:
> Dear mentors,
>
> So far it appears that I got no reply. I'm trying a small bump in hope that
> somebody will get interested because of my motivation, or that somebody that
> missed my first mail will see this one! :)

I can't sponsor your package as I have no upload rights, but reviewed it:

debian/control:
* Standards-Version: we are on 3.9.8 since yesterday;
* Vcs-Git: there's no need for "-b master", as this is the default
branch anyway;
* ${shlibs:Depends} can be dropped from the "Depends:" field of each
binary package, as this isn't need for Python packages;
* Architecture: "all" instead of "any" on each binary package.

debian/copyright:
* Copyright for Tristan Waddington is 2011-2015;
* Copyright for Pierre-Elliott Bécue is 2016;
* Why did you choose GPL-2+ for the packaging work? As said here
before[1], this can be a problem, as this license is more restrictive
than the upstream work, which is MIT.

debian/rules:
* Please clean up the file a little, removing (most of) the commented lines;
* Add "export PYBUILD_NAME=django-gravatar2"[2]. That's the reason why
you probably ended up with empty binary packages and needed to add
custom "*.install" files.

python3-django-gravatar2.docs and python-django-gravatar2.docs:
* The preferred format for additional documentation is HTML (Debian
Policy Manual, § 12.4). If you want to ship the contents of the
"README.rst" file you probably want to do this after converting them
to HTML (e.g. using Sphinx).

python3-django-gravatar2.install and python-django-gravatar2.install:
* Unneeded files that should be removed.

Additional suggestions:

* Please create a "debian/source/options"[3] file with
'extend-diff-ignore="^[^/]+\.egg-info/"'. Otherwise you can't build
the package more than one time because dpkg-source will complain about
modified files.
* Is there a reason why you packaged the tarball from PyPI and not a
tarball from the upstream repository[4]? I'm asking this because
there's an override for "override_dh_auto_test" (avoiding it), when
the upstream repository contains tests that would be nice to bring to
the Debian package as well.

I hope this helps you to find a sponsor.

Regards,
Tiago.

[1]: https://lists.debian.org/debian-mentors/2016/03/msg00332.html
[2]: https://wiki.debian.org/Python/Pybuild#debian.2Frules
[3]: https://wiki.debian.org/Python/FAQ#How_should_we_package_Python_eggs.3F
[4]: https://github.com/twaddington/django-gravatar/releases

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#820029: RFS: grip/4.1.0-1 [ITP]

[Tiago Ilieve]

Mattia,

On 6 April 2016 at 19:58, Mattia Rizzolo  wrote:
> I see, cool.
>
> Then, uploaded :)

I saw that it is now on the NEW queue. Thank you very much!

P.s.: can you please push the release tag to the collab-maint repo? :-)

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#820029: RFS: grip/4.1.0-1 [ITP]

[Tiago Ilieve]

Hi Mattia,

On 6 April 2016 at 13:24, Mattia Rizzolo  wrote:
> umh, reading it like that looks to me that it runs against the sources
> only.  Am I wrong?  DEP-8 tests should test against the installed
> packages.

Although written in a conventional "test_*.py" file, all the tests in
there calls the "grip" binary in $PATH. Without the package installed,
all of them fails with:

FileNotFoundError: [Errno 2] No such file or directory: 'grip'

> No need: I have it locally, and ftpmaster will notice these things and
> accept them in order.

No problem then.

> I see, well temporary branches to be deleted, rebased, squashed, etc are
> totally fine by me too.

Perfectly. Will use this approach from now on.

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#820029: RFS: grip/4.1.0-1 [ITP]

[Tiago Ilieve]

Mattia,

On 6 April 2016 at 09:49, Mattia Rizzolo  wrote:
> you forgot to add python-path-and-address and python3-path-and-address
> to build-deps.

Indeed. "python3-requests" was missing as well. Notice that building
it again on a clean sid install.

> And also I now notice that you're missing a python (or python-all)
> build-dep, which is kind of redundant but still mandated.

Actually, I don't know what I was thinking at the moment, but those
Python 2 dependencies aren't needed at all. The package is built
against Python 3 only.

> umh, so, tests are not copied, ok, that seems to be normal for pybuild
> and there is even an example about how to deal with it.
> but also copying tests/ seems to be not enough, as it seems to need the
> README.md too ?!?
>
> so, I did this, I used some pybuild black magic (and enabled the
> verbose mode as I was having more troubles than usual) and removed the
> override.
>
> With the following git diff the tests passes.

Thanks for the tip about BEFORE and AFTER pytest hooks. I've
simplified them a bit[1], because it actually needs the README.md file
only, not the entire "tests/" folder. I've also added DEP-8 tests[2]
for those who can't be run at build time. Both test suites are passing
now.

Worth mentioning that the package will FTBFS because right now
"python3-path-and-address" is still on the NEW queue:

The following packages have unmet dependencies:
 pbuilder-satisfydepends-dummy : Depends: python3-path-and-address
which is a virtual package and is not provided by any available
package
Unable to resolve dependencies!  Giving up...

Should we wait for dependencies of a package arrive at the archive
before uploading it?

> BTW, i really much don't mind WIP commits instead of sending diffs to
> paste.d.n ;)

Sorry. I try avoid pushing "dirt commits". Next time I'll push them in
a temporary branch.

Thank you very much, Mattia! :-)

Regards,
Tiago.

[1]: 
https://anonscm.debian.org/git/collab-maint/grip.git/commit/?id=ccbdc7cc694fb4e2ac7478ca7788380a3620851c
[2]: 
https://anonscm.debian.org/git/collab-maint/grip.git/commit/?id=a90a03eeaedfcd632141b98802c43ea6e1fdb4e6

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#820029: RFS: grip/4.1.0-1 [ITP]

[Tiago Ilieve]

Hi Mattia,

As the new version of "python-responses" has hit unstable, the test
were enabled with the following patch:

http://paste.debian.net/424537/

The "--ignore=tests/test_cli.py" argument was added because this file
consists of functional tests (DEP-8) that should not run on build
time. The problem now is the following error:

http://paste.debian.net/424538/

Adding an "import pdb; pdb.set_trace()" in the test that is failing, I
could see that it is looking for this README file in
"/vagrant/grip/deb-grip/.pybuild/pythonX.Y_3.5/build/tests/input/default".
This file exists on the upstream source[1] and the tests doesn't fail
when I run them locally. My guess is that it is not being copied by
"pybuild" (actually, looks like the entire "tests/" directory isn't),
thus causing the test to fail during build.

What should I do in this case? Would be sensible to skip this test?

Regards,
Tiago.

[1]: https://github.com/joeyespo/grip/blob/v4.1.0/tests/input/default/README.md

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#820029: RFS: grip/4.1.0-1 [ITP]

[Tiago Ilieve]

Hi Mattia,

On 4 April 2016 at 22:04, Mattia Rizzolo  wrote:
> meh, there is git, let me use it!
> https://anonscm.debian.org/git/collab-maint/grip.git

Actually, it would be pretty nice if the RFS template grabbed the
"Vcs-Git" field. I'll remember to add it manually in the next time.

> Though as I said on the other one I'm wary of taking out the tarball
> without pristine-tar, so I'm going to use the tarball you uploaded to
> mentors with the git repo.

Ok. No problem.

> I pinged onovy and see if we can upload src:responses before this, so
> that the tests are enabled.

Ondrej Novy sent an e-mail earlier today, where I was cc'ed, to the
main package maintainer, Simon Chopin, asking if it is OK to upload
the updated package. He also took the opportunity to do lot of
improvements[1] in the packaging work as a whole.

> The package itself looks cool instead, so I'm just going to wait for
> onovy to reply and discover when he plans on uploading.

So... Nothing to fix? I guess I'll have to start sending some
bad-shaped packages then. :-)

Thank you again, Mattia!

Regards,
Tiago.

[1]: http://anonscm.debian.org/git/python-modules/packages/responses.git

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#819773: RFS: python-path-and-address/1.0.0-1 [ITP]

[Tiago Ilieve]

Mattia,

On 4 April 2016 at 21:37, Mattia Rizzolo  wrote:
> yep, saw the mail that day, but didn't pay much attention back then.

There's no problem.

> This is basically a security feature, I think, not a bug.
>
> Though you should be able to fix it more manually by directly editing
> the HEAD file.
>
> but this time I just run the command for you :)
>
> This turned the HEAD file to be group Debian again and I can't have it
> back to scm_collab-maint as I'm not in the collab-maint anymore.
>
> Yeah, permissions on collab-maint (and alioth in general) are just a
> mess
> If you have troubles with file permissions on collab-maint feel free to
> mail me if you don't have any nearby DD..

Turns out that the "Debian" group is for DDs... Makes sense. Thanks
for fixing this. I'll surely reach you in case I need something like
that again.

> DSA has nothing to do with alioth (sadly?), there is only one active
> person with root on moszumanska (which is the guy that replied to you
> last time, iirc), but he won't chgrp the directory (as afaik he made
> them gid:Debian exactly because he wants to avoid external messing with
> repositories (if the root directory was writable by you you would be
> able to do anything with the config and the hooks, and that's a security
> trouble on collab-maint where everybody has access).

I see. The problem is that the repository is writable by the owner,
who can edit any configs/hooks. I had a problem in this case because I
was not the one who created it.

It is indeed quite hard to take care of a place where so many people
can write to.

> Yep, even if I'm always wary of this.
> I'm a guy who prefers using the tarballs as provided upstream.
> I wrote this item before noticing that you used .xz, so a different
> tarball than upstream.
> Fine by me, I see how this is enough for this case.

Now I understood. You mean a byte-to-byte identical tarball, not
identical regarding its contents only. I see this as enough by now
too. If the upstream starts releasing signed tarballs we can changed
that.

> ok, yes I know it's more popular.  To me it seems "Expat" is known only
> within Debian, heh :)

Actually, now that you mentioned I guess I had never ever heard of the
"Expat License" outside Debian...

> going to set myself as owner, will look at it somewhen tomorrow though.

Well, looks like you already take a look a few minutes ago. :-)

> Well, I uploaded it :D
>
> I also tagged the repository.

It is on the NEW queue right now. The tag detail is also pretty nice.
Fetched it.

Thank you very much, Mattia!

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#819773: RFS: python-path-and-address/1.0.0-1 [ITP]

[Tiago Ilieve]

Hi Mattia,

On 4 April 2016 at 18:25, Mattia Rizzolo  wrote:
> I usually prefer using git to do my stuff, though here a simple clone is
> not enough:
>
> mattia@chase ~/devel/RFS/python-path-and-address % git clone 
> https://anonscm.debian.org/git/collab-maint/python-path-and-address.git
> Cloning into 'python-path-and-address'...
> remote: Counting objects: 119, done.
> remote: Compressing objects: 100% (110/110), done.
> remote: Total 119 (delta 44), reused 0 (delta 0)
> Receiving objects: 100% (119/119), 27.69 KiB | 0 bytes/s, done.
> Resolving deltas: 100% (44/44), done.
> Checking connectivity... done.
> warning: remote HEAD refers to nonexistent ref, unable to checkout.
>
> you seems to use debian/unstable as main packaging branch, so please set
> HEAD in a way a simple 'git clone' just works.

This is related to some issues with collab-maint I've reported last
weekend[1]. In the other repositories that I've created in there, "git
symbolic-ref HEAD refs/heads/debian/unstable" can be used update the
default branch. The problem is that, as I'm not the owner (because I
didn't created the the repository, adopted ITP) nor member of the
group ("Debian" instead of "scm_collab-maint") of the folder
"/git/collab-maint/python-path-and-address.git", it raises the
following error:

error: Unable to open HEAD.lock for writing

If you know someone with sudo privileges on git.debian.org
(moszumanska) to fix the folder permissions, please let me know so I
can forward this issue to them. Maybe I should ask the DSA team
directly?

> Also, your git repository seems to lack a pristine-tar branch, which is
> basically needed to get the same tarball that is in the archive.

There's the "upstream" branch in there, which serves this purpose. It
is defined as "upstream-branch" in "debian/gbp.conf". Running "gbp
buildpackage" will recreate
"python-path-and-address_1.1.0.orig.tar.xz" from it:

gbp:info: python-path-and-address_1.1.0.orig.tar.xz does not exist,
creating from 'upstream/1.1.0'

It uses the tag to do this, so there's even no need to checkout
"origin/upstream" in a local branch.

> * debian/patches:
>   + empty, please remove the directory

Done[2].

> * debian/changelog:
>   + be more precise: that's the Expat license

I do understand that some may say that the Expat License is the right
name for MIT license, but the text in there is identical to the ones
published by OSI[3] and GitHub's Choose a License[4] of the MIT
License. In order to avoid any further confusion, I'd like to ask you
to leave this as is. The name "MIT" is much more popular for the text.

> I'll look also at the rdep of this once through with this.

Thank you. Feel free to take the ownership of the other RFS too.

> Note: fixing on git is enough, I'm very much fine doing everything
> with git.

I prefer to do that too. I've uploaded the package to mentors because
it would be easier for anyone to take a look (using the web interface)
at its state without even having to download it.

I'll ping you every time I make a change.

Regards,
Tiago.

[1]: https://lists.debian.org/debian-mentors/2016/04/msg8.html
[2]: 
https://anonscm.debian.org/git/collab-maint/python-path-and-address.git/commit/?h=debian/unstable=f75e55228e6a94ee9c87ef7cae91e07c5b4997c5
[3]: https://opensource.org/licenses/MIT
[4]: http://choosealicense.com/licenses/mit/

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#820029: RFS: grip/4.1.0-1 [ITP]

[Tiago Ilieve]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-pyt...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "grip"

* Package name: grip
  Version : 4.1.0-1
  Upstream Author : Joe Esposito 
* URL : https://github.com/joeyespo/grip
* License : MIT
  Section : utils

It builds those binary packages:

grip  - Preview GitHub Markdown files like Readme locally

To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/grip

Alternatively, one can download the package with dget using this command:

dget -x http://mentors.debian.net/debian/pool/main/g/grip/grip_4.1.0-1.dsc

-

This package depends on "python-path-and-address" (RFS #819773[1]), which is
not on the archive yet. It would be awesome if the sponsor could help me with
both RFS bugs.

Tests are commented out in "debian/rules" because they depend on a newer
version of "python-responses". I've filled a bug (#820020[2]) which is now
pending (thanks Ondrej Novy!). This can be fixed as soon as the updated package
hits unstable.

Decisions made about packaging layout (Python application vs. Python library)
have been clarified on the "debian-python" mailing list[3].

I also would like to thanks Gustavo Panizzo, who gave me permission[4] to take
over his ITP.

Regards,
Tiago.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819773
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820020
[3]: https://lists.debian.org/debian-python/2016/04/msg00017.html
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790611#17

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Minor issues with collab-maint

[Tiago Ilieve]

Hi Alex,

On 2 April 2016 at 05:32, Alexander Wirt  wrote:
> That was a misconfiguration of mine. It is fixed by now.

Thank you for taking a look at it so quickly. Now it is using a
short-lived Let's Encrypt certificate. :-)

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#819773: RFS: python-path-and-address/1.0.0-1 [ITP]

[Tiago Ilieve]

Hi,

I've updated the package to the version "1.1.0" which the upstream
kindly released after integrating my patch fixing some issues with
tests under Python 3.

It was uploaded to mentors.d.n[1] as well.

Regards,
Tiago.

[1]: http://mentors.debian.net/package/python-path-and-address

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Minor issues with collab-maint

[Tiago Ilieve]

Hi,

I'm having some minor issues with collab-maint today and didn't found
where to report it properly. There's a "collab-maint-devel"[1] list,
but there isn't any activity in there since June/2009.  Please point
me to the correct mailing list if this isn't the proper one.

* The HTTP certificate for "anonscm.debian.org" expired on Friday,
April 1, 2016 at 8:59:59 PM (no mention to timezone). This yields
browser warnings saying that the certificate can't be trusted.

* Whenever I "git push" to the repository
"python-path-and-address.git" (which wasn't created by me), the
following error appears (although the code can be pushed perfectly
fine):

remote: Migrating settings from hooks.* to multimailhook.*
remote: Traceback (most recent call last):
remote:   File "/usr/local/bin/git-commit-notice", line 16, in 
remote: config.set('announceshortlog', 'true')
remote:   File "/srv/git.debian.org/bin/git_multimail.py", line 405, in set
remote: env=self.env,
remote:   File "/srv/git.debian.org/bin/git_multimail.py", line 272,
in read_git_output
remote: input=input, keepends=keepends, **kw
remote:   File "/srv/git.debian.org/bin/git_multimail.py", line 287,
in read_output
remote: raise CommandError(cmd, retcode)
remote: git_multimail.CommandError: Command "git -c
i18n.logoutputencoding=UTF-8 config multimailhook.announceshortlog
true" failed with retcode 255
remote: error: unable to update info/refs+

This looks like a permission issue, but I'm not sure how to fix. Some
files and folders are owned by the group "Debian" (including the
"info/" folder), others are owned by the group "scm_collab-maint"
(like the "objects/" folder, which pushes are written to).

Regards,
Tiago.

[1]: http://lists.alioth.debian.org/pipermail/collab-maint-devel/

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#819773: RFS: python-path-and-address/1.0.0-1 [ITP]

[Tiago Ilieve]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-pyt...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "python-path-and-address"

* Package name: python-path-and-address
  Version : 1.0.0-1
  Upstream Author : Joe Esposito 
* URL : https://github.com/joeyespo/path-and-address
* License : MIT
  Section : python

It builds those binary packages:

  python-path-and-address - Functions for server CLI applications used
by humans. (Python 2)
  python3-path-and-address - Functions for server CLI applications
used by humans. (Python 3)

To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/python-path-and-address

Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/p/python-path-and-address/python-path-and-address_1.0.0-1.dsc

-

This package is a dependency of Grip[1], which is also being packaged
(ITP bug #790611[2]).

Regards,
Tiago.

[1]: https://github.com/joeyespo/grip
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790611

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#819289: RFS: pythonpy/0.4.10-1 [ITP]

[Tiago Ilieve]

Hi,

I've forgot to mention in the bug report that there's a Git
repository[1] for the package (as stated in debian/control). It would
be awesome if my sponsor is also able to help me to move it to
"collab-maint", which I already have write permissions.

Regards,
Tiago.

[1]: https://github.com/myhro/deb-pythonpy

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#819289: RFS: pythonpy/0.4.10-1 [ITP]

[Tiago Ilieve]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "pythonpy"

* Package name: pythonpy
  Version : 0.4.10-1
  Upstream Author : Russell Stewart 
* URL : https://github.com/Russell91/pythonpy
* License : MIT
  Section : utils

It builds those binary packages:

  pythonpy   - 'python -c', with tab completion and shorthand

To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/pythonpy

Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/p/pythonpy/pythonpy_0.4.10-1.dsc

I would like to thank Ben Finney and Gianfranco Costamagna who helped
me with the initial packaging work. :-)

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Packaging pythonpy

[Tiago Ilieve]

Gianfranco,

On 25 March 2016 at 19:07, Gianfranco Costamagna
 wrote:
> up to your sponsor :)

Tried one or two new approaches and it didn't worked. In the I've
created a patch[1] changing "#!/usr/bin/env python2" to
"#!/usr/bin/env python". This should work as long as Python 2 is the
default interpreter, something which may change in the next years, but
isn't a problem at least for Stretch.

I'm all in for another options if someone doesn't like this patch.

> swap Files: debian/*
> and Files: *
>
> first the more comprehensive and later the less.
> (lintian might be more specific)

This is awesome. I would never figure out by myself that it was so
simple to fix. :-)

> I did fix the python apps in blah section with section "utils", and uploaded 
> on debomatic again.
> Now that lintian warning is not there anymore.

Yup. I've did that as well[2].

> (I won't download the package, I think I already answered the points)

No problem. You answers were very helpful, as always.

I've uploaded a new version of the package to mentors.d.n[3]. There
are the following lintian messages now:

* "newer-standards-version": which can be ignored, as mentors.d.n
doesn't consider 3.9.7 as the current standard.
* "debian-watch-file-is-missing" and "no-upstream-changelog": which
will be fixed in the near future with upstream help regarding tagged
releases.
* "binary-without-manpage": which I'll be fixing, adding a manpage
before submitting an RFS.

Thank you very much, Gianfranco!

Regards,
Tiago.

[1]: https://github.com/myhro/deb-pythonpy/commit/5450656
[2]: https://github.com/myhro/deb-pythonpy/commit/0e2d987
[3]: http://mentors.debian.net/package/pythonpy

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Packaging pythonpy

[Tiago Ilieve]

Hi Gianfranco,

On 25 March 2016 at 16:21, Gianfranco Costamagna
 wrote:
> http://debomatic-amd64.debian.net/distribution#unstable/pythonpy/0.4.4-1/lintian
> please dget it from there and start again :)
>
> I fixed a lot of issues, and many more are there now!

I really appreciate your effort in trying to package it yourself, but
you didn't solved the main problem, which is the
"python-script-but-no-python-dep".

The "dh_auto_install" override is used to place it in
"/usr/share/pythonpy" which is the proper place for Python
*applications*[1]. Without it, it goes to the place where *libraries*
should be located.

The "remove_entry_points_scripts.patch" avoids the creation of
py{2,2.7} binaries that aren't needed. Without it and removing the
override for "dh_fixperms", the package becomes useless. There's no
way to call the "py" command, as its main script doesn't have
execution permissions.

Looks like it would be way easier to fix the entry point scripts to
created a binary named "py", avoiding just the other ones. We can also
ignore the override that changes the target folder, but doing this
feels wrong, is like we are ignoring the best practices for packaging
Python applications. That's why I'm wrecking my head with this issue,
removing every file that would be useless, instead of following the
easiest path.

About the lintian output:

* "unused-file-paragraph-in-dep5-copyright": this info doesn't appear
even when I run lintian with the same arguments on my machine. This is
strange, as I'm running "v2.5.42.1" from sid and debomatic-amd64.d.n
is using "v2.5.42.1~bpo8+1", which should be the same version. Do you
know how can I do this?
* "debian-watch-file-is-missing": this is right. I've asked[2]
upstream to tag every release on GitHub, so we can fetch information
about new versions from there.
* "application-in-library-section": fixed[3].
* "no-upstream-changelog": the upstream added a changelog file in the
last version (0.4.9, which I have packaged this afternoon), but it
doesn't comes with the tarball available in PyPI. This will be solved
when the releases are tagged and we grab them from GitHub.
* "package-installs-into-obsolete-dir": fixed using dh_bash-completion[4].

I've uploaded the last (0.4.9-1) package version to mentors.d.n[5].

Thanks,
Tiago.

[1]: https://wiki.debian.org/Python/Packaging#Example_2:_Python_application
[2]: https://github.com/Russell91/pythonpy/issues/76
[3]: https://github.com/myhro/deb-pythonpy/commit/0e2d987
[4]: https://github.com/myhro/deb-pythonpy/commit/954e424
[5]: http://mentors.debian.net/package/pythonpy

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Packaging pythonpy

[Tiago Ilieve]

Hi Gianfranco,

On 25 March 2016 at 06:25, Gianfranco Costamagna
<costamagnagianfra...@yahoo.it> wrote:
>
> adding python to the dependencies?
> do you have python to build dependencies, dh-python and python:Depends on the
> binary package?

This is what is strange. I've made the following changes:

-
diff --git a/debian/control b/debian/control
index f0c1b3f..5205298 100644
--- a/debian/control
+++ b/debian/control
@@ -3,6 +3,7 @@ Section: python
 Priority: optional
 Maintainer: Tiago Ilieve <tiago.my...@gmail.com>
 Build-Depends: debhelper (>= 9),
+   dh-python,
python (>= 2.7.3),
python-setuptools (>= 0.6.24)
 Standards-Version: 3.9.7
@@ -13,7 +14,9 @@ Vcs-Browser: https://github.com/myhro/deb-pythonpy

 Package: pythonpy
 Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
+Depends: python (>= 2.7.3),
+ ${misc:Depends},
+ ${python:Depends}
 Description: 'python -c', with tab completion and shorthand
  pythonpy is an utility that facilitates the usage of Python one-liners. The
  command 'py' evaluates a string consisting of any Python expression. It can do
-

But this didn't helped at all. The lintian.d.o page for
"python-script-but-no-python-dep"[1] says:

"Packages with Python scripts should depend on the package python.
Those with scripts that specify a specific version of Python must
depend on that version of Python (exactly).

For example, if a script in the package uses #!/usr/bin/python, the
package needs a dependency on python. If a script uses
#!/usr/bin/python2.6, the package needs a dependency on python2.6. A
dependency on python (>= 2.6) is not correct, since later versions of
Python may not provide the /usr/bin/python2.6 binary."

What is the "exactly" version of Python for a script which has
"#!/usr/bin/env python2" as its shebang?

> it is generated *during/after* the build, so the clean target won't work.
>
> a "package.pyremove" file might help, not sure
>
> codesearch.debian.net might help
> egg path:pyremove$
>
> https://codesearch.debian.net/results/egg%20path%3Apyremove%24/page_0

"pyremove" didn't worked, but in the same page that I found references
to it[2], there's a suggestion to override "dh_python", which is what
I did[3]. Thanks for the suggestion. :-)

Regards,
Tiago.

[1]: https://lintian.debian.org/tags/python-script-but-no-python-dep.html
[2]: 
https://wiki.debian.org/Python/LibraryStyleGuide#Python_3.3.2F3.4_unittest_fixers_for_2to3
[3]: https://github.com/myhro/deb-pythonpy/commit/68db18e

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Packaging pythonpy

[Tiago Ilieve]

Hi,

Can someone please help me on this one? I'm pretty close to finish the
initial packaging work. After fixing the following issues, it will be
a matter of adding a manpage and filling a RFS.

* How to fix the "python-script-but-no-python-dep" lintian error? I've
tried with and without pybuild and the error still persists.
* How to get rid of the ".egg-info/" folder that is being packaged?
Looks like "debian/clean" rules aren't working.

There's a GitHub repository for the package[1]. I have intention on
asking for a repository on collab-maint when the package is ready (I
have write permissions to it).

Regards,
Tiago.

[1]: https://github.com/myhro/deb-pythonpy

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Fwd: Packaging pythonpy

[Tiago Ilieve]

Hi Debian Python Applications Packaging Team,

I'm forwarding this message because it should have been asked on
"debian-python" mailing list as well. The first message of this
thread[1] is on "debian-mentors".

Regards,
Tiago.

[1]: https://lists.debian.org/debian-mentors/2016/03/msg00223.html

-- Forwarded message ------
From: Tiago Ilieve <tiago.my...@gmail.com>
Date: 11 March 2016 at 11:55
Subject: Re: Packaging pythonpy
To: debian-mentors@lists.debian.org


Hi Ben,

On 10 March 2016 at 22:19, Ben Finney <ben+deb...@benfinney.id.au> wrote:
> Not by itself. You need to run something that will actually use that
> substitution variable.
>
> By default you should be using Pybuild in new packages for Python code.
> This will bring many benefits, including interpolate the substvars for
> Python.

Following the Pybuild wiki page[1], I've added "dh-python" as a build
dependency and added the following to "debian/rules":

diff --git a/debian/rules b/debian/rules
index cc0781a..ae03e14 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,10 @@
 #!/usr/bin/make -f

+export PYBUILD_NAME=pythonpy
+
 %:
-   dh $@ --with python2
+   dh $@ --with python2 --buildsystem=pybuild


 override_dh_auto_build:

But that doesn't changed anything. The
"python-script-but-no-python-dep" error still persists.

Am I missing something here?

> Still needed. Build dependencies are not affected by Debhelper. If the
> build depends on ‘foo’, use of Debhelper won't take away the need to
> declare “Build-Depends: foo”.

Got it.

> That directory is effectively auto-generated garbage for a Debian
> package, it needs to be cleaned.
>
> Use the ‘clean’ target to remove files you don't need. Debhelper's
> ‘dh_clean’ is useful here, see its man page.

The Python FAQ wiki page has a section about "debian/clean" and Python
eggs[2], which I was already following. What is strange is that the
upstream tarball has five files in its ".egg-info/" folder:

- dependency_links.txt
- entry_points.txt
- PKG-INFO
- SOURCES.txt
- top_level.txt

But the built package has only three:

- dependency_links.txt
- PKG-INFO
- top_level.txt

So, it looks like the original files are being properly removed, but
are created again later. Any idea about how to overcome this?

Regards,
Tiago.

[1]: https://wiki.debian.org/Python/Pybuild
[2]: https://wiki.debian.org/Python/FAQ#How_should_we_package_Python_eggs.3F

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Packaging pythonpy

[Tiago Ilieve]

Hi Ben,

On 10 March 2016 at 22:19, Ben Finney  wrote:
> Not by itself. You need to run something that will actually use that
> substitution variable.
>
> By default you should be using Pybuild in new packages for Python code.
> This will bring many benefits, including interpolate the substvars for
> Python.

Following the Pybuild wiki page[1], I've added "dh-python" as a build
dependency and added the following to "debian/rules":

diff --git a/debian/rules b/debian/rules
index cc0781a..ae03e14 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,10 @@
 #!/usr/bin/make -f

+export PYBUILD_NAME=pythonpy
+
 %:
-   dh $@ --with python2
+   dh $@ --with python2 --buildsystem=pybuild


 override_dh_auto_build:

But that doesn't changed anything. The
"python-script-but-no-python-dep" error still persists.

Am I missing something here?

> Still needed. Build dependencies are not affected by Debhelper. If the
> build depends on ‘foo’, use of Debhelper won't take away the need to
> declare “Build-Depends: foo”.

Got it.

> That directory is effectively auto-generated garbage for a Debian
> package, it needs to be cleaned.
>
> Use the ‘clean’ target to remove files you don't need. Debhelper's
> ‘dh_clean’ is useful here, see its man page.

The Python FAQ wiki page has a section about "debian/clean" and Python
eggs[2], which I was already following. What is strange is that the
upstream tarball has five files in its ".egg-info/" folder:

- dependency_links.txt
- entry_points.txt
- PKG-INFO
- SOURCES.txt
- top_level.txt

But the built package has only three:

- dependency_links.txt
- PKG-INFO
- top_level.txt

So, it looks like the original files are being properly removed, but
are created again later. Any idea about how to overcome this?

Regards,
Tiago.

[1]: https://wiki.debian.org/Python/Pybuild
[2]: https://wiki.debian.org/Python/FAQ#How_should_we_package_Python_eggs.3F

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Packaging pythonpy

[Tiago Ilieve]

Hi,

I'm packaging a Python application named "pythonpy"[1] (ITP bug
#817856[2]). It has been uploaded to mentors[3] and there's a
repository on GitHub[4].

There's a few things which aren't fixed yet, which I would welcome help, like:

- A lintian error "python-script-but-no-python-dep" is being shown for
both binaries (symlinks in "/usr/bin"). The "${python:Depends}" in the
binary package shouldn't be sufficient to fix this?
- Is it right to declare "python-setuptools" as a build dependency, or
this is supposed to be superseded by "dh-python" somehow?
- The folder "/usr/share/pythonpy/pythonpy-0.4.4.egg-info/" should be
part of the binary package or should it be stripped? If it has to be
removed, how can I do this?

I'm all ears for any other issue that should be fixed, but those are
the ones that are annoying me most. Specially the lintian error that
is a showstopper.

Regards,
Tiago.

[1]: https://github.com/Russell91/pythonpy
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817856
[3]: http://mentors.debian.net/package/pythonpy
[4]: https://github.com/myhro/deb-pythonpy

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#814864: RFS: zbackup/1.4.4-1~bpo8+1

[Tiago Ilieve]

Gianfranco,

On 17 February 2016 at 13:57, Gianfranco Costamagna
 wrote:
> Hi, I removed you from uploaders (it has to be a no-change bpo, and nobody 
> should care about lintian).

This is something that I had talked with Antonio Terceiro in private
when we were dealing with another backport. The backport contribution
guidelines states that[1] if you do this, it will be easier to follow
the packages through DDPO.

In the section "Basic rules"[2], there's a mention of no modifications
beside the ones related to the backport itself. Well, adding who did
the backport to the uploaders field is indeed related, right? :-)

> (please consider helping the current maintainer, and / or asking to be added 
> in uploaders, if you really want
> to maintain it)

I'm trying to help the maintainer with the package in unstable, but is
somewhat hard to reach him. Maybe my e-mails are getting bounced... I
don't know. I'll try to cc him again in this message.

> I'm sponsoring soon.
>
> thanks for your contribution to Debian!

Thank very much, as always, Gianfranco. You are really one of the best
sponsors out there!

[1]: http://backports.debian.org/Contribute/#index13h3
[2]: http://backports.debian.org/Contribute/#index7h3

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#814864: RFS: zbackup/1.4.4-1~bpo8+1

[Tiago Ilieve]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "zbackup"

* Package name: zbackup
  Version : 1.4.4-1~bpo8+1
  Upstream Author : Vladimir Stackov 
* URL : http://zbackup.org/
* License : GPL-2+-openssl
  Section : admin

It builds those binary packages:

  zbackup- Versatile deduplicating backup tool

To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/zbackup

Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/z/zbackup/zbackup_1.4.4-1~bpo8+1.dsc

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Including "orig.tar.gz" for upload with gbp/git-buildpackage

[Tiago Ilieve]

Gianfranco,

On 1 February 2016 at 11:36, Gianfranco Costamagna
 wrote:
> this is annoying for me too, but I usually keep them installed or I remove 
> them after
> sponsoring the package.
> (for uploading I use source-only if possible, pbuilder, or DebOMatic as 
> fallbacks)

If it annoys me having to install build-dependencies for the few
packages that I need, I can't imagine how this can be for someone like
you which reviews/sponsors so many (155 and counting) packages!

> this makes completely sense now, I wasn't aware of this trick

I do remember you saying one of theses days that still learn new
things about packaging everyday. :-)

> my pleasure!
> I remember myself something like one year ago asking the same question on irc 
> -mentors, and
> somebody else telling me about the tool ;)

Worth mentioning for anyone interested: the command "changestool" is
part of the package "reprepro".

Thanks,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Including "orig.tar.gz" for upload with gbp/git-buildpackage

[Tiago Ilieve]

Hi Gianfranco,

On 30 January 2016 at 06:25, Gianfranco Costamagna
 wrote:
> Hi,
>
> gbp buildpackage -S -sa works for me.
>
> Mentors strips binaries, so I don't understand why to call it with pbuilder :)

Mostly because using "USE_PDEBUILD_INTERNAL=yes" in "~/.pbuilderrc" I
don't have to install the build dependencies (which maybe
needed[1][2]) on the system itself, as it will take care of everything
on the chroot. Although I do have a machine which is reserved for
development only, I take care for what is installed on it.

That's also the reason why "gbp buildpackage -S -sa" (without
pbuilder) didn't worked for me.

> And in case you want to do a backport, where you have to include the orig 
> tarball, but pbuilder strips
> it (yes, it happens)
>
> "changestool package_version~bpo8+1_amd64.changes includeallsources"
>
> this is how I force the reinclusion of the source tarball.

That did the trick! Thank you very much, Gianfranco! :-)

> cheers,
>
> Gianfranco

Regards,
Tiago.

[1]: https://lists.debian.org/debian-mentors/2010/11/msg00333.html
[2]: 
http://blog.unixstyle.ru/125/osobennosti-pdebuild-i-dpkg-checkbuilddeps-unmet-build-dependencies/

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Including "orig.tar.gz" for upload with gbp/git-buildpackage

[Tiago Ilieve]

Hi,

I've tried to upload a backport to mentors.d.n a few moments ago and
it got rejected with the following error:

"If you tried to upload a package which only increased the Debian
revision part, make sure you include the full source (pass -sa to
dpkg-buildpackage)"

The manpage for "dpkg-buildpackage" says nothing about "-sa", but
"dpkg-genchanges(1)" says it "Forces the inclusion of the original
source", which makes total sense here. The problem is that I couldn't
find out how to pass "-sa" to "gpb".

The command used to build the package was:

sudo gbp buildpackage --git-pbuilder --git-dist=jessie

Which, as expected, didn't included the original sources. If I try to
add "-sa" (because the manpage for "git-buildpackage" says that it
will "Call debuild ... passing along all arguments given to gbp
buildpackage that don't start with --git-"), as in:

sudo gbp buildpackage -sa --git-pbuilder --git-dist=jessie

It fails:

(...)
I: Running /usr/bin/dpkg-buildpackage -rfakeroot -us -uc ${DEBBUILDOPTS}
dpkg-buildpackage: unknown option or argument '-sa'

Use --help for program usage information.
(...)
gbp:error: 'git-pbuilder -sa' failed: it exited with 1

The chapter "6.7. Command hierarchy"[1] of the Debian New Maintainers'
Guide states that "gbp buildpackage" is a wrapper around "gbp",
"pbuilder" and "dpkg-buildpackage". By default it should call
"debuild" (as it says on the excerpt from the manual above), but as
"--git-pbuilder" is being used, it is calling "pbuilder" instead. The
problem is that the chapter "9.2. Including orig.tar.gz for upload"[2]
doesn't have any mentions about how to use "-sa" with "pbuilder",
neither with "gbp".

Am I missing something here and this isn't really hard to do? The
entire stack and multiple levels of wrappers and their options being
passed from one to another confused me a lot.

Regards,
Tiago.

[1]: https://www.debian.org/doc/manuals/maint-guide/build.en.html#hierarchy
[2]: https://www.debian.org/doc/manuals/maint-guide/upload.en.html#option-sa

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Packaging an apparently unreleased Git repository

[Tiago Ilieve]

Jan,

On 28 January 2016 at 06:46, Jan Dittberner  wrote:
> Otherwise you should not just name the package 0.2.0-x but make sure that
> you include the git commit id like:
>
> 0.2.0~git20160116.1.fa5b38f-1
>
> This version will sort before a real 0.2.0 version:
>
> (...)
>
> This will allow you to properly package later upstream version when new
> commits occur. I came up with this suggestion after I had a look at the
> versions of packages installed on my system:

Although you did suggested a pretty detailed version string, this is
really needed at all? The Debian New Maintainers' Guide states[1]
that:

"... If you need to invent a version string, use the MMDD format
such as 20110429 as upstream version. This ensures that dpkg
interprets later versions correctly as upgrades. If you need to ensure
smooth transition to the normal version scheme such as 0.1 in future,
use the 0~YYMMDD format such as 0~110429 as upstream version,
instead."

This approach is simpler, work as intended and is documented on one of
our official guidelines for packaging.

Regards,
Tiago.

[1]: https://www.debian.org/doc/manuals/maint-guide/first.en.html#namever

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Packaging an apparently unreleased Git repository

[Tiago Ilieve]

Gert,

On 28 January 2016 at 15:49, Gert Wollny  wrote:
> Hello Tiago,
>
> Since git is a distributed VCS, a given date might not be sufficient to
> get the exact version, because some developer might edit the source off
> -line, and push changes on a later date to the remote repo, but the
> commits will carry the date when developer committed the changes to her
> local repo.
>
> Therefore, adding the commit sha is the only way to be sure that you
> correctly reference the source tree used to create a package. And
> adding a "git" somewhere in the version string makes sure that one
> knows how to interpret the version string properly :)

You're completely right. I've not considered the "late push" use case,
which can happen even in a perfect-linear-and-rebased tree, resulting
in "newer" (at least appearing to be most recent in the tree) commits
with older dates.

Thanks,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Making a package that amounts to GBs of .wavs data?

[Tiago Ilieve]

Hi Victor and Gianfranco,

There was some related discussion here about downloader packages[1] a
couple months ago. I guess a separate package for downloading the drum
kits recordings, which can be added as dependency for either DrumGizmo
and Beast, would fit this use case.

Regards,
Tiago.

[1]: https://lists.debian.org/debian-mentors/2015/08/msg00208.html


-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro/
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil