Re: [gentoo-dev] RFC: gles global USE flag, USE=opengl clarifying
On Mon, 23 Jul 2018 17:43:59 -0700 Matt Turner wrote: > > Initially I thought of a global USE=gles2, but during the writing of > > this e-mail, I realized that as USE=opengl doesn't specify a version > > either (e.g. 3.3 or 4.5), so combined with gles3 not really needing > > a separate handling, it'd be more consistent with just USE=gles. > > However I'm rather torn on this - it could just as well be USE=gles2 > > instead, which just specifies that it's GLESv2 or later; then it's > > also clear we don't deal with old GLESv1 via this. > > gles2 is much more common than just gles in the tree. There are no > known gles1 applications on desktop Linux, so I'm happy to just remove > the gles1 flag from media-libs/mesa. > > I'd say we go with gles2. There hasn't been a new release in years but Neverball's git master supports GLESv1! Even my Vivante-based ARM board can run it with OpenGL though as it only requires 1.4 or something. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] Deprecation of virtual/libmysqlclient and virtual/mysql as providers for libmysqlclient.so
On 7/24/2018 12:44 AM, David Seifert wrote: > On Mon, 2018-07-23 at 14:18 -0400, Brian Evans wrote: >> With the current state of the forks of MySQL diverging, the client >> libraries are no longer compatible. >> >> Since virtual packages cannot handle rebuilds of subscribed packages >> when a consumer changes, the following action is to be taken by all >> developers: >> >> If you need libmysqlclient.so, please depend on dev-db/mysql- >> connector-c. >> If you need or can use libmariadb.so, please depend on >> dev-db/mariadb-connector-c. >> >> (Yes the above packages coexist just fine.) >> >> Please remove references to virtual/libmysqlclient as it does not >> work >> as I intended (and explained above). This virtual will be last-rites >> once nothing depends on it. >> >> Please remove all DEPEND on virtual/mysql where it is used for >> libraries. >> virtual/mysql is the client and server tools *only*. >> It is not correct to rely on this for libraries any longer. >> A good example for DEPEND is tests where the client/server binaries >> are run. >> RDEPEND for the purpose of running client/server is fine for >> virtual/mysql. >> >> Almost all of the consumers of virtual/mysql have already been >> updated >> (save mysql-cluster). Some are already stable. >> >> At a point in the future, likely in 2019, the compatibility DEPEND >> that >> exist in the consumers will be removed and may break packages which >> are >> not updated. >> >> In the coming months, I will try my best to test and report bugs on >> packages which I can find. >> >> I welcome any discussion on the details, but this is the only sane >> move >> for Gentoo and the ABI incompatibilities that exist on the client >> libraries. >> >> Thank you, >> >> Brian Evans >> > > How do you plan on dispatching against them at compile/link-time, i.e. > USE=libav/graphicsmagick/libressl? > > David > If a maintainer wishes to have a USE flag to link to libmariadb, that's up to them. Use of mariadb-connector-c may need patching (for mariadb_config or mariadb.pc) or build options to look at the other library. This may be beneficial for licensing purposes (GPL-2 vs LGPL-2.1) If such a flag is popular enough, then a global description can be agreed upon. Brian signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Adding USE=udev to linux profiles
On Mon, 23 Jul 2018 11:03:34 -0400 Mike Gilbert wrote: > On Mon, Jul 23, 2018 at 1:47 AM Andreas K. Huettel > wrote: > > > > Am Donnerstag, 19. Juli 2018, 23:51:17 CEST schrieb Ben Kohler: > > > Hello, > > > > > > I'd like to propose adding USE=udev to our linux profiles (in > > > profiles/default/linux/make.defaults probably). This flag is already > > > enabled on desktop profiles but it also affects quite a few packages > > > > > > Any objections to this idea? > > > > We removed the dedicated "server profiles" and told everyone > > "Don't ever use -*"; if you want to have a sane minimal set of features use > > the base profile as e.g. default/linux/amd64/17.0". > > > > If with USE=udev this profile still fulfills the definition of "sane minimal > > set of features", then it's fine. > > > > (Keep in mind, we have all sorts of people out there running gentoo not only > > on desktops or beefy servers.) > > > > Otherwise it should stay in desktop profile. > > USE="udev" is a sane default for anything that will be running on real > or emulated hardware. It might not be necessary for containers, which > don't do any hardware management. I do not agree with you. I have perfectly fine running Gentoo-based servers running without udev and so many other people. udev in desktop profile is just fine with me, on servers it is not needed in many cases. Best regards, Andrew Savchenko pgpickXtzqojh.pgp Description: PGP signature
Re: [gentoo-dev] Adding USE=udev to linux profiles
On Tue, Jul 24, 2018 at 11:05 AM Andrew Savchenko wrote: > > On Mon, 23 Jul 2018 11:03:34 -0400 Mike Gilbert wrote: > > On Mon, Jul 23, 2018 at 1:47 AM Andreas K. Huettel > > wrote: > > > > > > Am Donnerstag, 19. Juli 2018, 23:51:17 CEST schrieb Ben Kohler: > > > > Hello, > > > > > > > > I'd like to propose adding USE=udev to our linux profiles (in > > > > profiles/default/linux/make.defaults probably). This flag is already > > > > enabled on desktop profiles but it also affects quite a few packages > > > > > > > > Any objections to this idea? > > > > > > We removed the dedicated "server profiles" and told everyone > > > "Don't ever use -*"; if you want to have a sane minimal set of features > > > use > > > the base profile as e.g. default/linux/amd64/17.0". > > > > > > If with USE=udev this profile still fulfills the definition of "sane > > > minimal > > > set of features", then it's fine. > > > > > > (Keep in mind, we have all sorts of people out there running gentoo not > > > only > > > on desktops or beefy servers.) > > > > > > Otherwise it should stay in desktop profile. > > > > USE="udev" is a sane default for anything that will be running on real > > or emulated hardware. It might not be necessary for containers, which > > don't do any hardware management. > > I do not agree with you. I have perfectly fine running > Gentoo-based servers running without udev and so many other people. > udev in desktop profile is just fine with me, on servers it is not > needed in many cases. You can run any system without udev, but you need to be very careful about what Linux features you utilize and how you have the system configured. Most Linux servers out in the wild are running udev; your configuration is an exception to the common case.
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 07/24/2018 11:39 AM, Mike Gilbert wrote: > > You can run any system without udev, but you need to be very careful > about what Linux features you utilize and how you have the system > configured. > > Most Linux servers out in the wild are running udev; your > configuration is an exception to the common case. > udev itself works fine with the flag off. Please be wary of the Firefox marketing model. Gentoo users are Gentoo users because Gentoo is easy to customize. If you sacrifice that to make Gentoo a poor imitation of Fedora in an effort to cater to new users, a) New users will choose Fedora anyway, because it's better at being Fedora. b) Some annoyed Gentoo users will also become Fedora users.
Re: [gentoo-dev] Adding USE=udev to linux profiles
On Tue, Jul 24, 2018 at 12:06 PM Michael Orlitzky wrote: > > On 07/24/2018 11:39 AM, Mike Gilbert wrote: > > > > You can run any system without udev, but you need to be very careful > > about what Linux features you utilize and how you have the system > > configured. > > > > Most Linux servers out in the wild are running udev; your > > configuration is an exception to the common case. > > > > Gentoo users are Gentoo users because Gentoo is easy to customize. I don't believe anybody suggested making Gentoo harder to customize. This is just about setting reasonable defaults. You can run a server without bash, openrc, sysvinit, or glibc. Should these also be removed from the base profile? -- Rich
Re: [gentoo-dev] Adding USE=udev to linux profiles
On Tue, Jul 24, 2018 at 12:06 PM Michael Orlitzky wrote: > > On 07/24/2018 11:39 AM, Mike Gilbert wrote: > > > > You can run any system without udev, but you need to be very careful > > about what Linux features you utilize and how you have the system > > configured. > > > > Most Linux servers out in the wild are running udev; your > > configuration is an exception to the common case. > > > > udev itself works fine with the flag off. udevd works, but other software will not work optimally. If you are running udevd, it's usually good idea to have other stuff integrate with it, generally to prevent race conditions as devices are enumerated. For example, dhcpcd integrates with udevd via libudev to ensure that udev has finished renaming your network interfaces before dhcpcd attempts to configure them. I believe lvm2 uses libudev to prevent various races in block device setup and metadata gathering. Developers don't add udev support just for the hell of it; they do it to make their software play nice with hardware when udevd is running.
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 07/24/2018 12:14 PM, Rich Freeman wrote: > > I don't believe anybody suggested making Gentoo harder to customize. > This is just about setting reasonable defaults. For the (N+1)th time: enabling this flag by default does make Gentoo harder to customize, because you can't turn it off. And so yes, everyone suggesting that we enable the flag by default is suggesting that Gentoo become harder to customize. > You can run a server without bash, openrc, sysvinit, or glibc. Should > these also be removed from the base profile? Three of those four aren't in the base profile. Yeah, it was a good idea to remove them.
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 07/24/2018 12:24 PM, Mike Gilbert wrote: > > For example, dhcpcd integrates with udevd via libudev to ensure that > udev has finished renaming your network interfaces before dhcpcd > attempts to configure them. I believe lvm2 uses libudev to prevent > various races in block device setup and metadata gathering. Both of those have IUSE="+udev", which is fine for any package where the maintainer knows that udev support is critical. You yourself aren't even sure what it does for lvm2, though -- how are you going to convince me I need it? > Developers don't add udev support just for the hell of it hahahahahahaha your premise is that the people writing software aren't all idiots, and I deny it.
Re: [gentoo-dev] Adding USE=udev to linux profiles
On Tue, Jul 24, 2018 at 12:27 PM Michael Orlitzky wrote: > > On 07/24/2018 12:14 PM, Rich Freeman wrote: > > > > I don't believe anybody suggested making Gentoo harder to customize. > > This is just about setting reasonable defaults. > > For the (N+1)th time: Well, if it was already said, why did you add another reply? > enabling this flag by default does make Gentoo > harder to customize, because you can't turn it off. This was already addressed in a previous comment - PMS can be modified to nullify flags, and arguably it should already work this way (though that means subprofiles can't actually use -flags). > > You can run a server without bash, openrc, sysvinit, or glibc. Should > > these also be removed from the base profile? > > Three of those four aren't in the base profile. Yeah, it was a good idea > to remove them. It includes virtual/service-manager, which pulls in sysvinit and openrc by default. You can run just fine without any service manager. Just point the kernel at your daemon and it will launch it as PID 1. Also, you can use sysvinit without openrc and have it launch your daemon, but that also won't satisfy service-manager. But, none of this matters, because people who REALLY want to run without a service manager can do that with package.provided. Again, this is about sane defaults, and having a service manager is a sane default. -- Rich
Re: [gentoo-dev] Adding USE=udev to linux profiles
On Tue, Jul 24, 2018 at 12:32 PM Michael Orlitzky wrote: > > On 07/24/2018 12:24 PM, Mike Gilbert wrote: > > > > For example, dhcpcd integrates with udevd via libudev to ensure that > > udev has finished renaming your network interfaces before dhcpcd > > attempts to configure them. I believe lvm2 uses libudev to prevent > > various races in block device setup and metadata gathering. > > Both of those have IUSE="+udev", which is fine for any package where the > maintainer knows that udev support is critical. You yourself aren't even > sure what it does for lvm2, though -- how are you going to convince me I > need it? > > > > Developers don't add udev support just for the hell of it > > hahahahahahaha your premise is that the people writing software aren't > all idiots, and I deny it. > So upstream developers are all idiots, and Gentoo maintainers always know best? If that's your attitude, I won't bother arguing with your further.
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 07/24/2018 12:37 PM, Rich Freeman wrote: >> harder to customize, because you can't turn it off. > > This was already addressed in a previous comment - PMS can be modified > to nullify flags Saying that hypothetically we could modify the PMS and wait for a new EAPI and wait for all package managers to catch up and wait a year after that for the upgrade path and then update the profiles to a new EAPI and then implement this new feature is just an indirect way of saying "you can't do it." Changing the PMS won't let me set USE="-udev" in make.conf, anyway. It would only affect sub-profiles.
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 2018-07-21 9:33 a.m., Rich Freeman wrote:
> On Sat, Jul 21, 2018 at 5:33 AM Zac Medico wrote:
>>
>> Sure, why not? So ^flag would mean that the flag state propagates from
>> the settings in IUSE.
>
> Presumably this could be overridden in subsequent profiles, or
> /etc/portage. That is, one profile might set a flag, and another
> profile could unset it, and then the final one could re-set it.
>
>> It's also conceivable that we could add a way for
>> profiles to modify the effective IUSE defaults, via new operators in
>> package.use or by introducing a new file such as package.use.default.
>
> That makes sense, or the syntax could be available in the ebuild. I
> imagine the better approach to take would depend on the nature of the
> incompatibility.
>
This is getting a little scary as to what is overriding what, within a
repo.
Lets take a look at what we -can- do right now:
(a) use flag can be set globally by the repo
(b) ebuild IUSE can set (and unset?) a flag's state
(c) make.defaults and package.use from the profile (that generally is
defined within the gentoo repo) sets/unsets a flag's state
(d) make.conf sets/unsets a flag's state
(e) /etc/portage/package.use sets/unsets a flag's state
(f) {,package.}use.{mask,force} from the profile overrides a-e
(g) /etc/portage/profile/{,package.}use.{mask,force} overrides f
That's a lot of possible state overriding.
Now as I understand it, the issue here is that there is no way in (d)
to undo what is done in (c) on a global per-flag basis, ie, from
make.defaults, such that IUSE(b) is honored, correct?
What if we just split (c) so that make.defaults (c1) and package.use
(c2) are applied independently? That way (d) is meant to override
(c1), and (e) is meant to override (c2), and if an end-user wants IUSE
to take priority over (c1)+(d) they can change USE_ORDER accordingly?
I believe with wildcards, that in (e) we can set global flag overrides
still via an atom (like "*/*::gentoo [flag]") in
/etc/portage/package.use, correct? So we end-users would still have
the ability to define global state of a flag with a single line even
if IUSE was prioritized above make.defaults+make.conf
Note that I'm not suggesting we change the default value of USE_ORDER
right now, only that if we split 'defaults' into 'makedefaults' and
'packagedefaults' that end-users could set it up themselves a lot more
easily by changing their own USE_ORDER default.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Adding USE=udev to linux profiles
On Tue, Jul 24, 2018 at 12:49 PM Michael Orlitzky wrote: > > On 07/24/2018 12:37 PM, Rich Freeman wrote: > >> harder to customize, because you can't turn it off. > > > > This was already addressed in a previous comment - PMS can be modified > > to nullify flags > Saying that hypothetically we could modify the PMS and wait for a new > EAPI and wait for all package managers to catch up and wait a year after > that for the upgrade path and then update the profiles to a new EAPI and > then implement this new feature is just an indirect way of saying "you > can't do it." > > Changing the PMS won't let me set USE="-udev" in make.conf, anyway. It > would only affect sub-profiles. Certainly it should be implemented so that you could use it in make.conf. I also said nothing about the order of changes here. The PMS change could be made and be effective before the profile change is made. -- Rich
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 2018-07-22 1:52 p.m., Michael Orlitzky wrote: > > [...] > > It looks to me like *within (sub)profiles*, a USE="-foo" should undo > USE=foo, rather than adding "-foo" to the list of tokens that get pushed > down via USE_ORDER. > ...except that we often want the sub-profile containing "-foo" to not only undo +foo from a parent profile BUT ALSO unset +foo from IUSE. IE, the way "-jit" is set globally in hardened profiles. Though you do bring up an interesting point -- as portage may be the only one doing it this way, I wonder what happens with other PMs... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Adding USE=udev to linux profiles
Am Dienstag, 24. Juli 2018, 19:15:19 CEST schrieb Ian Stakenvicius:
> On 2018-07-21 9:33 a.m., Rich Freeman wrote:
> > On Sat, Jul 21, 2018 at 5:33 AM Zac Medico wrote:
> >> Sure, why not? So ^flag would mean that the flag state propagates from
> >> the settings in IUSE.
> >
> > Presumably this could be overridden in subsequent profiles, or
> > /etc/portage. That is, one profile might set a flag, and another
> > profile could unset it, and then the final one could re-set it.
> >
> >> It's also conceivable that we could add a way for
> >> profiles to modify the effective IUSE defaults, via new operators in
> >> package.use or by introducing a new file such as package.use.default.
> >
> > That makes sense, or the syntax could be available in the ebuild. I
> > imagine the better approach to take would depend on the nature of the
> > incompatibility.
>
> This is getting a little scary as to what is overriding what, within a
> repo.
I also tried to untangle this in my email from Sat, 21 Jul 2018 14:45:12 +
It indeed is a bit confusing, but I think you got it right in your list below:
> Lets take a look at what we -can- do right now:
>
> (a) use flag can be set globally by the repo
> (b) ebuild IUSE can set (and unset?) a flag's state
> (c) make.defaults and package.use from the profile (that generally is
> defined within the gentoo repo) sets/unsets a flag's state
> (d) make.conf sets/unsets a flag's state
> (e) /etc/portage/package.use sets/unsets a flag's state
> (f) {,package.}use.{mask,force} from the profile overrides a-e
> (g) /etc/portage/profile/{,package.}use.{mask,force} overrides f
>
> That's a lot of possible state overriding.
I, too, would hope that at some point later, independently of this discussion,
the algorithm for determining what use flags are active for a certain package
could be simplified.
--Dennis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 2018-07-24 1:55 p.m., Dennis Schridde wrote:
> Am Dienstag, 24. Juli 2018, 19:15:19 CEST schrieb Ian Stakenvicius:
>>
>> This is getting a little scary as to what is overriding what, within a
>> repo.
>
> I also tried to untangle this in my email from Sat, 21 Jul 2018 14:45:12 +
>
Yeah I did see that after posting my message; I believe both of our
lists align.
>
>> Lets take a look at what we -can- do right now:
>>
>> (a) use flag can be set globally by the repo
>> (b) ebuild IUSE can set (and unset?) a flag's state
>> (c) make.defaults and package.use from the profile (that generally is
>> defined within the gentoo repo) sets/unsets a flag's state
>> (d) make.conf sets/unsets a flag's state
>> (e) /etc/portage/package.use sets/unsets a flag's state
>> (f) {,package.}use.{mask,force} from the profile overrides a-e
>> (g) /etc/portage/profile/{,package.}use.{mask,force} overrides f
>>
>> That's a lot of possible state overriding.
>
> I, too, would hope that at some point later, independently of this
> discussion,
> the algorithm for determining what use flags are active for a certain package
> could be simplified.
>
I don't think the process needs to be simplified much more than this;
each layer above has its purpose. However I do very much want to
caution on making it more complicated, especially with the addition of
syntax that allows setting or ignoring useflag state changes in a way
that will jumble up these layers.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Adding USE=udev to linux profiles
On Tue, Jul 24, 2018 at 2:32 PM Ian Stakenvicius wrote: > > I don't think the process needs to be simplified much more than this; > each layer above has its purpose. However I do very much want to > caution on making it more complicated, especially with the addition of > syntax that allows setting or ignoring useflag state changes in a way > that will jumble up these layers. > I think as long as it is a heirarchy it will be straightforward enough. If we introduce a ^ operator that unsets a flag, the only question is how far that propagates down the layers, and into what kinds of layers: Does a profile ^flag undo an IUSE +flag? Does a make.conf ^flag undo a profile +flag? An IUSE +flag? A profile flag mask? Does a package.use ^flag undo a make.conf +flag? A profile +flag, an IUSE +flag? Etc... This matters more than with +/-, since these just bluntly set the flag to one setting or the other regardless of what happened below (I think - I'd have to check all the different possibilities even for that). When you're just unsetting things the question is how many of these flags do you unset going down how far? Obviously if you unset everything up to that point then it is no different from -flag as we default to off on everything. -- Rich
Re: [gentoo-dev] Adding USE=udev to linux profiles
On Tuesday, 24 July 2018 20:57:09 CEST Rich Freeman wrote: > On Tue, Jul 24, 2018 at 2:32 PM Ian Stakenvicius wrote: > > I don't think the process needs to be simplified much more than this; > > each layer above has its purpose. However I do very much want to > > caution on making it more complicated, especially with the addition of > > syntax that allows setting or ignoring useflag state changes in a way > > that will jumble up these layers. > > I think as long as it is a heirarchy it will be straightforward enough. > > If we introduce a ^ operator that unsets a flag, the only question is > how far that propagates down the layers, and into what kinds of > layers: > > Does a profile ^flag undo an IUSE +flag? > Does a make.conf ^flag undo a profile +flag? An IUSE +flag? A > profile flag mask? > Does a package.use ^flag undo a make.conf +flag? A profile +flag, an > IUSE +flag? Etc... I guess the question here is: Is there an official order in which the use settings from the different profiles and config files have to be applied? I think my initial assumption of this order was wrong, USE flags only have two states and indeed it seems that the ^ USE operator is not necessary, because the - operator already serves the same purpose. Thus the other proposal of adding a new server profile and enabling USE=udev for that and the desktop profiles would be sufficient to provide good defaults, but still allow people to not use that profile, if they don't want to. I.e. they could just use the 17.0 release profile and create their own minimal-server profile based on that. --Dennis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Adding USE=udev to linux profiles
On Tue, Jul 24, 2018 at 5:11 PM Dennis Schridde wrote: > > On Tuesday, 24 July 2018 20:57:09 CEST Rich Freeman wrote: > > On Tue, Jul 24, 2018 at 2:32 PM Ian Stakenvicius wrote: > > > I don't think the process needs to be simplified much more than this; > > > each layer above has its purpose. However I do very much want to > > > caution on making it more complicated, especially with the addition of > > > syntax that allows setting or ignoring useflag state changes in a way > > > that will jumble up these layers. > > > > I think as long as it is a heirarchy it will be straightforward enough. > > > > If we introduce a ^ operator that unsets a flag, the only question is > > how far that propagates down the layers, and into what kinds of > > layers: > > > > Does a profile ^flag undo an IUSE +flag? > > Does a make.conf ^flag undo a profile +flag? An IUSE +flag? A > > profile flag mask? > > Does a package.use ^flag undo a make.conf +flag? A profile +flag, an > > IUSE +flag? Etc... > > I guess the question here is: Is there an official order in which the use > settings from the different profiles and config files have to be applied? > > I think my initial assumption of this order was wrong, USE flags only have two > states and indeed it seems that the ^ USE operator is not necessary, because > the - operator already serves the same purpose. > Kinda sorta. In the flag is either set or it isn't. However, I think the intent here was to strip out the effects of profiles, but keep the effects of IUSE. The question then becomes what other contexts can it be used in, and in each case what does it undo? -- Rich
[gentoo-dev] [arm17] Background to ARM 17.0 profile migration
Hello all, For those who aren't already aware, there is a triplet (CHOST) change planned for the as-yet unreleased 17.0 profiles for ARM, affecting armv6j and armv7a hardfloat systems. Basically, the triplet will change from armv7a-hardfloat-linux-gnueabi to armv7a-unknown-linux-gnueabihf or similar. I won't bore you with the full history behind this but it is to fall in line with what the rest of the community are now using. Red Hat is one notable exception but they don't differentiate between hardfloat and softfp in their triplet at all. slyfox has rightly asked why we should put users through the trouble of migrating when GCC doesn't care either way when you build it; you have to explicitly request hardfloat using --with-float=hard as we do in toolchain.eclass. The main reason is LLVM. mgorny valiantly tried to fix LLVM to support our triplets but while upstream were somewhat supportive of this effort, he ultimately gave up because it proved too difficult. I have also seen issues arising from our unusual triplets when cross-compiling. There seems little point in fighting the trend. Of course, few users cross-compile and few ARM users have LLVM installed. I myself do not have it on my system. I therefore suggest a compromise. In the news item announcing this, rather than stating that users *must* migrate, not that we could force them to anyway, we will state that users should migrate but they can choose not to if they don't need LLVM and we will continue to support this to some extent. My initial migration guide was rather scary as changing CHOST is never easy and I was concerned that such a guide was never going to be sufficiently palatable for a news item. I didn't expect to be able to script it up but I gave it a shot and I'm actually quite happy with the result. I've run it on the newest (but quite old) glibc stage3, the newest musl stage3, and the newest glibc hardened stage3. All went well. It aborts on failure but allows you to rerun it if necessary and it will skip the time-consuming builds that have already completed. Please give it a try if you can and leave some feedback. Obviously we will need new stage tarballs so that new systems can start with the new triplet. The official arm stage tarballs are ancient and I have already prepared new stages for armv7a/glibc and armv6j/musl. veremitz has been busy building others. The RelEng team has agreed to put these up once the profiles go live. Hopefully regular stage auto-builds will return in the near future. I will now follow up this mail with others tagged [arm17] containing: 1. The news item (including a link to the migration script) 2. A toolchain-funcs.eclass patch 3. A crossdev patch Catalyst will need updating too but I will leave it to the RelEng team to decide whether they want to update the existing specs or create new ones. Cheers, -- James Le Cuirot (chewi) Gentoo Linux Developer pgpuweuydAtyN.pgp Description: OpenPGP digital signature
[gentoo-dev] [arm17] [News] ARM 17.0 profile migration with CHOST change
Please read my background [arm17] email before reviewing this. This is my first news item so please be kind! I have deliberately chosen News-Item-Format 1.0 to include older systems and because I do not need any 2.0 features. Title: ARM 17.0 profile migration with CHOST change Author: James Le Cuirot Content-Type: text/plain Posted: 2018-07-24 Revision: 1 News-Item-Format: 1.0 Display-If-Keyword: arm The new 17.0 profiles for ARM are now officially available. This not only features the PIE migration previously announced for other architectures but also a triplet (CHOST) change for hardfloat systems. In short, the triplet will change from armv7a-hardfloat-linux-gnueabi to armv7a-unknown-linux-gnueabihf or similar. This is to fall in line with what the rest of the Linux community are now using. If the vendor (2nd) part of your triplet is different or missing then you may keep it as it is. The hf ending is what matters. If you are using an unversioned alternative profile such as hardened/linux/arm/armv7a then the default CHOST will have changed for you already. Hopefully, you were shielded from the change by having CHOST explicitly set in your make.conf. In this case, a migration is still required. Changing CHOST is never simple and does carry some risk. We encourage users to migrate but if you do not have sys-devel/llvm on your system and you do not cross-compile for ARM then you may choose to keep your existing CHOST. We will continue to support this to some degree although we cannot promise that other packages will not be affected in future. If you choose not to migrate or your system is not hardfloat then you must ensure that CHOST is explicitly set in make.conf and then proceed with a regular 17.0 migration to deal with PIE as detailed here: https://www.gentoo.org/support/news-items/2017-11-30-new-17-profiles.html Otherwise, if you do wish to migrate then we have written a script to do the necessary steps for you: https://gist.github.com/chewi/1601684ad8f3cf8de0b786c00fa09b3c It takes a minimal backup of the existing toolchain with quickpkg before changing anything but we strongly recommend that you take a full backup first. The script echos each command as it goes along so that you can keep an eye on what it's doing. You are, of course, welcome to tinker with the script or perform the migration manually if you think you know your own system better. It is heavily commented for this reason. If the script fails then you can take remedial action before running it again and it should skip any time-consuming builds that it has already done. If the migration doesn't go to plan then please do seek help in #gentoo-arm. A migration of this kind can justify rebuilding @world but with ARM typically being very slow, the script does just the minimum necessary. You are free to rebuild @world yourself after running it. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpMdWOiCWQCY.pgp Description: OpenPGP digital signature
[gentoo-dev] [arm17] [PATCH] toolchain-funcs.eclass: Update tc-is-softfloat for new ARM triplets
The triplet will change from armv7a-hardfloat-linux-gnueabi to
armv7a-unknown-linux-gnueabihf or similar. The function already
treated the latter as hardfloat but ambiguous triplets such as
arm-unknown-linux-gnueabi will change from hardfloat to softfloat in
line with most everyone else. However, we will now check existing
toolchains to avoid breaking existing systems, if possible.
---
eclass/toolchain-funcs.eclass | 39 ---
1 file changed, 32 insertions(+), 7 deletions(-)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index cea8949b45d7..f484fffc2664 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -204,13 +204,38 @@ tc-is-softfloat() {
bfin*|h8300*)
echo "only" ;;
*)
- if [[ ${CTARGET//_/-} == *-softfloat-* ]] ; then
- echo "yes"
- elif [[ ${CTARGET//_/-} == *-softfp-* ]] ; then
- echo "softfp"
- else
- echo "no"
- fi
+ case ${CTARGET//_/-} in
+ *-softfloat-*)
+ echo "yes" ;;
+ *-softfp-*)
+ echo "softfp" ;;
+ arm*)
+ # arm-unknown-linux-gnueabi is
ambiguous. We used to
+ # treat it as hardfloat but we now
treat it as
+ # softfloat like most everyone else.
However, we
+ # check existing toolchains to avoid
breaking
+ # existing systems, if possible.
+ if type -P ${CTARGET}-cpp >/dev/null;
then
+ if ${CTARGET}-cpp -E - <<<
__ARM_PCS_VFP 2>/dev/null | grep -q __ARM_PCS_VFP; then
+ # Confusingly
__SOFTFP__ is defined only
+ # when -mfloat-abi is
soft, not softfp.
+ if ${CTARGET}-cpp -E -
<<< __SOFTFP__ 2>/dev/null | grep -q __SOFTFP__; then
+ echo "softfp"
+ else
+ echo "yes"
+ fi
+ else
+ echo "no"
+ fi
+ elif [[ ${CTARGET} == *-hardfloat-* ||
${CTARGET} == *hf ]]; then
+ echo "no"
+ else
+ echo "yes"
+ fi
+ ;;
+ *)
+ echo "no" ;;
+ esac
;;
esac
}
--
2.17.0
[gentoo-dev] [arm17] [PATCH] crossdev: Make armv[67] default to hardfloat following eclass change
armv7a-unknown-linux-gnueabi would have previously been treated as
hardfloat but is now softfloat.
I have removed the armv7a-hardfloat-linux-gnueabi-7.3.0 example from
the README to avoid confusion even though it does still work.
Signed-off-by: James Le Cuirot
---
README | 3 +--
crossdev | 2 ++
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/README b/README
index 99287a1..7aecdc4 100644
--- a/README
+++ b/README
@@ -50,8 +50,7 @@ executables or kernels if applies):
alpha-unknown-linux-gnu-7.3.0
arm-none-eabi-7.3.0
armv5tel-softfloat-linux-gnueabi-7.3.0
- armv7a-hardfloat-linux-gnueabi-7.3.0
- armv7a-unknown-linux-gnueabi-7.3.0
+ armv7a-unknown-linux-gnueabihf-7.3.0
avr-7.3.0
hppa-unknown-linux-gnu-7.3.0
hppa2.0-unknown-linux-gnu-7.3.0
diff --git a/crossdev b/crossdev
index a4b32a2..4ee7076 100755
--- a/crossdev
+++ b/crossdev
@@ -189,6 +189,8 @@ parse_target() {
CTARGET="${CTARGET}-ibm-linux-gnu";;
arm64*)
CTARGET="aarch${CTARGET#arm}-unknown-linux-gnu";;
+ armv[67]*)
+ CTARGET="${CTARGET}-unknown-linux-gnueabihf";;
arm*)
CTARGET="${CTARGET}-unknown-linux-gnueabi";;
aarch64*|alpha*|cris*|hppa*|ia64*|m68*|mips*|powerpc*|sparc*|sh*|tile*)
--
2.17.0
Re: [gentoo-dev] [arm17] [PATCH] toolchain-funcs.eclass: Update tc-is-softfloat for new ARM triplets
On Wed, 25 Jul 2018 00:09:28 +0100
James Le Cuirot wrote:
> The triplet will change from armv7a-hardfloat-linux-gnueabi to
> armv7a-unknown-linux-gnueabihf or similar. The function already
> treated the latter as hardfloat but ambiguous triplets such as
> arm-unknown-linux-gnueabi will change from hardfloat to softfloat in
> line with most everyone else. However, we will now check existing
> toolchains to avoid breaking existing systems, if possible.
[+arm@ CC]
1. This changelog is not clear if arm-unknown-linux-gnueabi will change
meaning in this commit.
2. Did Gentoo ever use arm-unknown-linux-gnueabi tuple? I don't see
it in recent profile history.
3. What are existing toolchain tuples? All the ones people use?
> ---
> eclass/toolchain-funcs.eclass | 39 ---
> 1 file changed, 32 insertions(+), 7 deletions(-)
>
> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> index cea8949b45d7..f484fffc2664 100644
> --- a/eclass/toolchain-funcs.eclass
> +++ b/eclass/toolchain-funcs.eclass
> @@ -204,13 +204,38 @@ tc-is-softfloat() {
> bfin*|h8300*)
> echo "only" ;;
> *)
> - if [[ ${CTARGET//_/-} == *-softfloat-* ]] ; then
> - echo "yes"
> - elif [[ ${CTARGET//_/-} == *-softfp-* ]] ; then
> - echo "softfp"
> - else
> - echo "no"
> - fi
> + case ${CTARGET//_/-} in
> + *-softfloat-*)
> + echo "yes" ;;
> + *-softfp-*)
> + echo "softfp" ;;
> + arm*)
> + # arm-unknown-linux-gnueabi is
> ambiguous. We used to
> + # treat it as hardfloat but we now
> treat it as
> + # softfloat like most everyone else.
> However, we
> + # check existing toolchains to avoid
> breaking
> + # existing systems, if possible.
> + if type -P ${CTARGET}-cpp >/dev/null;
> then
I believe correct way to get cpp for target is
"$(tc-getCPP ${CTARGET}) -E"
> + if ${CTARGET}-cpp -E - <<<
> __ARM_PCS_VFP 2>/dev/null | grep -q __ARM_PCS_VFP; then
4. This magic is hard to follow and reason about.
I suggest moving out autodetection of current setup into another helper.
Bonus point for detection of mismatch of actual vs. intended state.
Then we could start warning users about the fact of inconsistency and point
to migration procedure. And we could have cleaner ${CTARGET} matches against
what Gentoo expects.
5. you don't use ${CFLAGS} here. I feel we should use them as people do
occasionally
override defaults.
> + # Confusingly
> __SOFTFP__ is defined only
> + # when -mfloat-abi is
> soft, not softfp.
> + if ${CTARGET}-cpp -E -
> <<< __SOFTFP__ 2>/dev/null | grep -q __SOFTFP__; then
> + echo "softfp"
> + else
> + echo "yes"
> + fi
> + else
> + echo "no"
> + fi
> + elif [[ ${CTARGET} == *-hardfloat-* ||
> ${CTARGET} == *hf ]]; then
I suggest using *-gnueabihf. I don't think anything more generic is recognized
by toolchains
as a hardfloat target.
Also please link to description of what you think canonical hardfloat tuples
are supposed to
be. Upstreams do not agree on the definition.
> + echo "no"
> + else
> + echo "yes"
> + fi
> + ;;
> + *)
> + echo "no" ;;
> + esac
> ;;
> esac
> }
> --
> 2.17.0
>
>
--
Sergei
Re: [gentoo-dev] [arm17] [PATCH] crossdev: Make armv[67] default to hardfloat following eclass change
On Wed, 25 Jul 2018 00:11:18 +0100
James Le Cuirot wrote:
> armv7a-unknown-linux-gnueabi would have previously been treated as
> hardfloat but is now softfloat.
>
> I have removed the armv7a-hardfloat-linux-gnueabi-7.3.0 example from
> the README to avoid confusion even though it does still work.
Applied. Thanks!
> Signed-off-by: James Le Cuirot
> ---
> README | 3 +--
> crossdev | 2 ++
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/README b/README
> index 99287a1..7aecdc4 100644
> --- a/README
> +++ b/README
> @@ -50,8 +50,7 @@ executables or kernels if applies):
> alpha-unknown-linux-gnu-7.3.0
> arm-none-eabi-7.3.0
> armv5tel-softfloat-linux-gnueabi-7.3.0
> - armv7a-hardfloat-linux-gnueabi-7.3.0
> - armv7a-unknown-linux-gnueabi-7.3.0
> + armv7a-unknown-linux-gnueabihf-7.3.0
> avr-7.3.0
> hppa-unknown-linux-gnu-7.3.0
> hppa2.0-unknown-linux-gnu-7.3.0
> diff --git a/crossdev b/crossdev
> index a4b32a2..4ee7076 100755
> --- a/crossdev
> +++ b/crossdev
> @@ -189,6 +189,8 @@ parse_target() {
> CTARGET="${CTARGET}-ibm-linux-gnu";;
> arm64*)
>
> CTARGET="aarch${CTARGET#arm}-unknown-linux-gnu";;
> + armv[67]*)
> + CTARGET="${CTARGET}-unknown-linux-gnueabihf";;
> arm*)
> CTARGET="${CTARGET}-unknown-linux-gnueabi";;
>
> aarch64*|alpha*|cris*|hppa*|ia64*|m68*|mips*|powerpc*|sparc*|sh*|tile*)
> --
> 2.17.0
>
>
--
Sergei
Re: [gentoo-dev] [arm17] [PATCH] toolchain-funcs.eclass: Update tc-is-softfloat for new ARM triplets
W dniu śro, 25.07.2018 o godzinie 00∶09 +0100, użytkownik James Le
Cuirot napisał:
> The triplet will change from armv7a-hardfloat-linux-gnueabi to
> armv7a-unknown-linux-gnueabihf or similar. The function already
> treated the latter as hardfloat but ambiguous triplets such as
> arm-unknown-linux-gnueabi will change from hardfloat to softfloat in
> line with most everyone else. However, we will now check existing
> toolchains to avoid breaking existing systems, if possible.
> ---
> eclass/toolchain-funcs.eclass | 39 ---
> 1 file changed, 32 insertions(+), 7 deletions(-)
>
> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> index cea8949b45d7..f484fffc2664 100644
> --- a/eclass/toolchain-funcs.eclass
> +++ b/eclass/toolchain-funcs.eclass
> @@ -204,13 +204,38 @@ tc-is-softfloat() {
> bfin*|h8300*)
> echo "only" ;;
> *)
> - if [[ ${CTARGET//_/-} == *-softfloat-* ]] ; then
> - echo "yes"
> - elif [[ ${CTARGET//_/-} == *-softfp-* ]] ; then
> - echo "softfp"
> - else
> - echo "no"
> - fi
> + case ${CTARGET//_/-} in
> + *-softfloat-*)
> + echo "yes" ;;
> + *-softfp-*)
> + echo "softfp" ;;
> + arm*)
> + # arm-unknown-linux-gnueabi is
> ambiguous. We used to
> + # treat it as hardfloat but we now
> treat it as
> + # softfloat like most everyone else.
> However, we
> + # check existing toolchains to avoid
> breaking
> + # existing systems, if possible.
> + if type -P ${CTARGET}-cpp >/dev/null;
> then
> + if ${CTARGET}-cpp -E - <<<
> __ARM_PCS_VFP 2>/dev/null | grep -q __ARM_PCS_VFP; then
> + # Confusingly
> __SOFTFP__ is defined only
> + # when -mfloat-abi is
> soft, not softfp.
> + if ${CTARGET}-cpp -E -
> <<< __SOFTFP__ 2>/dev/null | grep -q __SOFTFP__; then
> + echo "softfp"
Either the comment is confusing or you did it the other way around.
> + else
> + echo "yes"
> + fi
> + else
> + echo "no"
> + fi
> + elif [[ ${CTARGET} == *-hardfloat-* ||
> ${CTARGET} == *hf ]]; then
> + echo "no"
> + else
> + echo "yes"
> + fi
> + ;;
> + *)
> + echo "no" ;;
> + esac
> ;;
> esac
> }
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v5 03/16] glep-0063: 'Gentoo subkey' → 'Signing subkey'
On 7/8/2018 2:38 PM, Michał Górny wrote: > Replace the 'Gentoo subkey' term that might wrongly suggest that > the developers are expected to create an additional, dedicated subkey > for Gentoo. > > Suggested-by: Kristian Fiskerstrand > --- > glep-0063.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/glep-0063.rst b/glep-0063.rst > index 0773e3b..f02537d 100644 > --- a/glep-0063.rst > +++ b/glep-0063.rst > @@ -116,7 +116,7 @@ Recommendations > > a. Root key: 3 years maximum, expiry date renewed annually. > > - b. Gentoo subkey: 1 year maximum, expiry date renewed every 6 months. > + b. Signing subkey: 1 year maximum, expiry date renewed every 6 months. > > 5. Create a revocation certificate & store it hardcopy offsite securely > (it's about ~300 bytes). > I lost track of this due to other priorities, but picking through some of the follow-up messages about the lead time on renewals and all, I don't have a problem with that. But why is the maximum of one year on subkey/signing key expiration still here? I'm not seeing a lot of additional follow-up on that, but that is still too short. Two years is perfectly fine in this case. I'd prefer three years myself, but am willing to compromise for two. I am not doing one year unless someone drops some really convincing logic on me. And no, scrawling "logic" on the side of an anvil doesn't count. Does anyone know what the other projects require for their keys? Without a proper explanation of //why// one year needs to be the maximum, looking to what other projects use seems sensible for guidance. I can't seem to find any specific guidance from Debian, but FreeBSD appears to be fine with three years on their committer keys: """ A three year key lifespan is short enough to obsolete keys weakened by advancing computer power, but long enough to reduce key management problems. """ https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#pgpkeys -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] [PATCH v5 03/16] glep-0063: 'Gentoo subkey' → 'Signing subkey'
W dniu śro, 25.07.2018 o godzinie 01∶28 -0400, użytkownik Joshua Kinard napisał: > On 7/8/2018 2:38 PM, Michał Górny wrote: > > Replace the 'Gentoo subkey' term that might wrongly suggest that > > the developers are expected to create an additional, dedicated subkey > > for Gentoo. > > > > Suggested-by: Kristian Fiskerstrand > > --- > > glep-0063.rst | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/glep-0063.rst b/glep-0063.rst > > index 0773e3b..f02537d 100644 > > --- a/glep-0063.rst > > +++ b/glep-0063.rst > > @@ -116,7 +116,7 @@ Recommendations > > > > a. Root key: 3 years maximum, expiry date renewed annually. > > > > - b. Gentoo subkey: 1 year maximum, expiry date renewed every 6 months. > > + b. Signing subkey: 1 year maximum, expiry date renewed every 6 months. > > > > 5. Create a revocation certificate & store it hardcopy offsite securely > > (it's about ~300 bytes). > > > > I lost track of this due to other priorities, but picking through some of the > follow-up messages about the lead time on renewals and all, I don't have a > problem with that. But why is the maximum of one year on subkey/signing key > expiration still here? Because I've started with small changes, and the thing you're asking about is changed in a followup patch. Please read the final text instead of wrongly assuming something from irrelevant change. > > I'm not seeing a lot of additional follow-up on that, but that is still too > short. Two years is perfectly fine in this case. I'd prefer three years > myself, but am willing to compromise for two. I am not doing one year unless > someone drops some really convincing logic on me. And no, scrawling "logic" > on > the side of an anvil doesn't count. > > Does anyone know what the other projects require for their keys? Without a > proper explanation of //why// one year needs to be the maximum, looking to > what > other projects use seems sensible for guidance. > > I can't seem to find any specific guidance from Debian, but FreeBSD appears to > be fine with three years on their committer keys: > > """ > A three year key lifespan is short enough to obsolete keys weakened by > advancing computer power, but long enough to reduce key management problems. > """ > > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#pgpkeys > -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v5 03/16] glep-0063: 'Gentoo subkey' → 'Signing subkey'
On July 25, 2018 1:28:52 AM EDT, Joshua Kinard wrote: >On 7/8/2018 2:38 PM, Michał Górny wrote: >> Replace the 'Gentoo subkey' term that might wrongly suggest that >> the developers are expected to create an additional, dedicated subkey >> for Gentoo. >> >> Suggested-by: Kristian Fiskerstrand >> --- >> glep-0063.rst | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/glep-0063.rst b/glep-0063.rst >> index 0773e3b..f02537d 100644 >> --- a/glep-0063.rst >> +++ b/glep-0063.rst >> @@ -116,7 +116,7 @@ Recommendations >> >> a. Root key: 3 years maximum, expiry date renewed annually. >> >> - b. Gentoo subkey: 1 year maximum, expiry date renewed every 6 >months. >> + b. Signing subkey: 1 year maximum, expiry date renewed every 6 >months. >> >> 5. Create a revocation certificate & store it hardcopy offsite >securely >> (it's about ~300 bytes). >> > >I lost track of this due to other priorities, but picking through some >of the >follow-up messages about the lead time on renewals and all, I don't >have a >problem with that. But why is the maximum of one year on >subkey/signing key >expiration still here? > >I'm not seeing a lot of additional follow-up on that, but that is still >too >short. Two years is perfectly fine in this case. I'd prefer three >years >myself, but am willing to compromise for two. I am not doing one year >unless >someone drops some really convincing logic on me. And no, scrawling >"logic" on >the side of an anvil doesn't count. > >Does anyone know what the other projects require for their keys? >Without a >proper explanation of //why// one year needs to be the maximum, looking >to what >other projects use seems sensible for guidance. > >I can't seem to find any specific guidance from Debian, but FreeBSD >appears to >be fine with three years on their committer keys: > >""" >A three year key lifespan is short enough to obsolete keys weakened by >advancing computer power, but long enough to reduce key management >problems. >""" > >https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#pgpkeys Everyone will have a different opinion. NIST, Debian, Redhat, etc. Shouldn't you be providing the logic as to why it is a bad idea? Someone wants to set a reasonable standard for the sake of having *a* policy in place. They did the work, proposed it, and it isn't something awful or intrusive. The whole, "I am not doing one year..." and then the "anvil doesn't count" seems uncooperative and contradictory. Is there some obstacle stopping you from updating your key expiration once a year? It takes at most 20 minutes. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
