Re: [gentoo-dev] bash-4.4 - call for testers
On Sun, Oct 2, 2016 at 1:28 PM, konsolebox wrote:
> On Sun, Oct 2, 2016 at 12:34 AM, Dan Douglas wrote:
>> I'd be perfectly happy requiring bundled readline when USE="readline"
>> for bash versions incompatible with the installed readline,
>
> I guess that's another good way to solve the readline issue (when it
> comes to bash). But I'd prefer that it's not done automatically.
> Instead we should add a formal use flag like 'installed-readline'. We
> can add it to release versions of bash ([[ ${PV} != *_rc* ]] &&
> IUSE+=' +installed-readline'), and enable it by default. Then we
> change all `[[ ${PV} != *_rc* ]]` condition checks to `[[ ${PV} !=
> *_rc* ]] && use installed-readline`. `${PV} != *_rc*` probably should
> also be `${PV} != *_alpha* && ${PV} != *_beta* && ${PV} != *_rc*`.
> (See attached file for POC.)
I missed disabling the dependency to readline when
'installed-readline' is disabled. Here's another example.
I also fixed a repoman warning related to tinfo and renamed
'installed_readline' to 'installed-readline'.
It installs and runs well with `USE='-installed-readline tinfo' emerge
-v 'bash::local'`.
The modifications related to tinfo by the way is related to this:
https://bugs.gentoo.org/show_bug.cgi?id=588486. I can't install bash
properly without it.
--
konsolebox
bash-4.4.ebuild
Description: Binary data
Re: [gentoo-dev] bash-4.4 - call for testers
On Sun, Oct 2, 2016 at 12:34 AM, Dan Douglas wrote:
> I'd be perfectly happy requiring bundled readline when USE="readline"
> for bash versions incompatible with the installed readline,
I guess that's another good way to solve the readline issue (when it
comes to bash). But I'd prefer that it's not done automatically.
Instead we should add a formal use flag like 'installed-readline'. We
can add it to release versions of bash ([[ ${PV} != *_rc* ]] &&
IUSE+=' +installed-readline'), and enable it by default. Then we
change all `[[ ${PV} != *_rc* ]]` condition checks to `[[ ${PV} !=
*_rc* ]] && use installed-readline`. `${PV} != *_rc*` probably should
also be `${PV} != *_alpha* && ${PV} != *_beta* && ${PV} != *_rc*`.
(See attached file for POC.)
> or simply depending on USE="-readline" for those versions.
> I rarely if ever use
> interactive mode with anything other than my system default /bin/bash.
I do, though. My application uses `read -e`. (That's not interactive
mode I know, but it still uses readline.)
--
konsolebox
bash-4.4.ebuild
Description: Binary data
Re: [gentoo-dev] bash-4.4 - call for testers
On Sat, Oct 1, 2016 at 4:48 PM, Dan Douglas wrote: > One note - it may be useful to install `BASH_LOADABLES_PATH=/usr/lib/bash` > to the global env.d environment when USE=plugins, now that bash has > this feature. It doesn't enable anything by default but just informs bash that > it can look for loadables in that location. > > (ins)ormaaj@smorgbox ~ $ BASH_LOADABLES_PATH=/usr/lib/bash bash > (ins)ormaaj@smorgbox ~ $ enable -f hello hello > hello builtin loaded > (ins)ormaaj@smorgbox ~ $ hello > hello world Hm on looking again it seems to look there anyway? I guess dlopen finds them via -rpath. Didn't know that was sufficient in this case. Sorry about that.
Re: [gentoo-dev] bash-4.4 - call for testers
One note - it may be useful to install `BASH_LOADABLES_PATH=/usr/lib/bash` to the global env.d environment when USE=plugins, now that bash has this feature. It doesn't enable anything by default but just informs bash that it can look for loadables in that location. (ins)ormaaj@smorgbox ~ $ BASH_LOADABLES_PATH=/usr/lib/bash bash (ins)ormaaj@smorgbox ~ $ enable -f hello hello hello builtin loaded (ins)ormaaj@smorgbox ~ $ hello hello world
[gentoo-dev] Last rite dev-libs/dbxml
David Seifert (18 Sep 2016) Masked for failing to build with GCC 6, still using ancient distutils.eclass, tightly coupled to dev-libs/xqilla-2.2*. Purged by Debian and Fedora more than 5 years ago. Mask for removal in 30 days. Bug #594236
[gentoo-dev] Last-rite net-libs/socket++
David Seifert (01 Oct 2016) Masked for failing to build with C++11, ancient codebase, dead upstream, no updates in 5 years. No revdeps. Mask for removal in 30 days. Bug #595754
[gentoo-dev] merging pull requests
All, this is a friendly reminder. If you are merging pull requests from Github into the tree, please remember to follow Gentoo ebuild maintenance policy [1]. In short, if you are not the maintainer of the ebuild or a member of a project listed in metadata.xml, you are only allowed to make changes if you know the maintainers approve of your changes or the maintainers make it clear that anyone can touch their packages. Thanks, William [1] https://devmanual.gentoo.org/ebuild-maintenance/index.html signature.asc Description: Digital signature
Re: [gentoo-dev] bash-4.4 - call for testers
On Sat, Oct 1, 2016 at 10:40 AM, konsolebox wrote: > I should also add that testing newer versions of bash becomes more > risky sometimes, since bash would sometimes need a newer version of > readline (see > https://lists.gnu.org/archive/html/bug-bash/2016-09/msg00020.html). > Rebuilding or installing a newer version of readline would cause some > other packages that depend on it to be rebuilt as well. > > If bash and readline become multi-slotted (or shared if there's a > difference), it would be easier to test them. Other stuff would also > not need to be rebuilt immediately. AFAIK upstream doesn't technically support unbundled readline anyway. If newer readline isn't tested with older bashes it would be miraculous for it to be backwards-compatible with every bash version in the tree. I'd be perfectly happy requiring bundled readline when USE="readline" for bash versions incompatible with the installed readline, or simply depending on USE="-readline" for those versions. I rarely if ever use interactive mode with anything other than my system default /bin/bash.
Re: [gentoo-dev] bash-4.4 - call for testers
I should also add that testing newer versions of bash becomes more risky sometimes, since bash would sometimes need a newer version of readline (see https://lists.gnu.org/archive/html/bug-bash/2016-09/msg00020.html). Rebuilding or installing a newer version of readline would cause some other packages that depend on it to be rebuilt as well. If bash and readline become multi-slotted (or shared if there's a difference), it would be easier to test them. Other stuff would also not need to be rebuilt immediately. -- konsolebox
Re: [gentoo-dev] bash-4.4 - call for testers
On Sat, Oct 1, 2016 at 8:38 AM, Kent Fredric wrote: > On Sat, 1 Oct 2016 01:49:56 +0800 > konsolebox wrote: > >> It would be nice to have some eselect command to >> easily switch from one version of Bash to another; probably something >> close to how it's done in dev-lang/ruby. > > Its just eselect itself is bash. So if bash is broken . switching out > becomes > impossible anyway. Good point, but that only applies if bash can become as broken as how you imagine it. I had tested many development versions of bash and none of them became that unusable, especially if it only comes to simple scripts like eselect. It's even more unlikely to happen with incremental releases (beta, rc, etc.). -- konsolebox
[gentoo-dev] Re: LLVM-3.9 news item for review
On 01/10/16 10:10, Michał Górny wrote: > explicitly selecting all targets. The item seems fine.
[gentoo-dev] LLVM-3.9 news item for review
Please review the inlined news item. I'd like to publish it when LLVM-3.9 is unmasked. -- Title: LLVM 3.9 with LLVM_TARGETS Author: Michał Górny Content-Type: text/plain Posted: 2016-..-.. Revision: 1 News-Item-Format: 1.0 Display-If-Installed: http://dev.gentoo.org/~mgorny/> pgpw_7R3xlSoM.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] bash-4.4 - call for testers
On Thu, Sep 29, 2016 at 5:29 PM, Kent Fredric wrote: > Maybe you could do some horrible QA Violation like USE=multislot > which changes the slot from :0 and adds the -suffix at the same time. > > But I still don't think its a useful or good idea. Really? Why is this a problem? Some issue to do with the symlink involving chroots or network filesystems I'm not considering? Looks like every version ends up in /bin anyway so you can make /bin/bash another hardlink that's a synonym for /bin/bash-suffix. I can't think of a way to screw that up other than perhaps by doing something weird with overlayfs.
Re: [gentoo-dev] bash-4.4 - call for testers
> I am against it as well. The purpose of this testing is to eventually > move to bash-4.4 being stable and replacing bash-4.3, so slotting it > would make that more complex later. Only true for users that have no interest in testing. Irrelevant for anyone that needs to test for backwards compatibility or cross-platform support in scripts. That's the only reason to support multiple slots of this in the first place. It doesn't imply one should substitute old versions for their system shell.
