[gentoo-dev] News item review: bash-completion-2.1-r90
Please review the following news item. - Title: bash-completion-2.1-r90 Author: Michał Górny Content-Type: text/plain Posted: -MM-DD Revision: 1 News-Item-Format: 1.0 Display-If-Installed: signature.asc Description: PGP signature
Re: [gentoo-dev] News item review: bash-completion-2.1-r90
El lun, 13-10-2014 a las 11:35 +0200, Michał Górny escribió:
> Please review the following news item.
[...]
> The current eselect-bashcomp setup will *not* be migrated. It may be
> necessary to rebuild packages installing completions after the upgrade,
> and remove old configuration symlinks afterwards. For details, please
> consult the app-shells/bash-completion post-install messages.
>
>
As I read in ebuild, the only additional information is about to run:
$ find ${EPREFIX}/usr/share/bash-completion -maxdepth 1 -type f '!'
-name 'bash_completion' -exec emerge -1v {} +
For rebuilding packages installing in old location and to run:
$ find ${EPREFIX}/etc/bash_completion.d -type l -delete
for removing the old links
Why not include this information in news item too? :)
Re: [gentoo-dev] News item review: bash-completion-2.1-r90
On 13/10/14 05:35 AM, Michał Górny wrote: > Please review the following news item. > > - > > Title: bash-completion-2.1-r90 > Author: Michał Górny > Content-Type: text/plain > Posted: -MM-DD > Revision: 1 > News-Item-Format: 1.0 > Display-If-Installed: > Starting with app-shells/bash-completion-2.1-r90, we are enabling > the completion autoloading support. Along with it, we are replacing > the eselect-bashcomp module with a new one suited better for the new > framework. > > Users will notice that the new framework is opt-out rather than opt-in. > Since completions are loaded on-demand, all of them are enabled > by default. If some of them are undesired, eselect-bashcomp can be used > to explicitly disable (mask) them. > > The current eselect-bashcomp setup will *not* be migrated. It may be > necessary to rebuild packages installing completions after the upgrade, > and remove old configuration symlinks afterwards. For details, please > consult the app-shells/bash-completion post-install messages. > > seems too oriented towards developer audiences, whereas news items are intended to target users; iow, I don't care what's going on behind the scenes, just tell me what I need to do to fix it. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News item review: bash-completion-2.1-r90
On Mon, Oct 13, 2014 at 07:37:19AM -0400, Alex Xu wrote: > On 13/10/14 05:35 AM, Michał Górny wrote: > > Please review the following news item. > > > > - > > > > Title: bash-completion-2.1-r90 > > Author: Michał Górny > > Content-Type: text/plain > > Posted: -MM-DD > > Revision: 1 > > News-Item-Format: 1.0 > > Display-If-Installed: > > > Starting with app-shells/bash-completion-2.1-r90, we are enabling > > the completion autoloading support. Along with it, we are replacing > > the eselect-bashcomp module with a new one suited better for the new > > framework. > > > > Users will notice that the new framework is opt-out rather than opt-in. > > Since completions are loaded on-demand, all of them are enabled > > by default. If some of them are undesired, eselect-bashcomp can be used > > to explicitly disable (mask) them. > > > > The current eselect-bashcomp setup will *not* be migrated. It may be > > necessary to rebuild packages installing completions after the upgrade, > > and remove old configuration symlinks afterwards. For details, please > > consult the app-shells/bash-completion post-install messages. > > > > > > seems too oriented towards developer audiences, whereas news items are > intended to target users; iow, I don't care what's going on behind the > scenes, just tell me what I need to do to fix it. > I disagree. I'm a user, and I'm interested in what is going on behind the scenes. I think that it's safe to assume that many Gentoo users care about the internals of the distribution too. I've actually been waiting for this to hit the tree since mgorny announced it. The news announcement is pretty good; I'd only incorporate pacho's suggestion to include the two commands needed to fix old stuff, and then I think it's good to go. —Guilherme
[gentoo-dev] Re: News item review: bash-completion-2.1-r90
Guilherme Amadio posted on Mon, 13 Oct 2014 09:52:11 -0300 as excerpted: > On Mon, Oct 13, 2014 at 07:37:19AM -0400, Alex Xu wrote: >> On 13/10/14 05:35 AM, Michał Górny wrote: >> > Please review the following news item. >> > >> > - >> > >> > Title: bash-completion-2.1-r90 >> > Author: Michał Górny >> > Content-Type: text/plain >> > Posted: -MM-DD >> > Revision: 1 >> > News-Item-Format: 1.0 >> > Display-If-Installed: > > >> > Starting with app-shells/bash-completion-2.1-r90, we are enabling the >> > completion autoloading support. Along with it, we are replacing the >> > eselect-bashcomp module with a new one suited better for the new >> > framework. >> > >> > Users will notice that the new framework is opt-out rather than >> > opt-in. Since completions are loaded on-demand, all of them are >> > enabled by default. If some of them are undesired, eselect-bashcomp >> > can be used to explicitly disable (mask) them. >> > >> > The current eselect-bashcomp setup will *not* be migrated. It may be >> > necessary to rebuild packages installing completions after the >> > upgrade, and remove old configuration symlinks afterwards. For >> > details, please consult the app-shells/bash-completion post-install >> > messages. >> > >> seems too oriented towards developer audiences, whereas news items are >> intended to target users; iow, I don't care what's going on behind the >> scenes, just tell me what I need to do to fix it. >> > I disagree. I'm a user, and I'm interested in what is going on behind > the scenes. I think that it's safe to assume that many Gentoo users > care about the internals of the distribution too. I've actually been > waiting for this to hit the tree since mgorny announced it. The news > announcement is pretty good; I'd only incorporate pacho's suggestion to > include the two commands needed to fix old stuff, and then I think it's > good to go. += Gentoo != Ubuntu. Many of our users do care what's going on, that's why they run gentoo, and for those that don't, a bit of extra information won't hurt 'em. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: News item review: bash-completion-2.1-r90
On Mon, Oct 13, 2014 at 9:56 AM, Duncan <1i5t5.dun...@cox.net> wrote: > > Many of our users do care what's going on, that's why they run gentoo, > and for those that don't, a bit of extra information won't hurt 'em. > Sure, though it may help to format things from a more "actionable" standpoint. By all means explain some of the why/how, but lead off with the what. Some messages that could be made a bit more clear: 1. If users don't do anything at all, then they may lose bash-completion support in installed packages until they are re-installed. If that doesn't bother them, then there is no need for action. If it does, use the provided instructions to ID and re-install these packages. 2. In the future, new package installs will enable their bash completion support automatically, and users will have to disable that package using eselect if they do not wish it. Any current selections using eselect bashcomp will be disregarded - it must be run again. 3. Unlike in the past, there is no longer a performance penalty from having too many bash completion modules enabled, which is why we're changing. We think that most users will prefer to just leave everything enabled now. The content is admittedly not all that different, but this focuses more on the impact for the user, rather than just describing the change itself. -- Rich
Re: [gentoo-dev] News item review: bash-completion-2.1-r90
Michał Górny wrote: > the new framework is opt-out rather than opt-in. Why is it desirable to make that change? //Peter pgpAbh_XiMjXl.pgp Description: PGP signature
[gentoo-dev] Removing a blocker from a stable package
I've got two obsolete packages masked currently: app-text/unix2dos and app-doc/djbdns-man. Both of them block other stable packages, app-text/dos2unix and net-dns/djbdns respectively. Fortunately, both of them have had version/revision bumps since the blocker so we can remove the blocker from the newer ebuild and then stabilize that, at which point there's no problem. But I wonder, what would be the best way to handle the situation if no version/revision bump had occurred? In other words, suppose that net-dns/djbdns-1.05-r30 didn't exist. In -r29, I have, KEYWORDS="alpha amd64 hppa ~mips ppc ppc64 sparc x86" DEPEND="!app-doc/djbdns-man" and app-doc/djbdns-man is now hard masked. Suppose I remove djbdns-man from the tree -- what do I do about the blocker? I see a couple of options: a) Edit the stable ebuild with ones fingers crossed b) Do a revbump and wait it out c) Do a revbump and file a stablereq immediately d) Do nothing, will repoman tolerate that? (b) is obviously safest, but (c) seems reasonable as well all things considered. Will the answer change when portage drops dynamic deps?
Re: [gentoo-dev] Removing a blocker from a stable package
(d) Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 13 October 2014 17:58, Michael Orlitzky wrote: > I've got two obsolete packages masked currently: app-text/unix2dos and > app-doc/djbdns-man. Both of them block other stable packages, > app-text/dos2unix and net-dns/djbdns respectively. > > Fortunately, both of them have had version/revision bumps since the > blocker so we can remove the blocker from the newer ebuild and then > stabilize that, at which point there's no problem. But I wonder, what > would be the best way to handle the situation if no version/revision > bump had occurred? > > In other words, suppose that net-dns/djbdns-1.05-r30 didn't exist. In > -r29, I have, > > KEYWORDS="alpha amd64 hppa ~mips ppc ppc64 sparc x86" > DEPEND="!app-doc/djbdns-man" > > and app-doc/djbdns-man is now hard masked. Suppose I remove djbdns-man > from the tree -- what do I do about the blocker? I see a couple of options: > > a) Edit the stable ebuild with ones fingers crossed > > b) Do a revbump and wait it out > > c) Do a revbump and file a stablereq immediately > > d) Do nothing, will repoman tolerate that? > > > (b) is obviously safest, but (c) seems reasonable as well all things > considered. Will the answer change when portage drops dynamic deps? > >
Re: [gentoo-dev] News item review: bash-completion-2.1-r90
On Mon, Oct 13, 2014 at 12:52 PM, Peter Stuge wrote: > Michał Górny wrote: >> the new framework is opt-out rather than opt-in. > > Why is it desirable to make that change? > > > //Peter
Re: [gentoo-dev] News item review: bash-completion-2.1-r90
Disregard previous fat-finger reply... On Mon, Oct 13, 2014 at 12:52 PM, Peter Stuge wrote: > Michał Górny wrote: >> the new framework is opt-out rather than opt-in. > > Why is it desirable to make that change? > See my previous email: 3. Unlike in the past, there is no longer a performance penalty from having too many bash completion modules enabled, which is why we're changing. We think that most users will prefer to just leave everything enabled now. -- Rich
Re: [gentoo-dev] Removing a blocker from a stable package
On 10/13/14 12:58, Michael Orlitzky wrote: I've got two obsolete packages masked currently: app-text/unix2dos and app-doc/djbdns-man. Both of them block other stable packages, app-text/dos2unix and net-dns/djbdns respectively. Fortunately, both of them have had version/revision bumps since the blocker so we can remove the blocker from the newer ebuild and then stabilize that, at which point there's no problem. But I wonder, what would be the best way to handle the situation if no version/revision bump had occurred? In other words, suppose that net-dns/djbdns-1.05-r30 didn't exist. In -r29, I have, KEYWORDS="alpha amd64 hppa ~mips ppc ppc64 sparc x86" DEPEND="!app-doc/djbdns-man" and app-doc/djbdns-man is now hard masked. Suppose I remove djbdns-man from the tree -- what do I do about the blocker? I see a couple of options: a) Edit the stable ebuild with ones fingers crossed b) Do a revbump and wait it out c) Do a revbump and file a stablereq immediately d) Do nothing, will repoman tolerate that? (b) is obviously safest, but (c) seems reasonable as well all things considered. Will the answer change when portage drops dynamic deps? You might be okay with rev bumping then then stabilizing yourself on the arches since the package has been already tested on them. The rev bump doesn't change any files on the system but just gets past the blocker. I don't want to speak for all arch teams, but I would be okay with that on the arches I take care of: arm, ppc, ppc64. In other words, go with C and do the stablereq yourself. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Removing a blocker from a stable package
On Mon, 13 Oct 2014 14:02:55 -0400 "Anthony G. Basile" wrote: > On 10/13/14 12:58, Michael Orlitzky wrote: > > I've got two obsolete packages masked currently: app-text/unix2dos > > and app-doc/djbdns-man. Both of them block other stable packages, > > app-text/dos2unix and net-dns/djbdns respectively. > > > > Fortunately, both of them have had version/revision bumps since the > > blocker so we can remove the blocker from the newer ebuild and then > > stabilize that, at which point there's no problem. But I wonder, > > what would be the best way to handle the situation if no > > version/revision bump had occurred? > > > > In other words, suppose that net-dns/djbdns-1.05-r30 didn't exist. > > In -r29, I have, > > > >KEYWORDS="alpha amd64 hppa ~mips ppc ppc64 sparc x86" > >DEPEND="!app-doc/djbdns-man" > > > > and app-doc/djbdns-man is now hard masked. Suppose I remove > > djbdns-man from the tree -- what do I do about the blocker? I see a > > couple of options: > > > >a) Edit the stable ebuild with ones fingers crossed > > > >b) Do a revbump and wait it out > > > >c) Do a revbump and file a stablereq immediately > > > >d) Do nothing, will repoman tolerate that? > > > > > > (b) is obviously safest, but (c) seems reasonable as well all things > > considered. Will the answer change when portage drops dynamic deps? > > > > You might be okay with rev bumping then then stabilizing yourself on > the arches since the package has been already tested on them. The > rev bump doesn't change any files on the system but just gets past > the blocker. I don't want to speak for all arch teams, but I would be > okay with that on the arches I take care of: arm, ppc, ppc64. In > other words, go with C and do the stablereq yourself. > The only right answer is d), carrying the block over to future versions for some time might even be appropriate.
Re: [gentoo-dev] Removing a blocker from a stable package
On Mon, Oct 13, 2014 at 2:20 PM, Ralph Sennhauser wrote: > On Mon, 13 Oct 2014 14:02:55 -0400 > "Anthony G. Basile" wrote: > >> On 10/13/14 12:58, Michael Orlitzky wrote: >> > I've got two obsolete packages masked currently: app-text/unix2dos >> > and app-doc/djbdns-man. Both of them block other stable packages, >> > app-text/dos2unix and net-dns/djbdns respectively. >> > >> > Fortunately, both of them have had version/revision bumps since the >> > blocker so we can remove the blocker from the newer ebuild and then >> > stabilize that, at which point there's no problem. But I wonder, >> > what would be the best way to handle the situation if no >> > version/revision bump had occurred? >> > >> > In other words, suppose that net-dns/djbdns-1.05-r30 didn't exist. >> > In -r29, I have, >> > >> >KEYWORDS="alpha amd64 hppa ~mips ppc ppc64 sparc x86" >> >DEPEND="!app-doc/djbdns-man" >> > >> > and app-doc/djbdns-man is now hard masked. Suppose I remove >> > djbdns-man from the tree -- what do I do about the blocker? I see a >> > couple of options: >> > >> >a) Edit the stable ebuild with ones fingers crossed >> > >> >b) Do a revbump and wait it out >> > >> >c) Do a revbump and file a stablereq immediately >> > >> >d) Do nothing, will repoman tolerate that? >> > >> > >> > (b) is obviously safest, but (c) seems reasonable as well all things >> > considered. Will the answer change when portage drops dynamic deps? >> > >> >> You might be okay with rev bumping then then stabilizing yourself on >> the arches since the package has been already tested on them. The >> rev bump doesn't change any files on the system but just gets past >> the blocker. I don't want to speak for all arch teams, but I would be >> okay with that on the arches I take care of: arm, ppc, ppc64. In >> other words, go with C and do the stablereq yourself. >> > > The only right answer is d), carrying the block over to future versions > for some time might even be appropriate. > I agree with Diego and Ralph: Go with d. repoman will generate a warning (not an error) about a dependency which does not exist, but this is safe to ignore.
[gentoo-dev] new virtual: virtual/podofo-build
Hi, In order to solve bug #503802 [1], I would like to add a virtual/podofo-build package to pull in app-text/podofo and dev-libs/boost. Then packages like app-text/calibre can put virtual/podofo-build in DEPEND and app-text/podofo in RDEPEND. The advantage of this approach is that it makes it possible to use a command like `emerge --depclean --with-bdeps=n` to remove the build-time only boost package (and virtual/podofo-build), since boost is only needed for build-time headers. There may be some other possible ways to specify the dependency, but this approach is the most attractive one that I've seen. In fact, this approach is basically identical to the "Virtual for C++ tr1 " example that's given in the dev-manual [2]. Would anyone like to suggest improvements to this idea, alternatives, or raise any objections? [1] https://bugs.gentoo.org/show_bug.cgi?id=503802 [2] http://devmanual.gentoo.org/general-concepts/virtuals/ -- Thanks, Zac
[gentoo-dev] OpenLDAP 2.3.x removal on October 27, migrate to 2.4.x
For compatibility and migration support, we've kept the old OpenLDAP 2.3.x ebuilds in the tree for nearly 5 years. OpenLDAP-2.4.x first went to stable 2009/11/04. package.mask has blocked
[gentoo-dev] last rites: dev-perl/Lucene
# Andreas K. Huettel (13 Oct 2014) # Does not build with current CLucene (bug 420195); dead upstream. # No consumers in the tree. Masked for removal in 30 days. dev-perl/Lucene -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] News item review: bash-completion-2.1-r90
Rich Freeman wrote: > >> the new framework is opt-out rather than opt-in. > > > > Why is it desirable to make that change? > > there is no longer a performance penalty There is a severe behavioral penalty! > We think that most users will prefer to just leave everything enabled now. I really do not want that to be chosen for me. Opt-out is not cool. :( //Peter
Re: [gentoo-dev] News item review: bash-completion-2.1-r90
On Mon, Oct 13, 2014 at 7:32 PM, Peter Stuge wrote: > > I really do not want that to be chosen for me. > > Opt-out is not cool. :( > Well, then all you need to do is tell eselect to disable them, etc. It always seemed pointless to me that there are a million bash completion filters installed on my system and I can't use them without going through eselect and turning them all on. :) I'm sure some subset of the users would prefer them to be opt-in, and another will prefer to have them be opt-out... -- Rich
Re: [gentoo-dev] OpenLDAP 2.3.x removal on October 27, migrate to 2.4.x
On 10/14/14 05:22, Robin H. Johnson wrote: > For compatibility and migration support, we've kept the old OpenLDAP > 2.3.x ebuilds in the tree for nearly 5 years. And you better keep them for a while, because some of us are stuck with 2.3, and mixed operation (e.g. master 2.4, slaves 2.3) is not supported. Since for example CentOS 5 is still around and there's no upgrade path, well, some people like me still have to use 2.3 ... > > OpenLDAP-2.4.x first went to stable 2009/11/04. > package.mask has blocked > I think the time has come to fully remove 2.3.x series, and the older > masked 2.4.x builds, so I strongly encourage everybody to move. Move away from other distros? Yes, that's definitely on my todo list, but it's not that easy, especially when it means upgrades to all services involved. > > The ebuild includes upgrade instructions, as in most major version > upgrades you need to dump+restore the database (both OpenLDAP major > versions, as well as changing backends or sys-lib/db major versions). > > Since it's been in package.mask for 6 months without reported bugs > complaining about this, I'm not going to announce it via a news item > unless there are strong demands to. >
Re: [gentoo-dev] News item review: bash-completion-2.1-r90
Peter Stuge wrote: > There is a severe behavioral penalty! Rich Freeman wrote: > > I really do not want that to be chosen for me. > > Well, then all you need to do is tell eselect to disable them, etc. Well, but see above - this is a huge change in behavior - I really don't think that should be done so lightly. I would be against it even if I actually wanted completions by default. > It always seemed pointless to me that there are a million bash > completion filters installed on my system and I can't use them > without going through eselect and turning them all on. :) Is USE=bash-completion set by default profiles? I suppose that that is what should actually control whether completions are available. I would unset it on my system to not have completions. //Peter
Re: [gentoo-dev] News item review: bash-completion-2.1-r90
On Tue Oct 14 03:32:32 2014 Peter Stuge wrote: > Rich Freeman wrote: > > > > the new framework is opt-out rather than opt-in. > > > > > > Why is it desirable to make that change? > > > > there is no longer a performance penalty > > There is a severe behavioral penalty! > > > > We think that most users will prefer to just leave everything enabled > > now. > > I really do not want that to be chosen for me. Given the amount of completions it's unmaintainable with opt-in: $ ls /usr/share/bash-completion/completions/ | wc -l 709 -- Alexander Tsoy
