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 <willi...@gentoo.org> 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 <andymenderu...@gmail.com> 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

[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] [RFC] New USE_EXPAND: LLVM_TARGETS

[Andy Mender]

It does. In effect it determines which xorg-drivers are to be merged. This,
and some other packages with options for specific graphic cards/adapters.

Best regards,
Andy Mender.

On 27 Sep 2016 22:52, "Raymond Jennings" <shent...@gmail.com> wrote:

> On Sun, Sep 25, 2016 at 11:29 PM, Michał Górny <mgo...@gentoo.org> wrote:
>
>> On Mon, 26 Sep 2016 08:18:27 +0200
>> Michał Górny <mgo...@gentoo.org> wrote:
>>
>> > On Mon, 26 Sep 2016 00:42:11 +0300
>> > Mart Raudsepp <l...@gentoo.org> wrote:
>> >
>> > > Ühel kenal päeval, P, 25.09.2016 kell 23:08, kirjutas Michał Górny:
>> > > > I'd like to introduce a new USE_EXPAND for LLVM & clang. It'd be
>> > > > named
>> > > > LLVM_TARGETS, and it's going to replace the current solution based
>> on
>> > > > USE=multitarget & VIDEO_CARDS=radeon.
>> > > >
>> > > > - VIDEO_CARDS=radeon enabled additional R600 target,
>> > >
>> > > No. It enables AMDGPU target these days, which is for the modern stuff
>> > > and very much needed by them.
>> > > r600 stuff was in the llvm 3.3-3.6 era, which was used by old
>> > > experimental mesa[r600-llvm-compiler] as an alternative shader
>> compiler
>> > > for r600 instead of builtin mesa stuff. This work has been ditched
>> long
>> > > ago afaik.
>> > > Instead now VIDEO_CARDS=radeon is required on llvm for radeonsi and
>> > > later AMD GPUs for _ANY_ shader compiler support at all, plus other
>> > > things (from it adding AMDGPU to llvm targets in current ebuild).
>> >
>> > Yes, yes, I am old :-P. You are right, it's AMDGPU these days.
>> >
>> > > > The new system will be applied to 3.9.0 and  ebuilds.
>> VIDEO_CARDS
>> > > > flag will be removed completely because of no revdeps.
>> > >
>> > > People with radeonsi graphics set VIDEO_CARDS=radeon already, I'm a
>> bit
>> > > reserved about having to force them to set some LLVM_TARGETS=radeon or
>> > > LLVM_TARGETS=amdgpu on top of that to satisfy some USE depends on
>> > > mesa[video_cards_radeon].
>> >
>> > How about nvidia users who seem to require NVPTX for libclc these days?
>> > Do they set VIDEO_CARDS='nvidia nv nouveau ...'? The problem is that
>> > this abuse of VIDEO_CARDS is never going to be 100% clear to users.
>> >
>> > I guess we can enable GPU targets in desktop profiles by default to
>> > save most of our users from the issues.
>>
>> Hmm, I actually see we're enabling them in arch profiles. So I guess
>> matching enable there would fit there as well.
>>
>> --
>> Best regards,
>> Michał Górny
>> <http://dev.gentoo.org/~mgorny/>
>>
>
> This might be a stupid question, but I have a hunch I'm not the only user
> curious about this.
>
> Doesn't VIDEO_CARDS factor in on xorg-server's video driver selection?
>