Re: [gentoo-dev] multilib amd64 news item for review
On 17 March 2015 at 23:33, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-03-15, o godz. 15:11:47 Michał Górny mgo...@gentoo.org napisał(a): Here's -r1: [...] I think this is really great! Just one small nitpick: Note that after performing this step, 32-bit applications on user's system may become temporarily broken. Make that the user's system. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] multilib amd64 news item for review
Dnia 2015-03-15, o godz. 15:43:56 Ulrich Mueller u...@gentoo.org napisał(a): On Sun, 15 Mar 2015, Michał Górny wrote: Hello, everyone. Here's the first draft of news item for gx86-multilib. I tried to cover all the important aspects. Please review and let me know what you think. Title: True multilib support on amd64 Author: Michał Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2015-01-28 Revision: 1 News-Item-Format: 1.0 Display-If-Keyword: amd64 Display-If-Keyword: ~amd64 Users of no-multilib profiles won't be affected, so maybe Display-If-Profile should be used (in addition, or instead of Display-If-Keyword)? Display-If-Profile does exact profile matching, so we'd have to keep an up-to-date list of all profiles derived from multilib amd64... Starting with 2015-03-29, we are enabling the true multilib support on amd64 and masking the old emul-linux-x86 package sets for removal. This change provides I'm not a native speaker, but shouldn't a future tense be used here? our users with the opportunity to build 32-bit libraries from source with all the flexibility given by ebuilds, rather than relying on pre-packaged binary versions of them. The switch to the new system is likely to require a specific action from the users of our multilib profiles. Since the new system collides with the old one, the Package Manager must be able to clearly satisfy all the dependencies using the new system in order to proceed. This may require unmerging packages installed from third-party repositories that have not been updated to support the new system. In order to enable building necessary 32-bit libraries, users will be required to enable the abi_x86_32 USE flag on respective packages. How? Maybe add a hint that this should be done in package.accept_keywords? It can't :P. But added a hint for package.use. In most of the cases, Portage will be able to deliver correct suggestions for that when using the --autounmask feature. However, some users may prefer setting ABI_X86 globally to enable 32-bit libraries in all packages supporting building them. Again, add a hint how to do this? Likewise. In case of issues, blockers especially, the users users s/the users users/users/ Fixed. are recommended to manually uninstall any emul-linux-x86 packages that may have been installed on their systems. This will aid the Package Manager in choosing the correct dependency resolution path. If using Portage, this can be done using the following command: $ emerge -C 'app-emulation/emul-linux-x86*' Note that after performing this step, 32-bit applications on your system So far you have used third person throughout, so avoid the your here. Fixed. may become temporarily broken. Therefore, this step should be followed by a @world upgrade immediately. Maybe a pointer to the wiki could be added? How about this: https://wiki.gentoo.org/wiki/Multilib_System_without_emul-linux_Packages (with that page being updated if necessary). If someone has time to uncruft that wiki page, I'd be happy to link it. -- Best regards, Michał Górny pgpBQRfYbHQRD.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] multilib amd64 news item for review
On Tue, 17 Mar 2015, Michał Górny wrote: Users of no-multilib profiles won't be affected, so maybe Display-If-Profile should be used (in addition, or instead of Display-If-Keyword)? Display-If-Profile does exact profile matching, so we'd have to keep an up-to-date list of all profiles derived from multilib amd64... Indeed, that might be too much effort. Show it to all amd64 users then. How? Maybe add a hint that this should be done in package.accept_keywords? It can't :P. But added a hint for package.use. That's what I meant, of course. :) Ulrich pgpdA4g0aWTp0.pgp Description: PGP signature
Re: [gentoo-dev] multilib amd64 news item for review
Dnia 2015-03-17, o godz. 16:55:32 René Neumann li...@necoro.eu napisał(a): Am 17.03.2015 um 16:33 schrieb Michał Górny: However, some users may prefer setting ABI_X86 globally to enable 32-bit libraries in all packages that support building them. This can be done using the following package.use entry: */* abi_x86_32 I'm confused: Has this a different semantics from adding USE+='abi_x86_32' to make.conf? If no, why mention this strange way (which is new to me) for setting default global useflags. Because this is how users learn new fun stuff. Like sane configuration. And to bring this even further: Wouldn't the nicest approach to add ABI_X86=32 This will disable some 64-bit web browser plugins. or ABI_X86=32 64 to make.conf? (With the latter being more descriptive, as the first one might suggest that _only_ 32bit should be built). This will enable some possibly-unwanted 64-bit software, e.g. 64-bit Windows support in wine. -- Best regards, Michał Górny pgpc9UMdPGY6S.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] multilib amd64 news item for review
Am 17.03.2015 um 16:33 schrieb Michał Górny: However, some users may prefer setting ABI_X86 globally to enable 32-bit libraries in all packages that support building them. This can be done using the following package.use entry: */* abi_x86_32 I'm confused: Has this a different semantics from adding USE+='abi_x86_32' to make.conf? If no, why mention this strange way (which is new to me) for setting default global useflags. And to bring this even further: Wouldn't the nicest approach to add ABI_X86=32 or ABI_X86=32 64 to make.conf? (With the latter being more descriptive, as the first one might suggest that _only_ 32bit should be built). - René
Re: [gentoo-dev] multilib amd64 news item for review
Dnia 2015-03-15, o godz. 15:11:47 Michał Górny mgo...@gentoo.org napisał(a): Hello, everyone. Here's the first draft of news item for gx86-multilib. I tried to cover all the important aspects. Please review and let me know what you think. Here's -r1: Title: True multilib support on amd64 Author: Michał Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2015-01-28 Revision: 1 News-Item-Format: 1.0 Display-If-Keyword: amd64 Display-If-Keyword: ~amd64 Starting on 2015-03-29, we are enabling true multilib support on amd64 and masking the old emul-linux-x86 package sets for removal. This change provides our users with the opportunity to build 32-bit libraries from source with all the flexibility given by ebuilds and the security of using mainline ebuilds, rather than relying on pre-packaged binary versions of them. The switch to the new system is likely to require a specific action from the users of our multilib profiles. Since the new system collides with the old one, the Package Manager must be able to clearly satisfy all the dependencies using the new system in order to proceed. This may require unmerging packages installed from third-party repositories that have not been updated to support the new system. In order to enable building necessary 32-bit libraries, users will be required to enable the abi_x86_32 USE flag on respective packages. This can be done using /etc/portage/package.use entries alike the following: sys-libs/zlib abi_x86_32 In most of the cases, Portage will be able to deliver correct suggestions for that when using the --autounmask feature. However, some users may prefer setting ABI_X86 globally to enable 32-bit libraries in all packages that support building them. This can be done using the following package.use entry: */* abi_x86_32 In case of issues, blockers especially, users are recommended to manually uninstall any emul-linux-x86 packages that may have been installed on their systems. This will aid the Package Manager in choosing the correct dependency resolution path. If using Portage, this can be done using the following command: $ emerge -C 'app-emulation/emul-linux-x86*' Note that after performing this step, 32-bit applications on user's system may become temporarily broken. Therefore, this step should be followed by a @world upgrade immediately. -- Best regards, Michał Górny pgpImXZ8Cn_IP.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] multilib amd64 news item for review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Dienstag, 17. März 2015, 17:29:50 schrieb Michał Górny: ABI_X86=32 64 to make.conf? (With the latter being more descriptive, as the first one might suggest that _only_ 32bit should be built). This will enable some possibly-unwanted 64-bit software, e.g. 64-bit Windows support in wine. errhm... I guess this needs an explanation. Why is this not equivalent? Sounds like a bug to me. - -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJVCFvgXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwNzlCRDk4QzA4RENBRkYzQUEwRjQzMDlF QkU2QTMzNkJFMTkwMzlDAAoJEOvmoza+GQOcbVEP/RDZjUvRs+iDoxvE9DA0MruI 8USQ5YpPWx4Yp35t2+P1nf9x1drFUeJp6XDSl0Qqeg92AVQG777RPH1PdSdgMOWb n/+B4LKxfpLu7YfOi+/fp2ENyH/SmwZinFY1M4WtZ5mt8+AGZe008J/Y/YboDGSy 5DKSqf/+JnW6WTNt48wgShetV00Wv9q1YHFEnnODTiVwi1nQ9yf+W8bNMBsMxKxO cn6k6xsLuPA2xzzmuqDnRSpG7NmZpOM9nU75jG0TVJCg8gjQEY4/lE2Cncwk0Y9z rACDWGryTnFZG1A9oogpkUPvdZ1dUjh52FaCtJryrikypKfiSMMseGXbmgbnLt1I WbQoVK0G7DpwETwOU/pdse+6e2/q9hskOYWbnrZizXULlXmlD7zjvZ65gL9ipzCe mn1mam+fS8kiBXq7Ruz1RFEqH6M35KXN5EOfXtrK+VSABY1YD7X/p056kOJ1ikjB XmE4UzdPgk2uczvQ3KiTNSU23U2sXd6v/KCM/HcODahvPK7PuOJAakHARxWVewIA Ey7tBiOKtHuC0GEF29RJNSQb0EEkWq1gW+p82v/AnsQnfwVu9uJ7NRK5X0bg+R6j P/u5uTwpQ5acJtg2NDBzXBkPBcmhZzJsL3172s0FsAMvOWC9UOpVApvtEWVqkXm3 aaUPxImOq5XIoPK4px+Z =6nW0 -END PGP SIGNATURE-
Re: [gentoo-dev] multilib amd64 news item for review
On 15/03/15 10:11 AM, Michał Górny wrote: In case of issues, blockers especially, the users users are recommended looks OK otherwise. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] multilib amd64 news item for review
On 15 March 2015 at 22:43, Ulrich Mueller u...@gentoo.org wrote: On Sun, 15 Mar 2015, Michał Górny wrote: Hello, everyone. Here's the first draft of news item for gx86-multilib. I tried to cover all the important aspects. Please review and let me know what you think. Title: True multilib support on amd64 Author: Michał Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2015-01-28 Revision: 1 News-Item-Format: 1.0 Display-If-Keyword: amd64 Display-If-Keyword: ~amd64 Users of no-multilib profiles won't be affected, so maybe Display-If-Profile should be used (in addition, or instead of Display-If-Keyword)? Starting with 2015-03-29, we are enabling the true multilib support on amd64 and masking the old emul-linux-x86 package sets for removal. This change provides I'm not a native speaker, but shouldn't a future tense be used here? English teacher here: no. The present continuous (are enabling) is a normal way to express the future in English. The only changes necessary here, as already noted, is changing 'with' to 'on' before the date, and dropping 'the' before true. It may be nice to specify *stable* amd64. I would also say that 'true' is incorrect, as the emul packages were also truly multilib, just implemented in a different way. Maybe 'eclass-based' is more specific and less opinionated? our users with the opportunity to build 32-bit libraries from source with all the flexibility given by ebuilds, rather than relying on pre-packaged binary versions of them. [...] installed on their systems. This will aid the Package Manager in choosing the correct dependency resolution path. If using Portage, this can be done using the following command: $ emerge -C 'app-emulation/emul-linux-x86*' Note that after performing this step, 32-bit applications on your system So far you have used third person throughout, so avoid the your here. I agree. Maybe 'that'? -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] multilib amd64 news item for review
Hello, everyone. Here's the first draft of news item for gx86-multilib. I tried to cover all the important aspects. Please review and let me know what you think. Title: True multilib support on amd64 Author: Michał Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2015-01-28 Revision: 1 News-Item-Format: 1.0 Display-If-Keyword: amd64 Display-If-Keyword: ~amd64 Starting with 2015-03-29, we are enabling the true multilib support on amd64 and masking the old emul-linux-x86 package sets for removal. This change provides our users with the opportunity to build 32-bit libraries from source with all the flexibility given by ebuilds, rather than relying on pre-packaged binary versions of them. The switch to the new system is likely to require a specific action from the users of our multilib profiles. Since the new system collides with the old one, the Package Manager must be able to clearly satisfy all the dependencies using the new system in order to proceed. This may require unmerging packages installed from third-party repositories that have not been updated to support the new system. In order to enable building necessary 32-bit libraries, users will be required to enable the abi_x86_32 USE flag on respective packages. In most of the cases, Portage will be able to deliver correct suggestions for that when using the --autounmask feature. However, some users may prefer setting ABI_X86 globally to enable 32-bit libraries in all packages supporting building them. In case of issues, blockers especially, the users users are recommended to manually uninstall any emul-linux-x86 packages that may have been installed on their systems. This will aid the Package Manager in choosing the correct dependency resolution path. If using Portage, this can be done using the following command: $ emerge -C 'app-emulation/emul-linux-x86*' Note that after performing this step, 32-bit applications on your system may become temporarily broken. Therefore, this step should be followed by a @world upgrade immediately. -- Best regards, Michał Górny pgpVtjSYRiFSW.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] multilib amd64 news item for review
On Sun, 15 Mar 2015, Michał Górny wrote: Hello, everyone. Here's the first draft of news item for gx86-multilib. I tried to cover all the important aspects. Please review and let me know what you think. Title: True multilib support on amd64 Author: Michał Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2015-01-28 Revision: 1 News-Item-Format: 1.0 Display-If-Keyword: amd64 Display-If-Keyword: ~amd64 Users of no-multilib profiles won't be affected, so maybe Display-If-Profile should be used (in addition, or instead of Display-If-Keyword)? Starting with 2015-03-29, we are enabling the true multilib support on amd64 and masking the old emul-linux-x86 package sets for removal. This change provides I'm not a native speaker, but shouldn't a future tense be used here? our users with the opportunity to build 32-bit libraries from source with all the flexibility given by ebuilds, rather than relying on pre-packaged binary versions of them. The switch to the new system is likely to require a specific action from the users of our multilib profiles. Since the new system collides with the old one, the Package Manager must be able to clearly satisfy all the dependencies using the new system in order to proceed. This may require unmerging packages installed from third-party repositories that have not been updated to support the new system. In order to enable building necessary 32-bit libraries, users will be required to enable the abi_x86_32 USE flag on respective packages. How? Maybe add a hint that this should be done in package.accept_keywords? In most of the cases, Portage will be able to deliver correct suggestions for that when using the --autounmask feature. However, some users may prefer setting ABI_X86 globally to enable 32-bit libraries in all packages supporting building them. Again, add a hint how to do this? In case of issues, blockers especially, the users users s/the users users/users/ are recommended to manually uninstall any emul-linux-x86 packages that may have been installed on their systems. This will aid the Package Manager in choosing the correct dependency resolution path. If using Portage, this can be done using the following command: $ emerge -C 'app-emulation/emul-linux-x86*' Note that after performing this step, 32-bit applications on your system So far you have used third person throughout, so avoid the your here. may become temporarily broken. Therefore, this step should be followed by a @world upgrade immediately. Maybe a pointer to the wiki could be added? How about this: https://wiki.gentoo.org/wiki/Multilib_System_without_emul-linux_Packages (with that page being updated if necessary). Ulrich pgpAaKvDGxhD5.pgp Description: PGP signature
Re: [gentoo-dev] multilib amd64 news item for review
On Sun, Mar 15, 2015 at 10:43 AM, Ulrich Mueller u...@gentoo.org wrote: On Sun, 15 Mar 2015, Michał Górny wrote: Starting with 2015-03-29, we are enabling the true multilib support on amd64 and masking the old emul-linux-x86 package sets for removal. This change provides I'm not a native speaker, but shouldn't a future tense be used here? our users with the opportunity to build 32-bit libraries from source with all the flexibility given by ebuilds, rather than relying on pre-packaged binary versions of them. I suggest: Starting on 2015-03-29, we are enabling true multilib support on amd64 and masking the old emul-linux-x86 package sets for removal. This change provides our users with the opportunity to build 32-bit libraries from source with all the flexibility given by ebuilds, rather than relying on pre-packaged binary versions of them. I just changed with to on and dropped a the. I think this sounds fairly natural - a grammar nazi might disagree, but I'd rate the paragraph above average for a native born American college graduate. (Granted, that isn't saying a whole lot). Without those tweaks I'd say it is still better than a lot of stuff that passes for prose these days. :) Trust me, you don't want to see my attempts at German, so I'll be the last to critique anybody's use of English (American or otherwise)... -- Rich
