# emerge -a1v bash-completion These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ~] app-shells/bash-completion-2.1-r1::gentoo [2.1::x-overlay] 0 kB [uninstall ] app-shells/gentoo-bashcomp-20101217-r1 [blocks b ] <app-shells/gentoo-bashcomp-20130101 ("<app-shells/gentoo-bashcomp-20130101" is blocking app-shells/bash-completion-2.1-r1) Total: 1 package (1 upgrade, 1 uninstall), Size of downloads: 0 kB Conflict: 1 block Would you like to merge these packages? [Yes/No] no Quitting. Reproducible: Always
*** This bug has been marked as a duplicate of bug 472938 ***
Hum, I don't think this is a duplicate of #472938, if anything it has been introduced by it. As far as I can tell the blockage is because the new app-shells/bash-completion-2.1-r1 ebuild needs a higher version of app-shells/gentoo-bashcomp (20130101) which is not in the tree. Typo in ebuild or missed file from commit perhaps?
(In reply to Jeroen Roovers from comment #1) > > *** This bug has been marked as a duplicate of bug 472938 *** Sorry, but it's not a duplicate of bug 472938
Created attachment 353460 [details, diff] use directory where the modules are picked up from propably path issue... not sure of futher incompabilities. try it, modify it, submit it ;) emerge --nodeps -av gentoo-bashcomp
also removed the blocker for now. downside is you get to keep the broken / misplaced files now, until this is resolved
(In reply to Samuli Suominen from comment #4) "repoman" and "layman" should work that way. But "gentoo" completion should be either installed in compatdir: $ pkg-config --variable=compatdir bash-completion /etc/bash_completion.d or splitted in separate files to support dynamic loading (completion name should match command name).
Created attachment 353494 [details, diff] gentoo-bashcomp-20121024.ebuild.patch This one works for me.
Created attachment 353524 [details, diff] gentoo-bashcomp patch - Do not use deprecated have() function. - Move gentoo_style_init completion in separate file. It doesn't support dynamic loading so it should be installed in compatdir. - Cleanup spaces at the end of lines.
Created attachment 353526 [details, diff] gentoo-bashcomp-20121024.ebuild v2 Resulting ebuild needs patched gentoo-bashcomp sources.
(In reply to Alexander Tsoy from comment #7) > Created attachment 353494 [details, diff] [details, diff] > gentoo-bashcomp-20121024.ebuild.patch > > This one works for me. This one works for me as well, thanks! The second one, however, doesn't due to the patch failing (for layman iirc). Symlinking, tbh, doesn't feel very good, but at least it's working again. Could a dev please take a look at this? I'd love to see an updated ebuild in portage.
(In reply to shinydoofy from comment #10) > (In reply to Alexander Tsoy from comment #7) > > Created attachment 353494 [details, diff] [details, diff] [details, diff] > > gentoo-bashcomp-20121024.ebuild.patch > > > > This one works for me. > The second one, however, doesn't due to the patch failing (for layman iirc). My patch should apply on git HEAD. http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-bashcomp.git > Symlinking, tbh, doesn't feel very good, but at least it's working again. This approach is recommended by upstream. You can find it in README.
That way it indeed works. Had to clone it, apply your patch and run make dist to get the patched tarball. The README cleared up this one as well. Thanks for the pointers!
+ local compatdir="$(_bash-completion-r1_get_bashdir compatdir /etc/bash_completion.d)" ... + insinto "${compatdir}" It's better to do "insinto /etc/bash_completion.d" and not call private functions from eclass of course. :)
sorry but could someone explain howto to get back a working bashcompletion?
http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-bashcomp.git;a=commit;h=454d3250f82f1bc29d0f27b386dd63d54cd2e0de I have a few other fixes to make for some recent portage changes (bug #478444) but I will try to get a new release done by the end of the week.
Fixed in gentoo-bashcomp-20130804.
Thank you.
