Re: [gentoo-dev] why is a line in /usr/portage/profiles/base/package.use.mask ignored?
On Wed, Feb 25, 2015 at 5:23 AM, gro...@gentoo.org wrote: Hello *, dev-lisp/ecls-15.2.21 does not compiled with USE=cpu_flags_x86_sse. So, I've added the line =dev-lisp/ecls-15.2.21 cpu_flags_x86_sse to .../profiles/base/package.use.mask. But I still see dns ~ # emerge -pv dev-lisp/ecls [ebuild R] dev-lisp/ecls-15.2.21:0/15.2.21::gentoo [15.2.21:0/15.2.21::grozin] USE=X emacs libatomic%* threads unicode -debug -gengc -precisegc CPU_FLAGS_X86=sse* 0 KiB Why isn't sse masked? Andrey This is because these cpu_flags_x86_* flags are masked globally in profiles/base/use.mask then unmasked where they're valid, like in profiles/arch/amd64/use.mask. So that later (global) unmask overrides your package-specific mask in the base profile. If you add your package.use.mask entry in profiles/arch/amd64/package.use.mask then I believe it should work. -Ben
Re: [gentoo-dev] why is a line in /usr/portage/profiles/base/package.use.mask ignored?
On Wed, 25 Feb 2015 17:23:03 +0600 (NOVT) gro...@gentoo.org wrote: Hello *, dev-lisp/ecls-15.2.21 does not compiled with USE=cpu_flags_x86_sse. So, I've added the line =dev-lisp/ecls-15.2.21 cpu_flags_x86_sse to .../profiles/base/package.use.mask. But I still see dns ~ # emerge -pv dev-lisp/ecls [ebuild R] dev-lisp/ecls-15.2.21:0/15.2.21::gentoo [15.2.21:0/15.2.21::grozin] USE=X emacs libatomic%* threads unicode -debug -gengc -precisegc CPU_FLAGS_X86=sse* 0 KiB Why isn't sse masked? Because USE over-rides it. Profiles are only a starting point and a bunch of defaults, everything in them is subject to being over-ridden by /etc/portage/* Why are you messing around with the profile anyway, when all the available documentation in many many places tells you to set your chosen USE for specific packages in package.use? Alan
[gentoo-dev] [PATCH 1/2] Document policy of not relying on implicit eclass inherits
--- ebuild-writing/using-eclasses/text.xml | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/ebuild-writing/using-eclasses/text.xml b/ebuild-writing/using-eclasses/text.xml index de9ec7f..49ec23b 100644 --- a/ebuild-writing/using-eclasses/text.xml +++ b/ebuild-writing/using-eclasses/text.xml @@ -26,7 +26,15 @@ link=::general-concepts/portage-cache/). /p p -After inheriting an eclass, its provided functions can be used as normal. Here'san example ebuild, cfoomatic-0.1-r2.ebuild/c, which uses four eclasses: +After inheriting an eclass, its provided functions can be used as normal. +/p +warning +You must not rely on provided functions of implicitly inherited eclasses. +As an example: if you use cepatch/c in your ebuild, you bmust/b +inherit ceutils.eclass/c directly, even if another eclass (like distutils-r1) +already inherits it. Exceptions to this policy must be discussed and documented. +/warning +pHere'san example ebuild, cfoomatic-0.1-r2.ebuild/c, which uses four eclasses: /p codesample lang=ebuild -- 2.2.1
Re: [gentoo-dev] Re: Policies for games dirs, new group gamestat for sgid binaries
On 02/25/2015 04:47 PM, Rich Freeman wrote: On Wed, Feb 25, 2015 at 10:44 AM, hasufell hasuf...@gentoo.org wrote: On 02/21/2015 10:16 PM, Andreas K. Huettel wrote: Am Samstag, 21. Februar 2015, 20:16:31 schrieb hasufell: What did the council say again about the functionality of the team? What's the argumentation to not do anything, except deciding policies over it's head? functionality != willingness to interact with others So if a project ignores the community, the council, the QA team AND violates GLEP39, we allow that, because they still do commits? Nobody is ignoring anything. Council/QA has stepped in to clean things up. You fixed a bug, you didn't fix the reason the bug was unhandled for 9 years. What specific action are you advocating for which hasn't been done? Start with enforcing GLEP39 which is still violated.
Re: [gentoo-dev] Re: Policies for games dirs, new group gamestat for sgid binaries
On 02/21/2015 10:16 PM, Andreas K. Huettel wrote: Am Samstag, 21. Februar 2015, 20:16:31 schrieb hasufell: What did the council say again about the functionality of the team? What's the argumentation to not do anything, except deciding policies over it's head? functionality != willingness to interact with others So if a project ignores the community, the council, the QA team AND violates GLEP39, we allow that, because they still do commits? That isn't very logical.
[gentoo-dev] [PATCH 2/2] Fix spelling
--- ebuild-writing/using-eclasses/text.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ebuild-writing/using-eclasses/text.xml b/ebuild-writing/using-eclasses/text.xml index 49ec23b..b54f559 100644 --- a/ebuild-writing/using-eclasses/text.xml +++ b/ebuild-writing/using-eclasses/text.xml @@ -34,7 +34,7 @@ As an example: if you use cepatch/c in your ebuild, you bmust/b inherit ceutils.eclass/c directly, even if another eclass (like distutils-r1) already inherits it. Exceptions to this policy must be discussed and documented. /warning -pHere'san example ebuild, cfoomatic-0.1-r2.ebuild/c, which uses four eclasses: +pHere's an example ebuild, cfoomatic-0.1-r2.ebuild/c, which uses four eclasses: /p codesample lang=ebuild -- 2.2.1
Re: [gentoo-dev] Re: Policies for games dirs, new group gamestat for sgid binaries
On Wed, Feb 25, 2015 at 10:44 AM, hasufell hasuf...@gentoo.org wrote: On 02/21/2015 10:16 PM, Andreas K. Huettel wrote: Am Samstag, 21. Februar 2015, 20:16:31 schrieb hasufell: What did the council say again about the functionality of the team? What's the argumentation to not do anything, except deciding policies over it's head? functionality != willingness to interact with others So if a project ignores the community, the council, the QA team AND violates GLEP39, we allow that, because they still do commits? Nobody is ignoring anything. Council/QA has stepped in to clean things up. What specific action are you advocating for which hasn't been done? -- Rich
Re: [gentoo-dev] Re: Policies for games dirs, new group gamestat for sgid binaries
On 02/21/2015 10:16 PM, Andreas K. Huettel wrote: Am Samstag, 21. Februar 2015, 20:16:31 schrieb hasufell: What did the council say again about the functionality of the team? What's the argumentation to not do anything, except deciding policies over it's head? functionality != willingness to interact with others (seems to be a recurring problem, not everyone is equally prone to fill our mailboxes) # of commits 1/12/2014 - 7/2/2015 in gentoo-x86 15 Julian Ospald 148 Alfredo Tupone 251 Michael Sterrett Sure, because I stopped working on the gentoo games in g-x86. I have over 300 commits in gentoo-games overlay from that time period. Any questions?
Re: [gentoo-dev] Re: Policies for games dirs, new group gamestat for sgid binaries
On Wed, Feb 25, 2015 at 10:52 AM, hasufell hasuf...@gentoo.org wrote: What specific action are you advocating for which hasn't been done? Start with enforcing GLEP39 which is still violated. I said specific - what do you mean by enforcing GLEP39? -- Rich
Re: [gentoo-dev] [PATCH 1/2] Document policy of not relying on implicit eclass inherits
On 02/25/2015 05:55 PM, Ulrich Mueller wrote: On Wed, 25 Feb 2015, Julian Ospald wrote: +warning +You must not rely on provided functions of implicitly inherited eclasses. Not sure if this can be stated as a general policy. For example, if your ebuild inherits elisp.eclass then it is pointless to inherit also elisp-common.eclass, because it is guaranteed (and documented) that all the functions of the latter will also be available when inheriting the former. Yes, see blow. +As an example: if you use cepatch/c in your ebuild, you bmust/b +inherit ceutils.eclass/c directly, even if another eclass (like distutils-r1) +already inherits it. Exceptions to this policy must be discussed and documented. +/warning Documented, maybe. But I don't want to discuss a feature of my eclasses which is in place since more than a decade and works flawlessly. What wording do you suggest instead? Maybe Exceptions to this policy are documented in the respective eclasses?
Re: [gentoo-dev] [PATCH 1/2] Document policy of not relying on implicit eclass inherits
On Wed, 25 Feb 2015, Julian Ospald wrote: +warning +You must not rely on provided functions of implicitly inherited eclasses. Not sure if this can be stated as a general policy. For example, if your ebuild inherits elisp.eclass then it is pointless to inherit also elisp-common.eclass, because it is guaranteed (and documented) that all the functions of the latter will also be available when inheriting the former. +As an example: if you use cepatch/c in your ebuild, you bmust/b +inherit ceutils.eclass/c directly, even if another eclass (like distutils-r1) +already inherits it. Exceptions to this policy must be discussed and documented. +/warning Documented, maybe. But I don't want to discuss a feature of my eclasses which is in place since more than a decade and works flawlessly. Ulrich pgpBfzuv6Vi9V.pgp Description: PGP signature
Re: [gentoo-dev] Re: Policies for games dirs, new group gamestat for sgid binaries
On Wed, 25 Feb 2015, Diamond wrote: It looks like I can't edit https://wiki.gentoo.org/wiki/Project:Games/Ebuild_howto, is it a bug? You can't because it is a project page. But I think you can leave a message there on the talk page. gamesenv function looks outdated there. This function is seems like done by adding RDEPEND=games-misc/games-envd to packages in games category now (according to games.eclass)? I guess they have changed it because they want to avoid orphan files. Ulrich pgpd1Z6xtRd8g.pgp Description: PGP signature
Re: [gentoo-dev] Re: Policies for games dirs, new group gamestat for sgid binaries
On Wed, 25 Feb 2015 16:44:28 +0100 hasufell hasuf...@gentoo.org wrote: So if a project ignores the community, the council, the QA team AND violates GLEP39, we allow that, because they still do commits? It looks like I can't edit https://wiki.gentoo.org/wiki/Project:Games/Ebuild_howto, is it a bug? gamesenv function looks outdated there. This function is seems like done by adding RDEPEND=games-misc/games-envd to packages in games category now (according to games.eclass)?
Re: [gentoo-portage-dev] Pre RFC on RFC: Add compiler information to exported a Package Manger's Cached Information.
On 02/25/15 14:51, Anthony G. Basile wrote:
On 02/22/15 01:30, Zac Medico wrote:
On 02/21/2015 10:22 PM, Zac Medico wrote:
If we put the real/canonical libstdc++.so path in the DT_NEEDED section,
then it will automatically work with existing soname dependency support.
Actually, we'd also have to add a way for you to put the full path of
the libstdc++.so in PROVIDES. For example:
PROVIDES_ABSOLUTE=/usr/lib/gcc/*/*/libstdc++.so.6
I guess I don't understand how this would work exactly. What if someone
has gcc-4.8.3. Builds library libfoo.so which uses c++. Then upgrades
to gcc-4.9, removes 4.8 and then tries to build bar which is also
written in c++ and links against libfoo.so. We would have mismatching
abis. How would this catch it and trigger the correct rebuilds?
Unless I'm misunderstanding your *'s in that line. Are you using
PROVIDES_ABSOLUTE as a way of recording what version of the compiler
libfoo.so was build with? So that you'd have a line that says libfoo.so
links against /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so, so
that parsing that line gives 4.8.3?
Also if you had the absolute path in VDB somewhere, like in PROVIDES,
then you don't need it in the elf's rpath which would make me feel better.
Actually no, you'd still need rpath for the elf itslef otherwise you can
still link against the wrong version of libstdc++.so. Note in my
following example that even though I build test.cpp with 4.7.3 I still
wind up linking aginast 4.8.3.
yellow tmp # cat test.cpp
#include iostream
using namespace std;
int main() { cout hello owrld endl ; }
yellow tmp # gcc-config -l
[1] x86_64-pc-linux-gnu-4.7.3 *
[2] x86_64-pc-linux-gnu-4.7.3-hardenednopie
[3] x86_64-pc-linux-gnu-4.7.3-hardenednopiessp
[4] x86_64-pc-linux-gnu-4.7.3-hardenednossp
[5] x86_64-pc-linux-gnu-4.7.3-vanilla
[6] x86_64-pc-linux-gnu-4.8.3
[7] x86_64-pc-linux-gnu-4.8.3-hardenednopie
[8] x86_64-pc-linux-gnu-4.8.3-hardenednopiessp
[9] x86_64-pc-linux-gnu-4.8.3-hardenednossp
[10] x86_64-pc-linux-gnu-4.8.3-vanilla
yellow tmp # g++ -o go test.cpp
yellow tmp # ldd go
linux-vdso.so.1 (0x033f63717000)
libstdc++.so.6 = /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6
(0x033f631cf000)
libm.so.6 = /lib64/libm.so.6 (0x033f62ecb000)
libgcc_s.so.1 = /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1
(0x033f62cb4000)
libc.so.6 = /lib64/libc.so.6 (0x033f628f8000)
/lib64/ld-linux-x86-64.so.2 (0x033f634f6000)
yellow tmp # g++ -Wl,-rpath,/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/ -o
go test.cpp
yellow tmp # ldd go
linux-vdso.so.1 (0x036035212000)
libstdc++.so.6 = /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6
(0x036034ccf000)
libm.so.6 = /lib64/libm.so.6 (0x0360349cb000)
libgcc_s.so.1 = /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libgcc_s.so.1
(0x0360347b4000)
libc.so.6 = /lib64/libc.so.6 (0x0360343f8000)
/lib64/ld-linux-x86-64.so.2 (0x036034ff1000)
--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197
Re: [gentoo-portage-dev] Pre RFC on RFC: Add compiler information to exported a Package Manger's Cached Information.
On 02/22/15 01:30, Zac Medico wrote: On 02/21/2015 10:22 PM, Zac Medico wrote: If we put the real/canonical libstdc++.so path in the DT_NEEDED section, then it will automatically work with existing soname dependency support. Actually, we'd also have to add a way for you to put the full path of the libstdc++.so in PROVIDES. For example: PROVIDES_ABSOLUTE=/usr/lib/gcc/*/*/libstdc++.so.6 I guess I don't understand how this would work exactly. What if someone has gcc-4.8.3. Builds library libfoo.so which uses c++. Then upgrades to gcc-4.9, removes 4.8 and then tries to build bar which is also written in c++ and links against libfoo.so. We would have mismatching abis. How would this catch it and trigger the correct rebuilds? Unless I'm misunderstanding your *'s in that line. Are you using PROVIDES_ABSOLUTE as a way of recording what version of the compiler libfoo.so was build with? So that you'd have a line that says libfoo.so links against /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so, so that parsing that line gives 4.8.3? Also if you had the absolute path in VDB somewhere, like in PROVIDES, then you don't need it in the elf's rpath which would make me feel better. -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197
Re: [gentoo-dev] do we need special elog messages for bindist?
On Wed, Feb 25, 2015 at 1:38 PM, Mike Gilbert flop...@gentoo.org wrote: I would like to remove the elog for a couple of reasons: 1. The use flag description is there for whoever cares to read it. There is no need to alert the user every time. 2. We are not lawyers, and I have no business giving legal advice about patent law which varies from country to country. To take it one step further: I think it would make more sense to call the flag h264 or something similar. We could then set RESTRICT=h264? ( bindist ) if we want to give some indication that it is not appropriate for binary redistribution. What you're saying here makes sense and I agree, but our users are already pretty confused about USE=bindist... what it does, why it's enabled by default, etc. If this is going to stay enabled by default in our stage3s (there's an open bug about possibly changing that) then I really think we should add a paragraph to the handbook that explains things. It seems that most new users don't have any idea what bindist is until they find some feature missing or they hit the classic openssl/openssh blocker and someone has to explain the whole thing to them. So in summary, let's get rid of the per-ebuild einfo warnings but let's educate the users about USE=bindist earlier. -Ben
[gentoo-dev] do we need special elog messages for bindist?
I'm looking at https://bugs.gentoo.org/show_bug.cgi?id=538628 which suggests removing elog messages chromium has for bindist: This is the snippet we use in the ebuild: if use bindist; then elog bindist enabled: H.264 video support will be disabled. else elog bindist disabled: Resulting binaries may not be legal to re-distribute. fi I think I used existing examples, e.g. from firefox ebuilds. Anyway, do you consider the part when bindist is disabled necessary? I'm open to removing it if it's not needed. While we're discussing this, do you consider the message when bindist is enabled useful? bindist is described in chromium's metadata.xml: Disable patent-encumbered HTML5 video codecs. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] do we need special elog messages for bindist?
On Wed, Feb 25, 2015 at 1:17 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: I'm looking at https://bugs.gentoo.org/show_bug.cgi?id=538628 which suggests removing elog messages chromium has for bindist: This is the snippet we use in the ebuild: if use bindist; then elog bindist enabled: H.264 video support will be disabled. else elog bindist disabled: Resulting binaries may not be legal to re-distribute. fi I think I used existing examples, e.g. from firefox ebuilds. Anyway, do you consider the part when bindist is disabled necessary? I'm open to removing it if it's not needed. While we're discussing this, do you consider the message when bindist is enabled useful? bindist is described in chromium's metadata.xml: Disable patent-encumbered HTML5 video codecs. I would like to remove the elog for a couple of reasons: 1. The use flag description is there for whoever cares to read it. There is no need to alert the user every time. 2. We are not lawyers, and I have no business giving legal advice about patent law which varies from country to country. To take it one step further: I think it would make more sense to call the flag h264 or something similar. We could then set RESTRICT=h264? ( bindist ) if we want to give some indication that it is not appropriate for binary redistribution.
Re: [gentoo-portage-dev] Pre RFC on RFC: Add compiler information to exported a Package Manger's Cached Information.
On 02/25/2015 11:51 AM, Anthony G. Basile wrote: On 02/22/15 01:30, Zac Medico wrote: On 02/21/2015 10:22 PM, Zac Medico wrote: If we put the real/canonical libstdc++.so path in the DT_NEEDED section, then it will automatically work with existing soname dependency support. Actually, we'd also have to add a way for you to put the full path of the libstdc++.so in PROVIDES. For example: PROVIDES_ABSOLUTE=/usr/lib/gcc/*/*/libstdc++.so.6 I guess I don't understand how this would work exactly. What if someone has gcc-4.8.3. Builds library libfoo.so which uses c++. Then upgrades to gcc-4.9, removes 4.8 and then tries to build bar which is also written in c++ and links against libfoo.so. We would have mismatching abis. How would this catch it and trigger the correct rebuilds? If the absolute libstdc++ path is recorded in DT_NEEDED, then libfoo.so built against gcc-4.8 will break as soon as gcc-4.8 is unmerged. It's easy to see that a rebuild is needed, because the DT_NEEDED data in NEEDED.ELF.2 shows that libfoo.so is linked against gcc-4.8. The relevant part of the DT_NEEDED data is also recorded in REQUIRES (which is available during soname dependency resolution for binary packages). Unless I'm misunderstanding your *'s in that line. Are you using PROVIDES_ABSOLUTE as a way of recording what version of the compiler libfoo.so was build with? No, it's for the gcc ebuild, in order to indicate that the absolute libstdc++ path should be included in PROVIDES, for the purposes of soname dependency resolution. So that you'd have a line that says libfoo.so links against /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so, so that parsing that line gives 4.8.3? No, this dependency information would propagate via DT_NEEDED. Any builds that use the -std= flag would be responsible for ensuring that the absolute libstdc++ path is recorded in DT_NEEDED, rather than the plain libstdc++.so.6 soname. Also if you had the absolute path in VDB somewhere, like in PROVIDES, then you don't need it in the elf's rpath which would make me feel better. Yeah, the absolute path of libstdc++ will be recorded in gcc's PROVIDES, thanks to the ebuild setting the PROVIDES_ABSOLUTE variable. The absolute path of libstdc++ that libfoo.so links against will be recorded in both NEEDED.ELF.2 and REQUIRES. There's no need for rpath. -- Thanks, Zac
Re: [gentoo-portage-dev] Pre RFC on RFC: Add compiler information to exported a Package Manger's Cached Information.
On 02/25/2015 12:01 PM, Anthony G. Basile wrote: On 02/25/15 14:51, Anthony G. Basile wrote: On 02/22/15 01:30, Zac Medico wrote: On 02/21/2015 10:22 PM, Zac Medico wrote: If we put the real/canonical libstdc++.so path in the DT_NEEDED section, then it will automatically work with existing soname dependency support. Actually, we'd also have to add a way for you to put the full path of the libstdc++.so in PROVIDES. For example: PROVIDES_ABSOLUTE=/usr/lib/gcc/*/*/libstdc++.so.6 I guess I don't understand how this would work exactly. What if someone has gcc-4.8.3. Builds library libfoo.so which uses c++. Then upgrades to gcc-4.9, removes 4.8 and then tries to build bar which is also written in c++ and links against libfoo.so. We would have mismatching abis. How would this catch it and trigger the correct rebuilds? Unless I'm misunderstanding your *'s in that line. Are you using PROVIDES_ABSOLUTE as a way of recording what version of the compiler libfoo.so was build with? So that you'd have a line that says libfoo.so links against /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so, so that parsing that line gives 4.8.3? Also if you had the absolute path in VDB somewhere, like in PROVIDES, then you don't need it in the elf's rpath which would make me feel better. Actually no, you'd still need rpath for the elf itslef otherwise you can still link against the wrong version of libstdc++.so. Note in my following example that even though I build test.cpp with 4.7.3 I still wind up linking aginast 4.8.3. If DT_NEEDED contains the absolute libstdc++.so path, it's guaranteed to link against the correct version, regardless of rpath. -- Thanks, Zac
Re: [gentoo-dev] [PATCH] qmake-utils.eclass: add qt{4,5}_get_bindir helper functions
On 20 February 2015 at 04:06, Jeroen Roovers j...@gentoo.org wrote: On Wed, 18 Feb 2015 19:58:29 +0800 Ben de Groot yng...@gentoo.org wrote: The attached patch proposes two helper functions to be added to qmake-utils.eclass. These functions echo the correct directory where qt binaries such as moc and lrelease are located. They can be used in ebuilds when such binaries need to be called directly. (Ebuilds should not rely on qtchooser for this.) Please review before I commit. Looks good (barring what Davide noted). Do you have a list of ebuilds that might benefit? I know net-analyzer/wireshark might, but it doesn't even use qmake-utils.eclass right now simply because it doesn't use qmake (but it does use moc and uic, so I wouldn't expect to find those functions in an eclass seemingly about qmake). Committed, with improvements by Davide. Based on a quick qgrep for lrelease/moc/uic, packages that would benefit are: app-cdr/qpxtool app-crypt/pinentry app-editors/znotes app-text/diffpdf app-text/qpdfview dev-util/universalindentgui games-board/qgo games-emulation/higan games-kids/cubetest games-util/higan-purify media-sound/lastfmplayer media-sound/musescore media-video/smplayer media-video/videocut media-video/vlc media-video/xvideoservicethief net-analyzer/wireshark net-im/psi net-im/skype net-p2p/transmission sci-calculators/speedcrunch sci-geosciences/gpsbabel sci-geosciences/merkaartor sci-visualization/qtiplot/ sys-boot/unetbootin -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] Re: why is a line in /usr/portage/profiles/base/package.use.mask ignored?
Alan McKinnon posted on Wed, 25 Feb 2015 14:00:57 +0200 as excerpted: Why are you messing around with the profile anyway, when all the available documentation in many many places tells you to set your chosen USE for specific packages in package.use? I believe you missed his email address, @gentoo.org. =8^0 IOW, he's a dev, trying to actually set a profile setting for others. But his own testing says it's not working, thus the question (for which bkohler has provided an answer). /That/ is why he's messing with the profile, instead of setting his chosen USE for that package in package.use. =:^) -- 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-portage-dev] Pre RFC on RFC: Add compiler information to exported a Package Manger's Cached Information.
On 02/25/2015 03:41 PM, Anthony G. Basile wrote: On 02/25/15 15:38, Zac Medico wrote: On 02/25/2015 12:01 PM, Anthony G. Basile wrote: On 02/25/15 14:51, Anthony G. Basile wrote: On 02/22/15 01:30, Zac Medico wrote: On 02/21/2015 10:22 PM, Zac Medico wrote: If we put the real/canonical libstdc++.so path in the DT_NEEDED section, then it will automatically work with existing soname dependency support. Actually, we'd also have to add a way for you to put the full path of the libstdc++.so in PROVIDES. For example: PROVIDES_ABSOLUTE=/usr/lib/gcc/*/*/libstdc++.so.6 I guess I don't understand how this would work exactly. What if someone has gcc-4.8.3. Builds library libfoo.so which uses c++. Then upgrades to gcc-4.9, removes 4.8 and then tries to build bar which is also written in c++ and links against libfoo.so. We would have mismatching abis. How would this catch it and trigger the correct rebuilds? Unless I'm misunderstanding your *'s in that line. Are you using PROVIDES_ABSOLUTE as a way of recording what version of the compiler libfoo.so was build with? So that you'd have a line that says libfoo.so links against /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so, so that parsing that line gives 4.8.3? Also if you had the absolute path in VDB somewhere, like in PROVIDES, then you don't need it in the elf's rpath which would make me feel better. Actually no, you'd still need rpath for the elf itslef otherwise you can still link against the wrong version of libstdc++.so. Note in my following example that even though I build test.cpp with 4.7.3 I still wind up linking aginast 4.8.3. If DT_NEEDED contains the absolute libstdc++.so path, it's guaranteed to link against the correct version, regardless of rpath. How do you get DT_NEEDED to the absolute libstdc++.so path when building? I'm not sure how we're going to accomplish that yet, but it should be feasible. Ideally, the build system would support it. The worst case would be that we would have to patch the DT_NEEDED sections after src_install. -- Thanks, Zac
Re: [gentoo-dev] [RFC] luajit global useflag
В письме от Чт, 26 февраля 2015 13:36:24 пользователь Ben de Groot написал: I propose we make luajit a global useflag, using the description from media-sound/csound: Use the lua just-in-time compiler pkgdev-lang/luajit/pkg instead of pkgdev-lang/lua/pkg Voting up! Although, I'd also propose lua.eclass and patch all ebuilds declaring Lua support to support building against LuaJIT as well (since they're fully compatible at runtime). -- Best regards, mva signature.asc Description: This is a digitally signed message part.
[gentoo-portage-dev] [PATCH] Do not interrupt on SIGCONT
From: Bertrand SIMONNET bsimon...@chromium.org SIGCONT signals should not interrupt any system calls (locking or wait pid for example). URL: http://crbug.com/417800 X-Gentoo-Bug-URL: https://bugs.gentoo.org/500436 --- pym/_emerge/Scheduler.py | 1 + 1 file changed, 1 insertion(+) diff --git a/pym/_emerge/Scheduler.py b/pym/_emerge/Scheduler.py index d6db311..6e3bf1a 100644 --- a/pym/_emerge/Scheduler.py +++ b/pym/_emerge/Scheduler.py @@ -1017,6 +1017,7 @@ class Scheduler(PollScheduler): earlier_sigterm_handler = signal.signal(signal.SIGTERM, sighandler) earlier_sigcont_handler = \ signal.signal(signal.SIGCONT, self._sigcont_handler) + signal.siginterrupt(signal.SIGCONT, False) try: rval = self._merge() -- 2.3.0
Re: [gentoo-dev] [PATCH 1/2] Document policy of not relying on implicit eclass inherits
On Wed, 25 Feb 2015, hasufell wrote: +As an example: if you use cepatch/c in your ebuild, you bmust/b +inherit ceutils.eclass/c directly, even if another eclass (like distutils-r1) +already inherits it. Exceptions to this policy must be discussed and documented. +/warning Documented, maybe. But I don't want to discuss a feature of my eclasses which is in place since more than a decade and works flawlessly. What wording do you suggest instead? Maybe Exceptions to this policy are documented in the respective eclasses? Exceptions to this policy must be documented in the inheriting eclass. BTW, for new eclasses there should be a discussion in -dev anyway. Ulrich pgpxODKDKKzUx.pgp Description: PGP signature
[gentoo-dev] [RFC] luajit global useflag
% quse -D luajit local:luajit:app-editors/gvim: Use dev-lang/luajit instead of dev-lang/lua local:luajit:app-editors/vim: Use dev-lang/luajit instead of dev-lang/lua local:luajit:app-editors/vim-qt: Use dev-lang/luajit instead of dev-lang/lua local:luajit:games-action/minetest: Use dev-lang/luajit instead of dev-lang/lua local:luajit:games-engines/solarus: Use LuaJIT instead of default Lua. local:luajit:games-roguelike/stone-soup: Use dev-lang/luajit as scripting backend instead of dev-lang/lua. local:luajit:media-sound/csound: Use the lua just-in-time compiler dev-lang/luajit instead of dev-lang/lua local:luajit:media-video/mpv: Use dev-lang/luajit instead of dev-lang/lua local:luajit:www-client/luakit: Use the lua just-in-time compiler dev-lang/luajit instead of dev-lang/lua, which should make luakit faster. local:luajit:www-servers/nginx: Use dev-lang/luajit instead of dev-lang/lua for lua support when building the lua http module. I propose we make luajit a global useflag, using the description from media-sound/csound: Use the lua just-in-time compiler pkgdev-lang/luajit/pkg instead of pkgdev-lang/lua/pkg -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] why is a line in /usr/portage/profiles/base/package.use.mask ignored?
Hello *, dev-lisp/ecls-15.2.21 does not compiled with USE=cpu_flags_x86_sse. So, I've added the line =dev-lisp/ecls-15.2.21 cpu_flags_x86_sse to .../profiles/base/package.use.mask. But I still see dns ~ # emerge -pv dev-lisp/ecls [ebuild R] dev-lisp/ecls-15.2.21:0/15.2.21::gentoo [15.2.21:0/15.2.21::grozin] USE=X emacs libatomic%* threads unicode -debug -gengc -precisegc CPU_FLAGS_X86=sse* 0 KiB Why isn't sse masked? Andrey
