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

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

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

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

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

Package: wnpp Followup-For: Bug #592985 Owner: "Gabriel F. T. Gomes" <gabr...@gftg.com.br> 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 m

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

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

Bug#876667: RFS: pragha/1.3.3-1

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

Bug#876667: RFS: pragha/1.3.3-1

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

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

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

Bug#592985: RFS: pragha/1.3.3-3

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

Bug#876667: RFS: pragha/1.3.3-1

load 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

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]

Bug#876667: RFS: pragha/1.3.3-1

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" <gabr...@inconstante.eti.br> wrote: >> >> In that same message [1], you sugg

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

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

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

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 >

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

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 :

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

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

Bug#876667: RFS: pragha/1.3.3-1

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]

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

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

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

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 bac

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

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

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

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

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

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

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

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

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

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#888090: bash-completion: Allow to run python zipapp (pyz files)

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

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

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

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

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

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

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

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

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

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

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:

Bug#876095: Still active?

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

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

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

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

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

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

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

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

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

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

-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

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

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

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

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

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

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#892080: bash-completion: cvs log ($mode=log) case disappeared?

On 05 Mar 2018, Tim Connors wrote: >I'm sure 'cvs log 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

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

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

Bug#811496: Cleaning "affects" flags

Similarly to message XX, I have confirmed that desktop-file-utils and initramfs-tools do not install to the obsolete directory $ dpkg -L desktop-file-utils initramfs-tools | grep "completion\.d" (no output) Thus, I'm removing the `affects' flag from them... Control: affects 811496 -

Bug#811496: Cleaning "affects" flags

I have confirmed that, among the following packages, only `dlocate' installs files under the obsolete directory (/etc/bash_completion.d): dpkg -L dlocate borgbackup ocaml-findlib dupload deborphan aapt linkchecker scilab-cli transifex-client qemubuilder cabal-install feedgnuplot notmuch

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

On 07 Feb 2018, Gabriel F. T. Gomes wrote: >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). Short explanation: This is not a problem in bash-compl

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

In my previous message, mentions to `ggrep' mean `grep -RnE' (that's an alias in my environment: $ alias ggrep alias ggrep='grep -RnE' On 03 Nov 2018, Gabriel F. T. Gomes wrote: > > $ ggrep "completion\.d" git-2.19.1/ > git-2.19.1/debian/git.install:4:debian/gi

Bug#811496: Cleaning "affects" flags

Control: affects 811496 - grub Control: affects 811496 + grub2 Similarly to message 98, I have confirmed that grub is not actually _affected_ by this bug, since it doesn't install any completion files: # dpkg-deb --contents grub-disk_0.97-75_amd64.deb | grep completion # dpkg-deb

Bug#912849: Package installs completions files into obsolete directory

Package: dkms Version: 2.6.1-1 The completions file for dkms are being installed into the obsolete directory, /etc/bash_completion.d/, when they should be installed under the default directory, /usr/share/bash-completion/completions. The reason for this is that the obsolete directory is

Bug#912850: Package installs completions files into obsolete directory

Package: dlocate Version: 1.07+nmu1 The completions file for dlocate are being installed into the obsolete directory, /etc/bash_completion.d/, when they should be installed under the default directory, /usr/share/bash-completion/completions. The reason for this is that the obsolete directory is

Bug#912854: Package installs completions files into obsolete directory

Package: git Version: 2.19.1-1 The completions file for git are being installed into the obsolete directory, /etc/bash_completion.d/, when they should be installed under the default directory, /usr/share/bash-completion/completions. The reason for this is that the obsolete directory is

Bug#811496: Preparing to close the bug report

On 04 Nov 2018, Gabriel F. T. Gomes wrote: > >Bug reports [1,2,3,4] explaining that the fix needs to be done by the >packages: dkms, dlocate, git, and grub2, have been created. I forgot the links. :) [1] https://bugs.debian.org/912849 [2] https://bugs.debian.org/912850

Bug#811496: Cleaning "affects" flags

Control: affects 811496 - apt-show-versions tig Finally, tig and apt-show-versions do not install to the obsolete directory, as can be seen in the following commands and output: # dpkg-deb --contents apt-show-versions_0.22.8_all.deb | grep completion [...] ./usr/share/bash-completion/

Bug#912852: Package installs completions files into obsolete directory

Package: grub2 Version: 2.02+dfsg1 The completions file for grub2 are being installed into the obsolete directory, /etc/bash_completion.d/, when they should be installed under the default directory, /usr/share/bash-completion/completions. The reason for this is that the obsolete directory is

Bug#907294: completions/dpkg: installing dctrl-tools breaks completion for held packages with -L/--listfiles

Hi, Paul. On 26 Aug 2018, Paul Wise wrote: > >The completion for dpkg -L/--listfiles does not list held packages when >grep-status (from dctrl-tools) is installed. This is because the >grep-status _comp_dpkg_purgeable_packages cares about the dpkg package >selection states

Bug#907294: completions/dpkg: installing dctrl-tools breaks completion for held packages with -L/--listfiles

On 02 Nov 2018, Gabriel F. T. Gomes wrote: >Thanks for writing the fix... I'll apply it to the package and forward >this upstream. I have reported the bug upstream [1], and I incorporated your patch to the git repo of bash-completion [2], however I have not yet produced a package with t

Bug#910128: bash-completion: diff for NMU version 1:2.8-1.1

Hi, Emmanouil, On 28 Oct 2018, Emmanouil Kampitakis wrote: >I've prepared an NMU for bash-completion (versioned as 1:2.8-1.1) and >uploaded it to DELAYED/5. Please feel free to tell me if I >should delay it longer. > >Previous diff was against stable. Attached diff is agains sid Thanks for

Bug#910128: bash-completion: diff for NMU version 1:2.8-1.1

On 02 Nov 2018, Gabriel F. T. Gomes wrote: >On 28 Oct 2018, Emmanouil Kampitakis wrote: > >>I've prepared an NMU for bash-completion (versioned as 1:2.8-1.1) and >>uploaded it to DELAYED/5. Please feel free to tell me if I >>should delay it longer. > >Thanks for do

Bug#549550: Clear patch tag

Control: tags -1 - patch After such a long time, the patch provided for this bug is no longer accessible, and even if it was, I doubt it would apply.

Bug#630521: Update tags

Control: tags -1 = unreproducible It looks like the bug is gone, so I'm setting it to unreproducible. After some time, if no one oposes, I'll close it. $ ls '!' file1 file2 file3 $ vi file file1 file2 file3 Michal, do you still see this problem?

Bug#696430: Update tags

Control: tags -1 = unreproducible I can't reproduce it, so setting the unreproducible tag. I'll leave this bug open for some time, then, if no one opposes, I'll close it. Steps to [not] reproduce: $ mkdir /tmp/files/ $ for i in `seq -w 1 200`; do touch /tmp/files/$i; done $ scp

Bug#741273: Add updated information

Control: tags -1 + upstream confirmed The discussion mentioned in message 10 [1], and hosted on alioth (decommissioned), has been migrated to the current upstream hosting and bug tracking site as Issue #44 [2]. This bug is still reproducible in Debian *and* upstream, and a fix is not available.

Bug#616018: Updating flags and preparing to close

Control: tags -1 + unreproducible Control: tags -1 - wontfix According to Debian's webpage on PDFs [1], Adobe's Acrobat Reader (acroread), can be installed from two different sources: 1. deb-multimedia.org I downloaded the .deb files from this server and none of them contains a completion file.

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

Hi, Christoph, On 08 Mar 2018, Christoph Anton Mitterer wrote: >Actually I think, it would be even better to just have * not expand by >completion per default (which would often just clutter up the readline >with countless of possible matches)... A bit of good news on this bug... An upstream

Bug#742466: bash-completion: [PATCH] bash-completion: unexpected EOF while looking for matching `) while completing in subshell

X command substitution $(). (Closes: #742466) + -- Gabriel F. T. Gomes Sun, 04 Nov 2018 18:48:03 -0200 bash-completion (1:2.8-2) unstable; urgency=low diff --git a/debian/patches/00-fix_quote_readline_by_ref.patch b/debian/patches/00-fix_quote_readline_by_ref.patch index f96e47f..b1eeb11 1

Bug#742466: bash-completion: [PATCH] bash-completion: unexpected EOF while looking for matching `) while completing in subshell

On 10 Nov 2018, G. Branden Robinson wrote: >At 2018-11-10T15:07:23-0200, Gabriel F. T. Gomes wrote: >> May I attribute this change to you (as commit author) in the git >> repository for Debian's bash-completion. It would like like the >> attached patch. > >I'm

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

I forgot to explicitly mention the TABs... On 11 Nov 2018, Gabriel F. T. Gomes wrote: >3) bash-completion 2.8-3 > + additional change [1] > + `set show-all-if-ambiguous off' in ~/.inputrc > > $ ls /tmp/test/* > bla ble blee > $ ls /tmp/test/* $ ls /tmp/t

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

On 10 Nov 2018, Christoph Anton Mitterer wrote: >On Sat, 2018-11-10 at 18:27 -0200, Gabriel F. T. Gomes wrote: > >> That is possible, but it would require a change that has not yet been >> accepted upstream [1]. I have added this information to Debian's >> bash-comp

Bug#865548: bash-completion: completion for OpenRC rc-service

Hi, Mathieu, On Thu, 22 Jun 2017 18:45:07 +0200 Mathieu Roy wrote: > > With the following (almost a copy of invoke-rc.d), rc-service should > be handled ok. Here's what I got on a freshly debootstrapped chroot: $ rc-service [TAB][TAB] cron--ifnotstarted procps

Bug#715470: RFP: cr3 -- Cool Reader 3, an e-book reader

Control: retitle -1 RFP: cr3 -- Cool Reader 3, an e-book reader Hi, I'm using this software from a local build and I'd like to add it to Debian. On the other hand, I'm not sure I'll be able to finish this until Buster release (as I have many bugs to solve on bash-completion and I want to focus

Bug#848125: bash-completion: Patch to allow '+' in (ssh/know_hosts) hostnames

On Wed, 14 Dec 2016 Vincent Danjean wrote: > I'm using automatic gateway with ssh (and ProxyCommand) so that > ssh gw1+gw2+host will correctly setup a connection first to gw1, > then to gw2 (via gw1 and ProxyCommand) and eventually with host > (via gw2 and ProxyCommand) whatever gw1, gw2 and

Bug#848125: bash-completion: Patch to allow '+' in (ssh/know_hosts) hostnames

On 14 Nov 2018, Vincent Danjean wrote: >3) experiments > $ ssh k[tab] # => autocomplete in kooot+eyak, ok > $ ssh kooot+aya# => no auto-completion on first try, normal > $ ssh k[tab] # => autocomplete in kooot+ > $ ssh kooot+e[tab] # => autocomplete in kooot+eyak, ok > $ ssh

Bug#865548: bash-completion: completion for OpenRC rc-service

On 12 Nov 2018, Gabriel F. T. Gomes wrote: >I suppose it would be OK to add --debug, --nodeps, --ifcrashed, >--ifstarted, --ifstopped, --resolve, --dry-run, --version, --verbose. I added these options (as well as the short options, such as -d, -h, etc.) to the completions file. I also r

Bug#730239: Updating tags

Control: tags -1 = unreproducible I could not reproduce this bug. Here's what I did to try: I edited /etc/login.defs, setting UMASK to 0027, then rebooted. Even after reboot, when I run the command `umask', I get 0022. To work around it, I manually set umask to 0027. # umask 0022

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

On 02 Nov 2018, Alf Gaida wrote: >Im fine with - i didn't really dig into it, d-qt-kde does an stopped >sourcing these files in case the shell is fish - that kind of solved >the issue, since fish is not posix compat if i understand it right. > >Thank you for getting back on this. Thank you for

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

On 18 Mar 2018, Gabriel F. T. Gomes wrote: >Thanks for pointing this out. I sent a patch for upstream review at: >https://github.com/scop/bash-completion/pull/194. The pull request has been integrated, but since it's not in an upstream release, yet, I added the patch to Debian (notice

Bug#811496: Preparing to close the bug report

On 03 Nov 2018, Gabriel F. T. Gomes wrote: >In order to understand the cause of this problem, I downloaded the >source files for these packages, and noticed that they do *not* use >`dh_bash-completion' to install their completions files. Instead, each >of them use their own metho

Bug#865548: bash-completion: completion for OpenRC rc-service

>I'll forward the original file with the changes upstream. Now forwarded upstream [1] and in the git repository [2] (notice that it is not yet in the Debian archive. I want to add more fixes before releasing a new version). [1] https://github.com/scop/bash-completion/pull/254 [2]

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

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

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

On Fri, Dec 28, 2018 at 01:46:30AM +0530, shirish शिरीष wrote: > $ sudo aptitude reinstall bash-completion > [sudo] password for shirish: > The following packages will be REINSTALLED: > bash-completion > 0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and > 9 not upgraded. >

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

On 27 Dec 2018, Gabriel F. T. Gomes wrote: >On Fri, Dec 28, 2018 at 01:46:30AM +0530, shirish शिरीष wrote: > >I don't see anything wrong with this snippet, however, I'm looking into >the packaging files for ifupdown2 and I see that it ships (or used to >ship) a completion file for

Bug#525082: reassign 525082 to bash,bash-completion

Control: severity -1 important On Wed, 28 Nov 2018 22:40:04 -0200 "Gabriel F. T. Gomes" wrote: > > I have investigate what causes this problem and found out that it is > due to bash_completion unsetting hostcomplete (shopt -u hostcomplete) > before installing compl

Bug#653386: bash-completion doesn't commands not first on line

On Tue, 27 Dec 2011 16:27:01 +0100 Jakob Bohm wrote: > Package: bash-completion > Version: 1:1.2-3 > Severity: normal > > The current "stable" version of bash-completion does not do > command completion in many of the places where something else > prefixes the command Current unstable (2.8-4)

Bug#550676: closed by gabr...@inconstante.eti.br (Gabriel F. T. Gomes) (Bug#550676: fixed in bash-completion 1:2.8-5)

On 22 Dec 2018, Norbert Preining wrote: > >Cool!!! Thanks a lot to dig out this old bug from 2009 - nearly 10 years >ago. No problem... I'm reading through each of the bugs reported against bash-completion, even very old ones. I'm not sure how long it will take to fix them all (definitely not

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

On Thu, Dec 27, 2018 at 02:50:27PM +0530, shirish शिरीष wrote: > $ adequate bash-completion > bash-completion: broken-symlink > /usr/share/bash-completion/completions/ifdown.disabled -> ifup I don't recognize the `.disabled' suffix. Have you manually renamed this file? > bash-completion:

Bug#645439: obsolete conffiles not removed on upgrades

The next upload will fix this problem. The relevant commits in the git repository are: https://salsa.debian.org/debian/bash-completion/commit/c9203c53ea75d6fe708bf2deb82f1341072a97db https://salsa.debian.org/debian/bash-completion/commit/e55d81a56ae89ee0b9cd3bc1e6fc683a33c17991

Bug#525082: upstream help request

Control: tags -1 upstream On 28 Nov 2018, Gabriel F. T. Gomes wrote: >I'll ask for advice upstream. Help requested upstream at: https://github.com/scop/bash-completion/pull/263

Bug#614775: bash-completion: perl -d inhibits filename completion

On Sat, 24 Nov 2018 15:57:27 -0200 "Gabriel F. T. Gomes" wrote: > On Sat, 24 Nov 2018 12:53:38 -0200 "Gabriel F. T. Gomes" > wrote: > > > > I'll apply it to Debian's bash-completion for the next upload. > > Now in the git repository [1]. I'll w

Bug#586695: Asking for help on network completion problems and concerns

Control: tags -1 + moreinfo While taking care of old bugs, I noticed that this one is being updated with tags for all newer Debian release (jessie, stretch, and buster). However, I'm not sure I can actually reproduce the related problems, so I'm asking for more information. On Mon, 21 Jun 2010

Bug#586695: Asking for help on network completion problems and concerns

On 02 Dec 2018, Barak A. Pearlmutter wrote: >Yup, this seems totally fixed: no completion of hostnames, or >filesnames following a hostname. I believe there's something else going on. I do get completion of hostnames (not from AVAHI, though) and of filenames following a hostname with a colon.

Bug#912850: Package installs completions files into obsolete directory

I opened this bug report before I ever read bug #551707 [1], more specifically, message #40 [2]. I'm sorry if this caused a harsh impression, as that was not my intention, at all (I opened similar bug reports for other packages [3][4][5], all at the same time). Please let me know if you still

Bug#625469: improvements for tar, cryptsetup, imagemagick completions and the _parse_help function

Hello, Frank, On Tue, 3 May 2011 20:02:54 +0200 David Paleino wrote: > > On Tue, 03 May 2011 10:46:19 -0700, Frank Harwald wrote: > > > Package: bash-completion > > Version: 1.2-3 > > > > I made several improvements for the bash-completion package. > > [..] > > Would you please make a clone

Bug#550676: please make bash-completion falling back to path completion if nothing else is found

On Mon, 26 Nov 2018 21:49:20 -0200 "Gabriel F. T. Gomes" wrote: > > Current sources for this can be found at the new repository [1], but I > think that for the suggestion to actually work, it requires a fix, > which I submitted upstream as pull request #260 [2]. >

Bug#551707: Processed: Re: dlocate does not complete filenames

On Sun, 27 Dec 2009 23:35:15 +0100 David Paleino wrote: > On Sunday 27 December 2009 23:27:33, Craig Sanders wrote: > > how should we handle this? should I release a new dlocate without > > completion first, or will you divert the completion file to your > > package? > > It would be best if you

Bug#614775: bash-completion: perl -d inhibits filename completion

On Sat, 24 Nov 2018 12:53:38 -0200 "Gabriel F. T. Gomes" wrote: > > I'll apply it to Debian's bash-completion for the next upload. Now in the git repository [1]. I'll wait for more changes (or more time) before doing a new upload. [1] https://salsa.debian.org/debian/bash-c

Bug#614775: bash-completion: perl -d inhibits filename completion

Thanks for the patch. I adpated it for current sources and forwarded it upstream as https://github.com/scop/bash-completion/pull/258. I'll apply it to Debian's bash-completion for the next upload.

Bug#914590: regression: parsing known_hosts is slow

Hi, thanks for the report. On 25 Nov 2018, Timo Weingärtner wrote: >with the last upgrade of bash-completion completing hostnames has >become slow (takes more than two seconds). My /etc/ssh/ssh_known_hosts >file has quite some size (23084 lines / 12 MB), but this was not a >problem with the

Bug#550676: [Bash-completion-devel] Bug#550676: Bug#550676: please make bash-completion falling back to path completion if nothing else is found

On Sat, 19 Jul 2014 16:33:07 +0300 =?UTF-8?Q?Ville_Skytt=C3=A4?= wrote: > On Fri, Jul 18, 2014 at 10:14 PM, David Paleino wrote: > > > > Just use Alt-/, which is the default bash shortcut for "complete on all > > files". > > ...or try the COMP_FILEDIR_FALLBACK environment variable: >

Bug#550676: make bash-completion falling back to path completion if nothing else is found

Control: fixed -1 bash-completion/1:1.3-1 On Wed, 03 Feb 2010 08:44:24 +0900 Norbert Preining wrote: > > My usual reminder ... since I am in kernel-build mood ATM I am again > hit by that > make -f debian/rules KDIR=/usr/src/li > nothing nothing nothing. Since the upstream commit commit

Bug#776160:

Control: tags -1 fixed bash-completion/1:2.7-1 On Sun, 25 Jan 2015 16:28:31 +0200 Ville Skyttä wrote: > Applicable bits applied upstream: > http://anonscm.debian.org/cgit/bash-completion/bash-completion.git/commit/?id=c725e6b195ea6ac2d25dfbb85b7e87bfbe42fe68 This is the link for the fix in the

Bug#776160:

Control: fixed -1 bash-completion/1:2.7-1 On 22 Nov 2018, Gabriel F. T. Gomes wrote: > >Control: tags -1 fixed bash-completion/1:2.7-1 This was the wrong syntax to set fixed version.

Bug#913949: bash-completion: please support .tar.zst

On 17 Nov 2018, Adam Borowski wrote: >On Sat, Nov 17, 2018 at 12:02:38PM -0200, Gabriel F. T. Gomes wrote: >> >> and even for `.tar.zstd', `.gem.zstd', `.spkg.zstd', as people are >> probably going to create archives with such extensions. > >Bad idea -- tar doesn't

Bug#913949: bash-completion: please support .tar.zst

Control: tags -1 upstream On 17 Nov 2018, Adam Borowski wrote: >Both upstream tar (for months) and Debian's tar (since today) support >zstd compression. It's drastically faster than gzip while compressing >much better, thus some of us switched to it already. Alas, if >bash-completion is

  1   2   3   >