Re: [gentoo-dev] bash-4.4 - call for testers

[konsolebox]

On Mon, Oct 3, 2016 at 3:09 PM, Kent Fredric  wrote:
> On Mon, 3 Oct 2016 14:37:15 +0800
> konsolebox  wrote:
>
>> But anyway, what do you think about just enabling
>> IUSE="+system-readline" by default to any version, and just rely on
>> KEYWORDS="" to prevent the user from misusing it with a pre-release
>> version of bash?  I believe we can both agree on that idea.
>
> Yeah. And at least that way if you need to prevent its use/force
> its use for any arch target you can use the USE forces.
>
> In general "less magical behaviour that tracks its version" is a good
> thing.

I created a formal request for this in
https://bugs.gentoo.org/show_bug.cgi?id=596028.

-- 
konsolebox

Re: [gentoo-dev] bash-4.4 - call for testers

[Kent Fredric]

On Mon, 3 Oct 2016 14:37:15 +0800
konsolebox  wrote:

> But anyway, what do you think about just enabling
> IUSE="+system-readline" by default to any version, and just rely on
> KEYWORDS="" to prevent the user from misusing it with a pre-release
> version of bash?  I believe we can both agree on that idea.

Yeah. And at least that way if you need to prevent its use/force
its use for any arch target you can use the USE forces.

In general "less magical behaviour that tracks its version" is a good
thing.


pgpJRAeCJ7ext.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] bash-4.4 - call for testers

[konsolebox]

On Mon, Oct 3, 2016 at 1:53 PM, Kent Fredric  wrote:
> And I get the impression that the desire you have to have different
> behaviour for non-rc versions is a bit niche.

Not quite.  I just started by siding with the current implementation
which is to disable system readline in rc versions of bash.  You're
actually the one challenging a new implementation which would allow
it.

But anyway, what do you think about just enabling
IUSE="+system-readline" by default to any version, and just rely on
KEYWORDS="" to prevent the user from misusing it with a pre-release
version of bash?  I believe we can both agree on that idea.

-- 
konsolebox

Re: [gentoo-dev] bash-4.4 - call for testers

[Kent Fredric]

On Mon, 3 Oct 2016 13:32:34 +0800
konsolebox  wrote:

> "A useflag that entirely goes away depending on the version" (or a
> flag that is implemented in one ebuild but is not on another) is
> pretty common among packages and I see that as totally valid, and is
> way better than a solution that uses dynamic default.

I think the main assumption I'm trying to challenge here is that users
would desire different USE and BUILD configurations based on _rc
status, and I don't think that's much the case.

People IME tend to prefer to set something on a package level, and then
apply consistent enforcement for all versions, or perhaps apply USE
flags to ranges of versions ( ie: everything larger than X, everything
smaller than X ), or on a per-slot basis.

Mostly because its consistent and minimises the amount of effort.

Thus, for basically any argument you can make for having the USE flag
at all, maps to an argument that applies to both _rc and non _rc
versions.

And I get the impression that the desire you have to have different
behaviour for non-rc versions is a bit niche.

( I can appreciate it in a - version, but that produces a situation
which falls under "all versions larger than 9" and thus gives you
version-range based consistency. )

Anything else seems to me to devolve into "being too fiddly", and may
discourage testing.

But I also see it that people who are testing _rc + KEYWORDS=""
versions to be people who's express intent is to optimise for maximum
breakage, in order to find the most possible problems before they
happen, and problems like "readline version is too new or too old" are
exactly the kinds of problems I'd want to make sure we didn't have
before we shipped bash in that configuration to everyone ( even to
~arch )






pgp0vezaOl0aI.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] bash-4.4 - call for testers

[konsolebox]

On Mon, Oct 3, 2016 at 1:37 PM, konsolebox  wrote:
> I created another example for this.

I mistakenly renamed --with-installed-readline to
--with-system-readline there, sorry.  Here's the correct one.

-- 
konsolebox


bash-4.4-r1.ebuild
Description: Binary data

Re: [gentoo-dev] bash-4.4 - call for testers

[konsolebox]

I examined both RC versions of bash and readline, and it turns out
that the KEYWORDS are disabled in those.  If that is -always- the
case, we could just have IUSE='+system-readline' in any version
regardless if it's a release or not, since users would not be able to
install it anyway, unless they apply 'app-shells/bash **' to
/etc/portage/package.keywords.  If they do, then that means they're
prepared for the risk, and should know when to use the use flag.

I created another example for this.  This time, the feature can still
be disabled, but only if there is no counter-package of readline for
the targetted version of bash, which may happen in alpha or beta
versions; not to mention  (and 9), which I believe should be
easy to implement now after this.

-- 
konsolebox


bash-4.4-r1.ebuild
Description: Binary data

Re: [gentoo-dev] bash-4.4 - call for testers

[konsolebox]

On Sun, Oct 2, 2016 at 7:42 PM, Kent Fredric  wrote:
> On Sun, 2 Oct 2016 18:18:17 +0800
> konsolebox  wrote:
>
>> I should also add that a dynamic "default" that varies depending on
>> the version doesn't sound good to me. For one at least, it confuses
>> the user.
>
> I agree that its a bit unintuitive.
>
> However, the alternatives are:
>
> - A useflag that entirely goes away depending on the version
> - A useflag that is inoperative depending on the version
>
> Neither of those are improvements.

"A useflag that entirely goes away depending on the version" (or a
flag that is implemented in one ebuild but is not on another) is
pretty common among packages and I see that as totally valid, and is
way better than a solution that uses dynamic default.

> And in both cases they're additionally messy as they require
> additional logic that changes what DEPEND is based on the version.

Doesn't look so messy to me.  My solution is pretty clean and
understandable.  It would only depend on how it is perceived by the
reading coder.  The bash ebuild was also already hacky enough.  Maybe
you're just being conservative because it doesn't always happen in
ebuilds.

>> Also, do you think there could be a helpful case that one would
>> install a non-release version of bash that compiles against the system
>> readline?  Perhaps if you're also brave enough to install an
>> pre-release version of readline to the system, there is.
>
> If this scenario was the expected scenario for non-rc releases, its only
> sensible that the development versions should be testing that usecase.
>
> If for example the development versions always only tested using their bundled
> readlines, and then the non-development versions always used dependencies,
> then testing is somewhat pointless.

Pointless for bash, or applications that depend on readline as well?
Because if it's only about bash, I see no difference.

If someone would want to try a pre-release readline, nothing would
stop him from doing it.

> Because you're no longer testing for real world problems that would be 
> possible
> due to using systemized dependenices.( ie: stipulating a new enough version,
> incompatibilities due to gentoo patching, etc )

If some maintainer would really want a pre-release bash tested against
an external pre-release readline, he's free to modify the ebuild to
work that way - just like how he uses to.  We can even add an internal
non-importing custom variable so this could be easily configured.  But
I don't think it's necessary to allow end-users to have that kind of
feature as well.

> "don't use external readline" would have to be the default of bash and
> everyone would have to be being encouraged to be using it that way in order
> for making the testing of that combination also a default.

Ok I don't -really- see that as a bad alternative.  The only question
is, would everyone want that?  And it still doesn't avoid the issue of
users not being able to make 'system-readline' only apply to release
versions of bash, once they enable it globally.

> Otherwise you're testing a situation that will never be a reality.

The difference in our view is whether we should allow users to test if
a -pre-release- bash would link and run well against a pre-release
readline, or not.  That really isn't something to be concerned of, if
you consider that release versions would be tested anyway.  Getting
those will-link-or-not-and-run-properly cases for pre-release versions
tested by developers should be enough.

--
konsolebox

Re: [gentoo-dev] bash-4.4 - call for testers

[Kent Fredric]

On Sun, 2 Oct 2016 18:18:17 +0800
konsolebox  wrote:

> I should also add that a dynamic "default" that varies depending on
> the version doesn't sound good to me. For one at least, it confuses
> the user.

I agree that its a bit unintuitive. 

However, the alternatives are:

- A useflag that entirely goes away depending on the version
- A useflag that is inoperative depending on the version

Neither of those are improvements. 

And in both cases they're additionally messy as they require
additional logic that changes what DEPEND is based on the version.

> Also, do you think there could be a helpful case that one would
> install a non-release version of bash that compiles against the system
> readline?  Perhaps if you're also brave enough to install an
> pre-release version of readline to the system, there is.

If this scenario was the expected scenario for non-rc releases, its only
sensible that the development versions should be testing that usecase.

If for example the development versions always only tested using their bundled
readlines, and then the non-development versions always used dependencies,
then testing is somewhat pointless.

Because you're no longer testing for real world problems that would be possible
due to using systemized dependenices.( ie: stipulating a new enough version,
incompatibilities due to gentoo patching, etc )

"don't use external readline" would have to be the default of bash and
everyone would have to be being encouraged to be using it that way in order
for making the testing of that combination also a default.

Otherwise you're testing a situation that will never be a reality.




pgppbEXcpePqY.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] bash-4.4 - call for testers

[konsolebox]

On Sun, Oct 2, 2016 at 6:00 PM, konsolebox  wrote:
> On Sun, Oct 2, 2016 at 4:58 PM, Kent Fredric  wrote:
>> On Sun, 2 Oct 2016 16:03:11 +0800
>> konsolebox  wrote:
>>
>>> I actually don't like the idea of enabling or disabling
>>> "installed-readline" based on the `${PV} != *_rc*` condition.  If a
>>> user would want to explicitly enable "installed-readline" globally,
>>> how would he make sure that it only affects the release version of
>>> bash?  I suggest that we just don't entertain the flag (and not make
>>> it available) if the ebuild is not targetting a release version, and
>>> not use the readline installed by the system by default.  No one would
>>> need a non-release version of bash compiled against a system readline
>>> anyway.
>>
>> That's not what that does.  It doesn't enable or disable the mechanic,
>> the code I offered only changes the default for _rc.
>>
>> That is, on _rc the default is "use bundled readline implementation",
>> and on non_rc, the default is "use pre-existing readline
>> implementation".
>>
>> if the user specifies an explicit
>>
>> USE="system-readline"
>>
>> in make.conf or /etc/portage/package.use, then this "default" gets
>> overridden and the system readline implementation is always used.
>>
>> if the user speciifies an explicit
>>
>> USE="-system-readline"
>>
>> in make.conf or /etc/portage/package.use, then this "default" gets
>> overriden and the inbuilt readline is awlays used.
>>
>> Explicitly defined configuration always trumps IUSE. The "+" prefix in
>> IUSE only specifies that the USE flag defaults to on, as opposed to
>> defaulting off.
>
> I understand those elementary stuff, but my point was about whether we
> should allow the user to configure 'system-readline' on a non-release
> version of bash (i.e. make the flag available for them to configure).
> Your point is that instead of statically deciding whether we shouldn't
> use `--with-installed-readline` through `${PV} != *_rc*`, we instead
> base it on the flag, which means we allow the users to change the
> behavior of -non-release- versions of bash, which is, compiling
> against the bundled readline, to compiling against the system readline
> instead.
>
> How would a user be able to apply a distinguishing global
> configuration which would apply differently when the installing bash
> version is a release version, and when it's not?  You might say that
> `system-readline` is enabled by default in a release version anyway,
> so specifying `system-readline` explicitly is meaningless and should
> only be done if you want to change the behavior of non-release
> versions of bash.  But that's not the point.  It's about the
> consistency.  When we specify use flags in /etc/portage/make.conf, it
> shouldn't depend on the current default "enability" of a package's use
> flag.
>
> Also, do you think there could be a helpful case that one would
> install a non-release version of bash that compiles against the system
> readline?  Perhaps if you're also brave enough to install an
> pre-release version of readline to the system, there is.
>
> Again, I say that it's better that the 'installed-readline' flag or
> 'system-readline' flag is only made available in the release versions
> of bash.  And we also don't want to make it a dummy where it is just
> ignored and not excluded.

I should also add that a dynamic "default" that varies depending on
the version doesn't sound good to me. For one at least, it confuses
the user.

-- 
konsolebox

Re: [gentoo-dev] bash-4.4 - call for testers

[konsolebox]

On Sun, Oct 2, 2016 at 4:58 PM, Kent Fredric  wrote:
> On Sun, 2 Oct 2016 16:03:11 +0800
> konsolebox  wrote:
>
>> I actually don't like the idea of enabling or disabling
>> "installed-readline" based on the `${PV} != *_rc*` condition.  If a
>> user would want to explicitly enable "installed-readline" globally,
>> how would he make sure that it only affects the release version of
>> bash?  I suggest that we just don't entertain the flag (and not make
>> it available) if the ebuild is not targetting a release version, and
>> not use the readline installed by the system by default.  No one would
>> need a non-release version of bash compiled against a system readline
>> anyway.
>
> That's not what that does.  It doesn't enable or disable the mechanic,
> the code I offered only changes the default for _rc.
>
> That is, on _rc the default is "use bundled readline implementation",
> and on non_rc, the default is "use pre-existing readline
> implementation".
>
> if the user specifies an explicit
>
> USE="system-readline"
>
> in make.conf or /etc/portage/package.use, then this "default" gets
> overridden and the system readline implementation is always used.
>
> if the user speciifies an explicit
>
> USE="-system-readline"
>
> in make.conf or /etc/portage/package.use, then this "default" gets
> overriden and the inbuilt readline is awlays used.
>
> Explicitly defined configuration always trumps IUSE. The "+" prefix in
> IUSE only specifies that the USE flag defaults to on, as opposed to
> defaulting off.

I understand those elementary stuff, but my point was about whether we
should allow the user to configure 'system-readline' on a non-release
version of bash (i.e. make the flag available for them to configure).
Your point is that instead of statically deciding whether we shouldn't
use `--with-installed-readline` through `${PV} != *_rc*`, we instead
base it on the flag, which means we allow the users to change the
behavior of -non-release- versions of bash, which is, compiling
against the bundled readline, to compiling against the system readline
instead.

How would a user be able to apply a distinguishing global
configuration which would apply differently when the installing bash
version is a release version, and when it's not?  You might say that
`system-readline` is enabled by default in a release version anyway,
so specifying `system-readline` explicitly is meaningless and should
only be done if you want to change the behavior of non-release
versions of bash.  But that's not the point.  It's about the
consistency.  When we specify use flags in /etc/portage/make.conf, it
shouldn't depend on the current default "enability" of a package's use
flag.

Also, do you think there could be a helpful case that one would
install a non-release version of bash that compiles against the system
readline?  Perhaps if you're also brave enough to install an
pre-release version of readline to the system, there is.

Again, I say that it's better that the 'installed-readline' flag or
'system-readline' flag is only made available in the release versions
of bash.  And we also don't want to make it a dummy where it is just
ignored and not excluded.

>> I also thought using 'system-' prefix is confusing.  Does that mean
>> the system of the machine, or the system of the application?  In
>> firefox, I once thought that system-* means packages bundled within
>> it.  Perhaps I misread, or perhaps it was changed.  At that time,
>> descriptions of use flags were not widely provided yet so I could only
>> guess it based on how I built the packages.
>
> The system of the machine. As in, "Operating System". Always.
> "system-foo" usually means "foo is bundled, and toggling this flag
> toggles between using the bundled foo, or the system foo.

Yes, but I'm not talking about how it is now.  But nevermind.

>> But I don't really mind which one is used.  I also just thought
>> 'installed-readline' is better since it configures
>> `--with-installed-readline`, so one can simply have `$(use_enable
>> installed-readline)` if applicable.
>
> 'use_enable' takes a USE flag and a configure token anyway.
>
> So:
>
> $(use_enable system-readline installed-readline)
>
> is equivalent to:
>
>  use system-readline && myconf+=" --enable-installed-readline"

I know, but like I said, "simply".  `installed-readline` is just more
relative.  But I don't really care whatever gets used.

-- 
konsolebox

Re: [gentoo-dev] bash-4.4 - call for testers

[Kent Fredric]

On Sun, 2 Oct 2016 16:03:11 +0800
konsolebox  wrote:

> I actually don't like the idea of enabling or disabling
> "installed-readline" based on the `${PV} != *_rc*` condition.  If a
> user would want to explicitly enable "installed-readline" globally,
> how would he make sure that it only affects the release version of
> bash?  I suggest that we just don't entertain the flag (and not make
> it available) if the ebuild is not targetting a release version, and
> not use the readline installed by the system by default.  No one would
> need a non-release version of bash compiled against a system readline
> anyway.

That's not what that does.  It doesn't enable or disable the mechanic,
the code I offered only changes the default for _rc.

That is, on _rc the default is "use bundled readline implementation",
and on non_rc, the default is "use pre-existing readline
implementation".

if the user specifies an explicit

USE="system-readline"  

in make.conf or /etc/portage/package.use, then this "default" gets
overridden and the system readline implementation is always used.

if the user speciifies an explicit

USE="-system-readline" 

in make.conf or /etc/portage/package.use, then this "default" gets
overriden and the inbuilt readline is awlays used.

Explicitly defined configuration always trumps IUSE. The "+" prefix in
IUSE only specifies that the USE flag defaults to on, as opposed to
defaulting off.

> 
> I also thought using 'system-' prefix is confusing.  Does that mean
> the system of the machine, or the system of the application?  In
> firefox, I once thought that system-* means packages bundled within
> it.  Perhaps I misread, or perhaps it was changed.  At that time,
> descriptions of use flags were not widely provided yet so I could only
> guess it based on how I built the packages.

The system of the machine. As in, "Operating System". Always.
"system-foo" usually means "foo is bundled, and toggling this flag
toggles between using the bundled foo, or the system foo.

> 
> But I don't really mind which one is used.  I also just thought
> 'installed-readline' is better since it configures
> `--with-installed-readline`, so one can simply have `$(use_enable
> installed-readline)` if applicable.

'use_enable' takes a USE flag and a configure token anyway. 

So:

$(use_enable system-readline installed-readline)

is equivalent to:

 use system-readline && myconf+=" --enable-installed-readline"

But you probably wanted "use_with" ( man 5 ebuild )

$(use_with system-readline installed-readline)

Which is instead equivalent to

use system-readline && myconf+=" --with-installed-readline"



pgpVvou7e6YxO.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] bash-4.4 - call for testers

[konsolebox]

On Sun, Oct 2, 2016 at 1:40 PM, Kent Fredric  wrote:
> On Sun, 2 Oct 2016 13:28:04 +0800
> konsolebox  wrote:
>
>> 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.)
>
> Conventionally, it would be better to have IUSE=" +system-readline"
>
> Though I'd probably opt for
>
> IUSE=" system-readline"
>
> As the default for development versions.
>
>
>if [[ ${PV} != *_rc* ]]; then
>   IUSE+=" system-readline"
>else;
>   IUSE+=" +system-readline"
>fi

I actually don't like the idea of enabling or disabling
"installed-readline" based on the `${PV} != *_rc*` condition.  If a
user would want to explicitly enable "installed-readline" globally,
how would he make sure that it only affects the release version of
bash?  I suggest that we just don't entertain the flag (and not make
it available) if the ebuild is not targetting a release version, and
not use the readline installed by the system by default.  No one would
need a non-release version of bash compiled against a system readline
anyway.

I also thought using 'system-' prefix is confusing.  Does that mean
the system of the machine, or the system of the application?  In
firefox, I once thought that system-* means packages bundled within
it.  Perhaps I misread, or perhaps it was changed.  At that time,
descriptions of use flags were not widely provided yet so I could only
guess it based on how I built the packages.

But I don't really mind which one is used.  I also just thought
'installed-readline' is better since it configures
`--with-installed-readline`, so one can simply have `$(use_enable
installed-readline)` if applicable.

-- 
konsolebox

Re: [gentoo-dev] bash-4.4 - call for testers

[Kent Fredric]

On Sun, 2 Oct 2016 13:28:04 +0800
konsolebox  wrote:

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

Conventionally, it would be better to have IUSE=" +system-readline"

Though I'd probably opt for 

IUSE=" system-readline" 

As the default for development versions.


   if [[ ${PV} != *_rc* ]]; then
  IUSE+=" system-readline"
   else;
  IUSE+=" +system-readline"
   fi


pgpK86gxRJ3s1.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] bash-4.4 - call for testers

[konsolebox]

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

[konsolebox]

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

[Dan Douglas]

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

[Dan Douglas]

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

Re: [gentoo-dev] bash-4.4 - call for testers

[Dan Douglas]

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

[konsolebox]

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

[konsolebox]

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

Re: [gentoo-dev] bash-4.4 - call for testers

[Dan Douglas]

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

[Dan Douglas]

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

Re: [gentoo-dev] bash-4.4 - call for testers

[Kent Fredric]

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.


pgpyIRUvKS7g7.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] bash-4.4 - call for testers

[konsolebox]

On Fri, Sep 30, 2016 at 5:56 AM, Andy Mender  wrote:
> Would it be OK to have the real stable version (now, Bash 4.3) as slot :0
> and a single testing version (now, Bash 4.4) as slot:1 in addition to
> needing the "~amd64" flag?

Or simply 4.3 and 4.4, not 0 and 1. And then 5.0 for the next
development version, or just .

-- 
konsolebox

Re: [gentoo-dev] bash-4.4 - call for testers

[konsolebox]

On Thu, Sep 29, 2016 at 1:54 PM, Dan Douglas  wrote:
> The only reason I haven't been testing this for many months
> system-wide is it's in the same slot as 4.3, and it still is. Is it
> not possible to separate them?

That would also be helpful to me since I closely monitor the
development of Bash.  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.

-- 
konsolebox

Re: [gentoo-dev] bash-4.4 - call for testers

[Andy Mender]

Alright then, I will give bash4.4 a try and if there are any problems, I'll
file a proper bug report.

Best regards,
Andy

On 30 September 2016 at 15:38, William Hubbs  wrote:

> On Fri, Sep 30, 2016 at 11:29:05AM +1300, Kent Fredric wrote:
> > On Thu, 29 Sep 2016 23:56:34 +0200
> > Andy Mender  wrote:
> >
> > > I believe the main problem comes from /bin/bash and potential symlinks
> that
> > > would need to be introduced as part of  the slotting.
> >
> > In a pinch you could probably get away with
> > calling :1 /usr/bin/bash-4.4 instead of /usr/bin/bash, and then
> > offering no luxuries beyond that, leaving it up to the user to do the
> rest.
> >
> > Then you could test it in ~/ with PATH + Symlink in ~/bin/ ... maybe.
> >
> > There would just not be much point, because the real purpose of testing
> > 4.4 is not for fear of it breaking user experience ( which is a
> > problem, but not the primary motive ),  but for making everything else
> > that runs with bash runs OK.
> >
> > 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.
>
> 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.
>
> William
>
>

Re: [gentoo-dev] bash-4.4 - call for testers

[William Hubbs]

On Fri, Sep 30, 2016 at 11:29:05AM +1300, Kent Fredric wrote:
> On Thu, 29 Sep 2016 23:56:34 +0200
> Andy Mender  wrote:
> 
> > I believe the main problem comes from /bin/bash and potential symlinks that
> > would need to be introduced as part of  the slotting.
> 
> In a pinch you could probably get away with
> calling :1 /usr/bin/bash-4.4 instead of /usr/bin/bash, and then
> offering no luxuries beyond that, leaving it up to the user to do the rest.
> 
> Then you could test it in ~/ with PATH + Symlink in ~/bin/ ... maybe.
> 
> There would just not be much point, because the real purpose of testing
> 4.4 is not for fear of it breaking user experience ( which is a
> problem, but not the primary motive ),  but for making everything else
> that runs with bash runs OK.
> 
> 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.

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.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] bash-4.4 - call for testers

[Kent Fredric]

On Thu, 29 Sep 2016 23:56:34 +0200
Andy Mender  wrote:

> I believe the main problem comes from /bin/bash and potential symlinks that
> would need to be introduced as part of  the slotting.

In a pinch you could probably get away with
calling :1 /usr/bin/bash-4.4 instead of /usr/bin/bash, and then
offering no luxuries beyond that, leaving it up to the user to do the rest.

Then you could test it in ~/ with PATH + Symlink in ~/bin/ ... maybe.

There would just not be much point, because the real purpose of testing
4.4 is not for fear of it breaking user experience ( which is a
problem, but not the primary motive ),  but for making everything else
that runs with bash runs OK.

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.


pgpz1hFyHx4J3.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] bash-4.4 - call for testers

[Andy Mender]

Yes, I also wouldn't want to sacrifice something as relevant as the default
Shell interpreter.
I quickly checked other GNU/Linux distributions and even on Arch Linux Bash
4.3 seems to be the newest stable version.

Would it be OK to have the real stable version (now, Bash 4.3) as slot :0
and a single testing version (now, Bash 4.4) as slot:1 in addition to
needing the "~amd64" flag?

I believe the main problem comes from /bin/bash and potential symlinks that
would need to be introduced as part of  the slotting.

Best regards,
Andy

On 29 September 2016 at 07:54, Dan Douglas  wrote:

> The only reason I haven't been testing this for many months
> system-wide is it's in the same slot as 4.3, and it still is. Is it
> not possible to separate them?
>
>

Re: [gentoo-dev] bash-4.4 - call for testers

[Dan Douglas]

The only reason I haven't been testing this for many months
system-wide is it's in the same slot as 4.3, and it still is. Is it
not possible to separate them?

Re: [gentoo-dev] bash-4.4 - call for testers

[David Haller]

Hello,

On Thu, 22 Sep 2016, David Haller wrote:
[..]
>I've found this that I guess has to do with the new readline:
>
>>From the build.log of
>emerge -1 dev-lisp/clisp
>
>
>[..]
> * Package:dev-lisp/clisp-2.49-r8
> * Repository: gentoo
> * Maintainer: common-l...@gentoo.org
> * USE:X abi_x86_64 amd64 berkdb elibc_glibc gdbm gtk
>   kernel_linux pcre postgres readline threads unicode userland_GNU
>   zlib
> * FEATURES:   ccache compressdebug nostrip preserve-libs sandbox
>   splitdebug userpriv usersandbox
>[..]
>;; Loading file 
>/var/tmp/portage/dev-lisp/clisp-2.49-r8/work/clisp-2.49/builddir/readline/readline.fas
> ...
>*** - FFI::FIND-FOREIGN-VARIABLE: foreign variable #"rl_readline_state" #x0088B460> does not have the
>  required size or alignment
>
>./clisp-link: failed in 
>/var/tmp/portage/dev-lisp/clisp-2.49-r8/work/clisp-2.49/builddir
>Makefile:2621: recipe for target 'base' failed
>make: *** [base] Error 1
>[..]
>
[..]

Got a patch for that:
https://bugs.gentoo.org/show_bug.cgi?id=594552
https://bugs.gentoo.org/attachment.cgi?id=447492

-dnh

-- 
Since attendees must wear their name tags, they must also wear shirts
or blouses.  Pants or skirts are also highly recommended. -- RFC 1391

Re: [gentoo-dev] bash-4.4 - call for testers

[David Haller]

Hello,

On Tue, 20 Sep 2016, Lars Wendler wrote:
>This is a call for testers. If you feel brave enough, please give
>bash-4.4 a shot and report all problems you might have with it.
>
>Add the following to you package.unmask file/directory:
>
>  =app-shells/bash-4.4*
>  =sys-libs/readline-7.0*

with basically no testing so far: builds ok.

>in order to get all readline reverse deps being built against new
>readline. Reporting those packages in our bug tracker [1] would be
>helpful.

Creating a new bug or what? [2] seems inappropriate.

>[2] https://bugs.gentoo.org/594496

I've found this that I guess has to do with the new readline:

>From the build.log of
emerge -1 dev-lisp/clisp


[..]
 * Package:dev-lisp/clisp-2.49-r8
 * Repository: gentoo
 * Maintainer: common-l...@gentoo.org
 * USE:X abi_x86_64 amd64 berkdb elibc_glibc gdbm gtk
   kernel_linux pcre postgres readline threads unicode userland_GNU
   zlib
 * FEATURES:   ccache compressdebug nostrip preserve-libs sandbox
   splitdebug userpriv usersandbox
[..]
;; Loading file 
/var/tmp/portage/dev-lisp/clisp-2.49-r8/work/clisp-2.49/builddir/readline/readline.fas
 ...
*** - FFI::FIND-FOREIGN-VARIABLE: foreign variable # does not have the
  required size or alignment

./clisp-link: failed in 
/var/tmp/portage/dev-lisp/clisp-2.49-r8/work/clisp-2.49/builddir
Makefile:2621: recipe for target 'base' failed
make: *** [base] Error 1
[..]


# equery uses -i =dev-lisp/clisp-2.49-r8 | xargs echo
+X +berkdb -dbus -fastcgi +gdbm +gtk -hyperspec -pari +pcre +postgres
+readline +threads +unicode +zlib

So, something with 'rl_readline_state' and how clisp uses that has
changed that I won't dig into right now. Clisp maintainers?

That seems to be the only problem with readline-7.0/bash-4.4 on this
install (so far).

-dnh

-- 
  The use of COBOL cripples the mind; its teaching should,
  therefore, be regarded as a criminal offence.
 -- Edsger Wybe Dijkstra