Bug#592985: ITP: pragha -- Lightweight Music Player

[Gabriel F. T. Gomes]

Package: wnpp
Followup-For: Bug #592985
Owner: "Gabriel F. T. Gomes" 

I have this software installed in my computer as a Debian package.  Now,
I'd like to check with the community if the package is ready for Debian,
or if more work is needed (I'm willing to make the required changes for
making it a Debian package).

Bug#592985: ITP: pragha -- Lightweight Music Player

[Gabriel F. T. Gomes]

I just uploaded the package to mentors
(https://mentors.debian.net/package/pragha)

This is the second version, because the first had a lintian warning
related the a duplicate changelog file.  I fixed it by using the
options "--keep" from dh_installchangelogs.

In this second version, I also updated the Standard-Version field to
4.0.0, after checking that the package was not affected by any of the
changes from 3.9.8.  However, I was puzzled to see that mentor is
giving a warning about 4.0.0 being too new.  Should I downgrade?

Bug#592985: RFS: pragha/1.3.3-3

[Gabriel F. T. Gomes]

Package: sponsorship-requests
Severity: wishlist

Breno (I hope you actually get CC'ed),

As you suggested, I'm opening a RFS for pragha.
Thanks for the reviews you already made in private. :)

 * Package name: pragha
   Version : 1.3.3-3
   Upstream Author : Matias De lellis 
 * URL : https://pragha-music-player.github.io/
 * License : GPL-3+
   Section : sound

It builds those binary packages:

  pragha - Lightweight Music Player

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

https://mentors.debian.net/package/pragha


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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pragha/pragha_1.3.3-3.dsc


Kind Regards,
Gabriel

Bug#876095: O: bash-completion -- programmable completion for the bash shell

[Gabriel F. T. Gomes]

retitle 876095 ITA: bash-completion -- programmable completion for the bash 
shell
owner 876095 !

--

On 18 Sep 2017, Axel Beckert wrote:

>Maintaining a package requires time and skills. Please only adopt this
>package if you will have enough time and attention to work on it.  

Although I'm new to Debian maintenance (my first and only work is the
packaging of pragha (https://mentors.debian.net/package/pragha)), I
would like to take ownership of this package.

>Please also notice that there seems new upstream development at
>https://github.com/scop/bash-completion/, so one of the tasks for the
>new maintainer is to update the package to the most recent upstream
>release.  

I cloned the package repository and I understood how syncing with
upstream was designed (very clever, imo).  So, I synced it and I began
working on the removal of the patches that are no longer required, or
that do not apply cleanly.

Once that is solved, I'll have a package and lots of bugs on Alioth to
mark as fixed.  Arguably, this will be the hardest part, since there
are a lot of open bugs and since there has been a lot of improvements
upstream.

Is it fine if I keep doing this?

Bug#868902: Floating-point exception happens when exception is disabled

[Gabriel F. T. Gomes]

Package: linux
Version: 4.9.30-2+deb9u2


Bug description:

While testing glibc on a powerpc64le machine with debian stretch, I
noticed that a test case (from the glibc test case suite) fails
intermittently. The test case in glibc [1] is rather long, so I reduced it
to a minimum that still reproduces the problem and I attached it to this
bug report (see fenv.c).


Steps to reproduce:

With the attached test case, there's no need to build the whole of glibc
(which would be needed to test the original test case). So, in order to
reproduce this bug, I just compiled the attached test case with:

$ gcc fenv.c -O0 -lm -o fenv

Since the test case only fails intermittently, it has to be executed many
times before the failure can be seen.  On my machine, I used the following
command:

$ while [ 1 ]; do \
./fenv &> ./fenv.log; \
if [ $? -ne 0 ]; then break; fi; \
  done

This command stops when the test case fails.  The log file, fenv.log
(also attached), can be examined for the error message, which will contain
an error message similar to the following snippet:

  Test: after fedisableexcept (FE_UNDERFLOW) processes will not abort
when feraiseexcept (FE_UNDERFLOW) is called.
Fail: Process exited abnormally with status 8.


Reproducing with upstream sources:

I reproduced this bug with the kernel provided by debian stretch (as
reported in the pseudo-header), but I also reproduced it with other
releases from kernel.org:

v4.10 (release tag)
v4.11 (release tag)
v4.12-rc4 (tag)

Since the 5th release candidate for 4.12, the test case miraculously
healed - ;) - and I tracked it down to a commit [2] by Breno Leitao,
Gustavo Romero, Anton Blanchard, and Michael Ellerman.

This problem does not reproduce with v4.12.


Backporting:

I backported (only locally) the patch [2] to v4.10, and it indeed fixes the
problem.


Additional information:

My system is running as a KVM guest with Debian Stretch on a powerpc64le
host machine.  The output of the following commands might be useful:

$ uname -a
Linux debian 4.9.0-3-powerpc64le #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) 
ppc64le GNU/Linux

$ /lib/powerpc64le-linux-gnu/libc.so.6 
GNU C Library (Debian GLIBC 2.24-11) stable release version 2.24, by Roland 
McGrath et al.
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 6.3.0 20170516.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC


References:

[1]
https://sourceware.org/git/?p=glibc.git;a=blob;f=math/test-fenv.c;h=b24b3a1e31ad0769c54d10e2eb0f230eaa7662d6;hb=HEAD

[2]
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=1195892c091a15cc862f4e202482a3/* Copyright (C) 1997-2017 Free Software Foundation, Inc.
   This file is part of the GNU C Library.

   The GNU C Library is free software; you can redistribute it and/or
   modify it under the terms of the GNU Lesser General Public
   License as published by the Free Software Foundation; either
   version 2.1 of the License, or (at your option) any later version.

   The GNU C Library is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   Lesser General Public License for more details.

   You should have received a copy of the GNU Lesser General Public
   License along with the GNU C Library; if not, see
   .  */

#ifndef _GNU_SOURCE
# define _GNU_SOURCE
#endif

#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

static int count_errors;

#if FE_ALL_EXCEPT
/* Test that program aborts with no masked interrupts */
static void
feexcp_nomask_test (const char *flag_name, int fe_exc)
{
  int status;
  pid_t pid;

  if (feenableexcept (fe_exc) == -1)
{
  printf ("Test: not testing feenableexcept, it isn't implemented.\n");
  return;
}

  printf ("Test: after feenableexcept (%s) processes will abort\n",
	  flag_name);
  printf ("  when feraiseexcept (%s) is called.\n", flag_name);
  pid = fork ();
  if (pid == 0)
{
  fedisableexcept (FE_ALL_EXCEPT);
  feenableexcept (fe_exc);
  feraiseexcept (fe_exc);
  exit (2);
}
  else if (pid < 0)
{
  if (errno != ENOSYS)
	{
	  printf ("  Fail: Could not fork.\n");
	  ++count_errors;
	}
  else
	printf ("  `fork' not implemented, test ignored.\n");
}
  else {
if (waitpid (pid, &status, 0) != pid)
  {
	printf ("  Fail: waitpid call failed.\n");
	++count_errors;
  }
else if (WIFSIGNALED (status) && WTERMSIG (status) == SIGFPE)
  printf ("  Pass: Pr

Bug#1070074: several errors on tab completion

[Gabriel F. T. Gomes]

Hi, Ivan and Alban,

Thank you very much for your reports. They certainly help me debug this large 
update.

I see two different issues:

1. Missing _comp_deprecate* functions

Bash-completion 2.12 adds a new file to /etc/bash_completion.d
(/etc/bash_completion.d/000_bash_completion_compat.bash), and this file
contains several calls to _comp_deprecate_func and _comp_deprecate_var.

These functions are only defined in version 2.12.0 of bash-completion.

I believe that the problem that Ivan reported happened after the
downgrade (from 2.12.0-1 to 2.11-8) and subsequently opening a new shell.

This happens because the downgrade does not remove the file from /etc.

I might need to move this file to a different location so that it gets
removed by downgrades.

2. New completion files requiring new function from bash_completion

This is mainly what Alban reported and the only solution I can think of
is restarting the shell or re-sourcing bash-completion.

Maybe we could have a downstream patch that provides this functions and
tells the user that they must re-source bash-completion. Providing them
as empty stubs would probably cause more harm than good, because the
calling routines would then misbehave; Copying them from the older
version could also work, but I fear that this would be a lot of work
for me.

On Tue, 30 Apr 2024 15:38:33 +0200
Alban Browaeys  wrote:

> Package: bash-completion
> Followup-For: Bug #1070074
> 
> I doubt this issue is related to util-linux-extra being too old.
> 
> I had a similar error while pressing "sudo" I got the error:
> "sudo bash: _comp_initialize : commande introuvable"
> ie "commande introuvable" is "command not found".
> 
> It turned out that this error only happens in bash shell I had opened
> before the upgrade (the fact you had the issue opening new bash shell is
> awakward to me). The bash shell I opened after were fine.
> 
> Note the _comp_deprecate_var, _comp_xxx functions are defined in 
> /usr/share/bash-completion/bash_completion
> which is part of the bash-completion package, so upgrading
> util-linux-extra can have no effect on them being present or not.
> 
> From the error I got above I guess bash completion 
> /usr/share/bash-completion/completions/*
> might get source anew after upgrade while the
> /usr/share/bash-completion/bash-completion common function definition
> file is not.
> A way to workaround this issue would be to source this file in existing
> bash shells: "source /usr/share/bash-completion/bash_completion" indeed
> fixed my shell with broken "sudo" and missing _comp_initialize
> command.
> 
> I see no easy fix as as far as I know, the 
> /usr/share/bash-completion/bash_completion
> is imported when the bash shell is started (profile file or bashrc) but it 
> seems the
> completion files can be source during the shell runtime.
> Maybe the a check at each completion files function call could be added
> to check if /usr/share/bash-completion/bash_completion has changed and
> source it when so. But this looks more like an upstream issue
> than a Debian specific topic.
> 
> NB: I still do not understand why you got the "command not found" when
> opening a new bash shell. The new
> /usr/share/bash-completion/bash_completion is source from the latest
> version at this point.
> Maybe your $HOME/.bashrc is not up to date:
> 
> /etc/skel/.bashrc: (should be in your $HOME/.bashrc)
> # If not running interactively, don't do anything
> case $- in
> *i*) ;;
>   *) return;;
> esac
> (...)
> # enable programmable completion features (you don't need to enable
> # this, if it's already enabled in /etc/bash.bashrc and /etc/profile
> # sources /etc/bash.bashrc).
> if ! shopt -oq posix; then
>   if [ -f /usr/share/bash-completion/bash_completion ]; then
> . /usr/share/bash-completion/bash_completion
>   elif [ -f /etc/bash_completion ]; then
> . /etc/bash_completion
>   fi
> fi
> 
> 
> /etc/bash.bashrc:
> # enable bash completion in interactive shells
> #if ! shopt -oq posix; then
> #  if [ -f /usr/share/bash-completion/bash_completion ]; then
> #. /usr/share/bash-completion/bash_completion
> #  elif [ -f /etc/bash_completion ]; then
> #. /etc/bash_completion
> #  fi
> #fi
> 
> or it is not imported from your $HOME/.profile which should have:
> # if running bash
> if [ -n "$BASH_VERSION" ]; then
> # include .bashrc if it exists
> if [ -f "$HOME/.bashrc" ]; then
> . "$HOME/.bashrc"
> fi
> fi
> 
> 
> but even then /etc/profile should have source the common bash completion 
> functions:
> /etc/profile:
> /etc/profile.d/bash_completion.sh
> # shellcheck shell=sh disable=SC1091,SC2166,SC2268,SC3028,SC3044,SC3054
> # Check for interactive bash and that we haven't already been sourced.
> if [ "x${BASH_VERSION-}" != x -a "x${PS1-}" != x -a 
> "x${BASH_COMPLETION_VERSINFO-}" = x ]; then
> 
> # Check for recent enough version of bash.
> if [ "${BASH_VERSINFO[0]}" -gt 4 ] ||
> [ "${BASH_VERSINFO[0]}" -eq 4 -a "${BASH_VER

Bug#1033847: Please update to upstream sources

[Gabriel F. T. Gomes]

Hi Richard,

thanks for your report.

With respect to the package being outdated, I realize that the sources
have not been sync'd with upstream for a long while, but that's because
upstream has not released any versions (no tags) since 2.11; and I
always wait for upstream releases before syncing. From time to time, I
do some backporting (cherry-pick); though I have a somewhat long list of
request from other users that I haven't applied yet, but plan to do so
soon.

Now with respect to the problem you're getting with the readline patch,
could you provide more details about your freezes? Maybe a directory
structure and files, as well as the pattern you are trying to complete?
That would help me reproduce the problem. I don't want to remove the
patch all of a sudden, because it's been there since a long time (since
before I was the maintainer).

Best regards,
Gabriel

Bug#1033642: ssh: deprecated option PubkeyAcceptedKeyTypes

[Gabriel F. T. Gomes]

Thanks, Matthias,

I submitted a patch upstream to get the feedback from the upstream [1]
developers. I hope they accept it; if they do, it's easier for me to
backport. Cheers, Gabriel.

[1] https://github.com/scop/bash-completion/pull/922

On Wed, 29 Mar 2023 11:40:09 +0200
Matthias Geerdsen  wrote:

> Package: bash-completion
> Version: 1:2.11-6
> Severity: minor
> 
> Hi,
> 
> completion for the ssh command offers PubkeyAcceptedKeyTypes as an option,
> which has been renamed to PubkeyAcceptedAlgorithms in openssh 8.5
> (https://www.openssh.com/txt/release-8.5), which makes this relevant starting
> from bookworm.
> The old option is not mentioned in the manpage anymore but is still valid, so
> the bash-completion is not wrong but a bit confusing.
> 
> Thanks
> Matthias
> 
> 
> -- System Information:
> Debian Release: 12.0
>   APT prefers testing-security
>   APT policy: (500, 'testing-security'), (500, 'testing'), (50, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.1.0-6-amd64 (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> -- no debconf information

Bug#1033847: Please update to upstream sources

[Gabriel F. T. Gomes]

On Mon, 10 Apr 2023 14:04:06 +0200
"Richard B. Kreckel"  wrote:
>
> Regarding my hangs: It is because something's broken in my NIS 
> (yellow-pages) setup (haven't fully analyzed yet). It turns out that, 
> when doing tab completion, your patch 00-fix_quote_readline_by_ref.patch 
> tries to match against ~*, which incurs a NIS look-up and that blocks.
> The upstream version doesn't do that and it seems like the patch has 
> never been applied.

Thanks for the info, I'll try to replicate.

> Are you sure it is necessary?

I'm not sure. See below.

> If no: can it be removed?

Maybe. See below.

> If yes: has it been reported upstream and what was the response?

I don't know. See below.

When I took the maintainer role for bash-completion, I did a lot of bug
archaeology, but the amount of bugs and patches was too large, so I
don't know the reason for every packaging bit. I could do some more
digging, but a lot of the history was gone when we moved to salsa (I
even forgot the name of the old system), so I'll just focus on your
problem and try to determine if we can get rid of this specific patch
while minimizing pain for other users.

Best regards,
Gabriel

Bug#1033847: Please update to upstream sources

[Gabriel F. T. Gomes]

Thanks, Sergio.

You're the best archaeologist! S2

On Mon, 10 Apr 2023 13:55:27 -0400
Sergio Durigan Junior  wrote:

> On Monday, April 10 2023, Gabriel F. T. Gomes wrote:
> 
> > When I took the maintainer role for bash-completion, I did a lot of bug
> > archaeology, but the amount of bugs and patches was too large, so I
> > don't know the reason for every packaging bit. I could do some more
> > digging, but a lot of the history was gone when we moved to salsa (I
> > even forgot the name of the old system), so I'll just focus on your
> > problem and try to determine if we can get rid of this specific patch
> > while minimizing pain for other users.  
> 
> Hey!
> 
> So, the old system was called Alioth.  When we migrated to salsa, there
> was some effort to preserve the history of old repositories, and
> fortunately bash-completion was one of them.
> 
> For reference, you can find the Alioth archive here:
> 
>   https://alioth-archive.debian.org/
> 
> Bash-completion's archive is here:
> 
>   https://alioth-archive.debian.org/git/bash-completion/
> 
> We're interested in the debian.git.tar.xz file, which contains the
> git repo for the Debian package:
> 
> $ wget https://alioth-archive.debian.org/git/bash-completion/debian.git.tar.xz
> $ tar xf debian.git.tar.xz
> $ git clone debian.git old-bash-completion
> $ cd old-bash-completion
> $ git log -- debian/patches/00-fix_quote_readline_by_ref.patch
> commit d734ca3bd73ae49b8f452802fb8fb65a440ab07a
> Author: David Paleino 
> AuthorDate: Wed Mar 19 10:20:35 2014 +0100
> Commit: David Paleino 
> CommitDate: Wed Mar 19 10:20:35 2014 +0100
> 
> fix_quote_readline_by_ref.patch, thanks to JuanJo Ciarlante (Closes: 
> #739835)
> 
> + avoid escaping 1st '~' (LP: #1288314)
> + avoid quoting if empty, else expansion without args only shows
>   dirs (LP: #1288031)
> + replace double escaping to single (eg for completing file/paths
>   with spaces)
> 
> HTH,
> 

Bug#1034567: bash-completion: Doesn't work for root in non-login shell (on default settings)

[Gabriel F. T. Gomes]

Control: tags -1 confirmed

Steps to reproduce

$ su -# become root
# echo $0
-bash # this is a login shell
# apt-get inst
(completes)
# su root
# echo $0
bash  # this is a non-login shell
# apt-get inst
(nothing happens)

I don't currently know what sources /etc/bash_completion in the login
shell. I'll try to figure it out.

On Tue, 18 Apr 2023 12:31:04 +
Askar Safin  wrote:

> Package: bash-completion
> Version: 1:2.11-6
> Severity: normal
> X-Debbugs-Cc: safinas...@gmail.com
> 
> bash-completion (for example, "apt-get inst") doesn't work for root in
> non-login shell on default settings. Completion works for normal users.
> And completion works in login shells.
> 
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-0.deb9.21-amd64 (SMP w/4 CPU threads)
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect
> 
> -- no debconf information

Bug#1034567: bash-completion: Doesn't work for root in non-login shell (on default settings)

[Gabriel F. T. Gomes]

On Wed, 19 Apr 2023 17:10:06 +0300
Askar Safin  wrote:

> If I copy /etc/skel/.bashrc to /root/.bashrc , the bug disappears.

That's because /etc/skel/.bashrc directly source /etc/bash_completion.

With login shells, /etc/bash_completion gets sourced by something else.
I think we need to dig deeper.

Bug#1034567: bash-completion: Doesn't work for root in non-login shell (on default settings)

[Gabriel F. T. Gomes]

On Wed, 19 Apr 2023 22:45:21 +0300
Askar Safin  wrote:
>
> (But I still think we should just make /etc/skel/.bashrc to be default
> /root/.bashrc . This will fix other possible "user vs root" bugs.
> Currently /root/.bashrc doesn't have any non-comment lines, i. e. it
> doesn't contain anything useful anyway.)

I believe that bash-completion has no influence over /root/.bashrc.

Actually, I don't even know which package owns /root/.bashrc
(dpkg --search /root/.bashrc returns nothing); I assumed it was owned
by the bash package, and I was planning on reassigning this bug to them
to get some feedback, but apparently I was wrong.

Bug#1033847: closed by Debian FTP Masters (reply to gabr...@debian.org (Gabriel F. T. Gomes)) (Bug#1033847: fixed in bash-completion 1:2.11-7)

[Gabriel F. T. Gomes]

Hi, Richy,

Erring on the side of caution, I just posted a comment [1] to the upstream 
project, asking if the plan to release 2.12 is still alive. If they say yes, 
then we might give them a hand with the remaining tasks to speed it up. 
Otherwise, I'll plan some debian-only update in the lines of what you mentioned 
before.

Best regards,
Gabriel

[1] 
https://github.com/scop/bash-completion/discussions/530#discussioncomment-6482817

Bug#1033847: closed by Debian FTP Masters (reply to gabr...@debian.org (Gabriel F. T. Gomes)) (Bug#1033847: fixed in bash-completion 1:2.11-7)

[Gabriel F. T. Gomes]

Hi again,

One of the project maintainers said [1] that the plan for a release is
still up. I'll try to help them with whatever spare time I can find.
Not sure if you are interested in doing that as well, but I wanted to
make a point that bash-completion is a very friendly community and
welcomes every contribution. ^^

[1] 
https://github.com/scop/bash-completion/discussions/530#discussioncomment-6490360

Bug#1033186: bash-completion: Please add .pages as possible extension for libreoffice (writer)

[Gabriel F. T. Gomes]

Control: reassign -1 libreoffice

Hi, I believe the libreoffice package produces its own completion files
(which is awesome), thus reassigning.

A patch for this would probably look like:

--- bin/generate-bash-completion.py 2023-06-19 18:32:31.988021669 -0700
+++ bin/generate-bash-completion.py.PATCH   2023-06-19 18:32:21.816021649 
-0700
@@ -39,7 +39,7 @@
 
 WRITERDOCS = ["doc", "dot", "rtf", "sxw", "stw", "sdw", "vor", "txt", "htm?",
   "xml", "wp", "wpd", "wps", "odt", "ott", "fodt", "docm", "docx",
-  "dotm", "dotx"]
+  "dotm", "dotx", "pages"]
 
 TEMPLATES = ["stw", "dot", "vor", "stc", "xlt", "sti", "pot", "std", "stw",
  "dotm", "dotx", "potm", "potx", "xltm", "xltx"]

Best regards,
Gabriel


On Sun, 19 Mar 2023 08:50:13 +0100
Helge Kreutzmann  wrote:

> Package: bash-completion
> Version: 1:2.11-6
> Severity: wishlist
> 
> I got a .pages file a few days ago. I did not know how to handle it and
> by chance realized libreoffice can open it just fine. Unfortunately
> this is not clear in the shell, as bash refuses to complete the file
> name by default.
> 
> Probably the following change should do the trick:
> -_install_xspec 
> '!*.@(sxw|stw|sxg|sgl|doc?([mx])|dot?([mx])|rtf|txt|htm|html|?(f)odt|ott|odm|pdf)'
>  oowriter lowriter
> +_install_xspec 
> '!*.@(sxw|stw|sxg|sgl|doc?([mx])|dot?([mx])|rtf|txt|htm|html|?(f)odt|ott|odm|pdf|pages)'
>  oowriter lowriter
> 
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing-security
>   APT policy: (500, 'testing-security'), (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to de_DE.UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> -- no debconf information
> 

Bug#921598: No METAR available since noaa.gov switched to https

[Gabriel F. T. Gomes]

Package: flightgear
Version: 1:2018.3.2+dfsg-2

Dear maintainers,

Very recently, noaa.gov switched to https, which makes flightgear unable
to download METAR data, thus unable to provide 'live' weather conditions
for the simulation.

I have created a merge request on salsa [1] with a possible, albeit not
ideal, solution to the problem.  Since this is about a hardcoded URL in
the source, which might potentially require rebuilds, and since we are
close to the freeze for buster, I decided to share this with you sooner
than later, so that you have more time to evaluate.

(as noted in the merge request, the flightgear forum has suggestions of
fixes that do not require a rebuild, but I haven't checked that they
actually work.  I did check that the merge request fixes the problem)

[1] https://salsa.debian.org/debian/flightgear/merge_requests/1

Bug#921962: Please remove obsolete 'xm' completion file

[Gabriel F. T. Gomes]

On Sun, Feb 10 2019, Hans van Kranenburg wrote:
> 
> Please remove the 'xm' file from the bash-completion package. This
> command does not exist in Xen any more (last time it was relevant was in
> Jessie, where it was already deprecated).

That should be easy to do for Debian.  On the other hand, I wonder if I
should work first with upstream to get it removed from there.  Do you
know if the deprecation of xm is debian-specific?  Or has it been
deprecated and removed by the xen project?

> Also, I just hijacked another of your bugs, 768005 , about the xl
> command completion. Hope that's fine, we can maintain this in the Xen
> packaging and upstream improvements.

Thanks for doing this.  That's the ideal situation (from an upstream
bash-completion point-of-view, anyway [1]).

[1] https://github.com/scop/bash-completion/pull/276#issuecomment-456558772

Bug#921598: No METAR available since noaa.gov switched to https

[Gabriel F. T. Gomes]

I updated the merge request.

When I first wrote the merge request, upstream did not have a fix for
the METAR problem.  Now they do [1].  So, I removed the simple patch I
wrote, and replaced it with this upstream fix.

Would you consider this for buster?
(otherwise, live weather won't work)

[1] 
https://sourceforge.net/p/flightgear/flightgear/ci/2fdc24c1097955c5d2c88a9cc0be66069b22eebe/

Bug#921598: No METAR available since noaa.gov switched to https

[Gabriel F. T. Gomes]

On Sat, Feb 16 2019, Florent Rougon wrote:
> 
> As has been discussed on flightgear-devel and despite the commit
> message, commit [1] is not a proper fix and will probably be reverted (I
> mean, the "if( responseCode() >= 400 )" part, not the http to https URL
> change which is okay though unnecessary now that redirection is fixed in
> SimGear's HTTP::Client).

OK, thanks for the clarification.

> The correct fix is [a]. [b] is also a bug fix in this area, but doesn't
> solve the particular METAR fetching problem.
> 
> [a] 
> https://sourceforge.net/p/flightgear/simgear/ci/34b3c52a288d62779073fc7694344d0658755645/
> [b] 
> https://sourceforge.net/p/flightgear/simgear/ci/6197098541eceecdb0dcfe8a58b15f0d0773c391/

I'll close the merge request.

Thanks,
Gabriel

Bug#877450: RFS: bash-completion/1:2.7-1 [ITA]

[Gabriel F. T. Gomes]

On 22 Dec 2017, Sergio Durigan Junior wrote:

>As promised, here's my review.

Thank you! ^^

>The first thing I did was to "gbp
>clone" your repository and build it locally.  After that, I ran:
>
>  lintian -EI --pedantic bash-completion_2.7-1_amd64.changes
>
>And noticed a few things worth fixing:
>
>  I: bash-completion source: vcs-field-uses-insecure-uri vcs-git
> git://git.inconstante.eti.br/bash-completion-debian.git I:
> bash-completion source: vcs-field-uses-insecure-uri vcs-browser
> http://git.inconstante.eti.br/?p=bash-completion-debian.git
>
>Not sure if you're planning to change these URLs, but you should use
>secure (HTTPS) ones.  But you're probably going to use the "official"
>repository, right?  The one at
>.

Not really.  If I understood it correctly, anonscm.debian.org is
alioth, which was being decomissioned when I started to work on this.

I just noticed that alioth's replacement, salsa.debian.org, is up.  So
maybe I should move this repository, now.

>  W: bash-completion: package-installs-into-obsolete-dir
> etc/bash_completion.d/ : ^etc/bash_completion.d/ ->
> usr/share/bash-completion/completions Ensure new filename matches
> sticter requirements (see https://bugs.debian.org/776954 and
> https://bugs.debian.org/814599)
>
>It seems the package was abandoned before these warnings were added.
>You can see more details in the bugs, but the idea here is that
>completions should be installed under
>/usr/share/bash-completion/completions/,
>because /etc/bash_completion.d/ has been deprecated.
>
>It is questionable whether you should make at least one revision with
>/etc/bash_completion.d/, because according to README.Debian the
>directory was being kept for compatibility reasons.  IMHO, this is a
>good opportunity to make needed changes to the package, and this is one
>of them.  But maybe you/others have a different opinion.

Currently, bash-completion only creates this directory because it is
listed in debian/dirs.  Bash-completion itself doesn't install any files
in this directory.

If I remove the listing from debian/dirs, the directory disappears from
the package.  Other packages (e.g.: git, dkms) might still create this
directory and populate it with their completion files.

Anyhow, I believe it is safe to remove the listing from debian/dirs at
this point (meaning I don't believe another revision that creates
/etc/bash_completion.d/ is necessary).

So, I'll prepare a new version with this (which will solve the
lintian failure).

>It's also a good idea to bump the Standards-Version to 4.1.2 now.

OK.

>Other than that, I really like what you did, and I think the package is
>basically ready to be uploaded.

I'll work on the changes you suggested.  Thanks!

Bug#877450: RFS: bash-completion/1:2.7-1 [ITA]

[Gabriel F. T. Gomes]

On 29 Dec 2017, Sergio Durigan Junior wrote:
>On Friday, December 29 2017, Gabriel F. T. Gomes wrote:
>> On 22 Dec 2017, Sergio Durigan Junior wrote:
>>
>Yeah, that's right.  I'm still using git.debian.org for my packages,
>but I should change that as well.

I changed to the new server and fixed the Vcs-* fields accordingly:

https://salsa.debian.org/gabrielftg-guest/bash-completion-debian/commit/f2140c2633a8849d423d475a91db9ba40ff840c9

>Cool.  As I said, I consider this to be a matter of preference; I
>personally wouldn't bother to see /etc/bash_completion.d/ still there
>in the next release.  But thanks for doing that.

Also fixed:

https://salsa.debian.org/gabrielftg-guest/bash-completion-debian/commit/e4185da001ceafbc713806faa4315cb8443471be

>>>It's also a good idea to bump the Standards-Version to 4.1.2 now.  
>>
>> OK.  
>
>4.1.3 now :-).

Also fixed:

https://salsa.debian.org/gabrielftg-guest/bash-completion-debian/commits/unstable


Thanks for the reviews, so far. :) <3

If and when you can, could you review these last changes?
If so, would you also be willing to sponsor the package?
(it's on mentors: https://mentors.debian.net/package/bash-completion)

Cheers,
Gabriel

Bug#877450: RFS: bash-completion/1:2.7-1 [ITA]

[Gabriel F. T. Gomes]

On 29 Dec 2017, Vincent Blut wrote:

>With this release, you can close #847971 too. ;-)

Oh, great! :)

I added this information to the changelog so that the bug gets closed
automatically  (I also resubmitted to mentors).  

Thanks.


pgpLrqiNCueS5.pgp
Description: OpenPGP digital signature

Bug#877450: RFS: bash-completion/1:2.7-1 [ITA]

[Gabriel F. T. Gomes]

The repository for the packaging of bash-completion is now hosted on
https://salsa.debian.org/debian/bash-completion/

The latest commit is not on the master branch, but on

https://salsa.debian.org/debian/bash-completion/commits/unstable

Mentors has been updated with a new build:

https://mentors.debian.net/package/bash-completion

Thank you all for the feedback! :)


pgpxqnnB3rK5T.pgp
Description: OpenPGP digital signature

Bug#891667: bash-completion: file wildcard (*) completion picks up only first match

[Gabriel F. T. Gomes]

On 27 Feb 2018, Christoph Anton Mitterer wrote:

>When completing e.g.
>$ ls *
>
>then * doesn't become all the files (not starting with a .), but
>instead only one of the files in the directory.
>
>This bug exists now since quite a while, and other bug reports, seem to
>include the reason (missing quotes in one of the bash-completion
>files):
>
>https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1387057

While I understand that this patch in launchpad fixes the reported
behaviour, I don't understand why upstream did not want to accept it.
Could there be unintended/undesired side-effects?

>https://superuser.com/questions/823257/unexpected-bash-glob-completion-uses-first-match-even-if-ambiguous
>
>Could this be fixed in the Debian package? :-)

I could definitely apply this to the Debian package, but I want to take
this questioning upstream first.  It's been a long time, and maybe they
have a better understanding of the problem, now.

I don't have a good understanding of the problem, myself. :)


Thanks for reporting.

Bug#891667: bash-completion: file wildcard (*) completion picks up only first match

[Gabriel F. T. Gomes]

On 07 Mar 2018, Gabriel F. T. Gomes wrote:

>On 27 Feb 2018, Christoph Anton Mitterer wrote:
>
>>https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1387057  
>
>While I understand that this patch in launchpad fixes the reported
>behaviour, I don't understand why upstream did not want to accept it.
>Could there be unintended/undesired side-effects?

I found these two issues upstream, which seem related:

https://github.com/scop/bash-completion/pull/77
https://github.com/scop/bash-completion/issues/181

It seems that Ville Skyttä is also worried about side-effects:

https://github.com/scop/bash-completion/pull/77#issuecomment-251582105


I also found this pair, which also seems related, but I'm not sure it
actually relates to what you're reporting:

https://github.com/scop/bash-completion/issues/42
https://github.com/scop/bash-completion/pull/41

Bug#891667: bash-completion: file wildcard (*) completion picks up only first match

[Gabriel F. T. Gomes]

On 08 Mar 2018, Christoph Anton Mitterer wrote:

>At least I think to remember that this wasn't always buggy... it only
>happened in to investigate&report ^^>.

If you do not source bash_completion, then these completions work as
you expect.  So maybe you didn't have bash-completion installed?

>I cannot really say for sure whether there are undesired side
>effects...

I guess that's the hard part...  Proving something to be free of
errors.  Maybe it's even impossible to prove.

>I mean bash-completion should anyway only be active in
>interactive sessions, right? So scripts shouldn't take any harm.
>And for interactive sessions (or such who kinda hack a script to behave
>like in an interactive one)... people must always expect that such
>changes occur in new versions.

That's a good point.

>What I personally would probably even like more was, if * is just not
>completed at all... but completing it only to one "random" match is
>just pointless.

I agree.

Bug#779814: bash-completion: please support new pkey, genpkey, pkeyparam, and pkeyutl subcommands of openssl

[Gabriel F. T. Gomes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05 Mar 2018, Brian Minton wrote:

>This is just a placeholder to inform you that the current version of
>bash-completion still does not have the new openssl commands.

Completion for these commands is not available, because they don't have
upstream (bash-completion) support.  Completion for other openssl
commands should be available, but not under /etc/bash_completion.d, as
has been mentioned in the first message in this bug report (maybe it
was a correct assumption such a long time ago :)).  Nowadays,
completions are shipped under /usr/share/bash-completion.

Anyhow, I thought it would be nice to see completions for these
commands, too, so I created a pull request upstream [1].  I'll wait for
comments, since I have little experience with openssl (maybe you could
provide some feedback, there?).

Thanks for reaching out. :)

[1] https://github.com/scop/bash-completion/pull/191
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE+wUJHFVUA1wadvc8rpsRODhuyvIFAlqjCrgACgkQrpsRODhu
yvJNaw/7ByjREf6y+l2x2Xj+ouG3dfiQkYrp5/9BnRLZu3+3CdPdwipfk9I1pR3i
b2n/u3y/66SOrgQhgvmbCPb/Nj6Ob9CQtofWzUEfWBaXZHsfk1ZBLAIUWc/pjpuS
jbSMkC080Z357SFyIx+QD/Nz1IcKwiqWzNMmGu6eP5dhRn28R4hHs8CFvOqzKz73
oVT3eA2FwghhuvNin9Ks53OSI+MJLx1h/ZRRiavUGswuljUORwDboLysnqZBpCPh
xCmIOSIFC9UVGGaBxWA2S+SQLhR1JqC2Vt87tdl1mflzo0jBSy8sFfxEbEACkxe+
b5xvVR4OpxrjxNiRfmGvvUiLWHO+sLTBraIya9lYJUMvuHApzob0ooFpyoV348Qd
tUeecVjOWqSbPUqbla9mAvaQGa8tU0RUa2Z/c+a6Eth+C0BApKTSH0stZ2zv3yY/
6jvyL5tbXQA1OLqVNrgd+HJ9LXmRkDueZU+LJJVmpimCyEITfMBaRxgoJFmMVwPk
I9zeqKIdxG4TiQr1iK1Pm0uf64JxTWx2G1KT+GRNi9WEvIKMErZXYj1rHlg7R321
HqmdQjAV32laH8e2UiAUlN00bTx6PYRm1DxxQ/892qZLy65Z2Du9UjmCpgQFhsF5
pD2hJrDjCnh59x3Qf0/Vg8xW18j4auZO45JFBxRj3gLRIzH/Y6A=
=RInE
-END PGP SIGNATURE-

Bug#892147: Please create the Pragha package with complete audio (api) support

[Gabriel F. T. Gomes]

On 06 Mar 2018, Jürgen Göricke wrote:

>Please create the Pragha package with gstreamer1.0-alsa _and_
>gstreamer1.0-pulseaudio support.

In order to try to reproduce this, I:

  - Installed gstreamer1.0-alsa;
  - Killed the pulseaudio daemon;
  - Selected alsa as the "Audio Sink" on pragha settings.

then I got the following error message:

  Error playing current track ()
  Reason: Could not open audio device for playback.

Is this the same error you're seeing?


Afterwards, I used "aplay -l" and "aplay -L" to learn what audio
devices I had (I'm only listing the outputs related to PCH, since all
other outputs are not actually connected to speakers):

  # aplay -l
   List of PLAYBACK Hardware Devices 
  [...]
  card 1: PCH [HDA Intel PCH], device 0: ALC892 Analog [ALC892 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
  card 1: PCH [HDA Intel PCH], device 1: ALC892 Digital [ALC892 Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
  [...]

  # aplay -L
  [...]
  default:CARD=PCH
HDA Intel PCH, ALC892 Analog
Default Audio Device
  [...]
  hw:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Analog
Direct hardware device without any conversions
  hw:CARD=PCH,DEV=1
HDA Intel PCH, ALC892 Digital
Direct hardware device without any conversions
  [...]
  (there were other PCH related devices, but too many to list here)


With that output, I understood that I also needed to modify the name of
the "Audio Device" in pragha settings to "hw:1" or "default:1".

Afterwards, audio worked again.

Do you think that this could still be going through pulseaudio?
(I don't know how to completely get rid of pulseaudio to make more
tests.  Pulseaudio was automatically installed by xfce, I guess).


Maybe you also need to change the "Audio Device" on pragha settings?

>It should be possible
>to install and use either gstreamer1.0-alsa or
>gstreamer1.0-pulseaudio.

If what I mentioned above is not enough and there is actually something
missing in the build of pragha, I think I'll need some help to fix it.

Do you know how to do it?  I looked into pragha's code and I didn't
find any macros preventing alsa code from being built.

In your machine do you build pragha from sources?  If so...

  - Do you need to pass any additional flags to configure?
  - Do you have any development libraries installed?


>Since Pragha is one of the few audio players
>that meets my requirements for a slim audio player, it would be
>wonderful if users who don't want to use the Pulseaudio could use this
>player. Thank you very much!

Thank you for reporting! :)

Let's try to make it work for you and for others.


pgpdQg2qW1Np4.pgp
Description: OpenPGP digital signature

Bug#892080: bash-completion: cvs log ($mode=log) case disappeared?

[Gabriel F. T. Gomes]

On 05 Mar 2018, Tim Connors wrote:

>I'm sure 'cvs log ' use to tab-complete , but it's
>clear why it doesn't:
>
>log|lo|rlog|rl)
>mode=log
>;;
>
>But then no corresponding case for $mode=log.

Thanks for pointing this out.  I sent a patch for upstream review at:
https://github.com/scop/bash-completion/pull/194.

Bug#904700: /etc/profiles.d/bash_completion.sh or the sourced script break sddm login

[Gabriel F. T. Gomes]

On 26 Jul 2018, Alf Gaida wrote:

>when user shell is set to fish and bash-completion is installed.
>Purging bash-completion "solved" the problem for fish. Culprit is the
>newly introduced sourcing of /etc/profile for fish in sddm 0.18.0.

Only today I had a look at this and I couldn't reproduce it.

I installed sddm and defined it as the default login manager (I was
prompted to do so during the installation, then I installed fish and
set it as the default shell using chsh.  Finally, I restarted the
system and logged in from the sddm login screen.

Alf,

Are you still seeing this bug you reported?
(maybe it was solved elsewhere...  sorry for taking so long to look)

I'm also running debian unstable.

Bug#921598: fixed in simgear 1:2018.3.2+dfsg-5

[Gabriel F. T. Gomes]

On Sun, 17 Feb 2019 20:54:34 + to...@debian.org (Dr. Tobias Quathamer) 
wrote:
> Source: simgear
> Source-Version: 1:2018.3.2+dfsg-5
> 
> We believe that the bug you reported is fixed in the latest version of
> simgear, which is due to be installed in the Debian FTP archive.

Thanks for this simgear fix.

I tested that rebuilding flightgear with this dependency updated solves
the METAR problem.  Do you plan to upload a new binary version of
flightgear, too?  (I'm asking because the flightgear package currently
on the archives still has the problem (probably because it needs to be
rebuilt - should a rebuild happen automatically?)).

Bug#867734: $ set $(cat /tm

[Gabriel F. T. Gomes]

Hi, I see that you forwarded this upstream as
https://github.com/scop/bash-completion/issues/282

I'm adding this note here for easier reference.

Bug#923005: nmu: flightgear 1:2018.3.2+dfsg-2

[Gabriel F. T. Gomes]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu: flightgear_1:2018.3.2+dfsg-2 . ANY . unstable . -m "rebuild against 
libsimgear-dev 1:2018.3.2+dfsg-5"

Fetching of 'live weather' data was broken on flightgear, as reported in
https://bugs.debian.org/921598#5.  The fix is not in flightgear itself,
but in libsimgear-dev, which flightgear build-depends upon.  Recently,
libsimgear-dev was updated (with the fix) on the archive, and now
flightgear needs to be rebuilt for the fix to be effective to users.

I have manually built flightgear with the updated libsimgear-dev, on
x86_64, and I confirm that it actually fixes the problem.

Thanks,
Gabriel

Bug#921598: fixed in simgear 1:2018.3.2+dfsg-5

[Gabriel F. T. Gomes]

On Wed, 20 Feb 2019 00:53:18 -0300 "Gabriel F. T. Gomes" 
 wrote:
>
> I tested that rebuilding flightgear with this dependency updated solves
> the METAR problem.  Do you plan to upload a new binary version of
> flightgear, too?  (I'm asking because the flightgear package currently
> on the archives still has the problem (probably because it needs to be
> rebuilt - should a rebuild happen automatically?)).

I learned about binNMUs (thanks tarpman@OFTC) and I learned that such
rebuilds are not automatically triggered, but must be manually request
via a bug report against the release.debian.org package.

I have created such request as https://bugs.debian.org/923005

I think I got it right, but I'll check once the build is done and if
you could also check that it fixes the problem for yourselves, that
would be good.

Thanks,
Gabriel

Bug#921962: Please remove obsolete 'xm' completion file

[Gabriel F. T. Gomes]

On Tue, Feb 12 2019, Hans van Kranenburg wrote:
> On 2/12/19 1:35 AM, Gabriel F. T. Gomes wrote:
> > 
> > That should be easy to do for Debian.  On the other hand, I wonder if I
> > should work first with upstream to get it removed from there.  Do you
> > know if the deprecation of xm is debian-specific?  Or has it been
> > deprecated and removed by the xen project?
> 
> There is no xm bash completion upstream any more.
> 
> Also, quoting upstream wiki about this:
> 
> https://wiki.xen.org/wiki/Choice_of_Toolstacks
> 
> "Deprecated in Xen 4.1; Removed in 4.5"

Thanks for the information.  I have forwarded this upstream as
https://github.com/scop/bash-completion/pull/284

> Stretch has Xen 4.8, Buster will have at least Xen 4.11.
> 
> So, there's really no reason to just throw this xm file into the
> wastebin asap. :)

I see.  It would be easier, from a maintenance perspective, to wait for
the upstream patch to be accepted, then released in bash-completion 2.9,
then updated in Debian, instead of backporting this specific fix.

It is my understanding that having the completion for the unavailable
command is not so harmful, and that we could ship it with buster, even
though it is useless.  Not ideal, but easier for maintenance.  Would
that be OK for you, or is it causing more trouble than I can actually
see (I don't use Xen, so I don't know).

Bug#923210: bash-completion: postinst and postrm generate find warnings

[Gabriel F. T. Gomes]

On Sun, Feb 24 2019, Daniel Lewart wrote:
> Package: bash-completion
> Version: 1:2.8-5
> Severity: minor
> Tags: patch
> 
> Both "apt install bash-completion" and "apt purge bash-completion"
> generate the following warning:
>   find: '/etc/bash_completion.d/': No such file or directory
> 
> The cause is that postinst and postrm assume that
> /etc/bash_completion.d exists.
> 
> Patch is attached.

Thanks.

I have a comment about a hunk in the patch and a question, here:

Is it safe to upload such a change so close to the freeze?  I'm always
worried about unforeseen side-effects.

> diff -ru a/debian/postinst b/debian/postinst
> --- a/debian/postinst 2018-12-21 19:23:09.0 -0600
> +++ b/debian/postinst 2019-02-24 00:00:00.0 -0600
> @@ -4,19 +4,21 @@
>  
>  case "$1" in
>  configure)
> -# let's remove old bash-completion conffiles
> -for f in $(find /etc/bash_completion.d/ -type f -name "*.dpkg-*"); do
> -dpkg-maintscript-helper rm_conffile ${f%.dpkg-*} 1:1.3-1 -- "$@"
> -done
> +if [ -d /etc/bash_completion.d ]; then
> +# let's remove old bash-completion conffiles
> +for f in $(find /etc/bash_completion.d/ -type f -name 
> "*.dpkg-*"); do
> +dpkg-maintscript-helper rm_conffile ${f%.dpkg-*} 1:1.3-1 -- 
> "$@"
> +done

OK.

> -if dpkg --compare-versions "$2" le "1:2.1-3"; then
> -if [ -d /etc/bash_completion.d/helpers ]; then
> -rmdir --ignore-fail-on-non-empty 
> /etc/bash_completion.d/helpers 2>/dev/null
> +if dpkg --compare-versions "$2" le "1:2.1-3"; then
> +if [ -d /etc/bash_completion.d/helpers ]; then
> +rmdir --ignore-fail-on-non-empty 
> /etc/bash_completion.d/helpers 2>/dev/null
> +fi
> +# disabled from Ubuntu, third party packages might have 
> installed things here
> +#if [ -d /etc/bash_completion.d ]; then
> +#rmdir --ignore-fail-on-non-empty /etc/bash_completion.d 
> 2>/dev/null
> +#fi
>  fi
> -# disabled from Ubuntu, third party packages might have 
> installed things here
> -#if [ -d /etc/bash_completion.d ]; then
> -#rmdir --ignore-fail-on-non-empty /etc/bash_completion.d 
> 2>/dev/null
> -#fi
>  fi
>   ;;
>  abort-upgrade|abort-remove|abort-deconfigure)

Is this hunk needed?  The test (-d /etc/bash_completion.d/helpers) is
not likely to produce the warnings you mentioned.

> diff -ru a/debian/postrm b/debian/postrm
> --- a/debian/postrm   2018-12-21 19:23:09.0 -0600
> +++ b/debian/postrm   2019-02-24 00:00:00.0 -0600
> @@ -5,10 +5,12 @@
>  case "$1" in
>  purge)
>   rm -f /etc/bash_completion
> -# let's remove old bash-completion conffiles
> -for f in $(find /etc/bash_completion.d/ -type f -name "*.dpkg-*"); do
> -dpkg-maintscript-helper rm_conffile ${f%.dpkg-*} 1:1.3-1 -- "$@"
> -done
> + if [ -d /etc/bash_completion.d ]; then
> +# let's remove old bash-completion conffiles
> +for f in $(find /etc/bash_completion.d/ -type f -name 
> "*.dpkg-*"); do
> +dpkg-maintscript-helper rm_conffile ${f%.dpkg-*} 1:1.3-1 -- 
> "$@"
> +done
> + fi
>   ;;
>  remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
>   ;;

OK.

Bug#923878: bash-completion: unrar completion doesn't suggest *.rar files immedietly, but requires options first (uneeded)

[Gabriel F. T. Gomes]

On Wed, Apr 10 2019, Witold Baryluk wrote:
> 
> I am using a free version of unrar, in package unrar-free in main repo of 
> Debian:
> 
> [...]
> 
> $ unrar-free --version
> unrar 0.0.1
> $ unrar --version
> unrar 0.0.1

Oh, I see.  Thanks for the explanation.

> Note that OPTION part is optional, i.e. -x / --extract is default.

I guess you are right.  I'll work on it.

Bug#981855: bash completion for man fails to identify manpages for subcommands ("man git bis" should complete to "man git bisect ")

[Gabriel F. T. Gomes]

On Thu, 04 Feb 2021, Daniel Kahn Gillmor wrote:
>
> (as i was writing this report, i realized that it's probably mainly an
> upstream bug, so i filed it at the URL above, but i figure it's worth
> tracking in the BTS as well since it affects other packages)

Thanks, and I agree. :)

Bug#988975: bash-completion: Wrong completion after some certain words such as TZ, TERM and LANG

[Gabriel F. T. Gomes]

Control: tags -1 + fixed-upstream

Koichi Murase kindly pointed out that this has already been fixed upstream:

  https://github.com/scop/bash-completion/issues/590#issuecomment-906045204

This patch has not been integrated into a release, yet:

  $ git describe --tags 79a504a
  2.11-81-g79a504a4

I'll downstream the patch soon.


Thanks

Bug#985151: dh_bash-completion: treats nitrokey-app file list as script

[Gabriel F. T. Gomes]

Hi, Kevin,

On Sat, 13 Mar 2021, Kevin Locke wrote:
> 
> I've attached a patch to fix the issue by requiring complete to follow a
> line break or semicolon.  It obviously does not address the root of the
> problem of reliably differentiating a list of paths from a Bash script.
> (Which is not really possible, since a list of paths is a valid bash
> script.)  But it may be a sufficient quick fix until/unless #785271 is
> addressed.

I'm not sure we will ever be able to correctly detect everything...
Anyhow, your patch looks not only sufficient, but correct on its own.
I'll check if it works correctly with the scripts currently installed
under my /usr/share/bash-completion.

Also, the detection algorithm has been kindly written by sergiodj (CC),
so I'll give him some time to weigh in, then I'll apply your fix. 

> Thanks for considering,

Thank you!

Cheers,
Gabriel

Bug#985151: dh_bash-completion: treats nitrokey-app file list as script

[Gabriel F. T. Gomes]

On Mon, 15 Mar 2021, Gabriel F. T. Gomes wrote:
>
> I'll check if it works correctly with the scripts currently installed
> under my /usr/share/bash-completion.

Perhaps we could also add && and || as command termination characters,
so that idioms like the following also get detected:

  complete -o bashdefault -o default -o nospace -F $wrapper $1 2>/dev/null \

|| complete -o default -o nospace -F $wrapper $1
  
  (from /usr/share/bash-completion/completions/gitk)

  test -s /usr/share/osc/complete && complete -o default -C 
/usr/share/osc/complete osc
  (from /usr/share/bash-completion/completions/osc)

Bug#985151: dh_bash-completion: treats nitrokey-app file list as script

[Gabriel F. T. Gomes]

On Mon, 15 Mar 2021, Kevin Locke wrote:
>
> Which appears to be a common idiom for only defining the function and
> completion if the command is in $PATH.  I've attached an updated version
> which matches & and | in addition to ; as command separators.  We may
> also want to consider modifying the compgen expression in the same way.

Oh, thank you!! We both noticed it! :)

Cheers,
Gabriel

Bug#985151: dh_bash-completion: treats nitrokey-app file list as script

[Gabriel F. T. Gomes]

Hi, Kevin,

On Mon, 15 Mar 2021 07:07:36 -0600
Kevin Locke  wrote:
>
> I've attached an updated version
> which matches & and | in addition to ; as command separators.  We may
> also want to consider modifying the compgen expression in the same way.

I added this patch (with a changelog entry) to the repository at:

https://salsa.debian.org/debian/bash-completion/-/commits/master

Then I tested it against as much packages as possible:

  # Download packages that have some completion file (get the list from 
apt-file)
  apt-file search "/usr/share/bash-completion/completions" | cut -d ':' -f 1 | 
sort -u | tr '\n' ' ' | xargs apt-get source -y
  
  # Unpack all
  for file in *.deb; do dpkg-deb --extract $file extract/; done

  # Run each package.bash-completion file against a simplified version
  # of the perl script [1] (with and without this change)
  for i in `find -name *.bash-completion`; do echo $i; perl 
/var/tmp/build-root/test-me/root/perl-pre.pl < $i; done > _result.pre
  for i in `find -name *.bash-completion`; do echo $i; perl 
/var/tmp/build-root/test-me/root/perl-pos.pl < $i; done > _result.pos

  # Compare the results
  diff -u1 _result.{pre,pos}
   ./nitrokey-app-1.4.2/debian/nitrokey-app.bash-completion
  -Yes
  +No


So, the change seems to affect nitrokey-app only, which is fine...

Nevertheless, I haven't released this to unstable, because of the
freeze... I'm worried that this change could undesired side-effects
(such as making other packages loose their completions) at this point
of the release cycle, even though the test is telling me it won't.

Let me know your thoughts (about this and/or about the tests I ran).


I'll submit it to experimental, then, once the freeze is lifted, to
unstable.


Cheers,
Gabriel


[1] The simplified version of the modified perl script:

while () {
# Get rid of lines containing just spaces or comments.
chomp;
s/^\s++//;
next if /^#/;
s/\s++$//;

# We always ignore/permit empty lines
next if $_ eq '';

# This is the heart of the script.  Here, we check for some
# well-known idioms on bash scripts, and try to determine if
# they're present in the file we're examining.  We assume that
# if they are, then this means the file is a bash-completion
# script.
#
# The regexes check:
#
# - If we're calling the bash function "complete", which is a
#   pretty common thing to do in bash-completion scripts, or
#
# - If we're using the $(program) way of executing a program.
#   We don't take into account multi-line statements.  Or
#
# - If we're calling the bash function "compgen", which is
#   also a pretty common thing that bash-completion scripts
#   do.  Or
#
# - If we see an "if...then" construction in the file.  We
#   take into account multi-line statements.
if (/(^|[|&;])\s*complete.*-[A-Za-z].*/
|| /\$\(.*\)/
|| /\s*compgen.*-[A-Za-z].*/
|| /\s*if.*;.*then/s) {
print "Yes\n";
exit 0;
}
}
print "No\n";
exit 0;

Bug#986861: pragha: No way of sorting album by track number

[Gabriel F. T. Gomes]

Hello, Pelle,

On Tue, 13 Apr 2021 00:12:40 +0200
Pelle  wrote:
>
> It appears there is no way to sort an album (or several albums in a playlist)
> by track order. The available column headers for sorting are 'Title', 
> 'Artist',
> 'Album' and 'Length'.

These are the default columns, indeed.

> When clicking on 'Album' to sort the tracks into albums,
> the track order within those albums will be either alphabetical by title or by
> length, depending on what sort mode was previously selected.

Right.

> I expected it
> would be possible to sort the playlist by track order within their respective
> albums so they could be played in the order the appear on the album(s).

To bring more columns into view, you can right click on any column
header, which will pop the list of available columns up, then select
the 'Track' item. Afterwards you will be able to sort by track, then
sort by album; then the songs within the album will also be sorted by
track number.

Let me know if that doens't work for you.

Cheers,
Gabriel

Bug#961660: Cause is have() Wrapper Function of Function _have()

[Gabriel F. T. Gomes]

Hello Jürgen,

thanks for following up on this bug.

On Mon, 23 Aug 2021 13:11:28 +0200
Jürgen Kuri  wrote:
>
> If have() is used AND bash-completion script is stored into directory
> 
>   /usr/share/bash-completion/completions

I'm still trying to reproduce the problem, so...

I copied the file that you attached to message #15 [1,2] into
/usr/share/bash-completion/completions/fsmtool2, as can be verified in
the following snippet:

  $ head /usr/share/bash-completion/completions/fsmtool2
  have fsmtool2 && {
  _fsmtool2_commands() {
COMPREPLY=( $(compgen -W "help showconfig showfiles showfileslex deleteall" 
-- $1) )
  }
  
  _fsmtool2()
  {
local areas command cur
cur=${COMP_WORDS[COMP_CWORD]}
command=${COMP_WORDS[1]}

Then, I tried basic completion:

  $ fsmtool2 
  deleteall help  showconfigshowfiles showfileslex  

i.e.: it completes with the basic commands correctly.

If I try to complete the second word, then it doesn't work, but that's
because I don't have the configuration file under /etc and I believe
that this is unrelated to your problem:

  $ fsmtool2 showconfig 
  grep: /etc/fsmd2/fsmd2.conf: No such file or directory

> completion does not work anymore.

Perhaps this only works for me because I'm running sid and testing?
But it does work for me.

I will create a chroot with old-stable (buster) to check if older
versions of bash-completion have this problem.

> If we replace have() by _have() or simply remove it in the bash completion 
> script (like many other do) it will work in both storage paths.

Can you do that?
I mean, does it fix the problems you are hitting?

While I understand that installing things under /etc/bash_completion.d/
made things work for you, we can't change dh_bash-completion to install
things under that directory. dh_bash-completion must install to
/usr/share/bash-completion/completions.


Cheers,
Gabriel


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961660#15
[2] 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=961660;filename=fsmtool2-completion;msg=15

Bug#961660: Cause is have() Wrapper Function of Function _have()

[Gabriel F. T. Gomes]

On Mon, 23 Aug 2021 19:36:34 -0300
"Gabriel F. T. Gomes"  wrote:
>
> I will create a chroot with old-stable (buster) to check if older
> versions of bash-completion have this problem.

Indeed, now I was able to reproduce it.

And yes, using _have instead of have does fix the problem.

So, would you be willing to make that change in your scripts? It looks
like the right thing to do anyway.


Cheers,
Gabriel

Bug#961660: Cause is have() Wrapper Function of Function _have()

[Gabriel F. T. Gomes]

Thanks for the update.

I'll close the bug report now. Feel free to reopen it if anything else pops-up.

Bug#988975: bash-completion: Wrong completion after some certain words such as TZ, TERM and LANG

[Gabriel F. T. Gomes]

Control: tags -1 + confirmed upstream

The change in behavior is caused by the following upstream commit:

  
https://github.com/scop/bash-completion/commit/d1756f06ef9bffb1b4621c4e63e47e181ddf1086

which got released in upstream version 2.10.

Bug reported submitted upstream as 
https://github.com/scop/bash-completion/issues/590


Cheers,
Gabriel

On Sat, 22 May 2021 17:59:29 +0800
WHR  wrote:

> Package: bash-completion
> Version: 1:2.11-2
> Severity: important
> X-Debbugs-Cc: msl023...@gmail.com
> 
> This version has a bug that didn't exist in previous Debian release (Buster).
> The completion becomes wrong after certain words; for exmaple I want to
> search for word 'TERM' in a file, so I typed (^ indicates cursor position):
> 
> grep -F TERM 
>  ^
> 
> however the completion here doesn't give the expected result, of listing
> files in the working directory, but instead:
> 
> $ grep -F TERM 
> Display all 1750 possibilities? (y or n)
> 9termhp2  screen.linux-m1
> Etermhp236screen.linux-m1b
> Eterm-256color   hp2382a  screen.linux-m2
> Eterm-88colorhp2392   screen.minitel1
> MtxOrb   hp2397a  screen.minitel1-nb
> ...
> 
> It appears that bash wrongly completed this as the TERM environmet variable,
> which is obviously incorrect here.
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.147-rivoreo-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> -- no debconf information

Bug#881719: libcdio 2.1.0 and lubcdio++

[Gabriel F. T. Gomes]

Hi, Vasyl,

on 24 May 2020, Vasyl Gello wrote:
>
>Gabriel has prepared 2.1.0 in his Salsa repo and I added C++ interfaces needed 
>by Kodi 19.0: 
>https://salsa.debian.org/gabrielftg-guest/libcdio/-/merge_requests/1

Thank you so much for writing this pull requests. I wasn't aware that
there was a C++ interface in libcdio. I'm actually very new to libcdio;
I only came across it because it is a dependency of another project
(pragha) that I mantain.

I'll review your merge request as soon as possible, then I'll prepare a
package for uploading. Initially, and because I was a little
uncomfortable with the soname change, I thought about uploading to
experimental first. Would that work for you?

>Can the version 2.1.0 be pushed into distribution?

Please bear in mind that we will have to go through the NEW queue,
because of the new binary packages (not just the C++ libraries, but
also because of the soname bump on the C library).


Cheers,
Gabriel

Bug#961660: DebHelper dh_bash-completion broken since Stretch OS, Bash Completion scripts not installed anymore into Path according to debian/.bash-completion

[Gabriel F. T. Gomes]

On 27 May 2020, Jürgen Kuri wrote:
>
>When I build the packages for Debian Jessie, everything works as expected, 
>both completion scripts are installed into the path:
>
>   $  ls -la /etc/bash_completion.d/
>   total 24
>   drwxr-xr-x  2 root root  4096 May 26 16:58 .
>   drwxr-xr-x 92 root root  4096 May 18 12:12 ..
>   -rw-r--r--  1 root root   933 May 18 17:26 fsmtool2-completion
>   -rw-r--r--  1 root root   980 May 18 17:26 fsmtool2_mtest-completion

For some time (I don't know exactly how long, because I only adopted
bash-completion about 2 years ago), the default installation path for
completion is /usr/share/bash-completion/completions/, as you have
noticed. So, I'd say that dh_bash-completion is doing the rigth thing.

>When I build the packages for Debian OS Stretch or Buster, bash-completion 
>does not work for both command line tools any more cause the completion 
>scripts are installed below:
>
>   * /usr/share/bash-completion/completions/fsmtool2-completion 
>   * /usr/share/bash-completion/completions/fsmtool2_mtest-completion 

On the other, you are saying that the completions do not work from this
location, and that's puzzling me. Could you provide more details about
the problem you are actually getting? Bash-completion is supposed to
work with files in this location.


Cheers,
Gabriel

Bug#881719: libcdio 2.1.0 and lubcdio++

[Gabriel F. T. Gomes]

Hi, Vasyl,

On 24 May 2020, Vasyl Gello wrote:
>
>Yes experimental is OK for me, even though I uploaded libshairplay & 
>libudfread to unstable queue. Balint asked me initially to target Kodi 19.0 to 
>experimental so I will probably re-upload both libraries to experimental to 
>keep everything consistent.

Awesome.

I accepted your merge request and I prepared the package for
experimental. It will take a while to get there though, because I'm not
a DD yet (my process is still ongoing), so we will need a sponsor.

Also, since it adds new binary packages, it will also have to go
through the new queue.


Cheers,
Gabriel

Bug#881719: libcdio 2.1.0 and lubcdio++

[Gabriel F. T. Gomes]

On 31 May 2020, Gabriel F. T. Gomes wrote:
>
>we will need a sponsor.

The package is now on mentors:

https://mentors.debian.net/package/libcdio

Balint, could you review it and, if everything is fine, sponsor it?
(I'm asking because Vasyl mentioned you are guiding the packaging of
Kodi, if I got it right)


Cheers,
Gabriel

Bug#881719: libcdio 2.1.0 and lubcdio++

[Gabriel F. T. Gomes]

On 01 Jun 2020, Bálint Réczey wrote:
>
>I've checked the package and it refers to
>https://salsa.debian.org/debian/libcdio as the packaging repo while it
>is not present.
>I fyou agree let me clone your packaging repo there, then I can review
>the changes.

Oh, please. And thank you. :)

>I can't upload in the next few days (weeks?) because my keys are
>expired and I'm waiting for the next keyring push to get them
>refreshed.

No problem.


Cheers,
Gabriel

Bug#881719: libcdio 2.1.0 and lubcdio++

[Gabriel F. T. Gomes]

On Tue, 02 Jun 2020, Bálint Réczey wrote:
>
> Done. I've omitted the last commit because I suggest using -1~exp0
> Debian version for the upload to experimental. IMO looks nicer when
> the upload to unstable has -1.

Thanks for the review. I'll fix this, then upload again to mentors.

Bug#958981: ITP: xreader -- A generic document reader

[Gabriel F. T. Gomes]

Hi, Hugo,

thanks for starting the work on this package.  I'll be around if you
need help with packaging stuff, and I'll review your work when you have
something ready to share.

Cheers,
Gabriel

Bug#877450: RFS: bash-completion/1:2.7-1 [ITA]

[Gabriel F. T. Gomes]

Hi, Andreas,

Does this new version correctly addresses your concerns about the
missing NMUs?  (And are there any other NMUs which I might have failed
to find?)

Thank you,
Gabriel

On 23 Oct 2017, Gabriel F. T. Gomes wrote:

>On 10 Oct 2017, Andreas Henriksson wrote:
>
>>You seem to have missed to incorporate all the NMUs of
>>bash-completion... (atleast they where not part of the
>>debian/changelog) Is there any reason why you did not include those
>>changes? Won't your updated version conflict with packages who now
>>ships their own bash completion files (that where dropped in the
>>bash-completion NMUs)?  
>
>I just uploaded a new version with all three NMUs incorporated [1].
>(I also updated the git repository (one commit per NMU) [2]).
>
>Could you review the package, again, please?
>
>[1] https://mentors.debian.net/package/bash-completion
>
>[2]
>http://git.inconstante.eti.br/?p=bash-completion-debian.git;a=shortlog;h=refs/heads/unstable
>

Bug#892147: Please create the Pragha package with complete audio (api) support

[Gabriel F. T. Gomes]

Hi, Jürgen Göricke,

Have you tried to do what I suggested? (i.e.: Change the "Audio Device"
in pragha settings to "hw:1" or "default:1")


pgpt6JOT2ujxZ.pgp
Description: OpenPGP digital signature

Bug#892147: Please create the Pragha package with complete audio (api) support

[Gabriel F. T. Gomes]

On Wed, 04 Apr 2018, Jürgen Göricke wrote:

>I have installed only a ALSA instance (alsa-tools alsa-utils and 
>gstreamer1.0-alsa) on my system.
>In the Pragha settings I have selected Alsa as my audio system.
>There is no pulse audio on my system.

OK.

>In my case I can't do a live stream, for example Classic FM from London 
>(http://media-ice.musicradio.com/ClassicFMMP3.m3u)
>Pragha reports (see screenshot) that a gstreamer plugin is missing

I tested it in my system, which has pulseaudio and this doesn't work
either...  So, I'm guessing that this is not a problem specific to alsa.

I don't know how to solve that, yet, but I'll investigate.

Thanks for the additional information! :)

>I hope my information helps you to narrow the problem down a bit?

It does! :)

>If you have any further questions, I will try to answer them as soon as 
>possible!

Just to confirm, have you tried to play an audio file (a .ogg file, for
instance)?  Did it work?  (I'm asking to be sure that the problem is only
when playing from online radios).

Bug#876095: Still active?

[Gabriel F. T. Gomes]

On Tue, 23 Jan 2018, Salvo Tomaselli wrote:

>It has been a few months since this ITA, but the package hasn't seen
>any updates and it is still owned by David Paleino.

I have opened an RFS [1], which received most (if not all) of the more
recent emails/activity.  I also marked that RFS as a blocker of this ITA,
however, this kind of information is somewhat hard to see [2].

[1] https://bugs.debian.org/877450

[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876095#30

>Are you still serious about adopting it?

Yes, definitely.  I'm currently waiting for a sponsor.  Maybe it's time to
ping again.

Bug#888090: bash-completion: Allow to run python zipapp (pyz files)

[Gabriel F. T. Gomes]

Hi, Salvo,

I have just now noticed this bug report.

Although I'm not yet the maintainer of bash-completion, I have an ITA
opened for it.  While adopting the package, I'm also upgrading
bash-completion to a newer version, which I believe solves the problem you
reported.

I'll mark this bug as fixed in the changelog, so that it gets
automatically closed.

Thanks for reporting the bug (and for the help with packaging).
Gabriel

On Tue, 23 Jan 2018, Salvo Tomaselli wrote:

>Package: bash-completion
>Version: 1:2.1-4.3
>Severity: normal
>Tags: patch
>
>Dear Maintainer,
>
>Currently the completion does not support python zipapp files. This means that
>tab doesn't complete them at all and I need to ls and then copy-paste the name
>of the file.
>
>Here's a patch to fix this.
>
>Best
>
>-- System Information:
>Debian Release: 9.3
>  APT prefers stable
>  APT policy: (500, 'stable')
>Architecture: amd64 (x86_64)
>Foreign Architectures: i386
>
>Kernel: Linux 4.9.0-5-amd64 (SMP w/4 CPU cores)
>Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: 
>LC_ALL set to it_IT.UTF-8), LANGUAGE=it (charmap=UTF-8) (ignored: LC_ALL set 
>to it_IT.UTF-8)
>Shell: /bin/sh linked to /bin/dash
>Init: systemd (via /run/systemd/system)
>
>Versions of packages bash-completion depends on:
>ii  bash  4.4-5
>ii  dpkg  1.18.24
>
>bash-completion recommends no packages.
>
>bash-completion suggests no packages.
>
>-- no debconf information

Bug#877450: RFS: bash-completion/1:2.7-1 [ITA] (was: Changes coming with VCS for Debian packaging)

[Gabriel F. T. Gomes]

On 03 Feb 2018, Juhani Numminen wrote:
>
>Quick note regarding debian/rules (which I only read online).
>https://salsa.debian.org/debian/bash-completion/blob/unstable/debian/rules
>
>debhelper(7) manpage tells me that autoreconf is enabled by default
>since compat 10, which means that "--with autoreconf" is not needed
>anymore.

Thanks, this is now fixed by:

https://salsa.debian.org/debian/bash-completion/commit/10ec55ff1c54543320b012b466b9e48c7e8611de

>Instead of doing version parsing the hard way, could you perhaps
>include /usr/share/dpkg/pkg-info.mk and use a suitable variable that
>it defines?

Indeed, but you also made me realize that the manpage was not being
re-generated, because the output (dh_bash-completion.1) was versioned
and not listed as a target dependency on debian/rules.

What do you think of the following change:

diff --git a/debian/extra/debhelper/dh_bash-completion.1 
b/debian/extra/debhelper/dh_bash-completion.1
deleted file mode 100644
index 82cde8b..000

diff --git a/debian/rules b/debian/rules
index 5ab9a19..8f7fb55 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,7 +4,8 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-VERSION=$(shell parsechangelog | grep ^Version | awk -F": " '{print $$2}' | 
cut -d"-" -f1)
+include /usr/share/dpkg/pkg-info.mk
+
 REMOVE=adb bts nmcli hwclock ionice mock modules mount rtcwake dmesg renice 
umount
 
 override_dh_auto_configure:
@@ -23,10 +24,10 @@ override_dh_installchangelogs:
 dh_bash-completion.1: debian/extra/debhelper/dh_bash-completion
pod2man \
--center "Bash-Completion Debhelper" \
-   --release $(VERSION) \
+   --release $(DEB_VERSION_UPSTREAM) \
$< > debian/extra/debhelper/$@
 
-override_dh_install:
+override_dh_install: dh_bash-completion.1
dh_install
for i in $(REMOVE); do \
rm -vf 
debian/bash-completion/usr/share/bash-completion/completions/$$i; \


Cheers,
Gabriel

Bug#876667: RFS: pragha/1.3.3-1

[Gabriel F. T. Gomes]

On Fri, 06 Oct 2017, Breno Leitao wrote:

>I am just doing a final review for the sponsor, and I found something
>that annoys every developer, it seems that pragha does not re-builds
>after an initial build.
>
>It builds fine for the very first time, but if you try to re-build, the
>directory stays dirty and does not allow the package to be rebuilt:
>
>This is what I tried:
>
>$ get -x
>https://mentors.debian.net/debian/pool/main/p/pragha/pragha_1.3.3-1.dsc
>
>$ cd pragha-1.3.3 
>
>$ debuild ; debuild
>
>You are going to see something like:
>
>   dpkg-source: error: cannot represent change to po/bg.gmo: binary file 
> contents changed
>   dpkg-source: error: add po/bg.gmo in debian/source/include-binaries if 
> you want to store the modified binary in the debian tarball
>
>This means that your clean rules is not cleaning everything that was
>generated during the build process.

Thanks for taking the time to write these steps.  I can easily reproduce
this on my machine.

I'll prepare a new version with that fixed.

Bug#876667: RFS: pragha/1.3.3-1

[Gabriel F. T. Gomes]

On 10 Oct 2017, Gabriel F. T. Gomes wrote:

>On Fri, 06 Oct 2017, Breno Leitao wrote:
>>
>>This means that your clean rules is not cleaning everything that was
>>generated during the build process.  
>
>I'll prepare a new version with that fixed.

Hi, Breno, Lukas,

I have fixed the problem with the clean rules.  It now succeeds when
rebuilding (debuild ; debuild).

I pushed a new version to mentors.  Could you review the package again?

https://mentors.debian.net/package/pragha

Thank you,
Gabriel

Bug#877450: RFS: bash-completion/1:2.7-1 [ITA]

[Gabriel F. T. Gomes]

On Tue, 10 Oct 2017, Andreas Henriksson wrote:

>You seem to have missed to incorporate all the NMUs of
>bash-completion... (atleast they where not part of the
>debian/changelog) Is there any reason why you did not include those
>changes?

No reason, other than sheer inexperience. :)

I'll look into these NMUs, then I'll come with a newer version, with
them incorporated.

>Won't your updated version conflict with packages who now ships their
>own bash completion files (that where dropped in the bash-completion
>NMUs)?

Definitely.  I'll fix this in the new version.

Bug#877450: RFS: bash-completion/1:2.7-1 [ITA]

[Gabriel F. T. Gomes]

On 10 Oct 2017, Andreas Henriksson wrote:

>You seem to have missed to incorporate all the NMUs of
>bash-completion... (atleast they where not part of the
>debian/changelog) Is there any reason why you did not include those
>changes? Won't your updated version conflict with packages who now
>ships their own bash completion files (that where dropped in the
>bash-completion NMUs)?

I just uploaded a new version with all three NMUs incorporated [1].
(I also updated the git repository (one commit per NMU) [2]).

Could you review the package, again, please?

[1] https://mentors.debian.net/package/bash-completion

[2] 
http://git.inconstante.eti.br/?p=bash-completion-debian.git;a=shortlog;h=refs/heads/unstable

Bug#877450: RFS: bash-completion/1:2.7-1 [ITA]

[Gabriel F. T. Gomes]

On 05 Feb 2018, Juhani Numminen wrote:

>I think you will also need to clean up the generated file, e.g. put it
>into debian/clean.

Indeed.  All these changes are now pushed as:

https://salsa.debian.org/debian/bash-completion/commit/1bbccc5353cbe2bb85bc9f487a632cace01c8aa9

As usual, the file at mentors was updated accordingly:

https://mentors.debian.net/debian/pool/main/b/bash-completion/bash-completion_2.7-1.dsc

Thanks,
Gabriel

Bug#811496: All the ones I have added have entries in /etc/bash-completion.d/ and not either in /usr/share/bash-completion nor in /usr/share/zsh/vendor-completions :(

[Gabriel F. T. Gomes]

Hi,

I am in the process of adopting bash-completion and I just saw this bug
(as well as bug 815563).

I haven't made any changes to bash-completion that would address what's
reported in this bug, because I think it has already been solved by
668254 (NMU for bash-completion 2.1-4.2).

Did I get something wrong?

On Sun, 22 Jan 2017 17:15:09 +0530
=?UTF-8?B?c2hpcmlzaCDgpLbgpL/gpLDgpYDgpLc=?=  wrote:
> Hi all,
> 
> While many of them don't report a bug via adequate all of them have
> entries in /etc/bas_completion.d/
> 
> I purged each package and then installed it manually and if still they
> were in /etc/bash_completion.d/ have shared those package names.
> 
> ─[$] adequate scilab-cli
>   [$]
> 
> [$] dpkg -L scilab-cli | grep zsh
> [$]
> 
> [$] dpkg -L scilab-cli | grep bash
> 
> /etc/bash_completion.d
> /etc/bash_completion.d/scilab
> 
> And all these are after purging and installing the individual packages.
> 
> Hope it helps.
> 
> -- 
>   Regards,
>   Shirish Agarwal  शिरीष अग्रवाल
>   My quotes in this email licensed under CC 3.0
> http://creativecommons.org/licenses/by-nc/3.0/
> http://flossexperiences.wordpress.com
> EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8
> 
> 

Bug#890267: URL check by cme reports that salsa.debian.org is not canonical

[Gabriel F. T. Gomes]

Package: cme
Version: 1.026-1

Running 'cme check dpkg' on a package maintained with git and that has
already moved the repository to salsa.debian.org produces warnings for
the fields 'Vcs-Browser' and 'Vcs-Git'.  The warning states that the
"URL is not the canonical one for repositories hosted on Alioth".

This is the output of 'cme check dpkg' for bash-completion ITA:

  $ cme check dpkg
  cme: using Dpkg model
  loading data
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  Warning in 'control source Vcs-Browser' value 
'https://salsa.debian.org/debian/bash-completion': URL is not the canonical one 
for repositories hosted on Alioth.
  Warning in 'control source Vcs-Git' value 
'https://salsa.debian.org/debian/bash-completion.git': URL is not the canonical 
one for repositories hosted on Alioth.
  checking data
  check done

Should salsa.debian.org also be considered a canonical URL now that it
is out of beta [1]?

[1] https://lists.debian.org/debian-devel-announce/2018/01/msg4.html

Bug#892147: Please create the Pragha package with complete audio (api) support

[Gabriel F. T. Gomes]

On 22 Apr 2018, Jürgen Göricke wrote:

>I can also resolve the URL with curl and play it back with the
>gstreamer framework

Ack.  That's valuable information for me.

>but directly in pragha the link extracted with
>curl is not played back. At least the artist's name, the title played
>and the channel in the pragha are resolved as text, but unfortunately
>no music is played.

That's very curious, but at least it means that gstreamer is able to
read something from the parsed URL. :)

>And yes, the volume control in pragha _and_ the
>system is set to full volume.

Hehehe, thanks for checking and for reporting this, too.

>Small additional information, in audacious I can play any online
>streaming link immediately with curl, or similar workarounds without
>any effort. I also got this package from the Debian repository.

OK, thanks for checking.

>It would be nice, though, if pragha could also enable problem-free
>playback of the live streaming sources.

Indeed and I'll probably need a little help from you to try and
reproduce it on my system.

>How else can I help you to find the problem?

Since I want to reproduce the problem on my system, I need to learn how
to make a pulseaudio-free installation, so that I can have a system
similar to yours (my system has the full XFCE stack installed and it
brings pulseaudio by default, I think).

So...  When and if you can spare some time, could you please tell me
what you use on your system?

Did you install with debootstrap, netinst?
Which window manager (so I don't get pulseaudio unintentionally)?
Which audio related packages you installed (gstreamer*, *alsa*)?
Any other packages you believe I should pay attention to?

Please feel free to ignore my request if you don't wish to give that
many details about your computer (I honestly don't know if my request
is intrusive, hehehe).


Cheers,
Gabriel

Bug#892307: fixed in bash-completion 1:2.8-1

[Gabriel F. T. Gomes]

On 02 Apr 2018, Paul Wise wrote:

>On Sun, 2018-04-01 at 18:19 +0000, Gabriel F. T. Gomes wrote:
>
>>* Fix regression when MANPATH is set with colons (Closes:
>> #892307)  
>
>I noticed the upstream version of the fix misses these things:
>
> * falling back on `man --path` when the man implementation does not
>   have support for `manpath` and `man -w`
> * falling back on $MANPATH when the man implementation does not have
>   support for printing the manual pages paths
>
>Would it be possible for one of you to send them a fix for that?

Sorry for taking so long to reply to this.

I can definitely send this upstream, but since you have already
provided the solution in the bug report, may I set the author name to
"Paul Wise " in the patch (git commit)?

It would look like this:



Author: Paul Wise 
Date:   Sun May 6 16:09:58 2018 -0300

Fallbacks for man completion

The commit

  commit e6a471511dfdc230ff3eed65ccba09b6d7d30262
  Author: Pawel 
  Date:   Wed Sep 27 06:34:59 2017 +0200

  man: Don't use $MANPATH directly (#161)

fixes the behavior of man completion when MANPATH is set, however, it
misses the following:

  * falling back on `man --path` when the man implementation does not
have support for `manpath` and `man -w`
  * falling back on $MANPATH when the man implementation does not have
support for printing the manual pages paths

This patch addresses them.

diff --git a/completions/man b/completions/man
index 0668b8ee..d0068fc7 100644
--- a/completions/man
+++ b/completions/man
@@ -51,7 +51,8 @@ _man()
 return
 fi
 
-local manpath=$( manpath 2>/dev/null || command man -w 2>/dev/null )
+local manpath=$( manpath 2>/dev/null || command man -w 2>/dev/null || 
command man --path 2>/dev/null )
+[[ -z $manpath ]] && manpath=$MANPATH
 [[ -z $manpath ]] && manpath="/usr/share/man:/usr/local/share/man"
 
 # determine manual section to search

Bug#876667: RFS: pragha/1.3.3-1

[Gabriel F. T. Gomes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: pragha
   Version : 1.3.3-1
   Upstream Author : Matias De lellis 
 * URL : https://pragha-music-player.github.io/
 * License : GPL-3+
   Section : sound

It builds those binary packages:

  pragha - Lightweight Music Player

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

https://mentors.debian.net/package/pragha


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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pragha/pragha_1.3.3-1.dsc


Regards,
Gabriel F. T. Gomes

Bug#876667: RFS: pragha/1.3.3-1

[Gabriel F. T. Gomes]

Breno,

Lukas (CC) pointed out some problems [1] with the packaging of Pragha.
For instance, the fact that I did not open a RFS properly.  I should
have sent the RFS message to sub...@bugs.debian.org, not to #592985.

This is a proper RFS (I think I got it right this time).  :)

[1] https://lists.debian.org/debian-mentors/2017/09/msg00298.html


Lukas,

In that same message [1], you suggested the use of a version control
system, but I don't know where to make it public (I know that alioth is
being discontinued, so I'm a bit lost with this).

I think I solved all other problems you pointed out.


Last but not least, I sent this message to debian-mentors (the right
place to ask question, right?).  Please let me know if I got this wrong.

Bug#876667: RFS: pragha/1.3.3-1

[Gabriel F. T. Gomes]

Hi, Lukas,

Thanks for the new round of reviews.  You're making me learn a ton.
:)

On 24 Sep 2017, Lukas Schwaighofer wrote:

>On Sun, 24 Sep 2017 15:15:41 -0300
>"Gabriel F. T. Gomes"  wrote:
>>
>> In that same message [1], you suggested the use of a version control
>> system, but I don't know where to make it public (I know that alioth
>> is being discontinued, so I'm a bit lost with this).  
>
>I hope someone here will have a suggestion where your repository can
>live.

In the meantime, I can keep it in my personal server [1].  However, I
don't think it's a good place for keeping it in the long run, because I
do not fully trust myself as a sysadmin.  Hehehe.

[1] 
http://git.inconstante.eti.br/?p=pragha-debian.git;a=shortlog;h=refs/heads/unstable

>* The upstream tarball you uploaded to mentors is not exactly the same
>  one as on github:
>
>$ cmp pragha-1.3.3.tar.gz pragha_1.3.3.orig.tar.gz 
>pragha-1.3.3.tar.gz pragha_1.3.3.orig.tar.gz differ: byte 5, line 1

Where did you get pragha-1.3.3.tar.gz from?
I got it from 
https://github.com/pragha-music-player/pragha/archive/v1.3.3.tar.gz.

The files are not exactly the same, as you mentioned, but their
contents, after extraction, are identical.

>  If you use git and git-buildpackage, make sure to use the
>  "pristine-tar" feature.  When using this, a small delta file will be
>  added to a special pristine-tar branch.  This allows to reconstruct
>  the original tarball exactly as it was.

I wasn't aware of git-buildpackage, so I was making the tarball by hand
and building with debuild.  Thanks for pointing this out.  On the other
hand, I still do not understand how git-buildpackage works.  All my
attempts to use it still resulted in a source tarball (.orig.tar.gz)
that is not exactly the same as the tarball from upstream.

>* In the debian/watch file you should replace "" with
>  "pragha" (it also works as is, but then the downloaded tarball is
>  called "-1.3.3.tar.gz" before the symlink is created).

Done.

>* in debian/patches/fix-appstream-errors.patch:
>  - referencing the ITP bug here does not make sense; you should only
>use "Bug-Debian" if there is a bug in the Debian BTS that is
>related to the patch (for example, if someone reported in the
>Debian BTS that the appstream xml data is wrong)
>  - Instead here you should record the URL of your pull request:
>
>  Bug: https://github.com/pragha-music-player/pragha/pull/125

Makes sense.  Done.


I uploaded a new package, which contains these changes and which was
built with git-buildpackage.

Best regards,
Gabriel

Bug#876667: RFS: pragha/1.3.3-1

[Gabriel F. T. Gomes]

Hi, Lukas,

Thanks again for the explanations.  You are a good professor!  :)

On 25 Sep 2017, Lukas Schwaighofer wrote:

>If you want to keep using git-buildpackage, I'd suggest you do the
>following:
>
>Add a file debian/gbp.conf with the following contents and commit it:
>===
>[DEFAULT]
>pristine-tar = True
>upstream-tag = upstream/v%(version)s
>
>[buildpackage]
>ignore-branch = True
>===
>this allows you to use the gbp commands without specifying the same
>parameters over and over.  It also makes working with the repository
>easier for someone else.

That's very interesting.  I accepted your suggestion.  :)

>That's it (and it is only required once); if you build the package now
>using git-buildpackage, it will reconstruct the original tarball
>exactly as it is on github. :)

It did, indeed.

I uploaded a new version with your suggestions.
(I also updated the git repository)

Thanks again,
Gabriel

Bug#876095: O: bash-completion -- programmable completion for the bash shell

[Gabriel F. T. Gomes]

On 22 Sep 2017, Axel Beckert wrote:

>> I cloned the package repository and I understood how syncing with
>> upstream was designed (very clever, imo).  
>
>Nice! Didn't look that deep into the package.

At the time I sent my first email, I was unaware of the existence of
git-buildpackage.  It turned out that bash-completion is maintained
with it, so that's where the clever syncing with upstream comes from.

(As a side not, I'm glad I learned about it, because it helped me in
the other packaging I am working on (pragha).  I converted it to
git-builbpackage)

>> So, I synced it and I began working on the removal of the patches
>> that are no longer required, or that do not apply cleanly.

That's done (see links to git repo below).

>Yes, but IMHO it's definitely a good thing to synchronise these bug
>reports (well, those which are still valid) to Github or the Debian
>Bug Tracking system — especially since Alioth is going away towards
>end of this year.
>[...]
>Not sure if it might be a good idea to make a dump or copy of all
>these bug reports as I don't expect them to be preserved when Alioth
>is decommissioned.

I saved the results of your search filter as a CSV, so that I have more
time to work on it.  Should that be enough?

>Please tell me if not being a member of the bash-completion project on
>Alioth hinders you in doing that work. (That should still be
>possible.)

So far so good.

I'm keeping my work on a personal git server [1], but as I mentioned in
the RFS for pragha [2], I don't think that's a good place to keep these
files in the long term, because I do not fully trust myself as a
sysadmin.

[1]
http://git.inconstante.eti.br/?p=bash-completion-debian.git;a=shortlog;h=refs/heads/unstable
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876667#26


Finally, I'd like to ask for some help...

After I upgraded bash-completion to newer upstream releases, I got some
conflicts during the installation of the package.  For instance, it
complained about the existence of the completion file for adb:

dpkg: error processing archive 
/home/gftg/debian/bash-completion/bash-completion_2.7-1_all.deb (--install):
 trying to overwrite '/usr/share/bash-completion/completions/adb', which is 
also in package adb 1:7.0.0+r33-2

I know that bts (from packages devscripts) and mount/umount (from
package mount) have the same problem, because I locally removed them
from bash-completion (just to test).

However, I don't know what to do about it.  There should be certainly
more files that collide this way, but I only saw these in my computer,
because I have few packages installed.

If you have any tips on how to proceed, I'd be glad to listen. :)


Kind regards,
Gabriel


pgpDbLjhbMGuk.pgp
Description: OpenPGP digital signature

Bug#877450: RFS: bash-completion/1:2.7-1 [ITA]

[Gabriel F. T. Gomes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "bash-completion"

 * Package name: bash-completion
   Version : 1:2.7-1
   Upstream Author : Bash Completion Maintainers
 * URL : https://github.com/scop/bash-completion
 * License : GPL-2
   Section : shells

It builds those binary packages:

  bash-completion - programmable completion for the bash shell

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

https://mentors.debian.net/package/bash-completion


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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/bash-completion/bash-completion_2.7-1.dsc


My work is versioned with git (and I'm using git-buildpackage).
Currently, the git repository is hosted in:
http://git.inconstante.eti.br/?p=bash-completion-debian.git;a=shortlog;h=refs/heads/unstable

This upload updates maintainer information, as well as it updates
upstream sources to version 2.7 (from version 2.1).  Since there were
many changes upstream, I made several changes downstream.

Regards,
Gabriel

Bug#876095: O: bash-completion -- programmable completion for the bash shell

[Gabriel F. T. Gomes]

On 29 Sep 2017, Gabriel F. T. Gomes wrote:

>After I upgraded bash-completion to newer upstream releases, I got some
>conflicts during the installation of the package.  For instance, it
>complained about the existence of the completion file for adb:
>
>dpkg: error processing
>archive /home/gftg/debian/bash-completion/bash-completion_2.7-1_all.deb
>(--install):
> trying to overwrite '/usr/share/bash-completion/completions/adb',
> which is also in package adb 1:7.0.0+r33-2
>
>I know that bts (from packages devscripts) and mount/umount (from
>package mount) have the same problem, because I locally removed them
>from bash-completion (just to test).

In the packaging of bash-completion itself, there were already some
instances of such conflicts:

http://git.inconstante.eti.br/?p=bash-completion-debian.git;a=commitdiff;h=116456a898d3468f5ae0c0a609a8087de7cd3e58
http://git.inconstante.eti.br/?p=bash-completion-debian.git;a=commitdiff;h=693e47c80aaaeeb50cf4b2b1f563eacbce65f4f5

So, I adopted the same strategy for adb, bts, mount, and umount.

>However, I don't know what to do about it.  There should be certainly
>more files that collide this way, but I only saw these in my computer,
>because I have few packages installed.

I still don't know if more collisions will occur on other people's
machines.  Perhaps I should just let them happen, then address each
individual collision reported as a bug against bash-completion?


I have just finished the upgrade [1], pushed to mentors [2] and opened
a RFS [3].

[1] 
http://git.inconstante.eti.br/?p=bash-completion-debian.git;a=shortlog;h=refs/heads/unstable

[2] https://mentors.debian.net/package/bash-completion

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


pgphyMxCYly4n.pgp
Description: OpenPGP digital signature

Bug#876095: O: bash-completion -- programmable completion for the bash shell

[Gabriel F. T. Gomes]

Hi, Axel.

Thanks for the review and explanations. :)

On 02 Oct 2017, Axel Beckert wrote:
>
>sorry for the late reply. Replying to your original mail as I already
>had written half the mail a few days ago.

Thank you!
I only sent a new email because I have found some answers and because I
have progressed with the packaging to a point where it might make sense
to share it (through mentors).

>This is a very common issue with bash-completion and zsh-common (where
>zsh's default completions live), but it's also unique to those two
>packages.
>
>Background: Some projects maintain shell completions rather well,
>others don't, but the team maintaining the completions does maintain
>them. If new completions are added to bash-completions, it's often a
>sign that the project they're for, doesn't really maintain them.

OK.

>So you should compare the conflicting files: Which are more uptodate,
>which have more precise completion.
>
>If it's the one in the project's package, just don't ship the one in
>bash-completion and it's good.

Makes sense.

>If the newly appeared file in bash-completion is clearly the better,
>you should maybe not ship it now, but file a bug report against the
>other package to exclude it, and if that's done, add in your next
>upload Breaks + Replaces headers against the last version of the
>package which still contained the conflicting file.

Makes sense.  In the packaging I already did, I removed the conflicting
files.  Based on your comment, I'll analyze which of them is better,
than if it's bash-completion's, I'll file a bug report agains the other
package.

Bug#892147: Please create the Pragha package with complete audio (api) support

[Gabriel F. T. Gomes]

On 05 Apr 2018, Jürgen Göricke wrote:

>Oh, I'm so surprised! Because the error message suggests otherwise.

I still do not understand what prevents .m3u URLs (such as the one
you want to use) from being played correctly on pragha, but I collected
some extra information and I have a workaround for you.

First, the workaround:

Use curl to display what's in your .m3u URL:

$ curl http://media-ice.musicradio.com/ClassicFMMP3.m3u 
http://media-the.musicradio.com:80/ClassicFMMP3

Then use this URL, instead of the original, to test your gstreamer installation:

$ gst-launch-1.0 -v playbin 
uri=http://media-the.musicradio.com:80/ClassicFMMP3

You can add this link to Pragha and it will work.

Could you test this workaround on your system and tell me if it works?



I'll keep trying to understand why the original URL is not acceptable.  Below 
is the output of a call to gst-launch-1.0, which shows that the problem is the 
lack of a decoder for 'text/uri-list' (it seems odd that a *decoder* is needed 
for text/uri-list.  I'd expect a *parser*.)

$ gst-launch-1.0 -v playbin
uri=http://media-ice.musicradio.com/ClassicFMMP3.m3u Setting pipeline to PAUSED 
...
Pipeline is PREROLLING ...
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: ring-buffer-max-size = 0
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: buffer-size = -1
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: buffer-duration = -1
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: use-buffering = false
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: download = false
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: uri = 
http://media-ice.musicradio.com/ClassicFMMP3.m3u
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: connection-speed = 0
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: source = 
"\(GstSoupHTTPSrc\)\ source"
Got context from element 'source': gst.soup.session=context, 
session=(SoupSession)NULL, force=(boolean)false;
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstTypeFindElement:typefindelement0.GstPad:src:
 caps = text/uri-list
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind:
 force-caps = text/uri-list
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0: 
sink-caps = text/uri-list
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0.GstPad:sink:
 caps = text/uri-list
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0.GstPad:src:
 caps = text/uri-list
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0.GstGhostPad:sink.GstProxyPad:proxypad0:
 caps = text/uri-list
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src:
 caps = text/uri-list
Missing element: text/uri-list decoder
WARNING: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: No 
decoder available for type 'text/uri-list'.
Additional debug info:
gsturidecodebin.c(921): unknown_type_cb (): 
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0
ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: Your 
GStreamer installation is missing a plug-in.
Additional debug info:
gsturidecodebin.c(988): no_more_pads_full (): 
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0:
no suitable plugins found:
gstdecodebin2.c(4640): gst_decode_bin_expose (): 
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0:
no suitable plugins found:
Missing decoder: text/uri-list (text/uri-list)

ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...

Bug#918430: find /tmp/ -path /tm

[Gabriel F. T. Gomes]

On 06 Jan 2019, 積丹尼 Dan Jacobson wrote:

>Package: bash-completion
>Version: 1:2.8-5
>File: /usr/share/bash-completion/completions/find
>
>No expansion is happening here:
>$ find /tmp/ -path /tm
>Please make it happen. Thanks.

I'm trying to understand what's the use case you want to enable.
I'll describe several scenarios:

1.
Suppose you have the following directories:

  $ ls -d /tmp/find-*
  /tmp/find-bar  /tmp/find-foo

If I make find /tmp -path /tmp/fi complete with directories, it
will complete to:

  $ find /tmp -path /tmp/fi
  $ find /tmp -path /tmp/find-

If you hit Enter after that, nothing will be found.

2.
Now suppose you only had one directory:

  $ ls -d /tmp/find-*
  /tmp/find-bar

Then the completion would look like:

  $ find /tmp -path /tmp/fi
  $ find /tmp -path /tmp/find-bar/

Again, nothing will be found, because of the trailing slash

3.
Take 2 as exemple, and remove the trailing slash

  $ find /tmp -path /tmp/find-bar

This works, but it's no different than:

  $ find /tmp/find-bar

which already works.

4.
Take 1 as example, but now, after completion, you add wildcard and quotes:

  $ find /tmp -path /tmp/fi
  $ find /tmp -path /tmp/find-
  $ find /tmp -path "/tmp/find-*"

Then it works, but it doesn't look like a good use case for completion.


What are you trying to do?


Cheers,
Gabriel

Bug#927232: find -path does not complete

[Gabriel F. T. Gomes]

Control: merge 918430 927232
Control: stop

This bug report is a duplicate of 918430.

Bug#918430: find /tmp/ -path /tm

[Gabriel F. T. Gomes]

On Sat, 26 Oct 2019, 積丹尼 Dan Jacobson wrote:

>All I know is I can't get any expansion at all even here:
>$ find . -path ./

Yes, I confirm that it doesn't.

>Why can't it ever expand anything at -path?

I'm trying to understand what to expand, thus I need your help.

>Is it because "the doctor thinks it is not good for me"?

I don't know what this is supposed to mean.

>Why not just let me expand filenames anyway?

Do you mean directories?  I don't think it would make sense to pass
filenames to the -path option in find.

>Certainly there can be at least one use case.

Yes, that's what I'm trying to understand, so that I can implement it
accordingly.


Cheers,
Gabriel

Bug#918430: find /tmp/ -path /tm

[Gabriel F. T. Gomes]

Forwarded upstream as https://github.com/scop/bash-completion/pull/359

Bug#929405: ITP: pveclib -- power vector library

[Gabriel F. T. Gomes]

Package: wnpp
Severity: normal

I will start working on the packaging for pveclib
(https://github.com/open-power-sdk/pveclib).

Cheers,
Gabriel

Bug#929405: ITP: pveclib -- power vector library

[Gabriel F. T. Gomes]

Hi, Steve,

After creating a initial version of the packaging [1], I got two
packages: one that contains the headers and the static library
(libpvec-dev_1.0.0-1_ppc64el.deb), and another that contains the shared
library (libpvec0_1.0.0-1_ppc64el.deb).

My first question would be: is that expected?  The shared library
contains a couple of symbols (e.g. tipowof10 and decpowof2) and it has
a valid soname, but README.md says that pveclib is "header files...".

Maybe the text is just out-of-date (maybe the wiki has newer content?).


[1] 
https://salsa.debian.org/gabrielftg-guest/pveclib/commit/3aeaa970f1f78b239bd26bb1e7ff52d77e2ec452

Bug#929405: ITP: pveclib -- power vector library

[Gabriel F. T. Gomes]

On Fri, May 24 2019, Steven Munroe wrote:
> In the current state, these libraries are only required for unit tests, but
> could be used for applications that need those constant values.

OK, if it can be useful for applications, than it's probably better to
distribute it, right away.

> [...] So the current build is looking ahead to a configuration
> that provides a space vs performance trade-off.
> 
> Fro example muludq <
> https://munroesj52.github.io/vec__int128__ppc_8h.html#aee5c5b2998ef105b4c6f39739748ffa8>
> where the POWER8 implementation runs 132 bytes. It is even bigger for
> POWER7 and only 80 bytes for POWER9.
> 
> The threshold for in-lining is a matter of some debate.
> 
> So I expect that eventually pveclib will need the option to move some
> operations for some -mcpu= values to use library calls. And some
> performance oriented applications will want to inline every thing
> regardless.

OK.  All good points to ship the shared library.

> For now I want to make pveclib available as-is to users. Then if someone
> complains about code size we can add the controls/configuration to adjust.

As-is sounds good to me. :)

With this information, I think the package is ready to be submitted to
the Debian Archive.  However, since we are under the freeze, that might
take a while, but I'll get the process started.

Thanks, Steve!

Cheers,
Gabriel.

Bug#929405: ITP: pveclib -- power vector library

[Gabriel F. T. Gomes]

Sean Whitton, from FTP Master, reviewed the package and pointed out
that the file CODE_OF_CONDUCT.md is probably not suitable for
distribution in the main section.  I agreed and repackaged the project,
as can be seen in:

https://salsa.debian.org/debian/pveclib/-/commits/master
(look for dfsg)

However, I did not upload it to the NEW queue yet, because there is a
problem with the compiler, which causes pveclib to fail to build.  This
has been reported to GCC and fixed [1], but it still needs some time to
land at Debian Unstable.  When that happens, I'll submit the new
package.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93987

Cheers,
Gabriel

Bug#653837: bash-completion: Variable $HOME in paths is escaped

[Gabriel F. T. Gomes]

Hi, thanks for your report.  I'll have a closer look at your debugging
effort, but I'd like to reply fast and add that completion with variables
has known problems, indeed.  There's a bug report upstream with more
information, here:

https://github.com/scop/bash-completion/issues/290

Cheers,
Gabriel

On Thu, 19 Dec 2019, Antoine Beaupre wrote:

>On Sat, Dec 31, 2011 at 02:14:14PM +0100, xiscu wrote:
>> Package: bash-completion
>> Version: 1:1.3-1
>> Severity: normal
>> 
>> Dear Maintainer,
>> 
>> * What led up to the situation?
>> - Pressing  to auto complete a path that uses $HOME
>> 
>> 
>> * What exactly did you do (or not do) that was effective (or
>>ineffective)?
>> -  Just try: dir $HOME/ and then press 
>> 
>> 
>> * What was the outcome of this action?
>> - The command is changed to: dir \$HOME/
>> (- If you then press  you will get the error:
>> dir: cannot access $HOME/: No such file or directory)
>> 
>> * What outcome did you expect instead?
>> - The command should be changed with the true $HOME value  
>
>I can reproduce the problem.
>
>$ bash --noprofile --norc
>bash-5.0$ echo $HOME/.bashrc 
>/home/anarcat/.bashrc
>bash-5.0$ . /usr/share/bash-completion/bash_completion
>bash-5.0$ echo \$HOME/.bashrc
>$HOME/.bashrc
>bash-5.0$ 
>
>I hit  after typing "$HOME/.bashr" in both cases, but after
>bash_completion is loaded it breaks $HOME.
>
>I've traced the problem down to this dynamic loader:
>
># set up dynamic completion loading
>_completion_loader()
>{
># $1=_EmptycmD_ already for empty cmds in bash 4.3, set to it for earlier
>local cmd="${1:-_EmptycmD_}"
>
>__load_completion "$cmd" && return 124
>
># Need to define *something*, otherwise there will be no completion at all.
>complete -F _minimal -- "$cmd" && return 124
>} &&
>complete -D -F _completion_loader
>
>If that code is removed, the problem doesn't occur. That's a complex
>piece of code I have kind of gotten lost along the way. It seems the
>escape character is inserted when this is called:
>
>_quote_readline_by_ref '$HOME/.bashr' quoted
>
>That's called somewhere below the _minimal callback defined above, which
>is:
>
>_minimal()
>{
>local cur prev words cword split
>_init_completion -s || return
>$split && return
>_filedir
>}
>
>Things look fine there, so I'm tempted to think it's
>_quote_readline_by_ref that's being too enthusiastic.
>
>But I'm pretty lost here so i'll stop there.

Bug#947942: bash-completion: "umount" breaks on spaces

[Gabriel F. T. Gomes]

This might be related:

https://github.com/scop/bash-completion/issues/378

Bug#907635: add .apk as file extension for jar and jarsigner

[Gabriel F. T. Gomes]

Hi, Hugo,

thanks for reaching out.

On Mon, 27 Jan 2020, Hugo Ziviani wrote:
>
> I think this is not exactly a bug.

Are you saying this because you think that this is more like a
reasonable feature that is missing, as opposed to a bug that causes
crashes or wrong output?  If so, I would say that we don't need to care
too much about the words: bug, issue, feature, you-name-it.  These
words are used interchangeably sometimes/by some people.  If not, can
you explain why you think that this is not a bug?

> Could anyone give-me more information if I start upstream or I can
> start from here downstream.

Since it really looks like an upstream bug, I think it would be better
if it was fixed there first.  That way, we won't have to carry a patch
in Debian (which is problematic, since upstream can have a different
judgement on whether this needs fixing or not, which is why I avoid
downstream patches as much as possible), and we will just wait for
upstream to make a new release and the bug will be gone sort of
automatically.

On the other hand, you don't *have* to fix it upstream first.  If you
don't want to fix this upstream, I'll happily accept a patch from you
here in Debian (then I would forward it upstream).  It's really up to
you. :)

Do you have a patch already?
Could you send it to me here (or send it upstream and post a link
here), please?

Thanks again,
Gabriel

Bug#881719: O: libcdio and libcdio-paranoia

[Gabriel F. T. Gomes]

Control: retitle -1 ITA: libcdio
Control: assign -1 !

I maintain pragha, which depends on this package, so I'll adopt it.

Thanks,
Gabriel

Bug#881910: O: libcdio and libcdio-paranoia

[Gabriel F. T. Gomes]

Control: retitle -1 ITA: libcdio-paranoia
Control: assign -1 !

I maintain pragha, which depends on this package, so I'll adopt it.

Thanks,
Gabriel

Bug#939427: rsnapshot adoption

[Gabriel F. T. Gomes]

Hi, Michael,

On 23 Oct 2019, Michael Lustfield wrote:

>Apologies- I missed your first line.

No problem, at all. :)

>I finished with a fair bit of packaging clean up and officially adopted
>rsnapshot. I'd be happy to co-maintain this package.

Awesome.  I'm happy it has a new maintainer!
I'll send bug reports and patches if I stumble upon anything.

>If you, or anyone else, are interested in helping with packaging or
>(preferably) upstream, please let me know and I'll share some more details.

I don't have anything to add for now, I just didn't want to see it go
away.  It's good software.  :)

Thanks for adopting rsnapshot! <3

Cheers,
Gabriel

Bug#917392: adequate reports broken symlink in bash-completions

[Gabriel F. T. Gomes]

On 28 Dec 2018, Gabriel F. T. Gomes wrote:

Shirish,

Thanks for the report and for reassigning the bug against ifupdown2.

Julien,

Shirish and I investigated a problem he found with bash-completion
(/usr/share/bash-completion/completions/ifup was missing), and we
noticed that the problem occurs after an upgrade of ifupdown2 (from
version 2_1.0~git20170314-1 to version 1.2.2-1).

In order to reproduce it, you may follow the following steps
(bash-completion must be installed):

>Here are the steps to reproduce it:
>
>1. Install ifupdown2 version (ifupdown2_1.0~git20170314-1_all.deb)
>
>  # dpkg -i ifupdown2_1.0~git20170314-1_all.deb
>
>2. Check that it installs files under /usr/share/bash-completion
>
>  # dpkg --search /usr/share/bash-completion/completions/ifup
>  diversion by ifupdown2 from: /usr/share/bash-completion/completions/ifup
>  diversion by ifupdown2 to: 
> /usr/share/bash-completion/completions/ifup.disabled
>  ifupdown2, bash-completion: /usr/share/bash-completion/completions/ifup
>
>3. See that ifup is actually there:
>
>  # ls /usr/share/bash-completion/completions/ifup
>  /usr/share/bash-completion/completions/ifup
>
>4. Upgrade ifupdown2:
>
>  # aptitude upgrade ifupdown2
>
>5. Repeat steps 2 and 3 (then see that the file is missing):
>
>  # dpkg --search /usr/share/bash-completion/completions/ifup
>  diversion by ifupdown2 from: /usr/share/bash-completion/completions/ifup
>  diversion by ifupdown2 to: 
> /usr/share/bash-completion/completions/ifup.disabled
>  bash-completion: /usr/share/bash-completion/completions/ifup
>
>  # ls /usr/share/bash-completion/completions/ifup
>  ls: cannot access '/usr/share/bash-completion/completions/ifup': No such 
> file or directory

I think that this may be a problem with ifupdown2, rather than with
bash-completion, so I suggested that this bug be reassigned against
ifupdown2.

Apparently, ifupdown2 used to ship the completion file for ifup, but it
no longer does it (which is great in my opinion, because it removes the
conflict with bash-completion).  However, I don't know why, after the
update, bash-completion is unable to install the completion file for
ifup.  There must be something in apt blocking it to do so.

Bug#918099: what is so special about TZ?

[Gabriel F. T. Gomes]

Control: retitle -1 bash-completion suggest timezone completion for any command 
after TZ
Control: tags -1 + confirmed,upstream

On Thu, Jan 03 2019, 積丹尼 Dan Jacobson wrote:
> Package: bash-completion
> Version: 1:2.8-5
> 
> Why does
> $ grep TZ a
> not expand?
> $ grep TZa a
> Does.

That's a side effect of the fix for Red Hat bug #994646 [1].

> Same problem with ls, whatever command.

As reported in the bug [1], completing `env TZ ', `declare TZ ',
`typeset TZ ', or `export TZ=' correctly suggests timezone options.
However, bash-completion also suggests timezone options for other
commands, such as ls and grep, and that looks wrong.  I'll try to
produce a fix that doesn't spoil it for export, env, etc.

> No there is no file called TZ.
> 
> No other environment variable names don't trigger the problem.

Yes, TZ is handled specially by bash-completion.


Thanks for the report,
Gabriel

[1] https://bugzilla.redhat.com/show_bug.cgi?id=994646

Bug#918099: what is so special about TZ?

[Gabriel F. T. Gomes]

On Thu, Jan 03 2019, Gabriel F. T. Gomes wrote:
> As reported in the bug [1], completing `env TZ ', `declare TZ ',
> `typeset TZ ', or `export TZ=' correctly suggests timezone options.

Hrm, on second thought, only the completion for `export TZ=' looks
correct.

Bug#930709: RFS: pveclib/1.0.1-1 [ITP]

[Gabriel F. T. Gomes]

On Sat, 22 Jun 2019 19:48:06 +0200 Adam Borowski  wrote:
> 
> Heck, just seconds ago, the package got uploaded with:
> Maintainer: Gabriel F. T. Gomes 
> keyid: FD9CE2D8D7754B78AB279BBD2C3B436FEAC68101
> and I'm pretty sure that key EAC68101 is not yours.

Hahaha, it took me some time to understand what you were talking about. :)
Thanks for the review and for the upload.

> It fails tests in qemu-user, works fine on Debian-provided porterbox.

I'll see if I can reproduce it with qemu-user, thanks for the feedback.

> All looks fine.  I did not test the functionality (beyond the
> testsuite), but packaging looks good.
> 
> Uploaded, thanks for your contribution!

Thank you!

Bug#931685: bash-completion: completion disables usage of environment variables

[Gabriel F. T. Gomes]

Control: merge 922657 931685
Control: stop

On Tue, 09 Jul 2019 11:39:47 +0200 Michael Becker  wrote:
> 
> with an existing directory $HOME/devel
>   ls $HOME/dev
> completes to
>   ls \$HOME/devel/

This has the same root cause of bug https://bugs.debian.org/922657,
i.e.: in _quote_readline_by_ref, the backslash gets added by:

  printf -v $2 %q "$1"

This has been reported upstream as
https://github.com/scop/bash-completion/issues/290

I'm merging the bug reports.

Thanks,
Gabriel

Bug#929405: ITP: pveclib -- power vector library

[Gabriel F. T. Gomes]

On Sat, 25 May 2019 15:31:47 -0300 "Gabriel F. T. Gomes" 
 wrote:
>
> As-is sounds good to me. :)

On second thought, I have an usability question for you, which would
also be relevant for other distros that might ship pveclib...

The headers are currently installed under /usr/include/pveclib/ (this
is based on what 'make install' does).  Then, users will have to use
'-I/usr/include/pveclib/' on their compilation commands, similarly to
what is suggested in the README page [1] for pveclib.

Wouldn't it be more appropriate to ask users to use:

  #include 

instead?  (and forget about '-I').

But if we do that, all header files in pveclib would have to be patched
so that the files they include also contain 'pveclib/', for instance,
in src/vec_bcd_ppc.h:

  -#include 
  -#include 
  -#include 
  +#include 
  +#include 
  +#include 

I submitted a pull request [2] upstream to foster this discussion.

[1] https://github.com/open-power-sdk/pveclib#usage

[2] https://github.com/open-power-sdk/pveclib/pull/71