Bug#1037914: cloud-initramfs-growroot: missing dependencies in initramfs

[Tiago Ilieve]

Control: tags -1 patch

Hi,

I've managed to reproduce the original report after adding 'debug' to the
kernel command line and checking "/run/initramfs/initramfs.debug"[1].

A patch was sent to the "cloud-team/cloud-initramfs-tools" Salsa repository[2].

Regards,
Tiago.

[1]: https://wiki.debian.org/InitramfsDebug#Saving_debug_information
[2]: 
https://salsa.debian.org/cloud-team/cloud-initramfs-tools/-/merge_requests/8

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

Bug#877001: should be in contrib since it requires GitHub API

[Tiago Ilieve]

Hans-Christoph,

On 28 September 2017 at 15:29, Hans-Christoph Steiner  wrote:
> As far as I know, there is no restriction on moving this package to
> non-free right now.  It clearly does not meet the criteria for being in
> main:
>
> * grip requires GitHub's proprietary API to do anything useful
> * without the proprietary service, grip is useless
>
> Either non-free or contrib works for this, in my opinion. I don't really
> care which, just not main.

Yes, there is a restriction: software should not be moved to
contrib/non-free because some wants, but because they are not
DFSG-compliant[1][2]. As far as we can tell, grip is indeed free
software, released under MIT/Expat license[3].

It can even be used without GitHub.com, specifying the URL of a GitHub
Enterprise instance[4]. And yes, if you have a free implementation of
the GitHub API, you can point it to your own server. If you want to
argue that maybe there are no free implementations of the GitHub API,
this is not grip's fault. Even then, if you don't agree with this
relationship between free software and proprietary services, you
should be discussing the matter with the people on the previous
mentioned thread[5], who are interested in this matter, not with me in
this bug report.

As you said, this is *your* opinion and, will all due respect, it's
not stronger or more important than the people on debian-mentors
mailing list or the FTP masters who reviewed the package before it
entered the archive, accepting it in the main section.

Regards,
Tiago.

[1]: https://www.debian.org/social_contract
[2]: https://wiki.debian.org/SourcesList#Component
[3]: https://github.com/joeyespo/grip/blob/bae3d0a/LICENSE
[4]: https://github.com/joeyespo/grip/tree/bae3d0a#configuration
[5]: https://lists.debian.org/debian-devel/2017/08/msg00306.html

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://de.linkedin.com/in/myhro
Berlin, Deutschland

Bug#877001: should be in contrib since it requires GitHub API

[Tiago Ilieve]

Hi Hans-Christoph,

On 27 September 2017 at 17:19, Hans-Christoph Steiner  wrote:
> Thanks for packaging grip, its useful.  But I think its not properly
> represented in Debian.  It seems to only work via the GitHub API, which
> is not free software.  Therefore it should be in 'contrib' not 'main'.

There was a discussion[1] on whether proprietary remote services
should be considered non-free software last month. I didn't followed
it entirely (actually, the discussion was so repetitive and annoying
that it made me unsubscribe from debian-devel), but as far as I
remember, there was no consensus at all. I'm also not sure if the
Debian Technical Committee (CTTE) was called to rule on the matter.
Therefore, I cannot move the package to contrib based on your request.

> Since I just got the GitHub rate limit page, I assume it is uploading
> the markdown files to GitHub.  This should also be documented.

The description of the package is clear, stating that it is an
"application written in Python that uses the GitHub markdown API to
render a local readme file"[2]. I, as a developer, know that this
means that data will be transferred to and from a proprietary service
- that's the price to pay for using public APIs like this. But at the
same time, while not sure if this will be clear for a non-technical
user, this hypothetical person who is not a developer would probably
not be using this package?

This matter a little more complicated than it seems - and concerns
like this are becoming more and more prevalent. Hope we can get more
productive feedback on this bug report.

Regards,
Tiago.

[1]: https://lists.debian.org/debian-devel/2017/08/msg00306.html
[2]: https://packages.debian.org/sid/grip

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://de.linkedin.com/in/myhro
Berlin, Deutschland

Bug#871835: speed up for debootstrap

[Tiago Ilieve]

Hi Thomas,

Do you mind to share how you identified those slower parts of the
code? Have you used a profiler or a similar tool?

I must say that I'm very impressed by your patches. :-)

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://de.linkedin.com/in/myhro
Berlin, Deutschland

Bug#868875: cloud-init growpart fails to grow root volumes larger than 256GiB

[Tiago Ilieve]

control: reassign -1 cloud-utils

Hi Steffen,

I was able to reproduce the bug and the logs follows as attachments.
This report being reassigned because it is not a bug on "cloud-init"
itself, but on "cloud-utils", as "growpart" is part of the later.

I think this may be related to the the "util-linux" version on Jessie,
as the problem is not present on Stretch (and the cloud-utils versions
on Jessie-Backports, used in the AMI, and Stretch are the same).
Anyway, I'm not sure and couldn't find the root cause yet, but this is
a known problem for at least a few months[1][2].

Any help in this regard is appreciated.

Regards,
Tiago.

[1]: https://stackoverflow.com/q/39920638
[2]: https://github.com/andsens/bootstrap-vz/issues/359

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://de.linkedin.com/in/myhro
Berlin, Deutschland


growpart-cli.log
Description: Binary data


growpart-cloud-init.log
Description: Binary data

Bug#864679: grip: does not work at all

[Tiago Ilieve]

control: retitle -1 grip: hangs when exporting to file

Hi Thorsten,

Indeed, the export function is hanging. I can't take a look at it
right now, but I'll do soon as possible. We'll probably have to ask
for a stable-update to get this fixed in Stretch.

Thanks for your report,
Tiago.

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

Bug#846526: cloud-init: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Tiago Ilieve]

Hi Marcin,

On 3 December 2016 at 18:25, Marcin Kulis  wrote:
> I had a quick looks into file you've provided and the PT translation we 
> already
> have. I have some questions (sorry in advance if those are lame but I don't
> understand Portuguese almost at all).
> Are those two really so different? pt_BR.po looks slightly different but not 
> so
> much and for example line 102 for me looks like is not translated at all, do
> you want to keep it that way?
>
> If you're really happy with this po file I'll add it to the package and it
> probably will find it's way into the next cloud-init release.

As you may guess, I'm a native Portuguese speaker. The differences
between the original Portuguese (from Portugal) and Brazilian
Portuguese may be very subtle, which looks like to be the case here.

I've analyzed the diff[1] between `pt.po` and `pt_BR.po` and, although
there are lines that really should be translated to make sense for
Brazilian users, there are some which I'm not sure if they are
properly translated. I never really did a Portuguese -> Brazilian
Portuguese translation, so I may be biased to think that some
sentences should (or shouldn't) be changed.

-

Adriano,

Were this translation reviewed by debian-l10n-portuguese@l.d.o (I do
not follow that list)? I'll not suggest any changes here, as I do not
know how the translation team works. If they reviewed it indeed, we
can certainly include this file for the next release.

Regards,
Tiago.

[1]: https://paste.debian.net/900453/

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

Bug#832284: [Pkg-fonts-devel] Bug#832284: closed by Hideki Yamane <henr...@debian.org> (Bug#832284: fixed in octicons 4.3.0-1)

[Tiago Ilieve]

Hideki,

On 11 August 2016 at 13:40, Hideki Yamane  wrote:
>  Q: Only needs octicons.svg as 
> /usr/share/fonts/web-fonts/octicons/octicons.svg?

Yes, for the grip package use-case this is the file I need. Maybe
other packages can benefit from the "svg" folder with multiple files,
but I can't say for sure.

Regards,
Tiago.

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

Bug#832284: closed by Hideki Yamane <henr...@debian.org> (Bug#832284: fixed in octicons 4.3.0-1)

[Tiago Ilieve]

Hi Hideki,

Thanks for taking care of this bug report. The "woff2" file looks OK,
but the "svg" one doesn't. Instead of a
"/usr/share/fonts/web-fonts/octicons/octicons.svg" link to a file,
there's a "/usr/share/fonts/web-fonts/octicons/svg" linking to a
"../../svg/octicons" directory, which contains lots of "*.svg" files.
I was expecting something like this[1] in its place.

Can you please take a look at why this happened?

Regards,
Tiago.

[1]: 
https://raw.githubusercontent.com/joeyespo/grip/v4.3.2/grip/static/octicons/octicons.svg

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

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

Bug#832000: grip: new upstream release (4.3.2)

[Tiago Ilieve]

control: block -1 by 832284
thanks

Jakub,

Unfortunately this update is currently blocked by #832284[1] (missing
Octicons webfont formats). I'll proceed as soon as it is fixed.

Regards,
Tiago.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832284

-- 
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#832284: octicons: please include 'svg' and 'woff2' formats

[Tiago Ilieve]

Package: octicons
Version: 3.5.0-1
Severity: normal

Hi,

I'm updating the "grip" package (bug #832000[1]) to a version that
includes embedded copies of Octicons webfonts. Those files have to be
substituted by symlinks to their equivalent files from the "octicons"
package.

The problem is that, looking at the "octicons" package file list[2],
files "octicons.svg" and "octicons.woff2", which are used upstream[3],
aren't available. Is there a possibility to include both "svg" and
"woff2" formats as well?

Regards,
Tiago.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832000
[2]: https://packages.debian.org/sid/all/octicons/filelist
[3]: https://github.com/joeyespo/grip/tree/v4.3.2/grip/static/octicons

Bug#832159: ITP: qutebrowser -- A keyboard-driven, vim-like browser based on PyQt5.

[Tiago Ilieve]

Hi Fritz,

On 22 July 2016 at 21:15, Fritz Reichwald  wrote:
> I also intend to package the dependency python3-pypeg2 do I have to write a 
> seperate
> ITP for it?

Yes, please. Doesn't matter if it is a dependency for this one. Every
new package should close an ITP bug.

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#832071: pristine-tar: pristine-gz cannot reproduce build of

[Tiago Ilieve]

Package: pristine-tar
Version: 1.33
Severity: normal

Hi,

When updating the "cloud-utils" package, the following warning was
shown:

$ pristine-tar commit ../cloud-utils_0.29.orig.tar.gz upstream
warning: pristine-gz cannot reproduce build of ../cloud-utils_0.29.orig.tar.gz; 
storing 89% size diff in delta
(Please consider filing a bug report so the delta size can be improved.)
pristine-tar: committed cloud-utils_0.29.orig.tar.gz.delta to branch 
pristine-tar

I've also tested the last version (1.34) from unstable and the result
was the same. The deltas from previous versions had 1.6KB and 1.7KB.
This one[1] reached 50KB[2].

I don't know if this is relevant or not, but that was the first repackaged
tarball from upstream (using "Files-Excluded"[3]). There were some files
under ".bzr/" folder that had to be removed.

Regards,
Tiago.

P.s.: this looks to be the same bug as #540747 and #750215. Maybe those
can be merged?

[1]: 
http://http.debian.net/debian/pool/main/c/cloud-utils/cloud-utils_0.29.orig.tar.gz
[2]: 
https://anonscm.debian.org/git/collab-maint/cloud-utils.git/tree/?h=pristine-tar=7369ba6
[3]: 
https://anonscm.debian.org/git/collab-maint/cloud-utils.git/commit/?id=b340e49

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Versions of packages pristine-tar depends on:
ii  libbz2-1.0  1.0.6-7+b3
ii  libc6   2.19-18+deb8u4
ii  perl5.20.2-3+deb8u5
ii  tar 1.27.1-2+b1
ii  xdelta  1.1.3-9.1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages pristine-tar recommends:
ii  bzip2 1.0.6-7+b3
ii  pbzip21.1.9-1
ii  xz-utils  5.1.1alpha+20120614-2+b3

pristine-tar suggests no packages.

-- no debconf information

Bug#832000: grip: new upstream release (4.3.2)

[Tiago Ilieve]

Hi Jakub,

I'm working on it since yesterday. Hope to have an updated package soon.

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#829522: glances: crashes when checking processes that already finished

[Tiago Ilieve]

Daniel,

On 3 July 2016 at 23:32, Daniel Echeverry  wrote:
> Thanks for the report!

You're welcome.

> Could you test if the crash persists with last version in unstable [1]?

Actually I can't even reproduce the problem on stable on purpose. I'll
have to figure what kind of workflow triggers this condition. Running
both versions from Jessie and Sid (on different Docker containers)
overnight didn't helped (as their process namespace are minimal).

I'll update the bug report when possible.

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#829522: glances: crashes when checking processes that already finished

[Tiago Ilieve]

Package: glances
Version: 2.1.1-1
Severity: important

Hi Daniel and Sebastien,

Sometimes, when I left glances running for a while (can't say exactly,
but at least a few minutes) it crashes showing the following exceptions:

-8<-

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/psutil/_pslinux.py", line 694, in wrapper
return fun(self, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/psutil/_pslinux.py", line 724, in name
f = open(fname, "rt", encoding=DEFAULT_ENCODING)
  FileNotFoundError: [Errno 2] No such file or directory: '/proc/672/stat'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
 File "/usr/bin/glances", line 9, in 
   load_entry_point('Glances==2.1.1', 'console_scripts', 'glances')()
 File "/usr/lib/python3/dist-packages/glances/__init__.py", line 121, in main
   standalone.serve_forever()
 File "/usr/lib/python3/dist-packages/glances/core/glances_standalone.py", line 
71, in serve_forever
   self.stats.update()
 File "/usr/lib/python3/dist-packages/glances/core/glances_stats.py", line 130, 
in update
   self.__update__(input_stats)
 File "/usr/lib/python3/dist-packages/glances/core/glances_stats.py", line 121, 
in __update__
   self._plugins[p].update()
 File "/usr/lib/python3/dist-packages/glances/plugins/glances_processcount.py", 
line 55, in update
   glances_processes.update()
 File "/usr/lib/python3/dist-packages/glances/core/glances_processes.py", line 
324, in update
   standard_stats=self.get_max_processes() is None)
 File "/usr/lib/python3/dist-packages/glances/core/glances_processes.py", line 
149, in __get_process_stats
   procstat.update(proc.as_dict(attrs=['cpu_percent', 'memory_percent', 
'name'], ad_value=''))
 File "/usr/lib/python3/dist-packages/psutil/__init__.py", line 414, in as_dict
   ret = attr()
 File "/usr/lib/python3/dist-packages/psutil/__init__.py", line 490, in name
   name = self._proc.name()
 File "/usr/lib/python3/dist-packages/psutil/_pslinux.py", line 704, in wrapper
   raise NoSuchProcess(self.pid, self._name)
 psutil.NoSuchProcess: process no longer exists (pid=672)

-8<-

Looks like it crashes when looking for information about a process that
already finished. It also messes the terminal (/bin/bash), needing a
"reset" command or closing it and opening a new one (but I guess this is
expected when a curses-based tool isn't properly finished).

Regards,
Tiago.

P.s.: Thanks for you work adopting this package a few months ago. It is a
really useful monitoring tool.


-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages glances depends on:
ii  adduser3.113+nmu3
ii  lsb-base   4.1+Debian13+nmu1
ii  python33.4.2-2
ii  python3-pkg-resources  5.5.1-1
ii  python3-psutil 2.1.1-1+b1
pn  python3:any

Versions of packages glances recommends:
ii  hddtemp  0.3-beta15-52
ii  lm-sensors   1:3.3.5-2
ii  python3-bottle   0.12.7-1
ii  python3-jinja2   2.7.3-1
ii  python3-pysnmp4  4.2.5-1

glances suggests no packages.

-- no debconf information

Bug#827144: grip manpage: undocumented $GRIPHOME

[Tiago Ilieve]

Hi Jakub,

On 12 June 2016 at 17:53, Jakub Wilk  wrote:
> Package: grip
> Version: 4.2.0-2
>
> Please document the GRIPHOME environment variable in the manual page.

Sorry for taking a few weeks to deal with something so simple, but
this is now fixed in Git[1]. I've already asked Mattia Rizzolo, which
is the package sponsor, to upload this newer version when possible.

Thanks for your report.

Regards,
Tiago.

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

-- 
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#821296: [rt.debian.org #6237] AutoReply: Please add Tiago Ilieve's key to the DM keyring

[Tiago Ilieve]

Hi Anibal,

On 26 May 2016 at 05:17, Aníbal Monsalve Salazar <ani...@debian.org> wrote:
> Hello Tiago Ilieve,
>
> Your DM application was accepted and the corresponding RT ticket is
> posted at https://rt.debian.org/Ticket/Display.html?id=6237
>
> Currently, rt.debian.org isn't accessible for the general public. It
> was so sometime ago. Maybe one of your advocates will look at your RT
> ticket for you, after it has been taken by a keyring maintainer. See
> http://wiki.debian.org/rt.debian.org

There's no problem. I'll wait until it is published on the "Debian
Maintainers Keyring changes" report that is usually sent to
"debian-project" mailing list. Hopefully on the next one.

If this doesn't happens, I'll then ask one of my advocates to help me
find out if something happened to the RT ticket.

> Not urgent but please try to get more OpenPGP signatures from DDs and
> sign theirs keys as well. :-)

This is on my TODO list. Unfortunately I won't be at the next DebConf
in Cape Town to attended its keysigning party[1], but I'll try to
reach other DDs. I know one who lives close to my home town, but I
haven't seen him in over a year.

And, of course, I have some signatures from DMs that will eventually
become DDs in the next months/years.

> Thank you for your contribution to the Debian Project.

You're welcome. :-)

Regards,
Tiago.

[1]: https://people.debian.org/~anibal/ksp-dc16/ksp-dc16.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#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

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#821175: naming conflict to grip the cd ripper

[Tiago Ilieve]

Harald,

On 17 April 2016 at 09:41, Harald Dunkel  wrote:
> This is not about a conflict of the package name, but about
> the config file/directory. Surely I wasn't the only one who
> had used grip the CD ripper a long time ago. Closing the
> report won't make the conflict in the user's $HOME go away.
> At least your grip should show a readable error message, even
> if it is Python.
>
> Please reopen.

I do understood the problem. But see, what is being reported is that a
packaged application has its configuration file names clashing with a
software that is isn't part of Debian anymore. I can't even forward
this bug to the upstream, because how one can argue about fixing a
conflict with a software that was abandoned over 10 years ago?

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#821296: debian-maintainers: Please add Tiago Ilieve as a Debian Maintainer

[Tiago Ilieve]

Package: debian-maintainers
Severity: normal

Hi,

Please add Tiago Ilieve <tiago.my...@gmail.com> to the Debian
Maintainers keyring.

The jetring changeset (add-06C285ACEF93257A) is attached.

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


add-06C285ACEF93257A
Description: Binary data

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#788527: pyro4: new upstream available

[Tiago Ilieve]

Hi,

On Fri, 12 Jun 2015 14:15:59 +0200 (CEST) ydir...@free.fr wrote:
> The version in sid is quite old now, and the online docs describe very
> useful features... that are simply not available in that old version.

Yup. 4.23 is over two years old now. I have a package that its server
component fails with "AttributeError: 'Configuration' object has no
attribute 'REQUIRE_EXPOSE'" because of the outdated Pyro4 library. :-(

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

Bug#820607: bootstrap-vz: upstream changelog is almost empty

[Tiago Ilieve]

Hi Olivier,

On Sun, 10 Apr 2016 15:43:02 +0200 Olivier Berger
 wrote:
> Hi.
>
> The upstream changleog provided in /usr/share/doc/bootstrap-vz/changelog.gz 
> is almost empty and quite useless :
>
> .. include:: ../CHANGELOG.rst
>
> Hope this helps.

Thanks for spotting this. It is now fixed in Git[1] and we'll be
releasing a new version of the package soon.

Regards,
Tiago.

[1]: 
https://anonscm.debian.org/git/cloud/bootstrap-vz.git/commit/?id=4f1cabb4bc5049580ad010e55de7555c065062c1

-- 
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

Bug#820685: zbackup: packaging improvements

[Tiago Ilieve]

Package: zbackup
Version: 1.4.4-1
Severity: wishlist

Hi Laszlo,

I've made a few improvements to the zbackup packaging, which are on
this GitHub repository[1]. As the package doesn't looks to have
already being managed with Git, the older versions were imported with
"gbp import-dscs --debsnap". Here's the summary of the changes:

zbackup (1.4.4-2) UNRELEASED; urgency=medium

  * Add myself to Uploaders.
  * Add 'fix_version_string.patch'.
  * Bump Standards-Version to 3.9.7 (no change).
  * Convert README.md to HTML (Debian Policy Manual § 12.4 "Preferred
documentation formats"):
- Add 'debian/clean', update 'debian/docs'.
- Add 'remove_external_travisci_img.patch'.
  * debian/control:
- Add 'discount' ('mkd2html' command) to build dependencies.
- wrap-and-sort.
  * debian/copyright:
- Add myself for 'debian/*' files.
- Bump Laszlo Boszormenyi copyright to 2016.
- wrap-and-sort.
  * debian/rules:
- Add hardening (fixes 'hardening-no-pie' and 'hardening-no-bindnow').
- Add 'override_dh_auto_build'.

 -- Tiago Ilieve <tiago.my...@gmail.com>  Mon, 11 Apr 2016 07:18:42 -0300

As there are some intrusive changes, like adding myself to Uploaders,
I haven't put the package on Debian infrastructure (like mentors.d.n
or collab-maint). If you like and accept them, is a matter of marking
it for release in unstable and pushing it to collab-maint - which I
can do as well. I'll only need the upload to be sponsored.

P.s.: is there an easier way to reach you than BTS? I've tried to
contact you by e-mail more than one time with no luck. If you are
extremely busy outside Debian and willing to give some packages up to
adoption, I volunteer to take this one and ask for sponsorship from
another DD.

Regards,
Tiago.

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

-- 
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

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

Bug#820020: marked as pending

[Tiago Ilieve]

Hi Ondrej,

On 4 April 2016 at 17:14, Ondřej Nový  wrote:
> Hello,
>
> Bug #820020 reported by you has been fixed in the Git repository. You can
> see the changelog below, and you can check the diff of the fix at:

Thank you very much the very quick response! :-)

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#820020: python3-responses: Please update the package to a new upstream version

[Tiago Ilieve]

Package: python3-responses
Version: 0.3.0-1
Severity: important

Hi Simon,

The current version in sid, 0.3.0-1 as I'm writing this bug report, is
nearly one and a half years old. This prevents packages like Grip[1]
(ITP #790611[2]) from running its tests, as it requires at least the
version 0.5.0, released on 14 Oct 2015[3], exactly one year after this
one[4].

Regards,
Tiago.

[1]: https://github.com/joeyespo/grip
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790611
[3]: https://github.com/getsentry/responses/tags
[4]: 
http://metadata.ftp-master.debian.org/changelogs/main/r/responses/responses_0.3.0-1_changelog

Bug#819703: xscreensaver: please disable "This version of XScreenSaver is very old! Please upgrade!" message

[Tiago Ilieve]

Hi Yves-Alexis,

On Fri, 01 Apr 2016 21:26:23 +0200 Yves-Alexis Perez  wrote:
> Right now, there's a way to switch to something else, which is light-locker,
> so it might be a good idea to do that indeed. I'll update the tasksel package
> with that in mind.

Indeed. For someone who uses Xfce and rely on xscreensaver only for
locking, it's a matter of switching to light-locker and uncommenting
the line "greeter-hide-users=false" in "/etc/lightdm/lightdm.conf".
This way it behaviors in a way pretty close to the former.

Thanks for the suggestion.

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#819806: ITP: ntpsec - a secure, hardened and improved ntp daemon

[Tiago Ilieve]

Hi Kurt,

On 2 April 2016 at 11:15, Kurt Roeckx  wrote:
> I don't actually have the time to work on this currently, but it's
> clearly something I want.

Wouldn't be better to fill an RFP, then take it as ITP when you are
available, if no one works on this in the mean time?

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

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#790612: ITP: python-path-and-address -- Functions for server CLI applications used by humans.

[Tiago Ilieve]

control: owner -1 !

Hi Gustavo,

I'm taking the ownership of this ITP bug too, as we talked about
packaging Grip[1] in #790611.

Regards,
Tiago.

[1]: https://github.com/joeyespo/grip
[2]: 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

Bug#819756: ITP: python-path-and-address -- Functions for command-line server tools used by humans

[Tiago Ilieve]

Package: wnpp
Severity: wishlist
Owner: Tiago Ilieve <tiago.my...@gmail.com>

* Package name: python-path-and-address
  Version : 1.0.0
  Upstream Author : Joe Esposito <j...@joeyespo.com>
* URL : https://github.com/joeyespo/path-and-address
* License : MIT
  Programming Lang: Python
  Description : Functions for command-line server tools used by humans

Path-and-address resolves ambiguities for command-line interface applications
with the following pattern:

$ your_app [] []

The library applies the principal of least surprise to command-line interfaces.

Some examples:

$ your_app .
 * Serving . on http://localhost:5000/

$ your_app 80
 * Serving . on http://localhost:80/

$ your_app ./80
 * Serving ./80 on http://localhost:5000/

$ your_app path/to/file
 * Serving path/to/file on http://localhost:5000/

$ your_app 0.0.0.0
 * Serving 0.0.0.0 on http://localhost:5000/

$ your_app . 0.0.0.0
 * Serving . on http://0.0.0.0:5000/

$ your_app 0.0.0.0:8080
 * Serving . on http://0.0.0.0:8080/

-

This library is a dependency of Grip[1], which is being packaged in ITP bug
#790611[2].

I plan to maintain it alone, but will evaluate joining Debian Python Modules
Team (DPMT) in the process.

Regards,
Tiago.

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

Bug#790611: ITP: python-grip -- Grip -- GitHub Readme Instant Preview

[Tiago Ilieve]

control: owner -1 !

Gustavo,

On 1 April 2016 at 06:19, Gustavo Panizzo  wrote:
> I'm interested on having it on Debian, unfortunately I won't have time
> to work on it in the near future, feel free to take this ITP

Thanks for the feedback! I'm taking the ownership of this ITP.

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#790611: ITP: python-grip -- Grip -- GitHub Readme Instant Preview

[Tiago Ilieve]

Hi Gustavo,

How the packaging work is going? Are you still working on it? Looks
like the missing dependencies right now are "path-and-address"[1] and
"responses"[2].

I'm interested in seen this package in Debian as well. Let me know how
(and if) we can work together on this.

Regards,
Tiago.

[1]: https://github.com/joeyespo/grip/blob/efb2539/requirements.txt
[2]: https://github.com/joeyespo/grip/blob/efb2539/requirements-test.txt

-- 
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

Bug#817856: ITP: pythonpy -- 'python -c', with tab completion and shorthand

[Tiago Ilieve]

Package: wnpp
Severity: wishlist
Owner: Tiago Ilieve <tiago.my...@gmail.com>

* Package name: pythonpy
  Version : 0.4.4
  Upstream Author : Russell Stewart <russell.s.stew...@gmail.com>
* URL : https://github.com/Russell91/pythonpy
* License : MIT
  Programming Lang: Python
  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 anything from simple arithmetic to complex operations,
importing modules automatically. It also comes with tab completion.

Its usage is not restricted to single expressions only. There's also the
possiblity to pipe data from stdin and to stdout, even generating
strings to be evaluated by other programs.

-

I plan to maintain this package by myself, as it is pretty simple. I'll
certainly reach the Python Applications Packaging Team (PAPT) in the
future if needed.

Bug#815760: (no subject)

[Tiago Ilieve]

retitle 815760 ITP: dpdk -- Data Plane Development Kit
thanks

Hi Christian,

I'm setting the title for your ITP because you left the "Subject:"
line in the message body.

As I'm also not a DD, I can't help you with the sponsorship. Hope you
find someone interested!

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#815110: tracker.debian.org: please use plain images (rather than web fonts) as icons

[Tiago Ilieve]

Hi,

Worth mentioning that GitHub itself has stopped using icon fonts,
delivering Octicons with SVG[1]. They even figured that using SVG is
actually (a little bit) faster than the previous approach.

Regards,
Tiago.

[1]: https://github.com/blog/2112-delivering-octicons-with-svg

-- 
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#814863: Backport of zbackup

[Tiago Ilieve]

Hi Laszlo,

On 16 February 2016 at 07:33, László Böszörményi (GCS)  wrote:
>  Ouch. I remember a mail, but it seems it got lost somewhere. Didn't
> get the other. :(

No problem. I'll also forward the first e-mail that I sent you because
there was some questions about the package repository, OK?

> Anyway, feel free to do the backport and if you still need a mentor
> for that, just ask.

Thank you. And yes, I do need help with that. There's an RFS bug #814864[1].

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814864

-- 
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

Bug#814863: zbackup: backport request

[Tiago Ilieve]

Package: zbackup
Version: 1.3-1
Severity: wishlist

Dear Maintainer,

I have proposed a backport[1] for zbackup, but haven't received an ACK
from you[2]. Gianfranco Costamagna suggested[3] this bug report so we
can propely track this issue.

The main reason for this is that the version in Jessie lacks the
garbage collector (GC) which is available in in the version in
Stretch. This allows the removal of previously made backups.

Regards,
Tiago.

[1]: https://lists.debian.org/debian-backports/2016/02/msg6.html
[2]: https://lists.debian.org/debian-backports/2016/02/msg00014.html
[3]: https://lists.debian.org/debian-backports/2016/02/msg00035.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#784673: cloud-utils: growpart fails with gpt

[Tiago Ilieve]

Hi Charles,

On 11 February 2016 at 11:19, Charles Plessy  wrote:
> Hi Tiago,
>
> this reminded your request for sponsoring the backport of cloud-utils; I just
> uploaded it.  (Build logs attached for the record).

This is awesome. Thank you very much!

It is on the NEW queue[1] right now. :-)

[1]: https://ftp-master.debian.org/backports-new.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#784673: cloud-utils: growpart fails with gpt

[Tiago Ilieve]

Hi Frederic,

I've tried to reproduce this issue using cloud-utils (0.26-2) on Jessie:

root@virtualbox:~# growpart -v /dev/sda 1
geometry is -C 2610 -H 255 -S 63. total size=41929650
max_end=41929650 tot=41929650 pt_end=41943040 pt_start=1 pt_size=41943039
NOCHANGE: partition 1 could only be grown by -13390 [fudge=20480]

And the output was a little bit different, but the result is the same,
as it could not grow the partition.

Then I've tried using cloud-utils (0.27-2) from Stretch on Jessie:

root@virtualbox:~# growpart -v /dev/sda 1
update-partition set to true
FAILED: GPT partition found but no sgdisk

And after installing "gdisk":

root@virtualbox:~# growpart -v /dev/sda 1
update-partition set to true
found GPT partition table (id = ee)
disk=/dev/sda partition=1: original sgdisk info:
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 4F846BCA-2671-486C-AFD7-6DBA157FDDD1
First sector: 2048 (at 1024.0 KiB)
Last sector: 15624191 (at 7.5 GiB)
Partition size: 15622144 sectors (7.4 GiB)
Attribute flags: 
Partition name: ''
Disk /dev/sda: 41943040 sectors, 20.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): D9C74796-7ED9-49AA-84C7-808685BC8ED7
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 41943006
Partitions will be aligned on 2048-sector boundaries
Total free space is 26320829 sectors (12.6 GiB)

Number  Start (sector)End (sector)  Size   Code  Name
   1204815624191   7.4 GiB 8300
disk=/dev/sda partition=1: pretend sgdisk info
Disk /dev/sda: 41943040 sectors, 20.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): D9C74796-7ED9-49AA-84C7-808685BC8ED7
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 41943006
Partitions will be aligned on 2048-sector boundaries
Total free space is 26320829 sectors (12.6 GiB)

Number  Start (sector)End (sector)  Size   Code  Name
   1204815624191   7.4 GiB 8300
disk=/dev/sda partition=1: pt_start=2048 pt_end=15624191
pt_size=15622143 pt_max=41943006 last=41943006
disk=/dev/sda partition=1: code=0FC63DAF-8483-4772-8E79-3D69D8477DE4
guid=4F846BCA-2671-486C-AFD7-6DBA157FDDD1 name=''
CHANGED: disk=/dev/sda partition=1: start=2048 old:
size=15622143,end=15624191 new: size=41940958,end=41943006

Everything went fine and "resize2fs" is now able to expand the filesystem:

root@virtualbox:~# resize2fs /dev/sda1
resize2fs 1.42.12 (29-Aug-2014)
Filesystem at /dev/sda1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/sda1 is now 5242619 (4k) blocks long.

root@virtualbox:~# df -h | grep sda1
/dev/sda120G  951M   18G   5% /

Then I've restored a snapshot, upgraded the machine to sid/unstable
and tried again.

Using cloud-utils (0.27-2) from Sid:

root@virtualbox:~# growpart -v /dev/sda 1
update-partition set to true
found MBR partition table (id = 0FC63DAF-8483-4772-8E79-3D69D8477DE4)
total number of sectors of /dev/sda is 41943040
## sfdisk --dump /dev/sda
label: gpt
label-id: D9C74796-7ED9-49AA-84C7-808685BC8ED7
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 41943006

/dev/sda1 : start=2048, size=15622144,
type=0FC63DAF-8483-4772-8E79-3D69D8477DE4,
uuid=4F846BCA-2671-486C-AFD7-6DBA157FDDD1
max_end=41943040 tot=41943040 pt_end=15624192 pt_start=2048 pt_size=15622144
attempt to resize /dev/sda failed. sfdisk output below:
| The last usable GPT sector is 41943006, but 41943039 is requested.
| Failed to add partition: Invalid argument
| Backup files:
| PMBR (offset 0, size   512):
/tmp/growpart.YN5dSL/backup-sda-0x.bak
|   GPT Header (offset   512, size   512):
/tmp/growpart.YN5dSL/backup-sda-0x0200.bak
|  GPT Entries (offset  1024, size 16384):
/tmp/growpart.YN5dSL/backup-sda-0x0400.bak
|
| Disk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 sectors
| Units: sectors of 1 * 512 = 512 bytes
| Sector size (logical/physical): 512 bytes / 512 bytes
| I/O size (minimum/optimal): 512 bytes / 512 bytes
| Disklabel type: gpt
| Disk identifier: D9C74796-7ED9-49AA-84C7-808685BC8ED7
|
| Old situation:
|
| Device Start  End  Sectors  Size Type
| /dev/sda1   2048 15624191 15622144  7.5G Linux filesystem
|
| >>> Script header accepted.
| >>> Script header accepted.
| >>> Script header accepted.
| >>> Script header accepted.
| >>> Script header accepted.
| >>> Script header accepted.
| >>> Created a new GPT disklabel (GUID: D9C74796-7ED9-49AA-84C7-808685BC8ED7).
| Leaving.
|
FAILED: failed to resize
* WARNING: Resize failed, attempting to revert **
512+0 records in
512+0 records out
512 bytes copied, 0.00159423 s, 321 kB/s
* Appears to have gone OK 

The partition could not be grown and now "resize2fs" can't do anything:

root@virtualbox:~# resize2fs /dev/sda1
resize2fs 1.42.13 (17-May-2015)
The filesystem is already 1952768 (4k) blocks 

Bug#813493: cloud.debian.org: [AWS] Debian Jessie 8.1 images lack root partition grow

[Tiago Ilieve]

Zied,

On 2 February 2016 at 18:42, Zied ABID  wrote:
> Hi Tiago,
>
> Thank you for this useful informations.

You're welcome.

> I'll try to contact James Bromberger as he is mentioned as the AWS images
> maintainer at [6].

Worth mentioning that he follows the "debian-cloud" mailing list,
which those bug reports are forwarded to. So he will probably see our
messages and answer when the time permits.

-- 
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#813493: cloud.debian.org: [AWS] Debian Jessie 8.1 images lack root partition grow

[Tiago Ilieve]

Hi Zied,

On 2 February 2016 at 12:03, Zied ABID  wrote:
> Package: cloud.debian.org
> Severity: normal
> Tags: newcomer
>
> Dear Maintainer,
>
>
>* What led up to the situation?
> Create new instance from one of the official Debian Jessie 8.1 images
> (https://wiki.debian.org/Cloud/AmazonEC2Image/Jessie)
>* What exactly did you do (or not do) that was effective (or ineffective)?
> Create instance with a volume other than the default size (8GB), say 30GB.
>* What was the outcome of this action?
> Root partition still at size 8GB in front of 30GB (EBS) volume size.
>* What outcome did you expect instead?
> Root partition should be resized as same as (EBS) volume.
>
>
> This bug is reproducible in at least 2 tested images (in eu-west-1 and
> us-west-1)
> This bug affect only Jessie 8.1 images, Wheezy images looks fine.
>
> As a work-around, installing cloud-initramfs-growroot package resolve the 
> issue
> for installed instances (after reboot) or for new instances created from 
> nested
> image.

This is a known issue, which is related to #784004[1]. We are already
tackling it on threads[2][3] at the "debian-cloud" mailing list.

> PS: If you consider this issue as a bug, I'm available to reproduce, test and
> validate new AWS images. I'm already looking at Anders Ingemann's bootstrap-vz
> work to find-out how to suggest a patch, but I'm not sure that I'm on the 
> right
> path.

Patches[4][5] were suggested to bootstrap-vz and the most recent one
was merged. What happened is, AFAICT, there were no newer EC2 images
generate using those fixes.

Regards,
Tiago.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784004
[2]: https://lists.debian.org/debian-cloud/2016/01/msg00035.html
[3]: https://lists.debian.org/debian-cloud/2016/01/msg00056.html
[4]: https://github.com/andsens/bootstrap-vz/pull/239
[5]: https://github.com/andsens/bootstrap-vz/pull/269

-- 
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#706052: Document when and how an image can be called "Debian".

[Tiago Ilieve]

Hi Charles,

I would like register to the following references, where the Debian
CD, Debian Cloud and Debian Trademark teams reached a rough consensus
and drafted a proposal (expected to result in a policy later) on what
can be called "Official" Debian images:

https://lists.debian.org/debian-cloud/2015/11/msg00086.html
https://lists.debian.org/debian-cloud/2015/11/msg00088.html
https://lists.debian.org/debian-cloud/2015/11/msg00093.html
https://lists.debian.org/debian-cloud/2015/11/msg00099.html

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#784004: Debian Jessie growpart issue

[Tiago Ilieve]

Juerg,

On 25 January 2016 at 07:38, Juerg Haefliger  wrote:
> I think the easiest solution is to backport cloud-utils from stretch.
> See my subsequent comments:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784004#10

I've followed your suggestion and prepared a backport which is now on
mentors[1]. As expected, following these instructions[2], it yield the
same result that you got using the package from Stretch:

cloud-utils from Jessie:

Jan 30 03:00:18 ip-172-31-10-36 [CLOUDINIT] helpers.py[DEBUG]: Running
config-growpart using lock ()
Jan 30 03:00:18 ip-172-31-10-36 [CLOUDINIT] cc_growpart.py[DEBUG]: No
'growpart' entry in cfg.  Using default: {'ignore_growroot_disabled':
False, 'mode': 'auto', 'devices': ['/']}
Jan 30 03:00:18 ip-172-31-10-36 [CLOUDINIT] util.py[DEBUG]: Running
command ['growpart', '--help'] with allowed return codes [0]
(shell=False, capture=True)
Jan 30 03:00:18 ip-172-31-10-36 [CLOUDINIT] cc_growpart.py[DEBUG]:
growpart unable to find resizer for 'auto': No resizers available

cloud-utils from Jessie-backports:

Jan 30 03:05:19 ip-172-31-10-36 [CLOUDINIT] helpers.py[DEBUG]: Running
config-growpart using lock ()
Jan 30 03:05:19 ip-172-31-10-36 [CLOUDINIT] cc_growpart.py[DEBUG]: No
'growpart' entry in cfg.  Using default: {'ignore_growroot_disabled':
False, 'mode': 'auto', 'devices': ['/']}
Jan 30 03:05:19 ip-172-31-10-36 [CLOUDINIT] util.py[DEBUG]: Running
command ['growpart', '--help'] with allowed return codes [0]
(shell=False, capture=True)
Jan 30 03:05:19 ip-172-31-10-36 [CLOUDINIT] util.py[DEBUG]: Reading
from /proc/345/mountinfo (quiet=False)
Jan 30 03:05:19 ip-172-31-10-36 [CLOUDINIT] util.py[DEBUG]: Read 2214
bytes from /proc/345/mountinfo
Jan 30 03:05:19 ip-172-31-10-36 [CLOUDINIT] util.py[DEBUG]: Reading
from /sys/class/block/xvda1/partition (quiet=False)
Jan 30 03:05:19 ip-172-31-10-36 [CLOUDINIT] util.py[DEBUG]: Read 2
bytes from /sys/class/block/xvda1/partition
Jan 30 03:05:19 ip-172-31-10-36 [CLOUDINIT] util.py[DEBUG]: Reading
from /sys/devices/vbd-51712/block/xvda/dev (quiet=False)
Jan 30 03:05:19 ip-172-31-10-36 [CLOUDINIT] util.py[DEBUG]: Read 6
bytes from /sys/devices/vbd-51712/block/xvda/dev
Jan 30 03:05:19 ip-172-31-10-36 [CLOUDINIT] util.py[DEBUG]: Running
command ['growpart', '--dry-run', '/dev/xvda', '1'] with allowed
return codes [0] (shell=False, capture=True)
Jan 30 03:05:19 ip-172-31-10-36 [CLOUDINIT] util.py[DEBUG]: Running
command ['growpart', '/dev/xvda', '1'] with allowed return codes [0]
(shell=False, capture=True)
Jan 30 03:05:19 ip-172-31-10-36 [CLOUDINIT] util.py[DEBUG]:
resize_devices took 0.070 seconds
Jan 30 03:05:19 ip-172-31-10-36 [CLOUDINIT] cc_growpart.py[INFO]: '/'
resized: changed (/dev/xvda, 1) from 8585740288 to 42942089728

The root partition was successfully resized from ~8 to ~40 GB.

There's one problem right now which is something that had already been
said many times: "Backports isn't where one is supposed to pull bug
fixes from"[3]. The solution would be a proposed-update to Jessie, but
that has already been tried (I can think of #789214[4]) for other bugs
in "cloud-init" with no success (the backport solution was mentioned
there too).

Worth mentioning that the package "cloud-utils" from stable wasn't
installed (neither the "growpart" module was present on
"/etc/cloud/cloud.cfg") on the 8.1 EC2 AMI (ami-116d857a)[5] by
default, so the problem wasn't the growpart version alone, as it
wasn't available at all.

This didn't happened with the 8.2 EC2 AMI (ami-c5265faf)[6] which was
announced on the "debian-cloud" mailing list, but is not on the Wiki
yet. "cloud-utils" was already installed, but the backport alone
didn't solved the problem, as it is using GPT. In this case, the
package "gdisk" is also needed, so growpart can use the "sgdisk"
command.

Charles, Julien and Thomas,

Do you guys think this should be "fixed with a backport"? If so, can
any of you please sponsor this upload?

Regards,
Tiago.

[1]: http://mentors.debian.net/package/cloud-utils
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1001714#c1
[3]: https://lists.debian.org/debian-backports/2016/01/msg00086.html
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789214
[5]: https://wiki.debian.org/Cloud/AmazonEC2Image/Jessie
[6]: https://lists.debian.org/debian-cloud/2015/11/msg4.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#811227: debian-handbook: small typo at "6.4.1 aptitude" section

[Tiago Ilieve]

Package: debian-handbook
Version: 8.20151209
Severity: minor
Tags: patch

Hi Raphaël,

There was a small typo at the "6.4.1 aptitude" section. Where it says
"note than" actually should be "note that".

I'm attaching a patch created from "jessie/master" as today (6709b9b).

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
From 9491474b90aa2c125f38023e0197d358371fc9af Mon Sep 17 00:00:00 2001
From: Tiago Ilieve <tiago.my...@gmail.com>
Date: Sat, 16 Jan 2016 22:21:44 -0200
Subject: [PATCH] Fix small typo at "6.4.1 aptitude" section

---
 en-US/06_apt.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en-US/06_apt.xml b/en-US/06_apt.xml
index 83b0522..054c77c 100644
--- a/en-US/06_apt.xml
+++ b/en-US/06_apt.xml
@@ -1482,7 +1482,7 @@ More tags: suite::debian works-with::software:package role::program interface::c
   + should be used to mark a
   package for installation, - to
   mark it for removal and _ to
-  purge it (note than these keys can also be used for categories, in
+  purge it (note that these keys can also be used for categories, in
   which case the corresponding actions will be applied to all the
   packages of the category). u
   updates the lists of available packages and 

Bug#806767: ITP: libzstd -- fast lossless compression algorithm, targeting real-time compression scenarios

[Tiago Ilieve]

Kevin,

On 1 December 2015 at 00:33, Kevin Murray  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Kevin Murray 
>
> * Package name: libzstd
>   Version : 0.4.0
>   Upstream Author : Yann Collet
> * URL : https://github.com/Cyan4973
> * License : BSD
>   Programming Lang: C
>   Description : fast lossless compression algorithm

The actual URL is https://github.com/Cyan4973/zstd , right?

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#778579: Output not explained

[Tiago Ilieve]

Hi Joachim,

On Tue, 17 Feb 2015 00:37:35 +0100 Joachim Breitner nome...@debian.org wrote:

 Package: zerofree
 Version: 1.0.3-1
 Severity: minor

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi,

 I just ran zerofree and it returned with

 $ zerofree -v /dev/vg-raid1/fry-disk
 2368428/2661728/4826112

 Now I wonder what these numbers mean, but neither the homepage nor the
 manpage would enlighten me.

The source code for the current version (1.0.3-1) states the following
(zerofree.c, lines 170-172):

if ( verbose ) {
printf(\r%u/%u/%u\n, modified, free, fs-super-s_blocks_count);
}


 If you know what they mean, please add that to the manpage.

Would you consider the following patch enough?

diff --git a/debian/zerofree.sgml b/debian/zerofree.sgml
index 405113b..1ab5cbb 100644
--- a/debian/zerofree.sgml
+++ b/debian/zerofree.sgml
@@ -133,7 +133,7 @@
 termoption-v/option
 /term
 listitem
-  paraBe verbose;/para
+  paraBe verbose (shows modified, free and super block count);/para
 /listitem
   /varlistentry
   varlistentry


 Thanks,
 Joachim


 - -- System Information:
 Debian Release: 8.0
   APT prefers unstable
   APT policy: (500, 'unstable'), (101, 'experimental')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386, armhf

 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
 Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 Init: systemd (via /run/systemd/system)

 Versions of packages zerofree depends on:
 ii  e2fslibs  1.42.12-1
 ii  libc6 2.19-15

 zerofree recommends no packages.

 zerofree suggests no packages.

 - -- no debconf information

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iEYEARECAAYFAlTifz0ACgkQ9ijrk0dDIGw9IgCdG7FTReQllWOkFrKwKF8R7POo
 6zUAoL8ucPqd7rbJH/+sHkHi9eNhjJNj
 =6h+3
 -END PGP SIGNATURE-

Regards,
Tiago.

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