Re: [gentoo-dev] new virtual: virtual/podofo-build
In order to solve bug #503802 [1], I would like to add a virtual/podofo-build package to pull in app-text/podofo and dev-libs/boost. Then packages like app-text/calibre can put virtual/podofo-build in DEPEND and app-text/podofo in RDEPEND. This sounds a bit like a one-time solution for a problem that occurs more frequently... It would be nice to have a more generic solution. :| -- Andreas K. Huettel Gentoo Linux developer kde, council
Re: [gentoo-dev] new virtual: virtual/podofo-build
On 10/15/2014 04:42 AM, Andreas K. Huettel wrote: In order to solve bug #503802 [1], I would like to add a virtual/podofo-build package to pull in app-text/podofo and dev-libs/boost. Then packages like app-text/calibre can put virtual/podofo-build in DEPEND and app-text/podofo in RDEPEND. This sounds a bit like a one-time solution for a problem that occurs more frequently... It would be nice to have a more generic solution. :| I's only been in the pms-bugs queue for about 3 years now: https://bugs.gentoo.org/show_bug.cgi?id=392239 -- Thanks, Zac
Re: Re: [gentoo-dev] new virtual: virtual/podofo-build
On 10/15/2014 04:42 AM, Andreas K. Huettel wrote: In order to solve bug #503802 [1], I would like to add a virtual/podofo-build package to pull in app-text/podofo and dev-libs/boost. Then packages like app-text/calibre can put virtual/podofo-build in DEPEND and app-text/podofo in RDEPEND. This sounds a bit like a one-time solution for a problem that occurs more frequently... It would be nice to have a more generic solution. :| I's only been in the pms-bugs queue for about 3 years now: https://bugs.gentoo.org/show_bug.cgi?id=392239 Right. My mind is full of holes. -- Andreas K. Huettel Gentoo Linux developer kde, council
Re: [gentoo-dev] new virtual: virtual/podofo-build
On Wed, Oct 15, 2014 at 7:42 AM, Andreas K. Huettel dilfri...@gentoo.org wrote: In order to solve bug #503802 [1], I would like to add a virtual/podofo-build package to pull in app-text/podofo and dev-libs/boost. Then packages like app-text/calibre can put virtual/podofo-build in DEPEND and app-text/podofo in RDEPEND. This sounds a bit like a one-time solution for a problem that occurs more frequently... It would be nice to have a more generic solution. :| If A depends on B, and in order to build A you need C, but in order to run B you do not need C, does it make sense to specify C as a dependency of B, rather than as a dependency of A? The risk I would see is whether that relationship holds 100% of the time. What if somebody comes up with an alternative to boost that is not 100% compatible, but it works for calibre (but not other packages that DEPEND on podofo)? I can see how this approach would work for something like split-headers. However, when you get into things like build systems it seems like this could be problematic. However, I haven't been thinking about this for 3 years... :) -- Rich
[gentoo-dev] Last rites: app-dicts/gnuvd
# Michael Palimaka kensing...@gentoo.org (15 Oct 2014) # No longer compatible with online service it depends on. # Dead upstream. Masked for removal in 30 days. Bug #451868. app-dicts/gnuvd
Re: [gentoo-dev] Removing a blocker from a stable package
that's intended. repoman warns for missing *needed* dependencies, but won't bother for unknown blockers exactly for cases like this. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 15 October 2014 01:25, Michael Orlitzky m...@gentoo.org wrote: On 10/13/2014 02:41 PM, Mike Gilbert wrote: I agree with Diego and Ralph: Go with d. repoman will generate a warning (not an error) about a dependency which does not exist, but this is safe to ignore. Given that (d) didn't require me to do anything else, I just went ahead and removed app-doc/djbdns-man. Repoman doesn't even warn. Huh.
Re: [gentoo-dev] Add gcc-specs-stack-check() to toolchain-funcs.eclass
On 10/12/14 17:22, Anthony G. Basile wrote:
On 10/12/14 15:55, Anthony G. Basile wrote:
On 10/12/14 15:46, Ulrich Mueller wrote:
On Sun, 12 Oct 2014, Dan Douglas wrote:
On Sun, Oct 12, 2014 at 11:22 AM, Anthony G. Basile
bluen...@gentoo.org wrote:
+# Returns true if gcc builds with fstack-check
+gcc-specs-stack-check() {
+local directive
+directive=$(gcc-specs-directive cc1)
+return $([[ ${directive/\{!fno-stack-check:} !=
${directive} ]])
+}
Am I missing something here? I don't see how any of the tests used
in gcc-specs-* functions could possibly produce an output. The fact
that this coincidentally works in Bash shouldn't be relied upon.
The command produces no output, so return is effectively called
without argument. Therefore it will return with the status of the last
command executed, which is [[ ]] ...
It would be clearer if the last line of the function was simply this:
[[ ${directive/\{!fno-stack-check:} != ${directive} ]]
Ulrich
Yeah the return there is useless and in fact deceiving. Its
returning a blank with an error code. Here's some bash to illustrate:
do_true() {
return $([[ 42 == 42 ]])
}
do_false() {
return $([[ 42 != 42 ]])
}
do_true # echo's nothing
do_false # echo's nothing
do_true ; echo $?
0
do_false ; echo $?
1
I can fix my function as well as the other gcc-specs-* in there,
which I just copied. I'll produce two patches for the community's
approval before committing anything. However, we'd better grep the
tree for those gcc-specs-* functions just in case something subtle is
going on.
Okay, I grepped the tree and there's nothing subtle that I can see. So
what I'll commit is the following:
1) First I'll clean up
--- toolchain-funcs.eclass.orig2014-10-12 11:23:41.585182742 -0400
+++ toolchain-funcs.eclass2014-10-12 17:19:30.086154455 -0400
@@ -169,7 +169,7 @@
# @FUNCTION: tc-is-cross-compiler
# @RETURN: Shell true if we are using a cross-compiler, shell false
otherwise
tc-is-cross-compiler() {
-return $([[ ${CBUILD:-${CHOST}} != ${CHOST} ]])
+[[ ${CBUILD:-${CHOST}} != ${CHOST} ]]
}
# @FUNCTION: tc-is-softfloat
@@ -210,7 +210,7 @@
local host=${CTARGET:-${CHOST}}
# *MiNT doesn't have shared libraries, only platform so far
-return $([[ ${host} == *-mint* ]])
+[[ ${host} == *-mint* ]]
}
# @FUNCTION: tc-export_build_env
@@ -578,37 +578,37 @@
gcc-specs-relro() {
local directive
directive=$(gcc-specs-directive link_command)
-return $([[ ${directive/\{!norelro:} != ${directive} ]])
+[[ ${directive/\{!norelro:} != ${directive} ]]
}
# Returns true if gcc sets now
gcc-specs-now() {
local directive
directive=$(gcc-specs-directive link_command)
-return $([[ ${directive/\{!nonow:} != ${directive} ]])
+[[ ${directive/\{!nonow:} != ${directive} ]]
}
# Returns true if gcc builds PIEs
gcc-specs-pie() {
local directive
directive=$(gcc-specs-directive cc1)
-return $([[ ${directive/\{!nopie:} != ${directive} ]])
+[[ ${directive/\{!nopie:} != ${directive} ]]
}
# Returns true if gcc builds with the stack protector
gcc-specs-ssp() {
local directive
directive=$(gcc-specs-directive cc1)
-return $([[ ${directive/\{!fno-stack-protector:} !=
${directive} ]])
+[[ ${directive/\{!fno-stack-protector:} != ${directive} ]]
}
# Returns true if gcc upgrades fstack-protector to fstack-protector-all
gcc-specs-ssp-to-all() {
local directive
directive=$(gcc-specs-directive cc1)
-return $([[ ${directive/\{!fno-stack-protector-all:} !=
${directive} ]])
+[[ ${directive/\{!fno-stack-protector-all:} != ${directive} ]]
}
# Returns true if gcc builds with fno-strict-overflow
gcc-specs-nostrict() {
local directive
directive=$(gcc-specs-directive cc1)
-return $([[ ${directive/\{!fstrict-overflow:} != ${directive}
]])
+[[ ${directive/\{!fstrict-overflow:} != ${directive} ]]
}
2) Then I'll add gcc-specs-stack-check()
--- toolchain-funcs.eclass2014-10-12 17:19:30.086154455 -0400
+++ /root/toolchain-funcs.eclass2014-10-12 17:19:05.983153358 -0400
@@ -610,6 +610,12 @@
directive=$(gcc-specs-directive cc1)
[[ ${directive/\{!fstrict-overflow:} != ${directive} ]]
}
+# Returns true if gcc builds with fstack-check
+gcc-specs-stack-check() {
+local directive
+directive=$(gcc-specs-directive cc1)
+[[ ${directive/\{!fno-stack-check:} != ${directive} ]]
+}
# @FUNCTION: gen_usr_ldscript
This has been committed to the tree. Please alert asap if anything
breaks. Thanks!
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
Re: virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3
On Fri, 10 Oct 2014, Rich Freeman wrote: On Fri, Oct 10, 2014 at 5:31 PM, W. Trevor King wk...@tremily.us wrote: On Fri, Oct 10, 2014 at 09:22:18PM +, Robin H. Johnson wrote: In a similar vein, would releng be open to moving stage1/2/3 package sets to virtual packages or package sets? Presently they are inside catalyst, and I think this would clean things up a lot. They're already in the Portage tree (the profile's packages.build for stage1, scripts/bootstrap.sh for stage2, and the profile's packages for stage3) [1]. Obviously this entails work on somebody's part, but would it still make sense to make the stage build process more generic along the lines Robin suggested? That is, instead of having 3 specific places we use to generate a stage1/2/3, we instead just define a stage as a virtual of some kind that optionally depends on another stage (not necessarily using the standard DEPEND mechanism) and then pulls in a list of packages. The root stage would not depend on another stage, and therefore would be built from the host system. All of the above suggestions would require changes to catalyst. In any case, given the way we build a stage1 and bootstrap stage2, that isn't possible. For stage1 and stage2 the *order* we build packages is relevant. We rely on portage following that list in sequence. Furthermore, because of the implicit dependencies and issues with circular dependencies, it would likely be impossible for portage to resolve the list of packages to build for stage1 and stage2 from a virtual. The build system would just iteratively start at the bottom and output a tarball or whatever as each level is completed, then use that as the basis for bootstrapping the next. That's how catalyst already works. To address one point in your last sentence in the above quote: The root stage would not depend on another stage, and therefore would be built from the host system. You almost always don't want to build with the state of a live system, but of a clean seed - that's why releng tells catalyst to use a stage3 as the seed for the stage1. Such a design would also eliminate the need to have the same list of packages define the contents of @system and a stage3. It could also support any number of stages, with any names we wish. No, not really. You're over-thinking this. To be able to split the system set and the stages releng provides, all we need is to fix the bug that was already mentioned before and have releng provide stages built from a stage3 (while removing some packages from the system set) and a list of packages that we want to provide (the ones dropped from system and a select few others). I would also still have stage builds use a profile of some kind - that could be useful from a standpoint of setting USE flags and so on. However, if it made sense to build earlier stages with different flags they could still be specified as USE dependencies (maybe due to circular deps you have to build a package with different set of USE flags before you can build the desired USE flags in a later stage). We build stages using a profile. One of the variables set on stage specs is profile to list the profile to be used in the stage. -- Rich Regards, Jorge Manuel B. S. Vicetto Gentoo Developer PS - As I've warned before, I'm not following closely the dev ml. So you got this reply now, because I just happened to look at the emails in this ml. If you want me to comment further, your best option is to poke me about it.
Re: virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3
On Thu, Oct 16, 2014 at 12:13:45AM +, Jorge Manuel B. S. Vicetto wrote: For stage1 and stage2 the *order* we build packages is relevant. Is this really true? The stage1 is being built with ROOT, so it's only using the seed stage3 packages. It's hard to have cyclic dependencies when you're using packages from one root (the seed stage3) but installing into another (/tmp/stage1root). Looking through a stage1 log I see: emerge --quiet --oneshot --nodeps --update sys-apps/portage … emerge --quiet --update --deep --newuse --complete-graph --rebuild-if-new-ver gcc … emerge --quiet --usepkg --buildpkg --newuse --oneshot --nodeps sys-apps/baselayout … emerge --quiet --usepkg --buildpkg --newuse --oneshot sys-devel/gnuconfig sys-devel/bison … The first two are just covering us against serious missmatches between the package tree and the seed stage3 (and are installed with ROOT=/). I expect we could handle shoving baselayout into the final emerge along with the other packages.build stuff. The logs for stage2 aren't as clear, but looking through the script I only see: * A Portage-updating emerge * The main GCC, binutils, … emerge * A possible 'emerge --prune sys-devel/gcc' I'm not sure this is needed at all. I'll try and find time to build a stage3 directly from a stage1, and we'll see if it blows up ;). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [RFC] Package description index file format for faster emerge search actions
On 10/14/14 02:40, Zac Medico wrote: Hi, As we all know, emerge --search/--searchdesc actions are embarrassingly slow (from most users' perspectives, anyway), especially in comparison to external tools like eix and esearch. Wouldn't it be nice if the performance of emerge's search functionality was more competitive with other offerings? Then, external search tools might not be seen as an absolute necessity. In order to solve this problem, I suggest that we add support for a package description index file format. For example, the attached script will generate a suitable index formatted as series of lines like this: sys-apps/sandbox-1.6-r2,2.3-r1,2.4,2.5,2.6-r1: sandbox'd LD_PRELOAD hack Using this format, the index file for the entire gentoo-x86 repository consumes approximately 1.5 MB. The whole file can be quickly searched as a stream (the whole file need not be in memory at once), yielding emerge --search/--searchdesc performance that will be competitive with app-portage/esearch. The index can either be generated on the server side by egencache, or on the client side by a post emerge --sync hook. It makes sense to support both modes of operation, so that server side generation is purely optional. What do others think about this proposal? Please do this. Once this is in place, I will probably deprecate esearch and point users to emerge for basic searching and eix for advanced searching. Regards, Paul
