Re: [gentoo-dev] www-client/chromium gtk3 support
On Fri, Sep 11, 2015 at 5:13 AM, Rich Freeman wrote: > On Fri, Sep 11, 2015 at 5:03 AM, Daniel Campbell wrote: > > > > I like the general 'gtk' flag we generally use to choose *which* > > toolkit, and local USE flags for specific versions, if they are > > supported. But in that case, the general gtk flag should be > > interpreted as the latest version supported, so users don't come > > across weirdly behaving packages that default to gtk2 (unless that > > version is the most stable). > > > >... > > > > For starters, versioned USE flags more than likely don't belong in > > make.conf's USE variable and shouldn't be global. > Personally i disagree with this. Versioned use flags for widely used dependencies (like a windowing toolkit) IMO qualify as global USE flags because they have a common effect across many packages. That was roughly my proposal. > > USE=gui or something like that if the main effect is to have a gui or > not. That is the sort of thing that SHOULD go in make.conf or in a > profile. If disabling gtk makes it a console-only application then > use the gui flag. > > USE=gtk if the main effect is to select /which/ toolkit is used if > more than one is optionally supported. That /might/ go in a make.conf > or profile, but probably shouldn't in general. It is more appropriate > for something like the desktop/gnome profile than the desktop profile. > > USE=gtk# if you're picking which version to use. That should /almost > never/ go in a profile (unless you're talking about a testing profile > of some kind, such as on an overlay), or in a global config unless you > REALLY know what you're getting into. Users setting this globally > should expect to run into bugs. The package should default these > flags to whatever is most appropriate for the specific package. > I really like this approach, and I think that having tiers of (gui)->(qt/gtk)->(qt4/qt5//gtk2/gtk3) would go a long way to keeping USE flags coherent. I'd be tempted to even say to not have gtk3 but instead call the flag > chromium-gtk3 or whatever so that it becomes very difficult to put in > the global config. However, that goes against our general principle > of letting the user break their system and keep the pieces if they > think they know what they're doing. If somebody WANTS to test out a > gtk3-only system or whatever they should have the freedom to do so, > understanding that testing sometimes uncovers problems. > I actually also think that there should be a single USE flag for building on gtk3, called gtk3. calling it "(packagename)-gtk3" is a bit redundant, and also flies in the face of having a single global flag with a coherent purpose. Of course any change will need a transition period, news, handbook > updates, etc. For the person who wants the "just works" experience > they can pick a profile and it will do the right thing, and if they > want to tailor things a bit more the USE=(-)gui flag will do what it > would be expected to do. > > -- > Rich > >
Re: [gentoo-dev] Re: USE="gui"
Duncan wrote: > hasufell posted on Fri, 11 Sep 2015 22:34:04 +0200 as excerpted: > >> USE flags in gentoo are the best and the worst thing at the same time. >> They are also mostly the main reason people don't like gentoo, because >> USE flags are (for todays situation) pretty much not an appropriate >> pattern to reflect real-world configuration. To be more precise... USE >> flags are first-class citizens and there is only one layer of them. > I agree with the one-layer problem, but just to say, without something > like USE flags, despite their single-layer-problem, I'd not be using > gentoo. Perhaps better can be done, but in the absence of better at the > moment, for better or worse, USE flags do get the job done, and I'd hate > to be without either them or an at least equally (if not more) powerful > replacement. > +1 If there is not some way to disable/enable things, there is little point is using Gentoo. Actually, Gentoo loses something huge that makes Gentoo different. Besides, how would you tell a package how and what to compile without USE flags?? Dale :-) :-)
[gentoo-dev] Re: USE="gui"
hasufell posted on Fri, 11 Sep 2015 22:34:04 +0200 as excerpted: > USE flags in gentoo are the best and the worst thing at the same time. > They are also mostly the main reason people don't like gentoo, because > USE flags are (for todays situation) pretty much not an appropriate > pattern to reflect real-world configuration. To be more precise... USE > flags are first-class citizens and there is only one layer of them. I agree with the one-layer problem, but just to say, without something like USE flags, despite their single-layer-problem, I'd not be using gentoo. Perhaps better can be done, but in the absence of better at the moment, for better or worse, USE flags do get the job done, and I'd hate to be without either them or an at least equally (if not more) powerful replacement. -- 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
[gentoo-dev] Re: USE="gui"
Ian Stakenvicius posted on Fri, 11 Sep 2015 14:03:59 -0400 as excerpted: > Also, I believe we need to have the conversation about the pros and cons > of IUSE=gui here before the council meeting, yes? Well, I brought up the idea in the context of Rich's already stated plan to start the discussion this council meeting, but only to take a straw- poll vote to get a general idea where council members stand, this time, and to hash it out more fully on the list, possibly with the benefit of an initial council suggested wording, before the real vote, presumably at the /next/ (that is, second from now) meeting. So that would be a yes, but I considered that presupposed. =:^) -- 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
[gentoo-dev] Re: news item: libvirt-1.2.19 init script upgrades
Matthias Maier posted on Fri, 11 Sep 2015 16:22:27 -0500 as excerpted: > Title: libvirt-1.2.19 init script changes ... > OpenRC Users: I'm not a libvirt (neither openrc, now) user, but it looks good here in terms of general clarity/spelling/grammar, and you didn't hit the commonly hit title-too-long bug. =:^) The only very minor nit I can /possibly/ find is that message opening... OpenRC users: That's arguably slightly confusing as it makes the news appear to be about openrc, but then the rest of it talks about libvirt. If you're a perfectionist, there's a possible argument for making that... OpenRC libvirt users: But arguably it's fine as-is. I doubt I'd miss the libvirt just reading it, and only saw it here because I was /trying/ to be picky! =:^) -- 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
[gentoo-dev] RFC: new function for versionator.eclass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hey all -- i have an idea for a new helper function for
versionator.eclass, that should improve correctness and convenience
when wanting to leverage $REPLACING_VERSIONS for checks in the
related phase functions.
Comments?
diff --git a/eclass/versionator.eclass b/eclass/versionator.eclass
index 74e676e..a92dfa7 100644
- --- a/eclass/versionator.eclass
+++ b/eclass/versionator.eclass
@@ -507,4 +507,27 @@ version_format_string() {
eval echo "${fstr}"
}
+# @FUNCTION: replacing_version_at_least
+# @USAGE:
+# @DESCRIPTION:
+# Are all values present in ${REPLACING_VERSIONS} at least version
$1? Uses version_is_at_least
+# and so may not be reliable, be sure to do very careful testing
before actually
+# using this.
+# Returns false if ${REPLACING_VERSIONS} is empty
+replacing_version_at_least() {
+ local tmp want=$1
+
+ case ${EBUILD_PHASE} in
+ pretend|setup|preinst|postinst)
+ if [[ -z ${REPLACING_VERSIONS} ]]; then
return 1 ; fi
+ for tmp in ${REPLACING_VERSIONS}; do
+ if ! version_is_at_least ${want}
${tmp}; then return 1; fi
+ done
+ return 0;
+ ;;
+ *)
+ die "replacing_version_at_least - invalid
phase: ${EBUILD_PHASE}"
+ esac
+}
+
fi
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlXzdD8ACgkQAJxUfCtlWe1nZQEAql2yv9bRSCGKdFTAM1dlszua
r1sAO6uV24+bUVvz4aMA/09q12uRea07Vy7I8pXT1w8YvN8EV03Fput8hDbunMHl
=Jkja
-END PGP SIGNATURE-
Re: [gentoo-dev] USE="gui"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/11/2015 01:34 PM, hasufell wrote:
> On 09/11/2015 08:03 PM, Ian Stakenvicius wrote:
>>
>> So, IUSE="X" has generally been used for gui, but more
>> technically it's used to depend on and build against x11-libs/*
>> packages. The fact that this gives a GUI is practically a
>> side-effect. When wayland comes along, do these packages still
>> build against x11-libs/* to support wayland?
>>
>> I'm just wondering if we're jumping the gun a little bit on
>> IUSE="gui".. yes it'll be nice to have one flag that "just
>> works" for anyone not caring about the details, but it'll also
>> mean propagating a slew of REQUIRED_USE="
>> {X,wayland,gtk,qt4,qt5}? ( gui )" entries and a lot of extra
>> use-defaults which may or may not cleanup the sub-profiles of
>> desktop/
>>
>> Also, I believe we need to have the conversation about the pros
>> and cons of IUSE=gui here before the council meeting, yes?
>>
>
>
> I already use IUSE=gui and will keep doing that.
>
> USE flags in gentoo are the best and the worst thing at the same
> time. They are also mostly the main reason people don't like
> gentoo, because USE flags are (for todays situation) pretty much
> not an appropriate pattern to reflect real-world configuration. To
> be more precise... USE flags are first-class citizens and there is
> only one layer of them. There's not configuration
> pattern/abstraction behind them. If you wonder what I am talking
> about, have a look at NixOS. The reason we lack proper declarative
> configuration is also the reason we had to introduce this ugliness
> called REQUIRED_USE. Instead of saying "gui.gtk" we say
> "REQUIRED_USE="gui? ( || ( gtk ... ) )". And it will get worse. I
> wonder when people start realizing that.
>
So are you suggesting maybe we come up with namespaced USE flags? That
would be interesting.
- --
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJV82lLAAoJEAEkDpRQOeFwiUAQAMoAzkd1NKwDaMeiKSwD1pIa
0RhytZ+YFMQp+A+eLuIIG7yzpbomzwMuQGe1YqHEAHibZx/C/Dfjdx5MMyAGAnkk
Am+ysOoHOZdGn/F5AMWNko4HZ+QxD22a1z6Mbkf00PE5J53vzgCAPh7nX6wRYFUP
Ag54pWCXP8xAN6hMmHtcyxz3vZ2s4AZfTvAlLcwVSCJmUa4Ki+64T/L8I6UMUC2h
qabu46RePWYDaTBDw7HB29Yja/UggGC7S9kTIvJYCwfyCbENOIa6kOU/qKeUP+Im
6blr8WfdWMUVlYxKlbPaibPQKUw3KCQIylLlp6Jn8Ix8tePyxm+086AE7q4qhbQX
64d6zbB+TaK8JC+ujWf90DmlXU0nTyMZ34Cooil1PwD5/b70lcSmTjxmffqSRG0w
KjUlI7op63qtiJ1r2PyLx1PliC6DVvhV9cZqO7oSB+mNi3oPKFCBNvIyhiCMQxzL
PrT80pF9HxloOarIMy0BCoHcr+qYYaoB20WqNC4XfM19iWsXQkvFCyUBFb9VxZd0
+EcGRRoVwr1UZjO8zYx5l1gdsvtck1Ka4WZgqVqeHFOgR+HJ18s5IfDLdSjOcDn4
F+XAewblzRAGsF4zM59q7ZIb70mmJmcAN6c1EmZwdrh0OAMH+HhXB97Z5tI/e3xY
8ouxCkDbfXutEydYI7mP
=jIAs
-END PGP SIGNATURE-
Re: [gentoo-dev] news item: libvirt-1.2.19 init script upgrades
Cardoe's second mail didn't make it to the list. Please find attached the second mail and the updated news announcement. = On 9/9/15 9:17 AM, Doug Goldstein wrote: > The following is the proposed news item to inform OpenRC users of a > change to the init script setup for libvirt 1.2.19 and newer. > There was some heartburn in #gentoo-dev about marking the init script as started automatically so the wording has been changed to reflect the changes to the ebuild which no longer do that. Title: libvirt-1.2.19 init script changes Author: Doug Goldstein Content-Type: text/plain Posted: 2015-09-09 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: signature.asc Description: PGP signature
Re: [gentoo-dev] USE="gui"
On 09/11/2015 08:03 PM, Ian Stakenvicius wrote:
>
> So, IUSE="X" has generally been used for gui, but more technically
> it's used to depend on and build against x11-libs/* packages. The
> fact that this gives a GUI is practically a side-effect. When
> wayland comes along, do these packages still build against
> x11-libs/* to support wayland?
>
> I'm just wondering if we're jumping the gun a little bit on
> IUSE="gui".. yes it'll be nice to have one flag that "just works"
> for anyone not caring about the details, but it'll also mean
> propagating a slew of REQUIRED_USE=" {X,wayland,gtk,qt4,qt5}? ( gui
> )" entries and a lot of extra use-defaults which may or may not
> cleanup the sub-profiles of desktop/
>
> Also, I believe we need to have the conversation about the pros and
> cons of IUSE=gui here before the council meeting, yes?
>
I already use IUSE=gui and will keep doing that.
USE flags in gentoo are the best and the worst thing at the same time.
They are also mostly the main reason people don't like gentoo, because
USE flags are (for todays situation) pretty much not an appropriate
pattern to reflect real-world configuration. To be more precise... USE
flags are first-class citizens and there is only one layer of them.
There's not configuration pattern/abstraction behind them. If you wonder
what I am talking about, have a look at NixOS. The reason we lack proper
declarative configuration is also the reason we had to introduce this
ugliness called REQUIRED_USE. Instead of saying "gui.gtk" we say
"REQUIRED_USE="gui? ( || ( gtk ... ) )". And it will get worse. I
wonder when people start realizing that.
Re: [gentoo-dev] USE="gui"
On Fri, Sep 11, 2015 at 2:03 PM, Ian Stakenvicius wrote:
> I'm just wondering if we're jumping the gun a little bit on
> IUSE="gui".. yes it'll be nice to have one flag that "just works"
> for anyone not caring about the details, but it'll also mean
> propagating a slew of REQUIRED_USE=" {X,wayland,gtk,qt4,qt5}? ( gui
> )" entries and a lot of extra use-defaults which may or may not
> cleanup the sub-profiles of desktop/
A completely valid concern. Of course, there is no requirement that
all this stuff happen overnight.
> Also, I believe we need to have the conversation about the pros and
> cons of IUSE=gui here before the council meeting, yes?
You can read my original post to -project:
http://article.gmane.org/gmane.linux.gentoo.project/4776
I did start it out with my reservation that this probably wouldn't
come to a vote. However, I did want to at least toss out a specific
proposal so that we have something to throw darts at, vs just going
around the room saying "sounds like something that might need some
attention."
This is of course an opportunity to have that conversation, but I
recognize that we're starting pretty late considering the timing of
the meeting. I didn't really intend to actually push for a vote on
this.
Most likely we'll express thoughts both pro and con, and then take it
back to the lists and maybe try to finalize something next month.
My sense is that this has been going on for a long time though and
we're seeing problems over and over. I agree that wayland is still a
bit off in the future, but I can see it coming up again there. In the
meantime both qt and gtk have run into this. I don't want to do
something just to do something, but it seems like my proposal is along
the lines of what most have been talking about.
--
Rich
[gentoo-dev] USE="gui"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/09/15 01:41 PM, Rich Freeman wrote:
> On Fri, Sep 11, 2015 at 1:11 PM, Duncan <1i5t5.dun...@cox.net>
> wrote:
>> Rich Freeman posted on Fri, 11 Sep 2015 08:13:48 -0400 as
>> excerpted:
>>
>>> USE=gui or something like that if the main effect is to have
>>> a gui or not. That is the sort of thing that SHOULD go in
>>> make.conf or in a profile. If disabling gtk makes it a
>>> console-only application then use the gui flag.
>>
>> I like the general proposal, but since it's going to council,
>> can we try to kill another bird with the same stone? This
>> USE=gui helps...
>>
>> Wayland's coming, and to the extent that USE=X has previously
>> indicated a GUI, much like USE=gtk and USE=qt indicating the
>> same thing, we're going to have problems.
>>
>> Can we make USE=gui the generic policy for that, and deprecate
>> more specific forms for choosing /any/ gui, so they can be used
>> for choosing /which/ gui?
>
> That was exactly why I used "gui" and not "X". We're going to
> run into the exact same problem once Wayland comes along with the
> way things have been done so far.
>
So, IUSE="X" has generally been used for gui, but more technically
it's used to depend on and build against x11-libs/* packages. The
fact that this gives a GUI is practically a side-effect. When
wayland comes along, do these packages still build against
x11-libs/* to support wayland?
I'm just wondering if we're jumping the gun a little bit on
IUSE="gui".. yes it'll be nice to have one flag that "just works"
for anyone not caring about the details, but it'll also mean
propagating a slew of REQUIRED_USE=" {X,wayland,gtk,qt4,qt5}? ( gui
)" entries and a lot of extra use-defaults which may or may not
cleanup the sub-profiles of desktop/
Also, I believe we need to have the conversation about the pros and
cons of IUSE=gui here before the council meeting, yes?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlXzF48ACgkQAJxUfCtlWe0ZQwD8CPt1rOkynOgb/as1gH/u2iYY
Du/EFPwleMDHVgMJDFYBAOfjguA8D1xTPJU9vzsvBf+y4rVFVvvFHuIX8+yyadjD
=SnN3
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: www-client/chromium gtk3 support
On Fri, Sep 11, 2015 at 1:11 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Rich Freeman posted on Fri, 11 Sep 2015 08:13:48 -0400 as excerpted: > >> USE=gui or something like that if the main effect is to have a gui or >> not. >> That is the sort of thing that SHOULD go in make.conf or in a profile. >> If disabling gtk makes it a console-only application then use the gui >> flag. > > I like the general proposal, but since it's going to council, can we try > to kill another bird with the same stone? This USE=gui helps... > > Wayland's coming, and to the extent that USE=X has previously indicated a > GUI, much like USE=gtk and USE=qt indicating the same thing, we're going > to have problems. > > Can we make USE=gui the generic policy for that, and deprecate more > specific forms for choosing /any/ gui, so they can be used for choosing > /which/ gui? That was exactly why I used "gui" and not "X". We're going to run into the exact same problem once Wayland comes along with the way things have been done so far. > > The question then remains whether ncurses, etc, should be treated as a > gui. Maybe make mention of that one way or the other in the policy as > well. > I actually was pondering that and left it out of my email. My gut feeling is that ncurses should be left alone for now. USE=-gui would mean console-only, whether that happens to include support for ncurses, aa, or whatever. Are there any applications out there which behave dramatically differently if they do/don't have ncurses support built-in? If you set TERM=dumb I imagine that software which actually supports this would just behave accordingly (ie if it is just using colors or moving progress bars or whatever it will drop the decorations). Usually though dumb terminal software tends to be somewhat dedicated (for things like editors and the like). I don't want to complicate things if nobody really cares about them. However, in theory you could treat various console-enhancing libraries in the same way. There is also svgalib and the like. -- Rich
[gentoo-dev] Re: www-client/chromium gtk3 support
Rich Freeman posted on Fri, 11 Sep 2015 08:13:48 -0400 as excerpted: > USE=gui or something like that if the main effect is to have a gui or > not. > That is the sort of thing that SHOULD go in make.conf or in a profile. > If disabling gtk makes it a console-only application then use the gui > flag. I like the general proposal, but since it's going to council, can we try to kill another bird with the same stone? This USE=gui helps... Wayland's coming, and to the extent that USE=X has previously indicated a GUI, much like USE=gtk and USE=qt indicating the same thing, we're going to have problems. Can we make USE=gui the generic policy for that, and deprecate more specific forms for choosing /any/ gui, so they can be used for choosing /which/ gui? Then of course ordain both X and wayland USE flags for choosing specific gui platform, like gtk and qt did at their level traditionally. The question then remains whether ncurses, etc, should be treated as a gui. Maybe make mention of that one way or the other in the policy as well. -- 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] Introduce ppc64le architecture into gentoo ! please share your comments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/09/15 08:01 AM, Leno Hou wrote: > 2. We believe to make Gentoo support ppc64le, we still need to > compile kernel and bootloader ...usually a gentoo installation requires you to build the kernel and bootloader yourself, inside of the chroot. Is this something that isn't possible? Or is the requirement related to a live-boot medium rather than the installation image? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXy4qwACgkQAJxUfCtlWe2mRAD/esR4zuaVTW4d1DMO43JYUbTe NJVFMQmzNVnZypHi9k8A/jjm9cB2hvJPCdf6JEnPO6rD1bh8iqByD0DX3NZEpstt =967P -END PGP SIGNATURE-
Re: [gentoo-dev] www-client/chromium gtk3 support
On Fri, Sep 11, 2015 at 5:03 AM, Daniel Campbell wrote: > > I like the general 'gtk' flag we generally use to choose *which* > toolkit, and local USE flags for specific versions, if they are > supported. But in that case, the general gtk flag should be > interpreted as the latest version supported, so users don't come > across weirdly behaving packages that default to gtk2 (unless that > version is the most stable). > >... > > For starters, versioned USE flags more than likely don't belong in > make.conf's USE variable and shouldn't be global. > That was roughly my proposal. USE=gui or something like that if the main effect is to have a gui or not. That is the sort of thing that SHOULD go in make.conf or in a profile. If disabling gtk makes it a console-only application then use the gui flag. USE=gtk if the main effect is to select /which/ toolkit is used if more than one is optionally supported. That /might/ go in a make.conf or profile, but probably shouldn't in general. It is more appropriate for something like the desktop/gnome profile than the desktop profile. USE=gtk# if you're picking which version to use. That should /almost never/ go in a profile (unless you're talking about a testing profile of some kind, such as on an overlay), or in a global config unless you REALLY know what you're getting into. Users setting this globally should expect to run into bugs. The package should default these flags to whatever is most appropriate for the specific package. I'd be tempted to even say to not have gtk3 but instead call the flag chromium-gtk3 or whatever so that it becomes very difficult to put in the global config. However, that goes against our general principle of letting the user break their system and keep the pieces if they think they know what they're doing. If somebody WANTS to test out a gtk3-only system or whatever they should have the freedom to do so, understanding that testing sometimes uncovers problems. Of course any change will need a transition period, news, handbook updates, etc. For the person who wants the "just works" experience they can pick a profile and it will do the right thing, and if they want to tailor things a bit more the USE=(-)gui flag will do what it would be expected to do. -- Rich
Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments
On Wed, Aug 12, 2015 at 4:30 PM, Anthony G. Basile wrote: > On 8/12/15 3:47 AM, Mike Frysinger wrote: > >> >> 4. I would like become a developer of porting gentoo on ppc64le. Anyone >>> could help/mentor me to join this project ? >>> >> ideally someone on the ppc side would pick you up, but i think they've >> been >> a bit of a skeleton team of late. so if need be, i can help you here. >> > > I can help out here. See in my mail > > > **Most importantly, Any Ideas/steps of how to porting gentoo on ppc64le >>> architecture?** >>> >> do you have hardware ? then it's simply a matter of booting Gentoo in it >> and >> filing/fixing bugs :). >> -mike >> > We should also start building stage3s. > > > -- > 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 > > > Appreciated your efforts and comments. 1. We've successfully compiled stage 3 for ppc64le. The stage 3 covers most useful functionalities: - GNU tool chains. e.g. automake, autoconf, gcc & glibc. - Normally use Portage, e.g. emerge, ebuild & python - Normally chroot in this stage 3. - Not included linux kernel & bootloader yet. 2. We believe to make Gentoo support ppc64le, we still need to compile kernel and bootloader - Which version of kernel provided by Gentoo would you suggest us to use? As to Ubuntu, there will be many patches to make the kernel workable, so how to patch our Gentoo kernel to make it work for ppc64le? - Which version of grub suitable for ppc64le ? Is there any patches to ppc64le grub ? 3. When the gentoo we make out workable on ppc64le, we would like to know the process of making it officially supported by Gentoo community - For each arch, do we have a subteam to verify the packages? If so, how to reach these guys? - For hardware environment, does anyone have Power8 systems ? -Leno Hou
Re: [gentoo-dev] www-client/chromium gtk3 support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/10/2015 11:26 AM, Rich Freeman wrote: > On Thu, Sep 10, 2015 at 2:21 PM, hasufell > wrote: >> On 09/10/2015 08:15 PM, Daniel Campbell wrote: >>> >>> tldr: If the problem is USE flags, let's talk USE flags. If >>> it's supporting more than one toolkit in general, I see no >>> reason not to let maintainers use their discretion and not >>> force their hand in either direction. >>> >> >> We have provided several arguments here repeatedly. >> > > Well, right now the status quo is that this is up to maintainers. > There is no policy that states otherwise. > > The USE flag issue is on the next council agenda, though I'm not > really confident that we'll resolve it in one go - there are only > a few days before the meeting. If anybody has concerns about the > approach that we take I'd suggest posting them on the thread, but > I suspect that most likely the council will go around the circle > and assess where everybody generally stands, then propose something > more solid for a vote the following meeting (which gives everybody > an opportunity to shoot holes it in beforehand). > Honestly, I can understand where the gnome team is coming from wrt keeping things moving forward. I personally don't think highly of gtk3, but in the grand scheme of things, if that's where it's going, maybe we *should* establish some policy on how USE flags are named and/or used. Use cases do indeed differ; sometimes it enables an optional GUI, sometimes it's one of many toolkit options. Whatever decision is made I'm fine with so long as I can ensure users of packages I maintain can choose which toolkit the package is built with (assuming upstream supports it, of course). I like the general 'gtk' flag we generally use to choose *which* toolkit, and local USE flags for specific versions, if they are supported. But in that case, the general gtk flag should be interpreted as the latest version supported, so users don't come across weirdly behaving packages that default to gtk2 (unless that version is the most stable). It's hard to apply such standards across a tree of thousands of packages, each with their own upstreams, build systems, code standards, and so on. I'm sure there's something we can find that enables us to continue providing choice to users while maintaining some semblance of consistency across the tree. For starters, versioned USE flags more than likely don't belong in make.conf's USE variable and shouldn't be global. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV8pjLAAoJEAEkDpRQOeFwu04P/0Hypny+iEXfEnvzl5MAVb+y OdpUYwhuhDq79cK5DEbs0sfc9deTYWj8PL8FOpxrSnunT6hwwesMepXQDWFInRhE aF9tvTgZJG7NlW6D4vG6d2+sOluuYXqkv75vezf173k/02WD8FxVlD3dbeIOrItn IH7JiBfJNzyXLgF9bjzxxV5ANe37jWf8j5ZGfvlv/NEiasM8zsDJzC0MQeEnPy6/ RNgjvP9U+BtWxHwLjgib6F4aYIr5aZzwa7bgbP7JGN88RPgui53LgklZjsxLh1sG qXnFmInejE2gNPt2yO5yxahue2tABCKiSFiZcYyhDMyA3vW+c4Uu71szlB2iWsWG ZeDG1FY5SR4nreD/Er/q5GQPuU/B32FzuJpc+e7F5uzBGVY+ZuHX9UJnFb6KFwg/ hxDXiVwJLoMHEMIfqk6NRI0A44aLDqJamND9Hv3D97jC1kLnu56qzhMVj+8/SQkn bXPtBQJEybMIemmobtm7clnjtY2wbFo4paN269+gJkgHoKmA+FpCCDX2eBFvCl/G yNkFEFwXp0SN4XaUQ3LysBlh3BZcb1grUeJKxt5punf9T6/Cc16V5jzjD7e2o/3g rD/oL5ea/BEyB2QPFII7IJl8V9kjAnVSPtGhvn8UJNtLUbS3tZEtwXONwDLNQV0R AD8GxhNJBRgau84x55na =v5ss -END PGP SIGNATURE-
